【图解物联网】第5章 物联网服务的系统开发

5.1   物联网和系统开发

        从字面意思就可以看出，物联网指的是“物”连接到互联网及其机制。物联网做到了对现实世界信息的感测和反馈，但把物联网系统化指的又是什么呢？是把传感器数据存储在数据库中呢，还是从云端自动控制空调和灯光呢？
        笔者认为，把物联网系统化就是应用传感器等各类设备来形成一个持续解决问题的机制。也就是说，不只用传感器进行测量，还通过对测量数据的监测和分析来发现能量损耗，预测机器故障，从而创造出新的信息和价值。而且，系统化并非暂时性的，在成本和应用的基础上生成一个持续运行的机制才是系统化。
        对物联网服务而言，系统的主体是设备，因此在进行系统开发时，也有一些是设备方面需要留意的地方。本章将会为大家介绍一下笔者们开发出来的物联网系统，这个系统是利用前面几章介绍过的架构以及物联网设备开发出来的。另外，本章还会借助开发案例，针对那些应用了物联网设备的系统特有的问题进行说明。

5.1.1 物联网系统开发的问题

        正如第1 章提到的那样，物联网服务潜藏着无限的可能性，然而一旦着手开发物联网系统，又会碰到各种各样的困难。这里从系统的使用者和开发者两个侧面来讲解。
        首先对使用者而言，难以事先预测服务的导入效果，或者说没法下定决心导入服务。虽然物联网服务是基于采集传感器数据等各类数据来掌握和分析现状的，不付诸实践就无法得知实际效果，但也不见得花了钱就能收到相应的成效。
        至于系统开发者方面的困难，从本书涉及技术面之广就能够看出，从事物联网系统开发需要的技术面要比从事一般的Web 开发更广（图5.1）。

        就算是小规模的物联网服务，也需要多方面的知识。除了在服务器端运行的应用程序外，还需要掌握构成设备的硬件、嵌入式软件、连接设备与传感器的网关、无线通信技术和网络等多方面的知识。当然这并不是说如果没有完全掌握这些知识就不能进行设备开发，而是说如果事先了解各个领域的技术内容和机制，就可以防止在开发和使用过程中出现问题。

5.1.2 物联网系统开发的特征

        在开发物联网服务时有一点不能忘记，即“物联网服务是一种包含设备的服务”。
        因为应用了物联网数据的大数据分析是以积累的海量数据和日志为对象的，所以不一定存在设备。然而物联网服务则名副其实，服务肯定与设备（物）相挂钩。又因为设备是构成物联网服务的主体，所以物联网系统存在其独有的特征，具体如图5.2 所示。

        这些特征给人感觉都是理所当然的，可是一旦不考虑这些特征就去进行开发，在应用阶段进行检修或维修终端时就会付出预想不到的代价，所以大家要将这些特征牢牢记下。

易于增加所管理设备的数量和设置地点的数量

        物联网服务由传感器终端等多台设备及集合这些设备的网关终端构成。根据应用状况，这些设备的种类或终端的数量往往会不断增加。例如在办公大楼或是商业楼层中，对温度、湿度、二氧化碳浓度等进行环境感测时，楼层的场所不同，测量到的值也有差异，因此不能光感测楼层的某一处，还要对多个场所进行感测，这样一来就需要在一个房间里设置数个传感器终端。
        此外，为了在应用设备的同时增加设备的数量和种类，多数情况下需要追加连接设备。打个比方，假设已经设置了传感器终端，并进行了监控，但从测量结果来看，有时获取的信息并不足以让我们采取行动，也没有达到理想中的效果。这种情况下为了更详细地进行测量，就需要设置新的传感器来增加测量地点，从其他角度进行分析。而且一旦设置传感器并获得成效，就能将其推广到别的楼层和设施里去。增加设置地点时，新设置的传感器数量跟之前的设置数量是相同的，根据情况不同传感器的数量也会激增。即使是在获得一定成效后，还有很多情况是需要增加设备的，例如增加了其他用户等。

设置在人们平时无法触及的地方

        办公室和商业设施里的设备和网关大多都设置在平时人们无法触及的屋顶或者墙壁等处，因此应用这些设备并不容易。如果要更换设置场所或变更终端内的软件，不仅需要请求设备管理者进行更换，还需要与设置场所的管理人员协调日程，有些情况下还需要跟承包商进行协调。

存在无线通信部分

        有一点很容易被遗忘，那就是数据通信路径上利用的是无线通信。就像第3 章介绍的那样，传感器终端和网关之间通信使用的传感器网络主要是无线通信。此外，连接网关和运营商网络时使用的接入线路也利用了4G/5G/LTE 等无线通信技术。
        当然有时人们也会用有线方式来连接各个设备，但在各类场所追加设置传感器终端等设备时，人们会更多地选择无线通信。一般来说，相较有线通信而言，无线通信的通信品质较低，设备有可能会因为障碍物的设置等现场环境的变化而连接不上通信线路，线路也有可能会因为周边无线电波的干扰而变得不稳定。

5.2   物联网系统开发的流程

        光用笔头很难算出物联网服务的成本效益，如果不去实际地反复采集并分析数据，是无法确切掌握导入效果的。站在服务开发的角度上来说，我们提供的就是以设备为主体的服务，因此需要调配符合要求的设备。然而如果要立即调配或是制造出那种能实现需求的设备，还要保证设备数量充足，这是一件相当困难的事。
        在这种情况下，重要的是要逐步进行事前验证。不要一开始就去构建大规模的系统，而是要采用小规模的原型系统来验证导入系统的效果。然后利用数台设备来进行比较选择，讨论应用方法。由此，物联网服务的系统开发要点也就出来了，即系统开发分为3 个阶段进行，它们分别是“验证假设”“系统开发”“应用维护”（图5.3）。

5.2.1 验证假设阶段

        此阶段进行的是效果验证和技术验证，效果验证通过构建小规模的原型和导入服务来验证，技术验证的目的则是实现物联网服务。前者利用物联网设备感测到的数据，分析创造出的信息是否拥有与成本相符的价值。除此之外，通过让使用者使用原型系统，还能探讨使用情景等需求。
        技术验证则针对的是构成物联网服务的服务器和设备，尤其对于设备，一定要事先仔细验证。因为物联网服务的主体是由设备进行的感测和反馈，如果设备无法完成目标动作，那么系统本身也就不能成立。因此在验证假设阶段需要谨慎地选择传感器终端等设备。我们将此阶段的实施要点归纳为以下几点。

5.2.2 系统开发阶段

        下面进入服务开发环节，此环节也是真正意义上面向导入的环节。
        此阶段基于验证假设环节的原型开发和验证结果来调配在实际环境中将要用到的设备，以及进行服务器端系统的开发。特别是，在使用服务的过程中很有可能要追加设备和设置地点，或是涉及获取数据的存储容量和存储时间等数据使用方面的内容，所以非常有必要跟多个利益相关方进行磋商。如果要把在事先验证阶段构建的原型按原样扩大，那么就需要在事先验证阶段就预见原型在实际环境下的运行，确保系统的品质，设计出一个易于追加设备的系统。

5.2.3 维护应用阶段

        在物联网服务的应用中，除了信息系统，还要运用并管理设置设备和网关终端。
        如下所示，在应用管理设备的过程中不仅要监测和修复设备异常，还要根据设备的运行情况更改设备设置参数、修理或更换设备，以及追加新设备等。

        ● 监测设备的状态、变更设置、修理或更换设备
        ● 追加新设备
        ● 监测系统状态
        ● 运用积累的数据
        ● 采集和应用数据

5.3 物联网服务的系统开发案例

        下面来看一下物联网系统的开发案例。

5.3.1 楼层环境监控系统

系统概要

        首先要为大家介绍的是旨在提升以办公室为主的职场环境的舒适度，对楼层环境进行监控的系统（图5.4）。众所周知，职场环境变得舒适，那么工作效率也会提升。职场环境包含人际关系和劳动时间等各种各样的因素，不过这里我们撇开那些不谈，只看看从环境卫生的角度来实施监控的系统。

        在房间里设置无线环境传感器，实时采集数据，并将测量数据可视化，这就是监控负责的内容。可视化会成为我们根据测量结果来作出判断的依据，如在Web 页面上显示数据，根据测量状况控制LED 照明。具体的监控内容如下所示。

        ● 测量楼层内的温度以调整空调设置
        ● 测量不适指数以预防流感
        ● 测量二氧化碳浓度以防止注意力下降
        ● 测量厕所单间门口的排队状况以削减排队上厕所的时间

测量楼层内的温度以调整空调设置

        办公室的空调温度夏天最好设置为28℃，冬天则设置在22℃为宜。然而即使设置在28℃，实际上有时室温也会超过28℃而让人感觉到热，另外室温也会根据座位的位置而有所不同，因此需要定量测量楼层环境的室温，将测量结果可视化。

测量不适指数以预防流感

        每年从深秋转入初冬这段时期，都是一个流感多发的时期，员工有可能会患上流感。因此需要根据温度和湿度计算出不适指数，由于这个指标与流感易感性之间有联系，所以可以运用它持续监控不适指数，一旦超过阈值就发出警报，并要求予以应对。

测量二氧化碳浓度以防止注意力下降

        从提升工作效率的观点来看，二氧化碳浓度和人的注意力之间也存在着一定的关系。据美国研究团队实验认定，二氧化碳浓度超过1000 ppm时人的思考能力就会下降，达到2500 ppm 时思考能力则会明显下降。此外，建筑物环境卫生管理基准也提倡房间内的二氧化碳浓度以不超过1000 ppm 为宜。因此我们用二氧化碳浓度传感器来监控了房间中二氧化碳的浓度。在楼层和房间这种密闭空间内，人会不断呼出二氧化碳，从而导致二氧化碳的浓度不断上升。由测量值可知，二氧化碳的浓度会根据办公室内的人数和换气设备的运行情况而产生变化（图5.5）。因此二氧化碳浓度偏高时，监控系统就会提醒人们注意换气。

测量厕所单间门口的排队状况以削减排队上厕所的时间

        就改善职场环境方面，这里搜集了一些意见，其中有人抱怨男厕所隔间要排很久队。停下工作（从座位上站起来）去上厕所时，如果所有厕所隔间都有人在用，就只能回到自己的座位上等会儿再去，这样就白跑了一趟。就白跑这一趟倒无所谓，不过要是连续多次在座位和厕所之间往返，那就不仅浪费了很多时间，还会让人感到压力很大。如果先用开关传感器来测量厕所的排队状态，再把厕所当前的排队状况反映到Web 上，同时相应控制LED 照明，这样一来，不用打开浏览器就能实时从视觉上感知当前的厕所排队状况。这个机制能节省在座位和厕所之间往返所浪费的时间，减轻往返所带来的压力。

系统结构

        本系统由环境传感器等无线设备、网关以及中心服务器构成（图5.6）。

        设备终端包括传感器终端、温湿度传感器终端、二氧化碳传感器终端、开关门传感器终端以及红外线传感器终端，驱动机器包括LED 照明。网关终端采集了各传感器终端的数据，同时具备控制LED 照明的功能。
        中心服务器由以下部分构成：消息队列，负责接收从网关发来的传感器数据；流处理部分，负责分解和处理接收到的数据；数据库，负责积累数据。虽然业务应用程序已经跟数据库实现了协作，但要做到用Web 页面实时显示，还需要用第2 章介绍的Publish/Subscribe 来连接数据库。此外，流处理阶段会把各个功能模块化，监控传感器数据，在一定条件下发出邮件通知等。

5.3.2 节能监控系统

系统概要

        接下来要介绍是对形形色色的设备进行节能状态监控的系统，其目的在于实现商业设施和办公室节能（图5.7）。

        本系统除了以办公室为对象设置了各种环境传感器，为实现各个设施的节能状况可视
化，并达到节能目的，还实施了改善措施。例如，在商业设施里的各种场所设置传感器，测量楼层内局部区域的温度、湿度、电力。基于测量的数据，可以提早发现楼层内是否过冷或过热，同时还能通过耗电状况可视化及其对策来实现节能目的。另外，还会在办公室里测算楼层停留人数，并根据人数进行空调控制和换气控制，以达到最舒适的状态。此外，为了横向分析各处的测算数据，本系统还在不断地将传感器数据采集到云端的服务器环境上。本系统还能在用户系统上对已采集的传感器数据加以分析，实现每处设施的耗电量可视化，提醒办公室员工注意，以及远程自动控制空调机。

系统结构

        本系统同5.3.1 节介绍的楼层环境监控系统相同，都是由各种环境传感器终端，以及采集这些终端的网关，还有中心服务器构成的（图5.8）。

        传感器终端方面使用了温度传感器终端、二氧化碳传感器终端，以及气压传感器和电力传感器。
        中心服务器由负责接收数据的数据接收部位，负责处理接收到的数据的处理部位，以及存储数据的数据库构成。就接收部位而言，网关终端到服务器之间的通信协议采用了HTTP 和Socket 等多种协议，一边吸收这些协议彼此之间的差异，一边与后续的数据处理部位协作。另外本系统从中心服务器处采集数据，并对设备发送控制命令，而已采集数据的分析则在用户服务器的系统上进行。因此就要经由一道手续（即应用程序编程接口，Application Programming Interface，API）来获取数据，进行控制，以实现系统之间的协作。
        应用管理方面，因为在本系统中，设备和网关设置在离管理者较远的位置，所以使用了远程设备管理功能。借助此功能，管理者不必赶到现场，就能在发生故障时确认网关的设置数值和日志信息，进行软件更新。

5.4   物联网服务开发的重点

        本节将基于以往的开发和应用经验，就物联网服务特有的开发重点从5 个角度进行说明，这5 个角度分别是：设备、架构、网络、安全性、应用与维修。

5.4.1 设备

设备的选择

        在物联网服务中，设备的选择是至关重要的。根据设备的特征不同，有做得到也有做不到的事，所以事先一定要切实明确目的，选择能够帮助我们达成目的的设备。

传感器的特征

        这里举之前楼层环境监控系统检测厕所隔间使用状态的例子。这个系统能实时检测出厕所使用状况，通过数间厕所使用的比例控制LED的颜色。因此，我们选取了一些能获取房间使用状况的传感器，并研究和比较了每种传感器的检测特性、环境特性、成本特性（表5.1）。

        然后，我们从各种传感器中选择了距离、开关门、运动（人体感知）这3 种传感器，它们实时性强、简单又便宜。我们采用这3 种传感器进行了试验，结果表明：人在厕所内的动作出乎意料地少，所以运动（人体感知）传感器检出率低，又因为距离传感器只能测量点，所以很难选择设置场所。至于开关门传感器，它会在无人使用厕所时准确地开启厕所门，在有人使用厕所时关闭厕所门，能够实时且精确地检测出厕所当前的使用状况，所以最终我们决定使用开关门传感器。
        在要购买或调配传感器终端时，除了需要选择用什么传感器来检测，同时还要选择装有传感器的传感器终端。选择传感器终端时需要讨论的方面大都列在表5.2 中了。尤其是从系统开发的角度来说，人们一般会基于设置和应用，围绕通电模式（交流电源或电池驱动、更换频率）、数据获取方法和可扩展性来进行选择。

        就这里的案例而言，为了能把传感器终端设置在厕所门上，又基于无线接口和应用方面的考虑，我们选择了带有自主电源的传感器终端。另外，这种传感器终端具备可扩展性，当对象数量增加时，可以轻松进行追加。而且除了开关门传感器，还具有温湿度传感器和红外线传感器等阵容，这种应用的灵活性也是其一大优势。

测量误差

        在使用传感器终端时，需要在理解传感器使用的测量方法的基础上，留意传感器的测量误差和错误判断。
        例如在查看温度传感器终端的说明书时，环境规格和测量规格一栏里写着：“周边温度：－10℃ ～+ 80℃；测量范围：－10℃ ～+ 80℃；测量精确度：±0.5℃。”也就是说用这台传感器终端测定为25℃时，实际温度则在24.5℃到25.5℃之间。因此在应用程序上使用测量得到的温度数据时，要时刻提醒自己，这个数据存在测量误差。
        除了前面提到的传感器，人体感知传感器也可以检测出人的存在，但并不是在任何状态下都能够检测成功。像无源型红外线传感器等是通过红外线来感知的，当感知范围内有与周边温度不同的物体运动时，传感器就会启动（图5.9）。因此，在感知范围内，如果产生热量（红外线）的物体（人或动物）不运动，或是物体的动作太细微，无法传达到感知轴时，传感器就无法检测出物体的存在。

        因为每种传感器的检测机制都不同，所以大家不仅要选择传感器终端，还需要掌握传感器终端内组装的传感器的机制，检查其是否能成功对测量对象进行测量。

法律制约

        还有一点很重要，即确认使用的终端是否符合《中华人民共和国无线电管理条例》的规定。中国制定了《中华人民共和国无线电管理条例》用来防止有人干扰和妨碍无线通信，以及确保无线电波的高效利用。
        一般情况下，如果购买了一台传感器终端，而且这台终端已经装有取得认证的无线机器，那么这台终端内部的无线机器上就会带有技合标志。可以通过向制造商咨询认证信息，或是利用那些已经获得过国家的符合标准证明书认证的机器的搜索站点，来确认使用的机器是否已经取得了认证（图5.10）。但是无线电波相关的认证制度非常复杂，有时候需要对于连接通信线路的机器进行技术标准认证，或者需要获取无线局的许可证才可以使用。所以，大家若是有不明白的地方，还是咨询专业机构为好。现在有一个动向，那就是促使那些没有技合标志的机器也能在满足一定条件的情况下为大家所用，但是这只是一个动向，所以目前还是需要大家注意的。

设备的设置 

        因为物联网系统需要在各种各样的场所设置小型设备，所以设置时还需要留意设置场所。在此就来讲解一下设置设备时需要注意的内容，即设计配置、设置场所以及设置环境。

设计配置

        通过改变设备和网关终端的配置设计，可以节省导入费用和应用成本。网关终端具有高性能，并配备多种多样的功能（如连接运营商网络的功能等），因此大多数情况下价格要比传感器终端昂贵。除此之外，从应用方面来考虑，连接到服务器端系统的终端越多，系统在管理上就更费事儿。
        因此，一般来说设计配置时都要尽量用传感器终端构成的传感器网络来采集传感器终端，同时尽力减少网关终端的数量（图5.11）。但是传感器终端输出的无线电波较弱，在开阔无障碍的地方信号就比较好，而在房间和走廊之间这种存在铁门的地方信号就难以通过。这种情况下就需要采用分割传感器网络来增加网关终端的方法。另外，在设计配置时要好好熟悉楼层地图，事先整理好设备信息和设备位置信息。

设置场所

        还需要注意的一点就是设置设备终端的场所。因为传感器终端体积较小，且容易携带，何况还设置在系统管理者看不到的一些地方（如较为偏僻的房间等），所以如果放在人能轻易接触到的地方就有可能被偷走。
        可以预想到以下情况：原本设置在房间里的温湿度传感器终端因楼层的更换（搬家）而被人拿走，进而失去了下落，或者安装在厕所隔间里的开关门传感器被人取下来拿走，等等。一旦被人拿走就不容易找回来了，所以大家还是尽量把传感器设置在一般情况下他人无法接触到的地方。

设置环境

        一般的传感器终端都设置在室内楼层环境中，几乎不会有环境方面的问题，然而如果要利用感测来进行食品等的温度管理，可能就需要在冷库等气温极低的场所设置传感器终端了。为此，还需要事先确认所使用的传感器终端，检查该终端的应用环境和测量范围。

参数设置

        设备参数设置也会影响维修的难易度，因此需要引起注意。

感测间隔

        传感器终端的数据获取间隔越短，能够采集到的数据也就越多。因此从使用传感器终端的立场出发，人们往往会把感测间隔设置得较短。然而需要大家注意的是，感测间隔和数据的发送频率还会影响维修的频率。
        为了能在各种场所大批量设置，大体上物联网设备都遵循着小型、无线通信、电池驱动的原则。近年来也不断涌现出一批新型终端，例如“能量采集”（energy harvesting），这种终端具备自主电源，能实现设备自身发电。然而仍旧有大部分物联网设备是靠电池驱动的。从耗电的角度来看，设备电池电量大部分都消耗在感测和无线发送数据上（图5.12）。感测频率越高，耗电也就越严重，这样一来更换电池的频率就会加快。因此各位需要考虑到更换电池的频率，根据各种条件设计一个合适的感测及发送周期。

传感器网络的设置

        使用传感器终端的传感器网络时，需要规定让传感器网络运行的参数。
        这里需要注意传感器网络的网络ID，也有人称其为组ID 或者采用其他叫法，不过这些叫法指的都是专门识别传感器网络的ID。只要把所有的网络ID 都设成相同值，就能够减少初期导入或是追加和更换终端时的设置成本。然而如果存在数台具备接收器的网关终端，这些接收器就会接收到同样的数据，其结果就是传感器端的数据会重复（图5.13）。这种时候就需要采取一些应对措施，例如白名单方式，即在网关终端内读取传感器ID，只接收那些在允许接收名单里的传感器数据。

 

        如果给每个网关终端都分别设置一个ID，虽然可以避免数据重复，但每导入一次，就要设置一次传感器终端，很费时间，而且还需要管理这些ID。
        此外，刚才提到的楼层监控案例是把前面说的两种方法组合起来进行管理的，即给每个网关终端设置不同的网络ID，同时再通过设置白名单来防止非法访问。

5.4.2 处理方式设计

        应用和维护物联网系统时，如果系统中有设备，那么往往会面对一些状况，例如新设备追加、数据量增多、无线干扰等。如果在系统开发初期不对这些状况加以考虑就进行设计，一旦遇上情况就难以扩展设备，事情就会变得非常棘手。因此，这里将基于物联网系统的实际应用状况，为大家说明事先应该掌握的处理方式。

        ●如何连接多种多样的设备
        ●如何处理负载，应对容量增加
        ●分散功能
        ●提高系统结构的牢固性

如何连接多种多样的设备

        就像前文中提到的那样，为了增加测量点或是从其他观点进行分析，会有种类繁多的设备在应用物联网系统期间连接到物联网系统。其中不仅包括现有的设备，还包括一些跟原有设备的格式完全不同的新设备。此外，在连接形式方面有通过网关连接的方式，也有通过服务器连接的方式，但每个连接形式对应的可扩展部分都是不同的（图5.14）。

        那么如何才能实现连接多种设备呢？处理的重点包括“分层化数据处理”及“在设备附近进行设备的相关处理”（图5.15）。

        具体来说就是在移交主处理时指定格式，并在上一轮处理中把接收到的数据转换成规定的数据格式。这样一来追加设备种类时就能不牵扯到共同处理的部分，只单独扩展和开发与设备相关的部分即可。
        打个比方，假设我们需要往网关上追加连接一个新的传感器终端，此时我们不用扩展服务器上的接收和处理部分，只要在网关上识别新传感器的格式就能够进行存储处理和感知处理。如果服务器端也在追加格式时进行了扩展开发，那么服务器端就会进行回归测试，原本正常运行的数据处理进程也可能发生故障。

如何应对接收数据量的增多

        由于很多设备会连接到物联网服务的系统，所以通信量可能会增大。当发生终端数量增多、感测间隔变更这种情况时，不仅要在服务器方面做一些改善（例如改善传感器终端的电池寿命，保证网关终端的性能），还要在服务器端的系统上做一些处理，以应对那些增多的接收数据。

讨论接受和处理数据的方式

        有一个方法能应付接收数据量的增多，就是把接收数据放入队列里。
        如果在接收数据的处理完成前，网关和接收服务器都一直连接着，那么由于连接时间长，到达的数据量就会增多或是处理就需要花费一定时间，连接的空间就会不足，也会处理不完接收数据。这种时候就不要在接收数据的处理完成后再向网关返回响应，而要在接收数据并将其放入队列时返回响应，这样一来就能处理大量的接收数据了（图5.16）。那些存入队列的接收数据会在之后被处理服务器从队列中取出来进行处理。

        这个方法的优点包括可以缩短网关端的等待时间，增多能够处理的接收数据量。此外，处理部分中间又多了一道队列工序，因此接收功能和处理功能的模块性也得到了提升。这样就便于根据队列的容量增强处理服务器。
        这个方法的缺点就是确认处理成功与否时需要再次进行访问。即使接收数据出错，处理服务器端处理失败，网关端也不会收到失败信息，因此就需要讨论再次发送等办法。

数据库的选择

        因为数据库负责积累接收到的数据，所以接收数据量增多意味着我们还需要在数据库方面有所应对。具体来说就是提升数据库积累处理大量数据的性能，确保用于积累数据的数据库容量。
        然而，物联网服务连接着大量设备，我们很难明确其极限所在。再说，用一台服务器处理，处理性能和容量方面也有限制。因此物联网服务的数据库在一般情况下（根据条件不同也会有所差异），需要具备可扩展性（易于向外扩展）、写入速度以及数据库模式的通用性。最后说的数据库模式的通用性用于应对以下情况：在存储多种设备的不同数据时，非结构化数据无法全部存入一开始设计的方案。
        第2 章也介绍过数据库。数据库的类型多种多样，有RDB、KVS、文档型数据库、图形数据库等，它们各自有着不同的特征。其中主流的数据库有RDB 和分布式KVS，下面将通常会被比较的项目总结在了表5.3 中。

        为了保证表连接和ACID 特性，RDB 不易向多个服务器扩展。而就KVS 而言，只要在处理性能和容量不足的情况下追加服务器就能向外扩展。因此物联网服务和传感器网络系统多采用KVS。
        但是分布式KVS 也有缺点。首先它不能使用关系，无法通过SQL进行复杂的连接和采集。因此需要在应用程序端取出数据，进行连接和加工处理。另外也要在应用程序端来实现一致性处理。 
        因此，建议大家不要胡乱采用KVS，只在需要利用到KVS 的两个大特征，即“可扩展性”和“高性能”时再去考虑采用它。就笔者的经验来看，在下述这些情况下采用RDB 处理起来会更方便。

        ●物联网服务处于初期验证阶段，或者整体规模较小时
        ●想结构化地存储接收数据时
        ●能够支持 RDB的设计和应用设计时

        除此之外，也有一些将RDB 和KVS 混合应用的案例，例如利用RDB来处理管理类的信息，利用分布式KVS 来作为专门积累采集到的数据的数据库。

数据库的应用

        一旦接收到的数据量增多，负责积累数据的存储空间容量也就需要相应增大。此时大家需要注意从应用程序访问数据库的时间的增加。如果积累的数据量不多，那么获取数据的时间和查找速度都不会有问题，但是如果积累的数据量变多，那么还可能会产生数据库访问速度变慢，应用程序变卡等问题（图5.17）。

分散功能

        开发物联网系统时，多数情况下要把所有感测数据发送到中心，在中心内进行分析判断，把所有执行命令的功能采集到服务器。但是如果换成大规模的物联网系统，连接的终端数量可至上万，在服务器进行接收处理可能会来不及。
        这种情况就需要像前面说的那样，在接收处理上下些工夫，还有就是把功能分散给设备及网关（图5.18）。

        特别是在下述情况下，建议大家考虑分散功能。

        ● 每台设备要感测的数据量较多
        ● 需要实时响应

        有些时候，即便传感器终端能够在10 秒钟内获取1 个数据，但从业务应用程序的角度来看，只要每10 分钟更新1 次数据就够了。也就是说，如果持续向服务器发送不用的甚至是无用的数据，就会白白浪费线路成本和存储空间。因此重要的不是用服务器端接收所有数据，而是要在网关终端上下工夫，例如以下这些情况。

        ●通过过滤来监控数据，只发送异常数据
        ●通过初步分析只发送分析结果

        这样一来不仅能减轻服务器端的负荷，还能提升采集数据的效率。
        此外，在进行实时控制时，如果在服务器端一并进行控制，就可能因为网关与服务器之间的4G/5G/LTE 线路不稳而导致控制缓慢甚至失败。因此一般来说最好不要在服务器端执行琐碎的控制命令，而要尽量在控制对象的附近执行运行判断和控制。前面介绍的楼层监控系统中的LED 照明控制的部分就采取了这种分散功能的方式，用开关门传感器信息在网关上判断情况，执行对照明的实时控制，并把总结数据注册到服务器。
        除此之外，人们也在不断推进关于分散功能的研究与开发，目前开发出的技术包括把模块化的功能动态配置在服务器和网关上等。但是这个分散功能的架构并不一定适用于所有情况，重要的是迎合系统需求来选择最适合的架构。

提高系统结构的牢固性

        因为物联网系统大多用于无线通信，所以数据的可达性会降低。使用无线通信就意味着一旦通信路径上设置有墙壁和大楼等障碍物，无线电波就可能会受到妨碍，通信也就有可能会连不上，没准还会和周围的无线电波互相干扰从而导致线路不稳。
        此外，有时候也会为了通过传感器网络来简化设置和管理，而让传感器网络的所有分组一致。这样一来如果设置了两台接收器，那么其中一台接收器就会接收从另一台传感器终端发出的传感器数据，并另行发送给传感器服务器，这样一来，同一时间在服务器上接收到的数据就会重复。因此非常有必要用传感器终端、网关终端，以及服务器上的应用程序来提高系统结构的牢固性（图5.19）。同时应该避免以下这样的设计：等收到传感器数据后再运行，或是测量的传感器数据重复时就不运行等。

        特别是在驱动时要多加注意，如果驱动器只会按照外部发来的指令运行，那么一旦无线通信中断，驱动器就会一直维持着上次运行结束时的状态。举个例子，假设通过控制LED 来反映人群的密度，当人群密度大时用红色表示，人逐渐减少后就用蓝色表示。但是由于无线电波状态的恶化，当驱动器接不到让其切换成蓝色的命令时，LED 就会一直是红色，显示结果就会出现错误。除此之外，在控制机器人时，如果机器人接到了动作指令后却没有接到停止指令，那么它就会一直动下去。如果是小孩子拿来玩的机器人玩具也就一笑置之了，但要是大型机器人就可能会伤到人。因此打算使用这种通过通信来运行的驱动器前，要事先想到通信中断时会发生的状况，最好将其设计成执行完一条指令后就恢复原状，或者是在信号中断时有一个固定的动作（例如关闭LED，停止机器人的电机等）。
        另外，就远程控制而言，发出动作指令的一方基本没法知晓这个动作是否真的被执行了，所以设计时要考虑到如何向指令方传达动作执行结束的信息，或是如何用其他传感器来获取动作执行完毕的信息等。

5.4.3 网络

提升通信效率

        随着物联网系统的导入，通信成本也成为肉眼可见的数字被拿上了台面。通信成本主要来源于使用运营商线路时的线路费用，这跟参加的套餐也有关系，不过总归是用得越多费用也就越多的。而且只要系统在运行，就会不断产生费用。设置地点（网关的数量）越多，通信成本也就越大。因此就需要研究在从网关向服务器发送数据时，如何控制每个设置地点的通信量。

压缩数据

        我们可以先把要从网关终端发送到中心服务器的那些传感器数据暂时积累在网关终端上，再把这些数据一并压缩，从而削减通信量。尤其是在连接到网关终端的设备数量较多，或是传感器终端发送数据的时间间隔较短的情况下，要采集的数据量会增多，比起接收一次数据就发送给服务器一次来说，采用压缩数据的方法更能大幅度地削减发送的数据量（图5.20）。

        另外，通过延长上传传感器数据的时间间隔，可以增加每个压缩数据中包含的传感器数据的数量，这样一来就会比把数据先分割后再压缩并发送更有效率，能更高效地把数据上传到中心服务器。
        当然，这种方法并不适用于需要实时分析的“可视化”情况，也不适用于要进行机器控制的系统。不过对于那些要先采集传感器数据后才进行分析的，实时性较弱的系统来说，这种方法不失为一个有效的手段。

选择协议

        通过选择网关和服务器之间的通信协议，可以减轻给网关和服务器带来的负担，实现轻型通信，起到抑制通信量的作用。
        比如我们来比较一下第2 章讲过的HTTP 和MQTT，HTTP 协议的首部（header）比较大，而且每次发送数据都要发送一个数据包来连接/断开TCP，因此发送的数据越多，数据总通信量也就越大（图5.21）。而MQTT 的首部比较小，还能在维持TCP 连接的同时，进行下一次数据的收发，所以比起HTTP，它更能抑制数据总通信量。

        除此之外，在使用MQTT 时还要注意一点，即应该一边维持MQTT的TCP 连接，一边进行数据的发送和接收。因为MQTT 是通过维持TCP 连接来削减通信量的，所以要是每次进行数据通信都断开TCP 连接，MQTT 就会跟HTTP 一样在每次发送数据时都执行连接和断开处理，结果反而会增加通信量。

5.4.4 安全性

安全性设计

        随着物联网的普及，人们开始担心能否保证其安全性。就物联网服务来说，有各种各样的设备要连接到网络，因此也就大大增加了遭到外部攻击的风险，比如联网的监控摄像头被黑导致影像被盗，或是系统被当成攻击其他系统的垫脚石等，诸如此类的事例皆有发生。国外还有过组装汽车的控制系统因感染病毒而瘫痪的事例。
        在开发物联网服务系统的初始阶段，开发者们为了验证效果，容易把精力放在操作的实现上，而忽视安全性问题。后来再想要实施安全措施的时候，就会发生成本方面的问题所导致的措施做得不到位的情况。而且设备原本在封闭的环境下运行，一旦把这样的设备连接到网络，就会面临想象不到的安全风险。因此为了提高物联网服务的安全品质，大家需要从设计阶段就着手推进安全性设计。

风险分析

        安全性设计的第一步是风险分析。关于风险分析的详细内容，相关的专业书都有提到，这里就不再赘述。大家只要明白风险分析中要做的就是明确要守护的资产和会存在的威胁，根据不同的威胁来决定什么更重要，以及要先做什么。

多层防御

        在风险分析之后，就该针对预想到的威胁讨论安全性对策了。这个时候的重点就是多层防御这一思路（图5.22）。
        多层防御指的是在多个层面执行安全性对策，即使一个层面被破坏了，也能在别的层面上守住。例如给主机安装最新版本的补丁以预防漏洞，这样即使防火墙被侵入了，也能降低主机被人占据的风险，即使有人通过非法访问盗走了文件，也能通过加密手段让对方无法读取文件内容，如此一来，我们就能从整体上提升安全性。

        多层防御不仅是一种针对应用程序和操作系统等软件的对策，在进行安全性设计时它还包含上锁管理和应用方针等物理层面和人为层面的措施。在物联网系统中，系统分散在设备端和中心端，而且设备端通常在管理者平时接触不到的地方运行，因此就需要按照多层防御的思路从设备端和中心端以及它们的交汇点来提高安全品质。
        下面我们将按照下列各项要素，来说明物联网系统独有的安全对策。

        ● 保护设备
        ● 保护服务器端系统
        ● 保护所采集数据的隐私

保护设备

        在设备管理方面，因为多数设备都放在管理者平时接触不到的地方，所以基本上会采用提高设备自身安全品质的方法。
        管理互联网网关终端时，有一个地方尤其需要注意。因为是通过互联网网关与物联网系统进行通信，所以网关终端可能会存有传感器的认证信息或应用程序的信息等。在设备安全方面，从预防、检测和应用的角度出发，可以采用以下的安全性对策。

预防

        从物理性对策的角度来说，为了预防盗窃以及第三者进行物理访问，首先应该研究设备的设置场所。因为设备体积小，容易携带，所以被偷窃的危险性很高，可是又很难一台台地去检测设备有没有被偷走。因此需要尽量把设备设置在只有管理者才能接触到的地方。
        从设备内部对策的角度来说，想对付外部来的攻击，就得停止不需要的服务，执行防火墙设置，用白名单的形式只允许那些我们所需的通信。近年来出现了很多以Linux 为基础的网关设备，这些产品开发简单，但相对地也就能轻易地给这些产品安装任意的软件。这样一来开发者可能会自行装入测试工具，在不知不觉中就启动了不需要的服务。只是在验证时启动FTP 和SSH 也就算了，万一这些服务被公开给外界了，那么就会非常危险。建议大家还是确认一下，看看在正式环境下是否是只启动了所需的服务。
        除此之外，为了不让人简简单单就能登录上终端，最好通过ID 或密码等方式进行登录认证。

检测

        万一发生了非法访问或是数据遭到他人篡改，我们就需要对这些情况进行检测。关于非法访问的检测，大家可以通过检测来自外部网络的通信来发现非法访问或疑似攻击的通信，从而发出警报。
        关于数据篡改方面有一个具体的解决办法，即信任传递（transitivetrust）。这个方法就是在接通机器电源后对机器进行确认，确认机器是否按照设计者设想的状态而运行。从最值得信赖的起点开始，按照“BIOS →引导加载程序→操作系统→应用程序”的传递顺序来测量组件，进行有效性认证。

应用

        人们每天都会发现软件内部隐藏的漏洞。也就是说，即使发布了一个在安全性对策上面面俱到的设备终端，其安全品质也会日益低下。
        例如在2014 年4 月，密码库OpenSSL 就被黑客挖出了一个软件漏洞。凡是使用OpenSSL 库的进程，其存储内容都存在被泄露的危险，好在人们迅速采取了措施。因此，定期修复漏洞来维持安全性品质就变得至关重要。此外，万一不小心泄露了登录用的ID 或密码，应该赶紧着手更改，为此需要事先确定更改ID 和密码的顺序。
        话虽这么讲，设备数量多，离得又远，一台一台地更新设备的软件和设备的设置是非常累人的，所以下面的5.4.5 节将讲解如何远程应用网关设备（图5.23）。

保护服务器系统

        要想保护服务器端系统，除了对一般的业务和信息系统实施安全性对策以外，还需要针对因连接设备而引发的安全风险来制定对策。在这里就为大家讲解一下物联网系统独有的安全性对策，即网关终端认证及数据流量控制。

网关设备的认证

        在互联网上公开服务时，系统有可能被系统管理对象以外的网关终端非法访问。即使使用了专用线路，用户也可能自己随意设置网关终端。这种情况下由于存在非法网关终端，会发生处理负载增大，黑客利用安全漏洞进行非法访问这类问题，这有可能会影响数据处理，导致无法正常处理来自其他正常网关终端的数据。
        对付这些问题就要采用网关设备认证的方法了。网关设备认证，即只允许在中心获得了认证的网关终端给中心发送数据，通过这种手段就能减少非法网关终端进行的访问，方法有很多，我们在这里举以下两种为例。

        ●使用中心端事先给出的 ID、密码及客户端证书认证
        ●利用动态方法，即由服务器端的管理者确认从网关发来的连接要求，在管理者已经确认连接要求的基础上再批准连接

        不过如果网关上存有服务器的连接认证信息，那么大家不但要对设备自身执行安全性对策，同时还要记得讨论认证信息的应用（图5.24）。

数据流量的检测和制约

        非法网关设备的连接，传感器终端发送周期的变更，以及传感器终端数量上的增加都可能导致服务器接收到的数据量急剧增多。当已认证的网关终端发来数据，而数据只能在中心端被接受及处理时，如果数据量增多，那么再继续进行处理就会导致负载增大，还可能对其他的数据处理产生影响。为了应对这种情况，人们想出了控制流量这种办法，即对接收的数据进行流量监测，如果出现流量异常的情况，就不继续接收数据（图5.25）。

保护所采集数据的隐私

        像温度信息和电力数据等这类传感器数据，单独来用意义不大，不过要是通过跟个人信息和测量位置挂钩，再进行数据分析，那么它们的存在意义就不仅仅是传感器数据这么简单了。
        举个例子，如果对家中的电量数据进行观测，就会发现人不在家的时候耗电量会下降，人在家时耗电量则会上升。这类数据一方面可以帮助看管高龄人士，但另一方面，也发生过盗贼仅凭一台传感器就判断出家里无人，从而实施盗窃的案例。因此，在构建物联网系统时需要保护所采集数据的隐私（图5.26）。

在信道上进行数据隐藏

        如果在通信路径上用明文（未加密的数据）进行通信，就会有可能被人偷看到通信的内容。特别是在网关至服务器之间，网关发送到中心的认证信息和传感器数据的内容都可能被第三者窃取，因此需要大家多加防范。
        为了防止数据从通信路径泄露，需要采用像SSLA 和IPsecB 这些对信道加密的技术，对应用程序间的数据通信加密，对信道本身加密。除此之外，还可以利用设备运营商（通信服务业者）提供的专用网络服务。

保护所感测数据的隐私

        有些情况下需要二次利用物联网服务测得的传感器数据，例如提供给分析人员，或是向外界公开等。但是就像刚才前文说的那样，传感器数据的泄露可能会造成隐私上的风险，因此在处理传感器数据时需要多加注意。
        人们正在不断研究和开发解决这类问题的技术，例如能够在加密状态下只获取那些得到允许的信息并对其加工和分析的技术，以及削减信息量以使无法识别出某个具体的人的匿名技术。

5.4.5 应用与维护

        物联网服务的应用和维护对象除了服务器上的系统以外，还包括设备和网关（表5.4）。应用方面包括监控设备和网关的连接状态和通信状态，以及设备自身的故障服务。维修方面则包括在系统发生故障时调查原因，以及增加设备种类的服务等。

        这里再强调一遍，由于物联网系统不仅由众多设备和网关等物理设备构成，还常常会有传感器网络和4G 线路等无线通信混入通信路径，所以容易发生设备类故障和通信干扰等系统故障。因此接下来我们将针对发生故障时需要重视的日志设计，以及如何高效率地应用远处的设备和网关来进行说明。

日志设计

        在检测到故障后的故障调查过程中，日志是必不可少的。这就需要从数据经过的设备、网关、服务器的各个构成要素中分别获取我们需要的每个主机操作系统和启动应用程序上的日志。如图5.27 所示，通过适当地输出日志，就能够顺利剖析故障，确定故障的位置和原因。

        特别是对于网关终端而言，由于它是服务器系统和传感器网络系统的分水岭，所以成为了一把用来剖析系统故障的重要的利刃。如果将已连接的物联网设备的信息、接收到的传感器数据、线路的无线电波信息，以及发送到中心服务器的传感器数据的状态信息等保存成日志，就能在发生故障时顺利确定故障原因，判断是传感器接收的问题，还是4G 线路连接的问题。
        另外大家还需要注意日志的输出容量。首先，网关中有些型号的磁盘容量可能会较小。这种情况下，如果日志的输出容量达到了日志文件的大小上限，旧日志就可能会消失。实际上运用物联网系统时，网关下属的感测设备也发生过如下故障：因为没有一个专用的结构来实时确认这么多设备的运行情况，所以常常是使用传感器数据时才发现很多异常问题，而这时候距故障发生已经过去了好些时日。这时候日志已经消失，要调查故障原因就非常费事了。
        接下来要说的是服务器。一般情况下只要进行传感器数据采集处理和设备的控制处理，各台服务器中就会输出日志。然而由于服务器端系统会接收到大量的传感器数据，所以每次处理时输出的日志体积都很大，眨眼间日志就溢出了。也有因设计问题而导致日志写入失败，从而应用程序停止的案例。因此在设计日志时，建议大家先考虑好物联网系统特有的日志容量和存储时间等因素。

设备及网关的远程应用 

        一个有效应用设备及网关的手段就是远程应用。就像我们前面说的那样，在调查故障发生的原因时需要确认网关设备的日志。此外在追加设备和升级固件时也需要在设备上进行操作，例如更改设置文件或者重启等。然而大多数情况下设备的设置场所和系统的应用场所都相距较远，赶到现场既花时间也耗费人力财力。而且就算赶到故障现场，设备也设置在一般人接触不到的地方，需要跟楼层负责人和设置人员协商日程，虽然修理本身很简单，但还是需要花费大量的成本。这样一来，在实际运用时就需要通过网络来实现对设备的远程管理功能（图5.28）。远程管理中包含远程设置参数、远程获取日志、远程上传应用及固件等功能。
        远程管理的标准协议包括TR-069 和OMA LightweightM2M（LWM2M）等协议。在这些标准协议中，那些远程管理设备时需要的功能决定着管理服务器和设备之间的通信手段的框架A。因为它是一个框架，所以实际上利用这些协议进行远程管理时，就需要用到安装了这个框架的中间件，再根据框架在设备和服务器上实现各项功能。

        打个比方，TR-069 使用SOAP 在设备与服务器间进行通信，定义的方法有获取能够利用的方法、获取及设置参数、重新启动以及上传等。要交换规定的通信，就要在利用中间件的基础上令某些部分（例如读取文件的具体路径，以及用于重新启动的命令等）依附于系统。

5.5   面向物联网服务的系统开发

        本章基于物联网系统开发的相关事例，解说了我们在物联网系统中使用设备时需要特别留意的地方。一方面物联网系统包含诸多设备，不实际尝试去开发和应用，就会出现很多令人费解的地方；另一方面，一旦发生了事故设备就会受牵连，但设备本身又设置得较远，所以有时问题就不好解决。本章涉及的内容如果能帮助大家通往物联网系统开发的成功之路，笔者将感到万分荣幸。
        最后来总结一下5.4 节解说过的物联网系统开发的要点，请见表5.5。为了方便大家在进行系统开发时查阅，我们分别对设备和整体系统的每个非功能性需求进行了整理。请大家在开发物联网系统时灵活应用此表格。