M2M标准在智能家居中的应用
引言
在前面的文章中我们描述的M2M架构被设计为横向架构,它们的服务层方法对于任何种类的M2M应用来说都是通用的。然后,对于真正的实现而言,有必要与通用的标准的目标保持一些距离,并支持受现实约束的特定的应用。本节专门针对以智能家居网关为中心的参考架构,该架构是可以联合智能家居应用开发商,制造商,运营商和服务提供商的HGI (HGI:Home Gateway Initiative,参见:)行业组织进行标准化工作。在这个特定的智能家庭领域需要一种抽象层以及对语义的需求使其与ETSI M2M / oneM2M标准化机构合作。
正如我们前面的文章中所说,M2M服务层标准最初由ETSI M2M制定的,现在由 oneM2M推动M2M标准化以适用于任何M2M应用领域。特别是,M2M可以在家庭环境中实现多样化的有前途的服务。
一些示例性应用包括涉及不同类型的领域,包括:智能电网(与家用电器能耗相互作用的需求和响应相关的应用场景),医疗保健,家庭自动化和安全性(例如烟雾检测或者入侵检测应用场景)等,这些应用中包括不同类型的行动器,但是需要一些相似类型的功能(认证,识别,访问权限控制,设备管理,存储和转发数据,计费记录等)来运行其应用程序。
图1展示了可由M2M应用提供商利用的M2M标准提供的一些功能性(在 ETSI M2M标准组织的术语中称之为“服务能力(service capabilities)”或者在 oneM2M标准组织的术语中称之为“通用服务功能(common service functions)”)的示例,因为这些功能大多数都在M2M2应用提供商的核心业务范围之外,这样应用提供商可以专注于他们的核心业务的发展。在该图中,SC在网络域上列出,并给出带有“N”前缀的缩写,用于表示在NSCL(NSEC,NRAR等)上的SCs(service capabilities);而相同的在网关SCL上的SCs可以使用“G”前缀而不是“N”标注,如GSEC,GRAR等或者在设备SCL上的SCs用前缀“D”标注,如DSEC,DRAR等。
图1、为不同的M2M应用提供商提供的通用的功能框架
我们看到的智能家居示例中,为了允许应用在不同的服务提供商之间共享,预计将需要通过标准化的APIs来提供最小的功能集,包括:
认证
访问权控制
从家中的设备访问订阅的某些事件的应用程序
发生事件时通知应用
有关在智能家居环境中正确运行应用所需的软件配置信息
配置硬件和应用
这些功能通常是由上面所示的ETSI M2M框架提供的通用SC的子集。当考虑如何在家庭网关服务层上实例化时,可以特别注意到ETSI M2M的一些最低限度的功能,如图2所示(智能家居案例被认为对于智能家居案件至关重要的功能被写在蓝盒中,而与智能家居的最低优先级的功能则放在白盒子中)。在该图中的实例称为“M2M代理(M2M Agent)”。
图2、可以在家庭网关GSCL上实例化的一些ETSI M2M服务功能的示例
ETSI M2M使用本地API(dIa)将允许传统本地网络访问M2M代理,而从HG(家庭网关)向云(mId)使用ETSI M2M API则允许我们通过mIa云API解决第三方应用程序。
通过更加具体地看待全球智能家居服务架构,可以看到如图2所示它由三个主要部分组成的:
1.房屋内的“家庭”部分,涉及处理本地应用程序,嵌入在设备和/或网关中;在这里,我们可以发现设备制造商和家庭自动化专家(例如,用于监控百叶窗或者监控照明灯光),以提供 ad hoc(点对点)智能家庭子系统。
2.房屋和外部世界之间的边界部分,可能包括(智能)家庭网关与远程服务平台之间的接口。
3.“云”部分,其中远程应用程序可以通过与将远程应用程序参数转发到寻址的家庭设备中的服务平台的接口进行目标定位家庭设备。
图3、智能家居的整体架构。
虽然在上面的图3中已经引用了一些标准,但它们并不是智能家居领域唯一可以看到的标准。相反,它强调了今天正在寻求独立于执行环境的智能家居的通用工具的组织之间的讨论,以及为部署智能家居服务而选择的连接技术。
从智能家居的角度来看,当考虑到存在资源有限的设备以及互操作性方面的问题时家庭内部部分(in-home part)具有特定的要求,这一点对于获得更愿意投资具有根据自身未来需求演进保障的可持续解决方案的最终用户的信心尤为重要。
通常家中存在各种具有各种标准化或者专有化无线连接技术的设备。为了增强最终用户的智能家居体验,HGI(HGI:Home Gateway Initiative,参见:)意识到,至少需要统一这些各种室内无线技术之间的一些安装和配对机制。 HGI意识到,以可以预期的最低需求集推广这些技术的最有效的方法是制定一个要在这些技术联盟之间传播的要求规范,并获得他们满足这些技术可能性要求的反馈。 HGI已经发布了相应的规范(参见:/downloads.aspx和下面的表1),并打算使用不同联盟的反馈来参考最适合RD-039中列出的智能家居需求的技术。
表1、HGI已经发布了的智能家居规范
Number | HGI Publication | 下载地址 |
HGI-RD057 | Wi-Fi System Requirements for Home Gateways: NFC Pairing, Guest Access, Hotspot | /userfiles/file/downloads/P_HGI02721R04.pdf |
HGI-SBI054 | Use Cases and Architectures for Hybrid Access | /userfiles/file/downloads/P_HGI02712R02.pdf |
HGI-SBI052 | Hardware Virtualization in Home Gateways, and comparison to Multi-Threading, Containers and NFV | /userfiles/file/downloads/P_HGI02619R12.pdf |
HGI-RD048V2 | HG Requirements for HGI Open Platform 2.1 | /userfiles/file/downloads/P_HGI02647R17.pdf |
HGI-RD048 | HG Requirements for HGI Open Platform 2 | /userfiles/file/downloads/HGI-RD048-HG_Requirements_for_HGI_Open_Platform_2_0_published_text.pdf |
HGI-RD045 | Wi-Fi requirements for Home Gateways - Automatic Channel Selection and Repeaters | /userfiles/file/downloads/P_HGI02464R05.pdf |
HGI-RD045V2 | WI-FI requirements for Home Gateways: Automatic Channel Selection, Channel measurements and repeaters | /userfiles/file/downloads/P_HGI02464R15.pdf |
HGI-RD044 | Home Gateway Base Requirements: Residential Profile 2 | /userfiles/file/downloads/P_HGI02723R11.pdf |
HGI-BR040 | Use Cases and Business Requirements for Media Gateway (MG) | /userfiles/file/downloads/HGI-BR040-Use-Cases-Bus-Req-Media-Gateway.pdf |
HGI-RD039 | Requirements for wireless home area networks (WHANS) supporting smart home services | /userfiles/file/downloads/RD039-Req-for-Wireless-home-area-networks.pdf |
HGI-GD038 | HG Requirements for Local Reading of Smart Meters | /userfiles/file/downloads/RD038%20Publication%20Source.pdf |
HGI-GD036 | Smart Home Architecture and System Requirements | /userfiles/file/downloads/RD036Publication.pdf |
HGI-GD035 | HGI-GD035 Smart Home Use Cases | /userfiles/file/downloads/P_HGI02362R07.pdf |
HGI-RD031 | Requirements for power management of home network devices | /userfiles/file/downloads/HGI-RD031.pdf |
HGI-GD030 | KPI Evaluation Framework Discussion Document | /userfiles/file/downloads/P_HGI01901R07.pdf |
HGI-RD027-R3 | Home Gateway QoS Module requirements | /userfiles/file/downloads/HGI-RD027-R3-QoS-Module-rq.pdf |
HGI-RD026 | IP-PBX Module Requirements | /userfiles/file/downloads/HGI-RD026-IPPBX_published_version.pdf |
HGI-RD024 | Requirements for an NGA (Active Line Access) Capable NT | /userfiles/file/downloads/HGI-RD024_Req-for-NGA.pdf |
HGI-GD017-R3 | Use Cases and Architecture for a Home Energy Management Service | /userfiles/file/downloads/GD-017-R3_use-cases-and-architecture-for-home-energy-Management-service.pdf |
HGI-RWD016-R3 | HG and Home Network Diagnostics Module Requirements | /userfiles/file/downloads/HGI-RD016_HG-Home-Network-Diag-Modul-Req.pdf |
HGI-RD015-R3 | Requirements for Common Power Supply for Home Networking Equipment | /userfiles/file/downloads/EF_HGI01556.pdf |
HGI-GD013-R2 | QoS Whitepaper | /userfiles/file/downloads/HGI-GD013-R2.pdf |
HGI-RD012 | QoS and unicast/multicast requirements on Home | /userfiles/file/downloads/P_HGI01628R19.pdf |
HGI-RD010-R3 | Home Gateway Requirements for Multiple Session Support | /userfiles/file/downloads/RD-010-R3_HG-req-for-multiple-session-support.pdf |
HGI-RD009-R3 | Requirements for an energy efficient home gateway | /userfiles/file/downloads/RD-009-R3_Req-for-an-energy-efficiency-HG.pdf |
HGI-RD008-R3 | HG Requirements for Software Execution Environment | /userfiles/file/downloads/RD-008-R3.pdf |
HGI-RD007-R2 | Requirements for HG Interworking with an External NT | /userfiles/file/downloads/HGI-RD007-R2.pdf |
HGI-GD006-R2 | IMS Enabled HG | /userfiles/file/downloads/HGI-GD006-R2.pdf |
HGI-GD004-R2 | Performance Metrics | /userfiles/file/downloads/HGI_Performance_metrics_v1.pdf |
HGI-GD003-R2 | Parental Control in the Home | /userfiles/file/downloads/HGI_Parental_control_v1.pdf |
HGI-GD002-R2.01 | Remote Access Guidelines | /userfiles/file/downloads/HGI_remote_access_v1.01.pdf |
HGI-RD001-R2.01 | Home Gateway Technical Requirements: Residential Profile V1.01 | /userfiles/file/downloads/RD-001-R2-01_HG-Tech-Req-Residential_V1-01.pdf |
然后,为了联合智能家居应用程序开发商,服务提供商,网关运营商,网关制造商和设备制造商围绕着具体的实现者来朝着高效和可互操作的方式来向终端用户提供智能家居应用,HIGI和BBF(BBF:Broadband Forum(宽带论坛) ,)正在合作开发一种设备模板,该模板旨在提供用于导出相干设备数据模型的工具。 HGI GWD-042工作指南文件旨在提供一种手段来规定设备,操作以及最终的通用模板,使所有智能家居利益相关者能够共享数据的结构和含义的共同定义。具体来说,提供GWD-042文件的主要目标是:
- 解释被认为对软件开发人员和最终用户能够访问的各种智能家庭用例,电器和设备有用的信息类型;
- 描述收集和建模信息的全球过程,这将有助于智能家居部署;
- 讨论具体的格式(“模板”),以方便收集过程数据。
预计这项技术工作将由支持智能家电互操作性的指定语义发起全球行动举措的欧盟委员会DG CONNECT(参见:)中加以考虑。
联合智能家居行动者的另一种方法是通过让家庭自动化子系统的不同业主通过一种“家庭总线(homebus)”在它们所有的子系统之间交换事件的通用方式达成一致,以解决房屋中的服务互操作性问题,其中的“家庭总线(homebus)”作为逻辑总线使得来自任何家庭自动化子系统的抽象事件都可以被连接到该家庭总线的任何其他的HA(家庭自动化)子系统循环使用。在法国,这种做法是由“AGORA des reseseux domiciliaires”进行的,在由EC DG CONNECT组织的研讨会上提出。在其他欧洲国家(例如,意大利的Energy @ home(参见:)和德国的EEBus,参见:)中选择了类似的方法,其中欧洲委员会DG CONNECT希望利用达成融合的技术解决方案,由TNO研究所(位于荷兰,参见:)负责向已经参与此类开发的所有利益相关方推荐。
HGI还在联合智能家居网关角色围绕智能家居在网关级别的抽象层进行设计,以便应用开发人员不必适应每种特定的技术以提出其在房屋基础设施中实施的应用。在HGI智能家居参考架构要求工作文档HGI RWD-036中,确定了关键参考点,如图4所示,其中包括使应用程序开发人员能够以统一的方式访问此抽象层的RPs。
图4、以网关为中心的智能家居概述
不仅是HGI(),BBF(),ETSI M2M ()/ oneM2M()以及OSGi ()等其他一些SDO(标准开发组织(SDO, Standard Development Organization))都在努力实现本地连接技术的抽象,并且随后参与HGI智能家居参考架构的制定。
作为这个抽象层的第一步,一个典型的例子就是如何将一个特定技术,例如ZigBee进行“抽象”,即把它的任务和属性映射成通用语言,而另一个具体的技术,例如,KNX(参见:或者:)也被“抽象化”成同一种通用语言。
在其与M2M区域网络互通的指南(参见:)中,ETSI M2M通过利用application / xml语法的oBIX 1.1语言(Open Building Information Xchange)(参见:)提供了一种可行的方法。 ETSI技术报告102 966(参见:)提供了映射原始ZigBee类型(ETSI技术报告102 966的附件B.2.1),原始wM-Bus原语类型和单元(附件B.3.1)以及原始KNX数据点类型(附件B.4.1)到oBIX类型和单元的映射示例。这种将多技术特定语义映射到一个公共的第一级语义约定中是实现应用程序不依赖于底层区域网络硬件和技术方面的第一步。
除了第一级语义映射之外,ETSI技术报告102 966(参见:)还提供了一种发现M2M区域网络结构的方式,创建了一种表示ETSI M2M SCL中的M2M区域网络结构的ETSI M2M资源结构,并管理M2M区域网络结构发生变化情况下的ETSI M2M资源结构。这是通过使用专用应用,即称之为互通代理单元(IPU:interworking proxy unit)来执行的。图5显示了IPU如何使我们能够将ZigBee网络表示为ETSI M2M资源的示例,然后就可以通过标准化的ETSI M2M API来操纵它。
这种IPU的典型实现将在家庭网关GSCL(gateway service capability layer:网关服务能力层)上。然后,我们来看一个非常基本的用例(本身不是特别有趣,但在这里却有用来解释这个方法),例如在云中的一个灯光照明应用程序,它会发出一个关闭房间中的一些灯光的请求,这些灯通过ZigBee连接到嵌入GSCL的家庭网关中。该请求通过mIa接口从云端发送到远程平台上的NSCL上,在平台中它可以通过mId接口连接到作为具有开/关簇的表示的GSCL的资源的ZB灯上。
图5、ZigBee网络表示为ETSI M2M资源的示例
在这里,灯的状态被置为“off”,通过将灯从“oBIX”语言映射到本机ZB语言(因为在技术报告102 966中定义“标签(tag)”来描述语义映射定义,将指示这个在GSCL中使用ZB技术表示的灯的状态为“off”),从而导致关闭灯的ZB命令。如果一些灯通过KNX技术连接到相同的网关,则在这个灯的GSCL中将由第二个IPU发出的类似的表示,不同的是这次提到的是KNX技术的“标签”;但整个过程将保持不变。
技术报告102 966文件另外定义了当通过USB加密狗(被认为是具有有限资源的设备,其被插入到家庭网关)来添加对新的M2M区域网络的支持时可以使用的dIa的情形,其被插入到家庭网关应用例中。 M2M区域网络(IPU,M2M区域网络,设备,应用和接口)到ETSI M2M资源架构之间的映射可以用两个步骤描述:
- 一个辅助步骤(以限制外部设备资源需求)
- 一个受控步骤,用于定义哪些REST资源可能由很少或根本没有控制M2M网关的外部设备来创建(为了实现原始协议和创新的可扩展性和透明度)以及M2M网关自身必须创建的哪些资源(用于保持在M2M运营商继续控制之下)
因此,dId接口被引入到ETSI M2M标准(ETSI M2M技术规范102 921 Rel2(参见:)的规范附录L)2中,通过定义“协助GIP”元件来减少资源有限的设备的负担,通过参考ETSI M2M技术报告102 966(参见:)中定义的经典网关互通代理应用( classical gateway interworking proxy application),以允许M2M区域网络技术的抽象和映射到ETSI M2M资源结构中。 “辅助GIP(assisting GIP)”负责将受限制设备的数据映射到dIa的完整标准格式中去。来自M2M区域网络互通技术报告附件E(ETSI M2M技术报告102 966(参见:))的图6说明了该方法。这里的例子表示可以部署(例如微型DA设备应用)应用嵌入到连接刚刚提及的网关的加密狗(设备d)中。
图6、用于有限资源的设备中的dId接口
考虑约束设备时的另一个概念是通过扩展到NSCL来简化使用dIa接口,允许将M2M标准化服务接入不支持DSCL或GSCL的设备。这可能是无法实现完整的ETSI M2M协议栈的受限设备的情况。相关协议还建议减少对资源检索请求响应的冗长度,并缩短URI和消息的长度(技术规范102 921 Rel2的附件M和N,参见:)。
M2M标准化的结论和未来发展趋势
ETSI M2M提出的水平架构方法,然后被oneM2M标准所采用,这一点对于跨域交互来说特别重要。 ETSI M2M“存储和共享”基于资源的范式标准化框架使数据可以由平台通过提供足够抽象的服务层提供给任何其他应用程序,以使框架独立于底层连接技术和设备。同时统一的接口简化了实现,并实现了互操作性。
oneM2M合作伙伴关系已经形成以开发一个独特的M2M服务层标准并且由“垂直”行业或者SDOs(标准开发组织)的关键支持所补充来实现全球标准化机构的涵义。这使我们能够确保在这种标准化工作中考虑现实世界的需求,并且所生成的标准对于希望执行它的行业来说是非常有用的。
使用这样一个通用标准化框架的关键优势在于可能与其他行为者共享一些数据,从而能够实现向最终用户提供丰富应用的预期演进,以及实现具有应用能力的可互操作设备,这将有望鼓励M2M(和物联网IoT)市场的起飞。
本章还展示了智能家居“垂直”的例子,其中展示了如何在其特定用例中利用这种M2M框架。这导致了将思想推向需要一种通用的数据结构化的方式,并正确地说明了它们的意义。这将标准化的努力推向语义和本体世界,任何想要从交叉应用协同效应中获益的人都是有如此需要的。这也是欧洲委员会DG CONNECT预测的方向,可以从TNO的研究得到相关的研究,这些研究得到了所有相关利益相关者的支持,在2015年初,ETSI 发布了Smart M2M智能家居本体标准能够支持从M2M服务层框架映射到更为概念化的数据模型(元数据模型)(参见:)。
实际上,一些用例和设备可以从不同的应用领域考虑,这意味着更多的词汇将被这些场景中涉及的设备所理解。这个词汇和所涉及的实体之间的关系的考虑形成了我们所说的语义。抽象和语义支持的概念在图7中有所区别。这些构成了应用程序开发人员专注于应用程序开发的基本要素,而不用学习运行其应用程序的设备将使会用到的每个特定技术。
图7、抽象技术和语义支持概念,作为向应用程序开发人员开放的可互操作的M2M系统的基础。
因此,预计在M2M / IoT应用程序的互操作性方面,M2M标准化活动将进一步深入到整合语义学和本体学方法中,同时考虑到预计实现本体之间的互操作性的需求的研究项目的首要方向。 oneM2M已经通过其第5工作组审视了这些方面,该工作组有一个专门的“抽象和语义学(abstraction and semantics)”的项目,其中包括欧洲项目族IERC AC4 (参考:)关于语义互操作性的内容。
M2M标准化也应该具体实施,这将意味着需要制定作为准备符合M2M标准的系统认证基础的测试计划。互操作性测试事件正在成为这个多个活动领域中必不可少的一件事,以确保这样一个水平的标准化框架对行业的价值。
图8、通过全球网络框架访问智能家居设备
(完)