当我们描述系统架构的时候，一定要区分系统架构的软件和硬件两个方面。本章的硬件架构部分为我们展示了现今汽车系统的艺术性。本章呈现的软件架构遵循了汽车开放系统架构（AUTOSAR）标准^[1]（见第2章）。当然，为了简洁、清晰和简化，我们做了适当的简化（即一些不必要的细节有时候会被省略）。

12.1.1.1 硬件架构

汽车系统的硬件架构可以在不同的抽象层次上查看。

“系统级”是抽象程度最高的。汽车系统由一系列通过网关互相连接的网络组成，如图12.1所示。总的来说，这些网络对应于现代汽车上不同的功能域（即底盘域、动力总成域和车身域）。

这些网络本身是由很多通过通信媒介互相联系在一起的ECU构成的（见图12.1中的网络A、D的放大图）。这些用于连通的物理拓扑结构基本上是任意的；但是总线型、星形和环形拓扑结构还是汽车上最常见的。这种层次被称为“网络层次”，它代表中间抽象层次。

需要注意的是从概念上讲，网关是一种特殊的ECU，它实际上是网络的一个成员，通过它，网络就互联起来了。

“ECU级”（图12.2）是抽象程度最低的层次。在这里，我们只对ECU的主要功能部分感兴趣。一个ECU是由一个或者更多的微控制器（MCU）以及通信控制器（CC）组成的。在多数情况下，ECU仅由一个MCU和一个CC构建而成。

图12.1 硬件架构——系统和网络级

图12.2 硬件架构——ECU层次

为了能够控制车辆的物理过程（比如控制发动机的喷油泵），这些ECU的MCU通过MCU的模拟量或者数字量的“输出”端口被连接到执行器上。为了提供获得外部环境信息的工具，传感器被连接到这些MCU的模拟量或者数字量的“输入”端口上。我们称这些接口为ECU的环境界面。

通信控制器（CC）促进了ECU与各个网络的物理连接。我们称该接口为ECU的网络界面。因此这些由网关ECU控制的通信控制器CC的数量等于由各自网关所连接的网络个数。

12.1.1.2 软件架构

汽车开放系统架构（AUTOSAR）中软件架构在应用软件和系统软件或基本软件之间作了严格的区分。当基本软件或系统软件为汽车通信协议（例如FlexRay）、操作系统以及故障诊断模块提供像通信协议栈功能时，应用软件是由具有具体应用功能（即控制环路、与传感器和执行机构互动功能，等等）的软件构成。这样一来，基本软件或系统软件提供了应用软件建立的基础。

12.1.1.2.1 应用软件

在AUTOSAR中，应用软件是由应用软件组件构成的，这些组件有独立定位的ECU以及由于要依附于ECU硬件而不能独立定位的传感器—执行机构组件。虽然这些组件可以很容易地被布置并且在不同的ECU之间重新定位，但是传感器—执行机构的组件因为性能/效率的原因，必须布置在特定的ECU上。AUROSAR组件标准支持在一个ECU上安置多个同样的应用组件。一个简单的例子就是一个ECU可以带两个冗余传感器。在这种方案中，两个单独的传感器组件被布置在一个ECU上，每个组件都为两个ECU中的一个提供恰当的服务。

应用软件组件和传感器—执行机构组件通过称为连接器的互相连接。这些连接器代表数据交换，这些数据在汽车域在连接器之间通常被称为“信号”。特性、要求和对信号交换的约束规定为各自连接器的属性。因此，下面考虑特性、要求和约束的类型。

12.1.1.2.1.1 时序特性和要求

这个类别的要求定义了信号交换的时间特性，它们包括发生、周期、延时和跳动。就关注的信号交换“发生”而言，可以区分周期性交换、零星交换和非周期性交换。尽管对于周期性交换和零星交换，对两个连续信号交换之间的时间长度的约束可以指定，但是对于非周期性交换却没有这样的约束。信号交换的“周期”在这里就是指周期信号中在两个连续信号交换之间的时间长度（如图12.3中的P所示）。在零星信号中，周期是指两个连续的信号交换之间的最短时间长度（有时也被称为最小时间间隔）。对于非周期性信号，周期特性并不需要。信号交换的“延迟”（图12.3中的L_i）被定义为发送端传输信号开始[即发送应用软件组件请求发送应用软件界面（API）服务的这个时间点]到接收端收到信号（即接收的信号在应用软件组件能接收到信号的这个时间点）之间的时间间隔。假定周期/零星信号的特性通过一个给定的网络交换，我们就能评估出每个信号的最大延迟；例如在参考文献[2]中，该作者为我们介绍了如何评估FlexRay网络中的最坏的延迟情况。而在本书的第13章，提供了针对CAN网络相同特性的评估方法。可以对信号的延迟比如“最大容许延迟”特性提出要求（例如图12.3中，L_i必须永远小于L_max，或者施加的平均值M[例如（Σ_iL_i/i）]必须等于图12.3中的M）。实际观测到的特殊信号的延迟对平均延迟的偏差被称为“跳动”。由于最小化跳动对保证高质量分布式控制环路具有极其重要的意义，所以“最大容许延迟跳动”是连接器的另一个重要指标[例如图12.3中，abs（L_i-M）必须要小于一个给定的值J_max]。特别指出，传输保真的要求（例如，保真VS尽力传输）可以很容易通过平均延迟和最大容许跳动参数来表达。特别地，对一个连接器设置一个平均延迟指标，比如一个有限的数，且要求最大跳动小于一个特定的值，这样就制定了一个其跳动是有界的保真传输要求；但是，对一个连接器设置一个无限大的平均延迟，并且要求其最大跳动小于一个特定的值，这样制定了一个不能保真传输的要求，该传输在发生时有一个有界的跳动。

图12.3 周期信号交换特征

12.1.1.2.2 容错要求

这个类别的要求定义了信号交换的容错特性，也就是特性的冗余类型、冗余度以及针对确定的冗余类型的附加参数。就关注的“冗余类型”来看，可以区分空间冗余（即信号通过多个物理通信通道进行交换）和时间冗余（即在一定的间隔内多次交换同样的信号值）。不同的物理通信通道数和规定间隔内冗余的信号交换次数就用“冗余度”特性来定义。由于两种类型的冗余（空间的和时间的）可以组合用于单个信号交换，所以需要对空间冗余和时间冗余特性进行分开请求。对于时间冗余，需要一个额外的属性来描述两次连续的、重复的信号交换的最小时间间隔。这个属性存在的合理性在于有这样的需求：（比如）在一个最大时间段ε内的突发干扰需要被容许。在这种情况下，为了保证干扰被容许，必须保证两个连续重复的信号交换之间的最小容许时间间隔大于最大的突发干扰持续时间ε。针对时分多址（TDMA）为基础的协议、如何确定重复值分布的进一步信息，读者可以参考文献[3]。明确地规定冗余类型是不需要的，因为这些信息已经被空间和时间冗余度隐性地定义了。(www.daowen.com)

12.1.1.2.3 基本或系统软件

除了应用软件组件，AUTOSAR同样也定义了基本软件或系统软件模块分层架构，这些系统软件为执行应用软件组件提供了运行平台。

AUTOSAR基本软件横向细分为不同类型的服务，它们是：

•输入/输出（IO）服务，它提供标准化访问传感器、执行机构以及ECU车载外设；

•记忆服务，它方便访问内部和外部（主要性能稳定）存储器；

•系统服务，包含诸如操作系统、ECU状态管理等模块；

•最后，也是最重要的是通信服务，它提供了一个访问不同车载网络[即

本地互联网络（LIN）、控制器局域网络（CAN）和FlexRay]的通信栈。

通信服务

通信服务是一组用于车辆通信（CAN、LIN和FlexRay）的模块。图12.4描述了通信服务模块所建立的通信栈。灰色的格子表示通信协议专用模块，“XXX”是各个通信协议（即CAN、LIN和FlexRay）的占位符。因此，AUTOSAR通信服务包含了通信协议下具体的传输协议（TP）和网络管理（NM）。

图12.4 AUTOSAR通信服务

XXX TP：在AUTOSAR中，TP是用来为大型通信数据单元（被称为消息）进行分段和重组的，这些消息是由诊断通信管理器（DCM）传输和接收的。专用的TP用于每个通信协议（CAN、LIN和FlexRay）。这些协议都很相似，甚至与ISO/DIS 15765-2.2规定的CAN（在特定的设置下）ISO TP兼容^[4]。

PDU路由器：PDU路由模块提供了两类主要服务。一方面，它把通过底层接口（比如FlexRay接口）接收到的这些数据单元（PDU）发送到更高层面（COM、DCM）中去。另一方面，PDU路由器通过把这些数据单元（PDU）从一个接口转发到另一个一样的（例如FlexRay到FlexRay）或者不同的接口（例如CAN到FlexRay），从而扮演了不同通信网络之间网关的功能。

COM：COM模块向高层次的运行环境（RTE）提供了基于信号的通信。COM提供的基于信号的通信服务可以被用于ECU内部或者各ECU之间的通信。在前一种情况中，COM主要用共享的内存来进行ECU内部通信，然而在后一种情况中，COM将大量的数据打包到信号发送端的PDU中，然后把这个PDU发送到PDU路由器中，其目的是通过各个的接口将PDU进行传输。在信号接收端，COM从PDU路由器那里获得PDU，然后从PDU中提取出信号，接着把提取出的信号转发到更高的软件层。

DCM：DCM通过通信网络（即CAN、LIN和FlexRay）提供允许测试设备控制ECU的诊断功能的服务。DCM支持KWP2000^[5]，它在ISO/DIS 14230-3中已标准化；也支持统一的诊断服务协议（UDS）^[6]，它在ISO/DIS 14229-1中已标准化。

NM：NM提供的工具使得网络中的ECU在进入和退出低耗能（甚至关机状态）的睡眠模式可以有一个平稳的过渡。AUTOSAR NM被分为两种模块：独立于通信协议的模块（通用NM）和依赖于通信协议的模块（CAN NM、LIN NM和FlexRay NM）。

XXX接口：接口模块有专门的协议，意味着不同的通信协议（即FlexRay、CAN和LIN）存在各自专门的接口。基于各种驱动（见下文）提供的基于帧的服务，接口模块方便了PDU的发送和接受。大量PDU在发送ECU处被打包成一帧，并且在接收ECU处被再一次提取出来。在FlexRay中，PDU被打包和提取的时间点，以及包含这些被打包的PDU的帧被移交给各自的驱动或者被接收端驱动恢复的时间点，均被叫做FlexRay接口通信操作的时间调度所控制。因此每个通信作业都是由一个或多个“通信操作”构成的，且其中每个通信操作都精确地处理一个通信帧（包括帧里所含的PDU）。

XXX驱动：和接口模块一样，驱动模块也有专门的协议。驱动模块通过各个CC协助帧的传输和接收，从而为接口模块提供了基础。

RTE：AUTOSAR RTE在应用软件组件和基本软件模块之间提供了接口，同时也为应用软件组件之间的通信提供了基础设施服务。

应用程序层：事实上，因为这个层面包含了AUTOSAR的应用软件组件（将在12.4节中详述），所以这个层面并不是AUTOSAR基本软件模块软件层架构中的一部分。

当我们观察FlexRay驱动、FlexRay接口、FlexRay传输协议和COM时，不同抽象层次与不同粒度层面——分别被称为帧层面、PDU层面、消息层面和信号层面的通信得到了加速。注意以上提到的所有要求都可以用于不同的抽象层面。