在嵌入式开发中，执行关键任务功能的嵌入式 Linux 设备的 OTA 或无线更新对于通过部署安全补丁、功能更新和新服务来管理设备群至关重要。
在这篇文章中，我们将讨论为什么传统上更新嵌入式设备具有挑战性，以及为什么我们需要现代云技术(如适用于嵌入式的容器)来在需要时持续远程更新嵌入式 Linux 设备。
更新嵌入式 Linux 产品的挑战
当你更新嵌入式固件时，如果在更新过程中出现问题，嵌入式设备将面临“变砖”的风险。变砖的意思就是它听起来的样子，一种无用的设备，可能需要技术人员进行昂贵的更改才能使其再次工作。
为避免设备变砖，OTA 系统需要能够在部署更新时缓解以下任何问题：
间歇性网络连接 — 在嵌入式开发中，连接可能是间歇性的，也可能会有所不同。你可能正在通过 5G 连接运行更新，或者比这更慢。在某些情况下，连接可能不安全。如果你通过公共网络发送更新，情况尤其如此。
不可靠的电源 — 电源可能并不总是你可以控制的。对于客户不是企业的 CSP(通信服务提供商)来说尤其如此。许多消费类设备使用电池供电，即使不是，也不能保证设备所有者在任何特定时刻和部署过程中都不会错误地拔掉电源。你必须能够处理具有间歇性电源连接的设备。
处理遗留固件和软件的能力 — 嵌入式领域的产品寿命差异很大。像汽车这样的一些市场可以将相同的硬件保持五到十年，而对于家用电器来说可以是两倍。但在消费电子领域，产品寿命要短得多，从 6 个月到 12 个月。当你对应用程序进行现代化改造时，你需要能够同时维护旧软件。
偏远地区 — 如前所述，其中许多设备并不总是很容易访问。今天在野外的许多物联网设备已经存在了相当长的一段时间。例如，你是否考虑过你的恒温器或路由器是否正在运行最新更新?在嵌入式开发中，与手机等“始终开启、始终连接”类型的设备不同，许多物联网 (IoT) 位于无法访问的位置，网络连接不可靠。
为了管理上述情况并保持其中许多设备所需的极端弹性，OTA 部署系统必须能够始终将设备软件和固件恢复到“良好状态”。
单片嵌入式更新与模块化更新
更新嵌入式 Linux 并不总是一帆风顺。除了上述可能干扰更新的情况外，还有大多数嵌入式团队如何构建软件的问题。通常当需要更新时，开发人员必须更新软件包或应用程序，然后重建整个单体应用程序，然后再将其部署到嵌入式 Linux 设备。
但是通过容器化方法，嵌入式开发人员将软件堆栈更容易作为组件进行管理。容器是指满足开放标准但专为嵌入式 Linux 设备设计的容器，这些设备通常以低规格运行且资源最少。构成物联网的大多数嵌入式 Linux 设备都无法运行 Docker 引擎，因为它非常占用资源。
发表评论 取消回复