汽车机电一体化控制系统：RBW或XBW基本原理

RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统是目前汽车研究中最重要的课题之一。一般来说，追求更高汽车安全性、舒适性和更好性能的需求刺激了该课题的研究，采用的手段综合应用不同主动DBWAWD驱动和BBW AWB制动、SBW AWS转向以及ABW AWA悬架机电一体化控制系统间的相互作用。

该课题的研究已经在几个方面取得进展，但同时出现了这样一种情况：在致力于构造基于一种RBW或XBW整体式一体成型车身或底盘运动机电一体化控制系统的汽车仿真器方面所做的努力很少。

例如，装备主动DBW AWD驱动和BBW AWB制动、SBWAWS转向以及ABW AWA悬架机电一体化控制系统的汽车，实质上被设计为一套任何参数都被合理给定的汽车动力学模型。这种汽车仿真器的设计参数是强制性的。

特别是，在建造前，汽车设计者原则上应能使用汽车仿真器测试原型系统。而测试成本应低于使用汽车模拟驾驶器和实际原型车。

本节的目的是提出一种RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统——利用车辆的主动DBW AWD驱动和BBW AWB制动、SBW AWS转向以及ABW AWA悬架机电一体化控制系统（同时考虑这些主动机电一体化控制系统的交互）。这种系统有能力用一组给定纵向运动（x）、横向运动（y）和垂直运动（z）动力学仿真一辆汽车。

在先进乘用车的乘坐与操控（ride and handing，R&H）特性开发中，基于物理模型的数值仿真，即虚拟原型和基于概念验证原型车的实验之间存在着差距。针对这一挑战，出现了通用原型车这一有前途的解决方案。

通用原型车会装备先进的计算机控制的“执行机构”（actuators），以验证和配置其乘坐和操控特性。

这种先进“执行机构”的例子包括：主动DBW AWD驱动和BBW AWB制动、SBW AWS转向以及ABW AWA悬架机电一体化控制系统。

一个整体式一体成型车身或底盘运动微控制器会命令那些“执行机构”跟踪一套参考信号。这套参考信号对应期望的R&H行为。

目前，在实车被制造出来之前，会用基于运动的驾驶模拟器仿真虚拟样车的R&H行为。然而，这种模拟器的可达加速度严重限制了逼真再现汽车运动的最大范围。

通用原型车能考虑到虚拟样车的R&H特性的逼真重现，因此可使汽车科学家和工程师在决定建造概念验证原型车之前试验和评估其行为。

图1-9【WINNER ET AL.2003】所示的这种RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统，用不同的E-M执行机构、踏板和转向感觉仿真器以及一个机电一体化控制模块的分布式嵌入（distributed embedded，DE）网络，取代传统机械或流体（液压和/或气动）式驾驶人控制装置、驱动（SBW AWS驱动）和制动（BBW AWB制动）、转向（SBW AWS转向）及减振/缓冲（ABW AWA悬架）装置之间的连接。

图1-9 某种RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的结构和功能框图【WINNER ET AL.2003】

传统的转向和制动机械零件，如转向柱、中间轴、泵、软管、流体、传动带和制动助力泵/主缸被全部移除。其结果令人满意，比如，SBW AWS转向和BBW AWB制动机电一体化控制系统可提供改善的油耗。

淘汰流态的油性液体或气体（空气）更为环保。元件减少后，简化了装配，并提高了驾驶舱设计自由度。而且没有了任何机械连接限制，使得增强驾驶人控制成为可能。另外，其适应性设计使机电一体化控制装置更容易从左舵驾驶变为右舵驾驶。

RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统也为汽车制造商改进避撞性提供了技术支持【DELPHI 2001】。

作为全编程机电一体化控制系统，RBW或XBW为汽车制造商提供快速调试能力，这大大地减少了开发时间和成本。

编程灵活性和快速调试策略使RBW或XBW能快速和精确地满足多种车辆操控和路感规范，这让汽车制造商可以通过编程设计其期望的品牌特征。虽然RBW或XBW先进技术具有许多优点，但为了安全考虑，必须进行严格的分析和验证。

因此，在汽车制造商和其OEM之间必须就一个RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的系统安全程序密切协作。对于OEM来说，系统安全是压倒一切的首要任务【DELPHI 2001】。

RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统让驱动和制动、转型及减振/缓冲动力学实现真正的协同机电一体化控制。它也提供了与汽车其他更多功能集成的能力。

这些机电一体化控制超系统可全编程，为优化R&H和主动安全性能提供最大可能，包括VSC、防侧翻辅助及防撞【DELPHI 2001】。

作为一个集成化安全系统（integrated safety system，ISS）的部件，RBW或XBW先进技术连同如德尔福公司的FOREWARN^TM碰撞预警传感系统等代表了动态车辆安全管理的关键构件。

在检测到一个可能发生的碰撞并认为可以规避时，RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统可自动激活，以便在需要的时候对驾驶人动作进行补充。这种综合方法可启动安全提高功能，如车道保持、增强侧向操纵以及最终的真正防撞等。同时，德尔福公司用一种机电一体化技术——RBW或XBW和FOREWARN^TM更好地保护驾驶人和乘客【DELPHI 2001】。

下一代RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统，即安全相关容错（fault-tolerant，FT）汽车机电一体化控制超系统，可在车辆中起关键的作用。它们可能是驾驶人和车辆之间的唯一联系，能自主地执行大量程序来实现车辆的多种功能。

例如，相比机械或流体式系统，图1-10所示的RBW或XBW整体式一体成型车身运动机电一体化控制超系统具有更多的优点，即【SHENOY 2006】：

• 机动性效率更高。

• 汽车行业的标准化。

• 更低油耗（SFC）。

• 安全性、舒适性和可靠性。

• 设计自由度。

图1-10 RBW或XBW的布局示例【SHENOY 2006】

它们更轻、更容易制造和维护，同时也能够提供更完善的功能。例如，在一个BBW AWB制动机电一体化控制系统中，一根数字总线可取代从制动踏板至车轮制动器的流体（液压和/或气动）管路。

踏板上的一个传感器测量驾驶人输入，在控制环路的另一端，一个E-M电动机对车轮施加需要的制动力。同样地，机电一体化可以取代或增强其他系统，如DBW AWD驱动、SBW AWS转向或ABW AWA悬架机电一体化控制系统【NOS-SAL AND LANG 2002】。

计算机分布式嵌入（DE）系统是RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统和机电一体化控制系统功能的关键。

开发者可以验证通信和操作系统及硅应用的正确运行，这是计算机DE系统的基础，但最终他们不能以相同的方式验证这些系统中应用的相关软件和数据结构。

开发者必须配置各自应用程序的通信系统，创建访问通信系统的中间件代码，最后是实现应用软件。因为这对于每个新应用都是必需的，因此【NOSSAL AND LANG 2002】的作者需要一个明确的流程和一套互补的工具来使错误最小化并支持一个高质量开发生命周期。图1-11给出了一个DE系统的示例性物理模型。该物理模型使用输入和控制块之间的一个任意分区边界，但其他分区也应该是可以的【EMAUS AND GRUSZCZYNSKI 2003】。

图1-11 Origin-from分布式功能【EMAUS AND GRUSZCZYNSKI 2003】

例如，从【EMAUS AND GRUSZCZYNSKI 2003】中可知，软件需要确立操作速度，而不是协议传输速度，如图1-12所示。

图1-12 分布式功能中的软件：I-输入；Tx-发送器；Rx-接收器；C-控制器； O-输出【EMAUS AND GRUSZCZYNSKI 2003】

SAE嵌入式软件工作组—目标【EMAUS AND GRUSZCZYNSKI 2003】

更多预定目标：

• 增加软件采购效率。

• 优化OEM和供应商之间共享的软件开发生命周期。

• 最小化初级工程师造成的错误。

• 通过可重用软件构造块和算法，降低软件开发成本。

• 开发请求调度、I/O处理、信号损失等常用方法。

• 开发通用分布式嵌入软件（distributed embedded software，DES）需求。

• 提升有关这种系统，即分布式嵌入（DE）系统的问题的行业意识。

• 开发车辆网络软件（如果支持OEM）的通用方法。

• 开发通用软件测试方法。

在【NOSSAL AND LANG 2002】中，作者提出了一种物理模型模式的流程，即“A”开发流程。该流程由一系列物理模型组成。每个物理模型服务一个特定目的，因此只包含该目的所需要的信息块。物理模型通过流程转换彼此相连，要么向前任流程增加信息，要么从前任务流程提取信息。“A”开发流程指导开发者从一个物理模型到下一个物理模型，并且有一套工具支撑。

在【NOSSAL AND LANG 2002】中，作者介绍了如何开发流程物理模型，特别讨论了其物理模型模式流程。

“A”开发流程建立在许多物理模型上，每个模型用于某个特定的开发阶段。【NOSSAL AND LANG 2002】根据两个特性定义物理模型：

• 一个物理模型是一个现实世界的专用抽象。

• 一个物理模型能帮助解释现实世界现象。

开发者在这里面临一个严峻挑战。因为每个物理模型用于某个特定目的，所以开发者在整个开发流程中需要不同的物理模型。然而，好几个物理模型代表相同系统的不同方面，它们可能在某些方面彼此冲突。

一个补救该问题的直接方法可能是创建一个全面的虚拟系统物理模型。该模型可能是对原系统的完美描述。它会对现实世界系统的全部属性建模，用户能从它得到不同的物理模型。显然，该模型会非常复杂，也不容易理解。

【NOSSAL AND LANG 2002】需要一种更实用的方法。为了实现开发流程期间不同的目的，该虚拟系统物理模型在不同抽象级别实例化，而无须实际建造。每种物理模型实例类型，即每种开发物理模型，适合某一流程步骤并只包含该步骤所需的信息块。下面两个主要的约束条件指导流程定义【NOSSAL AND LANG 2002】：

• 提出的流程只充当开发者可适应特定需求的一个角色物理模型。

• 该流程必须反映汽车行业特有的OEM-供应商关系。

如果开发流程在该流程中某个特定点向某个物理模型增加信息，【NOSSAL AND LANG 2002】不需要虚拟系统物理模型，并会将该信息传递至所有后面的模型。

因此，它们以某个开发流程中的两个问题为重点：

• 一系列流程步骤以一个给定顺序执行。

• 设计数据，即一个物理模型中使用的所有信息块在整个过程中添加，并且不允许清除。

初看，这些表述似乎稀松平常，但不幸的是它们并不平常。目前汽车系统中的开发方法很少遵守这些原则。

相反，他们应用ad hoc方法，为不同的目的创建不同的物理模型，而不考虑别的。或者，更糟糕的是，他们不使用建模或仿真。

ad hoc方法对主要应用可能够了，但RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统需要一种不同的方法。

在【NOSSAL AND LANG 2002】中，作者的物理模型模式开发流程遵守这些原则。它定义一系列流程步骤，专门对应于不同目的一系列物理模型。

【NOSSAL AND LANG 2002】从彼此导出模型，并向每个模型增加特定信息。

在增加信息时，【NOSSAL AND LANG 2002】执行一致性检查，以避免信息不一致。

通过把每个信息块从一个流程步骤向随后步骤传递，【NOSSAL AND LANG 2002】在流程中不能丢失任何信息块。

“A”开发流程由四种物理模型组成，见【NOSSAL AND LANG 2002】：

• 功能物理模型。

• 体系结构分配功能物理模型。

• 虚拟原型。

• 体系结构物理模型——可以根据各自抽象级别分类。

DECOMSYS的“A”开发流程物理模型跟踪RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的应用的开发生命周期。

“A”开发流程这一名称源自开发物理模型的先后顺序，从顶上的体系结构分配功能性物理模型开始，随后从它导出物理模型的交互模式【NOSSAL AND LANG 2002】。

图1-13图解了“A”开发流程，表1-1列出了“A”开发流程信息流的细节【NOSSAL AND LANG 2002】。

从一个物理模型传递至另一个模型的信息在适当的格内列出，表格中行表示信息的源物理模型，列表示信息的目的物理模型。

各自物理模型中的信息可以输入（正常字体）或创建（斜体）。空白框表示不直接交互的物理模型。在“A”开发流程中只有彼此毗连的物理模型可传递信息。

一个现实世界系统的配置基于体系结构物理模型。配置数据是运行现实世界系统所需数据的特定于硬件的表示。例如，一个schedule（调度）抽象地描述通信模式【NOSSAL 1997】。

图1-13 “A”开发流程：“A”流程模型跟踪从功能模型到中间件和应用代码的RBW或XBW应用的开发【NOSSAL AND LANG 2002】

表1-1 物理模型关系【NOSSALANDLANG2002】

①控制回路周期。

②信号传输周期，任务偏移，信号传输偏移。

注意：信息（对象和关系）从一个物理模型传递至另一个物理模型。正常字体表示输入各自物理模型的信息；斜体表示创建的信息。

配置某种专用通信控制器的缓存的数据是这些配置数据的一部分，缓存由schedule（调度）得到。RBW或XBW整体式一体成型车身、space-chassis或body-over-chassis运动机电一体化控制超系统有一个明显的时间驱动系统体系结构趋势，这种体系结构由一个时间驱动通信系统，如FlexRay^TM，以及一个时间驱动操作系统组成，如OSEKTime（www.osek-vdx.org）。两者都要求一个必须在运行之前创建并加载至系统节点的调度表（schedule）。为了创建消息调度表，一个消息调度程序使用发送方-接收方关系、软件物理模型信号周期和信号，以及硬件物理模型中的分配信息。第二步，一个任务调度程序使用通信调度表和任务设置信息来得到每个节点的任务调度表。例如，为了在系统开发中帮助用户，DECOMSYS已实现了xDesigner（www.decomsys.com/htm/frs/2_xd.htm）。xDesigner是一个负责体系结构模型的工具。执行核心开发功能的向导工作在体系结构物理模型上。

例如，xDesigner包括一个创建通信调度表的ScheduleWizard。它实现一个变种装箱算法（bin-packingalgorithm）来自动得到FlexRay^TM的通信调度表【NOSSAL AND LANG 2002】。

与汽车市场中主要OEM厂商的密集讨论表明，基于模型的“A”流程满足未来RBW或XBW集成化汽车机电一体化控制超系统的应用开发需求。由于这些应用有严格的需求，开发者需要收集系统的信息，并在实际建造一个系统前通过建模和仿真来获得对系统的信心。

一旦开发者已获得一个适当的物理模型，他们就应在该流程中无缝地将模型变成一个现实世界的系统。因此，一个好的方法是一个使物理模型变为现实世界系统的无缝隙工具链。大多数公司已经有了一个工作开发流程或使用了一套特定的工具【NOSSAL AND LANG 2002】。

因此【NOSSAL AND LANG 2002】讨论的方案可能意味着一种任务物理模型，而不是一个教条的过程。该过程和工具可适应某个OEM或供应商的特别需求，以适合某个给定流程环境。介绍的工具是DECOMSYS的Flex Ray^TM系统工具链的一部分，也是朝向一个无缝集成式工具链的第一步。在扩展该工具链以提供更好的用户支持的同时，DECOMSYS也加入了处理汽车领域中原始设备制造商（OEM）和供应商间一般关系的方法。扩展的流程考虑组织结构设置，可以允许单个流程参与者相对自主地开发电控元件（ECU）或部件【NOSSAL AND LANG 2002】。

近来在可靠的、嵌入式系统先进技术中所取得的进步，以及对改进的汽车操纵性和主动安全性改善的持续的需求，已引起汽车制造厂商和OEM及供应商继续计算机控制线控系统的开发。

结果，汽车OEM和供应商已协力RBW或XBW的开发工作，以便让RBW或XBW更加有效地服务汽车行业的新兴需求。

系统体系结构、控制算法、系统安全性和汽车动力学开发的通力合作，使得汽车科学家和工程师集中发挥专长以便将整体式一体成型车身或底盘运动机电一体化控制超系统迅速带给顾客。在设计流程中减少制造成本和最大化效率的同时，汽车OEM的一个日益增长的需求是增加汽车安全性和性能【LEEN AND HEERNAN 2002】。

汽车环境中引入RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的发展势头很快，RBW或XBW检验了关键性应用中用机电一体化取代流体或机械式系统的这一全球运动。

RBW或XBW代表任何安全相关应用的基础，包括DBW AWD驱动和BBW AWB制动、SBW AWS转向以及ABW AWA悬架机电一体化控制和/或多安全气囊系统。这些应用将驾驶人从日常任务中解放出来，并辅助在紧急情况下寻找解决方案。这些应用旨在增加整体车辆安全性和性能。

RBW或XBW整体式一体成型车身和底盘运动机电一体化控制超系统的目标是让普通驾驶人像职业驾驶人一样熟练稳定地驾驶车辆。集成RBW或XBW可带来功能和基础结构的双重改进。

其中功能性改进包括【DELPHI 2002】：

• 改善的行驶舒适性和抓地性能：RBW或XBW计算机控制集成化汽车动力性使得DBW AWD驱动和BBW AWB制动、SBW AWS转向以及ABW AWA悬架机电一体化控制系统能协同工作。

• 增强的稳定性控制：传感器和微控制器协同工作以发现并随之修正增加的横摆运动。横摆会造成汽车的打滑失控或侧翻。

• 安全性增强系统：RBW或XBW先进技术提供如车道保持或防撞等安全系统所需要的通信线路。(www.xing528.com)

通过模块化的设计和硬件淘汰，RBW或XBW提供几个基础结构的改进【DELPHI 2002】：

• 增加模块化：全功能线控模块减少了汽车OEM装配时间和成本。

• 驾驶人界面改进：淘汰至转向柱的机械连接，使汽车OEM有更大的自由度（如位置、类型、感觉及性能）来设计驾驶人界面。

• 被动安全性增强：RBW或XBW驾驶人座舱可简化并改进乘员约束系统。

• 灵活性增加：车辆设计者可以更灵活地布局发动机舱盖下空间，设计车内

硬件以支持可替代传动系、增强风格和改进内部功能。

• 交货期缩短：汽车OEM可以通过手提电脑执行软调优能力，而不是手动调整机械零部件。

第2章节内容部分节选自【LEEN AND HEFFERNAN 2002】。在过去的几年中，汽车设计的一个趋势是通过引入能帮助驾驶人应对紧急驾驶情况的人工智能（AI）辅助系统，如ABS、BA、ESP等，来增加车辆的安全性。这些功能的典型特征是分布式辅助系统实现的动态驾驶的主动机电一体化控制。分布式辅助系统需要一个通信网络。

控制这些功能的机电一体化组件的安全性是非常重要的。然而，机电一体化组件的辅助功能只实现了一种依据某种故障安全策略的附加服务。若对辅助系统的正确行为有任何怀疑，系统可被停止。

没有机械备份的“电传线控”（by-wire）机电一体化控制系统，达到了汽车机电一体化安全性需求的一个新的维度。出现故障后，需要检查系统故障直至达到某个安全状态（如汽车停车）。

图1-14给出了自20世纪20年代以来是如何稳步采用动态驾驶控制系统的【PETERSEN 2003】。

客户对改善行驶舒适性、抓地性及稳定性的不断增长的需求，已使汽车厂商在RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的课题上集中了大量的研发力量。

图1-14 动态驾驶控制系统过去和计划的进展【LEEN AND HEFFERNAN 2002；PETERSEN 2003】

近年来，提出了VSC系统和RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统，如DBW AWD驱动和BBW AWB制动、SBW AWS转向以及AWB AWA悬架机电一体化控制系统。

在没有任何机械备份的RBW或XBW整体式一体成型车身或底盘运动控制超系统中，由传感器、执行机构及通信系统失灵造成的故障会危及乘客安全。

应对这种故障，有必要开发整体式一体成型车身或底盘运动机电一体化控制超系统中的故障安全系统。这种在故障和失效发生时提供信息的超系统称为故障检测与隔离（fault detection and isolation，FDI）系统【PETERSEN 2003】。

未来的RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统可能要求既要容错又要一种可靠电源。这些特性和系统到目前为止是作为特殊系统开发并常常与应用分开的、未来必须整合进一个普遍适用的开发流程，以确保流程的无缝集成。使用一种数学模式软件开发流程是可行的。

通过增加车载E&IN和硬件架构的仿真模型（如冗余），即使在开发的早期，也可以总体评估系统行为，可以分析系统行为与其他系统的交互。有几种协议适合RBW或XBW应用。

例如，时间触发协议（time-triggeredprotocol，TTP），是专为改善驾驶安全性的一种有前途和可以使用的协议。然而，在制造厂商寻求更为灵活的设计和更低的成本时，FlexRay^TM和时间触发控制器局域网（time-triggered controller area net-work，TTCAN）协议可能开始与TTP竞争【LEEN ET AL.1999】。

图1-15展示了如安全气囊和道路识别传感器等主动或被动安全系统的过去以及未来潜在的改进。先进的机电一体化控制系统和RBW或XBW基础架构可带来潜在的主动安全性的改进。

总之，RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统由DBW AWD驱动和BBW AWB制动、SBW AWS转向及ABW AWA悬架等机电一体化控制系统组成，如图1-16所示【SNU 2000】。

图1-15 主动或被动安全系统的过去和未来：先进的机电一体化控制系统和RBW或XBW基础架构可带来潜在的主动安全性改进【LEEN ET AL.1999】

考虑研发一种目标RBW或XBW整体式一体成型车身或底盘机电一体化控制超系统。这种超系统带有如DBW AWD驱动和BBW AWB制动、SBW AWS转向及ABW AWA悬架等机电一体化控制系统，如图1-17所示【SNU 2000】。

如果RBW或XBW整体式一体成型车身或底盘机电一体化控制超系统要实现降低事故中死亡和伤害的安全性承诺，那么这种汽车内RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统必须有一个通信网络。该通信网络可使RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统能平稳、安全和高效地单独或协同工作。集成在一个网络中的RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统也提供了功能优势。要控制汽车，需要结合驱动（DBW AWD驱动）和制动（BBW AWB制动）、转向（SBW AWS转向）以及减振/缓冲（ABW AWA悬架）等，因此协同工作非常关键。

为DBW AWD驱动和BBW AWB制动、SBW AWS转向以及AWB AWA悬架等全部机电一体化控制系统建立一个单一微控制器网络，显然要比单个网络对应每个系统的多。原因是减少了信号延迟和共享了系统资源。为了处理RBW或XBW网络的通信需求，汽车业看起来要集中在一个时间触发体系架构（TTA）上。

图1-16 RBW或XBW的机电一体化控制层级【SNU 2000】

图1-17 RBW或XBW的结构和功能框图【SNU 2000】

简单地说，时间触发体系架构（Time-triggered architecture，TTA）意味着在确定的时间执行确定的动作。因此，在这种网络中的所有节点有一个基于同步时钟的共同时间基准。消息有优先级，因此即使正在发送有关另一个动作或时间的另一个消息，消息也会被网络中优先级更高的动作获得。两个领先的TTA是TTP和FlexRay^TM。TTP已有约20年历史，并得到了奥迪、大众和TTTech omputertechnik AG等厂商的支持。

2003年，一个由宝马、戴姆勒·克莱斯勒、摩托罗拉和菲利浦半导体组成的联盟公布了自己的TTA，称为FlexRay。第三个协议候选者TTCAN，目前被认为不太可能，它始于2004年。例如，据说下一代BMW X5车要实现汽车世界中的第一个FlexRay应用，该车的机电控制减振器上使用了这种相对新的网络协议。这可能会在宝马推广第一个使用FlexRay作为主要汽车通信主干网的平台前两年发生【BRYANT 2005】。

当前的CAN-C系统被限制在500kbit/s，许多汽车制造商觉得这还不够快。更成问题的是，CAN不是确定性的；也就是说，它不能保证可在某个特定时刻成功传输某个消息。有在网络主张优先级的方法，但这涉及选择不能厚此薄彼，即在需要它自己选择时行不通。例如，是制动重要还是转向重要，当制动和转向两者出现争执的时候，汽车的电动阀“崩溃”了。通过提高数据传输率，实现一种建立网络时钟以便每个模块有可做自己事情的独立时间切片的低成本方法，FlexRay解决了这两个问题。本章对这种系统有充分的介绍，那些想要学习的读者可以参考。在接下来的几年，关于这种系统的介绍估计会有更多。

同时，那些对CAN开发工具有着浓厚兴趣的OEM期待投资获得不错的收益【BRYANT 2005】。这是可能的，因为目前控制车内如电动车窗和门锁的网络是由所构建协议管理的。初看起来，FlexRay和TTP似乎完全相同。两者都是基于时间触发的体系结构，但数据速率和传输率不同。FlexRay为数据传输速率达10Mbit/s的光纤设计，而且也不能在铜线上运行。TTP使用速率只有2Mbit/s的铜线传输，尽管Vienna大学的开发人员正在探测利用光纤实现TTP。

FlexRay^TM首次出现在铜线上。铜线是汽车中当前最先进的技术。但是光纤很可能会是未来的尖端技术。

相比铜线，光纤能提供更快的数据传输速率，还有在质量和电磁兼容性上的优势；但是，使光纤弯曲而让它在整部汽车上运行也不太现实。有趣的是，FlexRay同时为铜线和光纤两者而设计，因为宝马和戴姆勒·克莱斯勒这两个联盟中的汽车制造厂商支持不同的选项。

FlexRay基于一个名为Byteflight的BMW协议，其背后的思想是这样的：接线必须提供与机械系统同等的安全性。那机械系统中的保护措施有哪些呢？机械系统中油液或气体（空气）提供工作力。接线运送的信息相当于油液或气体（空气），因此必须保护。

协议控制和组织信息。信息必须在一个清晰确定的时间点到达，也就是说，信息必须在正确的时间到达。为了避免某个不确定的时间点，则需要可预测性【BRETZ 2002】。

“确定的”（Deterministic）只是意味着数据在一个预定时间发送（基于时间触发），与之对比的是任何时间发送（基于事件触发）。根据FlexRay和TTP，网络上每个节点进出的数据消息均以该网络全局时钟为基准调度。

因此，为了保持所有网络节点有相同的调度表和在同一时间段内，需要时钟同步和定期再同步时钟。TTP和FlexRay有保持时钟同步的内建机制【BRETZ 2002】。

RBW或XBW协议也必须是容错的。汽车的工作环境恶劣，电线要在从非常热的外燃机（EEC）室或内燃机（ICE）室至冰冷冷起动的条件下工作。同时，随着汽车的运动，包括电线或插接件在内的零件也会移动。

因此，总线系统（即电线）和协议必须有防止断线、插接件腐蚀、短路等意外的安全保护措施。实现方式是冗余系统。TTCAN协议是候选协议中的黑马。

目前汽车中使用的基本CAN（没有时间触发器）经串行数据传输以1Mbit/s的速率进行控制和通信。但CAN是一种基于事件触发的协议（event-triggered proto-col，ETP），意味着它在命令发生时处理命令，而不是按照优先级。

由于CAN速度慢而且不能按优先级处理，汽车厂商认为CAN不适合用于机电控制的驱动、制动、转向或减振（缓冲）等关键领域。

到目前为止，TTCAN开发者是否能克服上述问题尚不清楚。将协议扩充至并非其最初设计目标的状态是件困难的事情【BRETZ2001，2002】。

总之，汽车行业对于与安全性有关的问题总是非常关注，也始终在努力开发不断提高安全性的方法，如智能驾驶人辅助系统。

然而，这种系统需要计算机控制以实现效率最大化。随之便是用机电一体化组件取代所有机械或流体（液压和/或气动）备件的需要。只有在确定取代机械或流体（液压和/或气动）式备件的系统非常安全时，才能真正完成取代。这种系统称为RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统【MOST 2003】。

由戴姆勒·奔驰、菲亚特、福特、沃尔沃、博世、Mecel、MagnetiMarelli、Chalmers大学和Vienna技术协会等组成的一个联盟已完成了该领域中的工作。

RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的例子包括：DBW AWD驱动和BBW AWB制动、SBW AWS转向及ABW AWA悬架机电一体化控制系统。

图1-18图解说明了RBW XBW整体式一体成型车身或底盘运动机电一体化控制超系统的一个范例应用【SHRINATH AND EMADI 2004】。

一个XBW或XBW整体式一体成型车身、space-chassis或body-over-chassis运动机电一体化控制超系统的范例应用由连接至电控单元（ECU）的执行结构和传感器组成。ECU根据传感器的信息给执行机构输送指令，同时反馈给驾驶人。基于获得的测量值，驾驶人可进行适当的修改，修改结果转给执行机构。必须确保获得的测量值一直是精确的。如果传感器采集的读数不准确，或驾驶人给执行机构的响应没有被准确解释，就会带来非常严重的损失。另一个实施大规模制造这种技术的问题是其经济可行性。此外，与这种技术有关的问题还有可靠性和可维护性【SHRINATH AND EMADI 2004】。

图1-18 RBW或XBW整体式一体成型车身、space-chassis、skateboard-chassis或body-over-chassis运动机电一体化控制超系统的一个实现【SHRINATH AND EMADI 2004】

RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的整体架构基于一种时间触发的方法。全部活动以一个特定的时间点执行。时间被划分为等长的时隙。每个时隙分配某个特定任务。

所有节点时钟与某个全局意义的时间同步。可以通过由某个主节点向其他节点发送同步脉冲实现。这种脉冲实际是周期的。

在特定时间实例点，所有传感器采集其测量值，测量值随之经总线传输。这些测量值用来更新某些变量。新的变量值覆盖旧的值。这些新值随后用来控制应用。

RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的一个主要特征是兼容性。这意味着不管DBW AWD驱动和BBW AWB制动、SBW AWS转向以及ABW AWA悬架机电一体化控制系统展示了何种特性，在将不同的机电一体化控制系统整合在一起提供相同功能和应用时，也都会展示同样的特性。

RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的另一个重要特征是处理错误的能力。错误是在某个未分配给它们的时隙期间节点“沟通”（talk）时产生的。这种节点被称为“胡说的笨蛋”（babbling idiot）。在一种基于时间触发的系统中可以避免这种错误，因为应该在哪个时段哪个节点传输是清楚的。总线访问由一种分时多址（time division multiple access，TDMA）方案控制，使用的是广播拓扑结构。

如前所述，关于哪个时段哪个节点可传输的信息存储在内存。这种信息在每个节点本地存储。每个节点应该遵循时间表。所使用的协议是时间触发协议/C类（time-triggered protocol/class-C，TTP/C）【SHRINATH AND EMADI 2004】。

节点架构基于一种被称为故障沉默“fail-silent”的操作方式。这意味着如果检测到某个节点有一个错误，则该节点会被要求停止传输。这样做是为了让错误节点不干扰网络的正常表现。有时，为了容错，系统会成对使用两个节点。在其中一个节点失效时，另一个节点会以一种无误差方式继续执行任务。这种技术有诸多独特的优势。首先，避免了实现其他容错（fault-tolerant，FT）机制所需的复杂电路。其次，结合软件故障检测，这种故障沉默（fail-silent）架构能够全面覆盖整个范围的可能错误。再者，可以测试这种机制以测试全部功能。如前所述，每个电控单元（ECU）由一些传感器和执行机构组成。图1-19介绍了一种SoC（system-on-chip，片上系统）电控单元（ECU）【BALSI 2006】。

图1-19 电控单元（SoC式）【BALSI 2006】

应该确定在一个由两个ECU组成的节点内，最终所作决策中不应该有任何的不同。这意味着每个ECU在公共总线上与另一个ECU交换数据，所以达成了一个共同决策。另一种使用公共系统的选择是使用一种传感器总线。同样，如果使用了一种数字传感器，则每个ECU可能会有相同的值。如果两个ECU的位置彼此远离，则传感器会连接到最近的ECU。如果相反，即两个ECU彼此距离很近，则传感器可通过传感器总线连接到ECU。

图1-18图解了一种汽车内RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的概念。软件物理模型包括两层：系统软件层和应用软件层。系统软件层向应用软件层提供服务。如容错和检测等服务在系统软件层实现。书写代码的语言是做了某些修改的ANSI C的一个子集，如（不包括特殊处理）高效率设计、更高的容错、可被测试和易于同步等是其主要的优势。这种RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统正由欧盟（European Consorti-um）开发，以作为一个能被全欧洲接受的智能驾驶人辅助系统开发的标准【SHRI-NATH AND EMADI 2004】。

NEC电子公司（欧洲）的新总线控制器TINA很好地支持TTP系统开发。该标准协议特别适合安全攸关的应用，如辅助换道、自动紧急制动、交通标志识别、自主跟踪等，以及新兴的RBW或XBW应用，如DBW、BBW、SBW和ABW。采用TINA，NEC开发了一种基于TTTech的TTP-IP“C2S”的总线控制器。该控制器满足开发人员对车内容错（FT）机电一体化系统的控制的高要求。TINA是第一个利用一个集成定序器核完全承担协议功能而使主CPU负担减轻的TTP控制器。至主CPU的数据传输采用的是一种通用总线接口（8位、16位或32位）。因此，TINA可与多种微控制器一起使用，如NEC的32位V850家族中的许多。

采用RBW或XBW应用，机械式或流体式（液压和/或气动）后备份系统被放弃，在早先的转向和制动系统中的备份系统中，这些备份系统只是由机电一体化辅助实现的。这种机电一体化控制系统对安全性和可靠性的要求非常高【D&R 2003】。

机电一体化控制系统必须安全传输某个确定时隙内出现的信号（如驱动、制动、转向和减振/缓冲信号等）。这便需要一种像TTP一样的容错、确定性的总线系统。TINA就是一种满足这些需求的ASIC微控制器。

主频为40MHz时，TINA的异步数据速率达5Mbit/s。TINA装有两个通道、用于通信网络接口（communication network interface，CNI）数据存储的4KB RAM以及调度信息的8KB RAM。

单个电源是DC3.3V，帧间隔＜5μs。TINA合适的工作温度为-40～85℃，以100针QFP封装提供。NEC的TTP总线控制器TINA促进了汽车开发人员大型开发灵活性，有助于OEM和供应商为未来汽车设计完全新颖的创新系统。

目前，正在开发基于TINA的安全关键应用和RBW或XBW整体式一体成型车身或底盘运动机电一体化控制功能【D&R 2003】。

例如，一匹马感知骑手意图、判断周围环境，为了确保自身和骑手安全而避开障碍物。类似地，在一个正响应另一辆汽车、行人或动物的突然出现的自适应驾驶人辅助系统中：一组传感器（如视觉传感器）识别周围环境；一个控制器在决定合适躲避动作的同时评估驾驶人的意图；在悬架控制调整轮胎向下力的时候，转向控制避免打转或打滑；独立的左右制动控制帮助躲避动作并控制车辆车速。这些动作的结果就是防撞得以完全安全地完成。

关于未来自适应驾驶人辅助系统建立、电子化执行机构的操作过程，改进传感器和控制器的安全性是一个关键问题。因此认为，充分利用Hitachi公司开发的集成技术的趋势会继续。这种至关重要技术的一个例子是正被Hitachi公司开发的RBW或XBW整体式一体成型车身、space-chassis、skateboard-chassis或body-over-chassis运动机电一体化控制超系统。这种系统可实现类似于人和马合一的功能【YOSHIDA ET AL. 2004】。

此外，一种能使汽车和驾驶人以一种自然方式合作的人机界面（human-ma-chine interface，HMI）先进技术，被认为会是朝着自主驾驶演变过程的一个重要部分。这种人机界面技术不会使自适应驾驶人辅助系统的干预对驾驶人造成任何不适的感觉，它也会与基础设施交互。

图1-20显示了一种高可靠性控制器的一个配置实例【YOSHIDA ET AL. 2004】。硬件备份确保了控制器能在某个部件损坏时继续作为一个整体工作。

图1-20 高可靠性控制器的配置实例【YOSHIDA ET AL. 2004】

软件架构的配置方式是：应用软件资源被用作软件组件，通信的安全性和I/O在中间层保证。这种分层架构，使得先前积累的软件资源可被利用，并且整个软件配置的可靠性可被轻易保证【YOSHIDA ET AL. 2004】。

RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的结构和功能集成：由于先前开发的因果关系以及采购策略，汽车制造商和OEM的研发中心一般倾向于把RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统作为独立的系统处理【SEMMLER ET AL 2006】。

这可能造成这样一种状态，例如，一辆带DBW AWD驱动（主动动力系统）和BBW AWB制动（主动制动）、SBW AWS转向（主动转向）和ABW AWA悬架（主动悬架）机电一体化控制系统的车辆，装备有多达4个独立行驶状态评估器、参考行为计算器和行驶状态控制器。

此外，一般会设置几个传感器来测量相同的变量，如横向加速度。这种架构可称作“共存功能方法”（coexistence functional approach），如图1-21所示【SEMMLER ET AT. 2006】。

考虑到大量执行机构动作主题中的重叠部分，必须以一种协调方式管理它们，以防止对动力稳定性造成不利的负面影响。由于在共存式功能方法中不可能总可以这样，所以获得的总结果可能不太理想。

这种方法的另一个决定性的缺点是：随参与的独立系统数量的增长，所需研发成本呈指数级增长。这个趋向与更短的研发时间和原型的约束可用性的需求不符【SEMMLER ET AL. 2006】。

作为响应，比如，Continental Teves已开发了功能分布的方法——集成式功能方法（integrated functional approach），如图1-22所示【SEMMLER ET AL 2006】。

在这种架构中，每个底盘机电一体化控制系统都有一个基本功能，如在SBW AWS转向机电一体化控制系统中的可变速比功能。

图1-21 功能分布的方法：共存功能方法【SEMMLER ET AT. 2006】

图1-22 功能分布的方法：集成式功能方法【SEMMLER ET AL 2006】

与共存式功能方法相比，这种结构中只有一个行驶状态评估器、一个参考行为计算器和一个行驶状态控制器。视车辆必要和实际的行为，这种SBW AWS转向机电一体化控制系统计算继续驾驶人设定路线所需的矫正横摆力矩。执行机构通过应用该力矩，为执行机构关心的调整和动力学储备留出余地。这种执行机构可保证主动安全性、行驶质量和驾驶乐趣的最佳整体优化。比如，转向干预的优先级高于制动干预。

机电一体化接口可以用在DBW AWD驱动（主动动力系统）和BBW AWB制动（主动制动）、SBW AWS转向（主动转向）和ABW AWA悬架（主动悬架）机电一体化控制系统之间。可以对这些机电一体化控制系统间的交互进行优化，以建立一个最佳整体效应【SEMMLER ET AT. 2006】。

即将到来的RBW或XBW整体式一体成型车身或底盘运动机电一体化控制超系统的技术包括【NOLTE ET AL. 2004】：

• 时间触发CAN（TT-CAN）：

■CAN之上的时间触发会话层；

■与CAN同样的限制。

• 时间触发协议（TTP）：

■纯TDMA；

■25Mbit/s；

■容错机制：

◆成员服务；

◆总线监护者；

◆时钟同步（分送式）。

• FlexRay^TM：

■混合TDMA/FTDMA；

■10Mbit/s；

■容错；

■灵活的。