4目??次前??言 II引??言 I范圍 1規范性引用文件 1術語和定義 1符號和縮略語 2物聯網語法互操作性的原則 2通則 2物聯網語法互操作性原則 2語法互操作性相關技術 3總體結構 3元模型驅動的信息交換方法 4信息交換規則 5物聯網（IoT）設備相關信息的要求 7通則 7轉換規則的通用要求 7操作規則的一般要求 9物聯網語法互操作性框架 197.1通則 20操作規則數據集（DOR）的概念模型 20語法互操作性框架的詳細程序 21附錄A（資料性）物聯網設備和數據的屬性 23物聯網設備的內在屬性 23物聯網設備的外在屬性 25附錄B（資料性）一個用例 27概述 27用例概述：智慧城市中的網聯車輛 27此用例的一個場景 27此用例中使用的示例 29附錄C（資料性）其他元模型定義 31參考文獻 32I——第1部分：框架。目的在于指導物聯網系統及其內部各實體之間交互的框架設計。——第2部分：網絡連通性。目的在于指導物聯網系統內部網絡之間和物聯網系統不同網絡之間的互操作及互聯互通。——第3部分：語義互操作性。目的在于規定實現物聯網系統中數據語義的互操作性要求。——第4部分：語法互操作。目的在于規定實現物聯網系統中數據語法的互操作性要求。——第5部分：行為互操作性。目的在于指導物聯網互操作系統中實體的行為規范。III物聯網系統互操作性第4部分：語法互操作范圍本文件從語法的角度規定了物聯網的互操作性。本文件的物聯網語法互操作性包含以下規范：——物聯網系統間語法互操作的原則，——與語法互操作相關的物聯網設備信息要求，——從語法角度制定物聯網設備間信息交換規則的流程框架。規范性引用文件下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。ISO/IEC20924物聯網詞匯(InternetofThings(IoT)—Vocabulary)術語和定義ISO/IEC20924界定的以及下列術語和定義適用于本文件。3.1實例instance具備自身數值及可能特征的單個實體。[來源：ISO19103:2015，4.20]3.2元模型metamodel一種規定建模語言抽象句法的特殊類型模型。注1：模型是元模型的實例（3.1）；注2：物聯網語法互操作性由使用元模型語法的結構、數據格式和約束的信息交換規則實現。[來源：ISO/IEC19506:2012，有修改-刪除了定義后的描述，增加了注解]3.3模型model對現實某些方面的抽象。[來源:ISO19109:2015，4.15]3.41GB/T41782.4—XXXX/ISO/IEC21823-4:2022屬性property對象類型的特定特性。[來源:ISO16484-5:2017，3.2.74]3.5語法互操作性syntacticinteroperability參與通信的系統能夠理解所交換信息格式的互操作性。注1：系統指物聯網系統。注2：物聯網設備、物聯網網關、傳感器和執行器被認為是系統。[來源:ISO/IEC19941:2017，3.1.4，有修改]符號和縮略語下列縮略語適用于本文件。——CRS坐標參考系（CoordinateReferenceSystem）——EPIoT（extrinsicpropertiesofphysicalIoTdevices）——IPIoT（intrinsicpropertiesofphysicalIoTdevices）——IoT物聯網（InternetofThings）——JSONJava腳本對象表示法（JavaScriptObjectNotation）——MOF元對象設施（MetaObjectFacility）——UML統一建模語言（UnifiedModellingLanguage）——XML可擴展置標語言（extensiblemarkuplanguage）物聯網語法互操作性的原則通則ISOIEC2123系列中，ISOIEC2183-1[91)網互操作性應包含五個方面：傳輸、語義、語法、行為和策略。每個標準應從其相應的角度提供規范說明。每個標準都能夠引用或獨立于其他的標準。ISO/IEC21823-2[10]從網絡連通性的角度定義了規范。ISO/IEC21823-3[11]從語義方面定義了要求，提供了指南。本文件從語法角度提供互操作性規范。物聯網語法互操作性原則在本條中，規定了實現物聯網語法互操作性的原則。為了實現一個物聯網系統與另一個物聯網系統或物聯網設備間的語法互操作性，需要使用兩者數據間的信息交換規則。語法互操作性的信息交換規則規定了以下類型的信息交換。格式交換。——“格式”指數據格式。——“格式交換”指在能交換不同數據格式的信息。例如，UML格式的數據能與XML格式的數據進行交換。結構交換。1)方括號中的數字代表參考文獻序號2——“結構”指具有層次和分支的數據結構。——“結構交換”指在能夠交換不同結構的信息。例如，能將分層樹結構的信息轉換為扁平樹結構的信息。語法約束交換。——“約束”指與數據語法或語法要求相關的限制條件。——“語法約束交換”指在能交換具有不同約束條件的信息。例如，物聯網系統1中的數值在小數點后保留一位，物聯網系統2中的數值在小數點后保留兩位。兩者的數值精度交換即為語法約束交換。此外，物聯網系統中的信息是用模型來表示的。在每個物聯網系統中，其信息都能用元模型、模型和實例表示。系統采用元模型和模型中的相關語法來描述語法互操作性中物聯網系統間的信息交換規則。此外，本文件還包含物聯網領域中元模型、模型和信息交換的具體要求。語法互操作性相關技術元模型和語法互操作性作為模型的模型，元模型由模型的一系列說明組成。特別是在UML[22]中，元模型規定了UML的抽象語法。該抽象語法定義了一組UML建模概念、屬性、關系以及通過組合概念來構建部分UML模型的規則。ISO/IEC/IEEE標準中還有其它元模型定義。其中一些列在附錄CC.1中。在表C.124765:2017[13]收集了不同來源的幾個元模型定義。本文件采用表C.1中元模型定義7，即“規定建模語言抽象語法的特殊模型”。從這個定義中可以看出，使用元模型中的要素創建信息交換規則的方法實際上是基于語法的，因此可以用于解決語法互操作性問題。UML、OWL（本體語言）、OntoML（本體標記語言）[1]、XML等都是在不同系統和領域中采用的建模語言。支持互操作性的元模型驅動方法基于元模型驅動的信息交換和互操作性方法是在信息集成和互操作領域實現模型驅動工程方法的一般方式[23][24]。通過創建聲明性映射規范，即交換規則，能在在線和離線的異構系統和設備之間執行自動信息交換。由于元模型驅動方法是在比模型更高的抽象級別上解決互操作性問題，它能夠提高實現符合相同元模型的異構系統和設備間互操作性的效率。即，信息交換規則能被信息模型符合相同元模型的物聯網系統和物聯網設備復用。總體結構圖1說明了所提方法的總體結構。圖1顯示了兩個物聯網系統：物聯網系統1和物聯網系統2。在每個物聯網系統中，其信息包括元模型、模型和實例數據。為了實現這兩個系統之間的語法互操作性，需要創建基于兩個物聯網系統元模型的信息交換規則。創建信息交換規則需要分析和定義支持執行信息交換所需的屬性和處理方法。在圖1中：——以“#”開頭的行表示注釋行；——在“信息交換規則示例”文本框中，列出了語法互操作性的示例信息；——在“所需屬性和處理方法”文本框中，列出了失配的示例屬性和解決失配問題的方法。本文件中，主要的三章描述如何實現物聯網語法互操作性。第5章解釋了元模型的相關技術及其在解決語法互操作性問題方面的適用性。并指定了在異構物聯網系統和設備之間創建信息交換規則的方法。信息交換規則一般分為兩類：3指定元模型所含元素的相互轉換規則。詳見5.6。指定物聯網系統元模型失配時的操作規則。詳見6.3。第6章規定了對物聯網設備相關信息的要求，包括：轉換規則(見6.2)所需的與物聯網設備相關的屬性，例如，物聯網系統或物聯網設備的標識符。為解決失配問題，實施操作規則所需的屬性和處理方法。物聯網系統間的信息交換可能產生失配，處理方法是為了處理失配問題。例如，如果請求信息交換的時間間隔不同,即進行互操作的物聯網系統不匹配，那么就需要語法處理方法來處理這種失配問題。在6.3中分析和描述了處理失配問題所需的屬性和處理方法。第7章描述了如何創建信息交換規則的框架。定義了按照所提出的方法實現物聯網語法互操作性的必要程序，還描述了是否應該創建或擴展物聯網系統的元模型，定義哪些類型的信息交換規則，以及如何能執行和評估交換規則。圖1總體結構元模型驅動的信息交換方法在過去的幾十年中，在基于模型的工程(MBE)領域，構建的模型可以用來表示現實世界中的信息。OMG(對象管理組織)社區提出了用于描述模型的四層建模架構MOF（ISO/IEC19502[6]）。MOF中的模型通常包括M0層的實例、M1層的模型，M2層的元模型和M3層的元元模型。因為本文件不包含M3層，因此圖2將其省略。如圖2所示，M1層中的模型定義了M0層中實例的結構、可用實體、關系等，M2層中的元模型指定了模型的語法。因此，M1層中的模型是其M2層中元模型的實例，即M1層到M2層為“抽象”過程（M1屬于M2的實例,用<<instanceOf>>表示）。同樣的關系存在于M0層和M1層之間。每個元模型可能有很多模型，4每個模型可能有很多實例。圖2中，物聯網系統1中的模型1為實例1的模型，元模型1為模型1的元模型。物聯網系統2中的模型2和元模型2具有相同的關系。從語法的角度來看，信息交換規則作為一種映射，允許在建模環境中將一個特定系統所有層中的信息轉換為另一個系統中的信息。基于M2層中元模型的信息交換規則適用于M1層中模型[6][25]的轉換，因為M1層中的信息是用M2層中的元素定義的。同樣的關系也適用于M1層和M0層。因此，基于元模型的信息交換規則適用于其模型和實例。圖2層次結構及元模型驅動的信息交換規則信息交換規則信息交換規則的分類如5.2和5.5所述，對于包含物聯網設備的物聯網系統（物聯網系統1），為了實現與其他物聯網系統和設備（物聯網系統2）的語法互操作性，需要采用特定的信息交換規則。圖3表明信息交換規則可以分為兩類。——轉換規則。轉換規則是使用物聯網系統1和物聯網系統2元模型中的元素創建的。元模型中的元素有類、屬性、關系等。這些元素之間的轉換規則被定義并命名為“轉換規則”，以實現物聯網系統之間的結構、數據格式和語法約束轉換。轉換規則所需的屬性在6.2中說明。——操作規則。操作規則用來解決兩個物聯網系統之間的失配問題。它可以檢測在實現互操作性的過程中發生的潛在操作失配問題。為了解決這些失配問題，其指定了必要的屬性和處理方法。從語法角度不能解決的失配問題和不基于語法的失配問題解決方法不屬于本文件討論范圍。“操作規則”的詳細內容在6.3中說明。5注：重疊的區域（淺灰色部分）包含同時在轉換規則和操作規則中使用的屬性。圖3信息交換規則分類信息交換規則表示方法信息交換規則應包括元模型之間的轉換規則以及物聯網語法互操作的操作規則。信息交換規則能用多種語言來表示。一些廣為人知的語言，例如QVT(查詢/視圖/轉換)[20]，OCL(對象約束語言)[21]，ATL(Atlas轉換語言)[17]，TGG(三重圖語法)[26][27]等能用于描述不同元模型之間和模型之間的信息交換規則。本文件沒有為信息交換規則提供新的語言，附錄B描述了示例信息的交換規則。本文件的實現能使用選定的語言和數據格式定義信息交換規則。信息交換規則表示實例圖4附錄B中的信息交換規則圖4列出了附錄B中用ATL語言描述的信息交換規則。在圖4中：6——物聯網系統1是聯網車輛，物聯網系統2是一個采用FIWARE表示的交通管理系統(TMS)。這兩個系統的元模型分別在第（2）行中定義為IN:ProbeVehicle和OUT:Fiware。——第（4）到（12）行說明了車輛“名稱”和“標識符”對TMS“名稱”的轉換規則，轉換規則使用元模型的屬性分別在[18]和[19]中定義。——第(15)和(16)行指出單位失配時，操作規則的實現方法。在這里，當檢測到單位失配時，人工規定不同單位之間的轉換。如6.3中所述，該轉換方法的具體實現不在本文件范圍內。此示例僅供參考。物聯網（IoT）設備相關信息的要求通則第6章描述物聯網語法互操作性所需信息的要求。該信息應在物聯網系統或物聯網設備的元模型或模型中定義。該要求適用于物聯網設備，用于物聯網系統之間的數據交換，不包括基于云計算的后端服務。圖5物聯網設備相關信息要求分類與5.6.1中描述的兩類信息交換規則相一致，對物聯網設備相關信息的要求也分為兩類：轉換規則的要求和操作規則的要求，如圖5所示。——根據所需的屬性，轉換規則對屬性的要求進一步分為兩種。一種是“實體物聯網設備所需的內在屬性”，另一種是“實體物聯網設備所需的外在屬性”[28][29]，它們分別在6.2.2和6.2.3中規定。內在屬性被定義為存在于自身或主體內部的特定主體的屬性，而外在屬性是指主體非本質或非固有的屬性[29]。——“操作規則”所需的屬性和處理方法在6.3中指定。轉換規則的通用要求通則轉換規則由物聯網系統元模型中的元素規范。一個物聯網系統包含物聯網設備，物聯網設備的信息用屬性表示。在6.2中，指定了與物聯網設備的語法互操作性相關的所需屬性。——本文件中沒有為物聯網語法互操作性指定新的標識結構和新的數據建模方法。7——如果已有的ID標準和數據模型已經應用在物聯網系統并實現了語法互操作性，則應在物聯網系統中使用這些已有的ID標準和數據模型。——對于每個屬性，無須特定的屬性定義、格式或分類。但如果對其定義、格式等有標準，并且這些標準應用于物聯網系統中，則應使用符合這些標準的屬性來實現物聯網語法互操作性。注：以上說明是為了避免誤解。實體物聯網設備所需的內在屬性(IPIoT)為了支持物聯網語法互操作性，物聯網系統應提供實體物聯網設備的內在屬性。附錄A.1列出了可用的參考性信息內在屬性。表1解釋了物聯網用例中使用的一些典型屬性。表1 實體物聯網設備所需的內在屬性屬性名稱描述必選/可選ID基于給定標準化對象識別系統的物聯網設備標識符必選名稱物聯網設備名稱a可選設備類型物聯網設備的類型b。它應是傳感器、執行器、集成物聯網設備和任何用戶定義的設備類型。必選位置唯一可識別的物理點或區域c,d可選設備所有者對所使用的產品具有合法所有權的個人或組織e[來源：ISO/TR20183:2015,2.21]可選維修記錄設備維修歷史記錄可選a例如，可能使用UID、IRDI、可識別的字符串名稱，例如“DevicID.temperature”b此屬性值可為空c位置可用坐標來表征。[來源：ISO29404:2015,3.11]d對于移動物聯網設備，可使用GPS等定位系統獲取的當前坐標作為位置；對于固定物聯網設備，可利用其部署位置e所有者也可以是操作者實體物聯網設備所需的外在屬性(EPIoT)表2 實體物聯網設備所需的外在屬性實體名稱描述必選/可選數據ID基于給定標準或用戶定義的數據參考系統中一段數據的標識符。必選設備ID采集數據的設備IDa必選值數據值[來源：ISO/IEC20944-1:2013,]必選時間戳表示數據生成時間的屬性或字段[來源：ISO/TS27790:2009,3.73]必選準確性測試結果或測量結果與真實值的接近程度[來源：ISO3534-2:2006，3.3.1]可選訪問權限對設備數據的訪問授權，例如禁止、可讀、可寫、可執行b可選a應使用表1中的“ID”b設備數據是指設備在運行時產生的數據8為了支持物聯網語法互操作性，物聯網系統應提供實體物聯網設備的外在屬性。外在屬性應在物聯網設備或物聯網系統的元模型/模型中定義。可用的相關參考性外在屬性列在附錄A.2中。表2解釋了物聯網用例中使用的一些典型屬性。操作規則的一般要求物聯網系統失配概述操作規則所需的屬性和處理方法與一個物聯網系統期望的內容和另一個物聯網系統能提供的內容之間的失配有關。失配是這兩個物聯網系統之間在數據的指定屬性方面的差異。為了實現語法互操作性，需要通過比較兩個物聯網系統所需的屬性來檢測物聯網系統之間的失配。操作規則用于解決失配問題。這些所需的屬性和處理方法被定義為操作規則的必要條件。圖6顯示了失配檢測和解決失配問題的總體過程。首先，通過比較所需的屬性來檢測失配。如果在元模型中定義了屬性，元模型就會創建轉換規則來解決格式和結構上的差異。創建轉換規則后，創建操作規則。如果未在元模型中定義屬性，則擴展元模型以包含該屬性，或者直接創建操作規則。圖6失配檢測與解決流程圖7顯示了物聯網失配及其解決方法的示例。“物聯網系統2”需要3個有效位的溫度數據，“物聯網系統15個有效位的溫度數據。這種失配的必要屬性是“significantFigure在圖7的例子中，首先，通過比較“significantFigure”屬性來檢測失配；然后，通過轉換規則解決格式和結構上的差異。例如，物聯網系統1的significantFigure屬性被轉換為JSON格式:“significantFigure”：{“type”：“int”，“value”：5}。然后，操作規則通過比較物聯網系統1的“significantFigure”屬性值(即5)和物聯網系統2的“significantFigure”屬性值(即3)來檢測失配。如果為“significantFigure失配”準備的“語法處理方法”是“截斷”，則用戶能夠通過執9行“截斷”功能，建立物聯網系統1和物聯網系統2之間的互操作性。最后，溫度值“24.475”在本例中被截斷為“24.5”。這些類型的失配可以通過操作規則來解決。然而，對于每種失配，可從不同的角度（如語法、語義、策略等）進行處理。本文件只指定了語法處理方法，而來自物聯網互操作性其他方面的處理方法不在本文件的考慮范圍內。圖7失配檢測與處理方法示例潛在物聯網失配所需的屬性和語法處理方法描述了潛在物聯網失配所需的屬性和語法處理方法。表3列出了物聯網系統間潛在失配要求的最少屬性和處理方法：——指定了每個失配所需的屬性和語法處理方法。——語法處理方法的分類（F：格式，S：結構，C：語法約束）由表3的“類型”列指定。——作為參考，表3的“非語法處理方法”列中解釋了示例的非語法處理方法，說明除了語法處理方法之外還可存在其他處理方法。表3 潛在物聯網失配所需的屬性和解決方法名稱標題類型a所需屬性語法處理方法非語法處理方法受影響的數據質量(ISO/IEC25012)示例失配1同步失配F/S/ClatestSynchronizedTime“同步”或“失配通知”見6.3.3中的各表符合性不同的時間戳失配2采樣頻率失配F/SsamplingFrequency“重采樣”或“插值”準確性每小時vs每分鐘失配3位置失配F/Slocation“補償位置差異”或“失配通知”準確性中心室溫vs墻壁室溫失配4數據記錄模式失配F/SdataRecordingPattern“補償記錄模式”或“失配通知”可訪問性周期性vs變化驅動10表3 潛在物聯網失配所需的屬性和解決方法(續)失配5精度失配F/S/Cprecision“截斷”或“失配通知”見6.3.3中的各表精度±0.2℃vs±1.0℃失配6有效數字失配F/S/CsignificantFigure“舍入”或“截斷”或“失配通知”精度2位數vs5位數失配7范圍失配F/SoperatingRange“范圍檢查”或“失配通知”"確實性±50.0℃vs±30.0℃失配8校準失配F/S/CcalibrationTime“重新校準”或“補償校準差異”確實性不同的時間戳失配9響應時間失配F/SresponseTime“響應時間補償”或“失配通知”校準20毫秒vs40毫秒失配10采集狀態失配F/SacquisitionStatus“狀態通知”確實性失敗vs成功失配11單位失配F/Sunit“單位換算”精度攝氏度vs華氏度aF：格式，S：結構，C：語法約束作為參考，本條描述了ISO/IEC25012[14]中定義的可能受失配影響的數據質量指標。為避免物聯網系統之間交換信息時數據質量下降，應考慮彌補失配的處理方法。潛在物聯網失配所需屬性和語法處理方法的詳細信息本條對表3中列出的每一種失配進行詳細說明。對于6.3.3中的所有表，“所需屬性”行通過XML格式的偽模式定義屬性。"<name>"標簽表示所需的屬性名稱。“<datatype>”標簽依據IEC61360-1:2017[16]進行描述。XML中的其他標簽用于提供屬性的附加信息。“失配檢測”和“語法處理方法”行中的“函數簽名”指定了方法名稱、參數和要求。——失配1：同步失配，見表4。表4 失配1：同步失配失配1：同步失配名稱失配1標題同步失配描述“同步失配”是物聯網系統之間的時鐘不同步。例如，如果物聯網系統1中定義的“最新同步時間”為“2004-04-01T12:00Z”，而物聯網系統2中定義的“最新同步時間”為“2004-01-01T11:00Z”，則存在失配。所需屬性<property><id>MS1</id><name>latestSynchronizedTime</name><datatype>DATE_TIME_TYPE</datatype><description>“latestSynchronizedTime”以ISO8601（RFC3339）的格式記錄最新的同步時間，即應使用“UTC”的時間格式</description><resource>ISO/IEC22417</resource></property>11表4失配1：同步失配（續）失配檢測函數簽名：失配檢測（物聯網系統1.latestSynchronizedTime,物聯網系統2.latestSynchronizedTime）要求：當兩個物聯網系統中定義的“latestSynchronizedTime”屬性不匹配時，應檢測到同步失配。語法處理方法函數簽名：語法處理方法（物聯網系統1.latestSynchronizedTime,物聯網系統2.latestSynchronizedTime）要求：語法處理方法應實現“同步”或“失配通知”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可以實現基于硬件或軟件的時間同步處理方法[30]。——失配2：采樣頻率失配，見表5。表5 失配2：采樣頻率失配失配2：采樣頻率失配名稱失配2標題采樣頻率失配描述“采樣頻率失配”是物聯網系統之間數據采樣頻率的不匹配。例如，如果物聯網系統2每分鐘請求一次數據，而物聯網系統1只能每小時提供一次數據，則存在失配。所需屬性<property><id>MS2</id><name>samplingFrequency</name><datatype>REAL_MEASURE_TYPE</datatype><description>“samplingFrequency”是數據周期性采樣的頻率</description><resource>[https://\h/TR/2017/REC-vocab-ssn-20171019/,\h/iot/qoi,http://www.ontology-of-units-of-/resource/om-2/Unit]</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.samplingFrequency,物聯網系統2.samplingFrequency）要求：當兩個物聯網系統中定義的“samplingFrequency”屬性不匹配時，應檢測到采樣頻率失配。12表5失配2：采樣頻率失配（續）語法處理方法函數簽名：語法處理方法（物聯網系統1.samplingFrequency,物聯網系統2.samplingFrequency）要求：語法處理方法應實現“重采樣”或“插值”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可通過基于策略的數據采集時間協調實現處理方法。——失配3：位置失配，見表6。表6 失配3：位置失配失配3：位置失配名稱失配3標題位置失配描述“位置失配”是物聯網系統之間的位置不匹配。例如，如果物聯網系統1需要表示房間溫度的“室溫”，而物聯網系統2能提供的是在墻壁上測量的“壁溫”，則存在失配。所需屬性<property><id>MS3</id><name>location</name><datatype>STRING_TYPE(geoURI)</datatype><description>“location”是在給定坐標參考系統(CRS)處獲取或期望獲取數據的地理空間信息。CRS應在“geoURI”的數據類型中指定。</description><resource>“geoURI”=\h/rfc/rfc5870</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.location,物聯網系統2.location）要求：當這兩個物聯網系統中定義的“location”屬性不匹配時，應檢測到位置失配。語法處理方法函數簽名：語法處理方法（物聯網系統1.location,物聯網系統2.location）要求：語法處理方法應實現“補償位置差異”或“失配通知”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可實現基于插值或校正因子的處理方法。13——失配4：數據記錄模式失配，見表7。表7 失配4：數據記錄模式失配失配4：數據記錄模式失配名稱失配4標題數據記錄模式失配描述“數據記錄模式失配”是物聯網系統之間數據采集時間點的不匹配。例如，如果物聯網系統1期望周期性記錄數據，而物聯網系統2只能在確認數據有變化時才記錄數據，則存在失配。所需屬性<property><id>MS4</id><name>dataRecordingPattern</name><datatype>ENUM_CODE_TYPE（“周期性”，“變化驅動”）</datatype><description>“dataRecordingPattern”指定了一種模式，該模式指示信息是按指定的周期性頻率采集還是基于變化驅動的方式采集。</description><resource>https://\h/TR/websub/</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.dataRecordingPattern,物聯網系統2.dataRecordingPattern）要求：當這兩個物聯網系統中定義的“dataRecordingPattern”屬性不匹配時，應檢測到數據記錄模式失配。語法處理方法函數簽名：語法處理方法（物聯網系統1.dataRecordingPattern,物聯網系統2.dataRecordingPattern）要求：語法處理方法應實現“補償記錄模式”或“失配通知”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可實現基于插值或變化點檢測的處理方法。——失配5：精度失配，見表8。表8失配5：精度失配失配5：精度失配名稱失配5標題精度失配描述“精度失配”是物聯網系統之間數據精度的不匹配。例如，如果物聯網系統1要求溫度傳感器的精度為±0.2°C，而物聯網系統2只能提供±1.0°C的精度，則存在失配。14表8失配5：精度失配（續）所需屬性<property><id>MS5</id><name>precision</name><datatype>REAL_MEASURE_TYPE</datatype><description>"precision"是指在特定條件下，由值及其單位表征的物理量的定量對稱或非對稱偏差</description><resource>https://\h/TR/vocab-ssn/</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.precision,物聯網系統2.precision）要求：當兩個物聯網系統中定義的“精度”屬性不匹配時，應檢測到精度失配。語法處理方法函數簽名：語法處理方法（物聯網系統1.precision,物聯網系統2.precision）要求：語法處理方法應實現“截斷”或“失配通知”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可實現基于策略的數據精度協調處理方法。——失配6：有效數字失配，見表9。表9 失配6：有效數字失配失配6：有效數字失配名稱失配6標題有效數字失配描述“有效數字失配”是物聯網系統間數據有效數字位數的不匹配。例如，如果物聯網系統1需要兩個有效數字位的溫度數據，而物聯網系統2能提供五個有效數字位，則存在失配。所需屬性<property><id>MS6</id><name>significantFigure</name><datatype>REAL_TYPE</datatype><description>“significantFigure”用于以近似方式表示與報告的數值結果相關的精度或不確定性</description><resource>https://\h/TR/vocab-ssn/</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.significantFigure，物聯網系統2.significantFigure）要求：當兩個物聯網系統中定義的“有效數字”屬性不匹配時，應檢測到有效數字失配。15表9失配6：有效數字失配（續）語法處理方法函數簽名：語法處理方法（物聯網系統1.significantFigure，物聯網系統2.significantFigure）要求：語法處理方法應實現“舍入”或“截斷”或“失配通知”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可實現基于策略的有效數字協調處理方法。——失配7：范圍失配，見表10。表10 失配7：范圍失配失配7：范圍失配名稱失配7標題范圍失配描述“范圍失配”是物聯網系統之間工作范圍的不匹配。例如，如果物聯網系統1需要±50.0°C的工作范圍，而物聯網系統2只能提供±30.0°C的工作范圍，則存在失配。所需屬性<property><id>MS7</id><name>operatingRange</name><datatype>LEVEL(MIN,MAX)OFREAL_MEASURE_TYPE</datatype><description>“operatingRange”描述了系統工作所需的范圍</description><resource>https://\h/TR/vocab-ssn/</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.operatingRange，物聯網系統2.operatingRange）要求：當這兩個物聯網系統中定義的“工作范圍”屬性不匹配時，應檢測到范圍失配。語法處理方法函數簽名：語法處理方法（物聯網系統1.operatingRange，物聯網系統2.operatingRange）要求：語法處理方法應實現“范圍檢查”或“失配通知”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可實現基于全系統范圍的工作范圍協調。16——失配8：校準失配，見表11。8：校準失配失配8：校準失配名稱失配8標題校準失配描述“校準失配”是給定時間尺度下校準時間的不匹配。例如，如果物聯網系統1需要特定的校準時間，而物聯網系統2只能提供不同的校準時間，則存在失配。所需屬性<property><id>MS8</id><name>calibrationTime</name><datatype>REAL_MEASURE_TYPE</datatype><description>“calibrationTime”描述了系統校準時的時間戳</description><resource>https://\h/TR/vocab-ssn/</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.calibrationTime，物聯網系統2.calibrationTime）要求：當兩個物聯網系統中定義的“calibrationTime”屬性不匹配時，應檢測到校準失配。語法處理方法函數簽名：語法處理方法（物聯網系統1.calibrationTime，物聯網系統2.calibrationTime）要求：語法處理方法應實現“重新校準”或“補償校準差異”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可實現基于全系統策略的調整處理方法。——失配9：響應時間失配，見表12。表12失配9：響應時間失配失配9：響應時間失配名稱失配9標題響應時間失配描述“響應時間失配”是物聯網系統之間響應時間的不匹配。例如，如果物聯網系統1期望響應時間為“20ms”，但物聯網系統2提供“40ms”響應時間，則存在失配。表12失配9：響應時間失配（續）17所需屬性<property><id>MS9</id><name>responseTime</name><datatype>REAL_MEASURE_TYPE</datatype><description>“responseTime”是物聯網設備設置一個數值的時間與其觀察到該數值的時間之差</description><resource>https://\h/TR/vocab-ssn/</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.responseTime，物聯網系統2.responseTime）要求：當兩個物聯網系統中定義的“responseTime”屬性不匹配時，應檢測到響應時間失配。語法處理方法函數簽名：語法處理方法（物聯網系統1.responseTime，物聯網系統2.responseTime）要求：語法處理方法應實現“響應時間補償”或“失配通知”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可實現基于策略的響應時間補償處理方法。——失配10：采集狀態失配，見表13。表13失配10：采集狀態失配失配10：采集狀態失配名稱失配10標題采集狀態失配描述“采集狀態失配”是數據采集狀態之間的不匹配。例如，如果物聯網系統1期望數據采集成功，而物聯網系統2無法采集數據或只能提供錯誤數據，則存在失配。所需屬性<property><id>MS10</id><name>acquisitionStatus</name><datatype>ENUM_CODE_TYPE（“成功”，“失敗”，“錯誤”）</datatype><description>“acquisitionStatus”是對不同物聯網系統之間數據采集中發生的狀態的枚舉，它可能是“成功”或“失敗”或“錯誤”</description><resource>https://\h/TR/vocab-ssn/</resource></property>表13失配10：采集狀態失配（續）18失配檢測函數簽名：失配檢測（物聯網系統1.acquisitionStatus，物聯網系統2.acquisitionStatus）要求：當兩個物聯網系統中定義的“acquisitionStatus”屬性失配時，應檢測到“采集狀態失配”。語法處理方法函數簽名：語法處理方法（物聯網系統1.acquisitionStatus，物聯網系統2.acquisitionStatus）要求：語法處理方法應實現“狀態通知”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可通過轉換或失敗及錯誤代碼通知實現處理方法。——失配11：單位失配，見表14。表14 失配單位失配失配11：單位失配名稱失配11標題單位失配描述“單位失配”是物聯網系統間測量單位的不匹配。例如，如果物聯網系統1期望室溫以“攝氏度”為單位，而物聯網系統2提供的溫度以“華氏度”為單位，則存在失配。所需屬性<property><id>MS11</id><name>unit</name><datatype>CLASS_REFERENCE_TYPE(0112/2///62720)</datatype><description>“unit”是測量單位</description><resource>IEC62720</resource></property>失配檢測函數簽名：失配檢測（物聯網系統1.unit，物聯網系統2.unit）要求：當兩個物聯網系統中定義的“單位”屬性不匹配時，應檢測到“單位失配”。語法處理方法函數簽名：語法處理方法（物聯網系統1.unit，物聯網系統2.unit）要求：語法處理方法應執行“單位轉換”。非語法處理方法非語法處理方法不在本文件的考慮范圍內。例如，可實現全系統范圍的單位協調處理方法[31]。物聯網語法互操作性框架19通則圖8從語法角度制定物聯網設備相關的信息交換規則的流程框架為了實現物聯網系統之間的語法互操作，根據第5章、第6章的描述，應提供如圖8所示的框架。框架的實現不在本文件的范圍內。框架中的過程分為三組。——右上角虛線框中的過程A應該根據6.3的要求準備必要的屬性和處理方法。此過程的輸出是“操作規則數據集”（DatasetofOperationRules，DOR）。——中間虛線框中的過程B應該創建信息交換規則。此過程的輸出是“信息交換規則數據集”(DatasetforInformationExchangeRules，DIER)。DIER由DOR和“轉換規則數據集”(DatasetforTranslationRules，DTR)組成。——最下面虛線框中的過程C應該執行信息交換規則并檢查結果。在圖8中，創建的DOR應被物聯網系統復用以實現語法互操作。如果物聯網系統具有與元模型1或元模型2相同的元模型，則應復用DIER。一旦創建了DOR和DIER，對于可復用DOR和DIER的兩個物聯網系統，可以省略過程A和過程B。操作規則數據集（DOR）的概念模型20圖9操作規則數據集（DOR）概念模型圖9為DOR的概念模型。以下要求適用于圖9中所示的類。——DOR應通過過程A創建，它應包含表3中定義的失配屬性和處理方法、6.2.2中定義的IoT設備內在屬性以及6.2.3中規定的IoT設備所需的外在屬性。——“RequiredPropertyOfMismatch”類應定義失配所需的屬性。——“RequiredSetOfIPIoT”類應定義物聯網設備所需的內在屬性。——“RequiredSetOfEPIoT”類應定義物聯網設備所需的外在屬性。——“RequiredResolutionOfMismatch”類應繼承上述三個類的所有屬性。——“RequiredResolutionOfMismatch”類應包含失配的可能解決方案。6.3.3中的每個失配都定義為一個類，該類應包含失配所需的屬性和語法處理方法。.代表失配的類的名稱與失配名稱相對應。例如，“Class:Synchronizationmismatch”是根據6.3.3中的失配1同步失配latestSynchronizedTime該概念模型中的所有實體都應能根據物聯網系統和物聯網設備不斷發展的需求而靈活地進行修改/更新/刪除/添加。語法互操作性框架的詳細程序A為了能夠根據第6章中的描述來準備DOR，圖10展示了過程A的總體流程圖。在此過程中，應需要以下步驟。步驟A1、步驟A2和步驟A3的順序可改變。——在步驟A1中，應定義物聯網設備的內在屬性IPIoT以實現語法互操作性。——在步驟A2中，應定義物聯網設備的外在屬性EPIoT。——在步驟A3中，應定義IoT失配的屬性和語法處理方法。——在步驟A4中，所有定義的數據都應保存到DOR。DOR應與圖9所示的概念模型一致。21——當DOR有更新時，更新的數據應在步驟A5中定義并保存到更新的DOR。圖10過程A步驟BDIER)過程B的一般流程圖如圖8所示，從步驟B1到步驟B3。通過過程B，能生成兩個物聯網系統之間的信息交換規則。應包含以下步驟。——在步驟B1中，如果物聯網系統1的元模型1和物聯網系統2的元模型2不包含語法互操作要求的必需屬性，則應考慮將必要的屬性適當添加到元模型中。——在步驟B2中，應創建元模型1和元模型1之間的信息交換規則。——在步驟B3中，創建的信息交換規則應保存為DIER，且應被用于執行元模型1和元模型2之間的信息轉換。信息交換規則可以是單向或雙向的。信息交換規則取決于元模型1和元模型2。符合元模型1和元模型2的物聯網系統能復用這些信息交換規則實現其語法互操作性。C過程C的流程圖如圖8中最下面虛線框所示。通過過程C，物聯網系統1中的模型1和數據能被轉換為物聯網系統2中的模型2和數據，反之亦然。在過程C中，應設置以下步驟。——在步驟C1中，物聯網系統1中的數據，即物聯網系統1的元模型1和模型1，以及創建的信息交換規則應作為輸入以執行信息轉換。——通過步驟C1，模型1被轉換為模型1'，模型1'應符合物聯網系統2的元模型2。——在步驟C2中，應檢查模型1'是否符合元模型2。如果模型1'符合元模型2，那么模型1'能被物聯網系統2理解和使用。經由第7章中的過程，物聯網系統1和物聯網系統2之間的語法互操作性能通過基于它們元模型創建的信息交換規則來實現。22附錄A（資料性）物聯網設備和數據的屬性物聯網設備的內在屬性表A.1列出了物聯網設備可能的內在屬性。該列表可能根據物聯網設備和物聯網系統的要求進行演進。表A.1 物聯網設備的內在屬性設備ID名稱必選/可選描述可用的物聯網用例IPIoT_P1ID必選參見表1中的“ID”。ISO/IECTR22417:IoT用例IPIoT_P2Name可選參見表1中的“名稱”。ISO/IECTR22417:IoT用例IPIoT_P3DeviceType必選/可選參見表1中的“設備類型”ISO/IECTR22417:IoT用例IPIoT_P4Location可選參見表1中的“位置”ISO/IECTR22417:IoT用例IPIoT_P5Digitalcommunicationprotocoltype可選在數字通信中使用的協議類型列表a,bISO/IECTR22417:IoT用例IPIoT_P6HeartBeatCurrentStatus可選規定項目運行狀態的限定符[來源:IEC61360-4CDD,61360_4#ADA356-operationalstatequalifier]ISO/IECTR22417:IoT用例IPIoT_P7Event可選從物聯網設備發出的事件ISO/IECTR22417:IoT用例IPIoT_P8SecurityLevelOfDevice可選層級安全分類和代表對象敏感性或個體安全許可的安全類別的組合[來源:ISO/IEC20944-1:2013,4]ISO/IECTR22417:IoT用例IPIoT_P9CommunicationAddress可選永久分配給設備或存儲位置的地址，該地址無需轉換或計算即可識別設備或位置[來源:ISO/IEC/IEEE24765:2017,3.19]ISO/IECTR22417:IoT用例IPIoT_P10Receiver可選接收消息的一方（指設備）[來源:ISO16609:2012,3.20]ISO/IECTR22417:IoT用例23表A.1物聯網設備的內在屬性（續）IPIoT_P11Power可選能量的來源（電池、電源）[來源:ISO14708-53.18]ISO/IECTR22417:IoT用例IPIoT_P12Port可選通過網絡與計算機程序通信的接口[來源:ISO17532:2007,3.29]ISO/IECTR22417:IoT用例IPIoT_P13Sender可選負責且被授權發送消息的一方（設備）[來源:ISO16609:2012,3.21]ISO/IECTR22417:IoT用例IPIoT_P14Description可選物聯網設備的描述ISO/IECTR22417:IoT用例IPIoT_P15DeviceOwner可選參見表1中的“設備所有者”ISO/IECTR22417:IoT用例IPIoT_P17AC|DC可選電源類型：交流或直流ISO/IECTR22417:IoT用例IPIoT_P18Cardinality可選相關設備的基數ISO/IECTR22417:IoT用例IPIoT_P19StateOfDevice可選物聯網設備當前狀態（運行|停止|錯誤等）ISO/IECTR22417:IoT用例IPIoT_P20PrivacyOfDevice可選物聯網設備隱私（隱私信息、級別等）ISO/IECTR22417:IoT用例IPIoT_P21SamplingFrequency可選從物聯網設備采集數據的頻率ISO/IECTR22417:IoT用例IPIoT_P22ContinuousWorkingPeriod可選對象持續運行的時長（月/日/小時等）ISO/IECTR22417:IoT用例IPIoT_P23Size可選制造商定義的設備的相關尺寸特性[來源:ISO10432:2004,3.25]ISO/IECTR22417:IoT用例IPIoT_P24RatedPower可選視在功率的常規值，為變壓器、并聯電抗器或消弧線圈的設計、制造商的保證和測試奠定基礎，確定在規定條件下施加額定電壓時可承載的額定電流值[來源:IEC60050-421:1990,421-04-04]ISO/IECTR22417:IoT用例a能制造支持一種或多種數字通信協議進行通信的產品b在運行過程中，一個產品僅使用一種通信協議24表A.1物聯網設備的內在屬性（續）IPIoT_P25MaintenanceRecord可選參見表1中的“維修記錄”。ISO/IECTR22417:IoT用例IPIoT_P26RoHS可選RoHS合規狀態ISO/IECTR22417:IoT用例IPIoT_P27StartTimestamp|OnTimestamp可選啟動時間戳ISO/IECTR22417:IoT用例IPIoT_P28StopTimestamp|OffTimestamp可選關閉時間戳ISO/IECTR22417:IoT用例IPIoT_P29OnOffCount可選開/關次數ISO/IECTR22417:IoT用例IPIoT_P30Relation可選與相關設備的關系ISO/IECTR22417:IoT用例IPIoT_P31SecurityLevelOfEnvironment可選物聯網設備安裝位置的安全級別ISO/IECTR22417:IoT用例IPIoT_P32BatteryLife可選沒有新能源供應的計時儀器的壽命[來源:ISO6426-2:2002,3.20]W3C語義傳感器網絡本體（W3CSemanticSensorNetworkOntology）IPIoT_P33VersionOfSoftware可選軟件版本標識-IPIoT_P34VersionOfDevice可選設備版本信息（序列號、年份等）-IPIoT_P35CO2可選二氧化碳排放-IPIoT_P36Readable|Writable可選物聯網設備是否可寫或可讀的限制-IPIoT_P37MeasurementRange可選誤差在規定范圍內的被測量的測量值集合[來源:ISO26782:2009,3.11]W3C語義傳感器網絡本體（W3CSemanticSensorNetworkOntology）IPIoT_P38ActuationRange可選執行器數據范圍W3C語義傳感器網絡本體（W3CSemanticSensorNetworkOntology）物聯網設備的外在屬性表A.2中列出了物聯網設備可能的外在屬性。該列表可以根據物聯網設備和物聯網系統的要求不斷演進。表A.2 物聯網設備的外在屬性設備ID名稱必選/可選描述可用的物聯網用例EPIoT_P1DataID必選參見表2中的“數據ID”-EPIoT_P2DeviceID必選參見表2中的“設備ID”ISO/IECTR22417:IoT用例25表A.2物聯網設備的外在屬性（續）EPIoT_P3Timestamp必選參見表2中的“時間戳”ISO/IECTR22417:IoT用例EPIoT_P4DataFormat可選文件或流中的數據格式。[來源:ISO/IEEE11073?10201:2004,3.14]SO/IECTR22417:IoT用例EPIoT_P5DataType可選值域。[來源:ISO10303?11:2004,3.3.5]ISO/IECTR22417:IoT用例EPIoT_P6AccessAuthority可選參見表2中的“訪問權限”ISO/IECTR22417:IoT用例EPIoT_P7Value必選參見表2中的“值”ISO/IECTR22417:IoT用例EPIoT_P8Accuracy可選參見表2中的“準確性”ISO/IECTR22417:IoT用例EPIoT_P9DataDomain可選信息的行業領域ISO/IECTR22417:IoT用例EPIoT_P10DataPrivacy可選設備數據的隱私aISO/IECTR22417:IoT用例EPIoT_P11ProtocolOfData可選信息通訊協議。如果未指定，則與連接時相同ISO/IECTR22417:IoT用例EPIoT_P12Analog|Digital可選從設備采集的數據類型（模擬/數字）ISO/IECTR22417:IoT用例EPIoT_P13SecurityLevelOfData可選數據安全等級ISO/IECTR22417:IoT用例EPIoT_P14MessageFormat可選消息的格式。如未規定，則與數據格式相同ISO/IECTR22417:IoT用例EPIoT_P15Version可選信息的版本ISO/IECTR22417:IoT用例EPIoT_P16DataSize可選數據的大小，如字節或兆字節ISO/IECTR22417:IoT用例EPIoT_P17DataSurvivalPeriod可選信息的有效日期。ISO/IECTR22417:IoT用例EPIoT_P18OwnerOfData可選數據擁有者bISO/IECTR22417:IoT用例EPIoT_P19ValueRange可選值的范圍。一組值的最大值和最小值之間的差值ISO/IECTR22417:IoT用例EPIoT_P20ValidPeriod可選信息的到期日期。如未規定，則沒有到期日期ISO/IECTR22417:IoT用例EPIoT_P21DiscreteData|ContinuousData可選從物聯網設備采集的數據是連續的還是離散的-EPIoT_P22Sensitivity可選用于特定目的的一組相關數據。W3CSemanticSensorNetworkOntologyEPIoT_23Precision試結果之間的接近程度。ISO3534-2:2006,3.3.4]a設備數據是指設備運行時產生的數據b擁有者與IPIoT_P15的描述相同26附錄B（資料性）一個用例概述附錄B中介紹了一個實現物聯網語法互操作性的用例。用例概述：智慧城市中的網聯車輛本用例介紹了如何通過元模型的信息交換規則實現網聯汽車和智慧城市車輛數據模型之間的語法互操作。在本用例中，利用了ISO22837[12]和ISO14817-1:2015[2]中的網聯汽車信息模型和數據要求。采用ISO22837:2009附錄A[12]中定義的信息模型作為網聯汽車探測數據的元模型MM1。本信息模型使用