ADAS/AD控制器模块开发14 - ASPICE流程
前言
相信每个从事汽车电子开发的人都会有这样的心路历程：1.刚毕业时，懵懵懂懂的进入公司，跟着公司的培训走，了解自己岗位的内容，以及与其他岗位的交互，还要熟悉V模型开发流程；2.工作几年后，睁开眼睛看外部的世界，例如跟从事IT行业的同学们聊聊，跟转行做医疗器械的同学们扯扯，突然会想一件事情，为什么汽车电子的开发会是这样一种形态呢？都涉及到系统和软件的开发，但是组织形式和开发形式却又如此的不一样？是什么东西在指导并搭建了这样一种特定的开发组织形式呢（即开发流程）？
具体再提几个深入一点的问题：
- 为什么汽车电子行业的开发要有系统、软件、硬件、结构（机械）、匹配、集成、测试、验证、确认、制造、质量管理、工程项目管理、产线项目管理、产品管理、风险管理等复杂的开发人员设置？
- 为什么在汽车电子相关的几个供应商和主机厂跳来跳去，发现公司的项目组织形式和部门组织形式都大差不差，都长成某种特定的样子呢？
- 为什么汽车行业那么多搞开发的不会写代码？不会写代码也能特么叫开发人员？？
- 为什么汽车电子开发要用V-model流程进行开发？
上述一切的答案就在于ISO15504 - Automotive Software Process Improvement and Capability dEtermination（Automotive SPICE，软件流程改进和能力测定的汽车行业定制化版本）。这是一个由欧洲车企发起的车载软件开发的流程标准，用于欧洲主机厂对供应商进行软件流程能力评估。包括：奥迪、宝马、奔驰、菲亚特、福特、捷豹路虎、保时捷、大众、沃尔沃等。
这个流程集合的意义在于，假如某个车企的软件是按照这个流程开发出来的，就认为符合“车规”，软件的功能安全等级能够满足车辆安全要求。
正文
A-SPICE 3.0 总览：
%%%%%%%%%%%%%%%%% 分割线 %%%%%%%%%%%%%%%%%%%%
具体工程开发流程步骤（ENG）
现在知道汽车电子零部件供应商里的系统工程师角色来源了吧？
看SYS.1/SYS.2/SYS.3/SYS.4/SYS.5的流程定义，需要这么一个角色来cover对应着五个环节的任务。分别是：需求获取、系统需求分析、系统架构设计、系统集成和集成测试、系统确认测试。
按照开发步骤详细讲讲工程开发细节：
------------------------------------------------------------
需求获取：从客户获取客户需求，并确认需求被正确理解；
---------------------------------------------------------
系统需求分析：将已定义的客户需求转换为一组系统需求，用以指导系统设计；
过程成果：
a. 已经定义了系统需求；
b. 已经对系统需求进行了分类和分析以获取正确性和可验证性；
c. 已经分析了系统需求对运行环境的影响；
d. 已经定义了实现系统需求的优先级；
e. 系统需求能够根据需要更新；
f. 已经在利益相关者（客户等）需求和系统需求之间建立了一致性和双向可追溯性；
g. 利益相关者需求已经根据成本，进度和技术影响进行了评估；
h. 系统需求已经传达给受影响的各方并且达成了一致。
输出物包括以下几种：
需求分析报告（RAR, Requirement Analysis Report）,比如诊断、CAN通信、XCP、电源、KAM存储机制等模块的RAR分析报告。
系统需求说明书（SYSRS, System Requirement Specification），里面需要定义好功能需求和非功能需求。系统说明书的结构可是按照项目相关集分组，也可按照项目逻辑顺序进行排序，也可根据项目相关标准进行分类，还可根据客户要求来分类。
接口需求说明书（IRS，Interface Requirement Specification），定义各个系统模块之间的接口。例如：两个产品之间、过程之间或者过程任务之间的关联；双方共同遵守的准则及格式；关键时间依赖性或前后顺序；描述各个系统组件之间的物理接口，如总线接口（CAN、LIN）、收发器（类型、制造厂商）、附加接口（IEEE、ISO、USB等）、数字接口（PWM）和模拟接口等；识别软件与软件组件之间的接口，如进程间通信机制、总线通信机制等。
验证标准（Validation Specification）。具体内容包括：1. 每条需求都可验证或评估；2. 验证准则定义了验证需求时所遵循的定性及定量的准则；3. 验证准则标明进行需求验证时所遵循的已达成共识的约束条件。
审查记录（RR，Review Record）：需提供评审的上下文信息（内容、出席评审的人员列表、评审状态）、覆盖信息（checklist、review标准、需求、标准符合性）、检查发现（不一致性、改进建议）、记录信息（评审准备完成状态、评审准备所花时间、评审所花时间、评审人员和角色的评审意见）、识别所需的纠正信息（风险识别、偏差list、解决问题所要求的行动及任务、纠正措施的负责人、已识别问题的状态及目标关闭日期）
跟踪记录（TR，Traceability Record）：跟踪所有需求（客户需求和内部需求）、识别生命周期中的产品&需求之间的映射关系、需求和工作产品之间的连接关系（例如：需求-设计-代码-测试-交付）、在生命周期各阶段提供需求到相关工作产品之间的正向和反向映射
沟通记录（Communication Record）：信件、传真、电子邮件、语音记录、电报；
变更控制记录（Change Control Record）, 记录变更请求，生成基线化产品（baseline product）。具体包括：采用控制机制来控制正式项目的基线化产品（baseline）、变更请求记录（识别受变更影响的系统即文档、识别变更请求、识别变更的负责团队、识别变更的状态）、与相关客户请求及内部变更请求建立连接关系、适当的批准、对重复的请求进行识别和分组
---------------------------------------------------------
系统架构设计：建立系统架构，确定哪些需求分配给哪些系统元素，并根据定义的标准评估所设计的系统架构。 具体的：
a. 提供所有系统的设计；
b. 描述系统元素之间的相互关系；
c. 描述系统元素与软件之间的相互关系；
d. 详细说明每个必需系统元素的设计，需要考虑到以下内容：内存和容量的需求、硬件接口需求、用户接口需求、外部系统接口需求、性能需求、指令结构、安全及数据保护特性、系统参数设定、人工操作、可重用组件等
e. 系统元素与需求之间的映射关系
f. 描述系统组件运行模式（启动、停止、睡眠模式、诊断模式等）
g. 描述在不同运行模式下各个系统组件之间依赖关系；
h. 描述系统和系统组件的动态行为。
过程可能产生的成果：
a. 已经定义了系统架构设计，并已经标识了系统元素；
b. 系统需求已经被分配给了系统元素；
c. 系统元素的每个接口已经定义；
d. 已经定义了系统的动态行为目标；
e. 在系统需求和系统架构设计之间已经建立了一致性和双向可追溯性；
f. 系统架构设计已经传达给受影响的各方并且达成了一致。
------------------------------------------------------------------
软件需求分析Software Requirements Analysis：将系统需求的相关部分转换为一组软件需求
- 指定软件需求：使用系统需求、系统架构及以上两者的变更需求来确定所需软件的功能和特性。在软件需求规范中指定功能性和非功能性软件需求。只有在软件开发中，系统需求和系统架构才会设计到一个给定的操作环境。
- 结构化软件需求：结构化可以按照项目相关的集群分组，或者按照逻辑排序，或者按照相关标准进行分类，或者为干系人需求设置优先级。
- 分析软件需求：分析指定的软件需求包括他们的相互依赖关系、确保正确性、技术可行性、可验证性和支持风险识别。分析成本影响，进度和技术的影响。
- 分析对操作环境的影响：分析系统元素接口和操作环境对软件需求的影响；
- 开发验证标准：为每个软件需求开发验证标准，以便于每条需求验证可以定性和定量的度量。
- 建立双向可追溯性：建立系统需求和软件需求之间的双向可追溯性。建立系统架构和软件需求之间的双向可追溯性。
- 确保一致性：确保系统需求和软件需求之间的一致性。保证系统架构和软件需求之间的一致性要求。
- 沟通已确认的软件需求：沟通已确认的软件需求并为所有相关方更新这些软件需求。
输出物包括：
- 沟通记录；
- 审查记录；
- 变更控制记录；
- 追溯性记录；
- 分析报告Analysis Record：分析的内容、分析人、所采用的分析准则（选择的准则或采用的优先级计划、决策准则、质量准则）、记录结果（决定或选择的内容、选择的原因、做出的假定、潜在风险）、正确性分析的方面（完整性、可理解性、可测试性、可验证性、可行性、有效性、一致性、内容的充分性）
- 接口需求规格说明书（IRS）：更新细化
- 软件需求说明书（Software Requirement Specification）：识别适用的标准、识别软件架构考虑及约束条件、识别必需的软件元素、识别软件元素之间的关联关系、考虑给出以下信息（必需的软件性能特性、必需的软件接口、必需的安全特性、数据库设计需求、必需的错误处理及属性恢复机制、必需的资源消耗特性）
- 验证标准
--------------------------------------------------------
软件架构设计Software Architectural Design：建立一个架构设计和确定哪些软件需求分配给软件的哪些元素，并根据定义的标准评估软件架构设计。
过程成果：
- 定义了软件体系结构设计，确定了软件的元素；
- 软件需求分配给软件的元素；
- 定义了每个软件元素的接口；
- 软件元素的动态行为和资源消耗目标已定义；
- 建立软件需求和软件架构设计之间的一致性和双向可追溯性；
- 软件架构设计被所有受影响的各方达成一致并已沟通。
具体步骤：
- 软件架构设计：指定软件要素和相关方面的功能和非功能软件需求；软件在适当的层级分解为元素，并在详细设计中描述组件（所谓组件，指软件架构设计的最底层的元素）；
- 分配软件需求：分配所有软件需求到软件架构设计元素；
- 定义软件元素接口：识别、开发和文档化软件元素之间的接口；
- 描述动态行为：参照系统动态行为，评估和文档化软件元素间的时序和动态交互行为。（动态行为是由操作模式确定的，如启动、关闭、正常模式、校准、诊断等等；进程和进程内部通信、任务、线程、时间片、中断等。另外，在评估动态行为时，目标平台和潜在载荷应被考虑）；
- 定义资源消耗目标：在软件架构设计的适当层级，为相关元素定义并记录所有软件组件的资源消耗目标。（资源消耗通常被明确为资源，诸如内存ROM、RAM、外部/内部EEPROM或Flash数据，CPU负载等）
- 评估可替代的软件架构；
- 双向可追溯性（需求与架构之间）
- 确保一致性
- 沟通已确定的软件架构设计
输出物：
- 软件架构设计：包括内容有：
a. 软件架构整体描述；
b. 包含任务结构的运行系统描述；
c. 确定任务与进程之间的通信；
d. 识别必需的软件元素；
e. 识别自主开发及供应方提供的代码；
f. 识别软件元素之间的关联及依赖关系；
g. 确定数据存储及灾备方案；
h. 描述不同模型系列或配置如何衍生出产品变体；
i. 描述软件的动态行为（启动、关闭、软件升级、错误处理、恢复）；
j. 确定数据存储位置及数据损坏的预防办法；
k. 描述哪些数据是在什么情况下是持续存在的；
l. 还要充分考虑以下内容（软件必需的性能特性、软件必需的接口、软件必需的安全特性、数据库设计需求）
2. 接口需求规格说明书
3. 跟踪记录
4. 审查需求
5. 沟通记录
-----------------------------------------------------------
软件详细设计和单元实现Software Detailed Design and Unit Construction：步骤几乎以以上步骤完全一致...
-------------------------------------------------
软件单元验证Software Unit Verification：软件单元测试过程的目的是验证软件单元，证明软件单元符合软件详细设计和非功能性软件需求。
过程成果：
- 指定了包括回归策略在内的软件单元验证策略；包括软件单元发生变更时重新验证的回归策略。验证策略应定义如何证明软件单元符合软件详细设计和非功能性需求。单元验证的技术可能包括静态/动态分析、代码审查、单元测试等。
- 根据软件单元验证策略开发软件单元验证标准，该策略适用于证明软件单元提供符合软件详细设计和非功能性软件需求；单元验证标准可能包括单元测试用例，单元测试数据，静态验证，覆盖目标和编码标准；单元测试规范可以实现诸如作为自动测试台中的脚本。
- 根据软件单元验证策略和软件单元验证标准对软件单元进行验证，并记录结果；其中，静态验证可能包括静态分析、代码审查、针对编码标准和指南的检查以及其他技术。
- 在软件单元之间建立一致性和双向可追溯性，验证标准和验证结果；
- 汇总单元验证结果，并传达给所有相关方。
输出物包括：
- 测试规范说明书 Test Specification：包括测试设计规格书、测试用例规格书、测试过程规格书、识别回归测试的测试用例；对于系统集成测试，要识别必需的系统要素，例如硬件要素、接线要素、参数设定和数据库等；识别系统元素集成必要的序列或排序
- 测试计划Test Plan：分级的测试计划、测试策略（黑盒/白盒测试、系统边界测试、回归测试策略等）；如有必要，编制综合测试计划
- 验证结果及测试报告Verification Result and Test Report：验证checklist、通过的项、失败的项、待验证的项、发现的问题issue、风险分析、解决方案、结论、签名确认。测试报告按照要求，形成测试日志分级、形成异常报告、形成测试报告分级。
- 分析报告Analysis Reprot
- 三记录（沟通记录、审查记录、跟踪记录）
------------------------------------
软件集成和集成测试Software Integration and Integration Test：将软件单元集成到更大的软件项目中，直到形成与软件架构设计一致的完整集成软件，并确保软件项目是经过测试的，可以证明包括软件单元之间和软件项目之间的接口在内的集成软件项目符合软件架构设计。
步骤：
- 开发软件集成策略
- 开发包括回归测试策略在内的软件集成测试策略
- 制定软件集成测试规范。软件集成测试用例可能关注：软件项目间的正确数据流、软件项目间的数据流的及时性和时间依赖性、使用界面对所有软件项目数据的正确解释、软件项目间的动态交互、符合接口的资源消耗目标
- 集成软件单元和软件项
- 选择测试用例，要有足够的覆盖度
- 执行软件集成测试
- 老三样（双向可追溯、确保一致性、总结和交流经验）
输出物：
- 软件项，两大块，一个是集成的软件，一个是文档。集成的软件可分为：源代码、软件元素、可执行代码、配置文件；文档包括：描述和识别源代码、描述和识别软件元素、描述和识别配置文件、描述和识别可执行代码、描述软件生命周期状态、描述归档和发布标准、描述软件单元编译、描述软件组件的构建
- 集成的软件：多个软件组件的集合。这里的软件一般是针对某一特定ECU配置的一组可执行文件以及有关的文档和数据。
- 测试老三样（说明书、计划、报告）
- 记录老三样（沟通、审查、追溯）
- 构建列表Build list: 识别软件应用系统的聚合、识别所需的系统元素（参数设定、宏程序库、基本数据、作业控制语言等）、识别软件编译时必需的顺序序列、识别输入输出资源库。
-----------------------------------
软件确认测试Software Qualification Test：确保集成的软件已经过了测试并满足软件需求。与上一步几乎相同。
-----------------------------------
系统集成和集成测试System Integration and Integration Test：集成系统项以生成集成系统，符合系统架构设计并确保系统项被测试，用以证明集成的系统项与系统架构设计的一致性，包括系统项之间的接口。
- 开发包含回归测试策略的系统集成测试策略；
- 开发系统集成测试规格说明书，包含：根据系统集成测试策略的每一个系统项集成阶段的测试用例。有四个需要注意的点：a. 接口描述系统元素和系统集成测试用例的输入关系；b. 符合架构设计：指定的集成测试能够适时证明，系统项间的接口满足系统架构设计提供的规范。c. 系统集成测试用例应关注：系统项间正确的信号流、系统项间信号流的及时性和时序、使用一个接口信号的所有系统项的正确解释、系统之间的动态交互关系；d. 系统集成测试可能支持使用仿真环境（硬件在环仿真、车辆网络仿真、数字样机）。
- 集成系统项；按系统集成策略，整合系统项，形成集成系统。系统集成可以逐步执行集成系统项（例如，作为原型硬件的硬件元素、外围设备、传感器、执行器、结构和已集成的软件），生产出与系统架构设计保持一致的集成的系统。
- 选择测试用例：从系统集成测试规范说明书中选择测试用例。有足够覆盖率。
- 执行系统集成测试
- 老三样（双向可追溯、确保一致性、总结和交流经验）
--------------------------------------------
系统确认测试System Qualification Test：确保集成的系统已经测试，为符合系统需求和系统准备交付提供依据。与上述步骤大同小异，略。
%%%%%%%%%%%%%%%%% 分割线 %%%%%%%%%%%%%%%%%%%%
具体支持流程步骤（SUP）
一、质量保证流程 Quality Assurance（SUP1）
目的：为工作产品和流程严格按照预定义的规定和计划提供独立的、客观的保证，并解决和预防不符合性的情况。
- 开发项目质量保证策略；主要是保证工作产品和质量保证在项目层面独立、客观且无利益冲突地执行。所谓独立性，可能是财务或组织架构的独立。质量保证可能协调并利用其它流程的成果，比如核查、验证、联合评审、审计与问题管理。流程质量保证包括流程评估和审计，问题分析，定期检查的方法、工具、文档和流程定义的坚持，报告和经验教训，为未来的项目改善流程。工作产品质量保证包括评审、问题分析、报告和经验教训，来改善未来的工作产品。
- 确保工作产品质量；相关工作产品的需求可能包括适当标准带来的需求。被发现的不符合的工作产品会进入问题解决流程（SUP9），并被归档、分析、解决和追踪以关闭问题并预防。
- 保证流程活动的质量；按照质量保证策略和项目日程表执行流程活动质量保证，以确保活动契合既定目标并把结果归档。相关过程项目标可包括从适当标准带来的目标；在流程定义或实施过程中发现的问题可进入流程改善流程（PIM3），以描述、记录、分析、解决和追踪，最终关闭问题并预防。
- 总结和沟通质量保证活动和结果；根据质量保证策略，定期给相关责任人报告性能、偏差和质量保证活动的趋势以获取信息和行动。
- 确保不符合项的解决；应当就过程和产品的质量保证活动中发现的不一致和偏差进行分析、追踪、纠正并预防的工作。
- 实施质量问题升级机制；根据质量保证策略建立一个渐进式管理机制，以确保可以将问题升至合适的质量保证管理等级和其它利益攸关方来解决问题。
输出物清单：
- 质量计划：a. 质量目标；b. 定义保证质量所需的活动任务; c. 参考相关工作产品; d. 质量评估/保证的方法； e. 参考法规要求、标准及客户需求；f. 识别预期的质量标准；g. 为定义的生命周期和计划的相关活动指定监控时间表及质量检查点; h. 以达到预期质量为目标设立时间表；i. 实现目标的方法：需要执行的任务、任务负责人、需要执行的审计、资源承诺；j. 识别工作产品和过程任务的质量标准。k. 指定采取纠正措施前允许的门限/耐受度；l. 定义质量度量和基准数据；m. 定义质量记录采集机制和采集时机；n. 指定质量报告对过低质量所影响过程的反馈机制; o. 由质量责任机构/部门的批准；p. 定义质量保证（QA）的独立性；q. 确定升级机会和渠道; r. 定义客户与供应商质量保证之间的协作。
- 质量记录；定义需要保罗的信息；定义产生信息的任务/活动/过程；定义数据收集日期；定义相关数据来源；识别相关质量准则；使用信息识别相关的度量；识别创建记录或记录需要满足的、需要遵循的任何需求。
- 审查记录：略
- 问题记录：识别问题报送人的姓名与相关联系细节；识别负责修复问题的组织/人员；包含问题描述；识别问题的分类（严重度、紧急度、关联性等）；识别已报告问题的状态；识别问题修复的目标发布版本；识别问题的预期关闭日期；识别问题关闭准则；识别问题复验活动。
- 纠正措施记录：识别初始问题；识别行动项的负责人；定义解决方案（为解决问题而采取的一系列行动）；识别问题发现日期及期望关闭日期；包含状态指示器；标明后续的审核活动。
- 质量标准。定义对质量的期望。建立工作产品充分程度的准则（必需元素、预期的完整性、精确度）；识别构成已定义任务的完整性的内容；建立生命周期变迁准则，以及每个已定义过程/活动的准入准出条件；建立预期的性能属性；建立产品可靠性属性。
---------------------------------------
二、配置管理 Configuration Management（SUP8）
配置管理流程，是为了建立和维护所有流程或项目工作产品的完整性，并提供给相关干系人。
- 开发配置管理策略，包括： 职责和资源、工具和存储库、对配置项及其命名规范的识别、权限、配置项的历史和基线（需要/可选的基线；命名规范；分支方法、合并以及建立基线；发布和批准基线）。配置管理策略通常为了配合商务搞的不同版本的产品（Variants变种）配置管理。
- 识别配置项；软件开发的配置项通常是：配置管理计划；需求文档、架构和设计文档；软件开发环境；软件开发计划；供应商协议；质量保证计划；软件单元代码和文档；应用参数；测试用例和测试结果，评审记录；编译清单，集成报告；用户手册。硬件和结构也可以有配置项，例如硬件布局、图纸、电路板、物料清单等。
- 建立分支管理策略。指定分支管理策略，适用于使用相同源码基线进行并行开发。分支管理策略列出了关于何种情况下允许分支，是否需要认证，分支如何合并，需要怎样处理以确认所有变更在未央及其他变更和原生软件的情况下相容地集成到一起。
- 控制修改和发布。根据配置管理策略建立配置项控制机制，并使用此机制控制修改和发布。
- 建立基线（baseline）。根据配置管理策略建立内部和外部交付基线。
- 报告配置状态。记录并报告配置项状态，以便于支持项目管理和其他相关流程。
- 核实配置项信息。例如评审。
- 管理配置项和基线的存储。
输出物：
- 配置项：包含模块、子系统、函数库、测试用例、编译器、数据、文档、物理介质和外部接口。除此之外，配置项还要有版本维护相关信息。一般建立配置项表格时，需要包含配置项类型、相关配置管理库/文件/系统、责任人、置于配置管理控制下的日期、状态信息（例如：开发阶段、已打基线、已发布）、与下一层配置项的关联关系、变更控制记录的识别、变更历史的识别
- 处理和存储指南：定义以下任务来实现产品的处理和存储：提供原版代码副本及文档、灾难恢复方案、登记关键安全性问题；提供描述来指导如何存储产品：所需存储环境、使用的保护媒介、所需包装材料、存储项、评估存储产品；提供恢复指南
- 配置管理计划：定义或引用流程来控制配置项的变更；定义度量标准来确定配置管理活动的状态；定义配置管理审计标准；由配置管理职能部门批准；确定配置库工具或机制；含有控制项历史及状态的管理记录及状态报告；为配置管理库指定位置及访问机制；指定存储、处理及交付机制。
- 恢复计划：识别恢复项，如执行恢复的规程和方法；恢复的时间表；关键的依赖关系；恢复所需的资源；备份维护列表；负责恢复的人员及分配的角色；所需特殊材料；所需工作产品；所需设备资源；所需文档；备份的存储位置；恢复的通知人联系方式；验证步骤；恢复的成本估算。
- 基线：标识一致且完整的一条或一组工作产品和工件的状态；下一个过程阶段的基础；唯一的且不能更改的。
- 配置管理记录（工作产品或工作项的修改状态；识别配置项；识别要执行的活动，例如备份、存储、归档和交付配置项；维持产品一致性）
- 变更历史（变更描述、变更对象的版本信息、变更日期、变更发起人信息、变更控制记录信息）
- 配置管理系统
-----------------------------------------------
三、解决问题管理
-----------------------------------------------
四、变更请求管理
------------------------------------------------
五、项目管理
------------------------------------------------------
六、供应商监控