【ZiDongHua 之驾驶自动化收录关键词：MathWorks   电动汽车    汽车行业    ECU 】
　　
　　开发和交付新一代软件定义汽车
　　
　　作者 Jim Tung, MathWorks
　　
　　算法无需由实时调度器调用，即可部署在面向服务的架构中，并通过 API 调用进行调用。鉴于这种转变，基于模型的设计工具已更新，不但支持基于信号的接口，而且还支持面向服务的架构。
　　
　　◆  ◆  ◆  ◆
　　
　　下一代汽车将是率先通过软件传递品牌特色和客户价值的汽车。连接、自主性和电气化方面的新技术，是这些软件定义汽车 (SDV) 的核心。这些技术将不断涌现，以应对客户对移动性不断变化的期望。这些创新背后的软件，无论是面向客户的还是在后台运行的软件，都需要大量的投资。它还代表着新的机遇，因为各公司不断发展自身能力，以提供附加 App 和服务，更不用说安全和其他关键更新了。
　　
　　多年以来，在提高车辆性能和安全性方面，软件无疑一直发挥着重要作用。这种嵌入式软件与物理系统紧密绑定并部署在 ECU 上，因此需要很高的可靠性。通常，它还必须符合过程模型（包括 Automotive SPICE®）以及功能安全标准（如 ISO® 26262）。许多汽车 OEM 和供应商都擅长使用基于模型的设计，以通过仿真以及随后的代码生成和验证对设计进行早期验证，从而加速此软件的交付（图 1）。
　　
　　
　　
　　图 1. 基于模型的设计有助于更早地发现并修复系统和软件缺陷。
　　
　　对于 SDV，软件发挥着更加重要的作用。为此，组织需要做好规划，以在车辆投产后持续改进和更新软件。他们需要整合从联网车辆收集的运营数据，以便推动这种持续改进。此外，他们还需要扩展用于衡量成功的关键性能指标 (KPI) 集，也就是用开发运营一体化方面的更多度量（包括改动失败率和从事故中恢复的平均时间）作为传统度量（如开发速度）的有力补充。
　　
　　完成上述任务需要转变心态。众多汽车公司面临的问题是：我们的软件开发和系统开发团队和过程需要做何改变，以及基于模型的设计如何发展才能应对这些变化？
　　
　　基于模型的设计如何发展以适应 SDV 开发
　　
　　迄今为止，工程团队最常使用基于模型的设计来针对嵌入式系统进行开发。在许多情况下，这意味着在资源受限的 ECU 或微控制器上难以实时实现算法（用信号流表示）。现在，除了 ECU，目标还包括 SDV 的中央或区域计算机以及云。此外，算法无需由实时调度器调用，即可部署在面向服务的架构中，并通过 API 调用进行调用。鉴于这种转变，基于模型的设计工具已更新，不但支持基于信号的接口，而且还支持面向服务的架构。
　　
　　这些工程团队习惯于使用基于模型的设计，专注于设计、实现和验证，并在人工驱动的交互式开发工作流中使用为桌面端打包的工具。展望未来，自动化将成为重中之重，并通过持续集成 (CI) 管道、Kubernetes 编排流程和类似机制发挥更大的作用。许多组织已将基于模型的设计和 CI 与自动化管道相集成，这些管道用于在提交模型更改时执行模型验证、代码生成、静态代码分析和其他任务。
　　
　　同样，尽管组织对使用产品生命周期管理 (PLM) 系统进行工具和资产管理的关注相对较少，但这种关注也在逐渐增加。如今，团队更倾向于使用 Git™ 和 Artifactory 仓库的主干分支方法，以敏捷方式存储、迭代和快速改进软件工件。软件开发团队使用的是更敏捷、更精细的方法。此外，这些团队不再只是将其软件系统交付到用于生产启动 (SOP) 的物料清单中，还要在 SOP 后将其无线传输到 SDV。基于模型的设计将不断发展，以适应这些新兴的开发模式。
　　
　　弥合 SDV 文化差距
　　
　　当然，任何创新案例，包括 SDV 案例，都不仅仅关乎一套不断发展的工具和流程。它还涉及工具和流程的使用者，并且往往与使用者所处的组织的文化有关。在许多方面，对于使用基于模型的设计进行嵌入式软件的系统工程和交付的团队，其工作方式明显不同于更以代码为中心的团队，后者更倾向于采用开发运营一体化做法。
　　
　　有些组织已着手弥合这些各行其事的常见团队之间的分歧（图 2）。在这些组织中，系统工程团队已开始采用开发运营一体化做法。例如，在创建系统模型或场景模型时，他们通过适当的流程将该模型转交给其他人，再由这些人将其纳入下游自动化过程中。另一方面，这些组织中以代码为中心的团队，已开始将系统和模型视为其工作的重要组成部分。他们认识到了仿真在将 SDV 所需的软件和系统作为一个有机整体交付时的价值，并且正在学习如何将它纳入自己的流程中。此外，这些组织正在采取各种措施，通过持续集成/持续交付 (CI/CD) 等公共平台将各团队汇聚于此。这种共享技术堆栈更易于扩展和维护，它有助于简化对流量、速度、软件稳健性和系统严格性等共享 KPI 的跟踪。
　　
　
　　
　　图 2. 通过基于模型的设计和自动化工作流弥合以代码为中心的团队与系统工程团队之间的鸿沟。
　　
　　真实用例
　　
　　为了更好地了解团队如今可以采取哪些措施来加速 SDV 软件的交付，请参考以下用例。工程团队的任务一直是为已投入生产的电动汽车提供更新。此更新将实现一项新功能，即 Sport + 模式。该功能有助于将车辆从 0 加速到 60 英里/小时（100公里/小时）的时间减少 10%。
　　
　　此示例侧重于团队为实现此目标而使用的下面三个关键工作流：
　　
　　在云端执行系统分析和仿真
　　
　　使用 CI 实现测试和代码生成自动化
　　
　　执行虚拟 ECU 部署和测试
　　
　　一、系统级研究。
　　
　　作为第一步，该团队需要确定可通过更改实现所需加速度的关键软件参数，然后在组件级别和系统级别量化更改这些参数所带来的影响。他们使用虚拟车辆组建工具在 Simulink® 中以交互方式配置和构建虚拟车辆（图 3）。然后，他们运行一系列参数扫描，更改最大电池电流和制动再生限制等模型参数，同时监控加速度、MPGe 和其他系统级和组件级度量。为了加快仿真速度，该团队使用 AWS® 上的 MATLAB Parallel Server™，对 EC2 实例运行参数扫描，这将执行数百次仿真所需的时间从数小时缩短到几分钟。若要增大所需的加速度，除了优化参数之外，可能还需要更改算法。这些更改可以在模型中快速实现，并通过模型在环 (MIL) 和软件在环 (SIL) 测试进行验证。
　　
　　
　　
　　图 3. 系统级研究中使用的虚拟车辆和关键变量图。
　　
　　二、使用 CI 实现测试和代码生成自动化。
　　
　　完成系统级研究后，该团队开始修改组件模型，更新参数值，并根据需要进行其他更改，以提高车辆的加速度。在许多情况下，多名工程师可能并行处理不同功能和组件，因此，该团队会将模型组件化并置于源代码管理之下。这样，工程师便可与其队友共享资产并同步工作。同样重要的是，该团队由此能够使用可扩展的 Jenkins® 或 GitLab® CI 管道，在更改提交时实现测试和代码生成自动化（图 4）。这些测试可以在模型级别和应用软件级别运行（包括 MISRA C™ 检查和其他静态分析），并且可以配置为在各种环境和容器中运行。
　　
　　
　　
　　图 4. CI 管道可用于在开发运营一体化工作流中实现测试和代码生成自动化。（徽标由 Jenkins 提供。）
　　
　　三、虚拟 ECU 部署和测试。
　　
　　在代码生成并经过测试后，该团队的下一步是在虚拟 ECU 上验证应用软件。在本例中，生成的代码将作为应用软件组件部署在 AUTOSAR Classic 和 Adaptive 平台上。为了验证组件是否可在接受目标硬件测试之前与中间件集成，并可能作为无线更新发送到车辆，该团队使用了运行在 AWS EC2 实例上的虚拟 ECU（图 5）。对于这种特殊的应用，他们针对 Adaptive AUTOSAR 将组件与 Elektrobit (EB) corbos 中间件相集成，而针对 AUTOSAR Classic 将组件与 EB tresos 基础软件相集成。在虚拟 ECU 上运行测试后，该团队将测试结果与之前通过 Simulink 执行的 MIL 和 SIL 测试的结果进行了比较。确认了集成生产软件可供进行测试后，该团队就可以部署此软件了。
　　
　　
　　
　　图 5. 在 AWS EC2 上的容器化环境中运行的虚拟 ECU 上进行测试。
　　
　　未来发展之路
　　
　　MathWorks 的工程师与汽车行业和世界各地的数千客户建立了合作关系，可以帮助他们的团队在组织内以新的方式使用基于模型的设计。随着越来越多的公司及早开启了他们的 SDV 之旅，我们将继续致力于这项工作，增加旨在进一步推动自动化和关闭反馈回路的新功能，将更多来自生产车辆的运营数据纳入系统工程、设计和开发活动（图 6）。
　　
　　
　　
　　图 6. 馈送运营数据。
　　
　　我们还将继续帮助客户调整组织内的软件开发和系统工程做法，以帮助他们经济高效地提供下一代汽车所需的更高性能、可靠性和安全性。对成熟的汽车公司来说，这往往意味着要利用系统工程团队的专业知识来增强或提升软件开发团队的能力。而对科技初创企业和更年轻的公司来说，这是赢得竞争优势的大好时机，因为他们可以将成熟的基于模型的设计做法（包括建模、仿真和代码生成）纳入面向开发运营一体化的工作流中。