FlexRay正在前行

　　2007年5月，超过200位开发者在斯图加特汇聚一堂，参加了由Vector Informatik公司主办的FlexRay大会。会上，汽车OEM和供应商展示了他们现在取得的成就、在系统集成方面的经验和针对未来的实现理念。

　　很久以前CAN总线就遭遇了本身的局限性。现代汽车电子架构需要不断地扩大网络化。只有提供更大的传输容量，日益加快的控制算法付诸实施时才会产生效果。很多车型在开始生产时就已经达到了最大的总线负载，而没有预留任何带宽。总线系统的数量加倍无论如何都不会使数据速率加倍。为系统联网而增加的必要的网关，不仅使系统变得错综复杂，而且可能产生不可接受的报文传输延迟。更要命的是，缺乏确定性成为了安全关键应用的绊脚石。

　　在发展过程中，CAN不能满足汽车中逐渐增长的数据传输要求，这导致了FlexRay串行总线系统的发展[1]。去年底，BMW展示了首个FlexRay产品级应用。Vector Informatik公司在那时举行FlexRay大会正是总结新协议应用经验和挑战的好时机。在BMW X5车上使用FlexRay完成减震器控制系统从两方面来讲都是一项“时间关键”工程，这让项目

参与者面临考验。不仅半导体产品和软件组件需要按时生产出来，而且面对这样一项艰巨的工程，其开发流程也必须要很快地适应现有的结构并能正确运转。在这里需要得到供应商的支持。“在BMW我们不能只为了FlexRay而开发一套新的流程”，BMW AG的网络技术组带头人Anton Schedl博士如此表示，“因此我们有意识地决定选取了一种相对简单的应用，这样可以根据已有经验、使用较短的协调和决策路径迅速实现改造。”

　　Schedl博士认为，在合适的时间有可用的半导体是这项试验性项目的最大挑战。得益于OEM和半导体供应商共同做出的积极承诺，这一目标有可能会按期完成。

　　万事开头难

　　尽管启动每个新系统必然会很困难，但是不同的部件还是比较快地集成到了一起。“时间触发通信是将不同供应商的部件和软件代码集成起来的理想平台”，在Robert Bosch公司汽车网络部门工作的Florian Hartwich说。他还协助FlexRay协会制定协议，之前参与了CAN和TTCAN的开发和标准化工作。因为每个应用系统都在预先规定的时刻发送报文并且知道该在何时接收何报文，所以在之后可以更为容易地将部件加入到分布式系统中。

　　最重要的工作需要在FlexRay系统开发一启动时就进行。所有的系统描述参数——比如波特率、循环时间、时隙数目、时隙长度以及静态段和动态段的报文分配——都在开始时定义。因为确定的时隙是分配给发送任务的，所以在工程定义过程中就必须明确如何组织报文的时隙分配、哪些应用系统可能最适合提到动态事件驱动段以及应该为后续车型系列的应用系统预留多少时隙等，参考图1。

图1 时隙确定地分配给单个部件（A，B，C）简化了系统集成时的合并工作

　　在分布式系统中保持整体观特别重要。在一开始，网络设计者往往不知道真实应用软件随后是如何进行实际通信的，也不清楚它们的执行时间。另一方面，ECU开发者习惯于只关注开发应用程序，而不怎么关心整个FlexRay通信过程的时间状况。但是，一个循环内的FlexRay数据必须保持一致，并且时间触发型总线的应用程序也必须保证一直同步。

　　因此，Hartwich留意了那些可能引起数据不一致的问题。比如，必须避免在发送过程中更新发送数据，这会导致在同一帧中同时包含新旧数据。BMW使用所谓的“信号窗口”解决了这一问题，它保证任务仅在该专用窗口中发送报文。这种方法的另一个好处是应用程序与通信分离：如果通信调度发生了改变，那么不会影响应用程序。

　　在实时系统中，任务同步是一项必须引起特别关注的关键特性。“调度表的正确同步问题至关重要”，Winfried Janz解释道，他是Vector公司OSEK实时操作系统开发项目的带头人兼产品经理。在关于OSEKtime和AUTOSAR操作系统的演讲中，他论述了如何按照规范使调度表与全局时间同步（参考图2）。选择硬同步（调度表跳转到一个预定义的执行点或者暂时停止了）还是软同步（在每个到期时刻进行时间调整，但是这些时刻的分配是无规律的，会导致一些无规律的时间调整行为）取决于应用程序是否容忍跳转和暂停。

图2：调度表状态图显示了同步是如何实现的。调度被启动，但不必立即完全同步（RUNNING）。为实现同步运行（AND SYNCHRONOUS），可以进入等待状态（SHEDULETABLE_WAITING）或者进行软同步。