汽车ECU通讯新平台--FlexRay(V2.1)协议规范
FlexRay通信协议中文版
一、FlexRay介绍FlexRay通讯协议运用于可靠的车内网络中，是一种具备故障容错的高速汽车总线系统。
它已经成为同类产品的基准，将在未来很多年内，引导汽车电子产品控制结构的发展方向。
FlexRay协议标准中定义了同步和异步帧传输，同步传输中保证帧的延迟和抖动，异步传输中有优先次序，还有多时钟同步，错误检测与避免，编码解码，物理层的总线监控设备等。
1.1汽车网络通信协议综述汽车网络通信协议在保证整个系统正常运行方面起着非常重要的作用。
它可以帮助解决系统很多问题，如数据共享、可扩展性、诊断接口等。
目前，应用于汽车领域的网络标准除了FlexRay还有很多，如CAN、LIN、J1850及MOST等。
CAN总线全称为“控制器局域网总线（Controller Area Network）”，是德国博世公司从80年代初为解决现代汽车中众多的控制与测试仪器之间的数据交换而开发的一种串行数据通信协议。
它是一种多主总线，通信介质可以是双绞线、同轴电缆或光导纤维。
CAN通信速率可达１Mbit/s，每帧的数据字节数为8个。
LIN（Local Interconnect Network，控制器局域网）总线是由LIN 协会发布的一种新型低成本串行通信总线，也称为经济型CAN网络。
LIN的目标是为现有汽车网络（例如CAN 总线）提供辅助功能，因此LIN总线是一种辅助的总线网络，在不需要CAN 总线的带宽和多功能的场合比如智能传感器和制动装置之间的通信使用LIN总线可大大节省成本。
J1850总线是1994年由汽车工程师协会颁布的标准，之后普及运用于美国车厂的汽车中。
不过，虽然美国各厂多采用J1850标准，但是各厂的实际做法又不相同，因此相对其他标准来说比较混乱。
由于J1850总线通信速率低，只适合用于车身控制系统及诊断系统，目前在美国逐步被CAN 所取代。
MOST（Media Oriented System Transport，面向媒体的系统传输）总线是采用光纤并用于智能交通及多媒体的网络协议，能够支持24.8Mbps的数据速率，与以前的铜缆相比具有减轻重量和减小电磁干扰的优势。
FlexRay通信协议中文版
一、FlexRay介绍FlexRay通讯协议运用于可靠的车内网络中，是一种具备故障容错的高速汽车总线系统。
它已经成为同类产品的基准，将在未来很多年内，引导汽车电子产品控制结构的发展方向。
FlexRay协议标准中定义了同步和异步帧传输，同步传输中保证帧的延迟和抖动，异步传输中有优先次序，还有多时钟同步，错误检测与避免，编码解码，物理层的总线监控设备等。
1.1汽车网络通信协议综述汽车网络通信协议在保证整个系统正常运行方面起着非常重要的作用。
它可以帮助解决系统很多问题，如数据共享、可扩展性、诊断接口等。
目前，应用于汽车领域的网络标准除了FlexRay还有很多，如CAN、LIN、J1850及MOST等。
CAN总线全称为“控制器局域网总线（Controller Area Network）”，是德国博世公司从80年代初为解决现代汽车中众多的控制与测试仪器之间的数据交换而开发的一种串行数据通信协议。
它是一种多主总线，通信介质可以是双绞线、同轴电缆或光导纤维。
CAN通信速率可达１Mbit/s，每帧的数据字节数为8个。
LIN（Local Interconnect Network，控制器局域网）总线是由LIN 协会发布的一种新型低成本串行通信总线，也称为经济型CAN网络。
LIN的目标是为现有汽车网络（例如CAN 总线）提供辅助功能，因此LIN总线是一种辅助的总线网络，在不需要CAN 总线的带宽和多功能的场合比如智能传感器和制动装置之间的通信使用LIN总线可大大节省成本。
J1850总线是1994年由汽车工程师协会颁布的标准，之后普及运用于美国车厂的汽车中。
不过，虽然美国各厂多采用J1850标准，但是各厂的实际做法又不相同，因此相对其他标准来说比较混乱。
由于J1850总线通信速率低，只适合用于车身控制系统及诊断系统，目前在美国逐步被CAN 所取代。
MOST（Media Oriented System Transport，面向媒体的系统传输）总线是采用光纤并用于智能交通及多媒体的网络协议，能够支持24.8Mbps的数据速率，与以前的铜缆相比具有减轻重量和减小电磁干扰的优势。
FlexRay汽车通信总线介绍及测试环境(原创博文)
FlexRay汽车通信总线介绍及测试环境综述FlexRay通信总线是由多个汽车制造商和领先的供应商共同开发的确定性、容错和高速总线系统。
FlexRay满足了线控应用（即线控驱动、线控转向、线控制动等）的容错性和时间确定性的性能要求，本文介绍FlexRay的基础知识。
为了使汽车继续提高安全性、提升性能、减少环境影响并增强舒适性，必须提高汽车电子控制单元（ECU）之间传送数据的速度、数量和可靠性。
先进的控制和安全系统(结合了多个传感器、执行器和电子控制单元)开始要求同步功能和传输性能超过现有标准的控制器局域网（CAN）所能提供的性能。
随着带宽需求的增长和各种先进功能的实现，汽车工程师急需下一代嵌入式网络。
经过OEM厂商、工具供应商和最终用户的多年合作，FlexRay标准已经成为车载通信总线，以应对下一代车辆中的这些新的挑战。
FlexRay还能够提供很多CAN网络不具有的可靠性特点，尤其是FlexRay 具备的冗余通信能力可实现通过硬件完全复制网络配置，双通道冗余进行数据通信。
FlexRay同时提供灵活的配置，可支持各种拓扑，如总线、星型和混合拓扑。
设计人员可以通过结合两种或两种以上的该类型拓扑来配置分布式系统。
了解FlexRay的工作原理对工程师在车辆设计和生产过程的各个方面都至关重要。
本文将解释FlexRay的核心概念。
FlexRay基础FlexRay的许多方面旨在降低成本，同时在恶劣的环境中提供最佳性能。
FlexRay使用非屏蔽双绞线电缆将节点连接在一起，FlexRay总线可以由一对或两对电缆组成的单通道和双通道组成。
每对线缆上的差分信号减少了外部噪声对网络的影响，而无需昂贵的屏蔽层。
大多数FlexRay节点通常还具有可用于收发器和微处理器的电源线和地线。
双通道配置可提高容错能力或增加带宽。
大多数第一代FlexRay网络仅利用一个信道来降低布线成本，但是随着应用程序对复杂性和安全性要求的提高，未来的网络将同时使用这两个信道。
Flexray线控总线技术
高速
FlexRay支持高达10 Mbps的数据传 输速率，满足汽车中大量数据传输的 需求。
可靠性
FlexRay具有错误检测和纠正功能， 能够保证数据传输的可靠性。
工作原理
1 2
通信模式
FlexRay支持静态和动态两种通信模式，可以根 据实际需求进行选择。
拓扑结构
FlexRay支持星型和总线型两种拓扑结构，可以 根据汽车内部ECU的分布情况进行选择。
的领域，其优势可能无法充分发挥。
对实时性的 依赖
由于FlexRay总线的通信机制和硬件资源限制，其支 持的节点数量有限，可能不适合大规模分布式系统。
04
FlexRay线控总线与其他总线的比较
CAN总线
总结词
CAN总线是一种广泛应用于汽车行业的通信协议，具有高可靠性和良好的实时 性。
详细描述
CAN总线采用基于优先级的通信方式，支持多主节点同时通信，具有较高的数 据传输速率和较低的延迟时间。然而，CAN总线在处理大量数据和复杂通信时 可能会遇到带宽限制。
随着汽车电子化程度的不断提高，对汽车内部通信的要求也 越来越高，FlexRay总线技术正是在这样的背景下应运而生。
技术发展历程
FlexRay总线技术最初由BMW和戴姆勒-克莱斯勒于1999年联合开发，旨在为汽车 内部通信提供一种高性能、高可靠性的总线系统。
自推出以来，FlexRay总线技术得到了广泛的认可和应用，已成为汽车内部通信的标 准之一。
市场前景
增长的市场需求
竞争格局变化
未来发展方向
随着汽车电子化程度的不断提高，对 线控技术的需求也在不断增长。 FlexRay总线技术作为汽车线控技术 的关键组成部分，其市场需求将进一 步扩大。
flexray,协议中文版
竭诚为您提供优质文档/双击可除flexray,协议中文版篇一：通信协议标准FlexRay总线的功能安全性详解通信协议标准FlexRay总线的功能安全性详解在汽车中采用电子系统已经有几十年的历史，它们使汽车安全、节能与环保方面的性能有大幅度的提高。
随着研究的深入，许多系统需要共享和交换信息，为了节省线缆，就形成了依赖于通信的分布式嵌入系统。
目前，世界上90%的都采用基于can总线的系统。
FlexRay是下一代通信协议事实上的标准，它的功能安全性如何是至关重要的。
1iec61508功能安全的要求目前车控系统正在向线控技术（xbywire）过渡，例如线控转向与线控刹车。
线控系统最终目标是取消机械后备，因为取消这些后备可以降低成本，增强设计的灵活性，扩大适用范围，为以后新添功能创造条件。
但是取消机械后备就对电子系统的可信赖性（dependability）要求大为提高。
车是一个运动的物体，处于运动的环境之中，它因故障可能伤及自身及别人。
取消机械后备，就将电子系统由今天的故障静默（failsilent）要求提升到故障仍工作（failoperational）的要求。
国际上对工业应用的功能安全要求已制定了标准iec61508，它主要关心被控设备及其控制系统的安全。
虽然它也适用于汽车，但汽车不仅有上述功能安全问题，而且要关心由于功能变化造成的整车系统安全，所以汽车业内正在制定相应的标准iso26262。
汽车的功能安全等级分为4级，要求最高的是asild，相应的失效概率＜10-8/h，它相当于iec61508的sil3。
根据实践经验，分配给通信的失效概率＜10-10/h。
有关这方面的介绍可参见参考文献。
现在安全攸关的应用系统的范围有所扩大，以前不算在内的一些系统现在都要算了。
例如安全预先动作系统（presafe）中座椅调整子系统、刹车辅助系统中的灯光控制子系统、碰撞后telematic自动呼叫求援的子系统，都将视为安全攸关系统。
汽车ecu bms通信协议标准
标题：汽车ECU BMS通信协议标准一、概述随着汽车电子系统的不断发展和智能化水平的提高，汽车的ECU（汽车电子控制单元）和BMS（电池管理系统）之间的通信协议变得越来越重要。
通信协议标准的统一对于汽车电子系统的互操作性和稳定性至关重要。
本文将重点探讨汽车ECU和BMS之间的通信协议标准。
二、汽车ECU和BMS的通信协议标准1. CAN总线通信协议CAN（Controller Area Network）总线是一种广泛应用于汽车电子系统中的通信协议。
它具有高速传输、抗干扰能力强等优点，在汽车ECU和BMS之间的通信中得到了广泛应用。
2. LIN总线通信协议LIN（Local Interconnect Network）总线是一种针对汽车电子系统中从属设备之间通信的低成本、低速率的总线标准。
在汽车BMS和部分低带宽要求的ECU之间的通信中，LIN总线也得到了应用。
3. FlexRay通信协议FlexRay是一种高速、冗余的汽车网络协议，它被设计用于替代现有的汽车通信标准，提供更高的数据传输速率和实时性能。
在某些高性能汽车和BMS之间的通信中，FlexRay也得到了应用。
三、通信协议标准的选择和应用1. 根据汽车电子系统的要求，选择合适的通信协议标准，考虑到数据传输速率、实时性能、抗干扰能力等因素。
2. 对于不同的汽车电子系统，选择不同的通信协议标准，以确保各个子系统之间的通信稳定和可靠。
3. 根据通信协议标准的应用场景和技术要求，对汽车ECU和BMS之间的通信协议进行定制化设计和开发，以满足具体需求。
四、未来发展趋势1. 随着汽车电子系统的不断发展和智能化水平的提高，汽车的ECU和BMS之间的通信协议标准将会不断进化和完善。
2. 在未来，通信协议标准的选择和应用将更加智能化和个性化，以满足汽车电子系统对数据传输速率、实时性能和稳定性的不断提升的需求。
3. 通信协议标准的开放性和统一性将会更加重要，以促进不同厂商的汽车电子系统之间的互操作和兼容性。
（完整版）FlexRay总线原理及应用
（完整版）FlexRay总线原理及应⽤FlexRay 总线原理及应⽤1 FlexRay 总线介绍1.1 FlexRay 产⽣及发展随着汽车中增强安全和舒适体验的功能越来越多，⽤于实现这些功能的传感器、传输装置、电⼦控制单元(ECU)的数量也在持续上升。
如今⾼端汽车有100 多个ECU，如果不采⽤新架构，该数字可能还会增长，ECU 操作和众多车⽤总线之间的协调配合⽇益复杂，严重阻碍线控技术( X-by-Wire ，即利⽤重量轻、效率⾼、更简单且具有容错功能的电⽓/电⼦系统取代笨重的机械/液压部分)的发展。
即使可以解决复杂性问题，传统的车⽤总线也缺乏线控所必需的确定性和容错功能。
例如，与安全有关的信息传递要求绝对的实时，这类⾼优先级的信息必须在指定的时间内传输到位，如刹车，从刹车踏板踩下到刹车起作⽤的信息传递要求⽴即正确地传输不允许任何不确定因素。
同时，汽车⽹络中不断增加的通信总线传输数据量，要求通信总线有较⾼的带宽和数据传输率。
⽬前⼴泛应⽤的车载总线技术CAN 、LIN 等由于缺少同步性，确定性及容错性等并不能满⾜未来汽车应⽤的要求。
宝马和戴姆勒克莱斯勒很早就意识到了，传统的解决⽅案并不能满⾜汽车⾏业未来的需要，更不能满⾜汽车线控系统( X-by-Wire )的要求。
于是在2000 年9 ⽉，宝马和戴姆勒克莱斯勒联合飞利浦和摩托罗拉成⽴了FlexRay 联盟。
该联盟致⼒于推⼴FlexRay 通信系统在全球的采⽤，使其成为⾼级动⼒总成、底盘、线控系统的标准协议。
其具体任务为制定FlexRay 需求定义、开发FlexRay 协议、定义数据链路层、提供⽀持FlexRay 的控制器、开发FlexRay 物理层规范并实现基础解决⽅案。
1.2 FlexRay 特点FlexRay 提供了传统车内通信协议不具备的⼤量特性，包括：(1) ⾼传输速率：FlexRay 的每个信道具有10Mbps 带宽。
由于它不仅可以像CAN 和LIN ⽹络这样的单信道系统⼀般运⾏，⽽且还可以作为⼀个双信道系统运⾏，因此可以达到20Mbps 的最⼤传输速率，是当前CAN 最⾼运⾏速率的20 倍。
汽车控制系统效能升级!FlexRay网络标准详解
汽车控制系统效能升级！FlexRay网络标准详解自2003年组建以来，AUTOSAR（汽车开放系统架构）联盟一直致力于改变车载网络和电子控制单元（ECU）的设计方式。
AUTOSAR提出了一个符合业界标准的车载网络设计方法，使行业能够集成、交换和传输汽车网络内的功能、数据和信息。
这一标准极大地促进了汽车原始设备制造商（OEM）及其一级供应商之间的合作，使他们能够以一种一致、明确且机器可读的格式来交换设计信息。
一辆汽车的不同部分对安全及性能有不同要求，而支持它们的车载网络必须具备可预测的安全性能。
随着汽车技术的不断演变，人们已经可以用一系列总线技术来连接豪华汽车上最多100个不同的ECU，这些总线技术通常包括LIN、CAN、FlexRay、MOST和基于以太网的架构。
如果靠手动来管理这些ECU 之间数以千计的信息和交互操作是不可能的，因此汽车设计人员必然用自动化设计和合成工具来预测网络性能和调整车载功能。
汽车数据总线一辆典型的现代化汽车将同时装配各类总线和协议并从LIN、CAN、FlexRay、MOST和以太网中选择合适的网络。
多媒体/视听信号和汽车环绕摄像系统需要更高的数据速率，因此汽车制造商和OEM厂商在网络解决方案上选择用以太网代替MOST.但对于许多标准汽车功能而言，LIN和CAN提供的带宽与性能就足够了。
在汽车架构中，ECU组合在一起形成“集群”，这些集群通过通信“网关”相连。
集群通常会共享同一类型的总线，因此要达到高可靠性、高速率的标准，就要采用FlexRay 网络，但要求没那么高的门锁ECU可以由CAN或LIN来负责。
ECU网关往往要连接不同类型的信号，并执行不同总线架构之间的映射和转换功能。
汽车行业对不断提高安全性和ISO26262等标准的合规性提出强烈需求，进而提升了车载网络的性能，同时也降低了制造和元件成本。
不断进步的网络标准可以适应越来越高的数据传输速率，汽车电缆也达到了安全且低成本的目标。
FlexRay总线原理及应用
FlexRay总线原理及应用1 FlexRay总线介绍1.1 FlexRay产生及发展随着汽车中增强安全和舒适体验的功能越来越多，用于实现这些功能的传感器、传输装置、电子控制单元(ECU)的数量也在持续上升。
如今高端汽车有100多个ECU，如果不采用新架构，该数字可能还会增长，ECU操作和众多车用总线之间的协调配合日益复杂，严重阻碍线控技术（X-by-Wire，即利用重量轻、效率高、更简单且具有容错功能的电气/电子系统取代笨重的机械/液压部分）的发展。
即使可以解决复杂性问题，传统的车用总线也缺乏线控所必需的确定性和容错功能。
例如，与安全有关的信息传递要求绝对的实时，这类高优先级的信息必须在指定的时间内传输到位，如刹车，从刹车踏板踩下到刹车起作用的信息传递要求立即正确地传输不允许任何不确定因素。
同时，汽车网络中不断增加的通信总线传输数据量，要求通信总线有较高的带宽和数据传输率。
目前广泛应用的车载总线技术CAN、LIN等由于缺少同步性，确定性及容错性等并不能满足未来汽车应用的要求。
宝马和戴姆勒克莱斯勒很早就意识到了，传统的解决方案并不能满足汽车行业未来的需要，更不能满足汽车线控系统（X-by-Wire）的要求。
于是在2000年9月，宝马和戴姆勒克莱斯勒联合飞利浦和摩托罗拉成立了FlexRay联盟。
该联盟致力于推广FlexRay通信系统在全球的采用，使其成为高级动力总成、底盘、线控系统的标准协议。
其具体任务为制定FlexRay需求定义、开发FlexRay 协议、定义数据链路层、提供支持FlexRay的控制器、开发FlexRay物理层规范并实现基础解决方案。
1.2 FlexRay特点FlexRay提供了传统车内通信协议不具备的大量特性，包括：(1)高传输速率：FlexRay的每个信道具有10Mbps带宽。
由于它不仅可以像CAN和LIN网络这样的单信道系统一般运行，而且还可以作为一个双信道系统运行，因此可以达到20Mbps的最大传输速率，是当前CAN最高运行速率的20倍。
FlexRay介绍
FlexRay一、FlexRay介绍 (2)1.1汽车网络通信协议综述 (2)1.2FlexRay特点 (2)1.3FlexRay协会 (3)1.4FlexRay应用 (3)二、FlexRay协议 (4)2.1FlexRay的ECU结构 (4)2.2FlexRay通信模式 (5)2.3FlexRay拓扑结构 (6)2.4FlexRay帧格式 (8)2.4.1帧头部分 (8)2.4.2有效数据部分 (8)2.4.3帧尾部分 (9)2.5帧编码与解码 (9)2.5.1帧编码 (9)2.5.2特征符编码 (10)2.6时钟同步 (11)2.7唤醒与启动 (12)三、FlexRay物理层 (13)3.1FlexRay总线信号 (13)3.2FlexRay套件（以富士通为例） (13)3.2.1FlexRay开发进程 (13)3.2.2FlexRay产品 (14)3.2.3FlexRay产品特性 (15)四、历史与展望 (16)4.1汽车技术与汽车产业 (16)4.2关于汽车计算平台的思考与机会 (17)一、FlexRay介绍FlexRay通讯协议运用于可靠的车内网络中，是一种具备故障容错的高速汽车总线系统。
它已经成为同类产品的基准，将在未来很多年内，引导汽车电子产品控制结构的发展方向。
FlexRay协议标准中定义了同步和异步帧传输，同步传输中保证帧的延迟和抖动，异步传输中有优先次序，还有多时钟同步，错误检测与避免，编码解码，物理层的总线监控设备等。
1.1汽车网络通信协议综述汽车网络通信协议在保证整个系统正常运行方面起着非常重要的作用。
它可以帮助解决系统很多问题，如数据共享、可扩展性、诊断接口等。
目前，应用于汽车领域的网络标准除了FlexRay还有很多，如CAN、LIN、J1850及MOST等。
CAN总线全称为“控制器局域网总线（Controller Area Network）”，是德国博世公司从80年代初为解决现代汽车中众多的控制与测试仪器之间的数据交换而开发的一种串行数据通信协议。
flexray协议原理
flexray协议原理FlexRay协议原理概述FlexRay是一种高速实时网络协议，特别适用于汽车电子系统中的分布式控制和通信。
它通过提供高带宽、低延迟和可靠性来满足汽车电子系统对数据传输的严格要求。
本文将介绍FlexRay协议的原理和工作机制。
FlexRay网络结构FlexRay网络由多个节点组成，每个节点都可以是一个控制器、传感器或执行器。
这些节点通过FlexRay总线相互连接，并通过FlexRay协议进行通信。
FlexRay网络通常采用双线缆冗余结构，以提高可靠性。
FlexRay通信周期FlexRay网络按照时间分割成周期，每个周期由两个静态段和一个动态段组成。
静态段用于发送控制信息，而动态段用于发送数据。
静态段和动态段的长度是固定的，并且根据网络的需求进行配置。
FlexRay通信帧FlexRay通信帧是数据传输的基本单元。
每个通信帧由一个静态段帧头、一个静态段有效载荷、一个动态段帧头和一个动态段有效载荷组成。
帧头包含帧的标识符、优先级和数据长度等信息，而有效载荷则包含实际的数据。
FlexRay时钟同步为了确保网络中的所有节点能够按照相同的时钟进行通信，FlexRay 使用了分布式时钟同步技术。
这种技术通过在网络中的节点之间进行时钟同步消息的传输来实现。
每个节点都会定期发送时钟同步消息并接收其他节点发送的时钟同步消息，从而保持时钟的一致性。
FlexRay通信调度FlexRay使用了一种称为静态分布式时间触发调度的方法来管理网络中的通信。
在这种调度方法中，每个节点都被分配了一个固定的时间槽，用于发送数据或控制信息。
节点根据优先级和时隙的分配来确定何时发送数据，并在特定的时间触发时发送数据。
FlexRay冲突解决由于多个节点可能同时发送数据，可能会导致冲突。
为了解决冲突，FlexRay使用了一种称为静态冲突解决的方法。
在这种方法中，每个节点都被分配了一个固定的优先级，优先级较高的节点具有更高的发送优先级。
新一代车内网络总线——FlexRay
第３５卷第４期２００８年８月拖拉机与农用运输车Ｔｒａｃｔｏｒ＆ＦａｒｍＴｒａｎｓｐｏｒｔｅｒＶ０１．３５Ｎｏ．４Ａｕｇ．，２００８新一代车内网络总线——ＦｌｅｘＲａｙ陈松１，王红燕２（１．洛阳拖拉机研究所有限公司，河南洛阳４７１０３９；２．中国一拖集团有限公司，河南洛阳４７１００４）摘要：ＦｌｅｘＲａｙ通信网络是一种新的具有确定性、容错、高速，并能支持分布式控制的总线系统，介绍其背景、技术特点及应用。
关键词：ＦｌｅｘＲａｙ；线控；通信总线；车辆中图分类号：ＴＮ９１５．０４文献标识码：Ａ文章编号：１００６—０００６（２００８）０４—００５５—０２ＮｅｗＧｅｎｅｒａｔｉｏｎＶｅｈｉｃｌｅＮｅｔｗｏｒｋＢｕｓ－－ＦｌｅｘＲａｙＣＨＥＮＳｏｎ９１，ＷＡＮＧＨｏｎｇ．ｙａｎ２（１．ＬｕｏｙａｎｇＴｒａｃｔｏｒＲｅｓｅａｒｃｈＩｎｓｔｉｔｕｔｅＣｏ．，Ｌｔｄ．，Ｌｕｏｙａｎｇ４７１０３９，Ｃｈｉｎａ；２．ＹＴＯＧｒｏｕｐＣｏｒｐｏｒａｔｉｏｎ，Ｌｕｏｙａｎｇ４７１００４，Ｃｈｉｎａ）Ａｂｓｔｒａｃｔ：ＴｈｅＦｌｅｘＲａｙｃｏｍｍｕｎｉｃａｔｉｏｎｓｎｅｔｗｏｒｋｉｓａｎｅｗｆａｕｌｔ．ｔｏｌｅｒａｎｔ，ｄｅｔｅｒｍｉｎｉｓｔｉｃ，ａｎｄｃａｐａｂｌｅｏｆｓｕｐｐｏｒｔｉｎｇｄｉｓｔｒｉｂｕｔｅｄｃｏｎｔｒｏｌｂｕｓｓｙｓｔｅｍ．Ｔｈｉｓａｒｔｉｃｌｅｇｉｖｅｓａｇｅｎｅｒａｌｉｎｔｒｏｄｕｃｔｉｏｎａｂｏｕｔｔｈｅｂａｃｋｇｒｏｕｎｄ，ｓｏｍｅｔｅｃｈｎｉｃａｌｃｈａｒａｃｔｅｒｓａｎｄａｐｐｌｉｃａｔｉｏｎｏｆＦｌｅｘＲａｙ．Ｋｅｙｗｏｒｄｓ：ＦｌｅｘＲａｙ；Ｘ—ｂｙ—ｗｉｒｅ；Ｃｏｍｍｕｎｉｃａｔｉｏｎｓｂｕｓ：ＶｅｈｉｃｌｅＦｌｅｘＲａｙ是国外许多公司正在评估的一种通信协议，由于具有支援高吞吐量、确定性、容错特性等特点，使整个行业对它产生了浓厚的兴趣。
１背景随着“线控”技术的出现，我们将能使用重量轻、效率高、更简单的电子机械系统，如线控制动（Ｂｒａｋｅ－Ｂｙ—Ｗｉｒｅ），电机执行器将电能转换成机械能，通过减速器传输到制动片上，然后制动片将制动压力施加到制动毂上。
(完整版)FlexRay总线原理及应用
FlexRay总线原理及应用1 FlexRay总线介绍1.1 FlexRay产生及发展随着汽车中增强安全和舒适体验的功能越来越多，用于实现这些功能的传感器、传输装置、电子控制单元(ECU)的数量也在持续上升。
如今高端汽车有100多个ECU，如果不采用新架构，该数字可能还会增长，ECU操作和众多车用总线之间的协调配合日益复杂，严重阻碍线控技术（X-by-Wire，即利用重量轻、效率高、更简单且具有容错功能的电气/电子系统取代笨重的机械/液压部分）的发展。
即使可以解决复杂性问题，传统的车用总线也缺乏线控所必需的确定性和容错功能。
例如，与安全有关的信息传递要求绝对的实时，这类高优先级的信息必须在指定的时间内传输到位，如刹车，从刹车踏板踩下到刹车起作用的信息传递要求立即正确地传输不允许任何不确定因素。
同时，汽车网络中不断增加的通信总线传输数据量，要求通信总线有较高的带宽和数据传输率。
目前广泛应用的车载总线技术CAN、LIN等由于缺少同步性，确定性及容错性等并不能满足未来汽车应用的要求。
宝马和戴姆勒克莱斯勒很早就意识到了，传统的解决方案并不能满足汽车行业未来的需要，更不能满足汽车线控系统（X-by-Wire）的要求。
于是在2000年9月，宝马和戴姆勒克莱斯勒联合飞利浦和摩托罗拉成立了FlexRay联盟。
该联盟致力于推广FlexRay通信系统在全球的采用，使其成为高级动力总成、底盘、线控系统的标准协议。
其具体任务为制定FlexRay需求定义、开发FlexRay 协议、定义数据链路层、提供支持FlexRay的控制器、开发FlexRay物理层规范并实现基础解决方案。
1.2 FlexRay特点FlexRay提供了传统车内通信协议不具备的大量特性，包括：(1)高传输速率：FlexRay的每个信道具有10Mbps带宽。
由于它不仅可以像CAN和LIN网络这样的单信道系统一般运行，而且还可以作为一个双信道系统运行，因此可以达到20Mbps的最大传输速率，是当前CAN最高运行速率的20倍。
汽车网络协议（转）
汽车⽹络协议（转）本⽂详细⽐较了现有⼏类主流汽车总线系统的特点。
这些⽐较将有助于界定下⼀代⾼安全性、⾼容错性的分布式汽车通信⽹络标准。
汽车总线协议随着汽车功能的不断增加、可靠性要求的不断提⾼以及价格的不断下降，越来越多的电⼦控制单元（ECU）将被引⼊到汽车中。
⽬前，在⾼端汽车中⼀般会有50个以上的ECU。
为了使这些ECU能够在⼀个共同的环境下协调⼯作，也为了进⼀步降低成本，⼈们设计了针对汽车通信⽹络的总线协议。
⼀般来说，汽车通信⽹络可以划分为四个不同的领域，每个领域都有其独特的要求。
现有的主流汽车总线协议都⽆法适应所有的要求：信息娱乐系统：此领域的通信要求⾼速率和⾼带宽，有时会是⽆线传输，⽬前主流应⽤协议有MOST，正在推出的还有IDB-1394等；⾼安全的线控系统（X-By-Wire）：由于此领域涉及安全性很⾼的刹车和导向系统，所以它的通信要求⾼容错性、⾼可靠性和⾼实时性。
可以考虑的协议有TTCAN、FlexRay、TTP等；车⾝控制系统：在这个领域CAN协议已经有了⼆⼗多年的应⽤积累，其中包括传统的车⾝控制和传动装置控制；低端控制系统：此系统包括那些仅需要简单串⾏通信的ECU，⽐如控制后视镜和车门的智能传感器以及激励器等，这应该是LIN总线最适合的应⽤领域。
其中，控制器局域⽹（CAN）是最有名的、也是最早成为国际标准的汽车总线协议。
CAN协议是串⾏协议，能够有效地⽀持具有⾼安全等级的分布实时系统。
CAN是⼀个多主机系统，所以它设计了⾼效率的仲裁机制来解决传输冲突问题，具有⾼优先级的系统总能优先得到总线的使⽤权。
CAN还同时使⽤了其它⼀些防错⼿段，能够判断出错的节点并及时关闭之，这样就在很⼤程度上保证了总线的可靠性。
CAN的传输速率和总线长度相关，最⾼可以到1Mbps，⼀般车内使⽤的速率是500Kbps到200Kbps。
CAN多年来作为车⾝控制的主⼲⽹已经形成了从IC设计到软件开发和测试验证的完整产业链，⽽且它还将在新的汽车主⼲⽹⾏业标准确⽴之前⼀直充当这⼀⾓⾊。
FlexRay通信系统电气物理层规范V2.1修订本B
FlexRay Communications System Electrical Physical Layer SpecificationVersion 2.1Revision BFlexRay Electrical Physical Layer Specification Disclaimer DISCLAIMERThis specification as released by the FlexRay Consortium is intended for the purpose of information only. The use of material contained in this specification requires membership within the FlexRay Consortium or an agreement with the FlexRay Consortium. The FlexRay Consortium will not be liable for any unauthorized use of this Specification.Following the completion of the development of the FlexRay Communications System Specifications commercial exploitation licenses will be made available to End Users by way of an End User's License Agreement. Such licenses shall be contingent upon End Users granting reciprocal licenses to all Core Partners and non-assertions in favor of all Premium Associate Members and Associate Members.All details and mechanisms concerning the bus guardian concept are defined in the FlexRay Bus Guardian Specifications.The FlexRay Communications System is currently specified for a baud rate of 10 Mbit/s. It may be extended to additional baud rates.No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.The word FlexRay and the FlexRay logo are registered trademarks.Copyright © 2004-2006 FlexRay Consortium. All rights reserved.The Core Partners of the FlexRay Consortium are BMW AG, DaimlerChrysler AG, Freescale Halbleiter Deutschland GmbH, General Motors Corporation, Philips GmbH, Robert Bosch GmbH and Volkswagen AG.Table of contentsCHAPTER 1 INTRODUCTION (7)1.1 Objective (7)1.2 Overview (7)1.3 References (7)1.4 Terms and definitions (8)1.5 List of abbreviations (8)1.6 Notational conventions (9)1.6.1 Parameter prefix conventions (9)1.7 Important preliminary notes (10)1.7.1 Bus speed (10)1.7.2 Functional classes (10)1.7.3 System and conformance tests (10)1.8 Revision history (11)1.8.1 Changes applied to “E-PL spec v2.1 Revision A” (11)1.9 Open issues (11)CHAPTER 2 COMMUNICATION CHANNEL BASICS (12)2.1 Objective (12)2.2 Propagation delay (12)2.2.1 Asymmetric delay (13)2.3 Truncation (14)2.4 Symbol length change (15)2.5 Collisions (15)2.6 EMC jitter (16)2.6.1 EMC jitter on signal edges (16)2.6.2 EMC jitter on TSS-truncation (16)2.6.3 EMC jitter on Symbol length change (16)2.7 Wake-up patterns (17)2.7.1 Overview (17)2.7.2 Valid wake-up pattern (17)2.7.3 Non valid wake-up patterns (18)CHAPTER 3 PRINCIPLE OF FLEXRAY NETWORKING (19)3.1 Objective (19)3.2 Interconnection of nodes (19)CHAPTER 4 NETWORK COMPONENTS (21)4.1 Objective (21)4.2 Cables (21)4.3 Connectors (21)4.4.1 Terminated cable end (22)4.4.2 Un-terminated cable end (23)4.5 Termination concept (23)4.6 Common mode chokes (24)4.7 DC bus load (24)CHAPTER 5 NETWORK TOPOLOGY (26)5.1 Objective (26)5.2 Point-to-point connection (26)5.3 Passive star (27)5.4 Linear passive bus (28)5.5 Active star network (29)5.6 Cascaded active stars (30)5.7 Hybrid topologies (31)5.8 Dual channel topologies (31)CHAPTER 6 ELECTRICAL SIGNALING (32)6.1 Objective (32)6.2 Overview (32)6.3 Bus state: Idle_LP (32)6.4 Bus state: Idle (32)6.5 Bus state: Data_1 (33)6.6 Bus state: Data_0 (33)CHAPTER 7 SIGNAL INTEGRITY (34)7.1 Objective (34)7.2 Definition of test planes (34)7.3 Eye-diagram at TP1 (35)7.4 Eye-diagram at TP4 (only valid for point-to-point connections) (36)CHAPTER 8 ELECTRICAL BUS DRIVER (37)8.1 Overview (37)8.2 Operation modes (38)8.2.1 BD_Normal mode (38)8.2.2 BD_Standby mode (38)8.2.3 BD_Sleep mode (optional) (38)8.2.4 BD_ReceiveOnly mode (optional) (38)8.3 Operation mode transitions (39)8.4 Bus Driver – Communication Controller interface (40)8.4.1 TxD/TxEN behavior in case a Bus Driver - Bus Guardian interface is implemented (40)8.4.2 TxD/TxEN - behavior in case a Bus Driver - Bus Guardian interface is not implemented (41)8.4.3 RxD - behavior (41)8.5 Bus Driver – Bus Guardian interface (optional) (42)8.6.1 Overview (43)8.6.2 Hard wired signals (Option A) (43)8.6.3 Serial Peripheral Interface (SPI) (Option B) (46)8.7 Bus Driver – Power supply interface (46)8.7.1 V CC supply voltage monitoring (47)8.7.2 V BAT supply voltage monitoring (47)8.7.3 Inhibit output (optional) (48)8.8 Bus Driver - Level shift interface (optional) (48)8.8.1 V IO voltage monitoring (48)8.9 Bus Driver - Bus interface (49)8.9.1 Receiver characteristics (49)8.9.2 Receiver behavior (50)8.9.3 Receiver timing characteristics (52)8.9.4 Receiver behavior at transition from idle to active and vice versa (54)8.9.5 Transmitter characteristics (56)8.9.6 Transmitter behavior at transition from idle to active and vice versa (58)8.9.7 Bus Driver - bus interface behavior, when not powered (59)8.9.8 Bus Driver - bus interface behavior under short-circuit conditions (59)8.10 Bus Driver – Wake-up interface (optional) (60)8.10.1 Local Wake-up operating requirements (60)8.11 Remote Wake-up event detector (optional) (60)8.11.1 Remote Wake-up operating requirements (60)8.12 Bus Driver behavior under fault conditions (61)8.12.1 Environmental errors (61)8.12.2 Behavior of unconnected digital input signals (62)8.12.3 Dynamic low battery voltage (63)8.12.4 Bus failure detection (64)8.12.5 Over-temperature protection (64)8.13 Bus Driver functional classes (65)8.13.1 Functional class “Bus Driver voltage regulator control” (65)8.13.2 Functional class “Bus Driver - Bus Guardian interface” (65)8.13.3 Functional class “Bus Driver internal voltage regulator” (65)8.13.4 Functional class “Bus Driver logic level adaptation” (65)8.14 Bus Driver signal summary (66)CHAPTER 9 ACTIVE STAR (68)9.1 Overview (68)9.2 Hardware realization (68)9.2.1 Active star - Communication Controller interface (optional) (69)9.2.2 Active star - Bus Guardian interface (optional) (69)9.2.3 Active star - Power supply interface (69)9.2.4 Active star - Bus interface (69)9.3 Basic functionality (69)9.4 Enhanced functionality (70)9.4.1 Functional class: “Active Star - Communication Controller interface” (70)9.4.2 Functional class: “Active Star - Bus Guardian interface” (71)9.4.3 Functional class "Active Star - Voltage regulator control" (71)9.4.4 Functional class "Active Star - Internal voltage regulator" (71)9.5 Active Star timing characteristics (71)9.6 Active Star operation modes (72)9.6.1 AS_Sleep (72)9.6.3 AS_Standby (72)9.7 Active Star operation mode transitions (73)9.7.1 Active Star behavior after wake-up (74)9.8 Operating states of branches (74)9.8.1 Branch_Idle (74)9.8.2 Branch_Active (74)9.8.3 Branch_FailSilent (74)9.9 Branch operating state transitions (75)9.10 Collisions (76)9.10.1 Collisions on busses (76)9.10.2 Collision of bus activity and TxEN (76)9.11 Active Star behavior under fault conditions (78)9.12 Behavior of unconnected digital input signals (79)CHAPTER 10 BUS GUARDIAN (80)CHAPTER 11 GENERAL FEATURES FOR FLEXRAY PARTS (81)11.1 Objective (81)11.2 Input voltage thresholds for digital signals (81)11.3 Voltage limits for digital output signals (81)11.4 ESD protection on chip level (82)11.5 ESD protection on ECU level (82)11.6 Operating temperature (82)11.7 Serial peripheral interface (SPI) (83)11.7.1 Behavior of unconnected digital input pins (83)CHAPTER 12 SYSTEM TIMING CONSTRAINTS (84)12.1 Objective (84)12.2 Overview of timing parameters (84)12.3 Requirements of the decoding process according to [PS05] (84)12.4 FlexRay topologies (85)12.4.1 Signal chain (87)12.4.2 Example of a signal chain (88)12.5 Description of asymmetry portions (89)12.5.1 Communication Controller (89)12.5.2 Contribution of the Bus Driver (90)12.5.3 Interface between the Bus Driver and Communication Controller (91)12.5.4 Passive networks (91)12.5.5 ECU (92)12.6 Requirements for Communication Controller (92)12.7 Overview of the network integrity (93)Chapter 1Introduction1.1 ObjectiveThis specification describes the electrical physical layer for FlexRay communications systems.1.2 OverviewThe electrical physical layer for FlexRay is designed to network automotive electronic control units (ECUs). The medium that is used is dual wires. Signaling on the bus is accomplished by asserting a differential voltage between those wires. Topology variations range from linear passive busses up to active star topologies. Furthermore the physical layer optionally incorporates a so called bus guardian as an instance, which may watch over the bus access and has the power to disable the bus access of a node module to a channel in case of mismatches in the time schedule.This specification includes the definition of electrical characteristics of the transmission itself and also documentation of basic functionality for bus driver (BD), bus guardian (BG) and active star (AS) devices.1.3 References[PS05] FlexRay Communications System - Protocol Specification, v2.1 Revision A,FlexRay Consortium, December 2005[EMC05] FlexRay Communications System - Physical Layer EMC Measurement Specification, v2.1, FlexRay Consortium, December 2005[EPLAN06] FlexRay Communications System - Electrical Physical Layer Application Notes, v2.1 Revision B, FlexRay Consortium, November 20061.4 Terms and definitionsFlexRay specific terms and definitions are listed in [PS05].1.5 List of abbreviationsAS: active starBD: bus driverBG: bus guardianBSS: byte start sequenceCC: communication controllerECU: electronic control unitSPI: serial peripheral interfaceTSS: transmission start sequenceuV BAT: means a voltage applied at the V BAT pin relative to ground of the semiconductor device uV ECU: means a voltage applied at the battery connector of an ECU relative to groundX: don’t carex: placeholder for a figure [2, 3, 4, …]1.6 Notational conventions1.6.1 Parameter prefix conventions<variable> ::= <prefix_1> [<prefix_2>] Name <prefix_1> ::= a | c | v | g | p<prefix_2> ::= d | l | n | ua AuxiliaryParameter Auxiliary parameter used in the definition or derivation of other parameters or in the derivation of constraints.c Protocol Constant Values used to define characteristics or limits of the protocol.These values are fixed for the protocol and cannot be changed.v Node Variable Values which will be changed depending on time, events, etc.g Cluster Parameter Parameter that must have the same value in all nodes in a cluster.p Node Parameter Parameter that may have different values in different nodes in thecluster.- Prefix 1 can be omittedThis table is mirrored from [PS05], where the binding definitions are made!Table 1-1: Prefix 1.d Time Duration Value (variable, parameter, etc.) describing a time duration, thetime between two points in timel Length Physical length of e.g. a cablen Amount Number of e.g. stubsu Voltage Differential voltage between two conducting materials (e.g. copperwires)The prefixes “l”, “n” and “u” are defined binding here. For all other prefixes refer to [PS05]Table 1-2: Prefix 2.1.7 Important preliminary notes1.7.1 Bus speedThe FlexRay communication system currently specifies for a data rate of 10MBit/s only.Thus the nominal time of one bit (gdBit) is 100ns.1.7.2 Functional classesIn chapters 8, 9 and 10, the physical layer devices BD, AS and the electrical interfaces of the BG are specified. This specification comprises the minimum functional features in order to ensure interoperability of FlexRay devices and compliance to constraints given by the FlexRay protocol. In addition to this, some ‘functional classes’ are introduced. Each functional class combines a set of specified options, which have to coexist when implemented. These functional classes may be implemented in order to enhance the set of functional features of FlexRay physical layer devices and make them more valuable for building automotive ECUs.1.7.3 System and conformance testsTests for system behavior and FlexRay conformance are currently under development. Some basic information and prerequisites can be found in this specification. Potentially, this kind of content is to be moved when appropriate test specification documents are available.1.8 Revision history1.8.1 Changes applied to “E-PL spec v2.1 Revision A”- Changes as listed in “Errata Sheet to E-PL v2.1 Rev. A”- Complete reworked chapter 121.9 Open issues- Chapter 10 to be updated – according to most recent BG conceptsChapter 2Communication Channel Basics2.1 ObjectiveThe electrical physical layer provides among other things an implementation of a FlexRay communication channel. In this section an abstract definition of the physical properties of this communication channel is given. Any physical layer that behaves according to these basics provides a valid FlexRay communication channel.2.2 Propagation delayBinary data streams transmitted from node module M are received at node module N with the propagation delay dPropagationDelay M,N. The propagation delay shall be measured from the falling edge in the Byte Start Sequence (BSS; see [PS05]) in the transmit (TxD) signal of node module M to the corresponding falling edge in the receive (RxD) signal at node module N.Node module MM,NNode module NFigure 2-1: Propagation delay.The actual propagation delay that occurs between node module M to node module N depends mainly on the topology of the path. The following equation must be true in order to meet the constraints given by the FlexRay protocol:dPropagationDelay M,N≤cPropagationDelayMaxIn [PS05] the parameter cPropagationDelayMax is limited to 2500ns. Consequently it is:Name Description Min Max Unit dPropagationDelay M,N Propagation delay from node module M to2500 nsnode module NTable 2-1: Propagation delay.See also section “Application hint: Propagation delay” in [EPLAN06].2.2.1 Asymmetric delayAs defined above the propagation delay is defined with help of the first negative edge after the TSS in the binary data stream.Due to the limitations of the FlexRay decoder module the channel plus the sending and receiving bus driver shall not introduce a static asymmetric delay that exceeds a certain level.For further consideration see chapter 12.Node module MM,NNode module NdAsymmetricDelayM,NFigure 2-2: Asymmetric propagation delay.2.3 TruncationThe channel may truncate the TSS (see [PS05]). The interval by which the TSS is truncated from a transmitting node module M to a receiving node module N is denoted as dFrameTSSTruncation M,N. The effect of truncation of the TSS of a frame is shown in figure 2-3.Node module MNode module NNFigure 2-3: Frame TSS Truncation.The truncation time is calculated as the difference of the duration of TSS at sender and duration of TSS at receiver: dFrameTSSTruncation M,N = dTSS M - dTSS N .The value of dFrameTSSTruncation M,N needs to be less than the maximum configurable value of the protocol parameter gdTSSTransmitter. The effect of truncation sums up of different portions, which are contributed by active stars and the activity detection in the receiving BDs.Name Description Min Max UnitdFrameTSSTruncation M,N Truncation on path from node module M to100 1350 nsnode module NTable 2-2: TSS Truncation.The truncation depends on the number of active stars in the path from node M to node N. More detailed information is given in [EPLAN06]2.4 Symbol length changeQuite similar to the truncation of the TSS the length of symbols is changed while traveling through the physical layer. Besides the truncation at the beginning by the activity detection time a lengthening at the end by the idle detection time occurs. These effects are described in detail in section 8.9.4.Name Description Min Max Unit dSymbolLengthChange M,N Change of length of a symbol on path from-1200 900 nsnode module M to node module NA negative value means that the symbol is shortened, a positive value means the symbol is elongated.Table 2-3: Symbol length change.2.5 CollisionsFlexRay is designed to perform communication without collisions. I.e. the nodes do not arbitrate on the channel and collisions do not happen during normal operation. However, during the startup phase of the protocol, collisions on the channel may happen. The electrical physical layer does not provide a means to resolve those collisions.In case of collisions of communication elements on the bus (at least two nodes are transmitting simultaneously) it cannot be predicted what signal the nodes will receive. At least some activity (noise) on the channel will be detected.Data_0 Data_0Data_0Data_0 Data_1Data_0 or Data_1Data_1 Data_0Data_1 or Data_0Data_1 Data_1Data_1For definition of Data_0 and Data_1 see chapter 6.Table 2-4: Data signal collision on the bus.2.6 EMC jitter2.6.1 EMC jitter on signal edgesJitter on signal edges, i.e. those edges that are different from first transition from HIGH to LOW at start of frame and the last transition from LOW to HIGH at the end of a frame, shall be considered in the course of system evaluation.2.6.2 EMC jitter on TSS-truncationJitter on the TSS-truncation, which means jitter on the first falling edge in a frame, might shorten the TSS additionally to the truncation as described in section 2.3.2.6.3 EMC jitter on Symbol length changeJitter on the two edges of symbols might lead to deviations of the symbol length change as described in section 2.4.2.7 Wake-up patterns2.7.1 OverviewIndependent from the data rate wake-up patterns can be sent to remotely wake nodes that are in Sleep mode.2.7.2 Valid wake-up patternA valid remote wake-up event is the reception of at least two consecutive wake-up symbols via the bus.The wake-up detector for such events shall be active when the BD is in a low power mode (e.g. BD_Standby or BD_Sleep (if implemented)).For remote wake-up in FlexRay systems, a wake-up pattern is sent via the bus as described in [PS05]. The FlexRay wake-up pattern consists of several repetitions of FlexRay wake-up symbols. The wake-up symbol is defined as a phase of Data_0 followed by a phase of Idle.A remote wake-up event occurs from BD's perspective when any sequence of { Data_0, Idle, Data_0, Idle } that starts after Idle and has a timing according to figure 2-4 and table 2-5 is received. The definition of the pattern [PS05] guarantees at the receiver: dWU01 > 4µs, dWU Idle1 > 4µs, dWU02 > 4µs, dWU Idle2 > 4µs and dWU < 48µs.tFigure 2-4: Valid signal for wake-up pattern recognition at receiver.Name Description Min Max Unit dWU0Detect Acceptance timeout for detection of a1 4 µsData_0 phase in wake-up patterndWU IdleDetect Acceptance timeout for detection of a Idle1 4 µsphase in wake-up patterndWU Timeout Acceptance timeout for wake-up pattern48 140 µsrecognitionTable 2-5: Wake-up pattern detection timing at receiver.Short discontinuities (e.g. due to external disturbances like injection of RF fields) in Data_0 or Idle phases shall not harm the recognition of a remote wake-up, therefore uBus shall be evaluated after integrative filtering in order to achieve a sufficient robustness against such disturbances. The acceptable discontinuities depend on implementation and need to be specified on BD product level.Moreover, the wake-up detector is allowed to judge Data_1 as Idle and the behavior needs to be specified on BD product level. Thus, the BD might also wake-up upon receiving other patterns, e.g. FlexRay frames.Mind that idle and activity detection is the process how the wake-up pattern is received, see section 8.9.2 Receiver behavior and especially table 8-16.2.7.3 Non valid wake-up patternsThe BD shall not wake-up, whena) the first idle phase is shorter than 1µs, while the Data_0 phases are 6µsb) the second Data_0 phase is shorter than 1µs, while the first Data_0 phaseand the first idle phase are 6µsc) the first idle phase is longer than 140µs, while the Data_0 phases are 6µsChapter 3Principle of FlexRay Networking3.1 ObjectiveThis chapter shows the basic operation principle of FlexRay networks.3.2 Interconnection of nodesThe FlexRay electrical physical layer provides a differential voltage link (= bus) between a transmitting and oneor more receiving communication modules. The differential voltage is measured between two signal lines, denoted BP (Bus Plus) and BM (Bus Minus). The fundamental mechanism of the bidirectional differential voltage link is shown below. The bidirectional link between any two nodes modules requires a transmitter and receiver circuit which are integrated in so called bus drivers.Bus driver Bus driverFigure 3-1: Principle of a differential voltage link.This structure can be extended with further bus drivers that are connected to the differential voltage link as depicted in the following figure. The differential voltage link is implemented by a dual wire cable. With each communication module one bus driver is added to the system.Bus driver Bus driverFigure 3-2: Principle of a linear passive bus.Limitations to the number of bus drivers (ECUs) and cable extents are documented in chapter 5. Furthermore, the bus can also comprise active stars, which are working in principle as bidirectional repeaters. The functionality of active stars is specified in chapter 9.Bus driverFigure 3-3: Principle of an active star network.Chapter 4Network Components4.1 ObjectiveThis chapter introduces some basic network components that are used to build up FlexRay networks.4.2 CablesThe objective of this subsection is to specify the required cable characteristics, but not to define a selection of cable types. The medium in use for FlexRay busses may be unshielded as well as shielded cables, as long as they provide the following characteristics:Name Description Min Max UnitZ0Differential mode impedance @ 10 MHz (*) 80 110 ΩT’0Specific line delay 10 ns / mα5MHz Cable attenuation @ 5 MHz (sine wave) 82 dB / km(*) see [EPLAN06]Table 4-1: Cable characteristics.4.3 ConnectorsThis specification does not prescribe certain connectors for FlexRay systems. However, any electrical connector used in FlexRay busses shall meet the following constraints:Name Description Min Max UnitR DCContact Contact resistance (including crimps) 50 mΩZ Connector Impedance of connector 70 200 Ωl Coupling Length coupling connection (*) 150 mmdContactInterruption (**)Contact resistance R> 1Ω100 nsDCContact(*) this parameter defines the length of the connectors including the termination areas of the cables(**) this requirement is to be generally understood as an quality issue and has no direct link with the timing performance of FlexRay.Table 4-2: Connector parameters.See further recommendations about connectors in [EPLAN06].4.4 Cable termination4.4.1 Terminated cable endThe simplest way to terminate the cable at an ECU consists of a single termination resistor between the bus wires BP and BM. Other termination possibilities are shown in [EPLAN06].Figure 4-1: Terminated cable end.In following sections, ECUs that have this kind of termination are symbolized with the following icon.Figure 4-2: Symbol: Terminated cable end.4.4.2 Un-terminated cable endAt an un-terminated cable end, no resistive element is connected between the bus wires.Figure 4-3: Un-terminated cable end.In following sections, ECUs that have this kind of termination are symbolized with the following icon.Figure 4-4: Symbol: Un-terminated cable end.4.5 Termination conceptThis specification does not prescribe a certain termination concept. Application specific solutions have to be found. Find some more general recommendations about termination in [EPLAN06].4.6 Common mode chokesThis specification does not prescribe a certain common mode choke for FlexRay systems. However, anycommon mode choke used in FlexRay systems shall meet the following constraints over the entire temperature range as specified in section 11.5:Name DescriptionMinMaxUnit R CMCResistance (per line)2 ΩTable 4-3: Common mode choke parameters.See further recommendations about common mode chokes in [EPLAN06].4.7 DC bus loadThe DC load a BD sees between the bus wires is R DCLoad . A network equivalent DC circuit is as follows:R DCLoad Figure 4-5: DC bus load.The schematic does not include parasitic resistances from common mode chokes (R CMC ), connectors (R Connector ) and the series resistance of the wiring (R Wire ), since those shall be neglected in the following calculation: The formula to calculate the overall DC bus load is:R DCLoad = (Σm (R Tm )-1)-1Equation 4-1: DC bus load.Name Description Min Max Unit R DCLoad DC bus load 40 55 ΩTable 4-4: DC bus load limitation.Mind that the termination resistance R Tm is usually a termination resistor in parallel to the BD’s receiver common mode input resistance (see section 8.9.1). The termination resistor might also be applied outside the ECU, e.g. at a network splice. In case of an un-terminated cable end according to section 4.3.2. the resistance R Tm represents only the BD’s receiver common mode input resistance.Some exemplary termination concepts for different bus structures are described in [EPLAN06]. All termination concepts have to consider the DC bus load limitation as defined here.Chapter 5Network Topology5.1 ObjectiveThis chapter introduces possible bus structures, their names and parameters. The layout of busses has to follow the constraints that are explained in this chapter. Application examples and recommendations are given in [EPLAN06].Dual channel applications, a main feature of FlexRay, are discussed at the end of this chapter.All FlexRay topologies are 'linear', which means that they are free from rings or closed loops respectively.A termination concept has to be found for each topology implementation individually. General hints can be found in [EPLAN06]. Whether a topology/termination combination composes a valid FlexRay network has to be judged according the signal integrity requirements as given in chapter 7.5.2 Point-to-point connectionThe point-to-point configuration is shown in figure 5-1. It represents the simplest bus and can be regarded as the basic element for the construction of more complex busses. For simplicity, the two-wire bus is shown as one thick line in the figures of this document.Figure 5-1: Point to point connection.5.3 Passive starFor connecting more than two ECUs a passive star structure can be used, which is a special case of a linear passive bus that is described in the following section. At a passive star all ECUs are connected to a single splice. The principle of a passive star network is shown in figure 5-2.Figure 5-2: Example of a passive star.Name Description Min Max Unit nSplice Number of splices (*) 1 1(*) if nSplice is 0, then refer to section 5.1, if nSplice is greater than 1, then refer to section 5.4Table 5-1: Parameters of a passive star.Practical limitations for nStub and lStub N depend on each other and depend also on other factors like cable type and termination concept; i.e. a passive star with nStub = 22 and each lStub = 12m for each stub is likely not to be operable.Examples of practical values are given in [EPLAN06], where also consideration about EMC robustness can be found in a separate section.。
FlexRay通信系统协议规范V2.1修订本A-第一章 简介
Chapter 1IntroductionFlexRay通信协议1.1ScopeThe FlexRay communication protocol described in this document is specified for a dependable automotive network. Some of the basic characteristics of the FlexRay protocol are synchronous and asynchronous frame transfer, guaranteed frame latency and jitter during synchronous transfer, prioritization of frames during asynchronous transfer, multi-master clock synchronization1, error detection and signaling, error containment on the physical layer through the use of a bus guardian device, and scalable fault tolerance2.1.2References1.2.1FlexRay consortium documents[EPL05]FlexRay Communications System - Electrical Physical Layer Specification, v2.1 Revision A, FlexRay Consortium, December 2005.[EPLAN05]FlexRay Communications System - Electrical Physical Layer Application Notes, v2.1 Revision A, FlexRay Consortium, December 2005.[DLLCT05]FlexRay Communications System - Data Link Layer Conformance Test Specification, v1.0, FlexRay Consortium, December 2005.[Req05]FlexRay Requirements Specification, v2.100, FlexRay Consortium, December 2005.[Mül01] B. Müller, “On FlexRay Clock Synchronisation”, Robert Bosch Corporation, 2001 (internal document).[Ung02]J. Ungermann, “Performance of the FlexRay Clock Synchronisation”, Philips GmbH, 2002 (internal document).1.2.2Non-consortium documents[Cas93]G. Castagnoli, S. Bräuer, and M. Herrmann, "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Transactions on Communications, vol. 41, pp. 883-892, June1993.[Koo02]P. Koopman, "32-bit Cyclic Redundancy Codes for Internet Applications", Proceedings of the International Conference on Dependable Systems and Networks (DSN 2002), Washington DC,pp. 459-468. June 2002.[Pet72]W. W. Peterson and E. J. Weldon, Jr., Error-Correcting Codes, 2nd ed., Cambridge MA: M.I.T.Press, 1972.[Rau02]M. Rausch, "Optimierte Mechanismen und Algorithmen in FlexRay", Elektronik Automotive, pp.36-40, December 2002.1 Multi-master clock synchronization refers to a synchronization that is based on the clocks of several (three or more)synchronization masters or sync nodes.2 Scalable fault tolerance refers to the ability of the FlexRay protocol to operate in configurations that provide various degrees offault tolerance (for example, single or dual channel clusters, clusters with or without bus guardians, clusters with many or few sync nodes, etc.).[Wad01]T. Wadayama, “Average Distortion of Some Cyclic Codes”, web site available at: http://www-tkm.ics.nitech.ac.jp/~wadayama/distortion.html[Wel88]J. L. Welch and N. A. Lynch, "A New Fault-Tolerant Algorithm for Clock Synchronization", Infor-mation and Computation, vol. 77, no. 1, pp. 1-36, April 1988.[Z100]ITU-T Recommendation Z.100 (03/93), Programming Languages - CCITT Specification and Description Language (SDL), International Telecommunication Union, Geneva, 1993.1.3Revision history Vers.Date Changes2.030-Jun-2004First public release.2.1May2005The SDL processes in Chapter 3 (Coding) have been restructured.Appendix B has been almost completely rewritten.BG references and BGSM chapter (former chapter 10) have been removed. Specific significant changes to CHI:•channel dependency of pMicroInitialOffset[Ch] and pMacroInitialOffset[CH] has been introduced in 9.3.1.1.2•pDecodingCorrection has been added in CHI in 9.3.1.1.2•error indicator in CHI has been added in 9.3.1.3.3•vSyncFramesEven/Odd/A/B have been removed in 9.3.1.3.4•indicators for zLastDynTxSlot have been added in 9.3.1.3.9The status variable vPOC!StartupState has been introduced in the CHI in 9.3.1.3.1. The variable is reset in Figure 2-6 to Figure 2-8 and set in Figure 7-11 to Figure 7-19.Figure 6-10 was split into two figures (now Figure 6-10 and Figure 6-11).The following figures have modifications that changed the operation of the protocol: Figure 2-8, Figure 5-21, Figure 6-8, Figure 6-16 (former 6-15), Figure 6-17 (former 6-16), Figure 7-3, Figure 7-11, Figure 7-19, Figure 8-4, Figure 8-8, Figure 8-10, Fig-ure 8-11, Figure 8-15, and Figure 8-17. The text related to these figures has also been updated.Numerous non-technical corrections and clarifications were made throughout the document.2.1 Rev A Dec2005Use of SDL priority input to resolve certain race conditions (see section 1.7.3.4 andFigure 5-21 and Figure 8-8)Re-arrangement of SDL to eliminate the use of SDL "enabling condition" structure(Figure 6-10, Figure 6-11, Figure 7-3, Figure 7-4, and Figure 7-5)Update of zLastDynTxSlot (Figure 5-13, Figure 5-20, Figure 5-21, and Figure 5-22)Re-arrangement of channel idle detection (Figure 2-9, Figure 3-15, Figure 3-16, Fig-ure 3-17, Figure 3-18, Figure 3-25, Figure 3-36, Figure 3-37, Figure 7-3, and Figure7-11)Introduction of new "a" class of variables (see section 1.6.1)Replacement of the bit counter by a timer in Figure 3-23Explicit export of all CHI variablesExtension of the color coding to SDL signals (see section 1.6.2)Rework of Appendix BNumerous non-technical corrections and clarifications were made throughout thedocument.Table 1-1: Revision history1.4Terms and definitionsapplication datadata produced and/or used by application tasks. In the automotive context the term 'signal' is often used for application data exchanged among tasks.busa communication system topology in which nodes are directly connected to a single, commoncommunication media (as opposed to connection through stars, gateways, etc.). The term bus is also used to refer to the media itself.bus driveran electronic component consisting of a transmitter and a receiver that connects a communication controller to one communication channel.bus guardianan electronic component that protects a channel from interference caused by communication that is not temporally aligned with the cluster's communication schedule by limiting the times that acommunication controller can transmit to those times allowed by the schedule.channelsee communication channel.channel idlethe condition of medium idle as perceived by each individual node in the network.cliqueset of communication controllers having the same view of certain systems properties, e.g., the global time value or the activity state of communication controllers.clustera communication system of multiple nodes connected via at least one communication channel directly(bus topology) or by star couplers (star topology).coldstart nodea node capable of initiating the communication startup procedure on the cluster by sending startupframes.communication channelthe inter-node connection through which signals are conveyed for the purpose of communication. The communication channel abstracts both the network topology, i.e., bus or star, as well as the physical transmission medium, i.e. electrical or optical.communication controller (CC)an electronic component in a node that is responsible for implementing the protocol aspects of the FlexRay communications system.communication cycleone complete instance of the communication structure that is periodically repeated to comprise the media access method of the FlexRay system. The communication cycle consists of a static segment, an optional dynamic segment, an optional symbol window, and a network idle time.communication slotan interval of time during which access to a communication channel is granted exclusively to a specific node for the transmission of a frame with a frame ID corresponding to the slot. FlexRay distinguishes between static communication slots and dynamic communication slots.cycle counterthe number of the current communication cycle.cycle timethe time within the current communication cycle, expressed in units of macroticks. Cycle time is reset to zero at the beginning of each communication cycle.dynamic segmentportion of the communication cycle where the media access is controlled via a mini-slotting scheme, also known as Flexible Time Division Multiple Access (FTDMA). During this segment access to the media is dynamically granted on a priority basis to nodes with data to transmit.dynamic communication slotan interval of time within the dynamic segment of the communication cycle consisting of one or more minislots during which access to a communication channel is granted exclusively to a specific node for transmission of a frame with a frame ID corresponding to the slot. In contrast to a static communication slot, the duration of a dynamic communication slot may vary depending on the length of the frame. If no frame is sent, the duration of a dynamic communication slot equals that of one minislot.framea structure used by the communication system to exchange information within the system. A frameconsists of a header segment, a payload segment and a trailer segment. The payload segment is used to convey application data.frame identifierthe frame identifier defines the slot position in the static segment and defines the priority in thedynamic segment. A lower identifier indicates a higher priority.gatewaya node that is connected to two or more independent communication networks that allows informationto flow between the networks.global timecombination of cycle counter and cycle time.Hamming distancethe minimum distance (i.e., the number of bits which differ) between any two valid code words in a binary code.the part of an ECU where the application software is executed, separated by the CHI from the FlexRay protocol engine.macrotickan interval of time derived from the cluster-wide clock synchronization algorithm. A macrotick consists of an integral number of microticks. The actual number of microticks in a given macrotick is adjusted by the clock synchronization algorithm. The macrotick represents the smallest granularity unit of the global time.medium idlethe condition of the physical transmission medium when no node is actively transmitting on thephysical transmission medium.microtickan interval of time derived directly from the CC's oscillator (possibly through the use of a prescaler).The microtick is not affected by the clock synchronization mechanisms, and is thus a node-local concept. Different nodes can have microticks of different duration.minislotan interval of time within the dynamic segment of the communication cycle that is of constant duration (in terms of macroticks) and that is used by the synchronized FTDMA media access scheme to manage media arbitration.networkthe combination of the communication channels that connect the nodes of a cluster.network topologythe arrangement of the connections between the nodes. FlexRay supports bus, star, cascaded star, and hybrid network topologies.nodea logical entity connected to the network that is capable of sending and/or receiving frames.null framea frame that contains no usable data in the payload segment. A null frame is indicated by a bit in theheader segment, and all data bytes in the payload segment are set to zero.physical communication linkan inter-node connection through which signals are conveyed for the purpose of communication. All nodes connected to a given physical communication link share the same electrical or optical signals(i.e., they are not connected through repeaters, stars, gateways, etc.). Examples of a physicalcommunication link include a bus network or a point-to-point connection between a node and a star. A communication channel may be constructed by combining one or more physical communication links together using stars.precisionthe worst-case deviation between the corresponding macroticks of any two synchronized nodes in the cluster.see communication slot.stara device that allows information to be transferred from one physical communication link to one or moreother physical communication links. A star duplicates information present on one of its links to the other links connected to the star. A star can be either passive or active.startup frameFlexRay frame whose header segment contains an indicator that integrating nodes may use time-related information from this frame for initialization during the startup process. Startup frames are always also sync frames.startup slotcommunication slot in which a startup frame is sent.static communication slotan interval of time within the static segment of the communication cycle that is constant in terms of macroticks and during which access to a communication channel is granted exclusively to a specific node for transmission of a frame with a frame ID corresponding to the slot. Unlike a dynamiccommunication slot, each static communication slot contains a constant number of macroticksregardless of whether or not a frame is sent in the slot.static segmentportion of the communication cycle where the media access is controlled via a static Time Division Multiple Access (TDMA) scheme. During this segment access to the media is determined solely by the progression of time.sync frameFlexRay frame whose header segment contains an indicator that the deviation measured between the frame's arrival time and its expected arrival time should be used by the clock synchronizationalgorithm.sync slotcommunication slot in which a sync frame is sent.1.5Acronyms and abbreviationsµT MicrotickAP Action PointBD Bus DriverBIST Built-In Self TestBITSTRB Bit Strobing ProcessBSS Byte Start SequenceCAS Collision Avoidance SymbolCC Communication ControllerCE Communication ElementCHI Controller Host InterfaceCHIRP Channel Idle Recognition PointCODEC Coding and Decoding ProcessCRC Cyclic Redundancy CodeCSP Clock Synchronization ProcessCSS Clock Synchronization Startup ProcessDTS Dynamic Trailing SequenceECU Electronic Control Unit, same as nodeEMC Electromagnetic CompatibilityERRN Error Not signalFES Frame End SequenceFSP Frame and Symbol ProcessingFSS Frame Start SequenceFTDMA Flexible Time Division Multiple Access (media access method) FTM Fault Tolerant MidpointID IdentifierINH Inhibit signalMAC Media Access Control ProcessMT MacrotickMTG Macrotick Generation ProcessMTS Media Access Test SymbolNIT Network Idle TimeNM Network ManagementPOC Protocol Operation ControlRxD Receive data signal from bus driverRxEN Receive data enable signal from bus driverSDL Specification and Description LanguageSPI Serial Peripheral InterfaceSTBN Standby Not signalSuF Startup FrameSW Symbol WindowSyF Sync FrameTDMA Time Division Multiple Access (media access method)TRP Time Reference PointTSS Transmission Start SequenceTxDTransmit Data signal from CC TxENTransmit Data Enable Not signal from CC WUPWakeup Pattern WUSWakeup Symbol WUPDEC Wakeup Pattern Decoding Process 1.6Notational conventions 1.6.1Parameter prefix conventions<variable> ::= <prefix_1> [<prefix_2>] Name<prefix_1>::= a | c | v | g | p | z<prefix_2>::= d | s1.6.2Color codingThroughout the text several types of items are highlighted through the use of an italicized color font.NamingConventionInformation Type Description aAuxiliary Parameter Auxiliary parameter used in the definition or derivation of other parameters or in the derivation of constraints.cProtocol Constant Values used to define characteristics or limits of the protocol. These values are fixed for the protocol and cannot be changed.vNode Variable Values that vary depending on time, events, etc.g ClusterParameterParameter that must have the same value in all nodes in a cluster, is initialized in the POC:default config state, and can only be changed while in the POC:config state.p Node Para-meterParameter that may have different values in different nodes in the cluster, is initialized in the POC:default config state, and can only be changed while in the POC:config state.zLocal SDLProcessVariable Variables used in SDL processes to facilitate accurate representa-tion of the necessary algorithmic behavior. Their scope is local to the process where they are declared and their existence in any particu-lar implementation is not mandated by the protocol.Table 1-2: Parameter prefix 1.NamingConventionInformation Type Description dTime Duration Value (variable, parameter, etc.) describing a time duration, the time between two points in time s Set Set of values (variables, parameters, etc.)Table 1-3: Parameter prefix 2.Parameters, constants and variables are highlighted with blue italics. An example is the parameter gdStat-icSlot. This convention is not used within SDL diagrams, as it is assumed that such information is obvious. The meaning of the prefixes of parameters, constants, and variables is described in section 1.6.1.SDL states are highlighted in green italics. An example is the SDL state POC:normal active. This highlighting convention is not used within SDL diagrams. Further notational conventions related to SDL states are described in section 1.7.2.SDL signals are highlighted in brown italics. An example is the SDL signal CHIRP on A. Again, this convention is not used within the SDL diagrams themselves as the fact that an item is an input or output signal should be obvious.Terms which are important for FlexRay are highlighted in red italics at their first (or defining) instance in the text. An example is the term communication element.1.7SDL conventions1.7.1GeneralThe FlexRay protocol mechanisms described in this specification are presented using a graphical method loosely based on the Specification and Description Language (SDL) technique described in [Z100]. The intent of this description is not to provide a complete executable SDL model of the protocol mechanisms, but rather to present a reasonably unambiguous description of the mechanisms and their interactions. This description is intended to be read by humans, not by machines, and in many cases the description is optimized for understandability rather than exact syntactic correctness.The SDL descriptions in this specification are behavioral descriptions, not requirements on a particular method of implementation. In many cases the method of description was chosen for ease of understanding rather than efficiency of implementation. An actual implementation should have the same behavior as the SDL description, but it need not have the same underlying structure or mechanisms.Several SDL diagrams have textual descriptions intended to assist the reader in understanding the behavior depicted in the SDL diagrams. Some technical details are intentionally omitted from these explanations. Unless specifically mentioned, the behavior depicted in the SDL diagrams takes precedence over any textual description.The SDL in this specification describes a dual channel FlexRay device. As a result, there are a number of mechanisms that exhibit behavior that is specific to a given channel. It is also possible to have FlexRay devices that only support a single channel, or that may be configured to support a single channel. Imple-menters of single channel devices will have to make appropriate adjustments to eliminate the effects of mechanisms and signals that do not exist in devices operating in a single channel mode.1.7.2SDL Notational ConventionsStates that exist within the various SDL processes are shown with the state symbol shaded in light gray. These states are named with all lowercase letters. Acronyms or proper nouns that appear in a state name are capitalized as appropriate. Examples include the states "wait for sync frame" and "wait for CE start". SDL states that are referenced in the text are prefixed with an identification of the SDL process in which they are located (for example, the state POC:normal active refers to the "normal active" state in the POC process). This convention is not used within the SDL diagrams themselves, as the process information should be obvious.The definitions of an SDL process are often spread over several different figures. The caption of each figure that contains SDL definitions indicates to which SDL process the figure belongs.1.7.3SDL ExtensionsThe SDL descriptions in this specification contain some constructs that are not a part of normal SDL. Also, some mechanisms described with constructs that are part of normal SDL expect that these constructs behave somewhat differently than is described in [Z100]. This section documents significant deviations from "standard" SDL.1.7.3.1Microtick, macrotick and sample tick timersThe representation of time in the FlexRay protocol is based on a hierarchy that includes microticks and macroticks (see Chapter 8 for details). Several SDL mechanisms need timers that measure a certain number of microticks or macroticks. This specification makes use of an extension of the SDL 'timer' construct to accomplish this.An SDL definition of the formµT timerdefines a timer that counts in terms of microticks. This behavior would be similar to that of an SDL system whose underlying time unit is the microtick.An SDL definition of the formMT timerdefines a timer that counts in terms of macroticks. Note that a macrotick timer uses the corrected macroticks generated by the macrotick generation process. Since the duration of a macrotick can vary, the duration of these timers can also vary, but the timers themselves remain synchronized to the macrotick-level timebase of the protocol.In all other respects both of these constructs behave in the same manner as normal SDL timers.In addition to the above, several SDL mechanisms used in the description of encoding make use of a timer that measures a certain number of ticks of the bit sample clock. An SDL definition of the form ST timerdefines a timer that counts in terms of ticks of the bit sample clock (i.e., sample ticks). This behavior would be similar to that of an SDL system whose underlying time unit is the sample tick. In all other respects this construct behaves in the same manner as a normal SDL timer.There is a defined relationship between the "ticks" of the microtick timebase and the sample ticks of bit sampling. Specifically, a microtick consists of an integral number, pSamplesPerMicrotick, of sample ticks. As a result, there is a fixed phase relationship between the microtick timebase and the ticks of the sample clock.The time expression of a timer is defined in [Z100] by:<Time expression> = now + <Duration constant expression>In this specification the time expression is used in the following simplified way:<Time expression> = <Duration constant expression>31.7.3.2Microtick behavior of the 'now' - expressionThe behavioral descriptions of various aspects of the FlexRay system require the ability to take "time-stamps" at the occurrence of certain events. The granularity of these timestamps is one microtick, and the timestamps taken by different processes need to be taken against the same underlying timebase. This specification makes use of an extension of the SDL concept of time to facilitate these timestamps.3 If the duration time expression is zero or negative then the timer is started and expires immediately.This specification assumes the existence of an underlying microtick timebase. This timebase, which is available to all processes, contains a microtick counter that is started at zero at some arbitrary epoch assumed to occur before system startup. As time progresses, this timebase increments the microtick counter without bound4. Explicit use of the SDL 'now' construct returns the value of this microtick counter. The difference between the timestamps of two events represents the number of microticks that have occurred between the events.1.7.3.3Channel-specific process replicationThe FlexRay protocol described in this specification is a dual channel protocol. Several of the mechanisms in the protocol are replicated on a channel basis, i.e., essentially identical mechanisms are executed, one for channel A and one for channel B. This specification only provides SDL descriptions for the channel-specific processes on channel A - it is assumed that whenever a channel-specific process is defined for channel A there is another, essentially identical, process defined for channel B, even though this process is not explicitly described in the specification.Channel-specific processes have names that include the identity of their channel (for example, "Clock synchronization startup process on channel A [CSS_A]"). In addition, signals that leave a channel-specific process have signal names that include the identity of their channel (for example, the signal integration aborted on A).1.7.3.4Handling of Priority Input SymbolsThe SDL language contains certain ambiguities regarding the order of execution of processes if multiple processes have input queues that are not empty. For example, the usage of timers and clock oscillator inputs causes multiple processes to be eligible for execution at the beginning of clock edges. Generally, this poses no problem for the FlexRay specification, but for certain special cases it is not possible to specify the required behavior in an unambiguous way without additional language constructs.To resolve these situations the SDL priority input symbol is used, but with a slightly extended meaning. Whenever an input priority symbol is used, no other exit path of this state may be taken unless it is impossible that the priority input could be triggered on the current microtick clock edge. Effectively, the execution of the process in question is stalled until all other process have executed. Should multiple processes be in a state where they are sensitive to a priority input, all are executed last and in random order. The message queue is handled in the standard way, i.e. the signal triggering the priority input is removed from the queue while any signals placed before or after are preserved for the succeeding state.1.8Network topology considerationsThe following sections provide a brief overview of the possible topologies for a FlexRay system. This material is for reference only - detailed requirements and specifications may be found in [EPL05].There are several ways to design a FlexRay cluster. It can be configured as a single-channel or dual-channel bus network, a single-channel or dual-channel star network, or in various hybrid combinations of bus and star topologies.A FlexRay cluster consists of at most two channels, identified as Channel A and Channel B. Each node in the cluster may be connected to either or both of the channels. In the fault free condition, all nodes connected to Channel A are able to communicate with all other nodes connected to Channel A, and all nodes connected to ChannelB are able to communicate with all other nodes connected to Channel B. If a node needs to be connected to more than one cluster then the connection to each cluster must be made through a different communication controller5.4 This is in contrast to the vMicrotick variable, which is reset to zero at the beginning of each cycle.5 For example, it is not allowed for a communication controller to connect to Channel A of one cluster and Channel B of anothercluster.。
flexray在汽车传感器总线上的研究与应用
flexray在汽车传感器总线上的研究与应用随着汽车技术的进步和发展，自动驾驶和智能汽车等新兴技术逐渐走入人们的生活，对汽车传感器总线的要求也越来越高。
传感器总线在汽车系统中扮演着重要的角色，能够实现不同传感器之间的快速和可靠的通信，从而提高汽车的安全性和性能。
在汽车传感器总线技术中，FlexRay（灵活射频总线）是一种广泛使用的标准。
FlexRay总线是一种高速、高带宽、实时性强的总线协议，能够满足自动驾驶等高要求的应用场景。
下面将从研究与应用两个方面来介绍FlexRay在汽车传感器总线上的相关情况。
一、研究方面：1. FlexRay总线协议研究：对FlexRay总线协议的研究是了解FlexRay的基础。
研究人员可以通过深入了解FlexRay总线的工作原理、报文结构、网络通信等方面，来对FlexRay进行分析和优化。
2.性能优化：在实际应用中，可能会遇到FlexRay传输速率不足、网络容量不足等问题。
研究人员可以通过优化FlexRay总线的工作参数、改进FlexRay网络拓扑结构等方面来提高其性能。
3.安全性研究：安全性是汽车传感器总线的重要指标之一。
研究人员可以通过对FlexRay网络的安全性分析，发现潜在的攻击方法和防范措施，提高汽车传感器总线的安全性。
4.网络管理与诊断：在实际应用中，需要对FlexRay网络进行管理和诊断，确保其正常工作。
研究人员可以研究FlexRay总线的网络管理与诊断方法，提供对FlexRay网络的监控和故障诊断能力。
二、应用方面：1. ADAS（高级驾驶辅助系统）：FlexRay总线可以实现不同传感器之间的快速和可靠通信，从而支持ADAS系统的实时性要求。
通过FlexRay总线，可以将传感器的数据及时传输给控制单元，从而实现智能的驾驶辅助功能。
2.自动驾驶：自动驾驶是当今汽车行业的热门话题，而实现自动驾驶需要高度可靠的传感器总线。
FlexRay总线可以满足自动驾驶系统对高速、高带宽、实时性强的要求，从而支持自动驾驶系统的实现。
《汽车网络控制系统检修》模块五 FlexRay 总线系统
FlexRay总线系统的结构组成有哪些？数据的通信原理是怎样的？目前 的应用状况如何？ 本模块将着重介绍这些问题。
七、FlexRay 数据帧的组成
FlexRay的一个数据帧由帧头、有效数据段和帧尾三部分组成。如下图所示。
1．帧头
帧头共由5个字节(40bit)组成，包括以下几位： ① 保留位（Reserved bit，1bit)：为日后的扩展做准备。 ② 负载段前言指示(Payload preamble indicator，1bit)：指明帧的负载段的矢 量信息。 ③ 空帧指示(Null frame indicator，1bit)：指明负载段的数据帧是否为零0 ④ 同步帧指示(Sync frame indicator，1bit)：指明这是一个同步帧。 ⑤ 起始帧指示(Startup frame indicator，1bit)：指明发送帧的节点是否为起始 帧。 ⑥ 帧ID(Frame ID，11bit)：指明在系统设计过程中分配到每个节点的ID(有效范 围为1-2047)。 ⑦ 有效数据长度(Payload length，7bit)：指示有效数据的长度，以字为单位。 ⑧ 头部CRC(Header CRC，11bit)：表明同步帧指示器和起始帧指示器的CRC计 算值，以及由主机计算的帧ID和帧长度。 ⑨ 周期(Cycle count，6bit)：指明在帧传输时间内传输帧的节点的周期计数。
二、FlexRay总线在宝马7系中的应用
1．总线应用概述
宝马7系F01/F02车型 FlexRay总线系统的拓扑结构 (见 右图）。
ecu协议
ecu协议ECU协议，即发动机控制单元协议（Engine Control Unit Protocol），是指用于发动机控制系统的一套标准化通信协议。
ECU协议定义了发动机控制单元与其他车辆系统之间的通信方式和规范，确保各个系统之间的信息交换和协同工作。
ECU协议包括物理层、数据链路层和应用层三个部分。
物理层用于指定通信介质和物理连接方式，如CAN总线、LIN总线等。
数据链路层用于确保数据的可靠传输和错误检测，如数据帧格式和校验机制等。
应用层则定义了各种命令和消息的格式和语义，如启动命令、故障码读取等。
ECU协议的主要功能包括：发动机参数读取、发动机控制、故障诊断和信息交互等。
发动机参数读取可以获取各种传感器和执行器的数据，如转速、温度、氧气含量等。
发动机控制则是根据输入的参数和逻辑进行计算，并控制相关执行器的工作，如喷油器、点火系统等。
故障诊断可以通过读取故障码和数据流来判断发动机的工作状态和故障原因，并采取相应措施进行修复。
信息交互则是发动机控制单元与其他车辆系统之间的通信和协同工作，如与制动系统、转向系统等进行联动控制。
ECU协议的设计和实现需要考虑以下几个方面的因素。
首先，协议的可扩展性和兼容性是非常重要的，要能够适应不同型号和品牌的车辆。
其次，通信的实时性和稳定性是保证车辆正常工作的关键，要能够快速、可靠地传输数据和指令。
另外，安全性也是十分重要的，要采取相应的保护机制，防止恶意攻击和数据泄露。
近年来，随着汽车电子技术的不断发展，ECU协议也在不断演进和完善。
例如，传统的有线通信逐渐向无线通信转变，以提高通信的灵活性和可扩展性。
同时，为了满足更复杂的车辆控制需求，ECU协议也在不断增加新的功能和特性，如车载网络的支持、自动驾驶的集成等。
总之，ECU协议是发动机控制单元与其他车辆系统之间通信的重要桥梁，它定义了通信的方式和规范，保证车辆各个系统的协同工作和信息交互。
随着汽车电子技术的发展，ECU协议也在不断演进和完善，以满足更复杂的车辆控制需求。
汽车ECU协议标准
汽车ECU通信新平台--FlexRay（）协议标准一、车载网络概述化程度与日俱增，应用在车上的ECU模块数量也随之增加，从而使线束也增加。
汽车电子系统的成本已经超过总成本的20%，并且还将继续增加。
由于汽车生产商对制造成本的严格控制，加上对车身质量的控制，减少线束已经成为一个必须要解决的问题。
另一方面，以网络通讯为基础的线控技术（X-by-wire）将在汽车上普遍应用。
因此，车载网络时代终将来临。
车载网络种类有很多种，应用较多的有LIN，CAN、FlexRay、TIP/C、SAEJ1850、TFCAN、ASRB、MOST等。
美国汽车工程师协会（SAE）根据速率将汽车网络划分为A、B、C3类。
A类总线标准包括TTP/A（Time Triggered Protocol/A）和LIN（Local Interconnect Net-work），其传输速率较低。
①TTP/A协议最初由维也纳工业大学制定，为时刻触发类型的网络协议，要紧应用于集成了智能变换器的实时现场总线。
②LIN是在1999年由欧洲汽车制造商Audi、BMW、DaimlerChrysler、Volvo、Volkswagen、VCT公司和Motorola公司组成的LIN协会一起尽力下推出的用于汽车散布式电控系统的开放式的低本钱串行通信标准，从2003年开始取得利用。
B类标准主要包括J1850、VAN，低速CAN。
①1994年SAE正式将J1850作为B类网络标准协议。
最先，SAEJ1850被用在美国Ford，GM和Chrysler公司的汽车中。
此刻，J1850协议作为诊断和数据共享被普遍应用在汽车产品中。
②VAN标准是ISO1994年6月推出的，它基于ISO11519-3，要紧为法国汽车公司所用。
但目前就动力与传动系统而言，乃至在法国也集中应用CAN总线。
③CAN是德国BOSCH公司从20世纪80年代初为解决现代汽车中众多的操纵与测试仪器之间的数据互换而开发的一种串行数据通信协议。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
汽车ECU通讯新平台--FlexRay（V2.1）协议规范一、车载网络概述汽车电子化程度与日俱增，应用在车上的ECU模块数量也随之增加，从而使线束也增加。
汽车电子系统的成本已经超过总成本的20%，并且还将继续增加。
由于汽车生产商对制造成本的严格控制，加上对车身质量的控制，减少线束已经成为一个必须要解决的问题。
另一方面，以网络通讯为基础的线控技术（X-by-wire）将在汽车上普遍应用。
因此，车载网络时代终将来临。
车载网络种类有很多种，应用较多的有LIN，CAN、FlexRay、TIP/C、SAEJ1850、TFCAN、ASRB、MOST等。
美国汽车工程师协会（SAE）根据速率将汽车网络划分为A、B、C3类。
A类总线标准包括TTP/A（Time Triggered Protocol/A）和LIN（Local InterconnectNet-work），其传输速率较低。
①TTP/A协议最初由维也纳工业大学制定，为时间触发类型的网络协议，主要应用于集成了智能变换器的实时现场总线。
②LIN是在1999年由欧洲汽车制造商Audi、BMW、DaimlerChrysler、Volvo、Volkswagen、VCT公司以及Motorola 公司组成的LIN协会共同努力下推出的用于汽车分布式电控系统的开放式的低成本串行通讯标准，从2003年开始得到使用。
B类标准主要包括J1850、VAN，低速CAN。
①1994年SAE正式将J1850作为B类网络标准协议。
最早，SAEJ1850被用在美国Ford，GM以及Chrysler公司的汽车中。
现在，J1850协议作为诊断和数据共享被广泛应用在汽车产品中。
②VAN标准是ISO1994年6月推出的，它基于ISO11519-3，主要为法国汽车公司所用。
但目前就动力与传动系统而言，甚至在法国也集中应用CAN总线。
③CAN是德国BOSCH公司从20世纪80年代初为解决现代汽车中众多的控制与测试仪器之间的数据交换而开发的一种串行数据通讯协议。
低速CAN具有许多容错功能，一般用在车身电子控制中，而高速CAN则大多用在汽车底盘和发动机的电子控制中。
C类总线标准主要包括TTP/C，FlexRay和高速CAN（ISO11898-2）。
都用于与汽车安全相关以及实时性要求比较高的地方。
如动力系统，其传输速率比较高，通常在125kb/s到10Mb/s之间，必须支持实时的周期性的参数传输。
①TTP/C协议由维也纳工业大学研发，基于TDMA（Time Division Multiple Access）分时多址的访问方式。
②FlexRay是BMW、Daimler Chrysler、Motorola和Philips等公司制定的功能强大的网络通讯协议。
基于TDMA的确定性访问方式，具有容错功能及确定的通讯消息传输时间，同时支持事件触发与时间触发通讯，具备高速率通讯能力。
③欧洲的汽车制造商基本上采用的都是高速CAN总线标准ISO11898。
总线传输速率通常在125kb/s～1Mb/s之间。
然而，作为一种事件驱动型总线，CAN无法为下一代线控系统提供所需的容错功能或带宽，因为X-by-wire系统实时性和可靠性要求都很高，必须采用时间触发的通讯协议，如TTP/C或F1exRay等。
二、FlexRay协议FlexRay是由FlexRay共同体（FlexRayConsortium）制定的协议。
该共同体为一企业合作组织，成立于2000年。
到2005年，FlexRay共同体的7个，核心成员是：BMWGROUP、BOSCH、DaimlerChrysler、GM、Motorola/Freescale、PHILIPS和VWAG。
除此之外，它还有超过93个协作和发展成员。
从2002年发布的V0.4.3协议规范到2005年的V2.1协议规范，共发布多达7个版本。
F1exRay网络是一种高传输速率（每通道10Mb/s）的时间触发型网络。
采用分时多址方式对总线进行访问，具有确定性和容错功能。
非常适合于下一代汽车线控系统或分布式控制系统的通讯要求。
（一）拓扑结构（Topology）共有3种网络拓扑结构，即：总线型（Bus）、星型（Star）和混合型（Hybrid）。
而每一种类型都有单通道（SingleChannel）和双通道（DualChannel）之分。
在星型结构中，还存在联级方式。
总线型如图1所示，单、双通道联级星型如图2、图3所示，单、双通道混合型结构如图4、图5所示。
（二）节点（Node）的内部逻辑结构主要由电源供给系统（Power Supply），总线驱动器（Bus Driver，简称BD）、总线监控逻辑（Bus Guardian，简称BG）、固化有FlexRay通讯协议的通讯控制器（CommunicationController，简称CC）及主机（Host）5个部分组成，如图6所示。
其中BD和BG的个数对应于通道数，而BG是用于避免通道定时错误的一个独立部分，与通讯控制器和微处理器相连。
总线监控逻辑必须独立于其他的通讯控制器。
节点的两个通讯过程如下。
a.发送数据主机（Host）将有效的数据送给通讯控制器（CC），在通讯控制器中进行编码，形成数据位流（bitstream），通过总线驱动器（BD）发送到相应的通道上。
b.接收数据在某一时刻，由总线驱动器访问总线，将数据位流送到通讯控制器进行解码，将有效数据部分由通讯控制器送给主机Host。
（三）FlexRay网络通讯协议FlexRay网络通讯协议主要体现在4个核心机制上：编码与解码（encoding and decoding）、媒体接入控制（Media Access Control）、数据帧与特征符处理（frame and symbol processing）和时钟同步（clock synchronization）。
除此之外，控制器主机接口（controller Hostinter face，简称CHI）为实现这些机制提供数据传输服务。
1．编码与解码（encoding and decoding）编码的过程实际上就是对要发送的数据进行相应处理的过程，如加上各种校验位、ID符等。
解码的过程就是对接收到的数据帧进行“解包”的过程。
编码与解码主要发生在通讯控制器与总线驱动器之间的通讯，如图7所示。
其中RxD为接收信号，TxD为发送信号，TxEN为通讯控制器请求数据信号。
信息的二进制表示采用“不归零”码。
对于双通道的节点，每个通道上的编码与解码的过程是同时完成的。
编码与解码的过程主要由3个过程组成：主编码与解码过程（CODEC）、位过滤（bitstrobing）过程和唤醒模式解码过程（WUPDEC）。
以主编码与解码过程（CODEC）为主要过程。
1）帧编码传输起始序列（transmission start sequence，简称TSS），为一段时间的低电平，用于初始化传输节点与网络的对接。
帧起始序列（frame start sequence，简称FSS），为一小段时间的高电平，紧跟在传输起始序列（TSS）之后。
字节起始序列（byte start sequence，简称BSS），由一段高电平和一段低电平组成，位于FSS之后。
给接收方节点提供定时信息。
帧结束序列（frame end sequence，简称FES），由一段低电平和一段高电平组成，位于有效数据位之后。
如果是在动态时序部分接入网络，则还要在FES后附加上DTS——动态尾部序列（Dynamic trailing sequence）。
将这些序列与有效数据位（从最大位MSB到最小位LSB）“组装”起来就是编码过程，最终形成能够在网络传播的数据位流。
此外，低电平的最小持续时间为一个gdBit。
图8与图9分别为静态和动态部分的帧编码。
2）特征符编码F1exRay，协议有3种特征符：冲突避免特征符（collision avoidance symbol，简称CAS）、媒体接入测试特征符（Media access test symbol，简称MTS）和唤醒特征符（wake up symbol，简称WUS）。
对CAS和MTS采用完全相同的方式进行编码，对唤醒特征符（WUS）采用另一种模式编码。
节点对传输冲突避免特征符（CAS）和媒体接入测试特征符（MTS）的编码，是跟随在传输起始序列（TSS）之后的一段时间长为cdCAS（为某一具体数值）的低电平，如图10所示。
节点对唤醒特征符（WUS）的编码并没有采用辅助信号TSS，随TxEN的边沿触发同步于TxD信号进行传输一个唤醒特征符（WUS），如图11所示。
帧与特征符解码的过程就是编码的逆过程。
这里不再赘述。
2．数据帧格式（FormatofFrame）一个数据帧由帧头（HeaderSegment）、有效数据（PayloadSegment）和帧尾（TrailerSegment）多个部分组成。
FlexRay数据帧格式如图12所示。
1）帧头部分共由5个字节（40个位）组成。
包括保留位（Reserved bit，1位）、数据指示位（Pay load Preamble indicator，1位）、空帧指示位（Null frame indicator，1位）、同步帧指示位（Sync frame indicator，1位）、启动帧指示位（Start up frame indicator，1位）、ID（11位）、有效数据长度（7位）、头部循环校验CRC（11位）和循环计数（6位）。
2）有效数据部分可由0-254个字节或0-127个字组成。
在图12中分别以Data0、Data1…Data253表示。
在帧的CRC校验中，有效数据部分的前6个字节设为海明距离（Hamming Distance）。
当数据超过248字节时，海明距离为4个字节。
在动态时序部分，有效数据部分的头两个字节通常用作消息识别域（messageIDfield）。
消息识别（又叫消息ID）标明应．用数据的物理内容，仅仅用于在动态时序传输的数据帧，长度为16位。
在传输节点中，消息ID是由主机将其作为应用数据而写入的，通讯控制器（CC）并不能够对消息ID进行识别。
在接收节点中，对一个帧的存储依靠于利用消息ID 而进行过滤处理的结果，如图13所示。
在静态时序部分，有效数据部分的头13个字节（DataO-Data12）通常用作网络管理向量（networkmanagementvector，简称NM）。
在同一个簇内，所有的节点应具有相同长度的网络管理向量，仅仅用于在静态时序传输的数据帧，长度为8位，如图14所示。
3）帧尾部分只含有单个的数据域，即一个24位的CRC。
FlexRay的CRC计算是遵循一定的运算法则。
包括帧头CRC计算和数据帧CRC计算。