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：将系统需求的相关部分转换为一组软件需求

1. 指定软件需