对于FlexRay通信系统而言，FlexRay驱动器和相关的通信层为应用开发人员提供了一个易于使用的帧或基于信号的接口。这些软件模块一般由网络设计工具来设置。目前市场上有好几种FlexRay驱动器和配置工具解决方案，它们在性能、可用性、功能和价格上各不相同。然而，在将来，汽车开放系统架构（AU-TOSAR；见第2章）^[AUT]标准将越来越与汽车制造商的项目关系紧密。其中，FlexRay驱动器和FlexRay接口模块将在AUTOSAR中规定，且将越来越多地用于硬件平台。

FlexRay应用开发需要一些关于系统架构的基本决定。关于FlexRay全局时间和应用程序间的同步有三种可能情况：

•应用程序和FlexRay通信异步执行。

•应用程序在FlexRay全局时间上同步。

•部分应用程序在FlexRay全局时间上同步运行。

如果应用程序在FlexRay全局时间上同步运行，那么可以达到信号延迟的最佳效果。在这种情况下，传输节点的应用软件可以在时槽即将在一致的帧传输开始前，把更新的数据发送给通信控制器。只要数据帧也与FlexRay全局时间同步，那么接收节点的应用程序可以在帧被接收之后，立即读取来自通信控制器的数据。这种情况的案例如图5.13所示。这种从一个ECU的发送任务到另一个ECU的接收任务的短的、固定且有保证的延迟数据，允许了高层次的分布式控制系统的建立。因为有了这项确定性，FlexRay对于可靠的安全子系统或驾驶动力系统十分方便。连同两个通道上的通信冗余选项，FlexRay也进而适合于容错线控系统的建立。(www.daowen.com)

通过通信控制器的中断或者通过支持外部时间同步机制（如OSEK时间）的实时操作系统，可以实现应用程序和FlexRay通信之间的同步。

图5.13 FlexRay控制系统案例（伊莱比特成员DECOMSYS，版权所有，已获得许可）

由于种种原因，存在应用程序和FlexRay通信之间不可能实现同步或不需要同步的情况。例如，在一个电动机控制单元中，软件必须与电动机旋转速度同步运行且不适合于另一个时基。在这种情况下，应该只使用支持这个同步操作的通信控制器。但即使如此，也不可能实现对系统行为关于精确信号延迟的控制。例如，如果一个应用程序任务在一致的时槽通过不久后就向通信控制器写入数据，那么通信控制器必须“等待”分配到帧的下一个时槽。不能预测数据最终将在哪个通信周期内被发送；“只有一个最坏情况的延迟值可以被确定”。如果一个信号组分布于一个以上的帧内，那么将无法保证信号间的一致性。因此，一个完全异步运行的应用程序是不可取的。

如果应用程序必须与FlexRay通信异步运行，那么另一个选择是只将FlexRay相关的通信层与FlexRay全局时间同步。尤其是负责应用程序和通信控制器之间数据传输的FlexRay通信任务，在这种情况下它们将被同步，然后执行时间解耦。