标签: 汽车软件开发

汽车行业在适应与电动、自动驾驶和混合动力车辆相关的日益增长的市场需求和挑战时，正在经历重大变革。在这里，我们将关注我们报告 《2024智能汽车技术与研发测试洞察报告》 中突出显示的一些值得注意的汽车趋势2024。 汽车软件领域的新兴行业趋势 过去，您只需查看引擎盖下方，就能对汽车的工作原理有一个基本的了解。然而，情况已不再那么简单。现代车辆配备了大量的软件，以增强用户体验，并为驾驶员提供安全和便利功能。所有这些软件都必须以安全和保障为设计考虑。 电动车变得更加主流 尽管对电动车的需求有所放缓，但根据路透社的数据，2023年全球电动车销量仍增长了31%。因此，我们调查的51%的汽车软件专业人员表示，他们现在正在广泛地从事电动车的工作（自2023年以来增加了6%），而不是去年大多数受访者只从事一些电动车组件的工作，这可能并不令人惊讶。 随着市场更多地转向电动车，确保电动车软件的安全性和保障性成为汽车开发人员的首要任务。遵守法规对开发人员至关重要。由于目前还没有专门针对电动车的功能性安全标准，对于传统车辆至关重要的标准同样适用于电动车，其中最重要的是ISO 26262。 ISO 26262的一个关键组成部分是汽车安全完整性等级（ASIL），用于衡量组件风险。ASIL有四个等级，从ASIL A作为最低风险等级到ASIL D作为最高风险等级。在今年的调查中，40%的受访者表示他们需要达到ASIL D，这意味着他们正在从事更高风险的汽车系统/组件的工作。 随着今年整体趋势中安全性作为主要挑战的上升，避免网络攻击（26%）成为开发电动车的第二重要关注点，比去年增加了6%。如果电动车继续增加，这个数字预计在未来会上升。随着电动车在汽车行业中变得更加成熟，这些嵌入式系统中的更多连接可能会导致更高的漏洞风险和潜在的攻击面。 来自2024年汽车软件开发现状报告的关键要点 我们调查了近600名全球汽车专业人士，以更好地了解他们遇到的挑战以及他们如何应对行业和客户需求的变化。在调查中，我们询问了他们正在使用哪些最佳实践和工具来处理这些重大变化。 这些回应的完整结果可在 《2024智能汽车技术与研发测试洞察报告》 中找到。 强调高效加速开发 全球经济是今年对汽车组织影响最大的市场条件。与供应链挑战相关的条件以及2024年转向远程/混合劳动力和/或全球外包的人数增加了6%也是因素。 保持行业竞争力和最大化现有资源继续是今年汽车开发人员的重要策略，特别是随着生产力问题的上升：54%的人表示他们的开发团队采用混合工作模式，同时团队生产力问题的增加为4%，以及管理硬件/软件设计和代码资产的跨团队协作的主要挑战（29%）。 为了提高团队间的效率并在开发过程中节省时间，大多数汽车开发人员受访者理解向左移动软件开发生命周期（SDLC）的重要性，并正在使用编码标准和指南，如MISRA® —— 比去年增加了20%！此外，静态代码分析器、版本控制和项目管理工具在汽车软件开发人员中使用频繁。 嵌入式安全在2024年超越了汽车软件的安全性 随着安全性在汽车行业中变得更加成熟，今年的关注点明显转向了代码质量和安全性而非安全性。 对于那些关心其软件质量的人来说，我们的发现表明，虽然内部代码审查流程正在变得更加流畅，但对于开发团队来说，仍然存在充分测试的挑战。 嵌入式安全也作为主要挑战而上升。根据2023年所有汽车网络事件中有50%具有高或巨大影响的最近一份来自网络安全和数据管理平台Upstream的报告，与2022年相比增加了2.5倍。此外，Upstream报告称，电动车充电站成为新的攻击战场。随着汽车软件安全风险的升级，我们调查的汽车专业人士的主要安全关注点是难以满足安全要求，如IEC 62443和ISO 27001。 此外，绝大多数汽车专业人士表示，他们将需要遵守ISO/SAE 21434，这是一个专注于车辆电子系统网络安全风险的汽车标准。虽然安全标准主要是客户要求而非市场强制，但它对汽车开发至关重要，因为当前的安全关键标准在涵盖网络安全风险方面是不足够的。标准合规仍然是必要的。 汽车软件开发过程的一个重要部分是确保软件符合关键行业标准和指南。如前所述，汽车功能安全标准ISO 26262对所有汽车软件开发都是必要的，我们调查的77%的人需要遵守它。 此外，根据我们调查的人所说，证明合规的主要挑战是难以满足每个安全要求并提供所有合规要求已满足的必要证据。 当与验证和验证软件的相关挑战相结合时，这是我们的受访者识别为最耗时的任务，执行和验证合规的标准可能是一项艰巨的任务。 执行和验证功能标准的最有效方法之一是使用静态分析工具。 标准遵从性仍然至关重要 汽车软件开发过程的一个重要部分是确保软件符合关键行业标准和指南。如前所述，汽车功能安全标准ISO 26262对所有汽车软件开发都是必不可少的，我们调查的77%的人需要遵守它。 此外，根据我们调查的人，证明遵从性的主要挑战在于难以满足每一个安全要求并提供所有遵从要求已经满足的必要证据。 当与验证和验证软件的相关挑战结合起来时，这是我们的受访者识别为最耗时的任务，执行和验证遵从功能标准可能是一项艰巨的任务。 执行和验证遵从功能标准最有效的方法之一是使用静态分析工具。 了解更多关于2024年汽车软件开发的新兴趋势 随着更多硬件组件被软件取代，汽车软件不仅需要安全，还需要保障。通过审查行业研究，您不仅能够跟上今年的挑战，还能为未来几年做好准备。 下载您的免费副本 《2024智能汽车技术与研发测试洞察报告》 ，其中包含超过60页的分析、信息图表和有关主要挑战、最佳实践和新兴趋势的信息。 ➡️免费获取 《2024智能汽车技术与研发测试洞察报告》 ➡️工具免费试用：marketing@polelink.com

AutoSar是Automotive Open Systems Architecture的缩写，译为汽车开发系统架构，定义了一套支持分布式的功能驱动的汽车电子软件开发方法和电子控制单元的软件架构标准化方案，以实现于不同汽车平台的软件开发，提高软件的复用性，从而降低成本和开发周期。 一、AutoSar背景 随着汽车的普及性，人们对汽车的需求量越来越大，要求越来越高，对于汽车的功能设计已不能快速地通过传统的设计方式来实现，通过对汽车功能开发的长期研究与总结，发现汽车很多功能都可以互用，或只需在原来基础上进行某些修改或微调，于是AutoSar孕育而生。它是由汽车OEM和一线供应商建立的汽车软件开发全球合作联盟，于2003年夏成立，并于04年开始工作，其目的就是控制汽车软件开发的复杂性和多样性。其包括9个核心成员：BWM、BOSCH、continental、DAIMLER、Ford、GM、PSA、TOYOTA、VOLKSWAGEN AG。目前国内已有一汽、上汽和恒润科技加入。 AutoSar提倡“在标准上合作，在实现上竞争”，核心思想为“统一标准、分散实现、集中配置”，这对OEM带来很大好处，使得对于软件的采购和控制更灵活。在具体实施的过程中，OEM起主导作用。OEM如何提出需求并将该需求实现在其产品上，于是就制定了AutoSar方法论。 二、AutoSar技术概述 AutoSar的计划目标主要有三项，一是建立独立于硬件的分层的软件架构；二是为实施应用提供方法；三是制定各种车辆应用的接口规范，作为应用软件整合标准，以方便软件架构在不同汽车平台上的复用。 1、AutoSar软件架构 为了实现 AutoSar，即应用程序和基础模块间的分离，汽车电子软件架构被抽象为如下图1所示。     图1、AutoSar软件架构层次图 为区别软件依赖和硬件依赖，基础软件分为4个层次：服务层（services layer）、ECU抽象层（ECU abstraction layer）、微控制器抽象层（mircocontroller abstraction layer）和RTE（Runtime environment）。在这四层外还有复杂驱动（complex driver），这部分涉及到严格的时序没有被标准化，如对某传感器的驱动。 微控制器抽象层：即与实际控制器间的连接，是物理基础，用于映射控制器的功能和外围接口，定义了内存接口、IO接口和通讯接口。 ECU抽象层：将ECU结构（如外设与ECU的连接方式等）进行了抽象处理。与ECU平台相关，但与微控制器无关。在ECU硬件的基础上，为ECU提供外围设备驱动的程序。 服务层：提供包括诊断协议、存储管理、ECU模式管理和操作系统等在内的系统服务，除操作系统外，其他服务层软件模块都与平台无关。 RTE层：实现了应用程序与基础软件间的分离，负责应用程序与基础软件间的数据交换。RTE以下为底层软件。RTE以上为应用层软件。 2、AutoSar操作方法 为符合该标准的汽车电子软件开发，定义了一套通用的技术方法，即AutoSar方法。该汽车电子软件系统设计与开发流程如图2所示。 图2、AutoSar系统设计与开发流程 开发过程可划分为两个阶段： 第一阶段是系统配置阶段，属于系统级设计决策工作，即编写系统配置输入文件和系统配置描述文件。系统配置输入文件包括软件构件描述输入、ECU资源描述输入、系统约束描述输入。软件构件描述输入定义了每个软件构件的接口，如形参的数据类型等。ECU资源描述定义了每个ECU的资源需求，如处理器、外设等硬件资源。系统约束描述定义了总线信号、拓扑结构和软件构件的映射关系。 系统配置描述文件是在系统配置输入文件基础上建立的，是这一阶段的最终成果。包含所有的系统信息、软件构件与ECU的映射关系和通讯矩阵。 第二阶段是ECU的配置，这一阶段是第一阶段的延续，对每个ECU分别进行细化。首先从系统配置描述文件中提取出与各个ECU相关的系统配置描述信息，包含ECU通讯矩阵、拓扑结构等放在另外一个XML中。然后进入ECU配置的实际工作，负责给输入对象中添加具体应用所必需的信息，如任务调度、给任务分配可运行的实体等。最后生成具体ECU的可执行程序，根据ECU配置描述文件中的配置信息构建完成ECU的基础软件设置和应用软件的集成，并生成ECU可执行的代码。 在这个设计过程中，使用了虚拟功能总线的概念，即将AutoSar软件构件间的通信、软件构件与基础软件间的通信进行了抽象，同时使用了预先定义的标准接口。对于虚拟功能总线来说，ECU内部通信和外部总线通信并没有区别。 三、实施 软件构件描述文件的生成，需要获取每个软件构件关于接口、行为、硬件接口、运行性能需求等方面的信息。软件构件描述文件本身将包含如下内容： （1）、一般特性：如名称、生产商等 （2）、通信属性：端口、接口 （3）、内部结构：子构件、连接关系 （4）、需要的硬件资源：处理时间、调度、内存等 ECU描述文件包含如下内容： （1）、一般特性：如名称、生产商等 （2）、温度（自身、环境） （3）、可用信号处理方法 （4）、可用编程能力 （5）、可用硬件：微控制器、内存、接口外设等 （6）、RTE之下针对控制器的基础软件模块 （7）、从引脚到ECU抽象层的信号 系统约束描述文件包含如下内容： （1）、网络拓扑：总线、连接的ECU，网关 （2）、通信：通信矩阵、网关表 （3）、软件构件的映射 以上描述的系统配置输入完成后，使用系统配置工具导出系统配置文件，决定哪个软件构件运行在哪个ECU上，生成ECU配置描述和系统内的通信矩阵。 接下来就是ECU配置。将每个ECU配置信息从系统配置文件中提取出来，包含ECU通信矩阵、拓扑结构、顶级功能组合。将软件构件和基础软件的代码集成生成可执行的代码。 值得注意的是在这整个过程中，需要进行多次的重复修改，以保证实现功能并且是最优的方式。