Q/LB.□XXXXX-XXXX目次TOC\o"1-1"\h\t"標準文件_一級條標題,2,標準文件_附錄一級條標題,2,"前言 II1范圍 12規范性引用文件 13術語和定義 14縮略語 15應用構件架構 15.1概述 15.2構件主體 25.3關聯依賴 25.4存儲中心 25.5構件接口 25.6基礎信息 25.7測試用例 25.8與外部系統交互 25.9構件運行時 36開發要求 36.1開發流程 36.2環境資源要求 36.3設計要求 36.4構件定義 46.5構件接口定義 66.6構件封裝 116.7構件測試 126.8構件發布 13附錄A（資料性）yaml文件的關鍵配置信息示例 14附錄B（資料性）values.yaml文件的關鍵配置信息示例 15前言本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規則》的規定起草。請注意本文件的某些內容可能涉及專利。本文件的發布機構不承擔識別專利的責任。本文件由北京智能制造創新聯盟提出。本文件由北京智能制造創新聯盟歸口。本文件起草單位：本文件主要起草人：工業互聯應用構件開發規范范圍本文件規定了企業研發制造資源共享服務平臺上應用構件的架構和開發要求，并給出了構件封裝的關鍵配置信息示例。本文件適用于指導企業研發制造資源共享服務平臺上應用構件的開發和測試。規范性引用文件下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。GB/T36455—2018軟件構件模型術語和定義下列術語和定義適用于本文件。構件component軟件系統中具有相對獨立功能、可以明確辨識、接口由契約指定、和語境有明顯依賴關系、可獨立部署的可組裝軟件實體。構件接口componentinterface軟件構件對外交流和交互的唯一通道。構件庫componentlibrary一種支持軟件復用的基礎設施。它提供對軟件構件進行描述、分類、存儲和檢索等功能。縮略語下列縮略語適用于本文件。CI：持續集成（Continuous

Integration）CD：持續交付（Continuous

Delivery）與持續部署（ContinuousDeployment）UAT：用戶驗收測試（UserAcceptanceTesting）API：應用程序接口（ApplicationProgrammingInterface）YAML：YAMLAin'taMarkupLanguage的遞歸縮寫，一種數據序列化標準應用構件架構概述應用構件為企業提供各類工業互聯應用服務，支持直接或組合應用，應用構件由構件主體、構件存儲中心、關聯依賴、基礎信息和構件接口五個部分組成，應用構件架構如圖1所示。應用構件架構圖構件主體構件主體是構件的核心部分，包含實現特定功能或服務的代碼，編程語言包括Java、Python、JavaScript等，具體取決于構件的需求和團隊的技術棧。關聯依賴關聯依賴是構件在運行時或編譯時所需的其他庫、框架、服務或數據，這些依賴項可以是內部的（例如構件庫中的其他構件）或外部的（例如第三方庫或API），為了確保構件的可移植性和一致性，所有依賴項都應被明確列出，并且應通過版本控制系統（如Maven、npm、Pip等）進行管理。存儲中心存儲中心是應用構件的存儲倉庫，負責存儲應用構件的各種數據，提供高效的數據檢索能力，并保證數據一致性和安全性。構件接口構件接口定義構件與其他構件或外部系統之間的交互方式，此外，接口還可以用于生成文檔和進行代碼自動生成，簡化開發過程。基礎信息基礎信息描述構件的詳情和基本信息，包含構件的基本情況和功能特點，便于用戶在需要時選擇合適的構件進行部署和使用。測試用例測試用例用于驗證構件功能的正確性，包括一系列自動化測試腳本和測試步驟，用于確保構件在不同條件下都能按預期工作，測試用例應覆蓋構件的所有主要功能點、邊界條件和異常處理邏輯，通過使用持續集成（CI）工具，可以自動運行測試用例，確保在每次代碼更改后都能及時發現問題。與外部系統交互構件與外部系統交互可以是同步的，也可以是異步的，具體取決于構件的設計和實現。在交互過程中，構件需要確保數據的正確性和一致性，并處理可能出現的錯誤和異常情況。構件運行時構件運行時表示構件運行時環境，包括必要的資源、庫和框架等，是用于創建、管理和運行構件的工具。開發要求開發流程如圖2所示，應用構件的規范化開發能夠使企業統一、靈活、簡便地使用和組合各種應用。應用構件的開發流程如下：構件定義，根據使用需求，開發人員進行構件開發，并且根據構件標準化格式進行構件的修改和調整；構件接口定義，利用構件接口規則，對構件接口進行規范化開發；構件封裝，進行構件代碼質量檢查后，對符合構件設計標準的構件進行打包生成構件鏡像和Chart格式；構件測試，將應用構件鏡像通過CI/CD自動部署到測試環境，系統自動完成UAT測試、功能測試和性能測試；構件發布，將擁有標準接口的構件推送到構件庫，并進行構件版本控制，以供不同需求用戶匹配使用。其中，步驟a-b由構件開發者按照標準化定義格式完成，步驟c-e由平臺根據開發者提交的構件源文件自動完成。應用構件開發流程環境資源要求本文件定義的應用構件以容器方式運行，支持以下運行環境：Docker；Kubernetes?；Node-RED；OCI；runc；CRI-O。設計要求應用構件的設計應符合下列要求：每個構件應只關注一個特定的業務功能，避免將多個不相關的功能集成在一個應用構件中；支持代碼編輯環境，包括常規配置、代碼編輯等設置選項；支持構件版本向下兼容；支持構件參數的修改，能讓用戶根據個人需求修改構件；明確日志規范，規定日志輸出的格式和應當包含的內容；支持多個應用構件的關聯組合；支持企業快速構建、構件動態擴展和多應用場景遷移；支持應用構件的調用和部署；提供在線開發和離線開發上傳的方式；支持多個協同在線開發。構件定義構件分類根據功能和結構特性，構件可以劃分為不同的類別，包括：基礎構件，提供基本的計算、存儲、通信等底層服務，包括數據可視、消息構件、報警構件、算法模型、成分分析模型等；業務構件，實現常見的業務邏輯、數據處理等功能，包括物料跟蹤、設備管理、運維巡檢、輔助調度、計算服務、工藝優化、檢測報告智能生成等；智能構件，具有更強的專業性，包括故障診斷、故障預警、能耗分析、設備畫像、健康維護、安全檢測、設備定位等。構件文件目錄構件在開發時需要遵循一定的文件組織規范，如圖3所示，分別存放構件測試用例、構件主體、構件關聯依賴、構件存儲中心、構件接口和構件基礎信息六個部分，其余部分的文件組織形式不做規范要求，模型開發者可進行個性化開發。應用構件文件目錄構件主體構件主體包含構件的全部功能代碼，用于實現構件的主要功能和業務邏輯，根據用戶需求，明確應用構件的需求場景和實現功能，應滿足以下要求：代碼編寫規范，可讀性高；擁有明確的功能，具有實際應用意義；只關注單一的功能或服務，便于復用和維護；對每個關鍵語句單獨說明，并提供錯誤提示；具備數據備份和數據恢復策略，確保數據的可靠性；提供錯誤的報警和基礎錯誤的恢復功能，便于用戶使用。構件測試用例構件測試用例是構件測試中的核心組成部分，用于驗證構件是否滿足規定的需求和功能。測試用例的設計和實現應遵循一系列的要求，以確保測試的全面性和有效性。測試用例應滿足以下要求：需求覆蓋，測試用例應覆蓋所有的需求點，確保被測功能100%被覆蓋；正確性驗證，驗證正確性操作、正常數據和可能導致出錯的數據、操作；數據值域覆蓋，有數據值域的必須考慮數據值域覆蓋，包括邊界值和等價類，所有邊界值都必須覆蓋，等價類必須包含有效和無效等價類，且等價類各子類不存在交錯以避免冗余，同時，等價類的使用應避開邊界值重疊的情況；明確性，測試用例中的描述應清晰明確，不存在二義性或多義性，不會因執行人不同而產生不同執行結果；預期結果，每個測試用例都應有明確的預期結果，便于準確判斷是否符合要求。測試用例編寫應包含以下要素：用例編號，具有唯一性，通常由字符和數字組成的字符串，易于識別。不同階段的測試用例應有不同的編號規則；測試項目，對應測試用例編號中的測試子項名，可以是功能點、性能指標、界面控件等；測試標題，簡要說明測試用例的出發點、關注點以及期望的測試結果；重要級別，根據測試用例的重要程度進行劃分，如高、中、低等級別，便于制定測試規程和回歸測試；預置條件，測試用例在執行前需要滿足的前提條件，包括環境設置、其他測試用例的執行結果等；測試輸入，測試用例執行過程中需要加工的外部信息，如手工輸入、文件、數據庫記錄等；操作步驟，執行當前測試用例需要經過的操作步驟，需要明確的給出每一個步驟的描述；預期輸出，測試用例執行后的預期結果，包括界面顯示、數據庫變化、相關信息變化等。構件關聯依賴構件關聯依賴包括：——組件依賴，可能依賴于其他構件提供的功能或服務，或是依賴于各種第三方庫，如數學計算庫、數據庫連接庫、網絡通信庫等；——框架依賴，包含運行的系統和計算框架，如Spring、Django等，這些框架本身可能包含多個庫和組件，需要依賴這些框架來構建和運行；——數據依賴，可能依賴于配置文件中的參數或設置運行；——環境依賴，可能需要在特定的硬件環境上運行；——版本依賴，可能依賴于特定版本的構件或庫。構件存儲中心存儲中心應支持：數據庫，采用關系型數據庫（如MySQL、PostgreSQL）或非關系型數據庫（如MongoDB、Cassandra）等技術來實現數據存儲和管理；分布式存儲，對于需要處理大量數據或具有高可用性和容錯性要求的構件，采用分布式存儲（如Hadoop、Cassandra等）來實現數據存儲和擴展性；緩存，為了提高數據訪問速度，采用緩存技術（如Redis、Memcached等）來存儲常用的數據或查詢結果。構件基礎信息構件基礎信息用于標識、描述和管理構件，構件基礎信息包括：ID，唯一標識構件的編號；名稱，正式名稱；類型，構件所屬的類別；詳情，描述構件功能和使用方法；用途，主要用途或應用場景；接口定義，構件提供的接口的定義，包括輸入輸出、接口說明等；定價，用戶使用構件需要支付的金額；開發者，開發人員；創建時間，構件開發的時間；版本，用于區分不同版本的構件。構件接口定義接口描述規則構件接口是對外交互的唯一通道，是構件外部可見行為的描述。應用構件的接口描述規則如下：協議規范：采用https或http協議；域名規范：接口有且僅有一個域名和端口；API路徑規范：為了和其他路徑區分，必須在路徑中添加api目錄；版本控制規范：正式版本的服務組件應確定接口版本，備份接口代碼，并在接口路徑中加入版本信息；API命名規范：url為域名規范+API路徑規范+版本控制規范；方法規范：采用http標準方法，如GET，POST，PUT，DELETE等；請求參數規范：公共數據使用GET方式請求，私有數據使用POST方式請求，盡量全部用POST，請求頭據需求添加配置參數；接口數據格式規范：使用JSON或者XML格式數據。接口規范構件接口應規范化定義，如圖4所示，一個應用構件的接口應包含：接口描述字段，對該接口的功能和作用進行較為詳細的闡述，使用戶能夠了解如何與該接口對接；請求地址字段，該請求從什么地方發出；請求方式字段，該請求以什么協議發出；資源描述字段，該接口需要何種資源，實際體現為該構件需要什么請求參數，同時還需要在此字段對具體的返回參數進行說明，并且給出一個正常的返回示例；資源地址字段，資源存儲在公共地址，構件訪問該地址進行資源的獲取；模型調用字段，寫明構件將調用什么模型。應用構件接口json格式圖接口分類應用構件通用接口模型如圖5所示，通用接口主要分為：人機交互接口，用于用戶與構件之間進行交流和指令交互，包括查詢構件信息和查詢構件狀態等；數據接口，用于數據的傳輸，包括向應用構件輸入數據、從外部數據源獲取數據、從應用構件輸出數據等；控制接口，用于對數據傳輸進行控制和管理，包括修改構件參數、運行控制等；第三方工具接口，用于連接第三方工具，如依賴關系的構件、智能模型，進行實時數據處理、信息與健康檢測等。應用構件通用接口模型接口定義應用構件接口定義見表1：應用構件通用接口說明表接口類型接口描述接口名稱功能說明人機交互接口查詢構件信息GetInfo查看構件詳情查詢構件狀態GetCon查看構件運行狀態數據接口輸入數據InputData向構件輸入數據外部數據調用GetEnternalData從外部數據源獲取數據輸出數據OutputData從構件輸出數據控制接口修改參數ChangeOP上傳和修改構件運行參數運行控制ControlRun控制構件運行過程第三方工具接口依賴連接ConnectTool連接其他構件或第三方應用工具實時數據分析工具集成RealTimeTool與實時數據分析工具集成信息與健康檢測工具集成HealthTool在構件自動化部署時，使用LivenessProbe和ReadinessProbe進行容器健康信息檢測；在模型運行時反饋模型細節，控制參數等輸入輸出數據類型各類接口涉及的輸入輸出數據類型包括：command類，為命令；number類，為數字；string類，為字符串；image類，為圖片；voice類，為音頻；video類，為視頻；file類，為文件；zip類，為壓縮包。人機交互接口查詢構件信息接口查看構件詳情的接口說明見表2。狀態碼用于判斷執行結果是否成功。查詢構件信息接口說明接口定義StringGetInfo(StringComName)URLhttp://localhost:8080/GetInfo請求方式GET參數構件名稱ComName返回內容狀態碼構件詳情ComInfo查詢構件狀態接口查看構件運行狀態，如是否正在運行、已完成、失敗等，接口說明見表3。查詢構件狀態接口說明接口定義StringGetCon(StringComName)URLhttp://localhost:8080/GetCon請求方式GET參數構件名稱ComName返回內容狀態碼構件狀態ComCon數據接口輸入數據接口向構件輸入數據的接口說明見表4。T概括了所有6.5.5中列舉的數據類型，具體使用的數據由構件功能決定，輸入數據接口應支持大數據處理任務。輸入數據接口說明接口定義StringInputData(StringComName,TInData)URLhttp://localhost:8080/InputData請求方式POST參數構件名稱ComName輸入數據InData返回內容狀態碼外部數據調用從指定數據源（如公共數據庫、云服務、第三方API等）獲取數據的接口說明見表5。外部數據調用接口說明接口定義StringGetEnternalData(StringComName,StringSource,StringOPName)URLhttp://localhost:8080/GetEnternalData請求方式POST參數構件名稱ComName數據源標識Source查詢參數OPName返回內容狀態碼輸出數據接口從構件輸出數據的接口說明見表6。輸出數據接口說明接口定義TOutputData(StringComName)URLhttp://localhost:8080/OutputData請求方式GET參數構件名稱ComName返回內容狀態碼輸出數據OutData控制接口修改參數接口上傳和修改構件運行參數的接口說明見表7。修改參數接口說明接口定義StringChangeOP(StringComName,StringOPName,TOPNum)URLhttp://localhost:8080/ChangeOP請求方式POST參數構件名稱ComName參數名稱OPName參數值OPNum返回內容狀態碼運行控制接口控制構件的運行，如啟動和停止操作，接口說明見表8。運行控制接口說明接口定義StringControlRun(StringComName)URLhttp://localhost:8080/ControlRun請求方式POST參數構件名稱ComName返回內容狀態碼第三方工具接口依賴連接接口連接其他構件或第三方應用工具，如深度學習模型等，接口說明見表9。依賴連接接口說明接口定義StringConnectTool(StringComName,StringToolName)URLhttp://localhost:8080/ConnectTool請求方式POST參數構件名稱ComName第三方工具名稱ToolName返回內容狀態碼實時數據分析工具集成接口與實時數據分析工具（如Storm、Flink等）進行集成，支持實時數據分析和處理，接口說明見表10。實時數據分析工具集成接口說明接口定義StringRealTimeTool(StringComName,StringToolConfig)URLhttp://localhost:8080/RealTimeTool請求方式GET參數構件名稱ComName工具連接配置ToolConfig返回內容狀態碼數據分析結果AnalysisData信息與健康檢測工具集成接口在構件自動化部署時，使用LivenessProbe和ReadinessProbe進行容器健康信息檢測；在模型運行時反饋模型細節，控制參數等，接口說明見表11。信息與健康檢測工具集成接口說明接口定義StringHealthTool(StringComName,StringToolConfig)URLhttp://localhost:8080/HealthTool請求方式GET參數構件名稱ComName工具連接配置ToolConfig返回內容狀態碼構件運行信息RunInfo構件封裝概述本文件按照技術實現的邏輯順序和構件間的調用關系，將構件封裝劃分為鏡像封裝和Charts封裝兩個步驟，如圖6所示。應用構件封裝總體設計容器化封裝容器化封裝過程如下：收集構件與構件接口信息，對配置信息進行標準化整合，判斷配置信息的正確性，如果不正確，則向構件開發者反饋錯誤信息以供修改；如果正確，則通過構件信息進行yaml文件的自動化編寫。根據yaml文件進行模型鏡像自動化封裝。yaml文件的關鍵配置信息示例見附錄A。Chart文件目錄Chart代碼文件目錄包括：templates/，模板文件，存放Kubernetes資源文件，如Deployment、Service、Ingress、ConfigMap、Secrets等；values.yaml，定義Chart的默認配置值；Chart.yaml，核心配置文件，定義Chart的基本信息（如名稱、版本、描述等）以及依賴關系，包含name、version、description、icon、sources、maintainers、dependencies等字段；README.md，介紹文檔。values.yaml文件的關鍵配置信息示例見附錄B。Chart封裝應用構件的Chart封裝過程如下：獲取容器化封裝后容器服務的端口、健康檢測接口等關鍵信息；編寫資源定義文件，使用YAML格式編寫資源定義文件，并放置在templates/目錄下；創建Chart.yaml文件，在Chart的根目錄下創建Chart.yaml文件，并填寫Chart的基本信息，如名稱、版本、描述和依賴等；創建values.yaml文件，在Chart的根目錄下創建values.yaml文件，并定義Chart的配置參數；編寫README.md文件，根據需要，編寫README.md文件，描述Chart的使用方法和注意事項；打包Chart，將Chart打包成.tgz格式的文件，完成Chart封裝。構件測試概述構件測試是對構件性能進行評估和對構件功能進行驗證的方法，本文件的構件測試在Kubernetes集群中完成，主要包括UAT測試、功能測試和性能測試。UAT測試構件開發完成后，由相關的用戶或獨立測試人員根據測試計劃和結果對構件進行測試和接收。這一階段的測試旨在驗證構件是否滿足業務需求、功能要求以及用戶期望，確保軟件在實際應用中的穩定性和可靠性，UAT測試主要包括：驗證功能完整性，確保所有規定的功能按預期工作，無遺漏或錯誤；確認用戶滿意度，用戶對構件的使用體驗感到滿意，界面友好，操作便捷；發現并修復缺陷，在發布前識別并解決潛在的問題，確保構件質量；業務流程驗證，確認構件支持的實際業務流程無誤，符合業務需求。功能測試功能測試用于驗證構件在實際業務場景中的表現，根據開發者提交的測試用例模擬用戶請求并驗證構件響應的正確性，功能測試主要包括：邊界值測試，測試構件在極限情況下的響應和表現，即測試邊界值處的構件行為是否符合規范；等價類劃分測試，將各種輸入值看做是幾個等價類，選取一個代表性的值進行測試；冒煙測試，運行構件的核心功能，檢查構件是否能夠啟動、執行基本操作和完成基本任務等；面向場景測試，定義不同的測試場景來驗證構件的功能和行為。性能測試性能測試用于評估構件在各種負載條件下的響應時間、吞吐量、資源利用率等性能表現，測試方式包括：負載測試，通過不斷增加并發用戶數或交易量，觀察構件的響應時間、吞吐量等性能指標的變化情況，以評估構件在特定負載下的性能表現；壓力測試，通過模擬極端負載條件，測試構件在資源飽和或過載情況下的性能表現，以評估穩定性和容錯能力；并發測試，模擬多用戶同時部署構件的場景，測試系統在并發訪問下的性能表現，以發現潛在的并發問題，如死鎖、資源爭用等；基準測試，在特定軟硬件和網絡環境下，模擬一定數量的虛擬用戶運行一種或多種業務，將測試結果作為基準線數據，用于后續的性能調優或系統評測；穩定性測試，在特定負載條件下，長時間運行構件，觀察其性能指標的穩定情況，以評估系統的長期運行穩定性。測試工具構件測試在Kubernetes集群環境中完成，為了實現構件的自動測試，可以使用以下工具：KUTTL；Kubemark；Clusterloader2；Popeye；Kubescape；Mirrord；Kube-linter；Prometheus+Grafana；Sysdig。構件發布發布流程構件通過測試后使用HTTP/HTTPS通信協議將封裝后的構件文件傳輸到構件庫，完成構件的發布，發布過程如下：系統前端收集開發好的應用構件信息，向后端發送發布請求；系統后端完成模型鏡像的打包，封裝為Image和Charts格式；使用HTTP/HTTPS通信協議將封裝好的構件上傳到構件庫中；構件發布完成，向開發者返回發布結果，用戶可以在構件庫中查看發布的構件。在構件發布的過程中需要完成開發者的身份驗證，只有注冊的開發者才能夠進行構件的發布。版本控制構件的版本控制是確保構件穩定性和可追溯性的重要手段。版本控制過程如下：版本號的定義，版本號格式為“主版本號.修訂號”，其中，主版本號當添加構件新功能時遞增，修訂號當進行向下兼容的問題修復時遞增；版本發布，詳細記錄本次版本更新的內容、修復的問