ZhagaBook18如何帮助路灯接入物联网系统

电子说

1.3w人已加入

描述

【导读】:日前,Zhaga联盟最近的技术白皮书翻译出炉,书中Zhaga Book 18 是主角,Zhaga Book 18的诞生将解决路灯接入物联网系统遇到的问题。

Zhaga联盟和ZigBee、蓝牙这些联盟有什么不一样呢?Zhaga Book 18技术是如何帮助路灯接入物联网系统的呢?下面这篇文章将带来详细解读。

1. 从一个简单的例子说起

在讲ZhagaBook 18之前,我们先讨论一个简单的例子。这个例子的思路简单、有效,和Zhaga的思路一脉相承。

假设你是一个电子工程师,需要为一个系统快速实现一个主控板。控制的功能需求是清晰明确的,你做出的板子将交给软件工程师开发软件。这是每个公司每天都在发生的事。

首先,你想到的是功能需求分析和电路实现。前面说了,这个系统定义清晰明确,你可以很快拿出一个方案来。问题是,软件会有什么需求?选择什么样的处理器更合适?考虑到可能的需求变化,在处理器的选择上你有太多选项:

1) 成本优先,尽可能简单。你可以选择单片机(MCU)。下一步,什么型号?

2) 性能优先,为将来软件升级提供余量。你可以选择嵌入式处理器(SoC)。下一步,选哪个公司?什么型号?

3) 软硬件协同设计,提供最大程度的可编程性。你可以选择FPGA。同样地,Xilinx,Altera, Actel,选哪家?什么型号?

这个问题可以表示成图1:

智慧路灯

图1.电子工程师遇到的问题

如何解决?一个简单而有效地思路是:将不确定的部分从确定的部分中抽离出去,使得固定的部分可以快速地实现而灵活的部分可以简便地接入主控板。在这个例子中,我们只要将处理器的外部接口定义清楚(因为系统的功能清楚,所以这个不难做到),即可通过几个标准的排针将CPU部分拆解出来。如图2所示。

智慧路灯

图2.将CPU模块通过定义好的接口独立出去

这种分割,使得即使未来的软件设计天翻地覆,只要系统的硬件功能不变,都可以通过设计新的小CPU板而实现升级换代。

2. Zhaga Book 18要解决的问题

每一种技术的诞生,都是为了解决存在的问题。ZhagaBook18要解决户外照明灯具(为了简便,后面都称为“路灯”)连入物联网系统遇到的问题。

一个路灯接入物联网会遇到什么问题?我们看下图3。

智慧路灯

图3.路灯接入云端的技术选择

如图所示,一个路灯要作为物联网设备接入云端,第一个要解决的问题是选择合适的无线通信技术。对路灯的制造企业来说,路灯本身的设计是轻车熟路信手拈来,从机械、电源、驱动、配光、散热各方面来说都可以进行模块化设计(Zhaga有其它相应的规范)或集成式整体设计。可是无线连接技术的选择就不是那么容易了。我们有太多的选项:

1) 近距通信技术,如Zigbee, 蓝牙,Wi-Fi,Sub-G

2) 传统的移动通信技术,如GPRS

3) 新的低功耗广域网技术,如NB-IoT, Lora等等

这些花样繁多的通信技术各有各的技术优势和适用场景,如何选择?今天的选择明天还正确吗?技术方案如果改了前期产品怎么办?这道难题摆在每一个智能路灯制造商的面前。下面回答本节提出的问题:智能路灯接入物联网,会遇到相对成熟、固定的灯具设计与花样繁多、灵活多变的通信技术的适用和匹配问题。

借用哲学语言重新叙述一遍:当前阶段智能路灯的主要矛盾是灯具设计的确定性和连接技术的不确定性之间的矛盾。

3. Zhaga的解决之道

Zhaga的BOOK 18试图解决这个问题。解决的思路与我们举得那个简单的例子是一样的:物联网技术快速发展,各种应用层出不穷。但是,路灯的功能却是相对稳定不变的,光的控制技术亦是相对成熟的。可以将相对固定的部分标准化下来,而将快速变化的部分开放出来。使得智能路灯的设计可以在相当大的程度上做到“以不变应万变”。

如图4所示,ZhagaBook 18将IoT连接模块从智能灯具中抽离出来(相当于例子中将CPU模块从主控板中抽离出来),并详细、完整的定义了扩展模块与灯具间的连接方式。同时,将模块与云端的连接完全开放,制造商可以选择任何合适的技术。

换句话说,面对智能路灯的主要矛盾,Zhaga的方法是:IoT模块与灯具间的接口由Zhaga来完整定义,保证互操作性。至于连接云端的无线通信技术,作为LED行业的国际联盟,Zhaga的态度可以用三个字概括——“随它去”,或者换三个字——“走着瞧”。请注意,这并不是消极的态度。相反,这是非常积极的态度和定位。

智慧路灯

图4.Zhaga Book 18定义的技术界面

4. Zhaga的4-Pin接口和DALI协议

图5 Zhaga BOOK 18定义的IoT扩展插头

智慧路灯

图5是BOOK18定义的插座,通过标准化的卡槽使得扩展模块快速地安装在灯具上。扩展模块通过什么技术连接云端Zhaga并不涉及,但是该模块与灯具间的接口却有着严格的定义。见表1。

智慧路灯

表1 Zhaga BOOK 18定义的控制接口(4pin定义)

Zhaga将扩展模块控制灯具的接口定义为DALI (Digital Addressable Lighting Interface,数字可寻址照明接口)。这样做的目的,是控制接口的所有细节全部由DALI国际标准定义,不会存在任何技术环节的缺失。换句话说,Zhaga引用了DALI后,灯具控制接口的电信号特性、数据传输协议、应用层协议全部都是明晰的,不存在任何缺失或是歧义。这就从根本上保证了Zhaga标准的合理性和完整性,进而,保证了Zhaga产品的即插即用和互操作性。

可是,Zhaga为什么要选择DALI而不是其它?

让我们回到问题的原点:Zhaga将连接模块独立出去,并将连接模块与灯具间的接口作为Zhaga标准化的范围。那么,Zhaga给出的规范应当具备以下两个特性:

1) 唯一性,即无歧义。

2) 互操作性。凡是符合Zhaga规范的模块和灯具可以即插即用,相互替换。

要满足这两个条件,作为控制协议而言,必须是一个“完整的协议“。借用OSI通信模型的概念,它应该涵盖物理层、网络层和应用层。

与DALI相对应,很多我们耳熟能详的所谓“控制协议”,它们并非完整的协议。图5给出完整协议的模型和常见的控制技术。

说句题外话,与DALI一样,Zigbee是无线通信中的一种完整控制协议,这二者可以进行类比。对Zigbee来说,其自下至上分别是:IEEE802.15.4物理层, Zigbee Pro 2017网络层, 和Zigbee Cluster Library应用层。

智慧路灯

图6. 控制协议的3层模型(简化版OSI 7层模型)

到此为止,事情就很清晰了。Zhaga联盟如果不试图重新定义一种照明用控制协议的话(也确实无此必要),它应当选择像DALI这样的国际开放标准。因为选择了DALI,就满足了“唯一性”和“互操作性”两个必要条件。反之,如果Zhaga不选择DALI,而选择比如UART,那么Zhaga还需要做很多事情:

1) UART定义了如何将一个字节进行传输,可如何用电信号表征字节呢?UART不定义,Zhaga可以选择比如RS422。

2) RS422定义了什么样的电平是逻辑‘0’, 什么样的电平是逻辑‘1’。UART给出了设备间传输字节的方法。那么,字节之上的应用层在哪里?照明属性的支持在哪里?Zhaga还需要进行定义。

再进一步讲,单单1)提出的问题真的那么好回答吗?刚才给出的RS422只是一个例子。其实这个例子并不满足需求。要选择一个合适的电气连接,要考虑很多的事情。这个信号:

1) 单端vs. 差分?

2) 高速vs. 低速?

3) 电压vs. 电流?

4) 长距离vs 短距离?

5) 单向vs. 双向?

6) 点对点 vs. 一对多?

7) 容错性如何?

8) 是否需要阻抗匹配?

DALI标准的物理层是设计非常精巧,深思熟虑的电气接口,绝不是随便选择的。它仅有两根线,是一个极性不敏感的差分信号(即无所谓正负,可以反接),高压差低速信号,支持长距离传输同时具备很强的容错性,支持双向通信和一对多网络型通信,设备端无需进行阻抗匹配。

我重复一遍:DALI具备差分极性不敏感高压差低速强容错双向通信网络型总线无需阻抗匹配的电气接口。从电子工程的角度欣赏,这是一款具有美感的电接口。在作者所能及的范围内,只有工业控制总线可以与之媲美,比如CAN总线,但是后者对极性有要求(不可反接),而且为了更高的数据率必须对终端设备按需选择匹配电阻。

5. 结束语

本文从一个电子设计的例子说起,引出了处理“确定性与不确定性”的思路,进一步分析当前智能路灯的主要矛盾和解决问题的方法。

显而易见,Zhaga Book 18通过合适地分割灯具与控制模块,并将两者之间的接口进行完整地定义与标准化,可以简化智能路灯设计的难度。同时,完全开放的无线通信连接可以随着物联网技术的发展不断地演进、变化。而这一变化并不会给路灯制造商带来过多的困惑。

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分