车载软件架构 —— Adaptive AUTOSAR软件架构中通信管理、诊断管理策略 我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师（Wechat：gongkenan2013）。 老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师： “ 本就是小人物，输了就是输了，不要在意别人怎么看自己。江湖一碗茶，喝完再挣扎，出门靠自己，四海皆为家。人生的面吃一碗少一碗，人生的面见一面少一面。人生就是一次次减法，来日并不方长。自己的状态就是自己最好的风水，自己的人品就是自己最好的运气。简单点，善良点，努力点，努力使每一天都开心，不为别人，只为自己。
本文大体如下： 1、通信管理 2、诊断管理 3、持续性 一、通信管理 1.1 概述 通信管理负责分布式实时嵌入式环境中应用程序之间通信的所有方面。其背后的概念是对寻找和连接通信伙伴的实际机制进行抽象，使应用软件的实施者能够专注于其应用的特定目的。 1.2 面向服务的通信 服务的概念是指在基本操作软件已经提供的功能之外，为应用程序提供的功能。通信管理软件为 Machine 内通信和 Machine 间通信提供了提供或使用此类服务的机制。服务由以下内容组合而成 -> 事件; -> 方法; -> 字段. 通信伙伴之间的通信路径可以在设计、启动或运行时建立。该机制的一个重要组成部分是服务注册中心，它充当中介实例，也是通信管理软件的一部分。 Service-oriented communication 每个提供服务的应用程序都要在服务注册中心注册这些服务。要使用某项服务，消费应用程序需要通过查询服务注册表找到所需的服务，这一过程称为服务发现。 1.3 语言绑定和网络绑定 通信管理提供了向应用程序实现者展示已定义服务的标准化方法(上层，语言绑定)以及服务数据在网络上的相应表示方法(下层，网络绑定)。这确保了源代码的可移植性和编译后的服务在平台不同实现中的兼容性 语言绑定定义了如何利用目标编程语言的便利功能，将服务的方法、事件和字段转换为可直接访问的标识符。性能和类型安全(在目标语言支持的范围内)是首要目标。因此，语言绑定通常由源代码生成器实现，源代码生成器由服务接口定义提供。 Example Language and Network Binding 网络绑定定义了如何将已配置服务的实际数据序列化并绑定到特定网络。它可以根据通信管理配置(AUTOSAR 元模型的接口定义)，通过解释生成的特定服务配方或直接生成序列化代码来实现。目前，通信管理支持 SOME/IP、DDS、IPC(Inter-Process-Communication 或任何其他自定义绑定)、信号 PDU(SignalBased 网络绑定)和Signal-Based 静态网络绑定。 本地服务注册表也是网络绑定的一部分。 请注意:语言绑定和网络绑定之间的接口被视为通信管理软件内部的专用接口。因此定义该接口的规范性规格目前不在范围内。不过，我们鼓励平台供应商为自己的软件独立定义这样一个接口，以便在其平台实施中轻松实施 C++ 以外的其他语言绑定和其他网络绑定。 1.4 C++语言绑定的生成代理和骨架 C++ 语言绑定的上层接口为 AUTOSAR 元模型接口描述中定义的服务提供了面向对象的映射。 作为通信管理软件开发工具一部分的生成器会生成 C++ 类，其中包含每个服务的字段、事件和方法的类型安全表示。 在服务实现端，这些生成的类被命名为服务提供者骨架。在客户端，它们被称为服务请求代理。 对于服务方法，服务请求代理提供了同步(阻塞调用者直到服务端返回结果)和异步调用(被调用函数立即返回)机制。调用者可以并行启动其他活动，并通过核心类型ara::core::Future 的特殊功能在服务端返回值可用时接收结果。平台实现可配置为生成器创建模拟类，以便在相关服务端尚未可用时轻松开发客户端功能。同样的机制也可用于客户端的单元测试。 客户端可以直接使用代理类，而用于 C++ 绑定的服务提供者骨架只是抽象基类。服务实现应从生成的基类派生并实现相应的功能。 1.5 静态和动态配置 通信路径的配置可在设计时、启动时或运行时进行，因此可分为静态配置和动态配置完全静态配置 完全不需要服务发现，因为服务端知道所有客户端，客户端也知道服务端。 不需要应用程序发现代码 客户端知道服务端，但服务端不知道客户端。事件订阅是应用程序中唯一的动态通信模式。 应用程序中的完全服务发现 在配置时不知道通信路径。服务发现 API 允许应用程序代码在运行时选择服务实例。 1.6 服务合同版本化 在 SOA 环境中，服务的客户端和提供方都依赖于涵盖服务接口和行为的合同。在服务开发过程中，服务接口或行为可能会随时间发生变化。因此，我们引入了服务合同版本管理，以区分服务的不同版本。AUTOSAR 自适应平台支持服务设计和部署阶段的合同版本管理。此外，客户端的"服务发现"可配置为支持版本向后合并。这意味着，如果提供的服务版本与客户端所需的服务版本向后兼容，客户端服务就可以连接到不同的服务版本。** 1.7 原始数据流接口 除了面向服务的通信外，通信管理还提供了一个独立的 API，用于处理面向外部 ECU(如 ADAS 系统中的传感器)的原始二进制数据流。API 是静态的，实现了客户端应用程序建立与服务端通信通道的功能，以及服务端应用程序等待客户端传入连接的功能。 API为客户端和服务端都提供了销毁通信通道的功能，以及通过通信通道读写原始数据(字节流)的功能。原始数据流通道可由集成商通过应用部署信息进行配置，例如包含网络端点信息和选定的协议。目前，TCP/IP 套接字将被用作传输层，但未来还可添加其他替代方案。原始数据流接口在命名空间 ara::com::raw 中可用。 二、诊断管理 2.1 诊断概述 诊断管理(DM)实现了基于 ISO 14229-1(UDS)和 ISO 13400-2(DoIP) 的 ISO 14229-5(UDSonIP). 诊断管理是自适应平台基础层的一个功能集群，配置基于经典平台的 AUTOSAR 诊断提取模板(DEXT)。支持的传输层是 DoIP。DoIP 是一种车辆发现协议，设计用于与诊断基础设施(诊断客户端、生产/车间测试仪)进行车外通信。 车内或远程诊断通常使用其他传输协议，因此提供了API，通过自定义传输层扩展平台。 UDS 通常用于车辆生产和车间维修。 2.2软件集群 原子可更新/可扩展部件由 Software Clusters(SWCL)管理。Software Cluster 包含所有与更新安装或部署特定新功能/应用相关的部件。因此，自适应诊断管理支持每个已安装 SoftwareCluster 的 DiagnosticAddress。同时，它也支持为整个 Machine 或任何诊断部署提供单个 DiagnosticAddress。因此，一个DiagnosticAddress 总是有自己的诊断服务端实例。每个 SoftwvareCluster 都有自己的诊断服务端实例，可为诊断提供独立开发，如独立的 ODX 文件。请注意，SoftwareCluster 也与 UCM 的软件包结合在一起，因此SoftwareCluster 可以更新或新引入到 Machine 中。 每一个SWCL有一个诊断地址 每台Machine一个诊断地址 2.3 诊断通信子集群 诊断通信子群集实现了诊断服务端(如经典平台的 DCM)。目前支持的服务有限，但在未来的版本中将扩展对更多 UDS 服务的支持。 DM 根据 ISO 14229-1 支持多客户端处理。这可以满足现代车辆架构的需求，包括多个诊断客户端(测试仪)的数据采集、后台访问以及一些经典的车间和生产用例。 2.4 自适应应用诊断(AA) DM 作为诊断服务端将传入的诊断请求(如例行控制或 DID 服务)发送到相应 AA 的映射提供端口。 为此，AA需要提供专门的 DiagnosticPortInterface。 2.5 类型接口与通用接口 DiagnosticPortInterfaces 有不同的抽象层次: RoutineControl 报文可作为 类型接口 API签名包括所有请求和响应报文参数及其原始类型。DM 负责序列化。该 API针对特定的 RoutineControl 报文 通用接口 API签名只包括请求和响应报文的 Byte-Vector。应用程序负责请求和响应报文的序列化。同一 API可用于多个 RoutineControl 报文。DataIdentifier 报文可作为 API 签名，包括所有请求(用于写入)和响应信息(用于读取)参数及其原始类型。DM 负责序列化。 通用接口 API 签名只包括用于请求和响应信息的 Byte-Vector。应用程序负责请求和响应报文的序列化。 单个 DataElement 每个请求和响应报文参数都有自己的接口。这是最高级别的抽象，即请求和响应信息结构的任何变化都不会对 API产生影响。此外，同一诊断信息的参数可能处于不同的Process 中。 2.6 诊断对话 如上所述，DM要求伪并行处理，因此它支持诊断对话，以反映诊断客户端和诊断服务端之间的不同对话。诊断服务端由相应 UDS 请求的目标地址标识，并在自适应平台运行期间动态分配。 2.7事件存储器子集群 事件存储器子集群负责 DiagnosticTroubleCode(DTC)管理(类似于经典平台的DEM)。 激活的 DTC 代表车辆中肯定检测到的问题(通常对生产或车间很重要)。DM 负责管理DTCs及其配置的SnapshotRecords(一组关于 DTC 发生时间的配置环境数据)和/或ExtendedDataRecords(属于DTC的统计数据，如重复发生的次数)的存储。 检测逻辑称为诊断监控器。该监控器向DM中的Diagnostic Event报告最近的检测结果。 UDS DTC 状态来自一个或多个 DiagnosticEvent. DTC 可分配给 PrimaryMemory(通过 19 02/04/06访问)或可配置的 UserMemories(通过 0x19 17/18/19 访问)。 消抖策略支持基于次数和时间两种方式。此外，DM 还提供内部转换通知:DTC 状态字节变化、DiagnosticEvents 重新初始化的监控需求以及快照或 ExtendedDataRecord 是否发生变化时，都会通知相关方。 如果 DTC 在配置的操作周期内没有激活，它就会从 DTC 内存中消失, DM支持对启用条件的通用处理。启用条件可用于在特殊条件下控制 DTCs的更新，如在欠压条件下禁用所有与网络相关的 DTCs。 2.8 面向服务的车辆诊断 随着 R23-11 版本的发布，诊断功能集群引入了与ASAM 相关的SOVD概念。主要功能包括 SOVD 网关、SOVD 到 UDS 的转换、后台连接、授权和近距离挑战。 三、持续性 3.1 持续性概述 持久性为自适应平台的应用程序和其他功能集群提供了在自适应 Machine 的非易失性内存中存储信息的机制。这些数据可在启动和点火周期内使用。Persistency 提供访问非易失性存储器的标准接口。 Persistency APIs将 PersistencyInterfaces 的标识符作为应用程序的参数，以寻址不同的存储位置。可用的存储位置分为两类: A：Key-Value 存储 B：文件存储 每个应用程序都可以使用多种存储类型的组合 自适应应用程序中持久性的典型用法 持久性数据始终是一个应用程序的一个 Process 的私有数据。不同 Process 之间没有使用持久性共享数据的机制。做出这一决定是为了防止在通信管理功能之下出现第二条通信路径。 持久性可处理同一应用程序的多个线程在同- Process 上下文中运行时的并发访问。要创建对 Key-Value 存储或文件存储的共享访问，可以将 OpenKeyValueStorage 和OpenFileStorage 返回的 SharedHandle 传递(即复制)给另一个线程，也可以在独立线程中调用 OpenKeyValueStorage 和 OpenFileStorage，分别用于同- Key-Value 存储或文件存储。 持久性可以保证存储数据的完整性。它使用几余信息来检测数据损坏。余信息包括CRC 代码、哈希值和"M out of N"模式。这些机制既可以一起使用，也可以单独使用。 持久性还提供 Safe 存储。这基本上是通过几余来实现的，但还有一个附加功能，即如果存储的数据出现任何问题，即使可以通过几余数据恢复，也能让应用程序知道持久性可为应用程序提供有关所用资源数量的统计数据。它还能确保不超过给定的配额。 持久性可对存储数据进行加密，确保敏感数据在存储到物理设备之前就已加密，从而确保存储数据的保密性。持久性还提供使用 MAC(消息验证码)的验证功能，以确保存储数据的真实性。 3.2 Key-Value 存储 Key-Value 存储提供了一种在一个存储位置存储和检索多个 Key-Value 对的机制。Key.Value 存储器直接支持以下三种数据类型: 1、SWS AdaptivePlatformTypes中定义的数据类型 2、应用程序中复杂类型流产生的简单字节数组。 3、所有通过 dataTypeForSerialization 由 PersistencyKeyValueStorageInterface 调用的实现数据类型，或在应用程序设计中专门用作该接口的 PersistencyDataElements。 为了能在更新过程中将值从一种类型迁移到另一种类型，持久性提供了数据类型映射可将当前使用的数据类型映射到以前版本中为同一键使用的一组数据类型。每个Key-Vale 存储的键都必须是唯一的，并由应用程序使用 Persistency 提供的方法来定义。 3.3 文件存储 并不是所有与持久性存储相关的数据结构都适合使用 Key-Value 存储针对这类数据，引入了文件存储机制。文件存储端口允许应用程序访问存储位置，并在其中创建一个或多个访问器。这些访问器同样由 String 格式的唯一密钥标识。为了更好地理解这种机制，可以将其与文件系统进行比较:文件存储端口可以理解为一个文件系统目录，允许应用程序在其中创建多个文件(访问器)。 3.4 处理 UCM 持久数据的用例 一般来说，在 ECU 或自适应 Machine 的生命周期内，UCM 支持三种主要用例来处理自适应应用程序。 -> 在自适应计算机上安装新的应用软件; -> 将现有应用软件更新到自适应计算机; -> 从自适应 Machine 卸载现有应用软件. 在前两种情况下，应用程序由 UCM 通过 EM 触发，以验证安装/更新，然后触发Persistency，根据 Manifest 中 Persistency 的配置部署/更新应用程序的持久数据在第三种情况下，UCM 使用 Persistency 配置中的 URIs 删除剩余的持久性数据Persistency 支持将持久性数据部署到 Key-Value 存储器和文件存储器的下列方案。 -> Persistency应能部署应用程序设计者在自适应应用程序安装过程中定义的持久化数据; -> 持久性应能部署由集成商更改的持久性数据; -> 持久性应能部署集成商定义的持久性数据. -> 在安装新版本的应用程序时，持久层应能根据为 Key-Value 存储或文件存储配置的更新策略覆盖或保留持久数据， 一般来说，持久层是在应用程序设计和部署过程中配置的。持久性应能使用部署阶段配置来覆盖应用设计配置。如果缺少部署阶段配置，则在部署持久性数据时将考虑应用设计中的配置。 搁笔分享完毕！ 愿你我相信时间的力量 做一个长期主义者！ 电子电器架构刷写方案——General Flash Bootloader
车载软件架构 —— 闲聊几句AUTOSAR OS（九）
车载诊断数据库——诊断问卷调查表与CDD关联关系
车载软件架构 —— 闲聊几句AUTOSAR OS（八）
车载软件架构 —— 闲聊几句AUTOSAR OS（七）
电子电气架构——车载DoIP通信汇总
车载软件架构 —— 闲聊几句AUTOSAR OS（六）
诊断测试工具CANoe.DiVa从入门到精通系列——开门见山
电子电气架构 —— OEM关于DTC具体实现相关见解
车载软件架构 —— 闲聊几句AUTOSAR OS（五）
车载软件架构 —— 闲聊几句AUTOSAR OS（四）
车载诊断协议 —— 诊断服务Service 11
车载软件架构 ——闲聊几句AUTOSAR OS（三）
车载软件架构 —— 闲聊几句AUTOSAR OS（二）
车载诊断协议-ISO 14229
车载诊断协议-ISO 14229 / 13400 /15765
车载软件架构——闲聊几句AUTOSAR OS（一）
电子电气架构——IP地址获取方式
车载通信架构 —— 传统车内通信网络MOST总线（光纤传输、专精多媒体）
电子电气架构——车载诊断通信参数
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报 。
