EEPW论坛

简介

随着 OEM 开发的高级平台的自动化和连通性水平不断提高，各领域的车辆复杂性都在增长。为了应对这种日益增长的复杂性，汽车、航空航天和商用车辆 OEM 必须发展架构设计流程，以利用 MBSE 和数字化流程。当今的 E/E 系统工程解决方案通过提供稳健的数据连续性、高级自动化能力、闭环验证和设计优化来帮助公司实现MBSE。借助此类解决方案，工程师可以使用现有功能模型来生成车辆架构和更详细的系统设计，并持续从上游流程扩充数据，以确保从功能到实现以及实际组件或系统的可追溯性。这种可追溯性对于证明高级车辆平台的合规性和安全性至关重要。

随着车辆技术朝着更高水平的自主性和连通性方向发展，汽车、航空航天和重型/非公路车辆行业的原始设备制造商 (OEM) 开始面临共同的挑战（图 1）。人们希望这些先进技术能够改善乘用车、飞机、农业和其他重型设备的安全性、生产率及能力。然而，支持这些技术需要复杂的电气、电子和机电系统，这促使所有领域的车辆复杂性急剧提高。

到目前为止，车辆的架构演变是由对更好的车辆功能、新型且更高级的特性的需求驱动的。例如，考虑过去 20 年中汽车电气电子 (E/E) 架构的演变。以前，车辆架构由几十个通过低带宽网络和低保真度信号连接的 ECU 组成。这些架构支持车辆的基本特性和功能，例如立体声音响、电动车窗、巡航控制和防抱死制动系统。相比之下，现代中档汽车包含约 90 个 ECU，这些 ECU 通过各种高速和低速网络连接到数十个传感器和执行器。这种现代架构在规模和复杂性方面有很大的增长，目的是支持新特性，例如先进驾驶辅助系统 (ADAS)、高级信息娱乐系统、导航等。

现在，更高级的车辆自动化、电气化和连接系统正在推动车辆 OEM 厂商将新技术整合到车辆中。其中特别值得注意的是，制造商正在尝试整合新的通信技术，以便将车辆连接到 5G 网络、WiFi 并实现 “车辆到一切” (V2X) 的通信。利用这些通信技术，OEM 将能对车辆软件进行空中更新 (OTA)，这样哪怕车辆已售出，也能解锁更多功能。但是，车辆架构中也需要额外的基础设施来保障安全，防范来自车辆外部及其所连接的网络的安全威胁。随着车辆自动化程度的提高，这一点尤其重要。

图 1：汽车、航空航天、重型和非公路行业的车辆的连通性和自动化水平越来越高。

此类演变的结果是车辆跨多个领域的复杂性激增。2014 年，德意志****开展了一项研究，基于典型车辆在不同时间的软件代码行数 (SLOC) 和网络信号数量来测量车辆复杂性的上升。该研究预测，到 2020 年，平均每辆车将包含 3000 万 SLOC 和 10,000 个网络信号，这两个数据均为 2012 年所报告数据的至少两倍。然而，这一预测已被证明不符合实际（图 2）。

根据我们与客户的交流，2020 年的典型车辆拥有 1.5 亿SLOC 和 20,000 或更多的网络信号。新车辆技术的快速发展和集成推动车辆复杂性的增长，其速度超过了仅仅几年前的预测。除了更复杂的车辆外，OEM 还必须管理所有这些软件、网络、电气组件以及所有其他车辆系统和零件的生命周期。这涉及协调开发周期以支持先导计划的启动，同时要确保已纳入后期计划的要求。这当然是非常复杂的。OEM 在管理软件和组件的生产寿命周期时，必须确保组件在每种派生车辆的生产和服务中得到适当使用，并且配置与每种车辆规格相匹配。这涉及组织中不同部门的多个团队。

在设计和开发过程中，车辆定义中功能划分的细小错误便可能导致安全相关功能所依赖的系统的完整性不足。这又可能导致后期计划需要付出高昂代价来进行更改，或者更糟的是，车辆在使用中发生故障，需要召回以更新多个 ECU。不正确的组件配置也可能导致车辆功能错误或丢失，引起客户不满，并需要额外的成本来确定生产中和使用中受影响的车辆。管理这种复杂性并确保贯穿开发过程的可追溯性，对于打造先进的自动化联网车辆并按照紧迫的时间表——这在当今汽车、航空航天和商用车辆行业司空见惯——将这些车辆推向市场至关重要。

图 2：德意志**** 2014 年开展的一项研究的预测结果远低于 SLOC 和网络信号的实际增长。

针对 E/E 架构设计的基于模型的系统工程

现代车辆复杂性的爆炸性增长要求改变设计方法。传统方法依赖手动操作，工程领域被划分为多个孤岛，而未来的工程策略必须采用自动化，并通过稳健的数据完整性和集成解决方案来支持协作。基于模型的系统工程(MBSE) 以及先进的工程软件解决方案组合，可以为开发现代汽车、飞机和商用车辆日益复杂的 E/E 架构提供这些关键能力。

基于模型的系统工程流程从功能模型开始。这些模型描述各种车辆系统和子系统的功能。例如，功能模型可以描述特定软件组件、电气信号或电子元器件，例如模数转换器。这些模型常常是采用不同供应商的多种工具构建的。因此，这些模型背后的源数据是分布式的，彼此脱节。这种脱节的数据可能成为下游流程的一大痛点，尤其是在设计变更时。

各种系统的源数据必须标准化为通用数据模型，并整合为网络、软件、电气、硬件和其他功能类型。将这些多样化输入标准化为通用数据模型非常关键，因为它使得整个 E/E 架构和其他下游开发流程都可以访问车辆系统的源数据。

系统架构师可以使用标准化数据来创建 E/E 架构并提供完整的逻辑、网络、硬件和软件信息。然后，每个领域的工程师可以查询 E/E 架构以获取特定领域的信息，从而用于创建详细的系统设计。例如，电气工程师可以从架构中提取逻辑原理图，然后使用其他信息加以完善和增强，以创建车辆网络和电气分配系统 (EDS)。接下来，可以使用网络和 EDS 设计来提取离散的线束设计，然后利用这些设计创建制造数据，最终创建服务数据和特定车辆的维修文档。

图 3：数据连续性使开发各阶段的数据能够馈入下一阶段，从而确保可追溯性并加快开发周期。

稳健的数据模型对于实现基于模型的工程流程至关重要；从定义到制造和服务，数据始终保持连续。数据连续性使得 EDS、网络和软件开发各阶段的工作成果可 以用作流程下一步的输入（图 4）。数据在开发流程中上下移动的这种连续数字化流程，也会增强工程师管理和实施变更的能力。在实施之前便可理解设计变更的全部影响，因为每个领域都是基于同一数字化流程来工作。变更一旦得到验证，便可将其快速传播到所有受影响的领域和设计。

此外，数据连续性还提供了从功能模型到这些功能在车辆软件、网络和 EDS 中实现并形成文档的可追溯性。这种可追溯性确保工程师可以快速识别车辆架构中任何组件的功能来源，或者（反过来）找到实现一项功能所涉及的特定 ECU、网络信号或引脚。

MBSE 使工程师能够利用各种环境中的现有功能模型和工程数据来创建车辆架构及更详细的系统设计。通过持续从上游流程扩充数据，MBSE 确保可追溯性并简化变更管理和实施。但是，整合模型、创建架构和维护可追溯性所涉及的许多流程仍然是手动完成的。现代 E/E 系统工程解决方案可以让手动任务自动化执行，从而改善这些流程，并提供统一数据库来确保整个 E/E 架构和系统设计的数据连续性。

增强 E/E 架构设计 MBSE 的关键软件功能

当前，将功能模型整合到单个车辆平台中是一个手动过程，需要大量时间和精力。功能模型存在于各种不同的系统工程工具中，每种工具都有自己的车辆功能抽象方法。在传统系统工程工具中，仅仅完善一个这样的模型以足够详细地表示其在车辆平台中的实现，便需要巨大的手动工作量。将这一工作量乘以定义车辆平台通常所需的数以百计或数以千计的模型，不难得知任务的规模是何等之大。

如今，E/E 系统工程解决方案（例如 Siemens DigitalIndustries Software 的 Capital）可以使很多工作自动化进行。高级 E/E 系统工程软件不是在系统工程环境中添加必要的领域详细信息，而是可以导入功能设计抽象，这样工程师便可在平台级别用软件、硬件、网络和 EDS的领域详细信息修饰该抽象（图 4）。然后，软件使用基于规则的综合功能，以后续领域工程流程所需的粒度在车辆平台中部署功能。

这些专业 E/E 工程解决方案还有针对逻辑和物理关键性能指标 (KPI) 的内置指标，包括成本、带宽利用率等。这些指标可以推动早期优化，并与基于规则的综合一起推动 E/E 架构快速迭代。然后，设计规则检查可以识别物理设计抽象中的违规或问题，例如超额带宽或 ECU 利用率。例如，考虑一个在 Excel 中构建的软件组件的功能设计。

E/E 工程解决方案可以导入此设计以及车辆需要的成百上千的其他设计，并部署该功能以创建车辆平台。部署功能后，内置指标可以显示架构中每个 ECU 使用了多少 RAM，以便工程师进行权衡。此外，工程师可以快速查看当前功能分配将在架构周围的每个 ECU 中产生多少CPU 负载，如有必要则调整分配。完成调整后，工程师可以综合更新后的架构，并以这种方式继续完善。

图 4：高级 E/E 系统工程解决方案允许工程师修饰系统级别的功能抽象，从而加快架构和领域工程过程。

结果得到一个经过验证的多领域车辆平台，该平台已经针对平台 KPI 进行优化。生成平台时，E/E 工程解决方案可确保从平台到源功能设计的数据连续性和可追溯性。当不同团队执行详细设计工作以创建逻辑、网络、软件和硬件系统时，上述数据连续性还将支持团队之间的协作和可追溯性。每个元件将自动关联到其功能抽象和物理实现。线束中某个连接器上的单个管脚可以追溯到定义该管脚的接线图、逻辑原理图和功能设计。

Capital 之类的高级 E/E 工程解决方案则在此基础上更进一步。与 Teamcenter 和 Polarion 等产品和应用生命周期管理解决方案 (PLM/ALM) 的集成，使数字化流程可以一直延伸回到产品配置、要求和约束（图 5）。这种全面的可追溯性确保工程师可以了解架构中的每个组件或功能及其实现方式，还有它为什么要存在。其结果是，车辆 OEM 可以自动生成详细而准确的合规文档，而无需到处搜罗信息。

数据连续性和可追溯性还能简化工程变更的管理、实施和传播。有时候，即使出于合理原因进行的更改也可能导致使用中的车辆出现电气问题。Capital 的数据模型使工程师可以查看和了解变更对车辆的影响。这种可见性可防止工程更改在其他相关系统中造成问题。自动化变更管理功能还可以将设计变更传播到所有受影响的系统，确保其在全车得到正确实施。

图 5：与 ALM 和 PLM 解决方案的集成使得数字化流程可以一直延伸回到产品要求和定义。

连接软件开发与集成

现在，嵌入式软件应用对于实现乘用车、飞机和商用车的车辆功能至关重要。软件的重要性日益提高，这意味着工程师在架构设计和功能分配期间就要考虑这些应用。Capital Software Designer 是 Capital 套件的最新成员，支持软件工程师直接与架构设计进行协作和同步，以在系统定义的背景下开发嵌入式软件应用需求（图 6）。根据这些需求，工程师可以协调软件模型和控制算法，并在编写代码之前验证功能。

Capital Software Designer 具有自动化和基于合同的软件设计功能，支持软件工程师将高层架构细化为要在软件应用中实现的数字化组件。汽车、航空航天和重型设备领域的大型 OEM 厂商也拥有许多传统软件。工程师可以导入用 C、SysML、Matlab 和其他语言编写的现有代码，更新传统软件，使其能够在新的车辆平台中复用。无论哪种情况，必要的软件组件都会连接到整体车辆架构，实现基于模型的软件架构模型综合。

集成的形式验证技术可以在数学上证明软件架构和软件组件实现中没有不一致的地方。Capital Software Designer 还能连接各种仿真环境，以对嵌入式应用进行模型在环、软件在环、硬件在环和车辆在环 (MiL/SiL/HiL/ViL) 测试。它还支持对各种车辆抽象中的软件架构和组件进行闭环验证，从而确保软件有效集成到架构中。同时，ECU 规范派生自 E/E 架构，允许在虚拟 ECU 模型的背景下开发应用代码。这些 ECU 的基本软件配置也可以根据提取的 ECU 规范进行开发和测试。

图 6：Capital Software Designer 支持将软件架构和组件设计集成到 E/E 系统工程流程中。

采用 Capital Networks，考虑完整网络拓扑及其多种技术（例如 LIN、CAN、CAN-FD、FlexRay 和以太网），可以使用功能分配和信号定义来推导和设计车辆网络。然后，可以使用全面的时序模型来验证网络设计的行为是否满足功能要求，进而将“设计即正确”的输出文件交付给内部团队或一级合作伙伴。

接下来，可以使用 Capital VSTAR Integrator 配置AUTOSAR 基本软件。该过程利用流程中早先的模型数据来构造和生成已配置的软件模板，并根据内部规则和模型对其进行验证，确保输出准备就绪。然后，在目标硬件可用之前，可以使用 Capital VSTAR Virtualizer 虚拟运行软件，使得行为验证和调试可以在开发流程的早期进行，节省早期样品硬件的宝贵时间。

基于 Polarion 的 ALM 框架将嵌入式软件开发联系在一起。ALM 跟踪软件开发，确保应用程序满足平台级要求，并提供全程可追溯性。ALM 还会协调软件验证和确认。工程师可以通过 ALM 解决方案触发功能模型仿真，也就是将每个可用的车辆抽象结合起来，以了解完整车辆的虚拟模型在虚拟环境中会如何响应。这种方法不是创建物理原型，而是集成 MiL、SiL、HiL 和 ViL 仿真以反映车辆功能的多领域情况。与制作物理原型以进行早期验证和确认相比，这可以节省相当可观的成本和时间。最后，ALM 解决方案跟踪每种派生车辆的应用配置和交付，确保交付的软件支持每种车辆上的特定功能组合。

…………未完待续…………

更多详细信息请点击>>