物联网中基于云的软件更新的组件

更新受限边缘设备以及更强大的控制器和网关上的软件（组件）是大多数物联网场景中的常见要求。

拥有软件更新功能确保物联网安全 通过为物联网项目提供对抗潘多拉魔盒的机会，他们在设备连接的那一刻打开了 .从那一刻起，这些设备就处于 IT 安全威胁的最前沿，从历史上看，许多嵌入式软件开发人员从未遇到过这种威胁。如今，运送一个 Linux 驱动的网络连接设备，而在其生命周期内从未应用任何安全更新，这类似于自杀。

软件更新的一个更吸引人的论点是它们支持硬件和硬件相关组件的敏捷开发。诸如最小可行产品之类的概念可以应用于设备，因为并非所有功能都需要在制造时准备就绪。物联网解决方案云端方面的变化也可以在运行时应用于设备。

有时，软件更新本身就是一种商业模式，因为如果设备可更新，则对客户更具吸引力。换句话说，消费者知道他们不仅可以获得一组固定的功能，而且还可以期望从未来的产品更新中受益。此外，新的收入来源可能来自功能扩展（例如应用 ) 无需设计、制造和运送新设备（修订版）。

设备连接

将设备连接到云服务有多种选择。从架构的角度来看，必须决定设备是否应该直接连接 到软件更新服务或间接 通过设备连接层（例如 Bosch IoT Hub、AWS IoT、IBM Watson IoT、Azure IoT Hub 等），它本身也可以是 IoT 解决方案服务。我本人非常相信直接方法，我的产品 Bosch IoT Rollouts 实际上支持这两种方法。我将在下面解释原因。

让我们开始吧：直接连接将允许 IoT 解决方案分离关注点，除了 IoT 解决方案用于设备事件流和命令的自己的通道之外，还有不同的软件更新通道。

这是一种有趣的方法，原因有二：首先，如果您不必为其他渠道的所有业务需求而烦恼，它可以更轻松地保持软件更新渠道的 API 稳定 .我们不应忘记物联网中的某些场景，其中连接的设备可能会在不与后端接触的情况下长时间运行。在某些情况下，可能需要数年时间，尤其是在制造和初始连接之间。在这段时间内保持传输层稳定很容易，但对于业务层来说肯定不是这种情况。在物联网中尤其如此，其中许多云解决方案仍处于成熟的早期阶段。

其次，拥有单独的渠道还可以让您在设备本身上将业务和更新功能分开 .尤其是在复杂的堆栈中（例如在 IoT 网关上），您是否真的想冒着潜在损坏的堆栈必须自行更新以解决问题的风险？并且可以保证它总是能够做到这一点吗？想象一个场景，您的网关上有一个 OSGi 运行时，其中一个包会导致内存不足异常，并且您的软件更新客户端在同一个运行时中运行。预测结果可能非常困难。

然而，这种分离是有代价的：两个渠道通常意味着在设备端需要更多的实施工作，并且在某些情况下，它还可能会增加您的流量预算或电池寿命。

第二种选择是将用例组合在一个渠道中。我们称之为间接 与软件更新服务集成，因为云连接层实际上连接到设备，并且必须将解决方案与云中的更新流量分开。

这具有简化连接架构的巨大好处。它还允许利用通用设备管理协议标准（例如 LWM2M、OMA-DM、TR-069），这些标准通常仅将软件更新作为其标准的一部分。此外，它还允许使用由设备（制造商）本身定义的专有协议。

归根结底，物联网解决方案工程师必须做出选择：关注点分离与简单性。 通过我们的博世物联网部署，我们决定支持这两种选择，并且我们有客户同时使用这两种选择。事实证明，物联网解决方案的直接连接更容易维护，而间接连接则给整体架构增加了很多复杂性。

然而，大多数物联网工程师在项目后期的设计过程中都包含软件更新问题，因为在大多数情况下，它不是核心业务功能的一部分，当他们遇到它时，他们不想再做任何更改到他们的架构。因此，大多数解决方案采取间接方法，可能会在上线后遭受后果。

物联网中基于云的软件更新的第二个决定与协议有关。我应该使用标准的设备管理协议还是设计一个自定义的协议？如今，许多物联网解决方案都偏爱带有自定义协议的 MQTT。此外，市场上的许多物联网连接层还提供基于 HTTP、MQTT 或 AMQP 的专有协议。

我个人认为，有些标准是有价值的，至少应该考虑一下。 OMA-DM v2 看起来很有希望，我们也有一些 LWM2M 的经验。与往常一样，标准提供了一个很好的框架，但它们通常带有一组约束；尤其是在物联网项目的早期阶段，这会增加很多复杂性。但是，如果设备和软件更新服务都支持现成的软件更新，则涵盖软件更新的良好标准将允许物联网解决方案将软件更新作为一项功能，而无需编写一行代码。

最后但并非最不重要的是，还有设备身份验证的问题。当然，这是每个物联网解决方案的普遍问题。但特别是对于直接集成路径，必须选择是否可以将相同的身份验证机制用于软件更新和物联网解决方案渠道。我通常主张使用相同的机制。这实际上很容易通过非对称身份验证（例如 X.509 证书）实现。 Bosch IoT Rollouts 为其直接设备集成 API 以及物联网中通常使用的大多数连接层提供支持。如果非对称不是一种选择（受限制的嵌入式设备通常是这种情况），我建议您使用可供不同渠道使用的中央（对称）密钥存储。

如上所述，必须做出选择并回答问题。不幸的是，物联网还没有找到一种至少适合大多数场景的架构。然而，好消息是有多种选择并且它们有效。