CAPL编程实现诊断刷写,车联网FOTA流程自动化测试(方案篇)
原创内容,转载请注明出处
本文围绕车联网的ECU,TBOX的FOTA升级业务展开描述。主要讲如何通过CANoe编程实现自动化测试, 验证TBOX在FOTA业务过程中作为一个诊断仪刷写整车其它ECU的流程、以及业务逻辑处理的正确性。通常情况下,主机厂都采用实车测试的方式验证FOTA业务。但是实车测试对对手件的稳定性有很高要求,在整车项目开发的很长周期内,整车上的所有的ECU都处于开发阶段,前期是无法开展TBOX的FOTA功能的验证工作的,所以仿真测试就势在必行了。
一、业务需求拆分
FOTA(Firmware Over-The-Air), 关键行为拆分为两点:下载 and 安装。
无论实车测试亦或仿真测试,“下载”这个过程都是一样的,并且“下载”不必需依赖于实车,也不依赖于对手件。所以需要仿真的部分集中在车内网络。主要问题就是解决车内ECU的仿真,总线网络节点建模,ECU逻辑实现。
二、物理组网环境
分析实车与仿真的差异,先列出脱离实车后组网模型上的必需件。12V B+供电源,业务触发的必需件ECU(根据TBOX的功能设计可确定必需存在的ECU),仿真设备CANoe, 工作站PC
实车测试组网示意图:
仿真测试组网示意图:
对比可以看到,仿真的测试方案新接入了电源,除了必需存在的主机外,其余的ECU(EPS,PEPS,BCM,ACU,TCU等)全由{PC+CANoe}仿真实现。
三、测试方案选择
TBOX的FOTA安装过程,是基于UDS协议实现的刷写。所以此处FOTA安装流程的本质就是编程模式下的诊断写入过程。
我们透析需求,实际上就需要做一件事:编程实现车内行为仿真。抽丝剥茧,层层深挖下来又是两点需求
1、解决车内网络通信信号的仿真
2、解决TBOX作为诊断仪在总线上诊断请求的实现 与 被刷写ECU的诊断应答(被刷写ECU的应用层业务逻辑封装)
重点讲第2点,需处理单对单的物理寻址请求,单对多的功能寻址请求。
我的设计思路是建立两条链路,分别支持物理寻址,功能寻址。接下来是选择从哪一层去实现,不同层所用的协议不一样,其实现的复杂程度也不一样。举个例子,要建一个Client与Server进行网络通信,如果你对底层比较清晰,可以直接采用套接字实现。否则你可以选择较上层的协议去实现。
CAN总线的OSI模型,见下图:
分析优缺点:
从数据链路层/物理层切入实现,需兼顾帧格式的问题,包含多帧分包传输,流控策略,连续帧拆分与组装等。在保证数据正确性上要写过多逻辑。且对ISO 11898有比较深的了解。 虽然整体框架和逻辑简单,可扩展性差。
从传输层切入实现,托管了数据处理的细节,ECU间的耦合度低,是比较好的选择。不过框架设计会复杂一些。
具体实现方案:基于CANoe的CanTp建模库,在CAN上实现了传输协议ISO/DIS 15765–2,控制传输大量数据,支持多通道并发。仿真整车上支持OTA的节点,每个节点都可通过两个连接(物理寻址-Connection 1 和 功能寻址-Connection 2),使用OSEK TP节点层DLL与诊断仪通信,在同一连接上在同一时间可以发送和接收数据。仿真FOTA刷写流程。
通信模型与系统框架:
CAPL代码具体实现,详见下一篇
最新文章
- 树莓派 基于Web的温度计
- Checklist For Choosing The Right Database Engine
- SQL判断字符串里不包含字母
- YII CJson类
- 动态脚本,在js里面又写js
- Qt5.4静态编译方法
- Histogram Equalization
- 记录Spring.net学习中遇到的各种问题
- Mahout之(四)Taste的架构和部署Demo
- 无论url请求什么.都可以拼接class类名.实例化.传递get参数-->;给当前控制器-->;传递给抽象父类-->;都交给抽象父类.这个方法去处理call_user_func_array()
- js-txt文本处理
- 使用XMLHttpRequest异步通信
- JDK+Tomcat搭建JSP运行环境--JSP基础
- PDFBox 打印带背景的文件速度慢
- Effective Java 第三版——19. 如果使用继承则设计,并文档说明,否则不该使用
- MSB4064 错误
- MySQL备份脚本-亲试ok
- wampserver_x86_3.0.6 允许外网访问配置教程
- 《Linux内核设计与实现》学习总结 Chap4
- 2017年要学习的三个CSS新特性