CAN调度理论与实践分析

CAN调度理论与实践分析

  分布式嵌入式系统是当前嵌入式系统的重要发展方向,因为它能提供更强的性能,节约系统的总体成本。但是由于各单个节点必须有通信网络相连才能协调地工作,网络就成了关键部分,没有网络提供及时正确的数据和命令,就谈不上所设计的系统服务了。在汽车的分布式嵌入式系统中,目前主流的通信网络是CAN总线。CAN是事件触发的通信协议,它根据消息的优先等级和节点的状态自动地调度消息的传送。低优先级的消息会因同时发生的高优先级消息太多而不能及时发送,高优先级消息也有可能由于节点状态等的影响而丢失。关于CAN的局限问题可见参考文献[1]。本文主要从调度理论方面讨论CAN系统的问题,这些问题与工程应用有非常大的关系,实践意义很强。

1  Tindell的分析方法和Davis的改进

  1994年,Tindell [23]首先将分析单处理器任务调度方法改造成适用于CAN总线的调度方法,求取消息的最坏响应时间。对于与安全相关的应用,只有对最坏响应时间有确切的掌握,才是合理的。CAN通信在网络上的实现经过2个阶段:通信任务将消息发到发送的通信控制器(CC),发送的通信控制器将消息发到接收的通信控制器。广义地讲,响应时间是从需产生通信的事件发生到消息到达目标节点的时间,包括发送节点host内的处理时间,host到CC的时间,总线上消息仲裁传送时间,接收CC到host的处理时间。仲裁获胜的消息开始传送后,便不能被中止,所以CAN调度是固定优先级非抢先式任务调度。消息m用到的参数定义如下:

  Tm ——启动通信的事件间隔,即周期;
  Jm——由事件发生到消息开始送CC的时间之最大变化,即抖动;
  Cm—— 在总线上传送消息m所需时间(要考虑位填充形成的最大值);
  Dm——由应用决定的传送消息m允许的时限;
  Rm——实际的最坏传送时间;
  Wm——传送消息m时最坏等待时间。

  它们之间的关系如图1所示。

  为了印刷的方便和易于理解,这里用了不同的写法,其中顶函数Ceiling返回的是最接近(大于等于)变量的上限整数, τ是1位时间。Ceiling( (Wm+Jk+τ)/Tk)表示在Wm时段内高优先级消息k会出现的最多次数。于是有:

  式(7)代表最坏等待时间已超时限,消息m不可调度。

  按优先级降低的次序逐条校验消息是否可调度,就可验证整个通信系统是否可调度。

  在2006年实时网络会议上,Bril、Davis等人发表了有关Tindell算法有漏洞的文章,后来他们又提出了完整的改进算法[4]。作为反例,表1中消息C用Tindell算法是可调度的,最坏响应时间为3 ms;但第2次消息C的传送已超时限,如图2所示。Tindell算法仅考虑了消息C的第1次传送。

表1  Tindell算法的反例

图2  消息C的最坏响应时间为3.5 ms

  另外,如将消息B和C的周期缩短为3.25 ms,按照Tindell算法,系统由于未求得最大的最坏响应时间,故仍是可调度的,但实际上总线的利用率已超过100%。Davis的方法核心是引入忙周期的概念,再对忙周期内各次传送的响应时间求最坏值,详见附录1。(见本刊网站www.mesnet.com.cn——编者注。)

  Tindell的开创性工作对后续的研究与应用有巨大的影响,Volcano通信技术公司(现在的Mentor Graphics)以此理论为基础开发了商用的CAN调度分析软件。由于漏洞的发现,用户应检验软件是否有了新的补丁以及用它完成的应用是否受影响。

2  笔者对Davis算法的简化

  Davis算法要先算出忙周期,再在忙周期中消息m多次传送中寻找最坏等待最大的那次。基于以下考虑,计算可以简化:

  在忙周期中,消息m传送时有高优先级消息进入队列,使m的后续消息发送前可能插入更多的高优先级消息,代表仍有一个对总线需求的高峰,从而有可能使后面的消息m有更大的最坏响应时间。

  最坏的情形是消息m刚发送,所有高优先级消息就进入队列,即领先于发完消息m后的第一个发送空隙的相位达到最大。

  因此求消息m的最坏响应时间就有两种可能: 用Bm产生阻塞,像Tindell那样求消息m的最坏响应时间;由Cm产生阻塞,求下一个消息m的最坏响应时间,下一个消息m的排队时间为Tm-Jm。

  简化方法的优点是减少了计算的次数,从而减少工作量。

  这种算法与Davis算法中的保守算法有两点不同:一是用Cm来产生阻塞是真实可能发生的,例如从休眠到上电时消息m比高优先级消息早了一点;二是本算法得到的是确切的而非保守的结果。

  计算方法:

  第1次,用公式(5)~(7)计算Wm,得到Wm(0);

  第2次,用公式

  就本例而言,在Ch=Cx=55位(0字节数据)、Ci=135位(8字节数据)、Cl=0时,总线利用率与可调度性的关系如表3所列。

表3  总线利用率与可调度性的关系

3.3  硬件选用对可调度性的影响

  Tindell [2]比较了两种通信控制器,认为像82C200一类的通信控制器只有一个发送缓冲器,从而会引起很大的滞后或抖动。例如一个节点有3个消息要传送,它们的优先级分别为H、 M、 L1,其他节点的消息优先级为L2、 L3、L4。对82C200来说,当要发送H而M已在发送缓冲器里时,就要中止M的发送,而将H写入,H发完后再将M写入,由于这些动作都需占用一定时间,而在这些时间里总线可能为其他节点的消息所占用。一次H的抢先,会造成M多次延迟而引起问题(详见附录2)。SJA1000与82C200是兼容的通信控制器,国内很多用户都用它。如果只用于发一种消息,则没有什么问题;如多个消息共用一个通信控制器,就必须考虑这个问题了。

4  调度分析在应用上的难处

  上述分析方法是十分简化的,对出错重发情形已有的扩展处理方法,以错误的概率模型为基础,并未考虑节点的状态。处于bus-off状态的节点是无法调度的了。因而这种分析总是不完整的,还有待完善。

  更为困难的是,如果系统不能通过可调度性,那么提供的补救措施极为有限。因为T、C均为实现应用功能所必需的,并可能是产品的现成的特性。此时可能要尝试修改优先级的分配,包括利用软件工具自动分配ID,但这与优先级(消息ID)的标准化又背道而驰。同一部件在不同系统应用中要装入不同的ID,容易混淆,对诊断与维修来说也比较困难。


图5  优先级为A—C—B时可调度

  即使进行可调度性分析,必须有所有消息的T、C、J三个参数。其中T、C是供应商会提供的,但J不一定会或不一定能提供。由OEM指定T、C、J,然后由供应商去满足订货要求。虽然有时可行,但随着专业分工的细化,供应商对控制对象的研究更深刻,所以主动权不全在OEM手里。

  为了在干扰严重的环境下可靠地工作,host一般会起用Watchdog功能来防止程序因走飞而失效。J与Watchdog的正常周期有关,也与Reset后的处理时间有关。如果程序抗干扰设计对数据没有足够的保护,则启动消息发送的本地时钟和某些与传送相关的状态标志会失控,使J也失控。一般的说,设计者现在还无法遍历所有的走飞状态从而提供有干扰下的J。如果通过测试确定,与软件有关的J测试集也是没保证的。不考虑走飞的J,对CAN调度分析结果可信度有所降低。

  从上述分析可知,像CAN这种事件触发的通信协议,为保证消息不错过时限,必须进行可调度分析;分析后要使不可调度的系统变为可调度,在实践上比较困难。如果要解决host走飞形成的抖动造成通信失常的后果,只能在控制算法上花力气了,这在时间触发协议中也是一样的。

原文地址:https://www.cnblogs.com/tianqiang/p/8424636.html

时间: 2024-09-30 15:33:32

CAN调度理论与实践分析的相关文章

CV学习资料《卷积神经网络与视觉计算》+《深度学习实践计算机视觉》+《视觉SLAM十四讲从理论到实践》电子资料代码分析

视觉和图形学真是一家,基础都一样! 如果学习图像识别,计算机视觉,推荐电子书<视觉SLAM十四讲:从理论到实践>,系统介绍了视觉SLAM(同时定位与地图构建)所需的基本知识与核心算法,既包括数学理论基础,如三维空间的刚体运动.非线性优化,又包括计算机视觉的算法实现,例如多视图几何.回环检测等. 一个周读完了,代码很清晰!Particle Filtering,KF,EKF, Batch Optimization, Lie Group,ICP,LK光流... 尤其惊喜的是文末作者看好的IMU-SL

JVM性能调优1:JVM性能调优理论及实践(收集整理)

本系列包括: JVM性能调优1:JVM性能调优理论及实践(收集整理) JVM性能调优2:JVM性能调优参数整理 JVM性能调优3:JVM_堆溢出分析过程和命令 JVm性能调优4:GC日志分析 JVM性能调优5:Heap堆分析方法 注:本文部分内容收集整理了网上的资料. 1.      内存结构 1.1.     分代结构图 注意: 在JVM中,非堆内存,根据模式不同分为不同的几个部分. -Server下:非堆包括:持久代和代码缓存(Code cache) -client下:非堆包括:持久代.代码

MySQL优化核心理论与实践

背景描述:朋友单位OA系统前不久完成升级大改造,后端用的MySQL存储数据,上线跑了个把月,抱怨电话开始接二连三打来,不是这里打不开,就是那里无响应,有人比喻升级后变成老爷车,越来越慢,问题迫在眉睫,必须马上想对策呀.由于部署采用了规范文档,上线前也做了各种测试,于是乎,在线排查,未果,翻出实施文档,逐条阅读,未果,于是想起曾经一个业务系统,也碰到类似情况,后来通过各种优化得以缓解,遂有下文,<MySQL优化核心理论与实践>.说明:本文理论部分来源叶老师的博文,实践部分来源工作积累和众多热爱M

视频编解码的理论和实践2:Ffmpeg视频编解码

近几年,视频编解码技术在理论及应用方面都取得了重大的进展,越来越多的人想要了解编解码技术.因此,网易云信研发工程师为大家进行了归纳梳理,从理论及实践两个方面简单介绍视频编解码技术. 相关阅读推荐 <视频直播关键技术:流畅.拥塞和延时追赶> <视频直播技术详解:直播的推流调度> <音视频通话:小议音频处理与压缩技术> <视频编解码的理论和实践1:基础知识介绍>   1.Ffmpeg介绍 <视频编解码的理论和实践1:基础知识介绍>介绍了视频编码的基础

理论与实践:如何从Hadoop迁移到MaxCompute

摘要: MaxCompute大数据计算服务,能提供快速.完全托管的PB级数据仓库解决方案,能够使用户经济且高效地分析处理海量数据.而用户往往之前使用了Hadoop实现大数据计算任务,在选择了阿里云大数据计算服务之后,如何从Hadoop向MaxCompute进行迁移就成为了一个需要面对的问题了. 摘要:MaxCompute大数据计算服务,能提供快速.完全托管的PB级数据仓库解决方案,能够使用户经济且高效地分析处理海量数据.而用户往往之前使用了Hadoop实现大数据计算任务,在选择了阿里云大数据计算

我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践

写在前面 插一句:本人超爱落网-<平凡的世界>这一期,分享给大家. 阅读目录: 关于DDD 前期分析 框架搭建 代码实现 开源-发布 后记 第一次听你,清风吹送,田野短笛:第一次看你,半弯新湖,鱼跃翠堤:第一次念你,燕飞巢冷,释怀记忆:第一次梦你,云翔海岛,轮渡迤逦:第一次认你,怨江别续,草桥知己:第一次怕你,命悬一线,遗憾禁忌:第一次悟你,千年菩提,生死一起. 人生有很多的第一次:小时候第一次牙牙学语.第一次学蹒跚学步...长大后第一次上课.第一次逃课.第一次骑自行车.第一次懂事.第一次和喜

采用[ICONIX] 方法实践分析和设计之六 [时序图](转)

采用[ICONIX] 方法实践BLOG设计之六 [时序图] 在前几篇文章中,我们分别进行了域模型和用例建模,并使用 Robustness工具进一步分析验证了相应用例的处理流程,并在相应模型(域模型)的基础上,通过Robustness方法引入相关的边界对象,控制对象(控制器),并更新了相应域模型中类的属性(字段).下面就可以进入到交互建模阶段了.如下图:    作为交互建模本身,就是要通过寻找对象之间的交互关系,进而进行方法(操作或行为)分配.    正所谓"只有在所有的用例为所有事件进程建立了交

Java 理论与实践: 流行的原子

Java 理论与实践: 流行的原子 新原子类是 java.util.concurrent 的隐藏精华 在 JDK 5.0 之前,如果不使用本机代码,就不能用 Java 语言编写无等待.无锁定的算法.在 java.util.concurrent 中添加原子变量类之后,这种情况发生了变化.请跟随并行专家 Brian Goetz 一起,了解这些新类如何使用 Java 语言开发高度可伸缩的无阻塞算法.您可以在本文的 论坛中与作者或其他读者共享您对本文的看法.(也可以通过单击文章顶部或者底部的 讨论链接来

Java 理论与实践: 非阻塞算法简介--转载

在不只一个线程访问一个互斥的变量时,所有线程都必须使用同步,否则就可能会发生一些非常糟糕的事情.Java 语言中主要的同步手段就是synchronized 关键字(也称为内在锁),它强制实行互斥,确保执行 synchronized 块的线程的动作,能够被后来执行受相同锁保护的synchronized 块的其他线程看到.在使用得当的时候,内在锁可以让程序做到线程安全,但是在使用锁定保护短的代码路径,而且线程频繁地争用锁的时候,锁定可能成为相当繁重的操作. 在 “流行的原子” 一文中,我们研究了原子