================== 项目规划 ================== 请注意到这里的大多数项目都是建议。 有一些想法来自于我跟客户的沟通，另一些想法是我自己的想法。 没有计划何时实现这些特性——这取决于是否引起了足够的兴趣， 以及是否会为项目提供补丁或提供资金来开发特性。 再次感谢所有支持我工作到现在的伙伴，以及所有为这个项目 做出贡献的人，让我把SWUpdate带到现在的状态! 主要目标 ========= 第一个目标是获得大量受众，使SWUpdate适合于大量的产品。 这将有助于围绕项目本身建立一个社区。 SWUpdate作为更新网关 =========================== 这个特性是通过 "swuforward" 处理程序引入的。如果每个设备都运行SWUpdate， 那么已经可以更新一个设备树。这个特性已经在针对嵌入式linux的SWUpdate中实现。 尽管如此，许多嵌入式设备都有小型处理器，可能还没有完全成熟的操作系统。 要确保所有设备的安全性是比较有风险的，如果只是在单一设备上则更容易确保。 如果运行SWUpdate的设备充当网关，它可以将协议从后端转换并将包更新发送 到连接的小设备。 一个例子是，如果SWUpdate以MQTT-broker的形式运行，并从Hawkbit获取更新。 SWUpdate应该能够运行suricatta的多个实例来实现这一点。 另一个例子是使用LWM2M。网关应该具有足够的通用性，以便将来能够添加更多的协议。 二进制差分更新 ==================== 进行完整更新可能会占用大量的流量。特别是在低带宽连接的情况下，引入增量 二进制更新的方法可能会很有意义。 邮件列表上已经讨论了好几次了。如果需要引入二进制增量，则严格要求不降低 更新的可靠性，不引入泄漏，不能使系统更加脆弱。 一种可接受的做法是添加不同的技术，每个技术都只处理增量更新的特定用例。 集成到Linxu发行版 =========================== 为了便于学习SWUpdate，也为了使用SWU转发器处理程序进行测试， 有必要为PC Linux发行版打包SWUpdate。 SWUpdate已经支持debian软件包。让包合并到Debian发行版中需要来自社区的一些帮助。 处理程序: ========= 新的处理程序 ------------ 用户们开发自己的自定义处理程序 - 我只是执行并鼓励每个人发送它们， 并讨论如何在主线中集成自定义处理程序。 引入了用于更新经由UART连接的微处理器的处理程序。 可以对其进行增强，以支持其他接口(例如SPI)。 一些新的处理程序的想法: - 用于更新微控制器的处理程序 - 用于更新带Flash的FPGA的FPGA更新程序 - 安装软件包的软件包处理程序(ipk, deb) 可以将包插入到SWU中，原子性由SWUpdate保证 - 如有可能，应将Lua处理程序添加到项目中以演示如何解决自定义安装。 Flash处理程序 ------------- 裸设备的flash处理程序(主要是NOR flash)不允许流式镜像， 如果设置了 "installed-directly"，就会报错。 该处理程序可以扩展到流式镜像。 在运行时将处理程序作为插件安装 ----------------------------------------- 该项目支持Lua作为脚本语言用于安装前和安装后脚本。 添加一种在运行时安装用Lua编写的处理程序的方法是很容易的， 它允许将SWUpdate扩展到产品设计阶段没有覆盖的情况。 当然，这个问题与安全特性有关:必须确保只有经过验证的 处理程序才能添加到系统中，以避免恶意软件能够控制目标。 当前版本支持经过验证的镜像。这意味着用Lua编写的处理程序现在 可作为复合镜像的一部分，因为未经身份验证的处理程序无法运行。 对评估板的支持 ============================= 新的是meta-swupdate-board - 关于评估板的例子放在那里。 目前，有Beaglebone Black, Raspberri PI 3和Wandboard。 也许要再多一些板？欢迎提交补丁 后端支持 (suricatta 模式) ================================ 后端: Hawkbit 的离线支持 -------------------------------- 在Hawkbit的邮件列表中，有一些关于如何离线同步Hawkbit服务器更新 (在本地完成或通过内部web服务器完成)的讨论。 目前，Hawkbit 被认为是唯一的部署软件。需要扩展Hawkbit DDI API， 随后Swupdate需要做一些改动。 后端:整合“通用服务器” ------------------------------------- 第二个OTA服务器是在2018.11中引入的，但是没有针对服务器的开源解决方案。 无论如何，任何人都可以使用非常简单的“通用服务器”接口来引入自己的服务器， 而不是像Hawkbit这样的复杂的后端解决方案。 后端: 支持 Mender --------------------------- 对于如何在不同的更新解决方案之间进行更强的协作进行了多次讨论， 之前讨论过的建议是使用SWUpdate作为客户端从一个Mender服务器进行升级， 参见 `BOF at ELCE 2017 `_ 同时支持多个服务器 ------------------------------------------- 目前，suricatta的服务器后端是一个互斥的编译时的选项。没有必要同时拥有多个OTA服务器。 如果没有激起兴趣，这个特性将不会被实现，我将从规划中删除它。 SWUpdate 用于救援系统的GUI =========================== 在对HMI设备进行救援的情况下，通常需要一个小的GUI，让操作员设置一些参数(网络)并开始更新。 SWUpdate-GUI的第一个版本发布时附带了一组基本特性。这个简单GUI的目标是， 与使用最新技术框架开发的GUI相比，具有较低的内存占用。这使得救援系统仍然适用于小型设备。 测试和持续集成 ============================== SWUpdate中配置和特性的数量正在稳步增加， 迫切需要找到一种方法来测试所有传入补丁以修复回归问题。 这个方向的一个步骤是支持Travis构建 - 一组配置文件存储在项目中， 应该有助于在构建中快速找到受破坏的点。 必须朝这个方向做更多的工作，以便对目标进行测试。 应该找到一个合适的测试框架。 目标是拥有一个“SWUpdate工厂”，让补丁可以在真实硬件上快速集成和测试。 文档 ============= 应该改进文档。关于如何在不同的配置下，设置meta-swupdate，目前仍然只有少量文档。