汽车软件开发流程介绍

在汽车软件开发中，软件开发流程是软件工程的核心，因为它们为软件开发实践“提供了一个骨架并确保了它的严谨性”。软件开发的流程包含“阶段”“活动”和“任务”三个要素，它们规定了参与者需要完成的工作。不同的参与者在软件开发过程中扮演着不同的角色，例如软件设计者、软件架构师、项目经理或质量经理等。

软件开发流程是分阶段的，每个阶段关注了软件开发的特定部分内容。总体上看，一般的软件开发工作分为如下阶段：

(1)需求工程(requirements engineering)：该阶段用于创建有关软件功能的设想并将设想分解为多个需求(关于“应该实现什么”的碎片化信息)。

(2)软件分析(software analysis)：该阶段用于执行系统分析，做出关于将功能分配到系统中不同部分的高层级逻辑决策。

(3)软件架构设计(software architecting)：该阶段软件架构师将描述软件及其组件的高层设计，并将这些组件分配至相应的计算节点(ECU)。

(4)软件设计(software design)：该阶段用于软件各组件的详细设计。

(5)实施(implementation)：在该阶段用相关的编程语言实施组件的设计。

(6)测试(testing)：该阶段，软件以多种方式被测试，例如单元测试或组件测试等。

基于V模式的开发流程

现代软件开发范式认为，设计、实施和测试的迭代进行是最好的实践，因此上述阶段通常是并行完成的，具体到汽车行业，则普遍采用V模式开发。该流程的特点是无论进行开发、编程或测试，总是在同一环境下工作，开发过程的每一步都可以得到验证。使用这一方法最直接的效果就是加速和简化了开发流程，这样，技术人员可以快速地把自己的思想变成现实并可以尽早消除错误。

V模式的开发流程如图1所示，包括：功能设计及控制方案设计——快速控制原型——代码自动生成——硬件在环仿真——系统集成测试/标定，构成了从功能设计、软件编程、可靠性测试到标定的汽车电控系统开发一体化解决方案。其中的每一个开发步骤都在计算机辅助控制系统设计工具的支持下，大大加快了开发的速度，并且整个过程建立在一个完整的开发环境中，实现了各个步骤间快速、平滑的过渡。

图1 V模式的开发流程

V模式开发流程的具体步骤包括：

(1) 需求定义与功能设计。根据系统的功能要求在MATLAB/Simulink等环境下进行图形化建模，建立控制器模型和被控对象模型，并进行离线仿真和分析。这一过程也称为模型在回路(model in the loop，MIL)。

(2) 快速控制原型(rapid control prototype，RCP)。建立实时仿真模型，并下载到原型系统中，接入实际被控对象进行测试，以验证控制系统软硬件方案的可行性。

(3) 目标代码生成。采用产品代码生成软件对模型进行转换，自动生成产品代码。这个过程可以针对特定ECU进行代码优化。

(4) 硬件在环(hardware in the loop，HIL)。采用真实控制器，被控对象或者系统运行环境部分采用实际物体、部分采用仿真模型来模拟，进行整个系统的仿真测试。

(5) 测试与标定。用于在系统集成中对ECU进行标定和测试，在便利的情况下对ECU进行必要的参数调整。

V模式的开发方式相对于传统ECU的开发过程有许多优点，它是一种基于模型的开发过程，所有控制策略与发动机仿真模型都是利用框图化的基本模块建立起来的。

首先由系统工程师进行功能的开发和建模，并进行系统设计，生产快速原型;接着需要软件工程师进行软件开发，将建好的模型转换成机器代码，并将其写入ECU;随后由软件工程师和硬件工程师依次进行软件测试、系统测试、标定及功能测试;最后需要匹配工程师在真实的汽车上对ECU测试，并将出现的问题反馈给开发部门重新修改，反复进行。

在整个ECU开发过程中，开发工具起到重要的作用。目前广泛采用自动代码生成技术可把框图模型直接生成可执行的代码，在专门设计的硬件平台上对控制功能及发动机进行仿真。同时模型化的控制算法也可直接生成目标ECU代码。V模式的开发方式大大缩短了ECU的开发周期，节约了开发成本，并能保证代码的高质量和控制系统的可靠性，同时为未来新的控制功能设计提供了图形化的接口平台。

基于ASPICE的开发流程

ASPICE，全称“Automotive Software Process Improvement and Capacity Determination” ，汽车软件过程改进及能力评定，在当前的汽车行业中有着十分广泛的应用，主要就是对软件开发团队所具备的研发能力水平进行评价的一种模型框架。这一评价模型及框架最早出现在2005年，是由欧洲的二十多家主要的汽车制造商共同制定并且发布的，其主要目的就是在汽车零部件厂进行软件开发流程的过程中给予其适当指导，从而使汽车软件研发质量可以得到有效改善，使汽车软件开发可以得到满意效果，并且这一模型框架在实际实践中的应用也越来越广泛。

图2 ASPICE框架

在Aspice体系中依据企业在管理上的细致程度及严谨程度上所存在的差异，对于企业软件研发能力可以以六个不同级别实行划分，分别为从零级到五级，级别越高也就表示在项目研发过程中有意外情况发生的可能性也就越低，对于相应的项目及产品，企业也就有着更强的掌控能力，也就更有能力生产高质量产品交付于客户。零级所表示的就是企业在项目研发方面处于比较混乱的一种状态;一级表示企业可以将有关的产品研发工作完成，然而缺乏合理的管理，成功率比较小，在项目研发过程中有很多的不确定性因素存在，对于项目研发缺乏应有的掌控能力，无法确保可以按时进行高质量产品交付;二级表示企业不但能够将相关产品研发工作完成，还能够提前制定科学严谨的完善工作计划，且可以依据工作计划实施项目监控及管理工作，使各个方面的项目都得以有序开展及落实;三级表示企业不但可以有效落实相关的项目管理，且能够在过往项目中积累有关经验教训，使公司内部的知识资产及标准工作流程形成，为今后项目落实提供指导与参考，并且有利于企业管理的进一步改善;四级所表示的就是在项目研发过程中融合统计学知识及技术，对于项目中的各种数据实行统计分析，并且将其应用到今后的项目管理中，对于项目结果实行预测，且可以依据预测结果实时调整项目，以保证项目目标的更好完成;五级所表示的就是企业可以依据商业目标需求，对于项目研发过程主动进行调整，在改革管理方面具有较强管理能力，可以根据对于过程中的量化分析，确定明确改进目标，且对于改进结果可以实行有效地量化监控及分析。

图3 ASPICE开发流程

依据上文中对Aspice体系的分析，可以以Aspice体系为基础进行汽车软件开发流程的设计，使汽车软件的开发得以更合理进行，从而使汽车软件开发可以获得比较满意的成果，其具体流程如下：

1)汽车软件开发需求的获取及分析

在进行软件开发设计之前，需要软件开发企业及开发设计人员由客户处得到客户需求，并且要确定这些需求能够被正确理解，对于这些经过定义的客户需求，将其转变成为系统需求，主要作用就是对系统设计进行指导。

2)系统架构设计

构建合理的系统架构，确定将哪些需求向哪些系统要素进行分配，且依据定义标准对所设计的相关系统架构进行评估。

3)软件需求分析

对于系统需求中的有关部分，将其转变成为软件需求。

4)软件架构设计

在这一环节需要注意以下几点内容：对于软件体系结构进行定义，对软件元素进行确定;将软件需求向软件元素进行分配;对每个软件元素接口进行定义;对于软件元素中的动态行为以及资源消耗目标实行定义;在软件需求及软件架构设计间构建一致性以及双向可追溯性;对于软件架构设计所有相关方均达成一致并且进行沟通。

功能安全开发流程

随着世界范围内汽车电气化不断深入，车辆的集成度和复杂性越来越高，为了保证复杂系统下汽车的安全性，国际标准化组织 ISO 针对汽车功能安全发布了 《道路车辆功能安全标准———ISO26262》标准，旨在提高汽车的安全性。

ISO26262 标准体系由 9 个子标准组成，第 1 部分为专用词定义，其余 8 个部分分别为: 功能安全管理、概念阶段、系统开发、硬件开发、软件开发、生产和运行、相关支持、ASIL导向和安全导向分析。其中的第 4、5、6 部分，兼容汽车电子常用 “V”模型开发流程，见图4。

图4 ISO26262 标准体系

安全生命周期是 ISO26262 定义的一个重要概念，完整的一个周期需包括 3 个阶段: 概念阶段、开发阶段和量产阶段，见图 5。ISO26262 覆盖了从对象构思、设计、开发、生产直到使用寿命结束的整个生命周期，每个阶段都分别有相应的子标准来管理。在产品开发流程之外，并行地进行以功能安全作为开发对象覆盖整个生命周期的功能安全流程，这是 ISO26262 一个重要的和核心的概念。

图5 安全生命周期概念

功能完整性等级 ASIL：在 ISO26262 中所有影响系统功能安全的风险都应该被辨别和确认，对于所有可能影响功能安全的风险，需要执行风险辨别和持续安全改进，风险评估的主要手段是确定 “功能安全完整等级”，可以通过 3 个指标: “严重性”，“发生概率”，以 及 “可控性”，来进行量化评估，作为后续阶段流程的输入。严重性: S0 ～ S3，代表对驾驶员及乘客可能造成伤害的级别; S0 代表没有伤害，S3 则代表致命伤害。发生率: E0 ～ E4，代表这个风险在实际应用环境中发生的概率; E0 代表不可能发生，E4 代表常见的。可控性: C0 ～ C3，代表这个风险发生后人员依旧采取措施控制并避免伤害的能力; C0 是总是可控， C3 代表很难或无法控制。在上面 3 个参数确定了以后，可以参考 ISO26262 的 ASIL分级矩阵来确定每个风险的 ASIL 等级。其中，QM 代表不需要特别的功能安全流程，只需要正常的质量管理就可以。

部分危害事件的ASIL的评级以及为其分配的安全目标如表1所述

ASIL 级别 A、B、C、D，越高代表着风险越大，该风险越不可容忍。在开发中一些常用的降低风险的手段有: 质保体系(文档化，流程，认证) 、校验方法 (方法设计，测试) 、安全验证分析 (失效分析，故障树分析，失效率) 以及可靠性分析(工具，零件，人员) 。

ISO 26262-3 到 26262-10 给出了一个功能安全的流程，如图6 所示，从概念阶段到产品开发，再到 SOP 后阶段。如果对于研发公司来说，SOP后阶段可以不考虑。

图6 功能安全流程

1)项目定义

项目定义的主要作用是定义和描述该系统，主要包括对该系统的初始架构、操作模式以及该系统的主要功能的描述。

在进行功能安全项目定义之前，研发人员可以参考一些以下文档，以对系统有一个初步的、充分的了解。主要包括：

1)新能源汽车市场的研究报告;

2)相关产品的设计报告;

3)电池和电池管理系统的技术报告;

4)BMS相关的法律、法规和标准，例如QC/T 897-2011等文档。

除此之外还需明确，此BMS是为总质量不超过3.5t的电动汽车设计的;且该车辆应该行驶在常规的场景，包括高速公路，城市道路，乡村道路等。通常情况下极端环境下如温度低于-40的情况下，该车辆是不适宜的。需要供应商提供电池的信息参数，例如电池额定容量，充放电截止电压，标准充放电工作电流等。此外，还需要与电池供应商确定好电池的安全的工作电压、温度以及电流工作区间，以便后期开发过程设定电池的故障阈值。

2)安全周期初始化

安全生命初始化的作用主要是为了区分该项目的初始状态，是一个新的开发项目还是对现有项目的修改。如果说是一个新的开发项目，那么概念阶段的开发将继续从后面的危害分析和风险评估进行;如果说是一个对现有项目的修改，应该进行系统修改的影响分析，以识别和描述适用于该系统或其环境的预期修改，并评估这些修改的影响。对系统或环境的修改主要可以考虑：a) 操作情况和操作模式;b) 与环境的接口;c) 系统的安装特性，如车辆内的位置、车辆配置;d) 周围环境，包括温度，海拔，湿度，振动和电磁干扰等的变化。通过以上几个角度的分析，形成对现有系统的修改分析报告，再进行相关的功能安全活动。

3)危害分析和风险评估

危害分析和风险评估(Hazard analysis and risk assessment， HARA)的作用是通过系统性分析，对危害事件进行评估，从而规避不合理的风险。HARA的主要流程如图7所示。HARA过程中首先需要做的是基于系统定义中得到的BMS的主要功能得出失效功能(Malfunction， MF)。此过程可以借助头脑风暴的形式确定该系统的失效功能，缺点是可能存在遗漏的情况。目前较为常见的方式借鉴HAZOP分析中的“关键字”法进行失效功能的确定。通过“主功能+关键字”的形式，可以有效地得到该系统的失效功能并进行后续的HARA分析。常见的关键字包括“Loss”，“More”，“Less”，“Reverse”，“Unintended”，“Stuck”等。

图7 危害分析和风险评估流程

4)功能安全概念

如果说概念阶段的项目定义、安全目标等安全活动与传统的开发流程相差甚远，研发人员对其较为陌生的话，那么功能安全需求则显得相对友好。在功能安全活动中，功能安全需求(Functional Safety Requirement, FSR)是从安全目标推导出来的，实际上，我们可以将其等价于“用户安全需求”，根据定义好的需求，我们便可以进行后续的系统，软件与硬件阶段的设计。

按照“检测信号-确认故障-进入安全状态”的方式进行推导。

ISO 26262中规定，每一个安全目标下至少有一个FSR，且FSR是可以共用于多个安全目标的。作为功能安全中一个重要的属性，FSR的ASIL等级是继承自该需求所属的安全目标的，如果该FSR属于多个安全目标，那么FSR的ASIL等级取多个安全目标的ASIL等级的最高值。如果说某一FSR可以分解为两个独立的需求，那么相应的ASIL等级也会进行分解，从而可以降低后续活动中该条需求的开发与验证难度。

借助V 字型开发流程，可以将功能安全过程与ASPICE 结合起来，如图8 所示，这对产品开发有很大的帮助。

图8 功能安全与 ASPICE

审核编辑：汤梓红