IEEE1888-物联网领域的绿色节能标准（四）

【从这一节起分几节介绍1888下的子标准】

七、1888.1管理与控制

1. 背景与简介

IEEE1888.1标准于2013年通过颁布，全称为：IEEE Standard for Ubiquitous Green Community Control Network:Control and Management。前面已介绍过，1888网络基本属于“自治”型，没有管理中心，各组件之间是松散的关系。现实当中，存在“自治”型网络，当然也存在“被控”型网络，那么，将管理和控制的思想引入1888中，就是理所应当了。

1888.1就是满足控制与管理的需求而制订。这种网络比较适合于运营，因为它可以控制网关的接入，可以控制访问权限等等。

2. 网络架构

IEEE1888.1体系结构
上图是1888.1的网络架构。对比1888的架构，它多了一个“MCU”组件，MCU的全称为Management and Control Unit，实际上，1888.1就是围绕MCU展开的，下一节将着重介绍MCU。

由于在网络中添加了MCU，为保持兼容性，整个网络分成了受控网络（即图中的Managed Network）和非受控网络（即图中的Unmanaged Network），顾名思义，受控网络是以MCU为中心的、受到MCU控制的网络，非受控网络是之前的1888“自治”网络。

图中列举了1888.1网络中组件交互的4种情况：

1.MCU与非受控网络中APP的交互

2.MCU与受控网络中组件的交互

3.非受控APP与受控GW的交互

4. MCU与Registry的交互

以下将介绍这些主要过程。

3. MCU

IEEE 1888.1是在1888网络基础上，扩展必要的功能而成为的一个可运营可管理的网络。这种管理功能是通过MCU来实现的，因此MCU是1888.1的核心，在标准中，MCU具有RAM(resource access manager)、OAM(operation administration and maintenance)、OSP(operation service provider)等基础逻辑能力。

RAM：可理解为资源控制管理器。MCU首先要控制网关的接入和对网关的访问控制。这就需要一个集中的权限管理的中心，它就是RAM。RAM主要负责网络中各种组件的权限管理和分配，例如，将网关的ACL(Access Control List)和安全策略分发到各网关，再由网关执行这些规则，拒绝非法的访问。

OAM：可理解为运行与维护中心。在控制好网关的权限之后，接着需要监测诸如网关的状态、下发控制类指令使网关更好运行等功能，这就需要一个集中的运维中心，它就是OAM。OAM通常包括网关配置管理、运行状态管理、故障/告警管理、性能管理等。OAM应该包括一个GML (GW Management List )，作为对已接入网关的记录，并作为管理网关的基础。

OSP：可理解为公共服务提供器。在管理好网关运行之后，就需要向外（用户）提供更优质更便捷的服务，这是可运营网络提供增值服务的基础，就需要一个集中的对外服务中心，它就是OSP。OSP主要提供对外的公共服务，MCU充分利用其中心节点的优势，可以方便完成用户难以完成操作任务，例如跨网关的操作，MCU操作起来就相当方便，并且可以将复杂的逻辑包含其中，在操作不成功时，做出适当的额外操作。一句话，管理者将复杂的操作自己扛起来，从而简化用户的操作。

注：MCU至少要提供单个测点查询这样基本的公共服务。

4. 主要的操作流程

上面已提起了4个主要的操作过程。因1888.1与1888的兼容性，1888中已涉及的操作过程依然有效，这里不再重复。

MCU与非受控APP之间的交互

无论是受控APP还是非受控APP，都可以访问MCU，如果MCU都应答，则MCU处于1888网络工作模式，如果不应答非受控APP，则MCU处于1888.1网络工作模式。MCU与非受控APP之间的交互，主要是APP可以调用MCU提供的服务，也可以通过MCU间接访问网关的数据。

MCU与受控网络中组件的交互

首先，各组件应接受MCU的管理，例如，MCU可以下发各种控制指令（ACL之类等），MCU也可以查询组件的状态，各组件发现异常时，也可以向MCU告警。总之，除数据外，MCU可以管理组件的方方面面。

非受控APP与受控GW的交互

与上面类似，如果GW应答，则GW处于1888网络工作模式，如果不应答非受控APP，则GW处于1888.1网络工作模式。在1888网络工作模式下，与1888标准中描述的没有区别。

MCU与Registry的交互

实际上， MCU与Registry必须密切配合才能完成管理功能。在1888标准中，Registry是负责注册的，也就是系统资源的“天然仓库”（测点和组件信息），MCU如果需要管理各组件，首先要获取这些资源，MCU才能对这些资源进行管理。因此，从运行效率上，MCU与Registry需要紧耦合（相对于其他组件之间），甚至它们就是一体化的。

5. 通讯协议

1888.1中个组件之间的通讯协议，采用与1888兼容的格式，并做适当的扩展：对session控制的扩展和对公共服务支持的扩展。

按数据点定义控制项

原则上，组件上的控制项按“点”处理，即每个控制项都是一个“点”，对其读、写，也就是控制项的获取与设置，但具体到MCU需要管理哪些控制项以及这些控制项的具体格式，标准中没有详细规定，在具体项目时可以按需扩展。

对session的控制

1888协议中，没有对session的管理。1888.1中，在header内定义control元素，用来规定session的某些信息。目前，session的控制信息包括

transaction: 操作应是一个完整的事务

priority: 包括优先级别和允许等待的时间

cache-refresh:刷新缓存

delay: 延时操作

实际上对session的控制类别可以很多，可根据项目需求扩展。

对公共服务的支持

公共服务是1888.1引入的新概念，是MCU对外提供的功能，因此MCU必须实现SERVICE 接口（注：service接口是MCU专属的）。对公共服务的支持，包括服务查询和服务调用。

服务查询：

[request]

<service id="8279c39f-270d-9492-82e4-9cd4a5793f8c" name="foo.example.com/sprinkler" type="inquiry" />

[response]

<service id="8279c39f-270d-9492-82e4-9cd4a5793f8c" name="foo.example.com/sprinkler" type="operation">

<argument name="building">2</argument>

<argument name="mode">ON</argument>

</service>

服务调用：

[request]

<service id="8279c39f-270d-9492-82e4-9cd4a5793f8c" name="foo.example.com/sprinkler" type="operation">

<argument name="building">2</argument>

<argument name="mode">ON</argument>

</service>

[response]

<OK/>

或

<error type=”…”>…</error>

标准中没有规定公共服务的定义过程，实际的实施中，视项目的需求，可以向用户开放定义接口（即用户可自定义公共服务）或只能使用系统预定义的服务。

6. 1888.1下的网关

以上基本上是从服务器端（MCU,Registry等）角度来描述的，网关是1888网络中的数据源，是很重要的组件，这一节从网关的角度来描述1888.1，当然，实际的应用中，它们是相互配合的。

在1888.1下，对网关的管理包括以下方面:

设置网关的配置和运行状态，即网关接收来自MCU的控制指令并做出反应；
发送配置和运行状态，即接收来自MCU的查询并做出反应；
向所属的控制器（转换）转发控制指令
监控传感器数据的变化，发现异常报警

将1888和1888.1中与网关有关的过程综合一下，如下图所示。



上图列出了7种过程，都比较简单，具体细节略。

7. 对1888.1的总结

先总结一下1888与1888.1的异同。

1888	1888.1
自治型网络，各组件相对独立	受中心控制型网络，有一个中心控制单元
注重测点数据的传输	注重对组件的管理与控制
就数据传输而言，网络协议相对规定比较完备	协议采用与1888数据的传输样式，但并未规定控制项目的具体内容与格式，因此在实际应用中可能会有比较大的扩展。

再次强调一点，1888.1中的网关等组件与1888中是兼容的。1888.1网关应该比1888网关复杂一些，通过附加相应的模块，1888网关就可以升级为1888.1网关。