国标解读（二） | 智能制造核心标准《智能制造应用互联 第1部分：集成技术要求》

管理壳是虚拟的信息模型定义，管理壳信息模型决定了通过包装器发布服务的报文标准格式，定义了消息报文数据结构。管理壳是协议包装器的核心信息模型。

▲ 管理壳信息模型与包装器构成关系

管理壳信息模型是物理或数字资产抽象化的“资产模型”，将资产的关键要素整合进结构化和层次化模型中，管理壳信息模型是资产虚拟化、数字化和服务化的表示，其“资产模型”应由“目录清单”和“组件管理器”两部分组成：

a)目录清单是数据的目录，这些数据代表资产的元信息，是虚拟表示的重要组成内容，除了元信息以外，还包括管理壳与资产间的连接关系，以及与安全能力相关的信息；

b)组件管理器使虚拟资产具备基于SOA的信息通信能力，以便外部可以访问模型的“目录清单”和资产的技术性功能。

管理壳信息模型的组成结构应由路由域（Header）和数据域（Body）两部分，管理壳信息模型结构决定了消息报文的格式及内容：

记录管理壳自身的标识、资产/服务标识、转换协议、路由信息；

分别是“操作指令”和“业务数据”，

1)第一段是操作指令，记载本次请求的操作指令，如增加、查询、修改、删除数据等操作功能；

2)第二段是业务数据，记载本次交换的数据内容，包括输入参数和返回参数。

▲ 管理壳信息模型内部结构

协议包装器是对已有IT系统、OT系统、硬件功能的能力封装，并对其提供的服务抽象化的信息结构，通过协议包装器三个组件的组合形成抽象的能力发布。

▲ 协议包装器装配结构

协议包装器注册管理器由UI表单维护界面完成，包装器构成应有以下要素：

a)包装器唯一标识ID：标识服务化接口的唯一ID，根据接口所属的系统、业务域等按照服务编码规则自动生成；

b)系统标识ID：服务来自哪个系统或者设备的标识；

c)消息唯一标识ID：在调用时动态生成消息唯一ID；

d)接口连接参数：记载接口的连接参数，包括IP地址、用户名、密码、数字证书等；

e)接口访问权限：接口的访问许可权限、黑名单、白名单；

f)接口安全认证参数：接口访问数字证书等；

g)接口协议及匹配的适配器：接口使用的协议类型及对应的协议适配器模板；

h)接口入站参数：接口调用的输入参数；

i)接口出站参数：接口调用的返回参数；

j)接口调用报文样板：XML的消息报文样板；

k)接口测试报文：接口联通性测试的测试报文。

▲ 协议包装器构成要素模型

协议包装器模型是一个抽象的协议接口的服务化表达模型，通过包装器注册管理程序实现，是实现CPS融通互联引擎的重要部件，由接口、管理壳信息模型、协议适配器三个部分组成，不同的协议包装器间通过统一的异步通讯消息机制实现。

▲ 协议包装器之间的通讯模式

协议包装器功能应有以下设计要求：

a)实现从物理世界到信息世界的映射：用计算机可处理的形式对资产信息进行形式化定义，捕获现实世界中资产对象所产生的事件，并映射到信息世界中的相应事件上；

b)具备主动通信能力：资产对象应能向外提供信息，使用统一的数据格式与信息系统进行主动通信；

c)信息建模能力：作为信息载体的物理资产，将可能来自于异构数据源的、表示资产对象属性的简单数据和复杂数据做一致性集成和持久化；

d)服务建模能力：服务是“实体或组织通过接口向外提供的相互分离的功能范围”。资产对象除了向外界提供信息以外，还提供技术性功能，功能代表基本执行规则和决策逻辑的技术性功能，再到具体用例场景的需要，组合成具有服务内涵的功能范围。资产对象应具备对技术性功能的形式化、数字化表示能力和对服务的建模能力；

e)面向服务架构能力：资产对象应具备以SOA方式接入更高一级的服务编排和流程协同层，以服务于更高层次的业务目的。包装器一方面接收并记录来自资产的实时数据（RuntimeData），另一方面通过面向服务的应用程序接口（API），以一致性的通信方式向外部提供数据和功能服务，并支持数据和功能视图（View）的浏览。

服务请求方报文应由两部分组成：

a) 服务路由域（Route）；

b) 服务数据域（Data）。

  1) 控制数据域（Control）；

  2) 请求数据域（Request）；

  3) 响应数据域（Response）。

服务提供方报文应由两部分组成：

a)服务路由域（Route）；

  1)响应信息域（Service Response）；

  2)流程控制域 （Processes）。

b)服务数据域（Data）。

  1)控制数据域（Control）；

  2)请求数据域（Request）；

  3)响应数据域（Response）。

共同完成消息报文的传输、转换、路由等任务，是消息体通过的逻辑通道，消息管道流应有以下作用：

a)在消息流管道中，消息体内容被解析、重组、格式转换等逻辑操作；

b)记录错误信息和日志信息；

c)消息流管道模板由可视化消息流编排工具开发实现，并部署于消息流引擎上；

d)为实现两端系统的解耦，消息体逻辑处理管道被设计成两部分，一部分用于请求消息处理逻辑，一部分用于响应消息处理逻辑；

e)消息流两端通过消息队列进行消息的接收和发送，消息队列提供缓冲机制，便于被请求系统繁忙时，请求消息排队用，不至于使消息丢失；

f)消息流管道除了处理正常的逻辑以外，还负责监控每条消息的传输情况，记录消息体在每个节点所用的处理时间，以判断引擎及周边系统的健康状况，实现服务治理，负责失败消息的重发等。

接收处理消息流宜有以下功能要求：

a)消息接收；

b)格式检查；

c)安全授权检查；

d)消息初始化；

e)消息路由；

f)消息输出。

响应处理消息流宜有以下功能要求：

a)消息接收；

b)格式检查；

c)安全授权检查；

d)消息初始化；

e)流量控制；

f)消息路由；

g)消息输出。

入站请求接口适配处理消息流宜有以下功能要求：

a)协议转换；

b)格式转换。

出站接口适配处理消息流宜有以下功能要求：

a)协议转换；

b)格式转换。

错误处理消息流宜包括以下功能：运行时异常捕获。

日志处理消息流宜包括以下功能：记录信息交换日志。