|
本文简略介绍下汽车电子范畴常用到的两种数据库：dbc，CDD（还有一种用于标定的数据库A2L自己不熟悉，这里不做说明）。 1、dbc； 习惯叫它通信数据库，dbc（data baseCAN）文件描述单一CAN网络中各逻辑节点信息，依据该文件可以用来监视和分析CAN网络中所有逻辑节点的运行状态信息。 比如现在以车载娱乐系统为例，作为与车载其他节点数据交互频繁的节点，车载娱乐系统需要实时反馈其他节点状态。最典型的莫过于与倒车雷达和车身空调控制器的交互。 OEM在研发款新车时，会先确定整车网络拓扑（谁是网管，谁是其中网络节点）。对于CAN网络，会定义网络通信内容。确定网络中有那些节点（Nodes）、用到那些CAN通信报文（Messages）、报文中包含那些信号（Signals）。这些内容一般存在方式是Excel或者PDF文件。这时将其内容编辑成数据库形式： 1、数据库为dbc； 2、编辑工具为CANdb++Editor 编辑界面如下：
如图上所示，包含了与车载娱乐系统进行数据交互的所有CAN节点。 （1）、Node表示与所研发ECU有数据交互的其他节点； （2）、Message表示CAN通信报文； （3）、Signal表示通信报文中包含的信号，这些信号以通信矩阵（8*8）的方式存在，如下图：
编辑好通信数据库dbc文件，可以带来以下几点好处： 1、对于supplier，自己所研制的ECU需要跟车身其他部件通信进行数据交互。但是其他部件一般情况下不容易直接获取。这时候通过CANoe（Vector公司一款很强大的工具）加载dbc数据库仿真整车网络，方便供应商调试； 2、将dbc数据库加载到上位机，通过数据库可以解析通信报文的物理意义，而不是干巴巴的十六进制报文（如下图）。
2、CDD CDD是业界常用的诊断数据库，通过CANdelaStudio工具编辑生成。其作用是贯穿需求提出-功能实现-集成测试-售后整个全流程（如下图）：
（1）、OEM提出诊断需求规范，定义要使用到的诊断服务、通信参数、DID、DTC等各种需求； （2）、供应商基于需求规范完成功能实现（代码）。这里提一句，随着用户对车辆控制器性能要求越发严苛，代码运行稳健性日益重要。通过工具配置生成代码在汽车电子行业内所占比重增加，而手写代码比重降低； （3）、功能实现后，需要检测功能实现是否是按照需求规范实现的，测试代码的稳健性。分为手动测试和自动化测试： ---手动测试
如上图，需要富有工作经验的工程师基于需求规范编写测试规范，由测试规范编写测试用例。最终由测试工程师按照测试用例中Step1到Step N逐步执行，并记录每一步的响应结果。 ---自动化测试 整个范畴可以分为两类： A：由工程师手动编写测试脚本，然后自动化运行测试脚本； B：由工具自动化生成诊断测试用例（当然需要加载诊断数据库）并自动化运行。 对比两种测试方式，手动测试整个流程涉及到不同工程师，需要对内容的理解有一致性。并且这种方式耗费时间。 数据库带来的好处
基于具体诊断需求规范编辑生成对应的数据库（使用CANdelaStdio编辑CDD文件），将数据库加载到对应的代码配置工具（如Geny 、DaVinciConfigurator）配置生成对应的协议栈（例如AUTOSAR）；
通过上位机（比如CANoe）,加载诊断数据库CDD文件，可以解读诊断请求以及响应的报文含义，如下图：
对于工程师可以从交互界面获取所需要的信息。 而对于另一个常见的诊断数据库格式ODX，我会以一个整模块分享。 ----------------------------------------- 作者简介 | 穿拖鞋的汉子 汽车电子工程师 来，每天进步一点点！ |
|
|
