5管理与控制单元（MCU)

图3APP直接访问GW

在IEEEStd1888一2011网络体系结构的基础上，本标准引入了MCU模块来管理组件（如GWs） 和其他设备，以获得一个更好操作和管理的网络。任何已注册和验证的GW都将受MCU控制。通过 受权机制，MCU执行GW的访问控制，防止未经授权的操作。MCU还提供公共服务，实现可靠、有效 的GW运行。MCU作为管理单元，能监视和收集GW运行时信息，根据这些信息可以访问远程配置或 发送警报消息， MCU在网络运行中起着关键性的作用。它起到了管理和控制的作用；通过网络，对GW和其连接 的传感器/执行器设备进行抽象资源和设备管理；简化了应用程序和GW之间命令、数据的安全性和性 能。为有效地管理和控制GW，MCU使用SERVICE协议提供公共服务，SERVICE协议见5.3和第 8章。 在MCU的直接或间接参与过程中，已经认证和授权的APP可以通过GW从设备读数据或向设备 写数据。即，当需要控制能耗设备或 参与者，通信过程见7.1中图8

MCU应实现三种基本功能：资源访问管理者（RAM）、操作管理与维护（OAM)以及运营服务提供 者（OSP），如图4所示。 a）RAM管理组件和GW之间的访问控制。它将所有组件（例如GW）和节点视为资源。如果已 将访问权限配置到ACL中，则由MCU管理的APP可以从GW和连接的设备获取数据或向 其发送命令。RAM还负责设置网络的安全策略。例如，可以根据不同的安全要求来调节不 同的授权策略。RAM可以根据这些要求设置不同的安全级别。 b）OAM主要用于组件的配置、运行状态和控制管理。OAM维护着网关列表，即网关管理列表 (GML）。列表中的GW已经通过身份认证酒店标准规范范本，ACL中的GW来自GML，并受MCU控制。「 回 时，OAM监视GW和其他组件之间的消息交互，以保持节点正常运行，具体细节见第7章

OSP提供了公共服务。其中一个服务就是控制或管理功能，它可能需要复杂的逻辑决策，也 更适合于MCU而不是APP。通过这些服务，OSP通过组件负责APP操作，简化APP访问 并为APP提供更稳定可靠的网络。 除RAM、OAM和OSP模块外，MCU还可具备其他业务和系统相关功能，如计费、服务质量 （QoS）等.这些不属于本标准规定范围

注1：MCU提供以下功能： a）向MCU报告GW接人/退出功能： b）由MCU控制从GW到APP的数据传输功能； c）由MCU执行GW运行状态查询功能； d）由MCU实现GW的控制和配置命令功能。 注2：MCU尽量避免繁重任务带来的实时数据传输负担，因此在通过MCUACL验证之后，组件将直接与GW通 信。MCU可以管理和控制这些通信活动

5.3典型MCU通信序列

P向MCU请求服务的典型通信序列如图5所示

图5典型MCU通信序列

实例A：APP向MCU的请求服务。在请求服务验证通过之后，MCU将根据服务请求可与组件可 注册表交互，并将结果返回给APP，APP实现与组件的交互。服务的详细信息见第8章 实例B：MCU检索数据服务，如检索GW与连接设备的运行状态数据，或者向GW发送命令。 实例C：MCU从注册表中查询指定的组件或点信息。 为了执行所需的功能，为MCU定义了一个新的接口“服务”，如图6所示，

图6MCU和其他节点的接口

用于控制GW或其他组件的复杂逻辑决策。通过调用此服务方法，APP能更有效地完成某些任 见第8章。

GW在IEEEStd1888一2011定义的基础上进行了扩展，以便MCU更好地执行管理角色，GW的 详细信息见IEEEStd1888—2011。 作为物理传感器网络和因特网之间的连接，GW是IEEEStd1888一2011网络的关键性组件，它的 基本功能包括：

0015—2021/ISO/IEC/IEEE18881:2016

从传感器/执行器获取数据； 将“设备感知”的数据转换为IEEE1888协议消息，并转发给其他组件； 接受有效的控制命令，并将其转发给执行器； 监控和记录其自身及与其连接的传感器/执行器的运行状态； 在特定事件发生时发送警报消息。 GW可内置访问策略，但访问策略需由MCU管理，以便于MCU可以直接或间接参与所有GW 活动。

图7给出GW的逻辑框架结构，这些逻辑模块实

访问控制模块（AC模块）用于控制GW的访问，包含一个由MCU管理和配置的授权信息列表。 如果MCU知道GW的授权发生变化，它会通知相关GW并更新授权列表，见6.3， 配置模块维护GW的工作模式，包括传感器/执行器的设置。MCU获取和设置配置信息见7.2和 7.3，示例配置见附录C。 现场设备模块用于维护传感器/执行器或点信息。GW需要维护传感器/执行器或点信息来执行读 与传感器/执行器数据的动作。 报警模块用于管理报警信息（报警信息可来自传感器/执行器设备或GW本身）。警报可以告知状 态的变化，如健康检查信息。发送警报前，需在报警模块中定义规则，根据这些规则分析数据（包括GW 工作状态）。如果数据满足触发条件，警报消息会依据规则生成，并按照IEEEStd1888一2011格式发 送给订阅者，见6.4。 为了同时与MCU和传感器/执行器进行通信，GW应具有两个外部物理接口，即： a）连接不同现场总线的南向接口； b）连接UGCCNet其他组件的北向接口。 如果网络是同质的，这两个接口可能是相同的

GW检查ACL以确定是否允许组件访问。来自MCU的访问也应进行检查。组件内访问验证的 过程不在本标准的范围之内。 MCU应在可管理系统中维护整个ACL，并为每个组件提供相应的ACL集。ACL的消息格式不

在本标准的范围之内。附录C给出了ACL编码方法的示例。 GW提供两种方法用于维护AC模块： a）MCU发送更新后的ACL集至相关联的GW； b）GW可请求MCU提供自己的ACL。 ACL应能够表达任意组件对任意节点的任意访问。为了使MCU能够更新ACL，每个组件的初始 ACL只允许一个适当的MCU进行访问。这是因为MCU需要在组件上设置、获取配置和运行状态，但 在安装的初始阶段，必须保护组件不受任何其他访问。 注：在可管理系统中，其他组件（应用、存储）应具有自已的ACL，也应遵循此规则

在本标准的范围之内。附录C给出了ACL编码方法的示例。 GW提供两种方法用于维护AC模块： a）MCU发送更新后的ACL集至相关联的GW； b）GW可请求MCU提供自己的ACL。 ACL应能够表达任意组件对任意节点的任意访问。为了使MCU能够更新ACL，每个组件的初始 ACL只允许一个适当的MCU进行访问。这是因为MCU需要在组件上设置、获取配置和运行状态，但 在安装的初始阶段，必须保护组件不受任何其他访问。 注：在可管理系统中，其他组件（应用、存储）应具有自已的ACL，也应遵循此规则

根据事件来源，GW事件可以被分为两类： a）由GW自身状态或参数的变化触发的事件； b）连接传感器/执行器参数变化引起的事件。 同时，事件触发类型也可以分为两类： a）有条件的，只有在相关参数满足特定条件时才触发事件； b）无条件的，任何时候参数改变时触发事件。 事件可以预先定义，其触发条件由GW提供者预定义且不能修改，这些事件只能订阅。也允许在 运行时定义的事件（称为用户定义的事件）。事件的触发条件和参数应在事件被订阅之前传递给GW。 当满足某些条件时.订阅事件将被触发，订阅方将收到通知.详见7.3

7网关(GW)控制和管理

本章主要描述了GW控制和管理过程。GW的访问由ACL控制，ACL由MCU设置。详细说明 见6.3。 GW管理功能包括： 设置GW的配置和运行状态； 检索GW的配置和运行状态； 向执行器发送控制命令数据； 监测传感器实时数据。 GW访间、控制和管理的工作流程见图8.

3。 GW管理功能包括： 设置GW的配置和运行状态； 检索GW的配置和运行状态； 向执行器发送控制命令数据； 监测传感器实时数据。 GW访问、控制和管理的工作流程见图8

实例A：描述GW注册序列。 实例B：描述MCU采用查询/数据方法访问GW。 实例C：描述GW采用数据方法推送数据给MCU。 实例D：描述MCU采用数据方法更新GW。 实例E：描述APP直接访问GW。在响应APP的任意请求前，GW将验证APP的权限（用AC模 块）。 实例E1：描述验证成功后由GW返回的请求信息。 实例E2：描述验证失败后由GW返回的错误信息。 实例F：描述GW采用查询/数据的方法从/向APP查询/推送数据。 此外，对GW的任意访问都应在ACL下进行验证，其他组件访问也应符合ACL规则，如存储器， APP等。 注：GW与其他组件之间的通信应用安全传输方式，信息的传输安全见IEEE1888

Z.2设置GW的配置和运行状态

GW的配置，也可以调用查询方法和便用TRAP协议向MCU发起请求，以便从MCU获取合适的 配置。 在某些情况下，MCU可以要求GW改变工作模式，从运行状态进人休眠状态或恢复正常运行状 态。GW周期性运行是一项节能管理政策。 GW工作模式（例如：休眠、运行等）如下： 休眠：休眠工作模式表示GW工作在节能模式。在这种模式下，GW的接口模块仍然工作，但 是逻辑相关的处理模块停止工作。 一运行：GW正常工作。 GW的配置设置示例见附录B。 GW可工作在运行、休眠、初始化或脱机状态。MCU可以采用数据方法，发送配置命令来改变GW 的工作模式。例如，当GW处于“运行”模式时，MCU可以发送命令给GW（值=“休眠”)以改变其工作 模莫式为休眠。当GW处于“休眠”模式时，MCU可以发送命令给GW（值=“唤醒”)以改变其工作模式 为运行。在休眠模式下，GW不会响应任何请求，除了来自MCU的查询方法或数据方法（值=“运 行”）。 图9显示了设置GW配置和改变其运行状态的流程

图9通过MCU设置GW配置和运行状态

实例A：描述MCU如何修改GW配置。 实例B：描述应用程序如何修改GW配置。当GW响应来自APP的请求时，GW将首先使用AC 模块验证授权，并且只响应那些验证通过的请求。 实例C：描述GW如何发起请求以从MCU获得合适的配置（如ACL）。 注：上述管理流程也可以应用于其他组件（如存储器）。

7.3获取GW的配置和运行状态

MCU可以通过查询方法获得GW的配置设置或运行状态。GW配置信息见7.2。受监测的GW 运行状态可能包括工作模式、健康信息、统计信息等。健康信息可能包括内存使用率、CPU使用率、磁 盘使用情况等。统计信息可能包括收到的FETCH请求数目、收到的WRITE请求数目和收到的 TRAP请求数目等。这类管理也可以应用到其他组件（见附录B中GW统计信息范例）。 图10显示了获取GW的配置和运行状态的流程

图10获取GW的配置和运行状态过程

实例B所示）。 MCU使用TRAP协议订阅GW运行状态的情况称为事件处理，详细信息见6.4

7.4向执行器发送控制要求信息

执行器的所有控制命令都由GW管理。该命令可能是启动设备、关闭设备等。如果存在这样的服 务，APP可以采用数据方法直接向GW发起控制，或要求MCU采用服务方法执行操作。 有三种方法可用于控制驱动器，如图11所示，

图11向执行器发送命令

实例A：APP使用服务方法向MCU发送控制命令，MCU采用数据方法向GW发送相应的控制命 令以对特定执行器进行控制。这个过程可以是同步的（A"），也可以是异步的（A）。 实例B：APP采用数据方法向GW发送控制命令，要求GW对指定的执行器进行控制 实例C：GW采用查询方法向MCU发送信息请求（例如，GW的配置）或控制命令请求，MCU将采 用数据方法响应该GW的信息。 注：GW与执行器之间的通信不在本标准范围之内

7.5读取传感器实时数据

APP可以调用MCU的服务方法来获取特定的实时传感器数据，或者在需要GW信息的情况下访 问相关GW。 该应用可以直接从GW中检索实时数据，也可以从GW中订阅数据。 流程如图12所示，

图12GW实时数据检

询原APP所指示的相应回调URL。GW从传感器检索到实时数据后，利用数据方法向APP发送 数据。 实例B：APP针对指定的实时数据调用MCU服务方法，MCU将相应的GW信息返回给APP或 方问GW来检索数据。APP可以使用实例C或实例D来读取数据。 实例C：APP使用FETCH协议调用GW的查询方法。GW将使用AC模块验证请求。如果这是 一个有效的请求，GW会将需要的实时数据发送回APP。 实例D：APP使用TRAP协议调用GW的查询方法。GW将使用AC模块验证请求。如果这是 个有效的请求.GW首先向APP发送一个响应。在接收到实时数据后.GW将数据发送回APP

SERVICE（服务）协议应用于调用MCU中定义的服务上。任何组件都可以发起通信。当MCU接 收到协议请求时，MCU应启动调用时指定的预定义过程。预定义过程的行为不在本标准范围之内。 组件（如APP）与MCU的交互过程如图13所示

图13服务方法的过程

来进行组织，这些类的命名空间没有在本标准 义。类名应以大写字母开头，而XML元素名称应以小写字母开头。从第二个字母开始，类名 L名称应该相同。但是，如果类名的前两个字母是大写的（即OK类），则XML的第一个字母也 大写。下面给出了服务协议的各类消息类：

8.2.1Transport类

Transport类允许在一条消息中传递数据和控制信息

Transport具有Header对象和Body对象。当它们不包含任何数据时，则省略它们

0015—2021/ISO/IEC/IEEE18881:2016

(transport)