当前位置:首页 > 嵌入式 > 嵌入式硬件
[导读]  TTCAN通过独占窗口的方式解决消息传送的确定性问题,提高总线利用率,试图满足应用发展的要求。但是在恶劣环境的高误码率下,传送的可靠性下降,容错的措施不成熟,成本较高。再考虑TTCAN的其他得失,认为它不是性价比高的CAN技术升级方案。

摘要 TTCAN通过独占窗口的方式解决消息传送的确定性问题,提高总线利用率,试图满足应用发展的要求。但是在恶劣环境的高误码率下,传送的可靠性下降,容错的措施不成熟,成本较高。再考虑TTCAN的其他得失,认为它不是性价比高的CAN技术升级方案。

关键词 CAN TTCAN 时间触发协议 误码率

2002年左右国外推出的TTCAN是一种时间触发的通信协议,在我国电动汽车“863”攻关项目及地方的科研项目中有许多尝试,目的是判断它能否成为新一代汽车的通信骨干网络。在研制中,它们一般规模较小,总线负载较轻,试验环境并不十分恶劣,对误码造成的丢帧不容易发现,且未经长期考验,所以没有发现什么问题;但对于大量生产的汽车,必须全面认识TTCAN的优劣,以及汽车控制用总线的技术走向,才能避免采用新技术带来的技术与经济风险。本文试图从可靠性与经济性角度对TTCAN作些分析,供大家决策时参考。

1 TTCAN兴起的推动力量

TTCAN是在CAN的基础上发展起来的一种高层协议,它的出现是为解决CAN应用中遇到的瓶颈而作的一种试探。

现在,TTCAN已被采纳为国际标准ISO118984;但在工业上也只是试验性的应用,没有见到大规模的采用。虽然如此,对它兴起的原因进行分析仍然会对我们有很大的启发,正是这些需求构成了评价一种新技术优劣的依据。CAN是最成功的一种现场总线,在今天依然是应用的主力,经过近20年的实践,对它的局限也有了较多的认识[1]。这里不重复其中总结的内容,仅从应用的角度来说明CAN所面临的问题。

1.1 为满足时限要求不得不降低总线利用率

CAN是事件触发协议,当许多消息同时要求发送时,竞争结果使低优先级消息发送的时间推后很多,甚至不能满足其时限的要求。

现以一个SAE benchmark为例[1]。该例有5条5 ms周期的消息,其帧长含1B、2B、1B、2B和4B数据,其余为50、100和1 000 ms的消息。在参考文献[1]中,消息可能的最大长度计算小了,但即便这样,对于5 ms周期的消息在125、250、500 kbps和1 Mbps的总线速率下,最大响应时间为4.456、2.228、1.114、0.557 ms。由于这些消息都置于较高优先级,它们只可能被一个低优先级4B数据消息阻断1次。我们可以只算这几条消息而估计相应总线的通信负载为75 kbps,对应的总线利用率为60%、30%、15%和7.5%。

现在看看最大响应时间对于应用意味着什么:一个闭环控制系统以5 ms为采样控制周期,在最坏响应时间为4.456 ms时,执行器产生的反馈控制效果在下一次采样前维持的时间最坏为5-4.456=0.55 ms,最长为5 ms。显然在这种变动巨大的情况下,控制参数只能取得比较保守,例如微分和积分增益不能太强。这就极大地限制了控制品质的提高。有些控制算法对这种纯迟后的变化更为敏感,例如smith预估,因此为了保证品质,只能取较低的总线利用率。对于以品质为第一的整车厂,这是唯一的选择,而取较低的总线利用率意味着成本的提高。

1.2 汽车厂是对成本非常敏感的企业

如果总线利用率只有20%~30%,随着安全、节能与舒适性要求的提高,要增加更多消息而不希望增加成本。1条总线不够,在技术上可再加,或者是连接2个ECU的专用总线,或者是连多个ECU的附加总线。要在2条CAN总线中加网桥,不要说复杂性的增加,成本的增加就很大。以一个网桥200元算,年产20万台车的厂家要增加4 000万元成本。如果把总线利用率提高到60%,这钱就省下来了。

1.3 CAN的开发与应用成本较高

为了使低优先级消息发送时间减少,不得不修改消息的优先级分配,这种变化增加了维修、管理的成本。由于系统中消息量与种类的变化,消息的送达时间会变化,又增加了认证和验证的工作量和成本。在开发新功能方面,也受到消息优先级设置上的相互影响,不易单独推进。

1.4 CAN达不到线控技术的要求

线控技术可能简化汽车的结构、降低成本、提高控制能力,是一个重要发展的方向。但要达到与原来机械—液压系统同样的可靠性,需要通信系统有更高的确定性与冗余度。CAN达不到这一确定性要求,所以要改进。当然,新的协议不能在性能上比CAN还差。

通过时间触发协议,使消息在调度好的时间片内发送,可以消除总线的争用,消息传送的确定性得到了保证,总线的利用率也得到了提高。由于一部分消息不具有周期性质,需要提供合理的带宽与时隙分布。TTCAN就在这种背景下出现了。几乎同时出现的还有其他时间触发协议,早一点的有TTP/C,晚一点的有FTTCAN、FlexRay等。它们都是在特定时隙指定周期性消息或事件消息的传送,细节上虽有区别,但没有根本的区别。与其他协议比较,TTCAN的优点是它用现有的CAN芯片就可以实现,因此价格便宜。这些经济上的考虑是TTCAN出现的直接推动力量。

2 TTCAN的简要内容

参考文献[2]有TTCAN的详细介绍。它的作者是TTCAN技术专利发明人、标准起草人。这里仅将它的几个要点摘出:

① TTCAN用System Matrix组织时间片。它相当于一个大周期,一个System Matrix里又分为2n个Cycle。在每个Cycle开始处,由时间上的Master节点发Reference消息,时间上的从节点对Reference进行同步,这样就建立了全局时钟。
② Cycle里可以划分为若干长度不同的Slot(时隙),但每个Cycle的Slot划分是一样的。
③ Slot的用途有3种:Exclusive Window(独占窗)、Arbitration Window(仲裁窗)和 Free Window(空窗)。Exclusive Window用于周期性消息发送,Arbitration Window用于事件消息的争用,Free Window用来备用。
④ 禁止消息跨窗口的发送,只有相连续的Arbitration Window除外。为此,禁止CAN的出错自动重发功能。在Arbitration Window内争用的消息要先判断能否发完,如能发完,才可参加争用。
⑤ Slot用途的指定是由调度器来实现的,它不是标准的内容,然而事件消息在Arbitration Window的争用并不是严格意义上的随到随争用。按参考文献[2]的想法,事件消息是偶发消息,应用程序可以预先安排几个偶发消息到一个Arbitration Window,再任它们争用。
⑥ 在一个Cycle里,Slot的用途不受约束。

3 TTCAN的缺点与问题

(1) TTCAN与CAN是不兼容的

TTCAN要求独占窗,因此它不能和CAN混合使用在一个系统中。带CAN通信口的ECU不受TTCAN的约束,可在任意时刻发送,就有可能在总线空闲时争得发送权,使TTCAN的调度发送完全失效。汽车厂在采用TTCAN时必须将所有要用到的ECU都改为用TTCAN的方式,这就要重新认证和验证所有的ECU,涉及大的工作量和投资。如果用网关将CAN的ECU过渡到TTCAN网,其成本的增加更大,只具有实验意义。



(2) TTCAN在恶劣环境下误帧太多

参考文献[3]中, 用实验方法得到CAN在恶劣环境下的误码率为2.6× 10-7。据文章作者认为,这是较为保守的估计,实际情况要好些。为了考察这个数据的有效性,我与该文作者进行了沟通,得到更为详细的资料,见参考文献[4]。根据这些资料,可以认为这个数据是一个与汽车现场接近的数据,不能算作保守。其主要理由有:

① 实验的原始想法是只测来源于CAN电缆干扰的误码,所以把CAN发送和接收节点放在屏蔽箱内,用二条电缆传送信号,一条在箱内,一条在箱外,通过比较从二条电缆收到的数据流,计算出误码率。但是将手机放在不带屏蔽、不作双绞的通信线上进行另外的实验时,却没有任何出错,说明来自空间的干扰影响很小。而实际恶劣环境下现场被测试设备的电源与干扰源的电源并不独立。与此对比,认为出错是通过电源传导的,这与原始设想不同。
② 实验的恶劣环境是指电焊机工作时的干扰,并无具体的数量指标,无法与汽车的电源传导干扰相比较(ISO7637)。实际上可能不如汽车电源干扰大。
③ 在电源传导干扰下,造成误码计数的情形较复杂。它与可能的故障位置、CAN收发节点状态有关。误码有多算也有少算的情形。
④ 电焊机是人工操作,通信实验中干扰源只在部分时间存在,计算误码率的通信总量多算了。

在此推定下,如假设TTCAN的总线利用率为60%,通信速率为500 kbps,按照2.6×10-7的误码率,那么在1小时内会有280.8个误码(500k×3 600×60%×2.6×10-7=280.8),约12.8秒1次。由于TTCAN禁止出错自动重发,因此会大量丢帧。而对CAN来说,只要在12.8 s内重发成功,就不会丢帧。TTCAN要回避这个问题,就要求更完善的抗干扰措施,这意味着成本的提高。

(3) 由预留Error Frame帧引起的开销大

TTCAN没有禁止Error Frame,由于错误可能出现在任何时间,就可能发生在帧的最后处,每一个Slot都要预留Error Frame的时间,否则它会阻碍下一个Slot内消息的发送,这是很大的开销,使TTCAN远达不到设想的100%的总线利用率。假定最小的数据帧为1B数据,长为65位,而Error Frame为20位,那么这项开销达到23.5%。

(4) Slot用途不同造成时间利用率低由

于TTCAN规定调度好的Cycle中的Slot划分是一样的,但可能的用途不同。不同的Cycle同一Slot里可能安排了长短不一的消息,此时对短帧来说,留下的时间就浪费了。

(5) 事件消息被阻塞的延迟可能性增大

在TTCAN中,由于调度结果造成几个连续的Slot都是独占窗,此时事件消息要等待的时间很长,必须有特别的设计加以处理。

(6) 网络内的时间同步要求较高

用软件来实现时就得留出时间以容许主从节点间的同步误差,这就又减少了带宽。如用Level 2的硬件实现,就不可能马上使成本低到与CAN一样。实际上,置TTCAN于一种新的与CAN无关的总线的地位,要与其他总线作全面的比较,TTCAN就没有其他总线好了。

(7) 丢帧处理两难

TTCAN在传送出错的情况下,不对本帧进行自动重发。在应用上要有所考虑。或者用比实际需要更多的发送,丢掉就算了的策略,这也会浪费带宽;或者由应用层在仲裁窗组织重发,但这相当复杂。如用冗余的第2条总线,意味着成本的加倍。

(8) 仲裁窗的要求较难实现

在仲裁窗判断事件消息能否发完,然后控制事件消息的发送是不容易实现的。用软件来实时处理来不及,又没有现成的硬件。

另外,在对付CAN系统中Babbling idiot出错方面,TTCAN没有改进。

4 小结

工业应用中可靠性是第一位的要求,出错自动重发是CAN最有价值的部分;而TTCAN禁止出错重发,使它的抗干扰能力大打折扣,在应用上造成困难。在许多时间触发协议中纠错的方法都复杂得多,如TTP/C和FlexRay用2个通道传送同样的消息,只要不是2个通道同时出错,消息就能送达,但是其代价是成本比单通道增加1倍。TTCAN也能构造2个通道,也会面临同样的代价问题;而且2个通道同时出错仍是有概率的,要重发又有时限等新的问题。因此在抗干扰方面,TTCAN没有给出性价比合适的解决方案。现在CAN每年都有数亿的节点产量,这说明用户对它的可靠性的认同,而这种可靠性完全来源于CAN在数据链路层实现的出错自动重发功能——干扰是客观存在的,自动纠错使用户根本感觉不到有错。比较所有的现场总线,纠错的方法要比CAN复杂得多,应用就不方便,性价比下降。尽管FlexRay的拓扑结构很多,有星型、总线型等,但设想用于替代CAN的只用1个通道的用法,可能会面临TTCAN同样的干扰丢帧问题;解决出错重发的高层软件并不成熟,也没有标准化,因此目前不会构成对CAN的威胁。

TTCAN与CAN的不兼容,使它在经济上不能充分利用CAN的资源,所以它也不是CAN的好的升级方案。

作者: 重庆工业自动化仪表研究所 杨福宇


参考文献

[1] Tindell K W, Burns A. Guaranteeing message latencies on Controller Area Network (CAN)[C]. In Proceedings of 1st International CAN Conference, pp. 111, September 1994.
[2] Fuhler T,et al. Time Triggered Communication on CAN[C]. Robert Bosch GmbH, Proceedings 7th International CAN Conference, Amsterdam, Holland, 2000.
[3] Ferreira J,Oliveira A,Fonseca P,et al. An experiment to assess bit error rate in CAN[C]. RTN 2004 3rd Int. Workshop on Real?Time Networks sattelite held in conjunction with the 16th Euromicro Intl Conference on Real?Time Systems, June 2004.
[4] Ferreira J. PhDjjcf_Charpter_4.pdf
[5] 杨福宇. CAN总线的局限[J]. 电子设计应用,2006(11):32, 34.

本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除。
换一批
延伸阅读

在嵌入式系统开发、调试和测试过程中,J-Link作为一种高效的调试工具,为开发者提供了极大的便利。然而,要想充分发挥J-Link的功能,首先需要正确安装其驱动程序。本文将详细介绍J-Link驱动的安装过程,并深入解析其中...

关键字: jlink 嵌入式系统 嵌入式开发

与谷歌的合作使 Nordic 能够在 nRF Connect SDK 中嵌入开发人员软件,以构建与安卓移动设备兼容的谷歌Find My Device和未知跟踪器警报服务

关键字: 谷歌 SoC 嵌入式开发

嵌入式开发作为当今电子工程和信息技术领域的核心分支,涵盖了广泛的软硬件技术和系统集成方法,用于构建高性能、低成本、低功耗、体积小巧且功能专一的嵌入式系统。这些系统无处不在,从微型传感器节点到复杂的工业控制设备,从日常使用...

关键字: 嵌入式开发 Python

嵌入式开发是当今信息技术领域不可或缺的一部分,它融合了硬件设计、软件开发和系统集成等多个学科,专门用于创建那些被嵌入到特定设备或系统中的专用计算机系统。嵌入式开发的主要过程包括利用分立元件或集成器件进行电路设计、结构设计...

关键字: 嵌入式开发 硬件设计 软件开发

嵌入式开发作为一种专业且技术密集型的领域,涵盖了从硬件底层驱动、中间件到应用层软件开发等多个层面的工作,其所需的工具种类繁多,各有针对性,旨在提升开发效率、保证代码质量以及简化调试过程。

关键字: 嵌入式开发 keil

嵌入式开发作为信息技术领域的重要分支,其涉及的语言种类繁多,各具特色。这些语言的选择取决于目标平台的特性、性能需求、开发者的熟练程度以及项目的具体要求。本文将详细介绍几种常见的嵌入式开发语言,包括C语言、C++、汇编语言...

关键字: 嵌入式开发 C语言

嵌入式开发是一项综合了硬件设计、软件编程以及系统整合的技术活动,其目的是为了创造出能够在特定环境中高效、稳定运行的嵌入式系统。这一流程涵盖了多个紧密关联且不可或缺的阶段,从最初的客户需求分析到最终的产品测试和交付,每个环...

关键字: 嵌入式开发 硬件设计

嵌入式开发作为一个融合了计算机软硬件和系统工程的综合性领域,其成功与否往往取决于三个核心要素的有效整合与协调。这三个要素分别是:硬件平台的选择与设计、软件开发及其优化、以及系统级的设计与集成。深入理解并熟练掌握这三个方面...

关键字: 嵌入式开发 ARM

嵌入式开发作为信息技术的关键支柱,在全球数字化转型浪潮中扮演着无可替代的角色。从传统的嵌入式微控制器到如今先进的片上系统(SoC),再到与云计算、人工智能深度融合的智能终端,嵌入式系统的演进与发展始终紧跟时代脉搏。本文将...

关键字: 嵌入式开发 智能应用

嵌入式开发是一种专门针对特定硬件平台设计和实现软件系统的工程实践,它涵盖了从需求分析、系统设计、编程实现、调试测试直到产品部署及维护的全过程。本文将深入探讨嵌入式开发的主要阶段,分解其流程并阐述每个步骤的关键要点,以便于...

关键字: 嵌入式开发 嵌入式软件
关闭
关闭