本系列文章描述了一个单一的语义数据模型，以支持IoT与建筑、企业和消费者数据的转换。该模型必须简单且可扩展，以实现跨行业领域的可插拔性和互操作性。对于一个目前从事智能硬件的老码农来说，我觉得这句话有积极的借鉴意义。本节讨论业务和设备本体的交集，以及两者的元素如何提高可扩展性。“好的设计就是好的生意。”–ThomasWatsonJr.发展成为以IOT为中心的业务对于用户而言，物联网的真正价值不在于对智能设备的远程控制，而是这些设备之间的良好协作。任何门传感器都应该能够触发独立于设备制造商的开关，任何HVAC单元都应该能够触发服务呼叫或触发更换空气过滤器的命令。这扩大了智能设备和商业系统之间语义互操作性的需求。它还需要一个新的架构来支持业务流程、设备处理，并消除围绕系统集成中间件构建的定制系统的成本和复杂性。这种新架构必须使IoT的模型和概念与业务应用程序平台的模型和概念保持一致。Gartner预测，到2020年，大多数新的平台即服务(PaaS)应用程序将以物联网为中心。这颠覆了传统方法，因为PaaS平台将用于实施围绕事件驱动架构和物联网数据构建的业务应用程序，而不是传统的主数据。这些以物联网为中心的业务应用程序将反过来转变应用程序设计实践，专注于实时、丰富的上下文决策、事件分析、轻量级工作流以及对网络规模数据的广泛访问。与此同时，“物联网标准”和“商业标准”联盟需要适当调整其数据模型、概念和术语。这些资产必须集中在可扩展语义互操作性的中心点，并分布在应用程序（信息）层以进行数据管理。通用业务本体的跨行业领域需求语义互操作性依赖于指定的本体来解释交换数据的含义（上下文）并将其应用于有价值的目标。这可以跨越多个系统、环境和行业。行业特定的业务本体（如金融中的FIBO）和数据模型（如零售中的ARTSODM）具有重叠的概念，可以形成一个通用的业务本体。这个公共业务本体中的概念应该与上层本体（在第3部分物联网语义互操作性本体）中保持一致，如根对象类，以便所有知识领域中的所有对象在本质上是可互操作的。这些通用的业务本体为促进跨行业的语义互操作性提供了基础。抽象（忽略不必要细节的通用处理模型）和面向对象的分解（将大型系统分解为逐渐变小的类或对象）一次又一次地证明它们在解决分布式系统不一致方面的价值方面很有用。为了使通用业务本体与上层本体的类别正确对齐，需要通过将业务相关数据跟踪到其原始对象类别来抽象和分解通用业务概念，这些对象类别可能是特定于行业的本体或其他知识领域的一部分。例如，为了与上层本体对齐，业务上显示的数据元素不会被认为是独立的“Contact”类的属性。相反，它们可以分解为相关顶级类（例如系统、位置或聚会）的属性。如图25所示，电话号码、街道号码、Internet域和电子邮件地址都是唯一的“地址”属性，它们在路由系统中充当端点并由系统运营商（组织）管理。可以将电话号码定义为可分配给设备的系统属性，而不是为“联系人”类定义“电话号码”属性。设备可以分配给一方，一方可以与另一方建立关系。图25将名片分解成与上层本体对齐在这个例子中，“BobSmith”代表一个实例（对象）person，它是party的一种。“DesignbyDesign”代表一个组织对象，也是Party的一种。Bob被赋予了“系统工程师”的角色，他被巧妙地设计，并且还被分配了一个移动设备，由一个组织分配了一个系统地址，该组织本身被分配了“电话系统操作员”。虽然这种抽象和分解级别可能看起来很复杂，但它实际上简化了语义互操作性并防止碎片化。反过来，它消除了在独立构想的对象类之间进行复杂数据映射的需要。位置顶级“位置”类和层次结构（图26）可以支持封闭的地理位置域（例如，Haystack的地理位置），以及住宅或建筑工地内的空间细分（例如，区域、楼层、套房或房间）。可以将位置分配给资产。“站点”类（类似于Haystack的位置实体）可以包含支持邮政地址（可以出现在名片上）的独特属性。站点可以分配给一方和交易（订单、装运）。图27所示的位置示例显示“会议室”包含城市内场所内“四”层的“会议室”，等等。Location类的“空气温度”属性可以调整分配给Location实例（四楼）的温度传感器的值（77.4华氏度）。邮政地址的位置实例可以反映邮政系统运营商组织(USPS)的所有权（所有者方）。图27显示控制和所有权对象所有权方的位置示例实例顶级Party类和层次结构（图28）可以包含Person和Organization子类。组织可以包括业务部门和团队子类。图28参与方类的层次结构和关系参与方可以拥有合法所有权，可以分配给事务，并指定对象的所有者（对象类的“所有者”属性）。使用这种方法，每个对象都属于一方，并在创建时分配给所有者方。所有者方可以是创建对象的人，也可以是与人或设备关联的组织。所有者方被所有权限授予对象的所有权限。一方还可以承担与一个或多个过程相关的一个或多个角色。“参与方的角色”类（类似于ARTSODM）可以建模为顶级关系类的子类。如图29所示，一方角色的实例可以为另一方（所有者方）指定一方的角色。例如，BobSmith（一个人的例子，一种类型）可以被分配一个“系统工程师”角色（出现在他的名片上）和一个“雇员”角色。与BobSmith（关系的所有者，显示在他的简历上）相比，“雇主”的角色可以颠倒过来。图29PartyRoleReverseRelationshipExamplePartyRoleReverseRelationshipExample贸易关系可以建立当“供应商”角色分配给一方（ArrowElectronics），而反向“客户”角色分配给另一方（via设计为智能）.业务交易顶级交易类和层次结构（图30）可以支持B2B交易和企业对消费者交易，包括订单、装运和支付对象。作为电子数据交换(EDI)的替代方案，这种面向对象的层次结构可以利用所有对象类共有的可互操作的数据交换机制。图30交易类层次结构和关系交易实例可以将一方与另一方（所有者）之间的业务交互（EDI文档）定义为与其有贸易关系的另一方（所有者）。事务项目类可以建模为顶级关系类的子类。交易实例中可以包含交易项的多个实例，以反映正在交易的产品（商品和服务）。各种规模的系统企业实施信息和自动化系统，以有效和准确地控制其运营。每个系统都包含一个本体或数据模型来管理、处理和存储信息对象。会计信息系统（财务/订单管理系统）是跨行业的核心业务系统。通过使用一个通用的业务本体，该系统可以与同样包含该本体的其他内部和外部系统进行内在的互操作。这种方法可以使企业有效地过渡到多方数据共享，以满足不断变化的客户需求和行业合规性（例如供应链可追溯性）。顶级系统类和层次结构（图31）可以支持系统的系统管理。每个“组件”系统都可以定义为“可独立运行”，但连接一段时间以实现某个更高的目标[11]。例如，将仓库管理系统与订单管理系统相连接可以消除重复数据输入并简化订单履行操作。图31系统类及关系自动化系统的事件处理每个系统实例可以包含一个Process实例的集合，Process实例可以包含一个规则实例的集合。流程实例可以根据其规则使用事件实例，并从其操作中生成事件实例。例如，更改订单状态（事件实例）可以触发生成发货或付款的自动化流程。系统根系统的互联网域系统的一个互联网域子类（图32）可以为一方（注册人）分配一个互联网域（类似于IETF的EPP），它可以为该方系统的系统提供一个根系统。例如，互联网域名“Smart-by-Design.com”，“com”可以分配给“SmartbyDesign”组织。SmartDesign的所有子系统都可以直接或间接连接到“Smart-by-Design.com”。图32域名系统指定一方为系统的根系统。系统属性类和系统连接类可以建模为顶级关系类的子类。这两个类的多个实例可以包含在一个系统实例中。如图33所示，系统属性实例可以是表示系统进程的一个或多个内部输入/输出中的类属性，或者是与其他系统共享数据的一个或多个本体。例如，订单管理系统可以引用交易类的“状态”属性和交易项目类的“产品”属性，这两者都包含在一个共同的业务本体中。图33业务系统的系统属性示例如图34所示，系统连接示例可以反映基础系统（通过设计智能）和子系统（订单管理）之间的连接。该子系统又可以成为另一个系统连接实例中的基础系统。镜像系统连接实例可以反映跨对象系统之间的连接。例如，通过设计实现的智能订单管理系统可以连接到ArrowElectronics的订单管理系统，以便能够共享其系统属性实例中定义的公共属性（例如交易状态）以实现跨数据共享。图34业务系统的系统连接示例设备的产品和资产类别顶级产品、资产类别和层次结构（图35）可以支持生产单元（实例），这些单元是在生产过程中使用的材料，成为交易、转换、使用或消耗资产。图35产品和资产类层次结构和多重继承大多数本体模型（例如OMG的UML、Schema.org）允许类层次结构中的多重继承：一个类可以是多个类的子类。这使得生产单元（例如一件设备）既是产品又是资产。它可以继承“Product”类的“Model”属性和Asset类的“Location”属性。生产单位通常从制造商的库存资产开始，然后转移到客户的设备资产。电子商务通用产品本体通用产品本体（类似于GS1的全球产品分类）可以根据产品的基本属性及其与其他产品的关系对产品进行分类。该本体使贸易伙伴能够以相同的方式对产品进行分组，以便在多个电子商务站点之间进行比较。产品本体可以包括设备子类和层次结构（图36），它定义了特定设备类的属性。例如，“PinCount”属性可以包含在Device类中（适用于所有设备），“MaximumOutputVoltage”属性可以属于Device的Sensors子类。电子商务网站(Arrow.com)可以显示传感器实例的继承属性，作为传感器模型之间的特征比较。图36电子商务的设备类属性产品组件类（图37）可以建模为顶级关系类的子类。产品组件的实例可以定义形成“产品的产品”或组件形式的材料。例如，一个实例可以定义恒温器的组件（传感器和执行器），它本身被定义为冰箱的组件。图37将冰箱定义为“产品的产品”的产品组件实例联盟概念可以与这个通用产品本体（图38）保持一致，它包含一个具有标识符、类和所有者方属性的根对象类。图38替换标识符的属性任何一方都可以使用根据标准方法（ISO、IETF）生成的通用（通用）唯一标识符(UUID)来标识对象，而无需依赖中央注册机构。虽然UUID被复制的概率不为零，但它非常接近于零以至于可以忽略不计。UUID和GUID的使用非常普遍，以至于许多计算平台都支持生成它们。然而，同样的对象也可以使用由注册机构（组织）控制的编号方案生成的标识符来唯一标识。例如，GS1维护“ID密钥”的数量，这些“ID密钥”可唯一标识支持全球供应链分布式系统的产品、资产、位置和交易类别的实例。此外，任何组织（如产品制造商、零售商或业务部门）都可以维护自己的编号模式（如产品模型），以唯一标识其内部系统中的对象。为了有效地管理这些“备用标识符”，属性实例可以定义一个唯一的类属性以支持由一方（所有者）控制的特定编号方案。在图39中，包含在产品类别中并由GS1拥有的属性实例用于标识产品实例的全球交易标识号(GTIN)的每个长度。图39支持备用标识符的示例属性实例如图40所示。产品实例可以通过其继承对象类中的标识符属性和产品类（型号、??GTIN-8、GTIN-12、GTIN-13）来标识等）的附加标识符属性。图40具有表示备用标识符的属性的产品实例将通用业务本体扩展到物联网本体产品向智能连接设备的演变——越来越多地嵌入到更广泛的系统中——正在从根本上塑造公司和竞争[12]。智能互联产品需要重新思考设计。在最基本的层面上，产品开发正从主要的机械工程发展为真正的跨学科系统工程，可以支持系统的系统，如图41[13]所示。图41将IoT转化为系统的系统与系统的系统一样，IoT组件是异构的、自治的、能够通信的、分布式的并且在操作和管理上是独立的。这两个领域都在导致新行为的动态情况下发展和运作。在这种情况下，物联网可以被视为一个设备系统[14]。随着业务系统和平台被重新设计为以物联网为中心，智能设备可以设计为以系统为中心，并利用通用的业务本体来提供业务和设备系统之间的内在互操作性。控制器是一种设备（通常是微处理器或计算机），可以监视和更改与其控制系统相连的组件（传感器、执行器）的运行状态（例如温度或速度属性）。这些设备的控制属性可以在通用设备本体的类中定义（图42）。设备控制器子类中的“系统”属性允许将系统分配给控制器实例。图42设备主体包含设备系统属性系统属性类可以包括支持的控制器设备系统的实例（图43）。这些实例可以引用通用设备本体中的类属性，表示系统进程的内部输入/输出，或与其他系统共享的数据。例如，气流控制系统可以引用传感器子类的“温度”属性、控制器类的“时钟”属性和执行器子类的“速度”属性。图43设备系统系统属性实例系统连接类可以包括与业务系统连接的配套设备系统实例（图44）。例如，一个实例可以反映气流控制系统和HVAC系统之间的连接，后者连接到智能建筑系统，后者连接到通过智能设计启用的设施管理系统。图44设备和业务系统的系统连接示例示例智能建筑系统可以包含一个进程，该进程可以更改风扇电机（一个组件设备）的“速度”属性，该进程由分配给连接的控制设备控制气流是控制系统。当触发事件实例发生时（例如温度变化），这个过程可以产生一个可以改变风扇速度的事件实例，并且可以通过过程规则监控这种情况。例如，当智能楼宇管理“四”层位置的“气温”属性超过华氏74度的设定值，且时间为早上7:30至下午6:30（流程规则）时，开启风扇速度更改为30rpm。将组织数据模型与通用本体相结合组织联盟可以通过抽象和分解不同的数据模型、使其以系统为中心并调整其概念和术语来加速通用本体的采用。例如，Zigbee集群、OpenConnectivityFoundation(OCF)“资源”和蓝牙“配置文件”可以移动到一个通用的“系统”概念/术语，包括“属性”和“过程”。Consortiumconceptscanbealignedtoformacommonsystemontology(Figure45)图45CommonSystemontology的类对齐Theunionobjectscanbealignedtoforminstancesofcommonsystemontology(Figure46)图46Acommonsystemontology对象分解和对齐可以将对齐概念联合起来形成一个通用的设备本体（图47）。链接模型或本体之间的数据元素。例如，需要与贸易伙伴发送和接收业务交易的企业可以创建一个数据模型，将数据从其业务系统的数据模型映射到EDI标准。控制器设备也可以使用数据映射，该控制器设备从资源稀缺的传感器接收数据，该传感器需要“语义注释”以提供标准时间序列内的完整上下文。数据映射类（图48）可以建模为顶级关系类的子类。数据地图实例可以将传感器对象(zn3-wwfl4)和属性（温度）链接到位置对象（四楼）和属性（气温）。通过引用此DataMap实例，控制器可以使用DataMap实例中包含的语义来注释从传感器接收到的语义，以填充时间序列的元数据。图48支持语义标注的对象属性数据映射设备和业务事件的通用时间序列为了创造价值，物联网设备产生的数据越来越规范化为时间序列数据（带时间戳的数据），并以固定的时间间隔分布（基于间隔）或基于状态（或值）的变化（基于事件）。时间序列类（图49）可以建模为顶级事件类的子类。时间序列实例可以被高效地索引、共享、存储、查询和分析。随着业务应用程序（系统）变得更加以物联网为中心并围绕事件驱动的架构构建，来自业务事件的数据也可以规范化为时间序列数据。通用时间序列类可以支持反映对象状态（属性值）变化的设备和业务事件。图49设备和业务事件的常见时间序列示例例如，时间序列实例可以根据传感器值反映某个位置的空气温度变化，从而产生一个反映冷却风扇速度变化的实例，从而产生一个反映风扇发动机故障，导致反映制造商更换零件订单和服务工作订单的示例。时间序列实例还可以反映货币单位相对于货币单位的转换因子（货币汇率）值的变化，这会影响更换零件的价格。总的来说，本文讨论的概念（类）可以形成支持业务和设备语义和流程的通用跨行业本体。这可以消除定制系统集成的成本和复杂性。参考资料10Lheureux、Benoit、GartnerResearch，201611年3月Jamshidi,M.，系统工程系统：原理和应用，CRCPress，2009.12Porter,MichaelE.和Heppelmann,JamesE.，“智能互联产品如何改变公司”,哈佛商业评论，201513年10月Bleakley,Graham和Hause,Matthew，“系统工程系统和物联网”，OMG网络研讨会，11月8日201614Alkhabbas,F.、Spalazzese,R.和Davidsson,P.，物联网-basedSystemsofSystems,瑞典马尔默大学【本文来自专栏作家“老曹”原创文章，作者微信公众号：哦家ArchiSelf，id：wrieless-com】点此阅读更多作者的好文章这位作者
