FlexRay,FlexRay时代

FlexRay,FlexRay时代

    

      今天，随着FlexRay作为一种新的总线系统进入汽车领域，越来越多的工程师为了完成他们的日常工作而面临新的挑战，因此FlexRay工程师需要新的工具帮助他们完成FlexRay开发任务以及解决遇到的FlexRay问题。本文将揭示FlexRay工程师如何利用Vector公司的CANoe.FlexRay来满足对于分析、仿真以及测试FlexRay网络和ECU的需求。

      在开发FlexRay网络和ECU的过程中，工程师经常要面对一些具有挑战性的任务，例如总线启动阶段仿真、ECU测试和网络仿真。FlexRay工程师可以利用CANoe.FlexRay有效地完成这些任务。
 
总线启动阶段仿真

      FlexRay总线通信的基本要求之一是总线同步。在应用程序能够通信之前，总线必须被启动。在启动过程中，总线处于异步模式；当至少两个ECU完成FlexRay时钟的同步并发出了同步帧，使得其它ECU能够加入到时分多路访问（TDMA）调度表中，此时总线进入同步模式。当对单个FlexRay ECU进行测试时，测试工具必须能够仿真已经启动的FlexRay总线。CANoe.FlexRay能够产生两个启动/同步帧，从而完成FlexRay总线的启动。集群的启动阶段可以通过Vector公司的FlexRay接口卡的异步模式进行观测。在集群进入同步模式之前，CANoe.FlexRay可以接收唤醒命令、符号、启动信息和一般帧。在这个阶段，检测总线行为可以不使用FIBEX数据库，只需要设置总线波特率来初始化网络接口即可。为了启动一个休眠中的集群，可以通过CANoe.FlexRay发送唤醒命令和符号。同步模式是默认模式，而且同步模式和异步模式可以共存，这样接口卡可以根据时钟同步状态自动切换它的工作模式，从而使得FlexRay工程师在任意时刻进行完整的分析和仿真。

通过激励进行ECU测试

      测试ECU的最简单方法是利用CANoe中的FlexRay帧面板发送帧。利用这个FlexRay帧面板，可以实现在运行时改变FlexRay帧内的信号值。所有总线系统中的信号都可以通过用户自定义的控制面板来实现交互式的改变。使用信号发生器也可以实现根据预定义的功能来改变信号值。对于更加高级和复杂的信号产生（例如任意信号序列），可以使用编程语言CAPL。使用CANoe的测试特征集，可以实现ECU测试的自动执行和自动报告生成。

观察ECU测试

      在开发ECU的过程中， ECU的通信与FlexRay调度表之间保持一致是至关重要的。尤其是调度表中的静态部分，所有传输都是基于时间触发的。CANoe可以直接测试ECU是否将预定义的所有帧发送到总线上，并将结果可视化。这一特点是通过CANoe.FlexRay中的FlexRay集群监视器来实现的。它可以帮助工程师回答以下问题：

• 那些ECU在线并发送帧？
• 指定节点是否发送了所有它应该发送的帧？
• 帧是否在所有的调度表周期内都被发送？    

      FlexRay集群监视器也可以用于离线模式，从而对记录文件进行分析。更多的测试任务可以通过CAPL编程来实现。

通过仿真进行ECU测试

      为了对ECU的功能进行测试，有时需要对其工作环境进行仿真。被测设备或系统通常嵌入到硬件在环仿真中。一个最小化的残余总线仿真应该对被测ECU产生输入帧，并对ECU的输出帧做出反应。当然，如果能够仿真测试环境（如传感器输入和执行器输出）更好。在一些更复杂的案例中，近似连续控制算法（例如用Matlab/Simulinnk定义的控制算法）可以在CANoe下运行。由于时间触发通信需要根据一个全局FlexRay时间进行，因此被仿真的控制器和ECU的控制算法必须与FlexRay调度表实现同步。所以运行平台必须提供同步点，在保证小延迟的同时，保证最小的、定常的抖动。这样可以确保在总线上提供时间正确的数据更新。对于环境仿真和残余总线仿真，运行平台必须是确定性的。CANoe实时系统（包括硬件平台）提供了一个高性能的确定性平台。CANoe和CANoe实时系统（包括硬件平台）可以无缝集成在一起，从而满足性能、总线和IO接口三方面要求。在CANoe和CANoe实时系统中可以使用相同的模型。

集群仿真

      在FlexRay系统的设计初期，定时是否正确或ECU性能是否满足通信调度表非常重要。简单一点就是要在指定的时间发送和接收相应的帧。因此，FlexRay工程师可以利用添加FIBEX数据库到CANoe.FlexRay中并定义被测系统需要的节点，从而实现残余总线仿真。CANoe.FlexRay允许仿真集群中所有ECU产生的全部总线负载。FIBEX数据库中的通信矩阵和FlexRay调度表可以用来配置所有ECU的仿真。所有的帧都以默认值自动发送到总线上。通过Vector的硬件接口，理论上的最大帧可以直接发送到总线上，无需考虑资源问题（例如缺少发送缓存）。通过这种方式，可以仅仅利用一个工具和一个硬件接口仿真所有的FlexRay ECU。FlexRay总线提供对于网络管理和休眠/唤醒功能的支持。Vector硬件接口卡上的收发器可以切换到休眠模式从而仿真休眠节点。在这种情况下，仅仅能够接收到唤醒命令。唤醒命令一般用来唤醒一个休眠中的集群。利用CANoe.FlexRay，任何仿真节点可以根据AUTOSAR的网络管理协议来参与网络管理。

网关仿真

      网关用于在两种或两种以上的总线之间进行报文/帧/信号的传输。由于CAN总线在汽车上的广泛使用，因此当试图在汽车上应用FlexRay总线时，CAN/FlexRay网关是无法避免的。作为一个支持CAN、LIN、MOST和FlexRay的多总线工具，CANoe既能仿真网关，也可以分析网关。

      一个虚拟网关可以用于仿真分析ECU之间通信的错误。可以用CANoe仿真一个FlexRay-FlexRay网关，从而实现被测设备和真实总线之间的隔离。两个FlexRay集群之间可以实现同步。同步运行的集群可以保证在不同总线上发生的信号之间的最小时间延迟。

总结

      上诉情况都是FlexRay工程师日常工作的一部分。当处理与FlexRay总线相关的技术问题时，CANoe.FlexRay是一个强大的工具。CANoe是Vector总线开发工具链和嵌入式软件组件中的核心产品，可以帮助工程师面对当前和未来的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）或者进行软同步。

    在开发阶段，监视同步和数据一致性由软件工具来完成。“我们必须做到同步地处理模型，否则就会丢失数据”，当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编程。”

    

     图4：符合AUTOSAR标准的FlexRay软件方案可灵活地适应不同的需求。该图展示了一种带有driver（相对于AUTOSAR进行了扩展并增加了XCP传输层和协议模块）的FlexRay栈。

    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重配置。这也展示出组件的灵活操作。

    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，很快就会出现大量的计算机通信应用软件。

参考文献：

[1] Mayer, E.: Data communication in the automobile. Part 4: FlexRay for data exchange in safety-critical applications. Elektronik Automotive, 2007, Issue 2, pp. 42ff.