APQP，ASPICE，敏捷，功能安全，预期安全，这些汽车行业的一堆标准

前言

APQP,ASPICE,敏捷，功能安全，预期安全，PMP，PRICE2汽车行业的有这样一堆标准。我是半路出家来到汽车行业做项目经理的，对几个标准的感觉是，看了文档和各种解析之后还是一头雾水，不知道到底说了个啥，别人问我还是一脸懵逼。

APQP（TS16949的最重要工具），ASPICE（软件）这些是质量标准，是优化整个公司体系的，但这套体系对项目管理有要求；

敏捷，PMP这些是项目管理的标准；项目管理中包含质量保证和质量控制；

功能安全，预期安全，这些都是针对产品的，但是要开发出符合功能安全和预期安全的产品，得从流程上下功夫，比如质量和项目管理。

一. APQP

APQP是TS16949的五大工具之一，起到贯穿始终的作用（其他四个工具在APQP的不同阶段，DFEMA和PFEMA分别在设计和量产阶段，MSA在导入生产的时候得对测量系统进行分析，SPC就是对工艺过程进行控制，PPAP就是在量产阶段提交客户批准，前面三个也在PPAP提交的资料里），它的主要思想是把汽车零部件的开发流程分成5个阶段，计划和确定项目阶段，产品设计和开发，过程设计和开发，产品和过程的确认，以及反馈评定和纠正措施阶段；然后规定了每个阶段必须得有的输出。比如计划阶段得有项目管理计划，像时间，质量，需求，范围，预算之类的规划；设计阶段得有对需求的评估，对技术提案的评估，得有DFEMA，设计图纸，图纸上得有更改历史，得有CCSC的列表，DVP以及DV结果等；过程设计阶段得有PFEMA，PVP，PV结果，MSA, SPC, CPK，PFC，WI，RUMP-UP，PPAP等；SOP阶段得有遗留问题清单等等；APQP中并未直接提出对软件开发管理的方法，不过这套灵活的体系是支持对软件的管理的，就是如果你有其他管理软件的体系，比如ASPICE，它和APQP不矛盾，可以互相兼容。

二. ASPICE

ASPICE全称是汽车软件过程改进及评审，这个名称说明它除了对软件开发流程进行改进，还要进行评审。就是告诉你要做哪些事，做的好不好的标准是什么，你这水平能评LEVEL几。其中过程参考模型，就是告诉你要做哪些事，大概是三大类，包括主要生命过程，组织的生命过程，和支持生命过程。这三大类又分11个组，32个子过程。主要生命过程包括系统，软件，采购和供应管理，现在改版后还增加了硬件和机器学习。注意主要生命过程中的获取过程组主要由销售主导，从客户那边获取信息，确保我们准确地理解并转化需求。而供应过程组是技术或生产部门主导，主要研究怎么满足客户的需求。除此之外还有支持生命过程，包括质保，文件配置管理，问题解决管理，变更和机器学习数据管理。组织生命过程包括项目管理，风险管理，测量（和主要生命过程中的测量测试不一样，这里不是衡量产品的，而是衡量我这个管理做的怎么样），过程改进，产品重用等。每个子过程都被分成几个BP和GP，每个BP和GP的完成度决定了整个体系的level。其中BP在LEVEL1中出现的，而且在更高LEVEL中就不会增加了。

其中过程评估模型分为过程实施指标和过程能力指标

过程实施指标：只适用LEVEL 1，包括BP（基本实践）和WP（工作成果），和特定过程相关的，而且是最基本的要求，就是只要你实施了这些BP，LEVEL1就算达标了。你有可能把项目做成功，但仅仅是瞎猫碰死耗子成功的，还没摸到管理的门道，掌握了管理的门道，那以后就会把把能赢。

过程能力指标：适用LEVEL 2-5，包括GP（通用实践）和GR（通用资源），与一个或多个得分点相关（PA），通用类型。上面的BP只是基操勿六，得实施这些GP，才会给你评能力，一般认证都只做LEVEL2级别，主要看其中挑出的16个子过程实施地如何。

三. 敏捷开发

PMP讲的那些方法适合大项目，但敏捷开发开发主要适用于需要灵活管理的软件项目。敏捷也是一个大的方法论，它的具体方法有SCRUM和kanban。

1. SCRUM

SCRUM是橄榄球的一个犯规后的罚球行为，罚球相当于重启一下比赛，要在每个罚球中取得优势，需要队员们互相配合，类似于软件开发中定期迭代开发和部署所做的项目管理动作。整个项目被叫做史诗（EPIC），每个需求被叫做故事（STORY），就是可以在一个2-4周地短时间内完成的任务；这个2-4周的短周期称为sprint（冲刺），在这个sprint中要求完成一组功能地开发测试和部署。scrum框架包含三个角色（产品负责人、Scrum Master 和开发团队）、三种会议（Sprint计划会、每日站会和Sprint回顾会）和三种工件（产品待办事项清单、Sprint待办事项清单和增量）。

2. KANBAN

KANBAN听起来像中文里的“看板”，实际是日语，但意思确实是中文中看板的意思。作用是将工作可视化，看板分成多个列，比如待处理，进行中，完成等。可以将任务在这几个列中流转。kanban和scrum不同，适用于持续输出的场景，而scrum则是适用于可以明确划分为小项目或迭代周期的工作。当然可以将KANBAN（流动性，可视化管理）和SCRUM（结构性和规律性）结合起来，使工作更加可视化，叫做Scrumban。比如把整个项目工作流程分成待办，进行中，待审查和完成，并用任务用看板的形式展示出来（jira）。

敏捷是日本人提出的，美国人系统化的，类似于精益制造和6sigma的关系。精益制造是日本人提出的，可以全员参与，减少浪费，搞5S之类的，但这些只是逼格不高的经验集成，美国人会把这些经验搞成高大上的统计学方法论，什么标准偏差之类的，就升华了，普通工人就理解不了了，更厉害了。

敏捷强调灵活，认为个体和互动高于流程和工具，工作的软件高于详尽的文档。看起来不像SPICE那种有完备方法论的体系那么稳当可靠。但敏捷还是有办法来保证质量的，比如：

1. 持续集成和自动化测试（CICD），就是每天都集成，并且自动化测一下子，这样可不质量就上来了，而且自动化的，效率提高了，符合敏捷的优势；

2. 测试驱动开发（TDD），开发人员先编写失败的单元测试案例，然后编码让测试通过，再重构编写的代码。

3. 定义明确的完成标准（DoD,Definition of Done）。就是先定义一组条件，只有这组条件被满足了，任务才算是完成。

4. 代码审查和对等编程，同事之间互相审查代码，两个人在一台电脑上工作，一个人编（驾驶员），一个人审（观察员），看起来有点浪费，但可以显著提高开发质量和效率。

5. 敏捷反馈循环，鼓励快速反馈循环，包括客户，用户，团队成员，迭代评审会和日常沟通来进行反馈；

6. 迭代和增量开发，项目以小块功能的形式逐步构建，确保每个增量的质量。

7. 团队责任和透明度，scrum团队都是自我管理，敏捷三个主要角色中，都没有项目经理，人人都兼任项目经理的一部分职责（作为项目经理，我一直在问chatgpt，我学这个有什么用），人人对质量共同负责，日常站会，看板，和敏捷追踪工具可以增加工作透明度，清楚当前进展和潜在问题。

8. 用户接受测试（UAT），软件发布前邀请用户进行测试。

3. 敏捷和ASPICE的结合

但是如果在汽车行业中要应用敏捷开发，它自带的这些质量工具就不够用了。毕竟汽车行业对安全性和稳定性有更高的要求，所以对流程要把控多一些才能保证质量。许多组织都将ASPICE和敏捷开发结合起来提高敏捷开发的质量，但是至今并没有一个官方的统一的方法（包括敏捷自身也没有一个官方组织，只有一个敏捷宣言，后面就是各搞各的，搞PMP的那个组织PMI也搞了个敏捷认证），每个组织各自有各自方法。具体建议如下：

1. 标准化的开发流程和最佳实践，如需求工程，软件设计，编码，测试，维护等，确保规范性和可追朔性；

2. 严格的需求管理和变更控制，如需求评审，追踪，控制和变更审批机制；

3. 详尽的文档记录和可追溯性，尽管敏捷对文档要求不高，但汽车行业中对合规和可追溯的要求比较高，否则就违规了；

4. 风险评估和管理，风险的识别和评估流程；

5. 质量保证和测试，整合敏捷中的测试驱动开发，CI和ASPICE中的系统级验证，确认要求相结合；

6. 持续改进和学习，定期评估等；

7. 项目管理和迭代开发，敏捷中不需要项目经理了，但是ASPICE是需要的，可以把敏捷的sprint定义为项目中的阶段和里程碑，确保每个迭代都生成可审计和可评估的工作产品。

 四. 功能安全和预期功能安全

1. 两个安全的概念

功能安全（FS，function Safty，ISO26262）和预期功能安全（SOTIF,Safety of the Intended Functionality，ISO/PAS 21448）

功能安全的目标是确保系统出现故障的时候能够保证安全地失败，避免伤害和损失（比如自动驾驶用的摄像头出故障了，怎么防止造成危害）；预期功能安全的目标是让产品在没有故障时也不要因为设计限制，环境因素或用户交互导致风险（比如摄像头在下雨天就算没出故障也看不清路面，这时怎么办）。虽然它们主要针对产品的安全性保证，但是对项目和质量管理的要求也非常严格和具体，要求组织在管理体系，流程，工具和技术等方面进行相应的配置和优化。

这相当于学校为了学生能考上好大学，原本已经制定了一套体系，后来教育局又说要保证素质教育，所以学校又在原来那套体系上又加了点新规定，比如必须有美术绘画体育等课程。这两大安全对质量和项目管理的要求如下：

2. 两个安全对质量管理的要求：

1. 安全生命周期管理，除了要定义一个明确的安全生命周期，安全目标的定义、风险评估、安全需求、设计、实现、验证、操作到退役等各个阶段，都必须按照规定的安全标准执行。连工厂生产，到司机个人操作这些都得考虑到。然后质量管理系统也必须覆盖这些阶段，能够监控和验证每个阶段的安全相关活动和产出。

2. 风险评估和管理，要实施有效的风险管理流程，包括分析，评估和缓解措施；

3. 文档和记录，包括设计文档，测试报告，风险评估报告，合规性证明；

可以看出来这些要求原本的体系里都有，FS和SOTIF是扩展了它们的范围，不局限于原来的那些；

3. 两个安全对项目管理的要求：

1. 项目规划，必须为安全相关的活动规划资源和活动，比如安全分析，设计审查，测试和验证等；

2. 资源分配，得有安全相关的资源，如人员，工具和技术支持，如安全工程师，人机交互专家；

3. 沟通和合作：还是在安全关键的决策和变更管理过程中；

4. 持续改进：包括事故和差错报告系统来识别潜在的安全缺陷等；

4. 功能安全的活动和输出

负责人：安全经理和安全工程师等

1. HARA，hazard Analysis and risk assessment：分析可能导致危险情况的潜在故障源，评估影响和概率；

2.  Safety Plan：制定一个详细的安全计划，描述实现和维护所需安全目标的过程和活动，即输出一个功能安全计划文档；

3. Function Safety Concept：基于风险评估结果，开发一个包含所有必要安全需求的安全概念，功能安全概念规范；

4. Technical Safety Concept：详细描述如何在系统和组件级别实现安全需求的技术安全概念

5. Safety Verification and Validation：验证和验证报告。

5. 预期功能安全的活动和输出

负责人：SOTIF经理，系统工程师等

1. Identification of Triggering Conditions:识别在正常操作中可能导致非预期行为的条件，即触发条件清单；

2. SOTIF safety Analysis：分析和评估在已识别的触发条件下系统可能表现出的不安全行为，即SOTIF安全分析报告；

3. Development of Mitigation Measurement：开发措施以减轻或消除已识别风险的潜在影响，即风险缓解措施文档；

4. Verificaiton of Effectiveness：措施有效性报告

6. 功能安全标准的解读：

1. 首先定义项目，就是对项目功能，接口，法规，危险等内容的一个整体描述，以便从整体描述中抽象出功能安全；

2. 然后是安全生命周期的初始化，是新项目还是老项目，老项目

3. 进行危险分析和风险评估，主要从发生问题的严重性，暴露的可能性和可控性三方面来定级，分成ASIL级，设立安全目标

4. 功能安全概念，有了安全目标，构建基本框架，对功能安全要求进行细化。比如如何检测故障，或进行失效环节，故障容错等，指定ASIL等级，合理分配到子系统中。

5. 系统级产品研发

6. 软硬件的研发

7. 还要考虑其他方面，比如用户的操作，产线生产，其他技术(机械等)，可控性（证明不在26262范围中）和外部措施

8. 产品发布

9. 生产

10.  操作，服务和生产