E/E系统架构开发指南-电子电器系统开发流程 E/E System Development

2020年2月21日网络架构评论11字数 8319阅读模式

作为一名合格的汽车电子电器架构工程师，了解完整的整车电子电器系统开发流程是很有必要的。今天微信上看到了一篇很好的文章，写的很好，在这里分享给大家。

“ 电子电器系统开发在整车开发当中所占比例越来越高，特别是平台化的快速推进，很多零部件的开发和验证都已经在平台上设计验证完成，所以整合和调教，软件配置升级等电子电器工作异常重要。文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

那么这个时候的整车项目开发其实主要依赖于电子电器软件配置更新标定等开发流程了，他的稳健和可靠开发决定了整个项目的成功与否，豪华汽车其实在本世纪初就开始了大量的电子电器化工作，所以本书的作者写的电子电器系统开发流程基本囊括了所有当代电子电器系统开发过程。对当前汽车电子化的开发管理具有很强的参考性。”文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

总体摘要：

传统的整车开发主要是设计和测试机械以及机电零件，但是在过去的二十年汽车已经变成了电子电器组成的复杂系统。电气系统和软件开发已经整和到整车开发流程当中，本章将对电子电器架构以及他们的开发流程进行解析。文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

1 从机械到电子电器系统 From Machinery to E/E Systems

1.1 一个全新而且不同的世界

大概在2000年左右，一些领先型的车企投产了包含很多电子电器配置的豪华汽车，但很多这样的汽车给客户和生产他的企业带来了惊讶和苦恼，因为偶然和不可预期的出现一些电子电器故障。很多在国际上享誉质量和可靠名誉的主机厂瞬间觉得很难去交付这些带有先进电子电器的汽车。文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

那到底发生了什么？当代的汽车几乎所有的功能都是被电子控制或者是关联的，随着越来越多的变种车型，这导致整个电子电器系统有量子性的飞跃，在一定程度上导致已经建立了几十年的以高效高质交付机械系统的整车开发流程不在适应当代复杂电子电器的整车开发，以下事实证明了这种转变事实：文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

当代汽车至少含有2500个软件控制功能，代表着背后有至少1000万条代码；
这些功能需要多达80个ECU（电子控制单元）去实现，通过多达5种不同种类的系统总线进行通信；
高达40%的车辆成本由电子和软件决定
90%的创新是通过电子和软件实现的
50-70%的电子控制单元开发成本与软件有关

未来，预计电子电器的硬件（例如ECU,传感器），操作系统和接口,将越来越标准化，甚至各个主机厂之间也出现标准化。不同品牌不同主机厂之间的差异甚至都可能由软件产生。文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

1.2 汽车电子电器系统

简单地说，电子车辆的功能总是由一个执行器来实现的，该执行器根据传感器产生的或人类用户给定的输入例如移动、加热、照明或显示一些东西，并由嵌入在ECU中的软件程序控制。因此，一个完整的车辆电子电器系统由所有载流的车辆部件组成，这些部件是：文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

传感器（例如轮速传感器）
输入设备（例如按钮，旋钮）
含有控制软件的ECU
执行机构（例如电机，灯光，加热）
显示屏和喇叭
数据和电力的线束（电线和插接件）
电池
发电机

在这些元器件当中，嵌入式软件越来越占主导角色。现在ECU 70%的成本与软件相关，2007款最高配的宝马7系大概有400万行的软件代码。文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

图用宝马7系用作例子展示了现代汽车电子电器的复杂性。文章源自线束工程师之家-https://www.suncve.com/e-e-system-development/

汽车电子电器系统可以用功能集群来区分-所以可以叫做汽车的域（Domain）。下面的清单表示域的结构广泛应用于汽车产业：

娱乐系统：是信息娱乐和交流的集合（例如，仪表盘，视频系统，天线调频，音频系统，导航，电话等），当然也包括娱乐系统的人机交互。

车身电器：例如权限管理，防盗系统中央车辆功能，车窗执行机构，尾门，座椅，雨刮或者驾驶舱内空气管理。

底盘和驾驶辅助：车辆动态安全相关例如ABS,ESP,ASC,DSC。

动力系统：所有控制动力转换成驱动力的功能，例如发动机电控，变速箱标定，油泵，OBD等等。

被动安全：防撞或者伤害转移等功能，例如，安全带预紧，安全气囊等等

当然自动驾驶时代，围绕着自动驾驶的域也产生了，不过他基本是集合了底盘驾驶辅助和安全相关功能。

属于同一个域（domain）的零部件通过总线交互数据。理想条件下，电子电器开发的功能组织结构遵循技术（domain）域结构，即使在某些情况下，域（domain）结构代表功能组织结构。

子系统包括完成一个或多个特定功能所需的所有零部件。这可以从只有几个零部件到几乎整个系统。作为示例，下图展示出了车辆访问控制子系统的组件。

与数据网络并行，电子电器系统还需要一个供电网络，为所有电力负荷提供所需的12 V DC标准电源（点火和电驱动电机除外）。

2 系统工程流程 Systems Engineering Processes

2.1 文化冲突

当考虑到上一代车辆出现上述汽车电子电器系统质量问题的原因时，有人认为，主机厂和供应商的开发过程跟不上日益增加的产品复杂性的一个主要原因实际上是“旧生态”和“新生态”之间的文化冲突。

毫无疑问，汽车开发植根于传统工程，开发中心盛行的文化主要由“汽车人”（大多具有机械、电气或控制工程背景）和他们对产品开发应如何工作的想法所主导。

但随着汽车电子控制功能在过去二十多年里的迅速增加，不同种类的专家几乎都有了不寻常的发展中心：

计算机科学家和软件工程师，他们大多来自非汽车公司甚至非工业公司，除了穿着不同的衣服，过着不同的生活方式——其实这实际上就开始使个人层面上的整合变得困难——对产品开发、整车整合或质量和可靠性，有着不同的想法（和需求）。

比尔盖茨和通用汽车（General Motors）董事长之间著名但虚构的争论很好地说明了这种不利的理解。

盖茨在这场争论中抱怨，与软件开发相比，汽车开发的效率低下。

作为反击，通用汽车（GM）董事长描绘了车主将经历的一切，如果这辆车符合微软软件同样的质量和可靠性标准。虽然开发底盘或车身部件的工程师始终通过几何集成进行检查，以确保整车在几何上保持一致，但软件工程师或多或少地是相互独立工作的，没有对整个系统的功能集成进行严格的过程。如果对旨在修复或改进某些功能的程序的自发更改导致了其他地方无法跟踪的故障，这会使整个车辆级别的问题分析成为一个几乎是徒劳的挑战。

2.2 系统工程

在这种情况下，主机厂将系统工程作为开发可靠电子电器系统的可持续方法，作为产品开发流程的一部分。

国际系统工程理事会（INCOSE）将系统工程定义为一种跨学科的手段，通过以此按照早期关注客户需求、记录需求、设计合成和系统验证，同时考虑所提出问题的所有方面，从而实现成功的系统。下图中的V型模型列出了系统工程（engineering）过程的主要元素，细节将在后续讨论。

2.3 需求工程

所有关于系统开发项目失败原因的研究都将客户需求的不完全澄清列为首要原因之一。

对需求的结构化收集和分析以及在项目过程中保持需求最新的管理过程是成功实现系统必不可少的基本前提。需求工程遵循四个步骤：提取、分析、规范和确认。

2.3.1 需求提取

作为需求提取过程的基本原则，必须确保从一开始就包括所有相关利益相关者的需求。

因此，需求获取的第一步是确定系统的相关利益相关者。涉众不仅包括操作系统的所有不同类型的直接客户（主要客户），还包括生命周期中的所有间接或次要客户（开发、制造、部署、支持、处置、培训，以及验证）他们对系统有各自的且常常相互冲突的要求。

第二步是从确定的人类利益相关者那里收集具体需求。在这里，主要的挑战是将干系人的不同语言和概念模型中的需求转换成一个统一的描述，这需要系统工程师对相关人的世界观有敏感和良好的理解。典型的引出方法包括：

相关方的采访
相关方的观察
测试和评论系统原型的可用性
现有系统的测试

2.3.2 需求分析

虽然需求提取的结果或多或少是一个未经调整的想法、希望和愿望的原始集合，但是需求分析步骤的结果是系统应该能够执行的功能的清单，包括系统应该能够执行这些功能的程度，以及所有与此相关的问题的解决：

可能的冲突
环境的交互
完成度
模糊度

需求的第一个分类通常是在功能性需求和非功能性需求之间，根据各自相关者的类型进行的。

功能需求从用户（主要客户）的角度描述未来系统的功能。非功能性需求不直接支持与客户相关的功能，但仍必须由系统满足。下表列出了可折叠车顶电子控制单元的示例要求：

为了作为未来车辆的坚实基础，系统要求必须满足不同的质量标准。它们必须是：

可实现的
可验证的
不模糊的
完整的
表达需求不是情况
需求必须一致性
适用于系统层次结构级别

2.3.3 需求的归档和确认

最终，所有的需求必须归档到一个正式需求归档文件，该文件可以系统地评审、评估和批准，并作为接下来系统设计的约束性基础。

文档的典型形式是user case 使用案例（系统如何响应外部请求的规范）或过程规范。

IT工具用来支持需求管理（如来自Telelogic/IBM的DOORS）通常使用数据库系统，该系统不仅允许结构化文档，而且还允许属性和需求链接，并提供与一般办公应用程序的接口。

2.4 系统架构和设计

系统设计从创建从指定需求自上而向下派生的体系结构开始。虽然需求规范描述了车辆电子电器系统应该做什么，但系统架构描述了系统应该如何做——无论是在逻辑/功能层面还是在技术层面。由于它定义了，车辆与通常由供应商开发和制造的零部件接口，因此系统架构的创建是主机厂或高度专业化的开发合作伙伴的核心能力。

2.4.1 逻辑系统架构

系统级需求分解为子功能，子功能及其内部和外部接口表示逻辑系统架构。

虽然内部接口描述了不同子系统之间所需的通信线路，但外部接口描述了来自系统环境的输入和输出，特别是驾驶员和乘客。

逻辑系统体系结构由一个框图表示，其中每个子功能由一个框图表示。例如，下图示出了宝马夜视系统的逻辑框图。

2.4.2 技术系统架构

划分过程

在下一步，即所谓的划分过程中，逻辑系统架构的功能被映射到技术系统架构的可实现元素（下图）：不同的ECU、传感器、执行器、总线系统（硬件架构）和应用程序（软件架构）。

软件元素（应用程序）到不同硬件元素（ecu）的映射称为部署。移动互联网连接性能的不断提高使得特定的车辆功能越来越多地被划分到车辆外部的计算机上，即所谓的后端。在这种情况下，车辆实际运行的是web应用程序（例如，导航系统的基于internet的路线规划算法），而不是车载软件。

为了在早期阶段优化系统，将根据以下条件创建替代分区并对其进行评级：

需求的满足程度
技术风险
开发风险
过程风险
系统性能
组织
兼容性
寿命

最终，最优的评级最高的划分选定用于开发。

总线系统

在将功能分配到特定硬件和软件组件的同时，技术系统结构的创建还包括用于ECU间通信的外部总线系统的规范。

总线系统由协议、载波（如电缆）的技术特性和不同ECU互连所依据的拓扑结构来指定。哪种总线系统最合适取决于域对数据传输的速度、容量和可靠性的普遍要求：

娱乐系统：多媒体系统需要很高的传输速度（例如视频）但他对于可靠度来讲却相对低所以典型的总线适合于他的是 MOST以及以太网。
车身电子：他需要高可靠度（例如车辆权限和雨刮）但速度要求不高所以一般选择低速CAN
底盘和驾驶辅助：一般他需要高可靠度同时快响应所以一般选择高速CAN。
动力系统：他要求和底盘和驾驶辅助相同所以一般也是高速CAN
被动安全：非常高的可靠性和快速响应所以需要TT CAN, byteflight或者FlexRay。

以宝马7 2007款为例，下图表示不同的domain采用的总线规格。

下图显示了同一辆车的完整技术系统架构。连接独立车辆域组件的总线通过中央网关模块相互连接，中央网关模块还通过无线连接控制与非车载计算机的连接和数据存储不仅技术系统架构必须代表一个有效的电子/电子系统，还必须集成到整车开发中，例如布置和几何集成，生产集成，或服务集成。

系统架构设计的不同步骤由多种方法和IT工具支持。功能网作为逻辑系统体系结构的标准表示，在UML-RT中进行建模，已经成为各种IT工具使用的准标准建模技术（如IBM的Rational Rose）。

2.5 零部件开发

2.5.1 ECU硬件和嵌入式软件

在E/E系统开发中，零部件的开发表示不同ECU和其他E/E元件（传感器、执行器等）的设计以及由此产生的子系统的验证。电子控制单元的主要部件是：

微型控制器，一个功能性的芯片电脑包括了CPU,内存，缓存和输入和输出等；
ECU基本软件，包括操作系统、内部和外部数据通信、网络管理等，如根据OSEK/ISO 17356；
应用软件：控制和执行所需功能的程序。
中间件，允许应用程序使用独立于数据总线系统和操作系统的公共API（应用程序编程接口）。
机械元件：印刷电路板（PCB）、外壳、防护、终端插座等。

中间件是不同款式、主机厂/或供应商之间软件和硬件零部件可交换性的关键先决条件。

在这里，AUTOSAR运行时环境已经成为汽车行业的标准。通过指定接口及其通信机制，应用程序与底层硬件和基本软件分离，从而实现标准库功能。下图显示了AUTOSAR ECU软件体系结构。

电子控制单元硬件的设计包括所需电子部件的尺寸和选择、电路设计、印刷电路板布局、所需接口的规格和位置以及适当的部件外壳的设计。

2.5.2 应用软件设计

电子电器零部件设计的核心过程是应用软件的生成，它定义了构件的行为。作为第一步，创建一个函数模型，指定所需的数学函数、算法和组件接口（输入和输出）。

IT工具包（例如Math Works的Matlab或ETAS的ASCET）为功能建模提供全面支持，MIL（model in-loop）和SIL（software in-loop）模拟（其中模拟了完整的硬件环境）和问题分析，直至生成应用软件的C代码（编译成汇编代码）。

然后，在应用过程中，设置软件的参数（如发动机和变速箱类型作为发动机控制器软件的参数）。该应用数据、汇编程序和诊断所需的附加数据随后链接到二进制程序文件，然后在控制器EEPROM中闪存（“嵌入”）。

2.5.3 零部件测试

电子电器组件设计的下一步是使用嵌入式应用软件测试ECU。为了允许ECU及其外围组件的并行开发，这些测试在HIL（硬件在环）测试台上进行，该测试台电子模拟ECU的接口（传感器和执行器）。仪表板的HIL模拟平台（如图5.9所示）模拟所有传感器，这些传感器提供显示信息所需的数据（如发动机转速、车速、燃油油位等）。

2.6 系统集成以及验证

系统集成是指在物理上和功能上将各个（内部或外部）设计零部件功能组开发的部件组合成一个完整的车辆系统，并确保该系统实现所需的功能。

在整车开发流程中，在每个样车阶段之前，执行一个正式的系统集成过程以确保各自车辆的功能。

在该过程开始时，设计零部件功能组希望成为车辆E/E系统一部分的每个组件必须注册以进行系统集成。在通过设计零部件功能组的资格预审并移交给系统集成部门后，各部件在系统集成过程中受到严格的变更控制，在系统集成过程中，将其作为子系统或整车系统的一部分进行评估。

2.6.1 子系统集成

在子系统测试台上，完成某一功能所需的所有部件都由相应的总线系统连接。为了创建被测子系统的真实行为，将模拟不属于子系统的组件。

子系统级测试包括用户和系统功能，例如机械、化学或大气应变、静态电流、电磁兼容性等。例如，下图显示了车灯系统的子系统测试台。

子系统测试包括:

编码
刷写
诊断
总线故障诊断
睡眠和唤醒测试
选定的用户/客户功能

发现问题及时反馈给子系统设计零部件功能组知道最后测试通过。

2.6.2 电子电器整车集成

在子系统分别建立、测试和验证之后，它们被继续集成，以创建完整的车辆E/E系统。不同的子系统在物理和功能上连接在一起，以测试它们的正确交互和系统级功能的实现。作为第一步，车辆的所有E/E部件都连接在一个固定的试验车内（见xiatu ），在试验车内对系统功能和非驾驶客户功能进行评估。

静态电子电器样车测试包括：

固定所有连接线束
总线物理连接
通电/断电
电压测试
测试客户功能
睡眠电流
24小时测试
总线负载测试
误用测试
网关测试
编码
刷写
诊断测试

一辆固定的实验车包括大约80%的整车E/E系统。为了从内部和外部客户的角度对整个系统进行评估，必须对来自各个样车的完整车辆进行调查。

这些所谓的动态实验室车辆配备有综合测量设备（见下图），记录所有数据总线流量，从而允许跟踪电子故障和验证动态E/E功能，如发动机控制、变速箱控制或底盘控制系统。同样，检测到的问题由设计零部件系统功能组修复。

在系统工程（engineering）过程结束时，系统集成将发布一个已定义和验证的整车E/E系统配置，即所谓的集成级别（见下文）。

2.7 支持管理过程

除了已经讨论过的技术开发过程外，电子电器开发管理过程非常重要的支持确保电子电器开发符合客户需求。除了一般的项目管理，两个主要的支持管理过程是配置管理和风险管理。

2.7.1 配置管理

就像几何集成一样，在硬件构建组之前，确保整车设计的几何一致性，系统集成将确保有效的E/E系统配置——车辆所有硬件和软件的功能一致的集合。

因此，根据前文所示的V模型的系统工程过程在车辆项目的硬件构建阶段的每个阶段之前被重复（参见图下图）。

在这里，配置管理的任务是构造、标记、记录和控制软硬件组件的所有版本和变体以及由它们组成的所有有效系统配置。

对软件或硬件工件的更改不能临时进行，而是由变更控制委员会（CCB）控制，CCB评估变更请求并分析其对整个系统的潜在好处和风险。

为了在硬件车辆中实现所需的E/E功能，配置管理还将有效的系统配置映射到相应的车辆变型（例如发动机变型、特定于国家/地区的变型、选项等），并确保车辆中仅内置最新的经验证配置。

下图显示了一个车辆项目的配置规划。第一个样车阶段（灰色）的第一辆车的系统配置表示为集成级别I200，随后的更新表示为I210、I220等。类似地，第二个样车阶段（蓝色）的集成级别称为I3xx，对于量产验证车辆（黄色）I4xx和销售给客户的系列车辆（绿色）I5xx。

2.7.2风险管理

在每一个车辆项目中，在E/E系统开发过程中总会发生许多事情，这些事情会对系统目标的计划实现和质量、进度或成本方面的性能产生负面影响。独立于工程师和管理者是否意识到他们，承认他们或计划他们，这些风险存在，知道他们是一个机会，以避免可能产生的问题。

风险的先决条件是未来的根本原因，如果消除或纠正了这些根本原因，将防止潜在的负面后果发生。因此，指定风险的两个参数是：

未来问题发生的可能性
问题产生的后果

风险管理支持系统工程开发包括以下四个主要方面：

目标、活动、资源确认、沟通等的策划。
风险识别和定量评估。风险可能与E/E系统本身（包括上游外部系统）有关，也可能与系统开发过程及其外部影响有关。
风险缓解或消除措施的实施。这包括风险规避（例如，通过系统性能的交易风险）、通过系统设计措施将风险降低到可接受的水平、接受E/E系统开发风险，或将风险从一个系统区域转移到另一个系统区域（例如从软件转移到硬件）。
监测、记录和报告所采取的措施，从而确保成功地缓解风险，重新评估风险状况，并与管理层沟通。

下图说明了风险管理的四个要素是如何相互联系的。

2.8 能力成熟度模型集成-Capability Maturity Model Integration

作为整车开发流程的一部分，车辆电子/电子系统的成功开发（按时并在预算内）在很大程度上取决于既定系统开发过程的质量。

能力成熟度模型集成（Capability Maturity Model Integration，CMMI）是卡内基梅隆软件工程研究所（Carnegie Mellon Software Engineering Institute，SEI）开发的一组过程模型，为有效组织软件或系统工程过程提供目标（经验证的最佳实践）。

这些目标由22个过程领域（见下表）规定，这些领域是相关实践的集群，在集体实施时，满足一组被认为对该领域的改进很重要的目标。过程区域被分为四类。

在过程评估和改进方面，CMMI方法提供了两种不同的方法：一种评估组织成熟度的阶段性表示方法，一种在不同的过程领域对组织能力的持续表示方法。