|
“ 电子电器系统开发在整车开发当中所占比例越来越高，特别是平台化的快速推进，很多零部件的开发和验证都已经在平台上设计验证完成，所以整合和调教，软件配置升级等电子电器工作异常重要，那么这个时候的整车项目开发其实主要依赖于电子电器软件配置更新标定等开发流程了，他的稳健和可靠开发决定了整个项目的成功与否，豪华汽车其实在本世纪初就开始了大量的电子电器化工作，所以本书的作者写的电子电器系统开发流程基本囊括了所有当代电子电器系统开发过程。对当前汽车电子化的开发管理具有很强的参考性。” 摘要： 传统的整车开发主要是设计和测试机械以及机电零件，但是在过去的二十年汽车已经变成了电子电器组成的复杂系统。电气系统和软件开发已经整车和到整车开发流程当中，本章将对电子电器架构以及他们的开发流程进行解析。 5.1 — 从机械到电子电器系统 From Machinery to E/E Systems 5.1.1 一个全新而且不同的世界 大概在2000年左右，一些领先型的车企投产了包含很多电子电器配置的豪华汽车，但很多这样的汽车给客户和生产他的企业带来了惊讶和苦恼-因为偶然和不可预期的出现一些电子电器故障。很多在国际上享誉质量和可靠名誉的主机厂瞬间觉得很难去交付这些带有先进电子电器的汽车。 那到底发生了什么？当代的汽车几乎所有的功能都是被电子控制或者是关联的，随着越来越多的变种车型，这导致整个电子电器系统有量子性的飞跃，在一定程度上导致已经建立了几十年的以高效高质交付机械系统的整车开发流程不在适应当代复杂电子电器的整车开发，以下事实证明了这种转变事实：
未来，预计电子电器的硬件（例如ECU,传感器），操作系统和接口（详情见5.2.5.1）将越来越标准化，甚至各个主机厂之间也出现标准化。不同品牌不同主机厂之间的差异甚至都可能由软件产生。 5.1.2 汽车电子电器系统 简单地说，电子车辆的功能总是由一个执行器来实现的，该执行器根据传感器产生的或人类用户给定的输入例如移动、加热、照明或显示一些东西，并由嵌入在ECU中的软件程序控制。因此，一个完整的车辆电子电器系统由所有载流的车辆部件组成，这些部件是：
在这些元器件当中，嵌入式软件越来越占主导角色。现在ECU 70%的成本与软件相关，2007款最高配的宝马7系大概有400万行的软件代码。 图5.1用宝马7系用作例子展示了现代汽车电子电器的复杂性。 汽车电子电器系统可以用功能集群来区分-所以可以叫做汽车的域（Domain）。下面的清单表示域的结构广泛应用于汽车产业：
当然自动驾驶时代，围绕着自动驾驶的域也产生了，不过他基本是集合了底盘驾驶辅助和安全相关功能。 属于同一个域（domain）的零部件通过总线交互数据。理想条件下，电子电器开发的功能组织结构遵循技术（domain）域结构，即使在某些情况下，域（domain）结构代表功能组织结构。 子系统包括完成一个或多个特定功能所需的所有零部件。这可以从只有几个零部件到几乎整个系统。作为示例，图5.2示出了车辆访问控制子系统的组件。 与数据网络并行，电子电器系统还需要一个供电网络，为所有电力负荷提供所需的12 V DC标准电源（点火和电驱动电机除外）。 5.2 — 系统工程流程 Systems Engineering Processes 5.2.1 文化冲突 当考虑到上一代车辆出现上述汽车电子电器系统质量问题的原因时，有人认为，主机厂和供应商的开发过程跟不上日益增加的产品复杂性的一个主要原因实际上是“旧生态”和“新生态”之间的文化冲突。 毫无疑问，汽车开发植根于传统工程，开发中心盛行的文化主要由“汽车人”（大多具有机械、电气或控制工程背景）和他们对产品开发应如何工作的想法所主导。但随着汽车电子控制功能在过二十多年里的迅速增加，不同种类的专家几乎都有了不寻常的发展中心：计算机科学家和软件工程师，他们大多来自非汽车公司甚至非工业公司，除了穿着不同的衣服，过着不同的生活方式——其实这实际上就开始使个人层面上的整合变得困难——对产品开发、整车整合或质量和可靠性（见7.917.9.1关于可靠性的不同定义）有着不同的想法（和需求）.比尔盖茨和通用汽车（General Motors）董事长之间著名但虚构的争论很好地说明了这种不利的理解，盖茨在这场争论中抱怨，与软件开发相比，汽车开发的效率低下，作为反击，通用汽车（GM）董事长描绘了车主将经历的一切，如果这辆车符合微软软件同样的质量和可靠性标准。虽然开发底盘或车身部件的工程师始终通过几何集成进行检查，以确保整车在几何上保持一致，但软件工程师或多或少地是相互独立工作的，没有对整个系统的功能集成进行严格的过程。如果对旨在修复或改进某些功能的程序的自发更改导致了其他地方无法跟踪的故障，这会使整个车辆级别的问题分析成为一个几乎是徒劳的挑战。 5.2.2 系统工程 在这种情况下，主机厂将系统工程作为开发可靠电子电器系统的可持续方法，作为产品开发流程的一部分。国际系统工程理事会（INCOSE）将系统工程定义为一种跨学科的手段，通过以此按照早期关注客户需求、记录需求、设计合成和系统验证，同时考虑所提出问题的所有方面，从而实现成功的系统。图5.3中的V型模型列出了系统工程（engineering）过程的主要元素，细节将在后续讨论。 5.2.3 需求工程 所有关于系统开发项目失败原因的研究都将客户需求的不完全澄清列为首要原因之一。对需求的结构化收集和分析以及在项目过程中保持需求最新的管理过程是成功实现系统必不可少的基本前提。需求工程遵循四个步骤：提取、分析、规范和确认。 5.2.3.1 需求提取 作为需求提取过程的基本原则，必须确保从一开始就包括所有相关利益相关者的需求。因此，需求获取的第一步是确定系统的相关利益相关者。涉众不仅包括操作系统的所有不同类型的直接客户（主要客户），还包括生命周期中的所有间接或次要客户（开发、制造、部署、支持、处置、培训，以及验证）他们对系统有各自的且常常相互冲突的要求。 第二步是从确定的人类利益相关者那里收集具体需求。在这里，主要的挑战是将干系人的不同语言和概念模型中的需求转换成一个统一的描述，这需要系统工程师对相关人的世界观有敏感和良好的理解。典型的引出方法包括：
5.2.3.2 需求分析 虽然需求提取的结果或多或少是一个未经调整的想法、希望和愿望的原始集合，但是需求分析步骤的结果是系统应该能够执行的功能的清单，包括系统应该能够执行这些功能的程度，以及所有与此相关的问题的解决：
需求的第一个分类通常是在功能性需求和非功能性需求之间，根据各自相关者的类型进行的。功能需求从用户（主要客户）的角度描述未来系统的功能。非功能性需求不直接支持与客户相关的功能，但仍必须由系统满足。表5.1列出了可折叠车顶电子控制单元的示例要求： 为了作为未来车辆的坚实基础，系统要求必须满足不同的质量标准。它们必须是：
5.2.3.3 需求的归档和确认 最终，所有的需求必须归档到一个正式需求归档文件，该文件可以系统地评审、评估和批准，并作为接下来系统设计的约束性基础。文档的典型形式是user case 使用案例（系统如何响应外部请求的规范）或过程规范。IT工具用来支持需求管理（如来自Telelogic/IBM的DOORS）通常使用数据库系统，该系统不仅允许结构化文档，而且还允许属性和需求链接，并提供与一般办公应用程序的接口。 5.2.4 系统架构和设计 系统设计从创建从指定需求自上而向下派生的体系结构开始。虽然需求规范描述了车辆电子电器系统应该做什么，但系统架构描述了系统应该如何做——无论是在逻辑/功能层面还是在技术层面。由于它定义了车辆与通常由供应商开发和制造的零部件接口，因此系统架构的创建是主机厂或高度专业化的开发合作伙伴的核心能力。 5.2.4.1 逻辑系统架构 系统级需求分解为子功能，子功能及其内部和外部接口表示逻辑系统架构。虽然内部接口描述了不同子系统之间所需的通信线路，但外部接口描述了来自系统环境的输入和输出，特别是驾驶员和乘客。逻辑系统体系结构由一个框图表示，其中每个子功能由一个框图表示。例如，图5.4示出了宝马夜视系统的这种框图。 5.2.4.2 技术系统架构 划分 在下一步，即所谓的划分过程中，逻辑系统架构的功能被映射到技术系统架构的可实现元素（见图5.5）：不同的ECU、传感器、执行器、总线系统（硬件架构）和应用程序（软件架构）。软件元素（应用程序）到不同硬件元素（ecu）的映射称为部署。移动互联网连接性能的不断提高使得特定的车辆功能越来越多地被划分到车辆外部的计算机上，即所谓的后端。在这种情况下，车辆实际运行的是web应用程序（例如，导航系统的基于internet的路线规划算法），而不是车载软件。 为了在早期阶段优化系统，将根据以下条件创建替代分区并对其进行评级：
最终，最优的评级最高的划分选定用于开发。 总线系统 在将功能分配到特定硬件和软件组件的同时，技术系统结构的创建还包括用于ECU间通信的外部总线系统的规范。总线系统由协议、载波（如电缆）的技术特性和不同ECU互连所依据的拓扑结构来指定。哪种总线系统最合适取决于域对数据传输的速度、容量和可靠性的普遍要求：
以宝马7 2007款为例，下图表示不同的domain采用的总线规格
图5.6显示了同一辆车的完整技术系统架构。连接独立车辆域组件的总线通过中央网关模块相互连接，中央网关模块还通过无线连接控制与非车载计算机的连接和数据存储
不仅技术系统架构必须代表一个有效的电子/电子系统，还必须集成到整车开发中，例如布置（见3.2）和几何集成（见4.2），生产集成（见8.1），或服务集成（见8.2条）。 系统架构设计的不同步骤由多种方法和IT工具支持。功能网作为逻辑系统体系结构的标准表示，在UML-RT中进行建模，已经成为各种IT工具使用的准标准建模技术（如IBM的Rational Rose）。 5.2.5 零部件开发 5.2.5.1 ECU硬件和嵌入式软件 在E/E系统开发中，零部件的开发表示不同ECU和其他E/E元件（传感器、执行器等）的设计以及由此产生的子系统的验证。电子控制单元的主要部件是：
中间件是不同款式、主机厂/或供应商之间软件和硬件零部件可交换性的关键先决条件。在这里，AUTOSAR运行时环境已经成为汽车行业的标准。通过指定接口及其通信机制，应用程序与底层硬件和基本软件分离，从而实现标准库功能[6]。图5.7显示了AUTOSAR ECU软件体系结构。
5.2.5.2 应用软件设计 电子电器零部件设计的核心过程是应用软件的生成，它定义了构件的行为。作为第一步，创建一个函数模型，指定所需的数学函数、算法和组件接口（输入和输出）。IT工具包（例如Math Works的Matlab或ETAS的ASCET）为功能建模提供全面支持，MIL（model in-loop）和SIL（software in-loop）模拟（其中模拟了完整的硬件环境）和问题分析，直至生成应用软件的C代码（编译成汇编代码）。 然后，在应用过程中，设置软件的参数（如发动机和变速箱类型作为发动机控制器软件的参数）。该应用数据、汇编程序和诊断所需的附加数据随后链接到二进制程序文件，然后在控制器EEPROM中闪存（“嵌入”）。 5.2.5.3 零部件测试 电子电器组件设计的下一步是使用嵌入式应用软件测试ECU。为了允许ECU及其外围组件的并行开发，这些测试在HIL（硬件在环）测试台上进行，该测试台电子模拟ECU的接口（传感器和执行器）。仪表板的HIL模拟平台（如图5.9所示）模拟所有传感器，这些传感器提供显示信息所需的数据（如发动机转速、车速、燃油油位等）。
5.2.6 系统集成以及验证 系统集成是指在物理上和功能上将各个（内部或外部）设计 零部件功能组开发的部件组合成一个完整的车辆系统，并确保该系统实现所需的功能。在整车开发流程中，在每个样车阶段（样车1阶段、样车2阶段、预批量生产等）之前，执行一个正式的系统集成过程（见图5.10）和3.3）以确保各自车辆的功能。
在该过程开始时，设计零部件功能组希望成为车辆E/E系统一部分的每个组件必须注册以进行系统集成。在通过设计零部件功能组的资格预审并移交给系统集成部门后，各部件在系统集成过程中受到严格的变更控制，在系统集成过程中，将其作为子系统或整车系统的一部分进行评估。 5.2.6.1 子系统集成 在子系统测试台上，完成某一功能所需的所有部件都由相应的总线系统连接。为了创建被测子系统的真实行为，将模拟不属于子系统的组件。子系统级测试包括用户和系统功能，例如机械、化学或大气应变、静态电流、电磁兼容性等。例如，图5.11显示了车灯系统的子系统测试台。
子系统测试包括:
发现问题及时反馈给子系统设计零部件功能组知道最后测试通过。 5.2.6.2 电子电器整车集成 在子系统分别建立、测试和验证之后，它们被继续集成，以创建完整的车辆E/E系统。不同的子系统在物理和功能上连接在一起，以测试它们的正确交互和系统级功能的实现。作为第一步，车辆的所有E/E部件都连接在一个固定的试验车内（见图5.12），在试验车内对系统功能和非驾驶客户功能进行评估。
静态电子电器样车测试包括：
一辆固定的实验车包括大约80%的整车E/E系统。为了从内部和外部客户的角度对整个系统进行评估，必须对来自各个样车的完整车辆进行调查。这些所谓的动态实验室车辆配备有综合测量设备（见图5.13），记录所有数据总线流量，从而允许跟踪电子故障和验证动态E/E功能，如发动机控制、变速箱控制或底盘控制系统。同样，检测到的问题由设计零部件系统功能组修复。
在系统工程（engineering）过程结束时，系统集成将发布一个已定义和验证的整车E/E系统配置，即所谓的集成级别（见下文）。 5.2.7 支持管理过程 除了已经讨论过的技术开发过程外，电子电器开发管理过程非常重要的支持确保电子电器开发符合客户需求。除了一般的项目管理，两个主要的支持管理过程是配置管理和风险管理。 5.2.7.1 配置管理 就像几何集成一样（见第4.4）在硬件构建组之前，确保整车设计的几何一致性（见第3.3.3），系统集成将确保有效的E/E系统配置——车辆所有硬件和软件的功能一致的集合。因此，根据图5.3所示的V模型的系统工程过程在车辆项目的硬件构建阶段的每个阶段之前被重复（参见图5.14）。
在这里，配置管理的任务是构造、标记、记录和控制软硬件组件的所有版本和变体以及由它们组成的所有有效系统配置。 对软件或硬件工件的更改不能临时进行，而是由变更控制委员会（CCB）控制，CCB评估变更请求并分析其对整个系统的潜在好处和风险。 为了在硬件车辆中实现所需的E/E功能，配置管理还将有效的系统配置映射到相应的车辆变型（例如发动机变型、特定于国家/地区的变型、选项等），并确保车辆中仅内置最新的经验证配置。 图5.15显示了一个车辆项目的配置规划。第一个样车阶段（灰色）的第一辆车的系统配置表示为集成级别I200，随后的更新表示为I210、I220等。类似地，第二个样车阶段（蓝色）的集成级别称为I3xx，对于量产验证车辆（黄色）I4xx和销售给客户的系列车辆（绿色）I5xx。
5.2.7.2风险管理 在每一个车辆项目中，在E/E系统开发过程中总会发生许多事情，这些事情会对系统目标的计划实现和质量、进度或成本方面的性能产生负面影响。独立于工程师和管理者是否意识到他们，承认他们或计划他们，这些风险存在，知道他们是一个机会，以避免可能产生的问题。 风险的先决条件是未来的根本原因，如果消除或纠正了这些根本原因，将防止潜在的负面后果发生。因此，指定风险的两个参数是：
风险管理支持系统工程开发包括以下四个主要方面：
图5.16说明了风险管理的四个要素是如何相互联系的：
5.2.8 能力成熟度模型集成-Capability Maturity Model Integration 作为整车开发流程的一部分，车辆电子/电子系统的成功开发（按时并在预算内）在很大程度上取决于既定系统开发过程的质量。能力成熟度模型集成（Capability Maturity Model Integration，CMMI）是卡内基梅隆软件工程研究所（Carnegie Mellon Software Engineering Institute，SEI）开发的一组过程模型，为有效组织软件或系统工程过程提供目标（经验证的最佳实践）。这些目标由22个过程领域（见表5.3）规定，这些领域是相关实践的集群，在集体实施时，满足一组被认为对该领域的改进很重要的目标。过程区域被分为四类[8]。 在过程评估和改进方面，CMMI方法提供了两种不同的方法：一种评估组织成熟度的阶段性表示方法，一种在不同的过程领域对组织能力的持续表示方法。
5.2.8.1 组织成熟度层级 以软件开发而不是系统开发为重点，阶段性表示将22个过程领域中建立最佳实践的过程分为五个步骤，这五个步骤代表了组织成熟度水平的提高（从1到5）。达到一个成熟度级别意味着22个过程领域（见表5.4）的特定子集的最佳实践的成功实施，并且是实现下一个更高成熟度级别所需过程的先决条件。一个成熟度级别为5的组织已经实现了所有22个过程领域的所有目标。
5.2.8.2 过程能力等级 当成熟度级别关注于一个开发组织整体的逐步改进时，CMMI能力级别则应用于一个组织在各个过程领域的增量过程改进。表5.5列出了过程能力的六个增加级别，编号为0到5：
声明：本文内容及图片由BC-AUTO转载至网络, 来源于公众号Vehicle。 |
|
|
