CAN总线车载网络通讯组件的研究和实现
1 引言
目前,汽车电子正朝着网络化的方向发展,车载网络成为汽车电子领域的最大热点。提高控制单元间通讯可靠性并且降低导线成本的网络总线应用中的关键技术包括CAN、LIN、FlexRey、MOST、IDB1394 等。对于汽车整车厂来说,CAN 网络设计是应用CAN 网络通讯的关键。纵观现有的设计技术,可以将其分为两类:一类是以仿真和测试为主的传统设计方法;另一类是以协议设计为主的方法。传统方法将每个节点对协议的要求拼凑起来,通过仿真、测试的方法检验协议的正确性,最终得到通讯协议。新方法通过系统设计技术,用理论方法对系统的时序建模,分析设计系统的通讯协议,保证系统的实时性能以及协议的正确性,最终发布正确的通讯协议。本文将简要介绍传统设计方法的局限性和新方法的优势,以及参考新方法所设计的通信网络软件系统。
2 传统设计方法的局限性
随着汽车上电子设备数量的逐渐增多,车载网络系统也越来越复杂,汽车电子网络面临着巨大的挑战。传统网络协议设计技术的局限性越来越突出,主要表现在数据丢失、通讯延迟、协议修改困难等三个方面。
2.1 数据丢失
数据丢失是指新数据没有来得及通过网络传输出去,或是超过接收节点的接收时限才传输出去的情况。数据丢失会严重影响通讯的实时性能,进而影响整车通讯的质量。实时性能好的系统应该完全避免数据丢失。
数据丢失的影响因素就是通讯协议。传统设计方法通过仿真和测试等手段检测协议的正确性,其缺点是无法覆盖所有的测试用例,因此,输出的通讯协议会存在潜在错误或者不够完整,这样就不可避免地会产生数据丢失的情况,影响整个系统的性能。
2.2 通讯延迟
通讯延迟是指数据准备好到通过总线发送出去的等待时间。通讯延迟可能导致数据丢失,是传统设计方法无法解决的根本性问题。这主要是因为,传统设计方法只是将各个节点对协议的要求拼凑起来,没有考虑整个系统的需求,比如发送节点发送数据到接收节点接收数据并用于控制,没有考虑实现这样一个完整功能的时间要求。因此协议设计结果难以保证实时性能,必然存在通讯延迟。
仲裁失败是产生延迟的主要原因,因此延迟与消息的 ID 及周期有关。系统越复杂,消息之间发生竞争的可能性越大,系统的实时性能就越差。
为了减小延迟的影响,传统设计方法采取了两种预防措施。一种是设定时限,如图1所示。另一种限制负载为平均30%左右,降低消息竞争的可能性。但是这两种方法都不能从根本上消除延迟。
图 1 时限设定和响应时间的计算
2.3 协议修改困难
修改协议在开发过程中不可避免。但对于传统的设计方法,因为应用程序和通讯功能的融合,通讯协议的参数变化会导致软件的重新编译和测试,这就意味着额外的时间和成本,供应商极不愿意整车厂商修改协议。因此,整车厂商修改协议十分困难,并需要很长的时间。
3 以协议设计为主的新方法的特点
以协议设计为主的方法通过系统级的设计理论和方法,保证通讯协议的准确性,避免数据丢失,保证系统的实时性能。其特点概括起来如下:
3.1 系统级设计,避免数据丢失
新技术采用自上而下的系统设计技术,对整个系统的架构进行设计,并完成优化。通过理论设计方法,可保证通讯协议的正确性,从根本上解决数据丢失问题。
3.2 有效控制消息延时
响应时间是消息准备发送到最后节点接收到数据的全部时间,它是发送时间和延迟的总和,其中延迟是影响响应时间的主要因素,控制延迟就可以有效控制响应时间。
如图 1 所示,通过对响应时间进行建模,并仔细安排消息的ID 和周期以控制延迟时间、响应时间及总线负载。然后用理论方法计算出最差情形下的延迟时间、最大的响应值,以及总线负载。
由于新方法能够计算出最大总线负载,也能有效控制系统延迟,因此没有必要再对系统的总线负载作任何限制,理论上可以达到100%。其优势在于保证了确定的通讯行为,可以有效地利用系统资源。
3.3 分隔应用程序和通讯协议,保证变更灵活性
如图 2 所示,新方法为ECU 通讯功能提供了标准的网络通讯组件。该组件将应用程序和通讯协议成功分隔开来,使得各自的修改互不影响,保证了协议修改的灵活性。网络通讯组件提供面向总线、应用程序和通讯协议三方面的标准接口。面向应用程序的接口是基于信号的操作,不包含通讯协议的参数。面向通讯协议的接口负责识别通讯协议。只要遵守接口标准,协议可以进行任意改变,而且不影响应用程序。
图 2 分隔应用程序和通讯协议
这种设计方案其优势在于整车厂商可以很容易地修改协议,不需要供应商支持,因此保证了系统变更的灵活性,同时
- 对TTCAN的分析(05-26)
- 嵌入式Win CE中CAN总线控制器的驱动设计与实现(05-01)
- μC/OS-II的多任务信息流与CAN总线驱动(07-11)
- 采用CAN总线实现DSP芯片程序的受控加载(11-08)
- 基于DSP的电动汽车CAN总线通讯技术设计(10-08)
- 基于DSP的CANopen通讯协议的实现(01-18)