Adaptive AutoSAR将逐渐成为车辆高性能计算机 (HPC) 的基础,因为它集成了以下功能:
高性能计算机要求OnBoard 和 OffBoard 诊断必须能适应车辆及其环境中逐渐增加的软件复杂性,其支持的传输层是DoIP。
为了能实现和 Adaptive AutoSAR的交互, A D-PDU API will have an additional protocol module for Diagnostics over IP (车载或远程诊断通常使用其他传输协议,因此提供了使用自定义传输层扩展平台的API,见下图) ;此外,UDS 和 ISO 规范也将被扩展以包含一些新功能「including: ISO 14229-1(UDS);ISO 13400-2(DoIP);ISO 14229-5(UDSonIP)」。
DoIP是一种车辆发现协议,诊断的流程如下:
注意:每个自适应ECU可以同时拥有多个诊断地址(Diagositic Address),每个软件集群 (SWC) 有一个诊断地址以及相关联的诊断管理器。自适应ECU通常会有 5 到 10 个软件集群。
图 1 两个软件集群的自适应ECU及外部诊断仪
如图所示, ECAS 「ECAS (Electronically Controlled Air Suspension )意为车辆空气悬挂的电子控制系统」包含两个(诊断)应用程序。
这两个应用程序不必同时处于活动状态。它们可以在ECAS ECU运行期间根据需要来动态启动和停止。 根据车型配置的版本高低,应用程序也可以有需要的进行裁剪(根据软件配置永久打开或关闭特定功能)。
例如,在上面的例子中,并线辅助(ADAS.LCA)功能是一种收费功能,默认情况下关闭该车辆功能,通过额外的付费来定制和激活该功能。
综上所属,具有诊断功能的应用程序可能不是同时可用的,甚至某些功能可能在车辆中永久被停用。因此,测试人员必须熟悉并能够使用 VIN「Vehicle Identification Number」 管理相关车辆数据。(不能假设ECU诊断管理器中的所有 DTC 信息都是最新的或可用的)
两个软件集群,每个都有自己的诊断地址,也需要两个 ODX文件(参见诊断描述文件的区别一章)来管理诊断数据。当有诊断请求时,Autosar 诊断协议栈将基于诊断请求PDU的地址来分发给相应软件集群的诊断管理器。
图 2 带有自适应 Autosar 的车辆的扩展诊断功能
目前,Classic Autosar 诊断协议栈循环检查Ecu特定的硬件模块(如电压,电流)是否有错误,发现的任何错误都存储在诊断管理中,并执行特定的错误reaction「通过FMEA(即失效模式和影响分析 )进行分析所采取的错误应对(reaction),通常是通过备份设计来保障正常功能的执行;例如飞机姿态传感器有四个,其中一个主传感器出现故障时,切换到组件中的其他三个备份传感器」。
某些子系统故障将不可避免地对其所集成的系统产生影响。为了确保正确考虑这些故障的影响,Autosar 配备了事件概念,可用于通知其他应用程序已发生的模式更改。
例如,某个姿态传感器故障时,受影响的飞机平衡功能模块也将在收到相应的故障事件(组件系统级别)。
车载诊断测试仪通过 DoIP 收集错误事件,然后决定如何处理错误故障(当然诊断DoIP也可用于获取车辆模块即乘客行为的数据,用于提升下一代产品更加人性化的服务)。
在此过程中,OnBoard Tester不仅可以访问原始UDS诊断信息,而且作为自适应Autosar应用程序,它还可以通过ARA::COM接口主动访问其他应用程序的其他接口进行深入分析。
图3 诊断与控制单元软件联合开发流程
如图所示,E/E 开发过程从车辆要满足的Product需求开始分析,及规划的Product变体(Product+Variablity)。随着数据的复杂性及规模庞大性,现有的方案如下:
ODX(Open Diagnostic Data Exchange)文件是一种开放式的标准化诊断数据格式,用于整车生命周期中诊断数据的交换。
PDX为所有ODX文件压缩文件的格式。 ODX是由ASAM制定的用来描述诊断规范的数据格式(MCD-2 D/ISO 22901-1),目前ODX诊断标准已在各大OEM全面施展开来。 但是后来DEXT开始进入市场,已经被多家OEM和供应商使用并提供支持。
DEXT(Diagnostic Extract Template)是AUTOSAR定义的诊断提取模板,用于DCM(Diagnostics Communication Manager)、DEM(Diagnostics Event Manager)以及FIM(Function Inhibition Manager)的需求及配置定义。
DEXT最初发布在AUTOSAR 4.2.1中。AUTOSAR 4.3.0在标准UDS协议之外,增加了OBD-II、WWH-OBD、FIM和SAE J1939的相关扩展内容。DEXT不仅描述通过各自协议传输的数据,还包括ECU应用层软件中的初始数据(数据的来源)。
当上述两种数据的描述完整正确时,即可通过DEXT配置AUTOSAR诊断相关BSW。 AUTOSAR标准没有定义诊断协议、诊断服务和数据,而是直接使用了UDS和OBD-II的定义
组件功能介绍
• ara::diag:基于 ISO 14229-1(UDS)、ISO 13400-2(DoIP)实现基于 IP 的诊断功能ISO 14229-5(UDSonIP)
♦ 通过诊断服务器,实现DEM诊断事件管理和DCM 诊断通信管理:
DEM 诊断事件管理主要提供诊断事件服务,处理诊断事件,记录操作循环状态,维护 DTC 状态和存储事件数据;
DCM 诊断通信管理主要提供诊断会话管理,诊断请求转发和UDS服务处理
♦ 支持配置多个诊断服务器,每个诊断服务器支持配置不同服务,且支持被多个Tester并行访问
♦ 实现传输协议管理:支持DOIP协议,后续可扩展和兼容其他传输层协议
使用DEXT,不仅可以描述相应协议传输的数据,还可以描述ECU应用软件中数据的来源。当且仅当两种类型的信息均可用时,才可以完全配置基础诊断软件。
AUTOSAR协议中定义了两种通用用例的诊断的配置过程。此过程涉及以下三方:
在用例1中,一些软件组件由OEM(或OEM的供应商)实现,并且Diagnostic Extract数据的首次合并由OEM执行。
在用例2中,OEM通过Diagnostic Extract提供诊断需求,多个Application Developer提供与其实施相关的信息,合并完全由ECU-Supplier执行。
此外,用例1和用例2也可以结合使用。ECU供应商也可以实施软件的某些部分,包括其相应的Diagnostic Extract。
图4 the ECU Development work-flow
对OEM而言,OEM或diagnostic requester使用Diagnostic Extract来定义一个或多个ECU诊断接口。它还可能会将一些Internal Behavior定义为ECU-Supplier或Application Developer的需求,例如:
DEXT可以满足AUTOSAR诊断模块的需求,主要应用于开发阶段的代码设计,支持AUTOSAR Classic以及Adaptive平台。
目前市场上,为了减少AUTOSAR配置的复杂性,会选择使用ODX或者CDD文件导出DEXT做AUTOSAR实现,虽然CDD(.cdd)、ODX(.odx或*.pdx)以及DEXT(*.arxml)都是描述诊断相关信息的数据库,但是它们并不能互相替代,侧重覆盖的应用场景也不一样。
如果使用ODX或者CDD做AUTOSAR实现,必然是需要补充ODX/CDD转DEXT所缺失的数据才能满足需求。
VisualODX 3.0版本通过EXCEL诊断问卷调查表扩展了DEXT定义所需支持的内容,新增了对服务及DID的Access Permission定义,和对事件(Event)数据的支持。
图4 EXCEL诊断问卷调查表Service页定义
该版本可以直接通过用户的诊断问卷调查表导出ODX/DEXT文件,不仅可以满足客户AUTOSAR架构中诊断模块软件实现的DEXT数据,而且能保证数据的同源,方便统一的维护。
图5 VisualODX软件ODX数据导出界面
诊断管理 DM 实现了 ISO 14229-5(UDSonIP),ISO 14229-5 基于 14229-1(UDS)和 ISO 13400-2(DoIP)。
DM 是 AP Foundation 层上的 Functional Cluster(FC)。
DM 的配置基于传统 CP 的 AUTOSAR Diagnostic Extract Template(DEXT)。
DM 支持 DoIP 作为传输层协议。
DoIP 是一个车辆发现协议,用于和诊断基础设施(诊断仪、工厂/售后测试仪)的 off-board 通信。
车载或远程诊断一般会使用其他传输层协议,为此 AP 提供了扩展自定义传输层的 API。
UDS 广泛用于车辆的生产和售后维修。
The atomic updateable/extendable parts are managed by SoftwareClusters(SWCL)
*SoftwareClusters(SWCL)*管理原子可升级/可扩展部分。
SWCL 包含与部署/更新功能/应用相关的所有部分。
DM 支持为每个安装的 SWCL 分配独立的诊断地址。
SWCL 也和 UCM 的软件包耦合,所以 SWCL 可以被更新或者新安装的一台机器上。
诊断通信子簇实现了诊断服务(好比 CP 中的 DCM)。目前只支持有限的诊断服务,后续的 Release 将扩展支持更多的 UDS 服务。
除了 ISO 14229-1 中的伪并行客户端支持,DM 还进行了扩展,可以在默认会话下支持客户端的全并行处理。满足了现代汽车架构的需求:
DM 作为诊断服务端,分发诊断请求(比如 Routine Control 和 DID 服务)到 AA 所映射的 Providing Port。AA 需要提供专门的 DiagnosticPortInterface。
DiagnosticPortInterface 有不同的抽象层级:
adaptive autosar中DCM的主要功能和作用有以下几点¹:
源: 与必应的对话, 6/1/2023
(1) Adaptive Platform AUTOSAR. https://www.autosar.org/standards/adaptive-platform/.
(2) Comparison of AUTOSAR Classic and Adaptive Platforms. https://www.mathworks.com/help/autosar/ug/autosar-platform-comparison.html.
(3) Adaptive AUTOSAR-Diagnostic Manager-概述和UDS传输层 - 知乎. https://zhuanlan.zhihu.com/p/259678095.
(4) Standards AUTOSAR. https://www.autosar.org/standards/.
DM 要求支持伪并行,诊断会话要能反应不同的诊断客户端和服务端的会话。诊断服务端是通过 UDS 请求中的 Target Address 来确定,且在 AP 中运行时动态分配。
根据我的搜索结果,adaptive autosar中DEM的主要功能和作用有以下几点¹:
(1) Adaptive Platform AUTOSAR. https://www.autosar.org/standards/adaptive-platform/.
(2) Standards AUTOSAR. https://www.autosar.org/standards/.
(3) AUTOSAR Adaptive | Vector. https://www.vector.com/de/de/know-how/autosar/autosar-adaptive/.
事件存储子簇负责 DTC(Diagnostics Trouble Code)的管理(好比 CP 中的 DEM)。Active DTC 表示一个检测到的问题(对产线和维修站很重要)。DM 管理 DTC 的存储、配置的 SnapshotRecords(当发生 DTC 时的一组环境数据)和/或 ExtendedDataRecords(属于 DTC 的统计数据,如重复发生次数)。
检测逻辑叫做 Diagnostic Monitor。Monitor 向 DM 的 DiagnosticEvent 报告最近的测试结果。UDS DTC 状态源自一个或多个 DiagnosticEvent。DTC 可以存储在主存储(通过 访问)或可配置的用户存储(通过1902/04/06访问)或可配置的用户存储(通过19 17/18/19 访问)。
DM 支持基于计数器或者基于时间的消抖。此外,DM 提供有关内部转换的通知:
如果 DTC 在配置的操作循环数内都处于非 Active 状态,则 DTC 将从 DTC 存储中擦除。DM 支持对启用和存储条件的全局处理。启用条件可用于在特殊条件下控制 DTC 的更新,例如在欠压条件下禁用所有与网络相关的 DTC
NDP数据包 可参考 https://blog.csdn.net/zhishenluo/article/details/103729512
0x00: reserved
0x01: DoIP ISO/DIS 13400-2:2010
0x02: DoIP ISO 13400-2:2012
0x03…0xFE: reserved by this part of ISO 13400 0xFF: default value for vehicle identifcation request messages
【0x0001至0x0004】用于汽车标识上报或请求,只能通过UDP报文来发送这种命令,主要用于在汽车和诊断仪进入网络之后、诊断连接建立之前的车辆发现过程。
【0x0005 和0x0006】标识的Routing activation request 和 response用于在socket建立之后,进行诊断通信的请求。
【0x0007和0x0008】用于Alive check,用于检查当前建立的诊断连接socket是否仍然在使用中,如果不再使用,则关闭socket释放资源。
【0x8001,0x8002,0x8003】,分别代表的含义分别是诊断消息、诊断消息正响应和诊断消息负响应。
就是标识后面的user data的长度。 此外源地址和目标地址可以参考UDS中定义即可,用户数据即为诊断相关服务数据。
DoIP实体内管理着一个DoIP connection table ,用来记录和维护诊断通信的逻辑连接。上图就是这个表中的一个元素,即一个逻辑连接的状态机。上图中的方框就是连接所处的状态,[Step]是状态之间跳转时发生的事情。
[Step1] 当一个新的套接字建立,逻辑连接的状态就从“listen”跳转到“socket initialized”,同时启动一个定时器, initial inactivity timer。
[Step2] 当DoIP实体接收到tester发来的一个routing activation信息后,逻辑连接的状态就从“socket initialized”跳转到“Registered [Pending for Authentication]” ,此时 initial inactivity timer被停止,启动一个名为general inactivity timer的定时器。
[Step3] 在完成Authentication之后,逻辑连接的状态就从“Registered [Pending for Authentication]”跳转到“Registered [Pending for Confrmation]” 。
[Step4] 在完成Confrmation之后,逻辑连接的状态就从“Registered [Pending for Confrmation]”跳转到“Registered [Routing Active] ” 。
[Step5] 如果initial timer 或general inactivity timer 过期后仍没收到后续请求,或者authentication 和 confrmation 被拒绝了,又或者外部测试设备对alive check 消息没有响应,则逻辑连接进入“Finalize”状态。
[Step6]进入Finalize后,此时TCP套接字将被关闭,并重新回到“listen”状态。
当DoIP实体和外部测试设备都连接到一个网络中时,它们会利用DHCP协议获得一个属于自己的IP地址。在网络中,路由器作为DHCP server,为新加入到该网络中的设备分配IP地址。在获取IP地址之后,有两种车辆发现的方法,如上图所示。一种方法是车辆主动上报自己的信息3次。如果测试设备没有收到车辆主动上报的信息,则会发送一个identification request,如果网络中有车辆的话,车辆对这个请求进行响应,测试设备便发现了被测车辆。
在诊断仪发现车辆之后,会把车辆添加到自己的车辆列表中。当用户选择这个列表中的某辆车,如果连接建立成功,用户就可以对车辆进行诊断了。 接下来用户给汽车发出诊断信息,网关会根据信息接收对象把诊断信息转发给网络中相关的ECU,当得到ECU 的响应之后,网关再把最终的响应发送给诊断仪。当用户选择退出时,用于DoIP通信的这个套接字就被关闭了。
Diagnostic in Adaptive AutoSAR - 知乎 (zhihu.com)