分布式汽车电气/电子系统设计和实现架构
在过去的十几年里，汽车的电气和电子系统已经变得非常的复杂。今天汽车电子/电气系统开发工程师广泛使用基于模型的功能设计与仿真来迎接这一复杂性挑战。新兴标准(如AUTOSAR)定义了与低层软件的标准化接口，最重要的是，它还为功能实现工程师引入了一个全新的抽象级。
这提高了软件组件的可重用性，但不幸的是，关于如何将基于模型的功能设计的结果转换成高度分布式环境中的可靠和高效系统实现方面的指导却几乎没有。
此外，论述设计流程物理端的文章也非常少。本文概述了一种推荐的系统级设计方法学，包括架构设计、分布在多个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和保险丝盒这样的子系统需要做进一步的详细设计。除此之外，在该步骤上，也可以开发出电源/接地概念。
逻辑架构设计的对应步骤是SWC映射到ECU。这也决定了SWC之间的通信方案，即多个SWC是通过总线系统还是内部ECU进行通信。
通信方法的选择对物理设计有直接的影响，这也增加了整个设计过程的复杂性。例如，这取决于是否需要电线、常规电线、双绞线或双股双绞线。
封装步骤之后是物理系统集成，此处，CAD系统的信息用于添加额外的物理信息，如所需的在线连接器和布线通道。
这反过来对设计的逻辑层面有影响，并再次增加了整个设计过程的复杂性。太小的布线通道可能使得无法使用双股双绞线，或太长的电线长度可能使得将某个SWC重定位到另一个ECU上成为一个更具成本效益的替代选择。
当物理和逻辑流程都可以提供结果以后，它们的各种数据就可用来评估和优化汽车架构。不过，由于流程的复杂性，很难找到一个以上行得通的架构。其结果是，逻辑和物理设计师只能尝试优化其各自负责的设计部分。
图3：用户案例2——物理设计驱动逻辑设计
图3显示物理设计驱动逻辑设计的设计流程，逻辑拓扑是物理拓扑的衍生。与前面的增加信息不同，这里不必要的信息需要被过滤。例如，在需要一个雪茄打火机的物理设计时，这一功能并不需要一个SWC描述，因此这一信息在逻辑域中不需要。这两个例子只是反映了今天现有的设计流程挑战的一小部分，并说明了整个流程的复杂性。
物理和逻辑设计流程的集成
改善这个内在复杂设计流程(多个设计小组在同一整体设计上同时工作)的一个选择是，两个不同设计流程之间的紧密联系。
在整个设计流程中，数据需要保持同步，但与此同时，工程师受到了这一同步的太多阻碍。在目前的工作流程中，所有的人都共享相同的数据对象，而且在使用它们之前必须对它们进行检查，一种替代工作流程是，针对两个不同的设计流程，使用两个独立的数据库（见图4），但找到一种办法可以在不带来大量人力工作量情况下保持数据同步。
这需要这样的一个设计流程，大部分的设计实际上是自动生成，而不是手工生成。在同步过程中数据库的变化将自动导致一次“综合”操作，从而完全避免了重复以前努力的任务。
图4：并行处理物理和逻辑设计
一个例子是网络配置的生成。当需要通过网络传输的信号发生变化时，设计师可以手动输入这些变化，并手动运行所有必需的验证测试，这可以导致设计过程的时间延长几个月。与此形成鲜明对比的是，各种通信数据可以自动基于通信要求和数学算法生成，这可将完成设计流程所需的时间大幅减少到秒级。
一个类似的物理设计例子是系统集成。当系统出现变化时(如不同的路由通道)，人工过程需要太多的时间，而且容易出错。通过使用一个自动生成的流程，系统的变化可以通过流程或多或少地马上得到处理。例如，连接器的安装位置改变和电线长度可以自动生成。在这里，工程师的know-how用于定义规则，而不是应用这些规则。