CAN 和TTCAN 系统延迟在Stateflow 中的仿真

李丽丹，王永康，南立军

(中国北方车辆研究所，北京100072)

目前，CAN总线是在众多领域中广泛应用的现场总线之一，TTCAN总线是在CAN总线基础上发展的基于时间触发机制的总线，延迟是评价总线系统性能好坏的主要因素之一.

在总线系统开发初期，对其性能进行预测和研究的最常用方法是计算机仿真法，像CANoe、ATI CANlab网络分析软件等基于软件的计算机仿真工具[1]，都需要相应的编程语言来实现，例如:CANoe常用CAPL语言来进行节点仿真，这样掌握起来就比较复杂.像MATLABSimulinkStateflow是图形化的仿真软件，不需要编程语言实现，比较容易掌握，而且它是采用模块化和层次化形式来建立仿真模型，便于修改、扩展.本文正是利用Stateflow这一动态系统建模仿真工具建立CAN和TTCAN的仿真模型，利用该模型，通过改变信息的发送周期，观测其对系统延迟的影响，从而证实Stateflow对总线协议进行建模仿真的可行性.

1 CAN和TTCAN的延迟及建模工具简介

1.1 总线通信延迟

TTCAN协议与CAN协议的物理层和数据链路层相同，两种协议下网络通信延迟时间的组成部分相同，主要可以分为两类:片内延迟和线上延迟[2].片内延迟与控制器的工作频率等硬件指标与控制算法的实现等软件指标相关.线上延迟与数据在网络上的发送过程相关，可以分为队列延迟和传输延迟.队列延迟指从报文进入CAN控制器等待发送到报文获得总线控制权的时间，传输延迟是从报文占据总线，到脱离总线之间的时间[3].

由于CAN协议采用的是事件触发和非破坏性逐位仲裁的机制来决定消息是否获得总线的使用权，因此，CAN协议下的总线通讯网络中消息的队列延迟和传输延迟时间均不为零[4].而TTCAN协议中的系统矩阵对于整个总线通讯时间进行了规划，网络中周期性消息帧的发送被规定在独占窗中完成，其发送不受其它消息帧的影响，所以其队列延迟为0 ms，系统中主要为传输延迟;对于非周期性消息，其延迟同CAN网络，但本文只研究周期性的消息.

1.2 建模工具Stateflow

Stateflow是嵌入在Simulink仿真环境中的，是在Simulink基础上完成动态逻辑系统建模与仿真的可视化开发平台[5].

Stateflow是图形化设计工具，每个状态自动机用一个图(Chart)来表示，每个图在Simulink中封装成一个模块，双击这个模块可以打开一个Stateflow的编辑窗口，在这个界面中可以完成所有的设计和编辑工作，仿真运行时还可以在该界面下观察状态流程.一个Stateflow图由图形对象和非图形对象构成.图形对象包括状态(State)、转换(Transition)、节点(junction)、图形函数(Graphical function)等.非图形对象则包括数据(Data)和事件(Event)的定义[6].

本文利用该工具建立了CAN和TTCAN通信系统中数据的发送部分，因此，只分析节点周期对CAN队列延迟的影响，以及TTCAN系统中不存在队列延迟，从而证明运用Stateflow工具箱来对总线协议进行建模仿真的可行性.

2 CAN总线系统仿真模型的构建

CAN总线是以事件触发为基础的总线系统，可以多个消息同时触发，这就会造成多个节点访问总线的冲突.总线冲突时利用非破坏性逐位仲裁机制，具有最高优先级的消息会赢得仲裁进行发送.根据CAN的这些特点，在Stateflow层建立的节点发送模块和总线仲裁模块分别见图1和图2.

图1 节点1的发送模块

图2 竞争总线的模块

图1显示的是节点1(node1)的发送模块，总线上其他节点发送模块的原理都与图1相同，它们之间采用parallel形式连接 (即每个模块的外围为虚线)，表示它们之间是并行的，能同时被触发，虚线框右上脚的数字表示它们的执行次序，每个节点中又包括3个并行结构的子状态:send，buffer，period_data_put.period_data_put用于采集Simulink中输入的数据Din1，然后组合成数据帧，并通过exit(node1.period_data_put.nodata)语句来触发buffer块从null转到nonnull，用于数据缓冲;之后通过exit(node1.buffer.null)语句来触发send块从sleep(无数据传输)状态转到wait(等待获得总线访问权)状态，一旦获得总线访问权，就脱离等待状态，进入transmission(传输数据)状态，当数据传输完就回到sleep状态;否则将一直处于等待状态，直到获得总线访问权.

图2竞争总线块fieldbus是通过调用compete函数来实现的.当节点有数据处于等待状态时，会置其状态标志位ni=1.compete函数利用选择结构判断每个节点的ni，之后决定节点对总线的访问权.当总线上有数据传输时，总线处于busy状态;当数据传输完之后会触发return这个事件，总线就会进入space状态，进而进入空闲状态，等待下一轮的竞争.

为了能够让Stateflow层设计的状态转移运动起来，还需要在Simulink层添加必要的输入源和输出.图3先建立了4个节点的CAN总线系统母板的仿真模型，频率为500 kHz，输入为随机分布的数，通过floor块将其变成整数，经过chart模块输出，结果会在scope模块中显示.要想修改chart模块，双击该模块就进入Stateflow的编辑界面.

图3 4个节点的CAN总线的母板模型

由于采用的是模块化设计，所以该系统很容易进行扩展，想要几个节点，就在Stateflow中添加几个状态和数据对象即行.图4是扩展的10个节点的母板仿真模型，其原理与图3相同，各个节点的子模块与图1相同，竞争总线模块只要将图2中的compete函数选择分支加成10个即行.

图4 10个节点的CAN总线母板模型

3 TTCAN总线系统仿真模型的构建

TTCAN是基于时间触发的总线，在每个时刻总线上最多只允许有一个节点发送信息，这些节点是通过周期矩阵来调度的.在TTCAN中，时间主节点周期性地发送参考消息来使网络中各节点达到时钟同步，通过调度表实现对网络中消息传输的管理与预测.参考消息标志着一个基本周期的开始，基本周期由若干个时间窗口组成，表1给出了由3个基本周期组成的矩阵周期表.

表1 系统的矩阵周期

本文要研究的是node1到node9在总线上的传输情况，以此来观测其队列延迟.不考虑参考信息，因此node0是空状态，建立的Stateflow层模型如图5所示.

图5中，1个基本周期(DB)为1个状态，它们之间以exclusive的形式连接，即DB1外框为实线，表示它们之间是互斥的关系，即每个时刻只能有1个状态处于激活态，当仿真开始时，先进入DB1，之后进入DB2，DB3，传输完成后又转移到DB1，这样循环进行直到仿真结束，n表示循环的次数.

图5 1个基本周期的模型

每个DB中又包含4个子状态，分别对应表1中的4列，也是以 exclusive的形式连接的，即node0、node1、node4、node7外框都是实线，表明它们只能通过事件来激发，即E1、E4，而图1中节点的外围为虚线，表明各个节点间是平行的，处于竞争总线状态.另外，每个节点又各自包含3个并行的状态send、buffer、period_data_put，它们中包含的具体内容见图6.

图6 node1的模型

DB1中，node0发生一个列宽时间后转移到node1，node1的状态图见图6，若有数据就传输，传输完成且到了下个节点的传输时刻，退出transmission状态，同时激发E1事件以此来触发node4(本文是利用事件E1～E8来模拟TTCAN协议中的时间主节点的)，之后，node4开始传输，依此类推;若无数据，则到时间点转移.node2到node9的模型与图6的模型只是触发事件的时间不同，即time变量不同，这里不再赘述.

为了能够让Stateflow层设计的TTCAN模型运动起来，也需要在Simulink层添加必要的输入源和输出.由于TTCAN在Simulink中的母板模块与图4基本相同，只是将node10的相关参数都改成node0，因此这里不再赘述.

4 仿真结果分析

文中对CAN和TTCAN通信系统进行了简化，只建立了它们发送部分的模型，而且1个节点只发送1个优先级的周期性报文，node1的优先级最高，其他节点依次降低.

4.1 CAN的仿真结果分析

由于CAN总线系统是多条报文竞争总线，所以其存在队列延迟.通过改变各个节点发送报文的周期改变总线负载率，从而影响系统的队列延迟，同时不同优先级的报文其队列延迟也不同.

从图1中可知，当节点处于wait状态时，n1为1;当开始传输数据时，n1变成2，所以，可以用n1为1的时间长度来反映队列延迟.这里将n1作为Stateflow的输出，可以从图3的Simulinkscope1中观测其变化规律.图7是T1=0.015 s，T2=0.01 s，T3=0.005 s，T4=0.001 s的波形图.

图7 4个节点的输出波形图

通过分析计算可得4个节点的队列延迟表，见表2.

表2 4个节点的队列延迟表

从表2可看出，优先级越高等待的时间越短.改变每个节点的周期，可以得出不同周期下4个节点的输出波形图和队列延迟表.根据队列延迟表，绘制3组不同周期下各个节点的队列延迟对比图，见图8.

图8 3组周期的延迟对比图

由图7、图8可以给出如下的分析结果:

1)在同一负载率下，优先级高的报文平均队列延迟要小，说明优先级高的报文在传输时所需的排队时间短.

2)对于同一优先级的报文，随着节点周期的减小，负载率的增加，平均队列延迟增大，说明随着负载率的升高，报文碰撞即总线仲裁的机会增多，导致排队时间增大.

3)在3组不同的周期下，优先级越低的报文平均队列延迟的时间增加的越快，说明在仲裁过程中，报文碰撞越多，优先级低的报文获得总线访问权的机会越小，导致排队时间增大的比较快.

以上的分析结果与CAN总线的传输特性相一致.

4.2 TTCAN的仿真结果分析

TTCAN中每个节点都是按照矩阵周期中分配的时间来发送的，到点即发，不存在队列延迟，下面通过仿真来观测这个现象.

在TTCAN中是通过改变基本周期和列宽来改变总线的负载率，基本周期和列宽越大，负载率越小，文中只观测了节点1、4、7的发送波形图，图9中基本周期为2 s，列宽为0.5 s.

从图9可以看出:当时间为0.5 s时，节点1开始发送，发送0.5 s之后，节点4开始发送，再过0.5 s，节点7开始发送，6 s之后DB3发送完，又转移到DB1，依次循环进行.改变基本周期为3 s，列宽为0.75 s的波形图见图10.

图10中节点1、4、7的发送时刻也是按照调度表中的时刻来发送的.

由于TTCAN中每个节点都是按照矩阵周期中分配的时间来发送的，所以从图9、图10可以看出，在不同负载率工况下，对于不同优先级的报文，队列延迟的大小不变，可见TTCAN的实时性要比CAN的好，这与TTCAN协议的传输特性一致.

图9 发送波形图

图10 改变负载率的波形图

5 结论

通过以上仿真可知，MATLABSimulinkStateflow便于扩展和修改，很多复杂的逻辑可以在一张小图表中表述，规则简单，可读性和可验证性很强，在Stateflow编辑界面中可以很直观的观察状态转换过程，便于调试和对系统原理的掌握.同时，证明了利用Stateflow对总线协议进行建模仿真的可行性.在进一步的研究中，可以加入系统的接收部分，对总线系统的其他特性进行仿真分析.另外，还可以将它和Realtime工具箱紧密集成，直接生成目标代码进行半实物仿真.

[1]杜 微.混合动力电动汽车TTCAN网络研究[D].北京:北京交通大学，2008.

[2]王俊波，胥布工.CAN报文实时性分析及在线评估[J].控制与决策，2007，22(4):448-452.

[3]王大方.基于OSEK与TTCAN的电动汽车分布式实时控制系统研究[D].北京:北京理工大学，2008.

[4]王 欢.电动汽车 TTCAN总线技术研究[D].北京:中国科学院研究生院，2006.

[5]张 威.Stateflow逻辑系统建模[M].西安:西安电子科技大学出版社，2007.

[6]邹 晖，陈万春，殷兴良.Stateflow在巡航导弹仿真中的应用[J].系统仿真学报，2004，16(8):1854-1856.