为了给ECU提供一个合适的基础设施，下面提供了两个不同的协议范例：

•事件驱动通信，例如在控制区域网络协议中（CAN，见第4章和第6章）实施。

•时间驱动通信，例如在时间触发协议中（TTP，见第4章和第15章）实施。

这些范例的不同，根本就在于访问共享通信介质的方式是在通信控制单元之间协调的。

在“事件驱动通信”的情况下，使用了一个特设的同步方案。这个方案基于一个动态的仲裁策略，避免使用基于信息优先级方案时的访问冲突。这个方案并不需要进程通信事件之间的优先协调；这些进程可能会任意地发送信息。发送对通信介质的访问要求是授予在每个事件的基础上：如果介质目前不被占用，每个进程都可能尝试访问它以发送信息。在两个或多个发送者之间存在冲突的情况下，优先级较低的消息发送延迟，让位于具有最高优先级的信息（发送）。因此，该协议只涉及对通信事件的处理，无须具有进一步的功能。(www.daowen.com)

相比之下，在“时间驱动通信”的情况下应用了一个预定义的同步方案。该方案使用一个基于时槽的静态仲裁策略，以避免访问冲突。通过事先分配给每条消息的一个独特的通信时槽，就不再需要冲突的特设回避。访问通信介质的授权基于一个依赖时间的策略；一个过程可能只发送在分配时槽内的信息。然而，冲突的避免主要取决于每个时槽的开始及持续的总协议。因此，除了实际的通信，协议还必须包括对于所有进程间时槽同步的功能。

就分布式开发过程而言，尤其是在设计和集成阶段，由于它们仲裁方案的性质，这两种不同的范例提供了相当好的互补性。事件驱动通信使用一个轻量级的通信协议。由于它特设冲突避免，设计接口规范时不再需要事先保留时槽。它的同步策略理想地容许了带宽的最佳使用，即使是在零星信息的情况下。根据通信负载的性质和平均带宽（实际上低于最大值），至少可以保证高优先级信息的最大延迟。事件驱动方法下的组件集成是通过组合来简单实现的，这是由于冲突形势下不兼容的同步策略采用了特设解决。然而，因为消息的延迟取决于可用带宽和通信负载，因此针对组件的一个子集建立的延迟不一定支持组合组件的完整网络。

相比之下，时间驱动通信需要一个额外的时钟同步机制。由于其仲裁策略，设计接口规范时，必须为所有通信保留时槽，这可能会导致出现未被使用的时槽，因此尤其是在零星信息的情况下会出现带宽损失。使用这种优先的保留方案，通过显式分配信息到时槽，时间驱动通信确保了所有信息的最大延迟。此外，组件集成还需要确保分配到时槽时的兼容性。然而，针对隔离组件建立的延迟保证（要能够）迅即支持组成系统。

总而言之，就零星信息的集成和调节而言，事件驱动通信的灵活性是以可靠系统的组合性为代价的。为了结合两种优势，FlexRay综合了这两种方法。