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.  操作,服务和生产

你可能感兴趣的:(安全架构)