现代车辆中的汽车软件变得非常复杂，并且提供了各种新功能和机遇。制造商的主要问题是要确保将新功能，错误修复和改进迅速应用于车辆，因为当今修理厂的软件更新方法不切实际。可以考虑通过空中更新（OTA）来更新新软件，而不会导致驱动程序中断。这就要求开发一个平台，该平台可以动态部署和更新应用程序，这是自适应AUTOSAR。这些程序不得违反安全关键ECU的正常工作，并应确保系统不受外部入侵的影响。在本文中，我们提出了一种车辆更新解决方案，其中包括将IoT技术与自适应AUTOSAR平台集成在一起，
如今，现代车辆非常依赖于软件，这可以实现一套全新的服务以及与驾驶员和乘客的交互，而许多功能取决于车辆的连接性。与智能手机建立连接和交换数据的能力是这一新兴趋势的一大进步。由于车辆已经开始与外界进行通信，因此汽车行业需要快速做出反应，并采用依赖于连接性的功能，例如远程更新，与软件即服务（SaaS）范式与后端系统的通信等。
在越来越多的电子控制单元（ECU）中增加软件复杂性的同时，许多软件组件已连接到外界，这为可能危害安全性的漏洞和利用创造了理想的环境。软件不可能做到防错；因此，最先进的产品与彻底的故障之间的界限非常小。对于原始设备制造商（OEM）而言，找到一种提供快速，安全，可靠的更新机制来解决这些问题的方法非常具有挑战性。
当前的汽车软件堆栈大多符合AUTOSAR。AUTOSAR伙伴关系的最新功能-自适应框架[1]将提供动态升级软件组件的机制。但是，在这种情况下，尚未提出用于可靠，安全的软件升级例程的完整流程。在本文中，我们提出了一个完整的升级软件体系结构，包括基于智能家居的基于物联网（IoT）技术的云连接；适用于托管和远程组件的自适应AUTOSAR堆栈扩展，验证和升级过程，以及面向OEM，驱动程序和服务人员的前端扩展。我们还将在模拟环境中对提出的概念进行评估。
解决汽车中软件更新问题的专有解决方案已经开发出来。有福特的Sync 3 [2]，Harman的OTA系统[3]，Uconnect [4]等。这些封闭的解决方案为系统强加了垂直方向的软件体系结构。当系统中需要更改或升级时，这会给OEM厂商带来重大问题。在这种情况下，标准化平台仍然不存在。自适应AUTOSAR将是第一个为此提供统一的应用程序编程接口（API）并解决如图1所示的创建水平对齐汽车软件体系结构的问题的标准。
图1.自适应AUTOSAR堆栈
关于学术界，也有关于车辆软件的安全交付的研究和相关工作[5]，以及具有自定义框架[6]和[7]的完整更新流程。这些技术和程序在物联网领域已经很成熟[8]，并且由于车辆的生命攸关性，它们可以在汽车工业中继承并进行适当的调整。
现有许多更新管理器解决方案，例如OSTree [9]或GENIVI SOTA [10]等，但是对于汽车ECU来说可能是至关重要的，因此这些管理器不适用，因此，新的管理器应基于较高的原则进行设计。安全性，验证性，授权性和数据正确性。在版本回滚，中间安装失败或取消的情况下，Automotive Update Manager也需要回滚过程。
据我们所知，汽车工业和学术界仍在寻求基于自适应AUTOSAR平台的软件动态升级的集成解决方案，并且许多提议的方法仍然相冲突。
III
拟议的软件更新体系结构如图2所示：
图2.
更新流程的体系结构A. OBLO系统
为了使车辆的OTA更新成为可能，名为“ OBLO” [11]的用于智能家居的现有物联网技术被用作系统的后端部分。OBLO系统的主要组件是图3中的用户和管理门户，云服务，数据库和网关。
图3.
OBLO系统架构用户和管理员使用门户网站获取有关家庭设备的信息或以所需方式对其进行控制。车辆作为智能设备显示在系统中，有关车辆的信息包括已安装应用程序及其版本的列表，如图4所示。
重要的功能是，通过门户网站，用户可以在升级可用时得到通知，并可以选择是否要更新。用户管理的应用程序来自Infotainment领域，对车辆中的乘客无害。但是，对于至关重要的更新，OEM可以从管理门户触发更新。
图4.
用户门户启动更新后，云服务负责使用MQTT协议将消息延长到网关。网关是放置在站点（家庭）上的OBLO系统的一部分，与节点（智能设备）进行通信。扩展了此组件，以便可以将车辆作为新的智能设备进行支持，并可以与平台（车辆中的ECU）进行更精确的通信-使用OTA Bridge Agent。
B. OTA桥接代理
空中（OTA）桥接代理代表了自适应AUTOSAR平台的扩展，该平台支持IoT系统与平台本身之间的双向通信。代理使用来自自适应平台（ARA :: COM）的通信模块与活动的自适应应用程序和服务进行通信，以收集数据并接收由承载不同类型信息的系统组件生成的各种类型的事件。
图5.
OTA桥架构通过代理本身的一部分Bridge Client组件与IoT云服务进行通信，如图5所示。Bridge Client将通信的详细信息（如协议或格式）抽象到平台的其余部分。这使其与物联网技术无关。
网桥运行时组件负责使用发布/订阅模式在代理中分发事件。事件从服务传播到客户端，反之亦然。Bridge Services和Bridge Client都注册到Bridge Runtime，并为其支持的各种类型的事件提供适当的处理器。当内部通信的参与者之一尝试将其事件发送到运行系统时，此事件将放置在事件的可用队列之一上。多个队列用于在事件分发期间提供最小的延迟。
代理程序最重要的部分是其桥接服务形式的扩展，可以绑定到Adaptive Platform的不同部分，例如诊断或更新和配置服务。通过在Bridge Runtime上注册来添加服务，从而应提供处理回调函数以及“预订”事件的列表。
OTA Bridge代理通过更新程序服务进行了扩展，该更新程序服务与自适应平台（ARA :: UCM）的更新和配置管理器绑定。在被云通知后，更新程序服务将下载软件包，因为ARA :: UCM仅适用于软件包的本地副本。下载完成后，更新程序将调用ARA :: UCM方法来处理下载的软件包。
C. 更新和配置管理器（ARA :: UCM）
ARA :: UCM[12]是自适应平台服务，不仅负责应用程序的更新，还负责底层OS和平台本身的更新。该服务的输入是“软件包”。
“软件包”是数据的组合，例如多个应用程序二进制文件，配置文件，资源等，以及为ARA :: UCM提供处理信息的软件包元数据。软件包的内容由OEM创建，生成和测试，然后上传到OBLO服务器。上载后，门户网站会显示有关新更新的通知。
由于ARA :: UCM不负责启动此过程，因此Updater Service会开始处理程序包。为了防止从另一个应用程序未经授权启动该过程，在这两个服务之间的通信中强制执行访问策略。
ARA :: UCM服务负责进一步的安全措施，包括包装验证，内存要求检查，跟踪正确的版本等。此外，在车辆处于行驶或停车模式时，无法进行更新，因此，在将车辆置于特殊状态之前-更新状态。
除了有关安全性的功能外，ARA :: UCM服务的简化任务如图6所示。
图6.ARA :: UCM用例图
IV.评价
通过测试完整的更新流程来完成验证和确认。通过创建软件包并上载来测试服务器。如果不是关键更新，则通过用户门户通知用户更新的可能性，如图7所示。然后，他们应该决定是否要升级软件。
图7.有可用更新
启动更新后，将在车辆级别执行上述过程。通过在图8的用户门户上验证应用程序的版本，并且在ECU级别没有崩溃的情况下，可以确认更新成功。
图8.更新的应用程序
这样的系统非常复杂，其性能取决于许多因素，例如Wi-Fi信号的强度和带宽，云服务的负载，汽车的状态，包裹尺寸，请求的类型等等。由于诸多因素，对车辆中执行的程序进行优化是很重要的。
表I的测量结果表明执行时间以毫秒为单位。与Web和IoT技术相比，响应时间可以是几秒钟，这表明该解决方案满足可以受到影响的标准。此外，可以看出，使用较大的程序包，执行时间会线性增长，这是可以预期的。
表I与软件包大小有关的安装请求的ARA :: UCM服务的执行时间
V.结论
本文提出的解决方案集成了现有的物联网技术-OBLO和新的自适应AUTOSAR平台，可帮助OEM解决昂贵且车辆更新缓慢的问题。提供快速方式将最新软件交付给车辆将满足非常苛刻的市场。
随着车辆变得越来越自主，驾驶员和乘客有更多的时间和空间来娱乐。此解决方案的未来工作可以是为Infotainment域实现“ App Store”，以确保客户满意度。
分享不易，恳请点个【👍】和【在看】
