汽车电子电气架构正向开发流程

智能汽车电子与软件 2024-10-25 15:22 1136浏览 0评论 0点赞

【直播】零成本升级IC验证效能 UCIe 2.0协议“死磕指南”！Avery VIP如何实现0缺陷互连？

关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯

国外的OEM在多年的Know-how积累下，其在规划新一代电子电气架构平台时，基本完全按照正向的流程来开发，例如VW的MEB E3架构，Volvo的SPA2等，伴随其正向电子电气架构开发的需要，诞生了强大的工具供应商，比如Vector的PREEvision，其囊括了电子电气开发的整个流程，从需求分析、逻辑功能架构、软件架构、硬件架构到电气原理设计、线束原理设计、几何拓扑设计以及线束2D图纸设计，同时包含通讯设计、功能安全开发、变形管理等，提供了电子电气开发的集成平台，需求工程师、功能工程师、软件工程师，通信工程师、架构工程师、电气工程师、功能安全工程师可以在这个平台彼此协作开发，数据无缝传递，每个专业的输入可通过上游设计的输出数据重构生成，数据可在全流程追溯，在应对目前电子电气的复杂性上确实具有领先性。

下面以PREEvision为例来简单介绍下电子电气架构的正向开发流程是什么样的：

1、需求工程和需求管理

在电子电气架构开发的概念阶段，我们需要明确开发的目标及范围，需要收集客户对车辆的功能需求、法规需求以及其他非功能需求，在这个阶段涉及两个重要的概念：

lCustomer Feature：在高层级描述车辆的特征，通常是客户可以感知的功能，比如自动空调，自动启停，自动泊车、自适应巡航等，

lRequirements:需求Requirement 是对Customer Feature的进一步细化，包括功能需求，技术需求（工作温度范围等），法规需求（排放法规等）；

同时可以将Requirement和Customer Feature进行映射关联，从而实现追溯，另外Customer Feature和Requirement在向下映射过程也是有差别的，Customer Feature通常和逻辑架构层（Logical Function Architecture）的元素(Activity Chain)进行映射,而Requirement通常和软件架构层（Software Architecture）的元素以及硬件架构层（Harware Architecture）的元素进行映射。

2、逻辑功能架构（Logical Function Archtecture）

逻辑功能架构设计阶段，就是根据需求阶段定义的Customer Feature，为每一个Feature设计功能的实现逻辑，设计的Activity Chain提供了一个功能的抽象视图，只从功能实现的角度划分Sensor（Input）、Logical Function(Process)、Actuator（Output），并不关心具体的软件实现、以及硬件实现，在该阶段设计完成的逻辑组件（Logical Component）会分配到硬件架构中的组件（ECU、传感器、执行器等）以及软件架构中组件（Application Software Component等）。

3、软件架构（Software Architecture）

在汽车行业嵌入式软件开发领域绕不开AUTOSAR（Automotive Open System Architecture）,其定义了一套分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准方案，AUTOSAR的核心思想“统一标准、分散实现、集成配置”，即提供统一、开放的软件架构标准和平台，软件构建在不同的汽车平台上复用，应用软件整合到ECU 中，建立独立于硬件的、分层的软件架构，针对AUTOSAR Classic的系统和软件架构设计在PREEvision中可以分为如下步骤：

同时，在目前SDV趋势下，PREEvision同时支持面向服务的架构设计（SOA）以及Adaptive AutoSAR系统和软架构设计，并提供SOA&Ethernet Explorer（Classic Platform）和Adaptive AutoSAR Explorer（Adaptive Platform）支持新的设计需求。

4、硬件架构（Hardware Architecture）

硬件架构的设计分为三层：硬件组件（Hardware components）和网络拓扑（Network topology），电气原理和线束原理，

l硬件组件（Hardware Component）架构，设计硬件组件（例如ECU、传感器、执行器）之间的硬线连接，包括硬线信号（PWM、高低电平等），总线连接（CANFD/CAN/LIN等），以及电源连接和接地连接，另外也设计ECU内部的细节，比如MCU、SBC、RAM等；

l网络拓扑（Network Topology）

l电气原理（Electric Circuit）,电气原理层将硬件架构层的数据进行重构，重新定义硬件组件之间的连接，并关注与线束设计相关的电气属性，例如电源供应、接地连接等，其可设计电源分配的保险、继电器以及接地分配电路。

l线束原理（Wiring Harness）将电气原理数据进行细化，将逻辑连接转换为导线，同时添加导线之间的焊接点（Splice），内部连接器（Inline），端子（Terminal），线束端连接器（Female Connector）,

5、几何拓扑（Geometric Topology）

几何拓扑层是整车电器的2.5D布局视图，其可以通过将3D CAD工具（Dassault Catia等）设计完成的3D线束通过KBL格式导入，展平为2D视图，表达各电器的安装位置，线束分段，然后将线束原理层中各组件映射到几何拓扑层，从而进行导线的路由规划，从而为最终的架构评估提供线束的长度、重量等数据支撑。

6、线束设计（Harness Design）

将几何拓扑中完成导线路由的线束总成，在Wire Harness Diagram中进行数据重构，同时添加卡扣、胶带以及其他固定件、防护件，可生成线束2D图纸，指导线束供应商进行线束的工艺转化，然后进行线束的生产和制造。

7、通讯设计（Communication）

在完成软件组件到硬件的Mapping后，可进行信号的路由，并进行网络通讯设计，PREEvision提供了多种通信设计编辑器来应对同步的通信类型，比如CAN Bus Editor,LIN Scheduling Editor,FlexRay Schedulling 和Ethernet Explorer。

上述基于模型的系统工程方法（MBSE）同时可导出文档，作为供应商开发的输入，比如可导出ECU的软件需求规范SWRS（Software Requirement Specification）用于指导供应商进行软件设计，导出ARXML文件用于供应商生成应用层软件框架代码，生成DBC/LDF文件用于总线仿真及测试等。

国内OEM的电子电气架构开发过程

而国内OEM通常采用基于文档的电子电气架构的开发流程，基于模型的正向开发流程通常很难真正的实施下去的，因为在过去几十年分布式架构下形成的OEM、Tier1的产业供应链是很固化的，目前市面上车型搭载的ECU大部分都是由国外头部Tier1在供应，特别是在底盘、动力领域，ESP、Ibooster、ECM这些零部件的核心Know-how都掌握在Bosch、Continental、APTIV等掌握在这些零部件巨头手里，国内OEM的电子电气架构团队自己的积累太少，并不能在此领域提出足够支配供应商的需求，另外这些供应商开发的零部件基本是平台化的，相同的零件应用在多家主机厂的车型上，收发信号都是定义好OEM根据需求信号进行匹配，因此我们的架构团队写的功能规范（子系统功能规范），迫于无奈要根据零部件实际的功能情况去更改适配，架构输出规范的作用更多的是梳理目前整车已有的功能，而不是去正向设计整车的功能，但是近些年我们国内的OEM也在一直成长，并尝试建立正向的电子电子电气架构开发流程：

l在需求阶段进行市场调研、法规标准分析、竞品分析、新技术分析、基础平台分析，定义整车架构目标，输出Function List，并针对每个功能编制功能需求规范FRS（Function Requirement Spefication）,进行功能描述，场景定义，功能系统框图设计等；

l在功能实现阶段，把功能需求分解并分配给子系统设计团队（功能需求+子系统交互图）；

l在子系统设计阶段，输出子系统需求描述SRD（System Requirement Description）

l在零部件设计阶段输出零部件技术规范CTS（Component Technical Spefication）

通过上述规范的输出，国内OEM掌握的Know-how也越来越多，并在新一代电子电气架构中，逐渐掌握主动权，不管是Domain架构还是Zonal架构，要实现SOA是大家达成的共识，同时在新的面向服务的架构中，主机厂要掌握车端、和云端可以提供的服务，并将服务开放给第三方应用开发者，从而创建SOA的开发生态，因此作为主机厂的电子电气架构团队在新的SOA趋势下，其作用显得越来越重要，其要从整车功能需求来设计整车的服务，并将服务分配到不同的Domain，由不同Domain的应用软件开发团队来实现。

来源:商用车诊断仪

-END-