[行业规范] 诊断功能在AUTOSAR中开发流程

[复制链接]
查看834 | 回复0 | 2022-4-10 13:22:24 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册 |

x
车载诊断技术 牌照.jpg
背景信息
在实现诊断功能过程中,主机厂和供应商会使用多种不同的流程,并采用不同的数据交互格式(保证流程数据一致性)和工具。但是问题往往出现在多个开发者和工具之间交互诊断描述文件时。
为了保证数据的完整性、一致性和正确性,工程师在处理数据时面临很大的挑战。但新的AUTOSAR诊断数据文件格式(ARXML)给解决此问题提供了可能性。诊断相关的基础软件模块(DCM/DEM/FIM)根据主机厂统一配置,软件模块集成通过ARXML来实现。

数据库文件格式ARXML最初发布在AUTOSAR 4.2.1版本中。AUTOSAR 4.3.0在标准UDS协议之外,增加了OBD-II(商用车排放)、WWH-OBD(重型卡车排放)、FIM和SAE J1939(国内现阶段主要用于充电桩)的相关扩展内容。另外AUTOSAR标准没有重新定义诊断协议、诊断服务以及对应数据内容,而是直接复用UDS(ISO 14229)和OBD-II(ISO 15031)等。
car-4361321.jpg
解决流程
全球统一诊断数据库ODX文件可作为通用诊断仪的数据格式:
->描述诊断协议:适用于ISO 14229、ISO 15031、ISO 11898、ISO 13400、ISO 15765等;
->ECU和诊断仪间的数据传输:映射到OSI七层模型,从物理层到传输以及会话层表示层等具体定义;
->诊断仪解析数据的方法:在数据库中定义诊断请求和响应的内容以及具体含义,比如对DID数据的解析(电压值、电流值、软硬件版本号等)。
注:相应的ODX介绍可参看文末关于ODX的介绍。

对于诊断仪来说,待测车辆的数据库来自哪里其实并不关心,所关心主要是数据库必须描述清除诊断数据及其结构(通过ODX UML模型实现),以往需要工程师通过手动方式将诊断数据与ECU应用层关联(工作量大不说,还也别容易出错)。
ODX数据库用于故障存储数据描述时,与ECU Software功能实现策略还是有很大的不一样性,比如用于故障DTC检测的去抖算法(时间去抖和次数去抖),会定义DTC产生机制(比如次数,当Software检测到当前状态满足记录条件,在Counter会+1,下一个周期检测不满足会-1,直到Counter值达到预定义的值,表示DTC产生并记录在ECU掉电非易失内存中)。但是ODX整个数据库架构中完全没有这部分信息(起初定义该数据库也是偏向用于售后使用场景,对于前期软件实现功能涉及不是很多)。再加上每一个主机厂的ODX企业级实现指南都存在不同,因此使得ECUC(ECU配置信息)的交互更复杂(信号交互)。
注:ODX企业级指南是主机厂定义ODX实现策略,比如对应每一个UDS服务名称、调用方式、DID调用策略等等。
AUTOSAR ARXML是专为满足BSW输入数据的需求而设计,如下图是AUTOSAR关于诊断功能实现示意图:

从物理层(车载总线类型CAN、LIN、FlexRay等)到传输层,通过PDUR传输给诊断模块(DCM/DEM等),若DCM可以处理接受到的诊断请求,单独处理。若需要跟RTE进行交互,比如从SWC获取应用层相关数据,例如DTC检测当前ECU电压值,就需要从SWC获取采样模块采样当前的电压值。
这个时候需要定义好与SWC交互的Link关系:

该数据Link关系从诊断模块DCM/DEM到SWC,需要在数据库中配置好,对应生成代码即可直接使用。
在AUTOSAR中,诊断功能对应协议UDS、OBD、WWH-OBD、J1939对诊断服务、子服务、DID以及DTC的选择;
-> 故障DTC路径和故障内存存储方式;
-> UDS/OBD诊断数据元素和相关的数据包内容;
-> 诊断数据元素与Software Application的映射关系;
-> 功能禁用模块(FIM)与功能降级策略。
若将上述内容实例化,比如ECU诊断DID实例解析关系包含16 bits的DID,其中映射一个或多个数据元素,在ECU诊断需求规范中会定义DID数据的Name和Type。在ODX数据库中数据类型建模,对于软件功能实现时,AUTOSAR相应代码配置工具可复用已存在的系统模板模型,抓取其中特征点,解析数据库模型关系,从应用层到物理层整个链路打通。

为了读、写或者重写DID,软件基础代码BSW需要与应用层软件交互(SWC),这时候会用到ARXML中存在的元素——诊断映射关系。诊断映射规定了BSW诊断内容之间的关系:
->Routine:诊断例程,可通过Routine ID定义用户需要实现的功能;
->DID数据:读取或写入ECU内部运行信息、状态信息;
->Event和Application的软件组件(SWC)。
为达到与AUTOSAR体系架构数据交互一致性,在定义SWC的接口时,需要遵循AUTOSAR定义的建模方法:
1、通过不同通信模式调用客户端/服务器的接口(Client/Server Port);
2、通过收/发接口来读/写ECU数据(Provide /Require Port)。
以往工程师不得不手动配置BSW和应用层软件间端口的关联;当使用ARXML时,这一操作自动Map对应关系。因此会减少配置时间以及错误,并在提高Software质量的同时缩短开发时间。
诊断开发过程中应用场景和对应角色
在使用工具和数据交互之外,车载诊断功能开发流程的体现在OEM和Tier1的分工不同:
1、由OEM完成设计:
系统级将诊断功能、应用场景做系统级别设计并具体细化Map关系;
2、由OEM和Tier 1联合进行诊断开发:
主机厂和供应商共同设计开发,当然这些供应商都有较高技术积累;
3、由Tier 1独立完成开发:
对供应商能力要求更高,特别是软件开发能力。在互联网技术公司不如车赛道后,这个需求更加明显。
应用场景1:OEM主要完成诊断设计
-> OEM创建系统设计(功能、应用场景包括SWC的诊断接口);
-> OEM提供ECU诊断规范:规定整车、ECU级别诊断需求规范,定义使用到服务、DID、DTC;
-> Tier1承接OEM的诊断规范并按照需求实现其功能。

应用场景2:Tier1扩充OEM诊断需求规范
-> OEM创建系统设计(包括SWC的诊断接口、调用Map关系、事件触发条件);
-> OEM设计ECU诊断需求规范:整车级以及ECU级别,伴随着域控制器在整车电子电气架构使用增多,系统级设计彰显更加重要,包括DTC存储策略、功能降级策略;
-> Tier1扩展ECU诊断需求设计:供应商基于自身技术积累,将以往项目经验迭代到项目中,会根据实际情况增补ECU诊断需求设计;
-> OEM更新Tier1修改的诊断规范:供应商基于自身技术积累,扩展了ECU诊断需求后,主机厂审核后会将增补的内容更新至自己规范中,这样达到一个良性循环。

场景3:Tier1创建ECU诊断需求规范
->   Tier1创建SWC的诊断接口:具备很高技术积累的供应商,诊断系统工程师会设计SWC诊断接口与DCM、DEM等诊断模块的接口设计;
->   Tier1创建适用于SWC的诊断需求规范:创建规范、实现功能;
->   OEM接手Tier1的诊断需求规范:主机厂接受供应商需求规范,并更新至自己规范中。
为达到以上三种需求,AUTOSAR ARXML文件中的元素需是供工程师可选的。根据不同的流程,创建并丰富其内容(最好是通过系统级的工具,有良好的人际交互界面)。创建的数据是正确合规且可实现交互。

工具链相关的需求
诊断开发流程需要工具链的支撑。工具链的好处在于从需求端(在流程开始阶段),通过需求管理系统定义诊断需求点。由诊断需求规范解读获取应用层软件与诊断服务相关的需求。

注:其中重点是系统设计与ECU具体实现映射关系、ECU级别诊断设计和SWC口Map关系。
在自顶向下的开发流程中,最先开发的是诊断应用层Software。诊断数据源自需求和应用层软件的接口描述(为保证数据的一致性、有效性和正确性,通过业界常用数据库更合理)。
ARXML文件被创建编辑,同步创建ODX数据库。从同一源头生成ODX和ARXML数据,可以确保诊断仪与ECU的诊断软件相匹配,也能保证数据的一致性。
因此采用系统级设计工具,设计整车级别诊断需求内容管理和对应关系,采用具体ECU诊断数据编辑工具编辑单个ECU诊断描述内容,导入代码配置工具生成对应的Software,达到功能。最后将系统级设计工具与单个ECU链路打通,实现高效性和一致性要求。

总结和展望
AUTOSAR ARXML提供了诊断开发领域的新可能,包括数据的精确描述(包括BSW配置信息的获取),OEM和Tier1之间的分布式诊断开发,以及自顶向下自动集成ECU的诊断功能。
为达到我国汽车行业崛起,不再是国外主机厂代工厂,要求从系统级别到单个ECU级别都有整盘考虑。
您需要登录后才可以回帖 登录 | 立即注册 |

本版积分规则