分布式汽车电气电子系统设计和实现架构

分布式汽车电气/电子系统设计和实现架构在过去的十几年里，汽车的电气和电子系统已经变得非常的复杂。今天汽车电子/电气系统开发工程师广泛使用基

于模型的功能设计与仿真来迎接这一复杂性挑战。新兴标准定义了与低层软件的标准化接口，最重要的是，它还为功能实现工程师引入了一个全新的抽象级。

这提高了软件组件的可重用性，但不幸的是，关于如何将基于模型的功能设计的结果转换成高度环境中的可靠和

高效系统实现方面的指导却几乎没有。

此外，论述设计流程物理端的文章也非常少。本文概述了一种推荐的系统级设计方法学，包括、分布在多个ECU中的网络和任务调度、线束设计和规格生成。

为什么需要AUTOSAR?

即使在同一家公司，“架构设计”对不同的人也有不同的含义，这取决于他们站在哪个角度上。物理架构处理系统的有形一面，如布线和连接器，逻辑架构定义无形系统的结构和分配，如软件和通信协议。目前设计物理架构和逻辑架构的语言是独立的，这导致相同一个词的意思可以完全不同，

设计团队和流程也是独立的，这也导致了一个非常复杂的设计流程(如图1所示)。

图1：物理和逻辑设计流程。

这种复杂性导致了次优设计结果，整个系统的正确功能是如此的难于实现，以致于几乎没有时间去寻求一种替代方法，它可导致更坚固的、可扩展性更好的和更具成本效益的解决方案。为了实现这样一种解决方案，设计师需要新的方法，它可以将物理和逻辑设计流程紧密相连，并仍然允许不同的设计团队做他们的工作。

新兴的AUTOSAR标准为系统级汽车电子/电气设计方法学提供了一个技术上和经济上都可行的选择，尽管它主要针对软件层面，即逻辑系统的设计。不过，大量广泛的AUTOSAR 元模型及其丰富的接口定义允许系统级电子/电气架构师以标准的格式表达他的设计思想。从经济上看，AUTOSAR标准

打开了一个巨大的、统一的市场，它使得可以创建合适的设计工具。

本文描述了基于AUTOSAR的由点工具组成的系统级设计方法。这导致整个流程在所有有意义的地方使用标准，但又不局限于标准，或要求用户采用这些标准。

AUTOSAR工作原理

AUTOSAR标准是汽车制造商、供应商和工具供应商一起发起的，旨在规汽车电子控制单元(ECU)的开放式软件架构。

AUTOSAR标准指定了一个分层软件架构，它明确定义了应用软件组件(SWC)之间的接口、用户可见汽车功能和基础设施组件的实现。它对基础设施组件进行了严格的规定，以允许不同供应商开发的组件能一起工作。

用户可见的汽车功能通过互连的应用软件组件来实现。SWC是可以映射到ECU的最小单元。为了使SWC与特定的硬件无关，定义了虚拟功能总线(VFB)概念，此处SWC就使用VFB与它们的环境进行通信。

这一概念支持SWC重新定位到不同的ECU，从而增强了应用软件的可重用性。

一个AUTOSAR系统基本上由以下三个XML文件定义：SWC 描述、ECU资源描述和系统配置描述。这些文件描述了一个逻辑架构的所有方面：SWC、功能网络、拓扑和功能到ECU

的映射。虽然这些文件的语法和语义由AUTOSAR标准定义，但它们的创建方法学则留给了工具供应商。

用户案例分析

下面两个代表性用户案例可以让你更深入地了解到总

体物理和逻辑设计任务的复杂性。

在图2显示的设计流程中，你可看到逻辑设计过程是如何驱动物理设计过程的。这一设计流程的第一步是汽车逻辑功能的定义和实现。大多数OEM将一部汽车的电气系统分解成约100-200个功能。用户创建能表达各种汽车功能的单元级SWC，或从像Matlab/Simulink这样的模型设计工具中调用这类 SWC。

由于SWC的规和开发在时间和地点上都是高度分散的，以及许多SWC从许多不同的来源进入设计流程，因此应进行一致性检查，以尽早发现错误。即便只有接口描述，也已经可以进行部组件之间的接口一致性静态检查。在设计流程的这一点上，增加端到端的时序要重要的，以支持后面流程中要求时序信息的先进分析工具。

图2：用户案例1——逻辑设计驱动物理设计。

与此同时，可以创建一个有潜力的拓扑结构，它能勾画出分布式汽车网络的逻辑拓扑结构，以及描述传感器、激励器和ECU的连接。通常情况下，一个汽车项目开始于原有设计的重利用，然后对它进行修改。在重利用现有的ECU时，非常详细的ECU信息可以来自企业数据库，或需要定义新的ECU，其技术特性在开发过程中的特定期间是变化的。

在以上两种情况下，功能信息和拓扑信息都可以提供给物理设计流程。物理设计过程的功能级也需要ECU上的数据(如总线系统使用的)。现在的物理设计需要一个子系统设计步骤，在该步骤上，在物理组件映射到汽车上的封装空间(插槽)之前，如ECU和保险丝盒这样的子系统需要做进一步的

详细设计。除此之外，在该步骤上，也可以开发出电源/接地概念。