在过去的十几年里，汽车的电气和电子系统已经变得非常的复杂。今天汽车电子/电气系统开发工程师广泛使用基于模型的功能设计与仿真来迎接这一复杂性挑战。新兴标准定义了与低层软件的标准化接口，最重要的是，它还为功能实现工程师引入了一个全新的抽象级。

　　这提高了软件组件的可重用性，但不幸的是，关于如何将基于模型的功能设计的结果转换成高度环境中的可靠和高效系统实现方面的指导却几乎没有。

　　此外，论述设计流程物理端的文章也非常少。本文概述了一种推荐的系统级设计方法学，包括、分布在多个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和保险丝盒这样的子系统需要做进一步的详细设计。除此之外，在该步骤上，也可以开发出电源/接地概念。