《分布式汽车电气电子系统设计和实现架构》由会员分享，可在线阅读，更多相关《分布式汽车电气电子系统设计和实现架构（4页珍藏版）》请在金锄头文库上搜索。
1、架构在过去的十几年里，汽车的电气和电子系统已经变得非常的复杂。今天汽车电 子/电气系统开发工程师广泛使用基于模型的功能设计与仿真来迎接这一复杂性 挑战。新兴标准（如AUTOSAR）定义了与低层软件的标准化接口，最重要的是， 它还为功能实现工程师引入了一个全新的抽象级。这提高了软件组件的可重用 性，但不幸的是，关于如何将基于模型的功能设计的结果转换成高度分布式环 境中的可靠和高效系统实现方面的指导却几乎没有。此外，论述设计在过去的十几年里，汽车的电气和电子系统已经变得非常的复杂。今天汽车电 子/电气系统开发工程师广泛使用基于模型的功能设计与仿真来迎接这一复杂性 挑战。新兴标准（如AUTOSAR）
2、定义了与低层软件的标准化接口，最重要的是， 它还为功能实现工程师引入了一个全新的抽象级。这提高了软件组件的可重用性，但不幸的是，关于如何将基于模型的功能设计 的结果转换成高度分布式环境中的可靠和高效系统实现方面的指导却几乎没 有。此外，论述设计流程物理端的文章也非常少。本文概述了一种推荐的系统级设 计方法学，包括架构设计、分布在多个ECU中的网络和任务调度、线束设计和 规格生成。为什么需要 AUTOSAR?即使在同一家公司，“架构设计”对不同的人也有不同的含义，这取决于他们 站在哪个角度上。物理架构处理系统的有形一面，如布线和连接器，逻辑架构 定义无形系统的结构和分配，如软件和通信协议。目前设
3、计物理架构和逻辑架 构的语言是独立的，这导致相同一个词的意思可以完全不同，设计团队和流程 也是独立的，这也导致了一个非常复杂的设计流程（如图1所示）。图 1：物理和逻辑设计流程这种复杂性导致了次优设计结果，整个系统的正确功能是如此的难于实现, 以 致于几乎没有时间去寻求一种替代方法，它可导致更坚固的、可扩展性更好的 和更具成本效益的解决方案。为了实现这样一种解决方案，设计师需要新的方 法，它可以将物理和逻辑设计流程紧密相连，并仍然允许不同的设计团队做他 们的工作。新兴的AUTOSAR标准为系统级汽车电子/电气设计方法学提供了一个技术上和经 济上都可行的选择，尽管它主要针对软件层面，即逻辑系统的
4、设计。不过，大 量广泛的 AUTOSAR 元模型及其丰富的接口定义允许系统级电子/电气架构师以标 准的格式表达他的设计思想。从经济上看，AUTOSAR标准打开了一个巨大的、 统一的市场，它使得可以创建合适的设计工具。本文描述了基于 AUTOSAR 的由点工具组成的系统级设计方法。这导致整个流程 在所有有意义的地方使用标准，但又不局限于标准，或要求用户采用这些标 准。AUTOSAR 工作原理AUTOSAR 标准是汽车制造商、供应商和工具供应商一起发起的，旨在规范汽车 电子控制单元(ECU)的开放式软件架构。AUTOSAR标准指定了一个分层软件架构，它明确定义了应用软件组件(SWC)之间 的接口、
5、用户可见汽车功能和基础设施组件的实现。它对基础设施组件进行了 严格的规定，以允许不同供应商开发的组件能一起工作。用户可见的汽车功能通过互连的应用软件组件来实现。SWC是可以映射到ECU 的最小单元。为了使SWC与特定的硬件无关，定义了虚拟功能总线(VFB)概念， 此处SWC就使用VFB与它们的环境进行通信。这一概念支持SWC重新定位到不同的ECU，从而增强了应用软件的可重用性。一个AUTOSAR系统基本上由以下三个XML文件定义：SWC描述、ECU资源描述和 系统配置描述。这些文件描述了一个逻辑架构的所有方面：SWC、功能网络、 拓扑和功能到ECU的映射。虽然这些文件的语法和语义由AUTOSA
6、R标准定义， 但它们的创建方法学则留给了工具供应商。用户案例分析下面两个代表性用户案例可以让你更深入地了解到总体物理和逻辑设计任务的 复杂性。在图2 显示的设计流程中，你可看到逻辑设计过程是如何驱动物理设计过程的。这一设计流程的第一步是汽车逻辑功能的定义和实现。大多数OEM将一部 汽车的电气系统分解成约 100-200个功能。用户创建能表达各种汽车功能的单 元级SWC,或从像Matlab/Simulink这样的模型设计工具中调用这类SWC。由于SWC的规范和开发在时间和地点上都是高度分散的，以及许多SWC从许多 不同的来源进入设计流程，因此应进行一致性检查，以尽早发现错误。即便只 有接口描述，
7、也已经可以进行内部组件之间的接口一致性静态检查。在设计流 程的这一点上，增加端到端的时序要求是重要的，以支持后面流程中要求时序 信息的先进分析工具。图2：用户案例1 逻辑设计驱动物理设计与此同时，可以创建一个有潜力的拓扑结构，它能勾画出分布式汽车网络的逻 辑拓扑结构，以及描述传感器、激励器和ECU的连接。通常情况下，一个汽车 项目开始于原有设计的重利用，然后对它进行修改。在重利用现有的ECU时， 非常详细的ECU信息可以来自企业数据库，或需要定义新的ECU,其技术特性 在开发过程中的特定期间是变化的。在以上两种情况下，功能信息和拓扑信息都可以提供给物理设计流程。物理设 计过程的功能级也需要EC
8、U上的数据（如总线系统使用的）。现在的物理设计需 要一个子系统设计步骤，在该步骤上，在物理组件映射到汽车上的封装空间（插 槽）之前，如ECU和保险丝盒这样的子系统需要做进一步的详细设计。除此之 外，在该步骤上，也可以开发出电源/接地概念。逻辑架构设计的对应步骤是SWC映射到ECU。这也决定了 SWC之间的通信方 案，即多个SWC是通过总线系统还是内部ECU进行通信。通信方法的选择对物理设计有直接的影响，这也增加了整个设计过程的复杂 性。例如，这取决于是否需要电线、常规电线、双绞线或双股双绞线。封装步骤之后是物理系统集成，此处， CAD 系统的信息用于添加额外的物理信 息，如所需的在线连接器和布
9、线通道。这反过来对设计的逻辑层面有影响，并再次增加了整个设计过程的复杂性。太 小的布线通道可能使得无法使用双股双绞线，或太长的电线长度可能使得将某 个SWC重定位到另一个ECU上成为一个更具成本效益的替代选择。当物理和逻辑流程都可以提供结果以后，它们的各种数据就可用来评估和优化 汽车架构。不过，由于流程的复杂性，很难找到一个以上行得通的架构。其结 果是，逻辑和物理设计师只能尝试优化其各自负责的设计部分。图3：用户案例2物理设计驱动逻辑设计图 3显示物理设计驱动逻辑设计的设计流程，逻辑拓扑是物理拓扑的衍生。与 前面的增加信息不同，这里不必要的信息需要被过滤。例如，在需要一个雪茄 打火机的物理设计
10、时，这一功能并不需要一个SWC描述，因此这一信息在逻辑 域中不需要。这两个例子只是反映了今天现有的设计流程挑战的一小部分，并 说明了整个流程的复杂性。物理和逻辑设计流程的集成改善这个内在复杂设计流程（多个设计小组在同一整体设计上同时工作）的一个 选择是，两个不同设计流程之间的紧密联系。在整个设计流程中，数据需要保持同步，但与此同时，工程师受到了这一同步 的太多阻碍。在目前的工作流程中，所有的人都共享相同的数据对象，而且在 使用它们之前必须对它们进行检查，一种替代工作流程是，针对两个不同的设 计流程，使用两个独立的数据库（见图 4），但找到一种办法可以在不带来大 量人力工作量情况下保持数据同步。
11、这需要这样的一个设计流程，大部分的设计实际上是自动生成，而不是手工生 成。在同步过程中数据库的变化将自动导致一次“综合”操作，从而完全避免 了重复以前努力的任务。图 4 ：并行处理物理和逻辑设计一个例子是网络配置的生成。当需要通过网络传输的信号发生变化时，设计师 可以手动输入这些变化，并手动运行所有必需的验证测试，这可以导致设计过 程的时间延长几个月。与此形成鲜明对比的是，各种通信数据可以自动基于通 信要求和数学算法生成，这可将完成设计流程所需的时间大幅减少到秒级。一个类似的物理设计例子是系统集成。当系统出现变化时（如不同的路由通 道），人工过程需要太多的时间，而且容易出错。通过使用一个自动生成的流 程，系统的变化可以通过流程或多或少地马上得到处理。例如，连接器的安装 位置改变和电线长度可以自动生成。在这里，工程师的 know-how 用于定义规 则，而不是应用这些规则。
