物联网 系统互操作性 第4部分：语法互操作 征求意见稿

1物联网系统互操作性第4部分：语法互操作本文件从语法的角度规定了物联网的互操作性。本文件的物联网语法互操作性包含以下规范：——物联网系统间语法互操作的原则，——与语法互操作相关的物联网设备信息要求，——从语法角度制定物联网设备间信息交换规则的流程框架。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。ISO/IEC20924物联网词汇(InternetofThings(IoT)—Vocabulary)3术语和定义ISO/IEC20924界定的以及下列术语和定义适用于本文件。3.1实例instance具备自身数值及可能特征的单个实体。[来源：ISO19103:2015，4.20]3.2元模型metamodel一种规定建模语言抽象句法的特殊类型模型。）；[来源：ISO/IEC19506:2012，有修改-删除了定义后的描述，增加了注解]3.3模型model对现实某些方面的抽象。[来源:ISO19109:2015，4.15]3.42GB/T41782.4—XXXX/ISO/IEC21823-4:2022属性property对象类型的特定特性。[来源:ISO16484-5:2017，3.2.74]3.5语法互操作性syntacticinteroperability参与通信的系统能够理解所交换信息格式的互操作性。注2：物联网设备、物联网网关、传感器[来源:ISO/IEC19941:2017，3.1.4，有修改]4符号和缩略语下列缩略语适用于本文件。——CRS坐标参考系（CoordinateReferenceSystem）——EPIoT物联网设备的外在属性（extrinsicpropertiesofphysicalIoTdevices）——IPIoT物联网设备的内在属性（intrinsicpropertiesofphysicalIoTdevices）——IoT物联网（InternetofThings）——JSONJava脚本对象表示法（JavaScriptObjectNotation）——MOF元对象设施（MetaObjectFacility）——UML统一建模语言（UnifiedModellingLanguage）——XML可扩展置标语言（extensiblemarkuplanguage）5物联网语法互操作性的原则5.1通则在ISO/IEC21823系列中，ISO/IEC21823-1[9]定义了物联网互操作性的总体框架。它规定物联 网互操作性应包含五个方面：传输、语义、语法、行为和策略。每个标准应从其相应的角度提供规范说明。每个标准都能够引用或独立于其他的标准。ISO/IEC21823-2[10]从网络连通性的角度定义了规范。ISO/IEC21823-3[11]从语义方面定义了要求，提供了指南。本文件从语法角度提供互操作性规范。5.2物联网语法互操作性原则在本条中，规定了实现物联网语法互操作性的原则。为了实现一个物联网系统与另一个物联网系统或物联网设备间的语法互操作性，需要使用两者数据间的信息交换规则。语法互操作性的信息交换规则规定了以下类型的信息交换。a)格式交换。——“格式”指数据格式。——“格式交换”指在能交换不同数据格式的信息。例如，UML格式的数据能与XML格式的数据进行交换。b)结构交换。3GB/T41782.4—XXXX/ISO/IEC21823-4:2022——“结构”指具有层次和分支的数据结构。——“结构交换”指在能够交换不同结构的信息。例如，能将分层树结构的信息转换为扁平树结构的信息。c)语法约束交换。——“约束”指与数据语法或语法要求相关的限制条件。——“语法约束交换”指在能交换具有不同约束条件的信息。例如，物联网系统1中的数值在小数点后保留一位，物联网系统2中的数值在小数点后保留两位。两者的数值精度交换即为语法约束交换。此外，物联网系统中的信息是用模型来表示的。在每个物联网系统中，其信息都能用元模型、模型和实例表示。系统采用元模型和模型中的相关语法来描述语法互操作性中物联网系统间的信息交换规则。此外，本文件还包含物联网领域中元模型、模型和信息交换的具体要求。5.3语法互操作性相关技术5.3.1元模型和语法互操作性作为模型的模型，元模型由模型的一系列说明组成。特别是在UML[22]中，元模型规定了UML的抽象语法。该抽象语法定义了一组UML建模概念、属性、关系以及通过组合概念来构建部分UML模型的规ISO/IEC/IEEE标准中还有其它元模型定义。其中一些列在附录C的表C.1中。在表C.1中，ISO/IEC/IEEE24765:2017[13]收集了不同来源的几个元模型定义。本文件采用表C.1中元模型定义7，即“规定建模语言抽象语法的特殊模型”。从这个定义中可以看出，使用元模型中的要素创建信息交换规则的方法实际上是基于语法的，因此可以用于解决语法互操作性问题。UML、OWL（本体语言）、OntoML（本体标记语言）[1]、XML等都是在不同系统和领域中采用的建模语言。5.3.2支持互操作性的元模型驱动方法基于元模型驱动的信息交换和互操作性方法是在信息集成和互操作领域实现模型驱动工程方法的一般方式[23][24]。通过创建声明性映射规范，即交换规则，能在在线和离线的异构系统和设备之间执行自动信息交换。由于元模型驱动方法是在比模型更高的抽象级别上解决互操作性问题，它能够提高实现符合相同元模型的异构系统和设备间互操作性的效率。即，信息交换规则能被信息模型符合相同元模型的物联网系统和物联网设备复用。5.4总体结构图1说明了所提方法的总体结构。图1显示了两个物联网系统：物联网系统1和物联网系统2。在每个物联网系统中，其信息包括元模型、模型和实例数据。为了实现这两个系统之间的语法互操作性，需要创建基于两个物联网系统元模型的信息交换规则。创建信息交换规则需要分析和定义支持执行信息交换所需的属性和处理方法。在图1中：——以“#”开头的行表示注释行；——在“信息交换规则示例”文本框中，列出了语法互操作性的示例信息；——在“所需属性和处理方法”文本框中，列出了失配的示例属性和解决失配问题的方法。本文件中，主要的三章描述如何实现物联网语法互操作性。a)第5章解释了元模型的相关技术及其在解决语法互操作性问题方面的适用性。并指定了在异构物联网系统和设备之间创建信息交换规则的方法。信息交换规则一般分为两类：4GB/T41782.4—XXXX/ISO/IEC21823-4:20221)指定元模型所含元素的相互转换规则。详见5.6。2)指定物联网系统元模型失配时的操作规则。详见6.3。b)第6章规定了对物联网设备相关信息的要求，包括：1)转换规则(见6.2)所需的与物联网设备相关的属性，例如，物联网系统或物联网设备的标识符。2)为解决失配问题，实施操作规则所需的属性和处理方法。物联网系统间的信息交换可能产生失配，处理方法是为了处理失配问题。例如，如果请求信息交换的时间间隔不同,即进行互操作的物联网系统不匹配，那么就需要语法处理方法来处理这种失配问题。在6.3中分析和描述了处理失配问题所需的属性和处理方法。c)第7章描述了如何创建信息交换规则的框架。定义了按照所提出的方法实现物联网语法互操作性的必要程序，还描述了是否应该创建或扩展物联网系统的元模型，定义哪些类型的信息交换规则，以及如何能执行和评估交换规则。5.5元模型驱动的信息交换方法在过去的几十年中，在基于模型的工程(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层之间。每个元模型可能有很多模型，5GB/T41782.4—XXXX/ISO/IEC21823-4:2022每个模型可能有很多实例。图2中，物联网系统1中的模型1为实例1的模型，元模型1为模型1的元模型。物联网系统2中的模型2和元模型2具有相同的关系。从语法的角度来看，信息交换规则作为一种映射，允许在建模环境中将一个特定系统所有层中的信息转换为另一个系统中的信息。基于M2层中元模型的信息交换规则适用于M1层中模型[6][25]的转换，因为M1层中的信息是用M2层中的元素定义的。同样的关系也适用于M1层和M0层。因此，基于元模型的信息交换规则适用于其模型和实例。图2层次结构及元模型驱动的信息交换规则5.6信息交换规则5.6.1信息交换规则的分类如5.2和5.5所述，对于包含物联网设备的物联网系统（物联网系统1），为了实现与其他物联网系统和设备（物联网系统2）的语法互操作性，需要采用特定的信息交换规则。图3表明信息交换规则可以分为两类。——转换规则。转换规则是使用物联网系统1和物联网系统2元模型中的元素创建的。元模型中的元素有类、属性、关系等。这些元素之间的转换规则被定义并命名为“转换规则”，以实现物联网系统之间的结构、数据格式和语法约束转换。转换规则所需的属性在6.2中说明。——操作规则。操作规则用来解决两个物联网系统之间的失配问题。它可以检测在实现互操作性的过程中发生的潜在操作失配问题。为了解决这些失配问题，其指定了必要的属性和处理方法。从语法角度不能解决的失配问题和不基于语法的失配问题解决方法不属于本文件讨论范围。“操作规则”的详细内容在6.3中说明。6GB/T41782.4—XXXX/ISO/IEC21823-4:2022注：重叠的区域（浅灰色部分）包含同时在转换规则和图3信息交换规则分类5.6.2信息交换规则表示方法信息交换规则应包括元模型之间的转换规则以及物联网语法互操作的操作规则。信息交换规则能用多种语言来表示。一些广为人知的语言，例如QVT(查询/视图/转换)[20]，OCL(对象约束语言)[21]，ATL(Atlas转换语言)[17]，TGG(三重图语法)[26][27]等能用于描述不同元模型之间和模型之间的信息交换规则。本文件没有为信息交换规则提供新的语言，附录B描述了示例信息的交换规则。本文件的实现能使用选定的语言和数据格式定义信息交换规则。5.6.3信息交换规则表示实例图4附录B中的信息交换规则图4列出了附录B中用ATL语言描述的信息交换规则。在图4中：7GB/T41782.4—XXXX/ISO/IEC21823-4:2022——物联网系统1是联网车辆，物联网系统2是一个采用FIWARE表示的交通管理系统(TMS)。这两个系统的元模型分别在第（2）行中定义为IN:ProbeVehicle和OUT:Fiware。——第（4）到（12）行说明了车辆“名称”和“标识符”对TMS“名称”的转换规则，转换规则使用元模型的属性分别在[18]和[19]中定义。——第(15)和(16)行指出单位失配时，操作规则的实现方法。在这里，当检测到单位失配时，人工规定不同单位之间的转换。如6.3中所述，该转换方法的具体实现不在本文件范围内。此示例仅供参考。6物联网（IoT）设备相关信息的要求6.1通则第6章描述物联网语法互操作性所需信息的要求。该信息应在物联网系统或物联网设备的元模型或模型中定义。该要求适用于物联网设备，用于物联网系统之间的数据交换，不包括基于云计算的后端服务。图5物联网设备相关信息要求分类与5.6.1中描述的两类信息交换规则相一致，对物联网设备相关信息的要求也分为两类：转换规则的要求和操作规则的要求，如图5所示。——根据所需的属性，转换规则对属性的要求进一步分为两种。一种是“实体物联网设备所需的内在属性”，另一种是“实体物联网设备所需的外在属性”[28][29]，它们分别在6.2.2和6.2.3中规定。内在属性被定义为存在于自身或主体内部的特定主体的属性，而外在属性是指主体非本质或非固有的属性[29]。——“操作规则”所需的属性和处理方法在6.3中指定。6.2转换规则的通用要求6.2.1通则转换规则由物联网系统元模型中的元素规范。一个物联网系统包含物联网设备，物联网设备的信息用属性表示。在6.2中，指定了与物联网设备的语法互操作性相关的所需属性。——本文件中没有为物联网语法互操作性指定新的标识结构和新的数据建模方法。8GB/T41782.4—XXXX/ISO/IEC21823-4:2022——如果已有的ID标准和数据模型已经应用在物联网系统并实现了语法互操作性，则应在物联网系统中使用这些已有的ID标准和数据模型。——对于每个属性，无须特定的属性定义、格式或分类。但如果对其定义、格式等有标准，并且这些标准应用于物联网系统中，则应使用符合这些标准的属性来实现物联网语法互操作性。6.2.2实体物联网设备所需的内在属性(IPIoT)为了支持物联网语法互操作性，物联网系统应提供实体物联网设备的内在属性。附录A.1列出了可用的参考性信息内在属性。表1解释了物联网用例中使用的一些典型属性。表1实体物联网设备所需的内在属性唯一可识别的物理点或区域例如，可能使用UID、IRDI、可识别的字符串名称，例如“DevicID.temperature”位置可用坐标来表征。[来源：ISO29404:2015,3.11]对于移动物联网设备，可使用GPS等定位系统获取的当前坐标作为位置；对于固定物联网设备，可利用其部署位置所有者也可以是操作者6.2.3实体物联网设备所需的外在属性(EPIoT)表2实体物联网设备所需的外在属性基于给定标准或用户定义的数据参考系统中值对设备数据的访问授权，例如禁止、可读、可写、可应使用表1中的“ID”设备数据是指设备在运行时产生的数据9GB/T41782.4—XXXX/ISO/IEC21823-4:2022为了支持物联网语法互操作性，物联网系统应提供实体物联网设备的外在属性。外在属性应在物联网设备或物联网系统的元模型/模型中定义。可用的相关参考性外在属性列在附录A.2中。表2解释了物联网用例中使用的一些典型属性。6.3操作规则的一般要求6.3.1物联网系统失配概述操作规则所需的属性和处理方法与一个物联网系统期望的内容和另一个物联网系统能提供的内容之间的失配有关。失配是这两个物联网系统之间在数据的指定属性方面的差异。为了实现语法互操作性，需要通过比较两个物联网系统所需的属性来检测物联网系统之间的失配。操作规则用于解决失配问题。这些所需的属性和处理方法被定义为操作规则的必要条件。图6显示了失配检测和解决失配问题的总体过程。首先，通过比较所需的属性来检测失配。如果在元模型中定义了属性，元模型就会创建转换规则来解决格式和结构上的差异。创建转换规则后，创建操作规则。如果未在元模型中定义属性，则扩展元模型以包含该属性，或者直接创建操作规则。图6失配检测与解决流程图7显示了物联网失配及其解决方法的示例。“物联网系统2”需要3个有效位的温度数据，“物联“significantFigure”用位数来描述数据的精度或不确定性。“物联网系统1”的属性为RDF格式，而“物联网系统2”的属性为JSON格式，因此它们存在格式差异。即它们在结构上也存在差异。在图7的例子中，首先，通过比较“significantFigure”属性来检测失配；然后，通过转换规则解决格式和结构上的差异。例如，物联网系统1的significantFigure属性被转换为JSON格式:“significantFigure”：{“type”：“int”，“value”：5}。然后，操作规则通过比较物联网系统1的“significantFigure”属性值(即5)和物联网系统2的“significantFigure”属性值(即3)来检测失配。如果为“significantFigure失配”准备的“语法处理方法”是“截断”，则用户能够通过执GB/T41782.4—XXXX/ISO/IEC21823-4:2022行“截断”功能，建立物联网系统1和物联网系统2之间的互操作性。最后，温度值“24.475”在本例中被截断为“24.5”。这些类型的失配可以通过操作规则来解决。然而，对于每种失配，可从不同的角度（如语法、语义、策略等）进行处理。本文件只指定了语法处理方法，而来自物联网互操作性其他方面的处理方法不在本文件的考虑范围内。图7失配检测与处理方法示例6.3.2潜在物联网失配所需的属性和语法处理方法6.3.2描述了潜在物联网失配所需的属性和语法处理方法。表3列出了物联网系统间潜在失配要求的最少属性和处理方法：——指定了每个失配所需的属性和语法处理方法。——语法处理方法的分类（F：格式，S：结构，C：语法约束）由表3的“类型”列指定。——作为参考，表3的“非语法处理方法”列中解释了示例的非语法处理方法，说明除了语法处理方法之外还可存在其他处理方法。表3潜在物联网失配所需的属性和解决方法通知”值”“补偿位置差异”或“失配通知”“补偿记录模式”或“失配通知”动GB/T41782.4—XXXX/ISO/IEC21823-4:2022表3潜在物联网失配所需的属性和解决方法(续)知”“舍入”或“截断”或“失配通知”偿校准差异”“失配通知”“状态通知”“单位换算”F：格式，S：结构，C：语法约束作为参考，本条描述了ISO/IEC25012[14]中定义的可能受失配影响的数据质量指标。为避免物联网系统之间交换信息时数据质量下降，应考虑弥补失配的处理方法。6.3.3潜在物联网失配所需属性和语法处理方法的详细信息本条对表3中列出的每一种失配进行详细说明。对于6.3.3中的所有表，“所需属性”行通过XML格式的伪模式定义属性。"<name>"标签表示所需的属性名称。“<datatype>”标签依据IEC61360-1:2017[16]进行描述。XML中的其他标签用于提供属性的附加信息。“失配检测”和“语法处理方法”行中的“函数签名”指定了方法名称、参数和要求。——失配1：同步失配，见表4。表4失配1：同步失配<name>latestSynchronize<datatype>DATE_TIME_TYP<description>“latestSynchro<resource>ISO/IEC22417</resourceGB/T41782.4—XXXX/ISO/IEC21823-4:2022表4失配1：同步失配（续）失配检测（物联网系统1.latestSynchronizedTime,物联网系统2.语法处理方法（物联网系统1.latestSynchronizedTim非语法处理方法不在本文件的考虑范围内。例如，可以实现——失配2：采样频率失配，见表5。表5失配2：采样频率失配例如，如果物联网系统2每分钟请求一次数据，而物联网系统1只<datatype>REAL_MEASURE_TYP<description>“sampli<resource>[https:///TR/2017/R20171019/,/iot/qoi,/resource/om-2/Unit]</resour失配检测（物联网系统1.samplingFreqGB/T41782.4—XXXX/ISO/IEC21823-4:2022表5失配2：采样频率失配（续）语法处理方法（物联网系统1.samplingFrequency,物联网系统2.非语法处理方法不在本文件的考虑范围内。例如，可通过基——失配3：位置失配，见表6。表6失配3：位置失配<datatype>STRING_TYPE(geoURI“geoURI”=https://t失配检测（物联网系统1.location,物联网系统语法处理方法（物联网系统1.location,物联网系统2.loc非语法处理方法不在本文件的考虑范围内。例如，可实现基GB/T41782.4—XXXX/ISO/IEC21823-4:2022——失配4：数据记录模式失配，见表7。表7失配4：数据记录模式失配例如，如果物联网系统1期望周期性记录数据，而物联网系统2只<name>dataRecordingPa<resource>https:///TR/websu失配检测（物联网系统1.dataRecordingPattern,物联网系统2.语法处理方法（物联网系统1.dataRecordingPattern,物联网系统2.非语法处理方法不在本文件的考虑范围内。例如，可实现基——失配5：精度失配，见表8。表8失配5：精度失配GB/T41782.4—XXXX/ISO/IEC21823-4:2022表8失配5：精度失配（续）<datatype>REAL_MEASURE_TYP<description>"precision"是指在特定条件下，由值及<resource>https:///TR/vocab-ssn失配检测（物联网系统1.precision,物联网系语法处理方法（物联网系统1.precision,物联网系统2.p非语法处理方法不在本文件的考虑范围内。例如，可实现基——失配6：有效数字失配，见表9。表9失配6：有效数字失配例如，如果物联网系统1需要两个有效数字位的温度数据，而物联<resource>https:///TR/vocab-ssn失配检测（物联网系统1.significantFiGB/T41782.4—XXXX/ISO/IEC21823-4:2022表9失配6：有效数字失配（续）语法处理方法（物联网系统1.significantFigure，物联网系统2.非语法处理方法不在本文件的考虑范围内。例如，可实现基——失配7：范围失配，见表10。表10失配7：范围失配<description>“opera<resource>https:///TR/vocab-ssn失配检测（物联网系统1.operati语法处理方法（物联网系统1.operatingRan非语法处理方法不在本文件的考虑范围内。例如，可实现基于全系统范围的工作范围GB/T41782.4—XXXX/ISO/IEC21823-4:2022——失配8：校准失配，见表11。表11失配8：校准失配例如，如果物联网系统1需要特定的校准时间，而物联网系统2只<datatype>REAL_MEASURE_TYP<description>“calibra<resource>https:///TR/vocab-ssn失配检测（物联网系统1.calibrati语法处理方法（物联网系统1.calibrationTim非语法处理方法不在本文件的考虑范围内。例如，可实现基——失配9：响应时间失配，见表12。表12失配9：响应时间失配表12失配9：响应时间失配（续）GB/T41782.4—XXXX/ISO/IEC21823-4:2022<datatype>REAL_MEASURE_TYP<resource>https:///TR/vocab-ssn语法处理方法（物联网系统1.response非语法处理方法不在本文件的考虑范围内。例如，可——失配10：采集状态失配，见表13。表13失配10：采集状态失配例如，如果物联网系统1期望数据采集成功，而物联网系统2无法<resource>https:///TR/vocab-ssn表13失配10：采集状态失配（续）GB/T41782.4—XXXX/ISO/IEC21823-4:2022失配检测（物联网系统1.acquisitionSt语法处理方法（物联网系统1.acquisitionStatus，物联网系统2.非语法处理方法不在本文件的考虑范围内。例如，可通过转——失配11：单位失配，见表14。表14失配11：单位失配<datatype>CLASS_REFERENCE_TYPE(011语法处理方法（物联网系统1.unit，物联网系统非语法处理方法不在本文件的考虑范围内。例如，可实现全7物联网语法互操作性框架GB/T41782.4—XXXX/ISO/IEC21823-4:20227.1通则图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。7.2操作规则数据集（DOR）的概念模型GB/T41782.4—XXXX/ISO/IEC21823-4:2022图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”，语法处理方法为“syntacticResolution()”，代表同步失配语法处理方法。其他失配类以相同的方法定义。该概念模型中的所有实体都应能根据物联网系统和物联网设备不断发展的需求而灵活地进行修改/更新/删除/添加。7.3语法互操作性框架的详细程序7.3.1过程A准备需要的属性和处理方法为了能够根据第6章中的描述来准备DOR，图10展示了过程A的总体流程图。在此过程中，应需要以下步骤。步骤A1、步骤A2和步骤A3的顺序可改变。——在步骤A1中，应定义物联网设备的内在属性IPIoT以实现语法互操作性。——在步骤A2中，应定义物联网设备的外在属性EPIoT。——在步骤A3中，应定义IoT失配的属性和语法处理方法。——在步骤A4中，所有定义的数据都应保存到DOR。DOR应与图9所示的概念模型一致。GB/T41782.4—XXXX/ISO/IEC21823-4:2022——当DOR有更新时，更新的数据应在步骤A5中定义并保存到更新的DOR。7.3.2过程B创建信息交换规则(DIER)过程B的一般流程图如图8所示，从步骤B1到步骤B3。通过过程B，能生成两个物联网系统之间的信息交换规则。应包含以下步骤。——在步骤B1中，如果物联网系统1的元模型1和物联网系统2的元模型2不包含语法互操作要求的必需属性，则应考虑将必要的属性适当添加到元模型中。——在步骤B2中，应创建元模型1和元模型1之间的信息交换规则。——在步骤B3中，创建的信息交换规则应保存为DIER，且应被用于执行元模型1和元模型2之间的信息转换。信息交换规则可以是单向或双向的。信息交换规则取决于元模型1和元模型2。符合元模型1和元模型2的物联网系统能复用这些信息交换规则实现其语法互操作性。7.3.3过程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之间的语法互操作性能通过基于它们元模型创建的信息交换规则来实现。GB/T41782.4—XXXX/ISO/IEC21823-4:2022（资料性）物联网设备和数据的属性A.1物联网设备的内在属性表A.1列出了物联网设备可能的内在属性。该列表可能根据物联网设备和物联网系统的要求进行演进。表A.1物联网设备的内在属性参见表1中的“设备类型”参见表1中的“位置”型列表层级安全分类和代表对象敏感性或个体安全许可的安全类别的组合GB/T41782.4—XXXX/ISO/IEC21823-4:2022表A.1物联网设备的内在属性（续）率d在运行过程中，一个产品仅使用一种通信协议GB/T41782.4—XXXX/ISO/IEC21823-4:2022表A.1物联网设备的内在属性（续） --A.2物联网设备的外在属性表A.2中列出了物联网设备可能的外在属性。该列表可以根据物联网设备和物联网系统的要求不断演进。表A.2物联网设备的外在属性参见表2中的“数据ID”-参见表2中的“设备ID”GB/T41782.4—XXXX/ISO/IEC21823-4:2022表A.2物联网设备的外在属性（续）参见表2中的“时间戳”参见表2中的“访问权限”参见表2中的“值”参见表2中的“准确性”节 W3CSemanticSensorNetwGB/T41782.4—XXXX/ISO/IEC21823-4:2022（资料性）一个用例B.1概述附录B中介绍了一个实现物联网语法互操作性的用例。B.2用例概述：智慧城市中的网联车辆本用例介绍了如何通过元模型的信息交换规则实现网联汽车和智慧城市车辆数据模型之间的语法互操作。在本用例中，利用了ISO22837[12]和ISO14817-1:2015[2]中的网联汽车信息模型和数据要求。采用ISO22837:2009附录A[12]中定义的信息模型作为网联汽车探测数据的元模型MM1。本信息模型使用ISO14817-1:2015[2]中标识的UML子集。采用智慧城市FIWARE数据模型[18]中的车辆数据模型[19]作为车辆元模型MM2。本用例的概览如图B.1所示。它描述了如何能够应用基于网联汽车元模型(MM1)和FIWARE中车辆元模型(MM2)的信息交换规则来支持它们的语法互操作性。B.3此用例的一个场景B.3.1此用例的架构GB/T41782.4—XXXX/ISO/IEC21823-4:2022如图B.2所示。根据ISO/IEC30141:2018[15]的图11，可将网联汽车识别为一个物联网设备。它能与FIWARE数据模型中包括车辆及相关定义的子系统共享其探测数据(包括在ISO22837[12]中定义的环境数据等)。在这个用例中，一个子系统——交通管理系统——能用来与联网车辆通信。图B.2智慧城市用例中的网联车辆架构图B.3.2场景：联网汽车与交通管理系统(TMS)之间的数据交换图B.3车辆与交通管理系统之间的信息交换图B.3描述的场景用于说明基于图B.2架构的网联汽车和TMS之间的信息交换。GB/T41782.4—XXXX/ISO/IEC21823-4:2022——汽车包含探测数据，交通管理系统（TMS）包含FIWARE数据模型中的车辆和相关定义。汽车能与TMS通信。——本场景是汽车使用TMS推荐的行驶路径以避免交通拥堵的一个简单用例。——本场景的目的是帮助读者理解如何能够实现基于元模型的信息交换。本场景的具体实现步骤如下。a)汽车向TMS发送其位置和速度等信息。b)然后TMS要求汽车共享其目的地信息。c)汽车向TMS发送其目的地信息，例如目的地(点)、周围障碍物信息（如障碍物的方向、距离d)TMS进一步要求汽车共享其环境信息。e)汽车向TMS发送其环境信息，例如周围温度、降雨强度和光照条件。f)TMS最终向汽车发送推荐的行驶路径。通过以上步骤，汽车的探测数据能与TMS的车辆相关数据进行交换。本场景的元模型、模型和数据包含在B.2的示例中。B.4此用例中使用的示例B.4.1概述在本用例中，MM1及其模型用XML格式进行描述，MM2及其模型用JSON进行描述。本用例的文件将在/21823-4/usecases/上公开提供。B.4.2图解示例文件及其关系图B.4用例示例文件之间的关系GB/T41782.4—XXXX/ISO/IEC21823-4:2022图B.4显示了MM1、模型1及其实例、MM2和模型2及其实例之间的关系。——MM1是联网汽车探测数据的元模型。——模型1是MM1的一个实例。它能用MM1中指定的“纬度”、“经度”和“海拔”来定义位置感知数据。图B.4左侧列出了模型1及其实例的XML格式摘录文件。XML标记，如<latitude>、<degree>和<confidence>来自其元模型。——MM2是FIWARE数据模型中车辆和相关定义的元模型。——模型2是MM2的一个实例。它能用geo:json格式定义其位置，该格式需要根据MM2规范描述为“经度”、“纬度”和“海拔”。图B.4右侧列出了模型2及其实例的JSON格式摘录文件。JSON文件的“键”(例如“位置”)及其值格式必须与其元模型相对应。——摘录的MM1和MM2之间的信息交换规则是用ATL（Atlas转换语言[17]）定义的。信息交换规则可定义为双向规则。——通过规则解释器，模型1及其数据可以转换为模型2及其对应的数据，反之亦然。总之，汽车的探测数据能与TMS的车辆相关数据进行交换。GB/T41782.4—XXXX/ISO/IEC21823-4:2022（资料性）其他元模型定义ISO/IEC/IEEE24765:2017[13]中列出的几个元模型定义如表C.1所示。表C.1各种资源中元模型的定义1ISO/IEC11179-3:2013,Informmetamodelandbasicattributes,3.22ToolInterconnections-Classification3IDEF对象子集的元模型Vm是子集中结构体的视图，它使用这些结构体表示，这样就存在Vm的有效实例，它是Vm本身的描述。ConceptualModellingLanguageSynta4ISO/IEC15474-1:2002Informationtechnology5[ISO/IEC24744:2014SoftwareEngineerinMetamodelfordevelopmentmetho6ISO/IEC15909-2:2011Systemandsoftware7ISO/IEC19506:2012Informationtechnology–ObjectManagementGroupArchitecture-DriGB/T41782.4—XXXX/ISO/IEC21823-4:2022参考文献[1]ISO13584-32Industrialautomationsystemsandintegration–Partslibrary–Part32:Implementationresources:OntoML:Productontologymarkuplanguage[2]ISO14817-1:2015Intelligenttransportsystems–ITScentraldatadictionaries–Part1:RequirementsforITSdatadefinitions[3]ISO16484-5:2017Buildingautomationandcontrolsystems(BACS)–Part5:Datacommunicationprotocol[4]ISO19103:2015Geographicinformation–Conceptualschemalanguage[5]ISO19109:2015Geographicinformation–Rulesforapplicationschema[6]ISO/IEC19502:2005Informationtechnology–MetaObjectFacility(MOF)[7]ISO/IEC19506:2012Informationtechnology–ObjectManagementGroupArchitecture-DrivenModernization(ADM)–KnowledgeDiscoveryMeta-Model(KDM)[8]ISO/IEC19941:2017Informationtechnology–Cloudcomputing–InteroperabilityandPortability[9]ISO/IEC21823-1InternetofThings(IoT)–InteroperabilityforIoTsystems–Part1:Framework[10]ISO/IEC21823-2InternetofThings(IoT)–InteroperabilityforIoTsystems–Part2:Transportinteroperability[11]ISO/IEC21823-3InternetofThings(IoT)–InteroperabilityforIoTsystems–Part3:Semanticinteroperability[12]ISO22837:2009Vehicleprobedataforwideareacommunications[13]ISO/IEC/IEEE24765:2017Systemsandsoftwareengineering–Vocabulary[14]ISO/IEC25012:2008,Softwareengineering–SoftwareproductQualityRequirementsandEvaluation(SQuaRE)–Dataqualitymodel[15]ISO/IEC30141:2018InternetofThings(loT)–ReferenceArchitecture[16]IEC61360-1:2017Standarddataelementtypeswithassociatedclassificationscheme–Part1:Definitions–Principlesandmethods[17]ATL:AtlasTransformationLanguage–SpecificationoftheATLVirtualMachine,/atl/documentation/old/ATL_VMSpecification[v00.01].pdf(accessed2020-07-09)[18]FIWAREdatamodel:/FIWARE/data-models/blob/master/specs/guidelines.md(accessed2020-07-09)[19]FIWAREvehiclemodel:https://FIWARE-datamodels.readthedocs.io/en/latest/Transp-ortation/Vehicle/VehicleModel/doc/spec/index.html(accessed2020-07-09)[20]MetaObjectFacility(MOF)2.0Query/View/Transformation(QVT)SpecificationVersion1.3,/spec/QVT/1.3/PDF,(accessed2021-10-04)[21]ObjectConstraintLanguageVersion2.4,/spec/OCL/2.4/PDF(accessed2021-10-04)[22]OMG®UnifiedModeling