如前所述，有两种类型的通信网络：TT网络（其中的活动由时间的进程驱动）和事件触发网络（其中的活动由事件的发生来驱动）。这两种类型的网络都有其优点，但通常认为TT总线更可靠（例如，可参考文献[9]关于这个问题的讨论）。这说明，目前只有TT通信系统被考虑用于线控场合。在这类网络中，基于TDMA的多路存取协议特别适合；它们提供对介质的确定性访问（传输的顺序是在设计时按静态定义），从而限制响应时间。此外，它们定期的信息传输可用作“心跳”来检测站的故障。基于TDMA的三个网络可以作为网关或用来支持安全关键场合，它们是TTP/C^[23]、FlexRay（参见4.2.2.1节）和TTCAN（参见4.2.2.2节）。由世界汽车行业支持的FlexRay正在成为行业标准，并从2006年起它被用在宝马X5车型中^[25]。接下来，我们不再进一步讨论TTP/C，因为据我们所知，它现在不再用于车辆中，而是用于飞机的电子系统中。然而，多年来取得的关于TTP/C的重要经验，尤其是关于容错功能^[36]和形式化验证（参见第15章）方面的经验，肯定有益于FlexRay。

4.2.2.1 FlexRay协议

主要来自汽车领域的公司联盟正在开发FlexRay协议。联盟核心成员有宝马、博世、戴姆勒、通用汽车、恩智浦、飞思卡尔和大众。FlexRay协议的第一次公开规范已经在2004年发布。规范的最新版本^[24]参见网页：www.FlexRay.com。

FlexRay网络在拓扑结构和支持冗余的传输两个方面非常灵活。它可以设置为总线、星形或多星形。它并不强制每个站点拥有复制通道或总线监控，即使这个站用于如线控转向的关键功能。在MAC层中，FlexRay定义了一个通信周期作为TT（或静态）窗口和事件触发（或动态）窗口的串联。每个通信窗口的大小在设计时都设置为静态，且每个通信窗口都应用了两个不同的协议。通信周期定期执行。TT窗口使用TDMA MAC协议；在TT窗口中，和TTP/C的主要区别是：在FlexRay中的站可能拥有几个时槽，但所有的时槽大小都是相同的（图4.1）。在通信周期的事件触发部分，使用的是灵活的TDMA（FTDMA）协议：时间被划分成所谓的小时槽，而每个站拥有给定数量的小时槽（不一定是连续的），并且可以在自己的小时槽中开始1帧的传输。如果站没有进行传输，那么一个小时槽处于闲置状态，那么这实际上会导致带宽的损失（见文献[37]中关于此问题的讨论）。一个动态窗口的示例如图4.2所示：通道B上，帧在小时槽n和n＋2中传输，而小时槽n＋1并没有被使用。值得注意的是，在通道A和B中，帧n＋4没有同时被接收，这是因为在动态窗口中，数据的传输在两个通道中是独立的。

FlexRay MAC协议比TTP/C MAC更灵活，这是因为在静态窗口中的节点被分配了尽可能多的时槽（总数高达2047），同时也是因为在通信周期的动态部分中，帧只在有必要的时候被传送。该通信周期的结构与TTP/C相似的方式被静态储存在节点中；然而，它又不同于TTP/C，随每个模式不同通信调度变化的模式变化是不可能的。

图4.1 有A、B、C和D四个节点的FlexRay通信周期示例

FlexRay的帧由三部分组成：头段、含有254B的数据负载段和24bit的CRC段。5B的头段包括了帧标识符和数据有效载荷的长度。标识符的使用允许将一个发送帧X的软件组件从一个ECU移动到另一个ECU，同时不会改变节点中任何会消耗帧X的内容。然而必须指出的是，当为了节省带宽而把通过不同组件产生的信号封装到同1帧中时[即被称为帧封装或协议数据单元（PDU）——多路切换（见文献[38]）——对这个问题在CAN上的解决方法]，上述情况是不可能的。

(www.daowen.com)

图4.2 FlexRay通信周期的动态段中的信息时序安排示例

从可靠性的角度看来，FlexRay标准制定了单独的总线监控器和时钟同步算法。其他功能，如模式管理设施或成员服务，将必须在软件或FlexRay顶部的硬件层上实现（例如，参考文献[39]，了解可以与FlexRay一起使用的成员服务协议）。这将允许设想和精确实施需要有缺点的服务，但这种正确和有效的服务实施在通信控制器以上的层面上更加难以实现。

在FlexRay的规范中，认为该协议提供了可扩展的可靠性，也就是“在配置中提供不同程度的容错操作能力”。事实上，该协议允许和同一网络、没有总线监控器的节点的子网上的单双传输支持或与关于时钟同步的不同容错能力等的混合连接。在关键和非关键功能将越来越多地共存和互操作的汽车领域中，如果缺少的容错功能在一个中间层（MW）中被提供，例如目前正在汽车行业项目AUTOSAR内开发的一个中间层（参见4.3.3节），那么这种灵活性可以证明在成本和现有组件的重新使用方面是有效的。对FlexRay感兴趣的读者可以参考第5章和文献[40，41]，来了解如何配置通信周期。

4.2.2.2 TTCAN协议

TTCAN^[27]是由罗伯特·博世有限公司基于CAN物理性和DLL开发的通信协议。TTCAN使用CAN标准，但此外，它要求控制器有可能根据传输错误禁用帧的自动重传，并且有可能提供给较上层，这些层有帧的第一位被发送或接受^[42]的时间点。网络的总线拓扑、传输支持的特性、帧格式以及1Mbit/s的最大数据传输速率，都是CAN协议施加的。通道冗余是可能的（参见文献[43]的建议），但不规范，并且没有总线监控器在节点中实施。如同FlexRay一样，关键的想法是提出一个灵活的TT/事件触发协议。如图4.3所示，TTCAN定义了一个基本周期（相当于FlexRay通信周期）作为一个或几个TT（或独有的）窗口和一个事件触发（或仲裁）窗口的串联。独有的窗口致力于TT传输（即周期的消息），而仲裁的窗口由标准CAN协议支配：传输是动态的，并且根据帧的优先级允许对总线的访问。可以定义几个基本周期，它们由于独有窗口及仲裁窗口中的组织而不同，并由于仲裁窗口内发送的信息而不同。连续的基本周期列表称为系统矩阵，它们在循环中执行。有趣的是，该协议使主节点（即通过“参考信息”的传输，开始一个基本周期的节点）可以在TTCAN模式中停止运作，并可以在标准CAN模式中重新开始。之后，主节点可以通过发送一个参考信息来切换回TTCAN模式。

图4.3 TTCAN基本周期的示例

TTCAN建立在一个掌握充分且成本低的技术上，但由标准定义的CAN并不提供重要的可靠性服务，例如总线监控、成员服务和可靠的认定。当然，它可以在应用程序或MW层中实施这些机制中的部分内容，但同时会降低效率。几年前，汽车制造商被认为会在FlexRay技术完全成熟前的过渡时期内对TTCAN的使用感兴趣，然而事实并非如此，且TTCAN在汽车产品中的未来似乎相当不确定。