![]()
我们都必须面对挑战，尤其是来自物联网的挑战！本文旨在剖析物联网项目中需要关注的三大挑战：回归，测试和模拟。
作者 | Adam Dunkels
译者 | 苏本如，责编 | 郭芮
出品 | CSDN（ID：CSDNnews）
以下为译文：
在本文中，我们将详细介绍所有物联网平台都必须面对的三大基本问题。作为如何在现实环境中解决这些问题的一个实例，让我们看看Thingsquare物联网平台是如何解决这些问题的。
在存在大量设备的情况下，即使是正常情况下不太可能发生的问题，也有可能发生。
许多物联网的部署涉及到数百或数千个独立设备。在存在大量设备的情况下，即使是正常情况下不太可能发生的问题，也有可能发生。
大型网络在实地很难监控，而在其开发过程中更具挑战性。
在Thingsquare，当我们讨论物联网的开发时，我们根据规模将其分为如下几类：
开发者规模：1-2台设备。当你面前只有一个或两个无线设备时，理解它们的工作原理和过程就比较容易。你可以通过添加打印输出或让发光二极管闪烁来了解有些事情正在发生。作为一个开发人员，你会因此感到有信心，因为一切都在你的掌控之中。你甚至可以在其中一个设备上停止软件的执行，并单步执行程序。
桌面级规模：2-5台设备。在这个阶段，你不再能够单独控制每个设备，你必须把它们当作一个整体来对待。虽然他们的数量仍然少到能够让你监测，但是你将不得不使用像视觉闪烁的LED灯这样的辅助手段，让你能够看到这些设备上正在发生什么。
办公室规模：5-10台设备。现在你已经没有足够的空间把所有设备放在一张桌子上了，你必须把它们分散到一个有点难以监控的区域。用一个新的程序开始对它们进行编程是一个实际的挑战，因为你将不得不在物理上连接并断开每个设备和闪存编程器（flash programmer）的连接。
楼面级规模：10-100台。现在很难在一个办公室里找到容纳所有设备的空间了，你需要把它们分散在整个楼层上。这使得你很难直观地看到所有设备，所以，要想知道发生了什么，唯一的办法就是通过无线通信——除非每个设备都连接了有线信道，而这本身就是一项庞大的设置工作。此外，在这种规模下，硬件问题开始显现：因为硬件的质量并非总是那么可靠，在99%的成材率下，100台设备中可能会有一个或多个设备存在物理损坏。
部署级规模：100-500台设备。这种一种开发时很少考虑的规模，通常开发考虑的规模不超过100台设备。这种规模的原型测试和验证的POC(概念验证)过程和前一个类别没有什么不同之处。但在这种规模下，互联网连接问题开始对系统产生影响了。如果系统的某些部分与其他部分具有不同的连接（例如，某些部分使用WiFi连接，而其他部分使用3G连接），那么在系统的不同部分，情况将有所不同。
城市级规模：500-1000+台设备。在这种规模下，需要自动化工具来跟踪系统的行为。另外，即使所有设备都包含在一个网络中，一个简单的操作也需要大量的时间。例如，由于无线网络的物理速度，向所有设备发送一个ping消息可能需要几分钟的时间。
在Thingsquare，我们用来应对这些挑战的策略是：
模拟。模拟一切，从物理无线层到微处理器层，再到网络和设备的高级模拟。
测试床（Testbed）开发。每个功能都在一组测试床中开发，最大的测试床有100个节点。
轻量级崩溃报告。如果代码崩溃，设备将提供一个简短但有用的崩溃报告。
回归测试。代码中的每一个更改都要在模拟器中经过严格的自动化测试。
在处理一个大型系统时，人们对系统中正在发生的事情，几乎没有可见性。当处理物联网设备时，由于它们是无线的，并且没有太多存储和传输日志的能力，它们的可见性甚至更低。
模拟是解决这一问题的重要方法。我们在如下几个层面使用模拟：
无线网络模拟：我们模拟系统中的无线网络行为，从而可以在任何给定时间看到传输中发生的情况。
微处理器仿真：我们仿真运行代码的处理器，从而允许我们按比例测量功耗和执行时间。
功耗模拟：在我们的网络模拟器和微处理器的仿真器中，我们跟踪代码和通信的功耗，这样就不需要所有需要信息都从硬件上测量得到。
高级模拟：我们通过使用高级编程语言（主要是Javascript）实现对物联网设备行为的模拟，在物联网规模大到无法借助仿真或测试床来测试时，该语言可以帮助我们完成系统测试。
测试床开发
模拟是一个强大的工具，但它不能替代在实际硬件上的开发工作。有时你需要开发一个物理传感器或驱动器。这时候你需要和真正的硬件交互。但更重要的是，模拟器的行为方式与现实世界不同。如果你完全在模拟中开发你的解决方案，当面对现实的时候，它很有可能会崩溃。
在Thingsquare办公室，我们有一套规模越来越大的测试床，它包括：
两个测试床，各自带有10台和20台设备。
一个带有100台设备的测试床。
我们使用我们的测试床来开发新的功能，并不断测试我们的系统。我们可以使用它们来复制我们在客户部署中看到的行为。我们也可以在测试模式中使用它们来运行比我们办公室实际能够容纳的更大型的网络。
![]()
软件都有可能崩溃，尤其是在开发过程中。当软件崩溃时，崩溃报告可以帮助开发人员了解代码崩溃的位置和原因。对于低功耗物联网设备，想要在其上存储和传输完全崩溃时保存的内存数据，几乎不太可能。
在Thingsquare，我们使用一种轻量级技术从设备处收集崩溃报告：
对于上传到设备的每个构建好的代码，ELF二进制文件都会被存储适当的地方，并用该构建的git commit ID打上标记。
如果设备崩溃，崩溃时的程序计数器（亦即指令地址寄存器）将会存储在非易失性存储器中。
当设备在崩溃后重新启动时，发生崩溃时的代码commit ID和程序计数器会报告给后台。
这使得构建一个包含导致崩溃的内存地址和崩溃发生时的特定代码版本的数据库成为可能。有了这个数据库，开发人员就可以很方便地调查并确定导致崩溃的原因，然后解决问题。
回归测试是一种标准的软件开发技术，可以确保软件在开发过程中不会崩溃。
物联网平台由许多类型的组件（从后端软件到无线设备）组成。要执行回归测试，每个组件都需要进行各自的测试，同时也需要作为一个整体进行测试。
在Thingsquare，我们使用模拟器对系统所做的每一个更改执行全平台回归测试。在回归测试通过之后，我们再在测试床上测试系统。回归测试套件旨在捕获致命的错误，而这些错误可能会导致测试台无法工作。
![]()
物联网可能功能强大，但几乎没有什么设备像物联网设备那样功耗低！
物联网设备通常是无线设备，它们需要依靠普通电池或太阳能电池上提供电力来运行。这些电池提供的电力很弱，非常弱。功耗通常必须不高于电池的自发放电，将功耗降低到如此低水平既是一门科学，也是一门艺术。科学之处在于如何通过使用软件或硬件来测量和了解功耗。而艺术这处则在于了解如何充分利用此信息。
功耗既是硬件问题，也是软件问题。硬件需要进行正确的调校，并支持尽可能多地关闭组件。而软件赐需要知道关闭什么，何时关闭以及何时可以安全地这样做。
在物联网中，最棘手的部分通常是无线通信。无线电传送会消耗大量电能，但它至关重要，因此不能盲目关闭。无线电波在接收时消耗的功率与发送时消耗的功率相同。随着网络规模的扩大，这一点变得越来越重要。
在Thingsquare平台中，我们使用多种技术来解决功耗问题：
基于硬件的功耗测量：我们使用很棒的工具来测量硬件的功耗。
基于软件的功耗测量：每个节点都会跟踪功率消耗并定期报告。
寿命估算：基于测得的功耗数据，我们可以估算每个设备的寿命。
具有异常检测功能的功耗跟踪：在大型系统中，我们使用异常检测功能来查看是否有任何设备使用的功耗超出预期。
基于硬件的功耗测量
第一步是确定原始硬件的功耗。最好的方法之一就是使用一种叫做Otii的装置。我们不仅需要查找硬件中可能导致功耗增加的错误，而且还要确定硬件各个组件所消耗的基准功耗。
然而，测量一台设备的功耗并不能让我们看到整个网络的功耗。因此，我们需要进行持续的测量。
基于软件的功耗测量让我们能够连续跟踪每个设备的功耗。
因为软件可以完全控制硬件，所以我们只需要测量每个组件打开的时间就可以很好地估算总功耗。每个设备都会定期报告此数据。
因为我们现在可以跟踪每个设备的功耗，所以我们可以使用它来估算每个设备的寿命。
![]()
随着设备数量的增长，监视单个设备的功耗变得越来越困难。因此，我们需要引入自动化工具。
我们从每个设备上收集功耗数据，可以使用异常检测来突出显示具有异常高功耗的设备。这些设备需要仔细检查——因为它们可能存在导致高功耗的错误，如果我们在开发过程中能找到它，那么在我们部署解决方案时，它们就不会造成麻烦。
![]()
一旦我们找到了一个有问题的设备，我们就可以深入了解细节，并查看历史功耗。我们发现，在几个时间尺度上对功耗进行平均可以提供有用的信息：一小时的功耗平均值有助于发现在一天中重复出现的问题，而24小时的平均值则有助于发现每周重复出现的问题。
![]()
上图显示了一个设备的24小时平均功耗。显然这个设备在4月份的几天里耗电量出现性异常。
一旦我们发现了存在的问题，我们就可以更加深入地研究为什么会发生这种问题。如果我们不具备识别这种问题的能力，那么这种问题就不会被发现，然后它们就会悄悄进入生产环境。
理解无线通信的一种方法是把它想象成光一样：它会反射并以意想不到的方式被遮挡。无线覆盖可能在一个地方很好，但仅仅一步之遥就不行了。就像灯发出的光，即使在靠近灯的地方也可能被遮住一样。
如果有东西挡在无线信号传输的路上，无线信号传输可能就会阻塞。许多物联网解决方案部署的位置不可避免地会有物体移动。如果某个大的物体正好在通信路径上移动，那么该通信路径可能会被堵塞。
无线通信也受到其他无线通信的严重影响。不同的频率有不同的干扰量。2.4 GHz频段，包括了WiFi和蓝牙信号，是一个特别难进入的频段。这就是为什么许多设备使用其他频段（如亚GHz频段）进行通信。
在Thingsquare系统中，我们采取以下措施来应对这些挑战：
网状组网技术
网状组网技术是这样的一种技术：一个设备通过重复发送来自其他设备的消息，来帮助其他设备达到更远的距离。
这种技术并不要求每个设备都在接入点的范围之内，它允许设备伸展到更大的区域。同时它还允许网络自动绕过障碍物。
Thingsquare平台使用支持RPL网格路由协议的IPv6组网技术。所有节点都会不断地测量到其邻居接点的连接质量，如果发现质量更好的链接，则可以重新排列路由图。
网格的形成和维护过程是完全自动化的。因此，只需将扩展器放入网络，就可以将网络扩展出去。
跳频技术是一种可以避免在一个特定的无线信道上花费太多时间的方法。这是必需的，因为该信道可能被其他通信所占用。对于某些频率范围，跳频是一项监管要求，不能正确切换频道的设备将被禁止部署。
Thingsquare平台采用跳频技术，它既符合监管要求，又能在同一位置支持多个网络。每个网络都有自己的跃点调度，这使得网络之间的干扰尽可能少。独立的网络需要不同的安全密钥，但是保持通信频率的独立使系统更加高效。
物联网是一个重大的技术挑战，因为其庞大的部署规模，功耗需求和无线通信的使用。
幸运的是，通过使用物联网平台，你不需要直接面对这些挑战。因为这些问题应该已经被平台解决。
原文：https://dzone.com/articles/the-3-challenges-that-will-kill-your-iot-solution
热 文 推 荐
☞骗了马云 10 亿被骂 4 年后，院士王坚留下 4 条人生启示
☞你真的懂云计算吗？
☞万字长文回望2019：影响区块链行业发展的9大事件
![]()
点击阅读原文，参与十大趋势观点PK
微信扫码咨询专知VIP会员