KGAS - AutomotiveSPICE - Formula Q | 理解与应用

本文主要讨论了VW大众Formula Q和KGAS软件开发基础要求的相关内容和感想,并讨论了在软件开发质量管控过程中,关于AutomotiveSPICE和KGAS融合执行的相关见解,并再次强调了过程改进过程中,管理层意识对于项目推进的重要性。
 
作者:David Liu @ FUSA Solutions
版权声明:本文为FUSA Solutions专家原创,未经事先书面许可,任何第三方不得随意转载。本文代表作者个人意见和经验总结。
 
近期有朋友在问关于VW大众Formula Q和KGAS相关要求和具体执行方法的问题,本人基于前期浅薄的认知,特此总结并列明如下,欢迎各位专家指正。
 
Formula Q - Capability Software Requirements
 
Fomula Q主要是定义VW大众集团如何识别和支持软件产品供应商, 主要包含VW大众在QA方面的相关管控活动的要求,以及QA具体管控措施的要求,也包含了针对供应商软件开发质量管控相关评估要求,以及具体的支持和推动供应商进行持续改进的要求。具体执行中,包含了LiSA供应商自评要求,潜在供应商评审和针对具体供货项目的SWA Formula Q正式评审等相关要求。Formula Q同时也引用了一些其它参考要求,如KGAS等。
 
在前期相关OEM车厂对用供应商的评审中,绝大多数的供应商评级为红灯,较少部分供应商评级为黄灯,几乎没有供应商能够得到绿灯的评级。其实,并不是说国内企业做的不好,也不是说OEM的要求具体有多严格,这样的结果,主要还是因为国内供应商对于德国企业提出的要求,还是没有理解透彻。换句话说,是文化或者意识上的差异。
 
例如,前期我们在各种AutomotiveSPICE项目当中不断的强调,AutomotiveSPICE主要是德国人搞出来的,大部分德国车企或者Tier1的项目都要求去做AutomotiveSPICE。那德国人为什么要搞这个东西,是希望为难大家吗?是技术壁垒吗?是啤酒喝多了,大肘子吃咸了,没事闲的要增加开发成本吗?….NO, 我们认为核心原因是: 汽车这种产品前期确实出现了一些问题:大笔罚款,股价下跌,身价缩水,车辆召回…真出了大事,OEM的CEO甚至不得不黯然下台。
 
核心的原因还是来源于OEM的焦虑,担心软件质量出问题,担心车卖出去会出伤亡事故,担心真出问题Tier1双手一摊说软件团队已经都走了,我们现在也没有办法解决,大家一块等死吧。所以,供应商说AutomotiveSPICE流程模板我都有,就是没时间按照模板流程来做。或者提出我们去年给BMW做到L3了,今年你们奔驰为什么还要让我们重新审核….等等各种疑问,我相信Tier1们自己想想也一定能够得出正确答案。
 
很多Tier1的老板们,没有真正在思路上认识到AutomotiveSPICE,具体应该是个什么思路,执行起来具体是个什么套路,具体应该如何去玩。
 
AutomotiveSPICE认证本身确实重要,但是最大的意义是在项目开发中,踏踏实实的,去按照流程去做,去做持续改进,去保存各种证据文件记录,去解决领导们只要晚上睡觉听到手机响,马上就血压飙升的问题。中国确实几千年来对于证书这个玩意太看重了,所以现在业内出现了6个月快速拿证的项目。我想问,您在开玩笑吗?
 
OEM要求做AutomotiveSPICE,不是要让各位Tier1拿张证书挂在网站上广而告之,而且在每个具体的开发项目中,真正按照AutomotiveSPICE流程要求去执行了。AutomotiveSPICE要是像这么去玩 (原来还有国内OEM问:3个月内能不能搞定L3级认证?),那请各位Tier1千万不要浪费这个钱,欧系OEM会认为Tier1在意识认知上存在不可调和的偏差项,一定会被OEM怼的。
 
KGAS - Group Basic Requirements for Software
主要是定义了VW大众供应商在软件方面比较基本的需要满足的要求,e.g:开发流程要求,产品技术要求, 组织架构要求, 具体的开发活动要求等。
 
关于KGAS的要求一部分个人感想:
 
1.KGAS是VW大众和供应商供货合同的一部分,是具备法律效力,而且对于所有VW大众关联公司(狼堡大众,南北大众,大众中国等等)都是有效的
[备注:如果涉及向以上各方同时供货的供应商,需要同时与各方协调好相关要求和工作流程]
 
2.KGAS是针对供应商软件开发质量管控的基础要求,其中定义了软件开发的文件输出物和建议的开发流程管控要求
[备注: KGAS是VW大众对于供应商软件开发的最基本要求,同时需要考虑与其他软件开发流程, e.g. Au-tomotiveSPICE, ISO 26262 等软件成熟度模型或者软件安全开发要求的协调]
 
3.最新版本的KGAS(V3.2)已经于2018年12月更新颁布,其中一个比较大的变化是新增了信息安全方面的相关要求
 
[备注: 这个时间和ISO 26262:2018的颁布时间如出一辙,在2018年圣诞节前曾经怀疑过ISO 26262:2018 究竟会不会被拖延成ISO 26262:2019。新版KGAS中新增的要求包含:基础信息安全要求,信息安全管理体系,信息安全威胁分析和信息安全概念设计,信息安全攻击树或者攻击链条分析,信息安全架构设计和信息安全详细设计,信息安全验证和确认,信息安全安全文档证据总集……等等。
 
个人感觉,其实里面大篇幅引用了ISO 27001信息安全管理体系, TISAX信息安全交换机制和ISO/SAE 21434道路车辆信息安全工程开发标准的相关要求,当然,里面另外也会包含VW企标80180-1和80180-2的相关要求。
 
而且今后执行AutomotiveSPICE中,无论是项目管理域还是独立QA域,对于信息安全开发 (是否有明确的信息安全目标,是否有独立QA流程关注信息安全等) 是否能够提供充分支持等基本流程策略和具体开发落地实践,都会是新的挑战和新的关注点。
 
最后一个比较值得关注的是Cyber Security Incident Management信息安全应急响应机制的要求, 这一条目前是各大车企普遍比较关注的问题点。究其原因,看看2018年某总部位于德国的OEM,在应对信息安全相关事件的影响和修复时间周期,就完全可以理解了]  
 
4.KGAS同时适用于直接或间接应用于车辆功能控制的软件开发项目中
 
[备注: 如果该条款被严格执行的话,不知道曾经或者正在追随等各位互联网大佬们,依靠不断创新,不断突破自我;早已经习惯了快速迭代开发,早就认同迭代速度为王的各位码农们,看到KGAS,看到AutomotiveSPICE等各类来自老牌德国车企定义的相关要求之后,会不会觉得无所适从,会不会感到无从下手?而且在这个问题上,各方都有自己的苦衷,OEM车厂要保证产品质量,互联网企业需要以靠快速迭代满足用户的各类需求,没有谁对谁错,只是双方需要寻求一个平衡点,这个问题还需要行业内各方面专家多多交流,互通有无]
 
5.KGAS要求在开发中,必须有独立的QA组来协调和持续监控软件开发流程和软件开发质量管控
 
[备注: 一个比较合理的理解是:有独立的QA实体小组或者独立QA部门最好,退而求其次的方法是至少有这么一个职能小组。在具体开发实践当中,需要有一些变通但必须行之有效的做法,否则我们试问一下:目前大部分互联网企业QA和OEM车企QA,在职能细节,在具体工作内容和工作方式上,具体差距会有多少海里?
 
另外,在AutomotiveSPICE SUP.1 过程域当中也提出了类似的要求,但是即使在传统的Tier1企业开发实践当中,真正做到独立QA,真正独立管控贯彻到位的,应该也没有多少。原因嘛,大家心知肚明,却又心照不宣]
 
6.KGAS要求在开发中,必须有明确的软件质量衡量指标(e.g.圈复杂度限制),以及具体且明确的的Coding Guideline
 
[备注: 圈复杂度指标其实在ISO 26262或者AutomotiveSPICE中都有引用,尤其是ISO 26262 第6章节的前面几个表格中,在不断强调各种各样的简化设计要求 (如下图所示),但是在实际的开发实践当中,真正能够将复杂度控制的不错的企业确实不算太多。
 
 
 
关于Coding Guideline的问题,前期我们在各种研讨会当中也在不断强调,其实无论是MISRA-C也好,部分开发IVI的朋友们应用Google Guideline也好,其实核心的问题是到底是否充分的应用了相关Guideline,而不是表面说用了,但是实际开发原来该怎么玩还是怎么玩。在KGAS具体执行或者评审中,还是要结合着AutomotiveSPICE来做,毕竟AutomotiveSPICE能够给软件质量管控甚至包含功能安全和信息安全,提供很好的基本支持。在有些项目中,KGAS和AutomotiveSPICE审核在一定程度上,是可以结合在一块来进行的。
 
总结:
 
1. 软件质量的话题太大了,但是有一点是可以肯定的,未来的OEM将普遍向软件公司的方向去发展。
2. 重视软件质量管控, 重视AutomotiveSPICE, 重视独立QA, 重视KGAS, 重视Formula Q, 重视ISO 26262....这个重视,是必须要体现在行动上,而不是仅仅放在舌尖上……
3. 在执行相关的软件质量流程改进方面,最重要的因素是必须有管理层的理解和支持,否则很难落地。