移动端
物联网智慧家庭的自动控制方案解析
  • 关键词:智能家居,物联网,自控
  • 资料类型:
  • 上传时间:2016-09-28
  • 上传人:
  • 下载次数:14173
  • 需要积分:0

暂无上传相关文件

资料简介

  近来物联网(IoT)潮流兴起,以及低成本感测与控制元件大量出笼,使得智慧家庭的发展快速升温,各种家用装置已开始加入联网与智慧化功能。此一转变,也让自动化控制应用逐渐由过往较大型的工厂、商办大楼或公共场所,进入一般民众家中。
  
  物联网(IoT)概念兴起前,自动控制(Automation)已经有相当长的发展历史,从工厂、办公大楼、附属设施到住家,都是自动控制的应用范围。早期相关元件布建成本、软硬件整合技术门槛较高,自动控制多半仅出现在工厂、较大型的商办大楼或设施等场所,对于家庭应用一直未能普及。
  
  近年来随着低成本感测与控制元件的出现、网络撷取技术的蓬勃发展,还有各种智能装置的快速普及,使得IoT概念被提出,不仅智慧家庭普及露出曙光,对于整个自动控制领域也出现新的契机。但本该是一脉相承的自动控制与IoT领域,有时观察起来却存在着一种「代沟」,因此本文将从自动控制、IoT的应用需求,探讨相关技术、解决方案的发展趋势。
  
  自动控制逐步向IP网络靠拢
  
  相信较早进入建筑物自动控制领域的人应该都对Modbus协定不陌生,由Modicon公司于1979年提出的Modbus协定因为资料格式简单易懂,快速地成为早期控制网络的共通标准。
  
  包含Modbus在内的早期控制网络,在实体层均使用有线序列通讯(Serial)的线路标准布建,较为常见的是RS422与RS485两种。这类序列通讯需要注意的问题相当多,诸如讯号本身的位元率(Baud-rate)、奇/偶函数检查(Parity)、停止位元(StopBit)与讯息间的间隔时间等,还有线材的材质、长度、绞线规格、串接方式、干扰隔离与终端电阻等,均可能对通讯品质造成影响。这些因素也使得传统序列通讯的控制网络有较高的布建、维护成本与实作技术门槛。
  
  随着电脑网络发展,TCP/IP逐渐成为电脑网络上共通的通讯协定架构,一些传统的控制网络也渐渐发展为以TCP/IP为基础的架构。因应这样子的趋势,Modbus协定也由以往使用序列通讯的ModbusRTU,进化到使用Ethernet搭配TCP/IP通讯协定架构,利用传输控制协议(TCP)传输层协定承载原本序列通讯内容的ModbusTCP。
  
  拜Ethernet架构的简单、维护成本低廉且在电脑网络中被大量应用等优势所赐,与旧有架构比起来,ModbusTCP毋须担心复杂的序列通讯的讯号、线材规范,使得布建与维护的成本、技术门槛均降低不少。
  
  也因为使用TCP/IP通讯协定架构,可以使用网络层IP协定进行定址(Addressing)、选径(Routing),也使得ModbusTCP有较大范围的定址空间与支援较大型网域的能力。若搭配网络桥接器(Bridge),也可经由无线、电力线、光纤等网络型态传输,让ModbusTCP适用于更复杂的网络环境(图1)。

  

图1
  
  图1传统的自动控制网络往TCP/IP协定架构靠拢后,能够与电脑网络、其他IoT网络整合,创造更多元化的应用。
  
  另一方面,随着电子元件大量生产、成本降低,各种更贴近电脑网络,并标榜成本低廉、容易开发的感测器、控制器和相关整合架构如雨后春笋般出现。例如各种使用ZigBee、蓝牙低功耗(BLE)的微型感测器、Arduino、树莓派(RaspberryPi)等,其中也不乏大厂投入。这类解决方案都大量使用无线传输、容易相容于电脑网络,并打着IoT的旗号,俨然成为新的兵家必争之地。
  
  物联网促成自动控制软/硬件现代化
  
  要建构一套能用于生活周遭、串连各种装置的网络,因为要长时间稳定提供服务,无法避免需要考量可靠度与能源效率。已在自动控制领域被广泛应用的各类工业规格控制器、感测器,因架构单纯且经过长时间产品开发,在可靠度与能源效率上皆有不错表现。
  
  步入IoT时代后,因有更大量的通讯需求、更多元化的通讯内容、模式与功能应用,使得可靠度与能源效率又面临新挑战。
  
  建立标准化、支援体系丰富的架构或许是不错的方式,目前可以观察到一些软/硬件厂商正积极朝这个方向布局,例如苹果(Apple)推出的HomeKit、Google主导的ThreadGroup、英特尔(In)发起的OCFIoTivity与高通(Qualcomm)为首的AllSeenAllJoyn等,这些都是针对IoT通讯协定架构(ProtocolStack)还有应用程式执行环境(ApplicationRuntime)推出的整合服务架构(Framework)解决方案,甚至已经有部分开始商品化。
  
  有整合的服务架构解决方案,zui方便的莫过于软件开发与商品整合。软件开发人员可以基于所提供的应用程式介面(API)开发应用程式,除可少花点心思在整合问题外,可靠度与资讯安全等也得以确保。
  
  设备厂商只需要在感测器、控制器上部属适当的服务架构并满足相关的规范,即可让产品有不错的相容性。而在商品整合的部分,有相容于某种服务架构的标示,对于相关人员选择产品进行部署,甚至是消费者选购,都会更加方便。
  
  除整合服务架构外,更往硬件层面看,就是控制器、感测器所使用的微型操作系统了。早期的产品多半使用厂商自行开发,或是委由软件厂商开发的封闭式微型操作系统。近年来出现一些基于UNIX-like、POSIX操作系统架构开发的开放原始码微型操作系统,例如Mbed、Contiki、FreeRTOS等。
  
  这类型操作系统功能较为单纯,同时间须执行的处理程序也比一般电脑少很多,但须考虑资料处理的即时性,不能有太大的延迟。因此除核心、软件模组的档案大小都很小外,架构上也是针对指令集较为精简的控制器芯片设计并*化,且多采用事件触发导向(Event-driven)、即时操作系统(Real-timeOS)等概念设计,以满足需求。
  
  就控制芯片的设计层面,也出现许多更省电、又有强大运算能力的芯片,搭配适当操作系统、服务架构与应用程式,都是未来IoT普及所需的重要元素。目前软、硬件厂商,甚至是开源社群,皆投入不少心力在整合解决方案上,合作比单打独斗带来更大的力量,透过软/硬件整合、优化,将让新型态的IoT感测、控制元件在可靠度与能源效率上更容易达到实用需求。
  
  不论是IoT还是自动控制,与装置通讯时zui基本的动作都是读取、写入,读取感测器撷取的值、控制器的开关状态或是装置的设定值等,当有控制需求时写入开关状态、设定值等。每个装置可视为是一个拥有多个属性值的实体。
  
  早期相当流行的Modbus使用暂存器(Register)的概念进行管理,每个装置上有数个暂存器,每个暂存器代表不同的开关状态、感测值、设定值等。读/写暂存器上的值即代表读取感测值或状态,或是控制开关的状态、写入新设定值等动作。而装置实作层面只须将感测器、开关等状态与暂存器进行对应。
  
  同样的概念也应用在BLE上,BLE提供ATT协定(AttributeProtocol)与GATT架构(GenericAttributeProfile),每个装置可以定义数个属性质,用读写属性质的方式达到存取、控制的目的。
  
  在资料库与软件工程领域常使用到ER模型(Entity-RelationModel),这样的概念也可套用在IoT中,每一个装置可视为一个实体(Entity),每个实体拥有若干属性(Attribute),而这些实体与属性间的互动关系(Relation),就是IoT所实作的。
  
  在IoT的概念中,将有更多数量、更多种类的装置同在网络上,这意味着IoT网络比起传统控制网络,需要更大的定址空间与更强的定址甚至是选径能力,同时需要支援更多元化的资料型态(图2)。

  

图2
  
  图2生活中一些常见的IoT应用装置与其属性范例
  
  网络汇聚与资源管理
  
  在拥有许多装置的IoT网络中,可能会有多种不同的实体网络介面,例如IEEE802.11、IEEE802.15、电力线网络等,如何汇聚这些网络将成为重要的课题。
  
  在现存的连接层(LinkLayer)解决方案中,常使用的解决方式为将不同网络桥接(Bridge)起来,使得不同类型的网络可形成连通的网域。但对于装置同时拥有多种网络介面、网络拓扑较为复杂的网络环境,就需要一些异质网络整合方案的协助。
  
  举例来说,高通Hy-Fi解决方案所实作的IEEE1905.1即是一种异质网络汇聚的协定,透过抽象连接层(AbstractLayer)的帮助,让上层架构更容易实作,并且达到更高的网络效率。
  
  在网络层(NetworkLayer)的部分,使用IP网络的好处除前面所述的拥有更大定址空间、具有良好的选径能力、容易整合外,也可以使用如IPSec、TLS等网络层、传输层(TransportLayer)安全机制。这也是6LoWPAN会兴起的原因之一,6LoWPAN为针对IEEE802.15成员设计的轻量化网络层协定,标头(Header)较短、且赋予很有弹性的标头定义方式,使得6LoWPAN可以在不浪费频宽资源的情况下具备如IP网络的定址、选径功能,且6LoWPAN标头具有扩充与IP网络相容的能力,使得与整个区域网络整合也相当容易。
  
  在下层都整合到TCP/IP通讯协定架构范围后,剩下的就是应用层(ApplicationLayer)了。基于IoT架构,DominiqueGuinard等人于2009年提出WoT(WebofThings)概念,许多IoT的通讯都将会以HTTP、JSON等协定架构下进行,并搭配CoAP、MQTT或JSON-RPC作为事件发生时的通知讯息推播机制。
  
  目前一些整合服务架构,如HomeKit、IoTivity、AllJoyn等都提供类似架构,而相关的控制器操作系统,也提供轻量的HTTP伺服器与浏览器满足这种需求。这个现象也呼应了前面所提用属性值看待每样东西的概念,在使用HTTP当作应用层协定的情况下,每一个装置上的每一个属性,都可以使用URI(UniversalResourceIndicator)进行定址、存取,而JSON使用精简纯文字表达多种资料型态的概念,也正好满足了IoT通讯所需(图3)。

  

图3
 
  
  图3网络汇聚架构式意图,汇聚不同类型的网络技术,不仅能将各种装置都纳入网域中,也将让上层应用程式、管理机制等更容易开发。
  
  结合云端改变图控软件
  
  图形、视觉化的监看、控制介面对人类是zui为直觉的。传统的自动控制,会将各个开关、感测器接到中控面板集中监控,电脑化操作兴起后,这样的工作被电脑图控软件取代,使用视觉化图形介面让使用者对各个感测器、开关进行监控或设定一些条件动作、排程等。
  
  但传统的图控软件有较高的采购与开发成本,且变化弹性也不高,所以一直以来图控软件皆由少数软件厂商掌握,在IoT架构中更是鲜少听到有人提传统的图控软件。
  
  但图形化操作介面的需求仍然是存在的,前面提到的WoT概念提供一个很好的切入点。网页,动态网页、浏览器端网页程式、网页美工等领域入手较为简单且有广大的开发??者,参考资料、各类素材、应用程式介面也非常丰富,且网页可在大部分人机互动装置上呈现。
  
  WoT架构等于是用开发网页的概念来开发IoT使用者介面,可使用送出URI的方式要求读取某个开关状态或感测器、改变开关状态。解析装置端回传的JSON资料,除能够取得某个属性值外,更可以透过丰富的视觉化套件以酷炫的方式呈现。这些特性都足以让网页介面取代传统的图控软件。
  
  另外一大好处就是可以轻松整合云端介面(API),目前许多云端服务也都是以HTTP、JSON等共通性很高的机制当作传输协定与资料格式。结合云端服务的好处除可用更多种装置,或是在远端存取IoT网络上的装置外,还可以透过云端提供如能源管理、健康照护、安全监控、物业管理等等服务,让IoT的应用更加广泛(图4)。

  

图4
  
  图4IoT设备端拥有与电脑网络相同的通讯协定架构,并搭配具IoT概念的网关,将有助于整合区域网络端各种设备,并介接云端服务。
  
  本文从通讯需求为出发点,从自动控制到IoT、从独立控制网络到整合区域网络,探讨IoT的发展脉络。在可预见的未来,具有IoT的装置会更加普及,连网技术与网际网络接取方式也将趋于多元化,云端服务市场也会趋于成熟。
  
  如此的整体架构下,网关(Gateway)的角色也比以前更加重要,以往网关主要提供区域网络内的电脑或装置存取网际网络,有IoT后,网关将扮演起整合不同装置、不同类型网络,并提供整合管理、云端网际服务接取等服务的角色。
  
  从zui早的自动控制,到现在的IoT,本质上有许多地方相似,都是以属性值看待每个装置,并且对于这些装置、属性加以定址、管理。因此,在早期??的自动控制与现在的IoT之间,「代沟」其实并不存在,某些程度上来说IoT甚至是自动控制的旧瓶新装,当然其中又添加一些新概念。
  
  各类工具与技术发展的出发点无非是希望对于使用者可以更方便使用,对于、营运者能够方便开发、维护。现存的IoT解决方案大致上包装到应用层底部,可轻松基于这些解决方案开发应用程式,使用者也可因此享受更方便的功能。
版权与免责声明: 凡本网注明“来源:智慧城市网”的所有作品,均为浙江兴旺宝明通网络有限公司-智慧城市网合法拥有版权或有权使用的作品,未经本网授权不得转载、摘编或利用其它方式使用上述作品。已经本网授权使用作品的,应在授权范围内使用,并注明“来源:智慧城市网www.afzhan.com”。违反上述声明者,本网将追究其相关法律责任。

本网转载并注明自其它来源(非智慧城市网www.afzhan.com)的作品,目的在于传递更多信息,并不代表本网赞同其观点或和对其真实性负责,不承担此类作品侵权行为的直接责任及连带责任。其他媒体、网站或个人从本网转载时,必须保留本网注明的作品第一来源,并自负版权等法律责任。

编辑精选

更多

本站精选

更多

名企推荐

更多

浙公网安备 33010602000006号