广告

AUTOSAR经典平台(CP)和AUTOSAR自适应平台(AP)分别满足嵌入式ECU和智能ECU需求

2022-03-31 汽车电子与软件 阅读:
AUTOSAR经典平台(CP)标准满足了深度嵌入式ECU的需求,而智能ECU的需求无法满足。因此,AUTOSAR指定了另一个软件平台,即AUTOSAR自适应平台(AP)。AP主要提供高性能的计算和通信机制,并提供灵活的软件配置,例如支持OTA技术。
1 范围和方法

1.背景pqRednc

传统ECUpqRednc

控制软件为目标车辆而设计pqRednc

在车辆使用寿命期间不会发生重大变化pqRednc

智能ECUpqRednc

高度自动驾驶的到来pqRednc

车辆中高性能CPU的引入pqRednc

OTA技术的搭载pqRednc

AUTOSAR经典平台(CP)标准满足了深度嵌入式ECU的需求,而智能ECU的需求无法满足。因此,AUTOSAR指定了另一个软件平台,即AUTOSAR自适应平台(AP)。AP主要提供高性能的计算和通信机制,并提供灵活的软件配置,例如支持OTA技术。pqRednc

2.技术驱动因素pqRednc

① 以太网pqRednc

车载网络不断增长的带宽要求导致引入了以太网。pqRednc

与传统的车载通信技术(例如CAN)相比,以太网具有高带宽并具有交换网络、可以更有效地传输长消息、实现点对点通信等 。pqRednc

CP尽管支持以太网,但主要是针对传统通信技术而设计的,并且已经为此进行了优化,因此很难充分利用基于以太网的通信功能并从中受益。pqRednc

pqRednc

② 处理器pqRednc

随着汽车的智能化程度越来越高,处理器的性能要求也大大提高。原本为单核MCU设计的CP虽然可以支持多核,但它设计起来却力不从心。pqRednc

随着越来越多的处理元件(例如多核处理器)被组合在一个芯片中,这些处理元件之间的通信变得比传统的ECU间通信更快,更高效新型的处理器互连技术(如片上网络NoC)使这成为可能。pqRednc

更大的处理能力和更快的芯片内通信速度的这种综合效果,也促使人们需要一种新的平台,以适应不断增长的系统要求。pqRednc

3.AP的特点pqRednc

AP采用了各种传统上尚未被ECU充分利用的成熟技术pqRednc

C++pqRednc

AP中使用C++对应用程序进行编程,可以更快地适应新算法并提高应用程序开发效率。pqRednc

SOApqRednc

AP遵循面向服务的体系结构SOA(service-oriented-architecture)。pqRednc

SOA基于以下概念:pqRednc

系统由一组服务组成,其中一个服务可以依次使用另一个服务,应用程序可以根据其需要使用一个或多个服务。pqRednc

服务可以驻留在应用程序运行的本地ECU上,也可以位于正在运行AP另一个实例的远程ECU上。pqRednc

并行处理pqRednc

由于不同的应用程序使用不同的服务集,因此SOA具有并行处理的特点。pqRednc

利用现有标准pqRednc

开发AP规范的重点是,不会仅仅因为现有标准提供了所需的功能就随意引入了新的接口。pqRednc

Safety和SecuritypqRednc

AP设计的系统通常需要某种级别的安全性,可能是最高级别。pqRednc

AP结合了架构、功能和程序方法。该体系结构基于SOA的分布式计算,从而使每个组件变得更加独立且不受意外干扰、有助于实现Safety和Security的专用功能、以及使用C ++编码来促进安全性。pqRednc

计划动态pqRednc

AP支持应用程序的增量部署,这意味着可以动态管理资源和通信,以减少软件开发和集成的工作量,从而缩短迭代周期。pqRednc

计划的动态示例可能是: pqRednc

·仅将动态内存分配限制为启动阶段pqRednc

·除了基于优先级的计划外,还需要公平的计划策略pqRednc

·将进程固定分配给CPU内核pqRednc

·仅访问文件系统中的现有文件pqRednc

·应用程序对AP API使用的限制pqRednc

·仅执行经过验证的代码pqRednc

敏捷开发pqRednc

敏捷开发至关重要的一点是,系统的基础体系结构是可增量伸缩的,并且有可能在部署系统后对其进行更新。AP的体系结构可以实现这一点,能应对快速变化需求的软件开发。pqRednc

4.经典、自适应和非AUTOSAR ECU的集成pqRednc

AP不会取代CP平台或IVI/COTS中的非AUTOSAR平台。 相反,它将与这些平台和外部后端系统(如路边基础架构)进行交互,以形成一个集成系统。pqRednc

pqRednc

图1 不同平台的示例性部署pqRednc

pqRednc

图2 AP和CP的示例性交互pqRednc

2 架构篇

1.逻辑视图pqRednc

① ARA

图1表示的是AP的体系结构。从图中可以看出以下几点:pqRednc

1. 自适应应用程序(AA)在自适应应用程序的AUTOSAR运行时(ARA)之上运行。pqRednc

2. ARA由功能群集提供的应用程序接口组成,这些群集属于Adaptive Platform Foundation或Adaptive Platform Services。Adaptive Platform Foundation提供AP的基本功能,而Adaptive Platform Services提供AP的平台标准服务。pqRednc

3. 任何AA也可以向其他AA提供服务,在图中以非平台服务形式说明。pqRednc

从AA的角度来看,功能集群的接口(无论是Adaptive Platform Foundation的接口还是Adaptive Platform Services的接口)都无所谓——它们仅提供指定的C ++接口或AP将来可能支持的任何其他语言的接口。pqRednc

另外,请注意,在ARA接口下,包括在AA上下文中调用的ARA库,可以使用ARA以外的其他接口来实现AP规范,这取决于AP实现的设计。pqRednc

pqRednc

图3 AP架构逻辑视图pqRednc

 ② 语言绑定,C++标准库和POSIX APIpqRednc

这些API是基于C ++,并且C ++标准库也作为ARA的一部分提供。pqRednc

关于OS API,AA只可使用PSE51接口pqRednc

建议不要将C ++标准库线程接口与本机PSE51线程接口混合使用,以避免复杂化。pqRednc

但是,C ++标准库没有涵盖所有PSE51功能,例如设置线程调度策略。在这种情况下,可能需要同时使用两个接口。pqRednc

③ 应用程序启动和关闭pqRednc

应用程序的生命周期由执行管理(EM)管理。pqRednc

应用程序的加载/启动是通过使用EM的功能进行管理的,并且需要在系统集成时或运行时进行适当的配置才能启动应用程序。pqRednc

实际上,从EM的角度来看,所有功能集群都是应用程序,除了EM本身以外,它们也以相同的方式启动。图2应用程序说明了AP内部和AP上不同类型的应用程序。pqRednc

pqRednc

图4 应用程序类型pqRednc

EM不会决定应用程序的启动时间和终止时间。pqRednc

应用程序的启动时间和终止时间是状态管理(SM)控制的,SM是一种特殊的FC,它根据系统的设计命令EM,仲裁不同的状态,从而控制整个系统的行为。pqRednc

SM还与其他FC交互以协调整体机器行为。SM应该仅使用标准ARA接口来维护不同AP堆栈实现之间的可移植性。 pqRednc

④ 应用程序交互pqRednc

AA之间没有直接进行交互的接口,不能通过IPC(进程间通)进行直接交互。pqRednc

AA之间要想交互需要通过通信管理(CM)pqRednc

AA可以直接调用POSIX OS的PSE51接口,但是不能调用POSIX OS的非PSE51接口pqRednc

CM还为Machine内和Machine间提供面向服务的通信pqRednc

注意:其他ARA接口可能在内部触发AA之间的交互,但是,这不是显式的通信接口,而只是相应ARA接口提供的功能的副产品pqRednc

⑤ 非标准接口

AA和功能集群可以使用任何非标准接口,只要它们不与标准AP功能冲突,并且它们符合项目的安全性要求即可。pqRednc

除非它们是纯的应用程序本地运行时库,否则应注意使此类使用最少,因为这将影响软件在其他AP实现上的可移植性。pqRednc

 pqRednc

2.物理视图pqRednc

在此讨论AP的物理体系结构。pqRednc

注意:本节中的大多数内容仅用于说明目的,并且不构成AP的正式要求规范。pqRednc

 操作系统,进程和线程

每个AA被实现为一个独立的进程,具有自己的逻辑内存空间和名称空间。

请注意,单个AA可以包含多个进程,并且可以将其部署到单个AP Instance上或分布在多个AP  Instance上。

每个进程都由OS从可执行文件实例化。可以从单个可执行文件实例化多个进程。同样,AA可以构成多个可执行文件。

功能集群通常也被实现为进程。功能集群也可以用单个过程或多个(子)过程来实现。自适应平台服务和非平台服务也被实现为进程。pqRednc

所有这些进程可以是单线程进程或多线程进程。但是,根据进程所属的逻辑层,它们可以使用的OS API有所不同。如果它们是运行在ARA之上的AA,则它们只能使用PSE51。pqRednc

如果该进程是功能集群之一,则可以自由使用任何可用的OS接口。pqRednc

综上所述,从操作系统的角度来看,AP和AA只是形成一组进程,每个进程包含一个或多个线程——这些进程之间没有区别。这些进程确实通过IPC或任何其他可用的OS功能相互交互。请注意,AA进程可能不会直接使用IPC,而只能通过ARA进行通信。pqRednc

② 基于库或基于服务的功能集群实施pqRednc

如图1 AP体系结构逻辑视图中所示,功能集群可以是Adaptive Platform Foundation模块或Adaptive Platform Service。如前所述,这些通常都是进程。为了使它们与AA(也是进程)交互,它们需要使用IPC。有两种替代设计可以实现此目的。pqRednc

一种是“基于库”的设计,其中由功能集群提供并链接到AA的接口库直接调用IPC。pqRednc

另一个是“基于服务”的设计,该进程使用通信管理功能,并且具有链接到AA的Server Proxy库。Proxy库调用通信管理接口,该接口在AA进程和服务器进程之间协调IPC。请注意,AA是仅通过通讯管理直接执行IPC,还是通过Proxy库与Server 直接IPC混合,由实施定义。 pqRednc

选择功能性集群设计的一般指导原则是,如果仅在AP实例中本地使用它,则基于库的设计会更合适,因为它更简单且效率更高。pqRednc

如果以分布式方式从其他AP实例中使用它,则建议采用基于服务的设计,因为无论客户端AA和服务的位置如何,通信管理都将提供透明的通信。顾名思义,属于Adaptive Platform Foundation的功能集群是“基于库的”,而Adaptive Platform Services是“基于服务的”。 pqRednc

注意:允许FC的实现以库的形式实现,即:AA和FC之间的交互将是常规进程调用,而不是如前所述基于IPC。pqRednc

③ 功能集群之间的交互

功能集群之间的一种典型交互模型是使用功能集群的受保护接口来提供实现功能集群的特殊功能所需的特权访问。pqRednc

从AP18-03开始,引入了功能间群集(IFC)接口的新概念。它描述了FC提供给其他FC的接口。注意,它不是ARA的一部分,也不构成AP实施的正式规范要求。这些接口在相应的FC SWS的附件中进行了描述。pqRednc

④ 机器/硬件

AP将运行在其上的硬件视为一台Machine。其背后的原理是获得一致的平台视图,而不考虑可能使用的任何虚拟化技术。该Machine可能是一台真正的物理Machine,一台全虚拟化的Machine,一台半虚拟化的OS,一个OS级虚拟化的容器或任何其他虚拟化环境。pqRednc

在硬件上,可以有一个或多个Machine,并且在一台Machine上仅运行一个AP实例。通常认为,该“硬件”包含一个芯片,可容纳一台或多台Machine。但是,如果AP允许的话,也有可能多个芯片组成一台Machine。pqRednc

3.方法论和ManifestpqRednc

对功能应用程序的分布式,独立和敏捷开发的支持需要一种标准化的开发方法。pqRednc

AUTOSAR自适应方法论涉及工作产品的标准化,用于描述诸如服务,应用程序,Machine及其配置之类的工件。以及定义这些工作产品应如何交互以实现针对自适应平台产品开发所需的各种活动的设计信息交换的相应任务。pqRednc

图3给出了如何实施自适应方法的概述草案。pqRednc

pqRednc

 图5 AP开发流程pqRednc

 pqRednc

4.ManifestpqRednc

Manifest代表一段AUTOSAR模型描述,该描述是为了支持AUTOSAR AP产品的配置而创建的,并且会上载到AUTOSAR AP产品中,并可能与其他包含Manifest文件的可执行代码的工件(如二进制文件)结合使用。pqRednc

Manifest的使用仅限于AUTOSAR AP。但是,并不是说在针对AUTOSAR AP的开发项目中生成的所有ARXML都会自动被视为清单。pqRednc

一辆典型的汽车很可能还配备了许多在AUTOSAR CP上开发的ECU,因此,整个汽车的系统设计必须同时涵盖两个方面——在AUTOSAR CP上构建的ECU和在AUTOSAR AP上创建的ECU。pqRednc

在应用程序设计时,有必要将术语Manifest的定义细分为三个不同的分区:pqRednc

应用设计 pqRednc

这种描述指定了所有与设计相关的方面,这些方面适用于为AUTOSAR AP创建应用程序软件。不一定需要将其部署到自适应平台Machine,但是应用程序设计有助于在执行Manifest和服务 Instance Manifest中定义应用程序软件的部署。pqRednc

执行Manifest pqRednc

这种Manifest用于指定在AUTOSAR AP上运行的应用程序的与部署相关的信息。执行Manifest与实际的可执行代码捆绑在一起,以支持将可执行代码集成到计算机上。pqRednc

服务Instance Manifest 此类Manifest用于根据基础传输协议的要求指定如何配置面向服务的通信。服务Instance Manifes与实际的可执行代码捆绑在一起,该可执行代码实现了面向服务的通信的相应用法。pqRednc

Machine Manifest 这种Manifest应该描述与部署相关的内容,这些内容仅适用于运行AUTOSAR AP的基础计算机(即,该计算机上没有运行任何应用程序)的配置。Machine Manifest与用于建立AUTOSAR AP实例的软件捆绑在一起。 pqRednc

不同种类的Manifest的定义(和用法)之间的时间划分得出这样的结论:在大多数情况下,将使用不同的物理文件来存储这三种Manifest的内容。pqRednc

除了应用程序设计和不同种类的Manifest外,AUTOSAR方法论还支持系统设计,它有可能在一个单一模型中描述将在系统中使用的两个AUTOSAR平台的软件组件。pqRednc

不同的AUTOSAR平台的软件组件可以以面向服务的方式相互通信。但是也有可能描述信号到服务的映射,以在面向服务的通信与基于信号的通信之间建立桥梁。pqRednc

5.应用设计pqRednc

应用程序设计描述了所有与设计相关的建模,这些建模适用于为AUTOSAR AP创建应用程序软件。应用程序设计侧重于以下方面:pqRednc

1) 用于对软件设计和实现的信息进行分类的数据类型pqRednc

2) Service Interface是面向服务的通信的关键要素pqRednc

3) 定义应用程序如何访问面向服务的通信pqRednc

4) Persistency接口是访问持久性数据和文件的关键要素pqRednc

5) 定义应用程序如何访问持久性存储pqRednc

6) 定义应用程序如何访问文件pqRednc

7) 定义应用程序如何访问加密软件pqRednc

8) 定义应用程序如何访问平台运行状况管理pqRednc

9) 定义应用程序如何访问Time BasepqRednc

10) 序列化属性,用于定义如何序列化数据以在网络上传输的特征pqRednc

11) REST Service Interface是通过REST模式与Web服务进行通信的关键要素pqRednc

12) Client 和Server 功能的描述pqRednc

13) 对应用程序进行分组,以简化软件的部署。pqRednc

在应用程序设计中定义的工件独立于应用程序软件的特定部署,因此可以简化针对不同部署场景的应用程序实现的重用。pqRednc

 pqRednc

6.执行ManifestpqRednc

执行Manifest的目的是提供将应用程序实际部署到AUTOSAR AP所需的信息。pqRednc

总体思路是保持应用程序软件代码与部署方案尽可能独立,以增加应用程序软件可以在不同部署方案中重用的几率。pqRednc

通过执行Manifest,可以控制应用程序的实例化,因此可以:pqRednc

1) 在同一台计算机上多次实例化同一应用程序软件,或者pqRednc

2) 将应用程序软件部署到多台计算机上,并在每台计算机上实例化应用程序软件。pqRednc

执行Manifest集中于以下方面:pqRednc

1) 启动配置,定义应如何启动应用程序实例。启动包括启动选项和访问角色的定义。每次启动可能取决于Machine状态和/或Function Groups状态。pqRednc

2) 资源管理,尤其是资源组分配。pqRednc

 pqRednc

7.服务Instance ManifestpqRednc

在网络上实现面向服务的通信需要特定于所使用的通信技术(例如SOME / IP)的配置。由于通信基础结构在服务的提供者和请求者上的行为相同,因此服务的实现必须在双方上都兼容。

服务Instance Manifest集中于以下方面:pqRednc

1) Service Interface部署,用于定义如何在特定的通信技术上表示服务。pqRednc

2) Service Instance 部署,以为特定的提供和所需的服务实例定义通信技术所需的凭据。pqRednc

3) E2E保护的配置pqRednc

4) Safety保护的配置pqRednc

5) 日志和跟踪的配置pqRednc

8.Machine ManifestpqRednc

Machine Manifest允许配置运行在特定硬件(机器)上的实际自适应平台实例。

Machine Manifest 集中于以下方面:

1) 配置网络连接并定义网络技术的基本凭据(例如,对于以太网,这涉及设置静态IP地址或定义DHCP)。pqRednc

2) Service Discovery技术的配置(例如,对于SOME / IP,这涉及要使用的IP端口和IP多播地址的定义)。pqRednc

3) 使用的Machine状态的定义pqRednc

4) 使用的Function Group的定义pqRednc

5) 自适应平台功能集群实现的配置(例如,操作系统提供具有特定权限的OS用户列表)。pqRednc

6) 加密平台模块的配置pqRednc

7) 平台健康管理的配置pqRednc

8) 时间同步的配置pqRednc

9) 可用硬件资源的文档(例如,可用的RAM数量;可用的处理器核数量)pqRednc

3 操作系统

1.概述pqRednc

操作系统(OS)负责Adaptive Platform上所有应用程序的运行时调度,资源管理(包括策略内存和时间限制)以及进程间通信。pqRednc

执行管理负责平台的初始化,操作系统与执行管理协同工作,执行应用程序的启动和关闭。 pqRednc

Adaptive Platform没有为高性能处理器指定新的操作系统。而是定义了操作系统接口(OSI),供自适应应用程序使用。 pqRednc

OSI规范包含作为ARA(自适应应用程序的标准应用程序接口)一部分的应用程序接口。OS本身可能会提供执行管理启动应用程序所需的其他接口,例如创建进程。但是,提供此类功能的接口尤其不能作为ARA的一部分使用,并且应定义为与平台实现有关。 pqRednc

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

pqRednc

2.POSIXpqRednc

市场上有几种操作系统,例如 提供POSIX兼容接口的Linux。但是,与平台Service和Foundation相比,应用程序对操作系统使用会更受限制。 pqRednc

一般的假设是,Application-Level类型的应用程序应使用PSE51作为OS接口,而Platform-Level类型的应用程序则可以使用完整的POSIX。pqRednc

如果Application-Level类型的应用程序需要更多功能,这些功能将取自POSIX标准,并且在可能的情况下不会重新指定。 pqRednc

Adaptive Platform Foundation和Adaptive Platform Services功能的实现可以使用其他POSIX调用。特定调用的使用将对实施者开放,并且不会标准化。pqRednc

pqRednc

3.调度pqRednc

操作系统提供了多线程和多进程支持。标准调度策略是SCHED_FIFO和SCHED_RR,它们由POSIX标准定义。pqRednc

允许使用其他调度策略(例如SCHED_DEADLINE或任何其他特定于操作系统的策略),但要注意的是,这可能无法在不同的AP产品上实现移植。pqRednc

4.内存管理pqRednc

支持多进程的原因之一是要实现不同功能集群和AA之间的“无干扰”。pqRednc

OS的多进程支持迫使每个进程位于一个独立的地址空间中,并与其他进程分开并加以保护。同一可执行文件的两个Instance在不同的地址空间中运行,因此它们可以在启动时共享相同的入口点地址和代码以及数据值,但是,数据将位于内存中的不同物理页中。pqRednc

 pqRednc

5.设备管理pqRednc

设备管理将在POSIX PSE51接口下提供。有关详细信息,请参阅POSIX规范。pqRednc

4 执行管理

1.概览pqRednc

执行管理负责系统执行管理的所有方面,包括平台初始化和应用程序的启动/关闭。pqRednc

执行管理与操作系统结合使用,以执行应用程序的运行时调度。pqRednc

 pqRednc

2.系统启动pqRednc

启动计算机后,将首先初始化操作系统,然后启动执行管理作为操作系统的初始过程之一。然后,执行管理将启动Adaptive Platform Foundation的其他功能集群和Application-Level类型的应用程序。pqRednc

Adaptive Platform Foundation启动并运行后,执行管理将继续启动Adaptive Applications。Platform-Level类型的应用程序和Application-Level类型的应用程序的启动顺序由执行管理根据Machine Manifest和执行Manifest信息确定。pqRednc

pqRednc

图6 AP启动顺序pqRednc

执行管理(可选)支持经过身份验证的启动,其中从信任“锚”开始,在保持信任链的同时启动Adaptive Platform。在经过身份验证的启动过程中,Execution Management会验证应用程序的真实性和完整性,如果检测到违规,将阻止其执行。pqRednc

通过这些机制,可以建立可信平台。pqRednc

3.执行管理责任pqRednc

执行管理负责Adaptive Platform执行管理和应用程序执行管理的所有方面,包括:pqRednc

① 平台生命周期管理pqRednc

执行管理是Adaptive Platform启动阶段的一部分,它负责对Adaptive Platform和已部署的应用程序进行初始化。pqRednc

② 应用程序生命周期管理pqRednc

执行管理负责部署的应用程序的有序启动和关闭。执行管理根据Machine Manifest和执行Manifest中的信息确定已部署应用程序的集合,并根据声明的应用程序依赖性导出启动/关闭的顺序。根据Machine状态和Function Group状态,已部署的应用程序会在Adaptive Platform启动或更高版本期间启动,但是,由于许多应用程序将为其他应用程序提供服务,因此,预计不会所有的Application立即开始活动工作。 pqRednc

执行管理不负责应用程序的运行时调度,因为这是操作系统的事。pqRednc

但是,执行管理负责OS的初始化/配置,以使其能够根据执行管理从Machine Manifest和Execution Manifest中提取的信息执行必要的运行时调度。pqRednc

4.确定性执行pqRednc

确定性执行提供了一种机制,使得使用给定输入数据集进行的计算始终在限定时间内产生一致的输出。执行管理区分时间和数据确定性。前者指出输出总是在截止日期之前产生的,而后者则指从相同的输入数据集和内部状态产生相同的输出。pqRednc

执行管理提供的支持集中于数据确定性,因为它假定时间确定性已通过提供足够的资源来处理。对于数据确定性,执行管理提供了DeterministicClient API,以支持对内部流程的控制,确定性工作人员池,激活时间戳和随机数。对于软件锁步,DeterministicClient与可选的软件锁步框架进行交互,以确保冗余执行的流程具有相同的行为。DeterministicClient与Communication Management进行交互,以使数据处理与周期激活同步。 pqRednc

pqRednc

图7 Deterministic Client说明了DeterministicClient支持的API及其与应用程序的交互pqRednc

5.资源限制pqRednc

自适应平台允许在同一台机器上执行多个自适应应用程序,因此确保不受干扰是系统属性。因此,行为不当的自适应应用程序应受到影响其他应用程序的能力的限制,例如,应避免某个应用程序消耗比指定时间更多的CPU时间,因为这可能对其他应用程序的正常运行产生潜在影响。pqRednc

执行管理通过配置一个或多个分配了应用程序进程的ResourceGroup来支持不受干扰。然后,可以为每个ResourceGroup分配CPU时间或内存限制,以限制应用程序的可用资源。pqRednc

6.应用程序恢复pqRednc

执行管理负责流程启动/停止的状态相关管理,因此它必须具有启动和停止流程的特殊权限。平台运行状况管理会监视进程,并可以触发恢复操作,以防任何进程的行为不在指定参数之内。集成商根据平台运行状况管理的软件体系结构要求定义恢复操作,并在执行清单中进行配置。pqRednc

 pqRednc

7.受信任的平台pqRednc

为了保证系统的正确功能,确保平台上执行的代码具有合法来源至关重要。保留此属性使集成商可以构建受信任的平台。pqRednc

实施受信任平台的系统的关键属性是信任“锚”(也称为信任根)。信任“锚”通常被实现为存储在安全环境中的公钥。在不可修改的永久内存或HSM中。pqRednc

系统设计者负责确保至少系统以信任“锚”开始,并保持信任直到启动执行管理。根据系统设计者选择的建立信任链的机制,可能已在系统启动时检查了整个系统的完整性和真实性。但是,如果系统设计者仅确保已经检查过已执行的软件的完整性和真实性,则执行管理在接管系统控制权时将接管继续信任链的责任。在这种情况下,系统集成商负责确保正确配置了执行管理。pqRednc

从信任“锚”向操作系统和自适应平台传递信任的一个示例(即建立信任链)可能看起来像这样:信任“锚”-根据定义是一个真实的实体-在启动引导程序之前对引导程序进行身份验证。在引导过程的每个后续步骤中,应首先对要启动的可执行文件进行身份验证。真实性检查应由已经过身份验证的实体完成,例如,真实性检查可以通过以下方式完成:例如,由先前启动的可执行文件或某些外部实体(例如HSM)决定。pqRednc

操作系统可靠启动后,它将启动执行管理作为其第一个过程。在启动执行管理之前,操作系统应确保执行管理的真实性已由已经过身份验证且因此可信赖的实体进行了验证。pqRednc

注意:如果未通过Trust Anchor本身的功能(根据定义是真实的)检查身份验证,则在应用该软件之前必须对用于验证可执行文件真实性的软件进行身份验证。例如,如果将使用Crypto API来验证可执行文件的身份验证,则在使用Crypto API本身之前,必须先由某些受信任实体对Crypto API进行身份验证。pqRednc

执行管理现在负责启动自适应应用程序,然后再启动它们。但是,存在不止一种可能性来验证可执行代码的完整性和真实性。在SWS_ExecutionManagement中,提供了完成此任务的可能机制的列表。pqRednc

责编:Admin
文章来源及版权属于汽车电子与软件,EDN电子技术设计仅作转载分享,对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。如有疑问,请联系Demi.xia@aspencore.com
汽车电子与软件
汽车电子与软件
  • 微信扫一扫
    一键转发
  • 最前沿的电子设计资讯
    请关注“电子技术设计微信公众号”
广告
热门推荐
广告
广告
EE直播间
在线研讨会
广告
广告
面包芯语
广告
向右滑动:上一篇 向左滑动:下一篇 我知道了