对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没有改进。