汽车电子笔记之：AP AUTOSAR架构及概念

目录

1、概述

2、AP特性

2.1、C++

2.2、SOA

2.3、并行处理能力

2.4、利用现有标准

2.5、安全性

2.6、动态计划

2.7、敏捷

3、CP、AP和非AUTOSAR ECU的集成

3.1、ARA

3.2、语言绑定

3.3、应用交互

3.4、非标准接口

3.5、OS，处理器，和线程

3.6、基于库或基于服务的功能集群的实现

4、AP开发方法论

4.1、概述

4.2、操作系统

4.2.1、调度

4.2.2、内存管理

4.3、执行管理（Execution Management）

4.3.1、系统启动

4.3.2、EM的职责

4.3.3、状态管理

4.4、通讯管理

4.4.1、面向通信的服务

4.4.2、语言绑定和网络绑定

4.4.3、生成c++语言绑定的代理和框架

4.4.4、静态和动态的配置

4.5、持久化管理

4.5.1、Key-Value存储

4.5.2、File存储

4.6、健康管理

4.6.1、信息交换的保护

4.6.2、平台健康管理

4.6.3、C++编程指引

4.7、安全措施(Security)

4.7.1、身份和访问管理

4.7.2、Crypto和Key管理

4.7.3、安全架构

4.8、更新和配置管理

4.8.1、软件包处理

4.8.2、软件信息报告

4.8.3、软件更新的一致性

4.9、时间同步

4.9.1、设计

4.9.2、架构

1、概述

        新四化（电动化，网联化，智能化，共享化）的变革驱使汽车软件系统变得更加灵活。汽车软件既要安全又要可持续更新以反映新的功能特性或法规要求，为此需要新架构支持软件组件的动态部署以及与非车载系统之间的交互。今天的汽车 E/E 架构可划分为信息娱乐、底盘和车身控制等不同域，信息娱乐系统通常使用 Linux 或商业化的通用操作系统，车身控制则使用标准的AUTOSAR CP。

        随着未来新技术及深度嵌入式系统对计算能力需求的不断增长，急需第三种控制器—— 域控制器，用于集成特定领域的功能特性（如车辆动力域、车身域等 )，形成域集中或跨域集中式电子电气架构。在未来，随汽车电子及软件功能的大幅增长，E/E 架构最终可能向基于中央计算平台的整车集中式电子电气架构，以及车云协同控制发展。

        在这种趋势下，需要高度灵活、高性能、动态通信等特性的新软件架构平台—— Adaptive Platform AUTOSAR 平台（下文简称 AUTOSAR AP）。

2、AP特性

        AP包含的特性来自于未来的智能ECU和技术驱动两个方面。高性能的计算满足了安全的需要同时也需要很高的能耗，因此带来了许多新的挑战。为了应对这些挑战，AP采用了很多传统ECU未充分利用的技术。有如下几个方面

2.1、C++

        Adaptive AUTOSAR平台的应用都将采用C++编程。虽然C语言是嵌入式系统的主要编程语言，具有执行速度快、效率高的特点；但是在性能要求非常高的复杂应用和算法开发上（如机器学习、图像特征识别等）具有面向对象特性的C++显然比C更具有优势。C++能够提供算法开发和性能均衡的软件。并且方便很快地适配和量产开发。

2.2、SOA

        为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可伸缩性，AP遵循SOA(service-oriented-architecture)的架构。SOA主要基于以下概念：系统由一组服务构成，其中一个可使用另外一个的服务，应用程序可根据自己的需要使用一个或者多个服务；此外服务可以在应用程序运行的本地ECU上，也可以运行在另一个AP实例的远程ECU上。

2.3、并行处理能力

        分布式计算本质是并行的。先进的多核异构处理器既具有强大的计算能力也能为并行计算提供技术支持，随着多核异构计算技术的发展，AP具有扩展其功能和性能架构的能力。事实上，硬件和接口规范仅是实现AP的一部分，在OS等技术和开发工具的发展上对实现AP的应用也至关重要。

2.4、利用现有标准

        重新发明轮子是没有意义的，尤其在规范方面。正如已经在c++中描述的那样，AP采取了重用和适应现有开放标准的策略，以促进AP自身的更快发展，并从现有标准的生态系统中受益。因此，开发AP规范的一个关键重点是不要随意引入现有标准已经提供的新替代功能。例如，这意味着不会仅仅因为现有标准提供了所需的功能，但接口表面上不容易理解，就随意引入新的接口。

2.5、安全性

        AP所针对的系统通常需要某种级别的安全性，可能是最高级别的安全性。新概念和技术的引入不应破坏这些需求，尽管实现这些需求并非易事。为了应对这一挑战，AP结合了体系结构、功能和过程方法。该架构基于基于SOA的分布式计算，这使得每个组件更加独立，避免了意想不到的干扰，具有专门的功能来帮助实现安全和保障，以及诸如c++编码指南之类的指导方针，它促进了像c++这样的复杂语言的安全使用

2.6、动态计划

        AP支持应用程序的动态部署，动态地管理资源和通信，以减少软件开发和集成的工作量，从而缩短迭代周期。在AP架构下，不同的应用可能由不同的供应商提供，因此在产品交付阶段，AP允许系统集成商合理限制这种动态部署的特性以降低不必要的风险和影响。

2.7、敏捷

        敏捷尽管没有直接反映在平台功能中，AP的目标是适应不同的产品开发过程，特别是基于敏捷的过程。对于基于敏捷的开发，至关重要的是系统的底层架构是可增量扩展的，在部署后可以更新系统。AP的体系结构应该允许这样做。作为概念的证明，AP规范本身和演示者(AP的演示实现)都是用Scrum[^1]开发的。

        [^1]: Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums. [1]

3、CP、AP和非AUTOSAR ECU的集成

        综合以上的介绍，AP不会替代CP或者非AUTOSAR的平台。而是与这些平台以及外部后端系统(如路边基础设施)交互，形成一个完整的系统(图2-1不同平台部署示例、图2-2 AP与CP交互示例)。例如，CP已经包含了一些SOME/IP协议，AP也支持这些协议。

        逻辑视图如下

3.1、ARA

        在autosar cp中，应用程序是运行在RTE层之上。同样的，autosar ap架构中，也为应用程序提供了实时运行层。如下图AP架构逻辑视图：其中Adaptive Application(自适应应用)运行在ARA(AUTOSAR自适应应用的运行环境)之上。ARA是应用程序（AP中称为Adaptive Application）运行时的基础环境，可以提供多种本地功能供应用程序调用，这些本地功能在AP中统称为Function Clusters，其分为两个部分：Foundation Function Clusters和Service Function Clusters。

3.2、语言绑定

        这些API的语言基于C++绑定的，C++标准库也可以作为ARA的一部分使用。关于OS接口，只有POSIX标准的单进程概要文件(PSE51接口)作为ARA的一部分可用。选择PSE51是为了为现有的POSIX应用程序提供可移植性，并实现应用程序之间的自由干扰。

        C++标准库包含许多基于POSIX的接口，也包括多线程接口。

3.3、应用交互

        对于AAs之间的交互，PSE51没有包含IPC (Inter-Process- Communication)，所以在AAs之间没有直接的交互接口。通信管理(CM)是唯一的显式接口。CM还为ECU内外部提供面向服务的通信。CM处理服务请求/响应的路由，而不管服务和客户端应用程序的拓扑部署。

3.4、非标准接口

        AA和功能集群可以使用任何非标准接口，只要它们不与标准AP功能冲突，并且符合项目的安全性/安全性要求。除非它们是纯粹的应用程序本地运行时库，否则应该注意尽量减少这种使用，因为这将影响软件对其他AP实现的可移植性。

3.5、OS，处理器，和线程

        AP操作系统要提供多进程 POSIX OS的兼容性。每一个AA实现为一个独立的进程。自适应平台服务和非平台服务也实现为进程。

        进程可以是一个单线程或多线程进程。可以使用OS API根据进程所属的逻辑层而有所不同。如果它们是运行在ARA之上的AAs，那么它们应该只使用PSE51。如果一个进程是功能集群之一，它可以自由使用任何可用的操作系统接口。

        AA进程不能直接使用IPC，只能通过ARA进行通信。其他进程可以通过IPC或任何其他可用的OS功能相互交互

3.6、基于库或基于服务的功能集群的实现

        上图AP架构逻辑视图中，功能集群可以是自适应平台基础模块，也可以是自适应平台服务。为了与同样是进程的AAs进行交互，它们需要使用IPC。有两种替代设计可以实现这一点。一种是基于库的设计，由功能集群提供的接口库链接到AA，直接调用IPC。另一种是基于服务的设计，流程使用通信管理功能，并有一个服务器代理库链接到AA。代理库调用通信管理接口，协调AA进程和Server进程之间的IPC。注意，它是由实现定义的，AA是否只直接执行IPC与通信管理或混合直接IPC与服务器通过代理库。为功能集群选择设计的一般原则是，如果它只在AP实例中本地使用，那么基于库的设计更合适，因为它更简单，也更高效。如果它以分布式方式从其他AP实例中使用，建议采用基于服务的设计，因为通信管理提供透明的通信，而不考虑客户端AA和服务的位置。自适应平台基础的功能集群是基于库的，自适应平台服务的功能集群是基于服务的。最后，需要注意的是，一个功能集群的实现可以没有进程，而是以库的形式实现，在AA进程的上下文中运行，只要它满足功能集群定义的需求规范和软件规范。在这种情况下，AA和功能集群之间的交互将是常规的过程调用，而不是像前面描述的那样基于IPC。

4、AP开发方法论

4.1、概述

        下图简要展示了 AP 平台的开发工作流，总体来说需要经历三个阶段七个步骤，最终将开发的软件集成入车辆中。

（1）架构设计阶段

① 服务接口设计（Define Services）：主要是定义服务接口及数据类型，包括定义服务所包含的method、event、field等通信元素以及数据类型详细说明等；

② 机器配置设计（Configure Machine）：定义和配置机器的网络通信属性，包含网络连接配置，服务发现配置等信息；

（2）软件开发阶段

③ 定义与配置可执行实例及通信方式，定义可执行实例如何访问软件集；

④ 定义软件集群所提供的服务实例、配置服务实例和可执行实例的映射；

⑤ 服务实例接口框架源码生成；软件集群源码开发及测试等；

（3）集成与部署阶段

⑥ 软件集群集成 (Integrate Software) ：配置可执行实例和进程的映射、定义和配置应用程序配置清单、定义和配置服务实例部署信息；

⑦ ECU 集成 (ECU(Machine) Integrate)，定义应用程序执行清单 (Execution Manifest)、定义平台程序的配置清单、诊断和进程之间的映射配置；

4.2、操作系统

        操作系统负责运行时的资源和时间管理。EM负责平台初始化和应用的启动和停止，与操作系统协同工作。

        AP没有为高性能的处理器指定操作系统。而是，其定义执行上下文和操作系统接口供AP应用使用。

        OSI(操作系统接口)规范包含了ARA中部分应用接口以及AP应用的标准接口。OS本身可以很好地提供其他接口，例如创建进程，这是执行管理启动应用程序所需要的，但是这种类型的接口，不能作为ARA的一部分使用，因为它被定义为依赖于平台实现。

        OSI同时提供C和C++接口。对于C程序，应用程序的主要源代码业务逻辑包括在POSIX标准中定义的C函数调用，即在IEEE1003.13[1]中定义的PSE51。在编译过程中，编译器决定来自平台操作系统的哪个C库提供了这些C函数，应用程序的可执行文件应该在运行时被链接。对于c++程序，应用软件组件的源代码包括在C++标准及其标准C++库中定义的函数调用。

4.2.1、调度

        操作系统提供多线程和多进程的支持。标准的调度策略是SCHED_FIFO和SCHED_RR，由POSIX标准定义。其他如SCHED_DEADLINE或者任何其他操作系统规定的策略也被允许，但有一些限制，即这些策略可能不能跨不同的AP实现移植。

4.2.2、内存管理

        支持多进程的原因之一是实现了不同功能集群和AA之间的自由干扰。操作系统对多进程的支持迫使每个进程处于一个独立的地址空间中，与其他进程隔离和保护。同一个可执行文件的两个实例在不同的地址空间中运行，这样它们在启动时可能共享相同的入口点地址和代码以及数据值，但是数据将在内存中的不同物理页中。

4.3、执行管理（Execution Management）

        EM负责系统执行管理的各个方面，包括系统初始化和应用的启停。EM与操作系统协同工作执行应用的调度。

4.3.1、系统启动

        当机器启动时，操作系统会被首先初始化然后EM作为操作系统一个初始进程被启动。然后EM启动自适应平台基础的其他功能集群和平台级应用程序。自适应平台基础启动并运行后，EM将继续启动自适应应用程序。平台级应用程序和自适应应用程序的启动顺序由执行管理基于机器清单和应用程序清单信息决定。

4.3.2、EM的职责

EM负责AP平台和应用执行管理的各个方面，包括

1、平台生命周期管理

        EM是自适应平台启动阶段的一部分，负责自适应平台和部署的应用程序的初始化

2、应用生命周期管理

        EM负责已部署的应用程序的有序启动和关闭。EM根据机器清单和应用程序清单中的信息确定已部署的应用程序集，并根据声明的应用程序依赖项派生启动/关闭顺序。根据机器状态和功能组状态，部署的应用程序在自适应平台启动时或之后启动，然而，并不期望所有的应用程序都立即开始活动工作，因为许多应用程序将向其他应用程序提供服务，从而等待和侦听传入的服务请求。

        执行管理不负责应用程序的运行时调度，因为这是操作系统的责任。但是，执行管理负责操作系统的初始化/配置，使其能够根据执行管理从机器清单和应用程序清单中提取的信息执行必要的运行时调度。

4.3.3、状态管理

        状态管理提供了一种机制来定义自适应平台的操作状态。状态管理定义了AUTOSAR自适应平台的操作状态，由EM执行不同状态之间的转移。

EM有四种不同的状态：

        Machine State该状态主要用控制机器生命周期(Startup/shutdown/restart)，平台级的进程，和其他基础设施。在每台机器上都必须存在几个强制性的机器状态。其他特定于机器的机器状态可以在机器清单中定义。

        Function Group State该状态主要用于单独启动和停止功能一致的用户级应用进程组。它们可以在机器清单中配置。

        Process State该状态用于应用程序生命周期管理，并由执行管理内部状态机实现。

        Execution State该状态描述了应用程序的内部生命周期，即进程。每个进程必须向执行管理报告应用程序状态更改。

        如下图，显示了在状态管理请求了不同功能组状态之后，不同类型状态之间的交互的简化示例。可以看到功能组的状态转移，以及引用此功能组的一个状态的流程和执行状态。

4.4、通讯管理

        通信管理实现了自适应AUTOSAR应用程序之间面向服务的通信，适用于所有级别的通信，如进程内、进程内、机器间。它由潜在生成的服务提供者框架和服务请求者代理以及可选的用于中央代理和配置的通用通信管理器软件组成。

        通信管理提供了内置的安全机制，即E2E保护，其可以用于所有级别的对于事件和方法的通信。

4.4.1、面向通信的服务

        服务的概念意味着提供给应用程序的功能超出了基本操作软件已经提供的功能。通信管理软件提供了一些机制来提供或使用这些服务，用于机器内部通信和机器间通信。

一个服务包括：

Events

Methods

Fields

        通信伙伴之间的通信路径可以在设计时、启动时或运行时建立。该机制的一个重要组件是充当代理实例的Service Registry，它也是Communication Management软件的一部分。

        每个提供服务的应用程序都在服务注册中心注册这些服务。要使用服务，应用程序需要通过查询服务注册表来查找所请求的服务，这个过程称为服务发现。服务发现可以发现所有本地和远程的服务实例。服务消费由Proxy（P1...P3）表示，应用可以选择使用哪一个服务实例。

4.4.2、语言绑定和网络绑定

        通信管理提供了标准化的方法，即如何将已定义的服务呈现给应用程序实现者(上层，语言绑定)，以及服务数据在网络上的各自表示(下层，网络绑定)。这确保了源代码的可移植性和编译服务在不同平台实现之间的兼容性。

        语言绑定，定义了如何通过目标编程语言的特性将服务的方法、事件和字段转换为直接可访问的标识符，性能和类型安全(只要目标语言支持)是主要目标。因此，语言绑定通常是由服务接口定义，源代码生成器实现的。

        网络绑定定义了如何将已配置服务的实际数据序列化并绑定到特定的网络。它可以根据Communication Management配置(AUTOSAR元模型的接口定义)来实现，既可以解释生成的特定于服务的配方，也可以直接生成序列化代码本身。

网络绑定的三种方式：

        SOME/IP网络绑定

        基于Signal的网络绑定

        DDS网络绑定

本地服务注册也是网络绑定的一部分。

        请注意:语言绑定和网络绑定之间的接口被认为是通信管理软件内部的私有接口。因此，定义该接口的规范目前已超出范围。尽管如此，平台供应商还是被鼓励独立地为他们的软件定义这样的接口，以方便实现其他语言绑定(而不是c++)以及平台实现中的其他网络绑定。

4.4.3、生成c++语言绑定的代理和框架

c++语言绑定的上层接口提供了服务的面向对象的映射。

        作为Communication Management软件开发工具的一部分，生成器生成c++类，这些类包含各个服务的字段、事件和方法的类型安全表示。

        在服务实现端，这些生成的类被命名为服务提供者框架。在客户端，它们被称为服务请求者代理。对于服务方法，服务请求者代理提供了同步和异步调用的机制。调用者可以同时启动其他活动，当服务器的返回值通过c++标准模板库(std::future)的特殊特性可用时，调用者可以接收结果。

        当相应的服务器还不可用时，可以对平台实现进行配置，使生成器创建模拟类，即可轻松开发客户端功能。同样的机制也可以用于对客户机进行单元测试。虽然代理类可以被客户端直接使用，但c++绑定的服务提供者框架只是抽象基类。

        服务实现应该从生成的基类派生并实现相应的功能。ara::com的接口还可以为端到端安全通信提供代理和框架。

4.4.4、静态和动态的配置

        通信路径的配置可以在设计时、启动时或运行时进行，进一步可分为静态或动态的。

        完全静态配置:根本不需要服务发现，因为服务器知道所有的客户端，而客户端也知道服务器。

        应用程序代码没有发现:客户机知道服务器，但服务器不知道客户机。事件订阅是应用程序中唯一的动态通信模式。

        应用程序中的完整服务发现:在配置时不知道任何通信路径。服务发现的API允许应用程序代码在运行时选择服务实例。

4.5、持久化管理

        持久化管理提供应用在NVM中存储信息的机制。该数据可在启动和点火循环使用。持久化通常被实现为一个库，它运行在自适应应用程序的进程中，具有该进程的权限。

        持久化管理库将存储位置标识符作为来自应用程序的参数，以寻址不同的存储位置。可用的存储位置分为两类：

Key-Value Storage

File-Proxy Storage

        每个应用可以使用多个存储类型的组合。

        对于一个应用，存储的数据总是私有的。使用存储库不能在不同应用间共享数据。这一决定是为了防止在communication Management提供的功能之下出现第二个通信路径。

        持久化管理对于存储的数据提供加密方法，确保敏感数据在写入物理设备之前进行加密。

4.5.1、Key-Value存储

        键值存储提供了从一个存储位置存储和恢复数据的机制。支持的value类型是基础类型，

        每个Key-Value数据库的键必须是唯一的字符串，并且由应用程序使用存储库提供的方法定义。

4.5.2、File存储

        并不是所有持久存储的数据类型都适合Key-Value机制，因此AP平台还支持File存储机制。File存储提供对一组文件的访问，类似于文件系统的目录。

4.6、健康管理

        健康管理为AP应用在车辆内外提供保护信息交互的机制，包括ECU内外的通信机制。出于此目的，这个机制允许在发生任何损坏时进行错误检测。健康监控是ISO26262(控制流程监控、外部监控设施、看门狗、逻辑监控、时间监控、程序顺序监控)所要求的。

        另外，对编码指引提供指导，有利于安全可靠的使用复杂的语言，比如C++。

4.6.1、信息交换的保护

        最新的AUTOSAR E2E配置支持所有AUTOSAR AP和CP实例组合之间的安全通信，无论它们是在相同或不同的ecu中。在有用的情况下，将提供使用自适应平台中面向服务的更多功能的机制，以允许安全通信。所提供的功能提供了验证从发布者发送和由订阅者接收的信息在传输期间没有更改的可能性。根据AUTOSAR CP中的E2E机制，在E2E上下文中不提供传输确认和传输安全。

        当在发布者和订阅者之间的通信中使用端到端保护时，在发布者的进程中同步调用端到端保护。在订阅者端，在接收订阅者流程中的数据时调用被选中的端到端。

4.6.2、平台健康管理

提供健康管理机制以支持fail-safe应用。包含如下方面

Alive supervision（存活监督）

Deadline supervision（运行时间监督）

Logical supervision（逻辑监督）

Error handing of supervision errors（监督错误的异常处理）

Health Monitoring

4.6.3、C++编程指引

        AUTOSAR C++ 14编码指南文档适用的主要应用领域是汽车，但它也可以用于其他在安全相关和关键环境中工作的嵌入式应用。AUTOSAR C++ 14编码准则适用于在32位和64位微控制器上，使用POSIX或类似操作系统，提供高效和完整的c++ 14语言支持的高端嵌入式微控制器。

        现有的标准是不完整的，包括旧的c++版本，或者不适用于关键/安全相关的。特别是，MISRA c++:2008不包括c++ 11/14。多个新的语言特性需要分析它们在提供有效实现方面的作用，以及使用每个特性会带来多大的风险。

4.7、安全措施(Security)

Security服务提供AP平台增强系统的方法，比如安全通信和访问管理系统。

4.7.1、身份和访问管理

        我们建议AUTOSAR自适应平台采用身份和访问管理框架，以支持对各个AUTOSAR组件(自适应AUTOSAR应用程序、服务和功能集群)进行身份验证，并引入角色和权限管理功能的概念。使用IAM框架，这些应用程序可以查询基于现有策略的访问控制决策。查询将通过功能集群处理，因为应用程序没有与IAM框架的直接接口。在使用请求时，服务将能够用指定的框架来评估请求者的权限和权利，并相应地实施相应的策略。

        这个框架背后的思想是由日益增长的安全需求驱动的，因为AUTOSAR自适应平台需要与它的应用程序建立一个健壮的、定义良好的信任关系。如果攻击者破坏了应用程序，它不应该对自适应平台本身有任何影响，攻击者的能力应该被限制在被破坏的应用程序的能力。这就是为什么应用程序应该只能访问系统资源或触发它们应该执行的操作。IAM框架管理身份和访问权限，可以被视为一种可理解的机制，将应用程序的访问限制在必要的最低限度。

4.7.2、Crypto和Key管理

        AUTOSAR自适应平台支持用于通用密码操作和安全密钥管理的API。该API支持在运行时动态生成密钥和加密作业，以及对数据流进行操作。为了减少存储需求，密钥可以存储在加密后端内部，也可以存储在外部，并根据需要导入。

        该API旨在支持在单独的组件(如硬件安全模块(HSM))中封装安全敏感的操作和决策。通过将密钥限制到特定的使用(例如，仅解密)，或根据IAM的报告，将密钥的可用性限制到单个应用程序，可以提供对密钥和密钥使用的额外保护。

        根据应用程序支持的不同，API还可以用于在处理TLS和SecOC等加密协议时保护会话密钥和中间秘密。

4.7.3、安全架构

Key管理

4.8、更新和配置管理

        AP平台提供一个很重要的能力是通过OTA(over-the-air)升级软件和配置。为此，AP平台提供Update and Configuration Manager(UCM)服务处理软件升级请求。

        UCM负责升级，安装，卸载和记录AP平台的软件。它的角色类似于已知的包管理系统，如Linux中的dpkg或YUM，具有额外的功能，以确保以一种安全的方式更新或修改Adaptive Platform上的软件。

4.8.1、软件包处理

        除了应用程序和配置数据，每个软件包都包含一个清单，提供元数据，如包名、版本和处理包所需的其他元信息。

        软件包的数据内容可以包含一个或多个自适应应用程序，内核或固件更新，或更新的配置和校准数据。

        UCM基于提供的元数据和Adaptive Platform软件信息处理软件包。

4.8.2、软件信息报告

        UCM提供了服务接口，该接口公开了检索Adaptive Platform软件信息的功能，例如已安装软件的名称和版本。

4.8.3、软件更新的一致性

        UCM确保只安装具有所有描述的依赖项的验证包。这样就不会安装不需要的或不合适的软件。UCM提供了一个读取安装结果的界面。如果在更新过程中出现故障，UCM将平台恢复到一个已知的功能状态。可恢复故障的一个例子是由于功率损失而中断的更新过程。

4.9、时间同步

        当需要跨分布式系统的不同事件的相关性时，不同应用程序和/或ECU之间的时间同步(Time Synchronization)是至关重要的，无论是为了能够及时跟踪这些事件，还是为了在准确的时间点触发它们。

        由于这个原因，一个时间同步API被提供给应用程序，所以它可以检索与其他实体/ECU同步的时间信息。

        时间同步功能是通过系统中不同的“时间基础资源”来提供的。

4.9.1、设计

对于AP平台，下面3种不同的技术应用满足时间同步的需要

CP平台的StbM模块

chrono库（与日期和时间相关的库） - std::chrono (c++ 11)或boost::chrono

POSIX Time 接口

时间同步模块提供类似于CP平台StbM的功能，但带有一个std::chrono启发的API设计。

时间同步模块会考虑以下几个方面

Startup Behavior（启动行为）

Constructor Behavior(构造函数的行为)

Normal Operation（正常操作）

Error Handing（错误处理）

未来会考虑以下几个方面

Shutdown Behavior

Error Classification（异常分类）

Version Check

4.9.2、架构

        应用程序将能够访问每个基础时间资源(Time Base Resource)以不同的类进行实现。TBR以资源的形式提供，就像在ara::com设计中提供服务一样，因此它采用了以下ara::com的架构设计模式

        代理:类似于ara::com服务代理框架模式，TS提供了一个资源代理模式，省略了框架部分。

        查找:类似于ara::com服务代理查找模式，TS提供了一个资源代理查找模式来提供对tbr的访问。

        代理方法:类似于ara::com代理方法模式，TS使用的方法模式也遵循异步的Future模式。

        当谈到避免延迟时，这种架构设计显然将时间同步设计置于正面冲突之中，因为后者是由ara::com API的设计模式的异步行为固有地添加进来的。

声明：文章属于转载，原文请见如下链接，如有侵权，请联系本人删除。

AutoSar 架构与概念 - 知乎