很久以前CAN总线就遭遇了本身的局限性。现代汽车电子架构需要不断地扩大网络化。只有提供更大的传输容量，日益加快的控制算法付诸实施时才会产生效果。很多车型在开始生产时就已经达到了最大的总线负载，而没有预留任何带宽。总线系统的数量加倍无论如何都不会使数据速率加倍。为系统联网而增加的必要的网关，不仅使系统变得错综复杂，而且可能产生不可接受的报文传输延迟。更要命的是，缺乏确定性成为了安全关键应用的绊脚石。
在发展过程中，CAN不能满足汽车中逐渐增长的数据传输要求，这导致了FlexRay串行总线系统的发展。去年底，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。
在分布式系统中保持整体观特别重要。在一开始，网络设计者往往不知道真实应用软件随后是如何进行实际通信的，也不清楚它们的执行时间。另一方面，ECU开发者习惯于只关注开发应用程序，而不怎么关心整个FlexRay通信过程的时间状况。但是，一个循环内的FlexRay数据必须保持一致，并且时间触发型总线的应用程序也必须保证一直同步。
因此，Hartwich留意了那些可能引起数据不一致的问题。比如，必须避免在发送过程中更新发送数据，这会导致在同一帧中同时包含新旧数据。BMW使用所谓的“信号窗口”解决了这一问题，它保证任务仅在该专用窗口中发送报文。这种方法的另一个好处是应用程序与通信分离：如果通信调度发生了改变，那么不会影响应用程序。
在实时系统中，任务同步是一项必须引起特别关注的关键特性。“调度表的正确同步问题至关重要”，Winfried Janz解释道，他是Vector公司OSEK实时操作系统开发项目的带头人兼产品经理。在关于OSEKtime和AUTOSAR操作系统的演讲中，他论述了如何按照规范使调度表与全局时间同步（参考图2）。选择硬同步（调度表跳转到一个预定义的执行点或者暂时停止了）还是软同步（在每个到期时刻进行时间调整，但是这些时刻的分配是无规律的，会导致一些无规律的时间调整行为）取决于应用程序是否容忍跳转和暂停。
图2：调度表状态图显示了同步是如何实现的。调度被启动，但不必立即完全同步（RUNNING）。为实现同步运行（AND SYNCHRONOUS），可以进入等待状态（SHEDULETABLE_WAITING）或者进行软同步。
在开发阶段，监视同步和数据一致性由软件工具来完成。“我们必须做到同步地处理模型，否则就会丢失数据”，当Carsten B？ke博士解释Vector的工具CANoe时他这样说道。B？ke演示了CANoe提供的确保同步和检测不一致数据的机制。CANoe运行模型的主要体系结构基于一种使用所谓“通知句柄”的通知概念。它包括了接收到消息时的模型激活、定时器到期时的处理和错误状态的检测。尤其是，这种概念针对FlexRay作了扩展，包含了在FlexRay循环的特定时刻进行的同步通知，如图3所示。另外，B？ke演示了一种运行CANoe RT、具有特定硬件支持的优化平台，该平台是为了满足FlexRay系统严格的时间要求而定制的，比较适合中小尺寸的硬件在回路仿真。
图3：在CANoe中，可以参照循环开始或特定时隙的结束有规律地执行动作。当然，通知也可以发生在总线上接收到帧或丢帧的时候。
FlexRay与AUTOSAR
“为将来做准备，必须按照AUTOSAR标准设计新的软件概念”，负责FlexRay基础软件开发的Dirk Gro？mann说。因为Vector Informatik公司是AUTOSAR协会的成员，所以该协会的成果和结论很快就在Vector的FlexRay开发中得到了实践，如图4所示。Vector的FlexRay接口和FlexRay driver已经符合AUTOSAR标准了，因而可以在今天不用依赖于以后特定的应用程序而开发这些组件，而且这些组件可以灵活地适合不同的车型和平台。FlexRay driver对通信控制器进行了抽象，而FlexRay接口提供了针对和FlexRay调度表无关的单个PDU（协议数据单元）的访问入口。 此外，Vector提供符合AUTOSAR标准的网络管理和传输协议实现。作为对AUTOSAR的补充，可以将XCP协议集成到FlexRay栈中。Gro？mann还谈到通过FlexRay进行flash编程的可能性：“一种方案是完全交换协议并且使用单独的调度表进行flash编程。”
Oliver Kitt在其演讲中更为深入地论述了使用XCP（由ASAM标准化的一种标定协议）标定ECU的话题。在Vector公司，他负责测量、标定和诊断工具CANape的硬件接口集成工作。XCP中的“X”表示不同的传输层，比如它可以表示XCP-on-CAN、XCP-on-Ethernet以及2006年2月发布的XCP-on-FlexRay等。这是一种单主/多从概念，可以非常高效地与ECU通信并且使用可变带宽进行测量和标定。可以将slave集成到FlexRay栈中，而由工具来提供对协议master功能的支持。在运行时刻根据需要为单个节点重新分配带宽。有必要使用一种增强版FlexRay driver来实现XCP-on-FlexRay的buffer重配置。这也展示出组件的灵活操作。
图4：符合AUTOSAR标准的FlexRay软件方案可灵活地适应不同的需求。该图展示了一种带有driver（相对于AUTOSAR进行了扩展并增加了XCP传输层和协议模块）的FlexRay栈。
FlexRay协议规范的编辑，在Freescale公司负责FlexRay相关工作的Mathias Rausch博士（工程学），阐述了buffer结构是如何影响整个系统的。Rausch详细描述了配置不同的静态或动态段时优化buffer存放的方法。另外，Freescale利用了FlexRay协议中没有详细规定控制器主机接口（CHI）、仅规定最低需求作为约束条件的实际情况。这给了半导体厂商提供特殊功能的自由。CHI的优化设计使随后的软件更容易构造。Rausch建议使用工具，因为“配置多达128个消息buffer时需要考虑很多参数”。
在Schedl博士的请求下，NXP半导体公司汽车商务领域创新和发展管理主管Patrick Heuts先生挑选出了更为经济的FlexRay组件。“除了收发器，我们也提供FlexRay控制器，它是完全集成在MCU中的，是一种单片机方案。相比较那种通常作为外围设备嵌入到MCU中的FlexRay控制器，这种完全集成的方案具有明显的优势。比如，消息buffer的数量和类型可以灵活配置。事实上，完全集成的FlexRay控制器工作起来更像一种具有一个或两个通道的DMA工具。NXP半导体公司的下一步计划是研究在片上集成收发器是否可以进一步降低系统的成本”。参考图5。
图5：NXP半导体公司提供了“MCU中心”解决方案，其优点是在MCU中完全集成了FlexRay控制器。
尽管宣称的目标之一是“降低成本”，FlexRay系统已经不再比相似的CAN架构贵多少了。因为需要增加必要的硅片，FlexRay的芯片成本要高于CAN。但是，BMW的内部研究表明，整个系统的成本是非常接近的，而且还获得了更高的性能和可扩充性以及更低的复杂度。
结论
FlexRay有很多潜力。BMW的试验性项目还仅仅是开始，它证明了FlexRay系统“一旦正确建立”就可以稳定地运行。强烈建议在不同的开发阶段选择通用工具，以便保持对众多不同需求的清晰的整体观。具有扩展检查系统的工具简化了开发者的工作并且从一开始就能帮助预防错误。由于FlexRay，很快就会出现大量的计算机通信应用软件。
很久以前CAN总线就遭遇了本身的局限性。现代汽车电子架构需要不断地扩大网络化。只有提供更大的传输容量，日益加快的控制算法付诸实施时才会产生效果。很多车型在开始生产时就已经达到了最大的总线负载，而没有预留任何带宽。总线系统的数量加倍无论如何都不会使数据速率加倍。为系统联网而增加的必要的网关，不仅使系统变得错综复杂，而且可能产生不可接受的报文传输延迟。更要命的是，缺乏确定性成为了安全关键应用的绊脚石。
在发展过程中，CAN不能满足汽车中逐渐增长的数据传输要求，这导致了FlexRay串行总线系统的发展。去年底，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。
在分布式系统中保持整体观特别重要。在一开始，网络设计者往往不知道真实应用软件随后是如何进行实际通信的，也不清楚它们的执行时间。另一方面，ECU开发者习惯于只关注开发应用程序，而不怎么关心整个FlexRay通信过程的时间状况。但是，一个循环内的FlexRay数据必须保持一致，并且时间触发型总线的应用程序也必须保证一直同步。
因此，Hartwich留意了那些可能引起数据不一致的问题。比如，必须避免在发送过程中更新发送数据，这会导致在同一帧中同时包含新旧数据。BMW使用所谓的“信号窗口”解决了这一问题，它保证任务仅在该专用窗口中发送报文。这种方法的另一个好处是应用程序与通信分离：如果通信调度发生了改变，那么不会影响应用程序。
在实时系统中，任务同步是一项必须引起特别关注的关键特性。“调度表的正确同步问题至关重要”，Winfried Janz解释道，他是Vector公司OSEK实时操作系统开发项目的带头人兼产品经理。在关于OSEKtime和AUTOSAR操作系统的演讲中，他论述了如何按照规范使调度表与全局时间同步（参考图2）。选择硬同步（调度表跳转到一个预定义的执行点或者暂时停止了）还是软同步（在每个到期时刻进行时间调整，但是这些时刻的分配是无规律的，会导致一些无规律的时间调整行为）取决于应用程序是否容忍跳转和暂停。
图2：调度表状态图显示了同步是如何实现的。调度被启动，但不必立即完全同步（RUNNING）。为实现同步运行（AND SYNCHRONOUS），可以进入等待状态（SHEDULETABLE_WAITING）或者进行软同步。
在开发阶段，监视同步和数据一致性由软件工具来完成。“我们必须做到同步地处理模型，否则就会丢失数据”，当Carsten B？ke博士解释Vector的工具CANoe时他这样说道。B？ke演示了CANoe提供的确保同步和检测不一致数据的机制。CANoe运行模型的主要体系结构基于一种使用所谓“通知句柄”的通知概念。它包括了接收到消息时的模型激活、定时器到期时的处理和错误状态的检测。尤其是，这种概念针对FlexRay作了扩展，包含了在FlexRay循环的特定时刻进行的同步通知，如图3所示。另外，B？ke演示了一种运行CANoe RT、具有特定硬件支持的优化平台，该平台是为了满足FlexRay系统严格的时间要求而定制的，比较适合中小尺寸的硬件在回路仿真。
图3：在CANoe中，可以参照循环开始或特定时隙的结束有规律地执行动作。当然，通知也可以发生在总线上接收到帧或丢帧的时候。
FlexRay与AUTOSAR
“为将来做准备，必须按照AUTOSAR标准设计新的软件概念”，负责FlexRay基础软件开发的Dirk Gro？mann说。因为Vector Informatik公司是AUTOSAR协会的成员，所以该协会的成果和结论很快就在Vector的FlexRay开发中得到了实践，如图4所示。Vector的FlexRay接口和FlexRay driver已经符合AUTOSAR标准了，因而可以在今天不用依赖于以后特定的应用程序而开发这些组件，而且这些组件可以灵活地适合不同的车型和平台。FlexRay driver对通信控制器进行了抽象，而FlexRay接口提供了针对和FlexRay调度表无关的单个PDU（协议数据单元）的访问入口。 此外，Vector提供符合AUTOSAR标准的网络管理和传输协议实现。作为对AUTOSAR的补充，可以将XCP协议集成到FlexRay栈中。Gro？mann还谈到通过FlexRay进行flash编程的可能性：“一种方案是完全交换协议并且使用单独的调度表进行flash编程。”
Oliver Kitt在其演讲中更为深入地论述了使用XCP（由ASAM标准化的一种标定协议）标定ECU的话题。在Vector公司，他负责测量、标定和诊断工具CANape的硬件接口集成工作。XCP中的“X”表示不同的传输层，比如它可以表示XCP-on-CAN、XCP-on-Ethernet以及2006年2月发布的XCP-on-FlexRay等。这是一种单主/多从概念，可以非常高效地与ECU通信并且使用可变带宽进行测量和标定。可以将slave集成到FlexRay栈中，而由工具来提供对协议master功能的支持。在运行时刻根据需要为单个节点重新分配带宽。有必要使用一种增强版FlexRay driver来实现XCP-on-FlexRay的buffer重配置。这也展示出组件的灵活操作。
图4：符合AUTOSAR标准的FlexRay软件方案可灵活地适应不同的需求。该图展示了一种带有driver（相对于AUTOSAR进行了扩展并增加了XCP传输层和协议模块）的FlexRay栈。
FlexRay协议规范的编辑，在Freescale公司负责FlexRay相关工作的Mathias Rausch博士（工程学），阐述了buffer结构是如何影响整个系统的。Rausch详细描述了配置不同的静态或动态段时优化buffer存放的方法。另外，Freescale利用了FlexRay协议中没有详细规定控制器主机接口（CHI）、仅规定最低需求作为约束条件的实际情况。这给了半导体厂商提供特殊功能的自由。CHI的优化设计使随后的软件更容易构造。Rausch建议使用工具，因为“配置多达128个消息buffer时需要考虑很多参数”。
在Schedl博士的请求下，NXP半导体公司汽车商务领域创新和发展管理主管Patrick Heuts先生挑选出了更为经济的FlexRay组件。“除了收发器，我们也提供FlexRay控制器，它是完全集成在MCU中的，是一种单片机方案。相比较那种通常作为外围设备嵌入到MCU中的FlexRay控制器，这种完全集成的方案具有明显的优势。比如，消息buffer的数量和类型可以灵活配置。事实上，完全集成的FlexRay控制器工作起来更像一种具有一个或两个通道的DMA工具。NXP半导体公司的下一步计划是研究在片上集成收发器是否可以进一步降低系统的成本”。参考图5。
图5：NXP半导体公司提供了“MCU中心”解决方案，其优点是在MCU中完全集成了FlexRay控制器。
尽管宣称的目标之一是“降低成本”，FlexRay系统已经不再比相似的CAN架构贵多少了。因为需要增加必要的硅片，FlexRay的芯片成本要高于CAN。但是，BMW的内部研究表明，整个系统的成本是非常接近的，而且还获得了更高的性能和可扩充性以及更低的复杂度。
结论
FlexRay有很多潜力。BMW的试验性项目还仅仅是开始，它证明了FlexRay系统“一旦正确建立”就可以稳定地运行。强烈建议在不同的开发阶段选择通用工具，以便保持对众多不同需求的清晰的整体观。具有扩展检查系统的工具简化了开发者的工作并且从一开始就能帮助预防错误。由于FlexRay，很快就会出现大量的计算机通信应用软件。
举报
