Adaptive AUTOSAR 19-11和19-03的差异比较

Explanation of Adaptive Platform Design -- AUTOSAR AP R19-11

change history

从修改历史来看，改动看起来蛮多的

更新了架构逻辑视图

更新了执行管理，通信管理，信息安全，诊断，持久性，状态管理，网络管理，更新配置管理，平台健康管理，核心类型模块。这些更新已经体现在软件规范SWS中了，这次只是同步一下

更新了一些分类的小错误

文档的状态从Final改到公开

目录部分

诊断这一部分改动比较大

改动比较大的还有十三章介绍UCM

第一章和第二章都是一些非常General的描述，直奔第三章

3.

首先是逻辑架构图做了修改

19-03 AP架构逻辑视图

19-10 AP架构逻辑视图

主要改动有四处

1. 更改了ara::log的位置

2. 更改了ara::crypto的位置

3. 更改了ara::ucm service的位置

4. 删除了ara::s2s service模块，移到了ara::com模块，改成了Signal PDU.

5. ara::diagnostic 模块从service 划分到了foundation

5.执行管理

5.2 系统启动

在系统启动这个章节加了补充说明

机器启动的时候，首先初始化OS，接着EM作为OS初始化进程的一部分被加载。EM加载完成后，会启动其他的功能集合和平台级别的应用程序。完成之后，EM继续加载其他应用程序。平台级别的应用程序和Adaptive应用程序的启动顺序由EM根据machine manifest and execution manifest中的信息决定。下图为AP启动顺序。

下面就是本章补充说明的部分

第五章 补充说明部分

EM模块也可以支持认证启动，从信任锚启动。Adaptive平台启动的时候同时维护这个信任链。在认证启动期间，EM会检查应用程序的可靠性和完整性。如果检测到违规行为，启动就会停止。通过这些机制，建立可信任的平台。

新增 章节 5.7 Trusted Platform 可信任平台

5.7 可信任平台

为了保证系统功能的正确性，确保代码在平台上执行的时候有一个合法的开端是很重要的。保持这个特性可以让集成商构建一个可信任的平台

系统实现可信任平台一个关键属性 是信任锚（也可以成为信任锚）。信任锚可以被认为是一个存储在安全环境中的公钥，比如，存在不可更改的持久内存或HSM中。

系统设计者要负责保证至少系统启动从信任锚开始，而且这种信任要保持到EM启动完成。根据系统设计者选择的建立信任链的机制，整个系统的可靠性和完成性检查在系统启动的时候已经完成。但是，如果系统设计者只保持已经执行的软件的可靠性和完整性检查，当EM接管系统控制权的时候，由EM来继续负责这个信任链。这种情况下，系统集成商只要保证EM正确配置即可。

信任锚从OS传递到Adaptive 平台（信任链的建立）的一个例子像这样：信任锚-定义的认证实体-在bootloader启动之前验证bootloader。在接下来的每一个启动步骤，首先要先验证将要启动的应用程序。可靠性检查可以由一个已经认证过的实体来做，比如认证检查可以由之前启动的可执行程序来检查，或者由外部实体比如HSM 来检查。

在OS认证启动之后，作为第一批要启动的进程中的一个，EM要被加载。在EM被启动之前，OS要保证EM的可靠性已经被认证过，因此是值得信任的。

注意：不过不能被 信任锚本身的功能做可靠性检查，用来做可靠性检查的软件，在使用之前必须要进行认证。比如，如果用Crypto API来认证可执行文件，Crypto API自己在使用之前需要被其他的可信任的实体进行检查。

EM模块现在承担认证在Adaptive 应用程序启动之前的认证。但是 认证可执行代码的可靠性和完整性有多种方式。在SWS_ExecutionManagement文中，列举了多种方式完成这项工作。

5. 通信管理

7.2 language binding and network binding

这一小结增加了补充说明

目前，CM模块支持SOME/IP,DDS, IPC(进程通信或其他绑定)，信号PDU（基于信号的网络绑定）

同时增加了两个小节

7.6 Service contract versioning 服务合同版本

在SOA环境中，客户端和服务合同这依赖一个合同。这个合同包含了服务的接口和版本。在服务开发的过程中，服务的接口和行为会发生变化。因此为了表明各个合同之间的不同引入服务合同版本。AUTOSAR 平台在服务的开发和部署阶段支持和同版本。另外，客户端的服务发现可以配置以支持版本的向下兼容。这意味着客户端服务可以连接服务端提供的不同版本，如果客户端要求的这些服务是向下兼容的。

7.7 原始数据流接口

除了面向服务的通信，通信管理模块也为处理外部的ECU的原始二进制数据流提供独立的API， 比如来自ADAS系统传感器的数据。 这些API是静态的，实现的功能又为客户端建立通信通道，断开通信通道，读写通信通道上的原始数据。原始数据流通道可以由集成商来配置，通过配置部署信息，比如网络末端节点信息和选择的协议。目前，传输层协议用的是TCP/IP,也许将来有其他的替代协议。原始数据流接口的定义在命名空间ara::com::raw

9.诊断

诊断之前都是划在service这一类的，19-11标准中划在了foundation分类中。诊断这一章改动很大，我要重新翻译了。

9.1 概述

诊断管理模块实现了基于ISO 14229-1(UDS)和ISO 13400-(DoIP)的ISO 14229-5(UDSonIP)

诊断管理属于Adaptive平台基础层的一个功能集合。19-11明确了属于foundation，不是service

配置仍然和classic AutoSAR的DEXT一样

传输层支持DoIP。DoIP是一个车辆发现协议， 为使用诊断基础设备（诊断客户端，产品/workshop tester)的场外通信设计。

车内或远程诊断通常使用其他的协议，因此提供API扩展使用定制化传输层的平台

UDS通常使用在车辆的生产中或工作车间内来修理车辆。在当前的（HDV）或将来的（LDV）的法规中，UDS也可以用于OBD（排放相关的诊断）

软件簇 Software Cluter (SWCL)

原子的更新扩展部分有软件簇（SWCL）来管理。一个SWCL包含和更新安装相关的所有部分，或部署新的功能和应用。因此Adaptive 诊断管理器支持每个SWCL有自己的诊断服务服务器，每个SWCL有自己的诊断地址。注意SWCL也是和UCM的软件包耦合的所以SWCL可以更新或引入到新的机器

9.2 诊断通信子集

诊断通信子集实现了诊断服务器（类似Classic平台的DCM）。目前支持的服务是有限的，后续的发布版本中会支持更多的服务。

除了处理ISO 14229的假并发客户端外，诊断管理（DM）可以支持并行处理不同诊断客户端的默认会话。 这样可以满足现代汽车架构的要求，包括数据手机，从后端和一些经典workshop访问和生产场景。如果SOTA（software over-the-Air)序列在默认会话中实现的话，并发客户端处理时可能的。

AA（Adaptvie Application)中的诊断

DM作为诊断服务器分发收到的诊断请求，然后映射到对应AA提供的端口。为了实现这个，AA需要提供一个特别的DiagnosticPortInterface.

类型化的 VS 通用接口

DiagnosticPortInterface不同的抽象层

日常控制消息

* 类型化接口

API签名包换所有请求和应答消息的原始类型参数。DM负责序列化。

API独立于特定的日常控制消息。

*通用接口

API签名只包含请求和应答消息的字节向量。应用程序负责请求和应答消息的序列化

相同的API可用于多个日常控制消息

数据标识服消息

*类型接口

API签名包换所有请求和应答消息的原始类型参数。DM负责序列化。

*通用接口

API签名只包含请求和应答消息的字节向量。应用程序负责请求和应答消息的序列化

*数据元素独立

每个请求和应答消息参数有子集的接口。这是最高级别的抽象。换句话说，任何请求和应答消息接口的改变都不会影响API. 未来，相同诊断消息的参数可以用在不同的进程中。

诊断对话

根据上面提到的DM要求假并行处理，它支持诊断对话来反应诊断客户端和诊断服务器之间不同的对话。根据UDS请求，诊断服务器通过目标抵制来表示，并且在Adaptive平台上是在运行期间动态分配的。

9.3 事件内存子集

事件内存子集负责DTC（DiagnosticTroubleCode)的管理(类似Classic平台的DEM）。

一个激活的DTC代表在车上某个检测到的事件（通常对生产或工作间很重要）。 DM管理DTC的存储和配置的快照记录（在DTC发生的瞬间配置的环境数据的集合）或者扩展的数据记录（统计数据属于DTC不日重复发生的次数）。

检测逻辑被称为诊断监控。 监控是报告最近的特使结果到DM的诊断事件中。 UDS DTC的状态是源自 一个或多个诊断事件。

DTC会被发配到主要内存中或可配置的用户内存中。

counter和Timebase支持消除抖动。而且，DM提供关于内部转化的通知：DTC状态字节的变化，诊断事件需要监控重新初始化，并且如果快照或扩展的数据记录的变化，都会通知到兴趣方。

如果DTC没有激活配置的操作周期数，它就会从DTC的内存中消失。

DM 支持Storage and enable conditions 的处理。 Enabling Conditions可以用来某些特殊场景下DTC的更新。比如低电压条件下disable所有网络相关的DTC。

10.持久性

本章没有什么大的改动。

* 错误单词的修正。assessor 改为accessor

*文件代理改为文件存储。 file-proxy 改为file-storage.

新加的两段的翻译

持久性用来处理同一个应用的多线程的并发访问，这个应用程序运行在同一个进程的上下文中。为了创建键值存储或文件存储的共享访问，OpenKeyValueStorage和OpenFileStorage返回的ShareHandlerk可以被另一个线程访问或OpenKeyValueStorage和OpenFileStorage可以被相同的键值存储或文件存储的不同的线程分别调用。

持久性负责存储数据的完整性。 它使用冗余信息来检测数据损坏。这些冗余信息包括CRC校验码和“M out of N”模式。这些机制可以一起使用也可以独立使用。

持久性提供关于使用资源数量的应用统计

11. 时间同步

这一章没有改动

12.网络管理

这一章没有改动

13.更新配置管理

改动非常大

14.身份和访问管理

这一章没有变化

15.加密

这一章没有变化

16.日志追踪

只有一个小变化

对于日志的每一个严重等级，都有独立的函数提供给AA或功能簇使用。

17.功能安全概述

功能安全的描述在AUTOSAR_EXP_SafetyOverview这篇文章中

17.2 E2E 保护

本次发布E2E支持

* 轮询模式下的周期性和混合周期性时间

* 方法 （关于限制详见AP SWS Communication Management)

本次发布还没有支持的

* 回调模式的时间

* 非周期性事件

* 方法(没有限制)//这一点有点迷糊，似乎跟上面有点矛盾，不是很理解

17.2 平台健康管理

这一小节重新翻译，因为流程图有了很大的变化。

平台健康管理监控软件的执行。它提供监管功能 （所有的监管功能都可以被单独使用）

* 存活监控

* 期限监控

* 逻辑监控

* 监控频道监控

存活监控检查一个被监控的实体运行不是太频繁也不是太少。

期限监控检查被监控的实体中的步骤是不是在配置的最小和最大实践内执行完成。

逻辑监控检查执行的这些控制流是不是匹配当初设计的控制流。

存活，期限和逻辑监控的执行是基于检查点的报告。这些检查点是通过应用程序或簇/服务的API ReportCheckpoint实现的。

健康频道检查给平台健康管理供了挂钩外部监控结果（比如RAM测试，电压监控。。。）的可能性

平台健康管理的执行是基于健康状态的报告实现的。这些健康状态是通过应用程序或簇/服务的API ReportHealthStatus实现的

如果在被监控的实体中探测到失败，平台监控管理可以触发一个可配置的恢复动作

平台健康管理和其他功能簇

从上图可以看出跟PHM交互的几个模块

1 和执行管理模块的交互

EM会通过API ReportPorcessInfo()报告进程信息给class ReportProcessInfo，当进程状态发生变化的时候会报告给PHM

同时PHM也会通过Class RequestRecoveryAction()请求EM执行恢复操作。在class RequestARecoverAction中有两个公共函数 EnterUnrecoverableState()和ProcessRestart( processID), 从名字中不难猜出这两个函数执行什么操作。

2. 和HW Watchdog的交互

是通过impementor specific交互

3. 和诊断管理的交互

和DM模块的交互目前还没有定义

4. 和状态管理模块的交互

PHM和state management 交互通过 ara::com模块中的class FunctionGroupState 进行。这个类中有一个公共的成员FunctionGroupState和一个公共函数RequestState()。State Manager会向PHM模块报告FunctionGroupState，同时PHM也会向State Manager请求状态

5. 和Safety 应用程序或其他PHM实体的交互

PHM模块和safety应用程序/其他PHM 实体交互是通过ara::com模块中的ApplicationRecoveryActionHandler和Handler Eable实现的。ApplicationRecoveryActionHandler有一个public的函数ApplicationRecoveryActionHanlder(). Handler Eanble有两个public的函数Offer()和StopOffer().

6 和应用程序或簇/服务的交互

PHM和这部分的交互是通过PHM模块的三个类来实现的。其中一个class是 ReportHealthStatus,这个类用于HealthChannel监控，这个类有一个公共的函数ReportHealthStatus(HealthStatus)。另外两个类用于被监控的实体，这两个类分别是ReportCheckPoint和GetSupervisionStatus. Class ReportCheckPoint和class GetSupervisionStatus用于被监控的实体。类ReportCheckpoint有一个公共函数ReportCheckPoint(Checkpoint)。类GetSupervisionStatus有两个公共函数GetGlobalSupervisionStatus(0和GetLocalSupervisionStatus().

7. 和清单的交互

PHM模块可以通过配置Manifest来配置AA或其他的功能簇和服务

Adaptive AUTOSAR中PHM模块的恢复操作的应用场景

* 请求状态管理切换到一个特定的功能组合状态

* 请求执行管理强制切换到一个特定的不可恢复的状态

* 请求执行管理重启某个特定的进程

* 请求看门狗驱动执行看门口重置（实现者特定的API）

* 报告错误信息给DM :这次发布还没有发布

* 转发错误信息给应用程序

本次发布已知的限制

* 目前只支持一个PHM实例。当前不支持多个PHM实例或多个实例的菊花链

* 对诊断管理的依赖还没有定义

* 健康管理对相关监管模式的配置在本次发布中还没有支持。

CP和AP共享的功能在文档RS_HealthMonotoring和SWS_HealthMonitoring命名为 'Health Monitoring'.

AP额外的规范在文档RS_PlatformHealthManagement和SWS_PlatformHeathManagement中命名为'Platform Health Management'

18 核心类型

只修改了一些措辞。