从ISO26262看缺失的系统设计.docVIP

从ISO26262看缺失的系统设计 （一）功能安全与系统设计 翻开ISO26262 Ed. 1(2011)与ISO26262 Ed. 2 (2018)，当中有些许显著不同的地方。其中一处便是发生在系统开发阶段的要求：第一版在安全合规交付物的产出中，要求输出System Design Specification（系统设计规格）；第二版仅只是客气的提及System Architecture Design Specification（系统架构设计规格）。 为啥会有这样的变化？这种变化又代表何事？ 首先，汽车业在经过多年的系统工程方法论洗礼（如A-SPICE）及功能安全导入经验之后，多半已认识到「安全」仅只是系统的一个属性，尽管这个属性在某些系统开发工作中被视为是最重要的属性（下图为笔者在迪拜参与自动驾驶研讨会时，现场参与嘉宾投票的自动驾驶落地最重要关键要素为何：明确可见，安全的地位比技术亮点本身还高许多）。 除了这个属性，依照系统功能的不同，系统还要能照顾到其他许多属性。诸如，当我们谈论的是动力总成相关系统时，「可靠性」与「舒适性」也是必须要照顾到的属性；当目标是仪表显示系统时，「直观易理解」则是重要的系统属性。 ? 既然安全始终就只是系统的一个属性，我们在实施安全标准的时候，若把完整的系统设计及与其相关的系统设计规格定义成为符合安规的必要交付物，似乎就显得小题大做与不知所谓何事。然而，系统的全貌及方方面面确实会跟安全特性之间有某种程度的耦合关系：一个HMI人机接口设计的不够人性化，不只是难用而已，可能也会因为安全报警的不清楚而影响到安全性；AEB设计的强度阶梯变化很舒适，但也可能造成面对危害事件时的响应不及而降低安全性。 ? 为了能充分考虑安全是否已在系统中充分达成，基于系统设计的一些交互资讯反馈给安全团队开发人员仍然是必要的，为此，ISO26262 Ed. 2 (2018)?做了一个还不错的折衷方案：它把系统级别的交付物限缩到仅剩System?Architecture?Design Specification-系统架构设计规格 ? 依笔者之见，系统架构设计规格足够反应出相当程度的「安全要素」与「非安全要素」间的依赖关系，对判定系统安全特性的达成程度有很大帮助。 ? 然而，对于未来的标准Ed.3; Ed.4……甚至更久远的未来，关于系统设计的交付物是否就会冻结在System?Architecture?Design Specification-系统架构设计规格？笔者认为难说，因为时至今日，我们对于「何谓系统」的样貌及理解诠释方式都还在演进中，尤其对于复杂的系统更是如此：自动驾驶；高度自动化机器人；先进武器系统；大型航空载具……等等，这些东西都不比20-30年前的车身控制系统；电动窗控制系统，简简单单地仅需一份System Design Specification就能总结。 ? 笔者过去曾参与过战斗机开发团队的技术讨论，光谈论系统的功能层面，就有好几种不同的规格：功能需求规格；功能分解规格；功能集成规格…… ? 系统是抽象的东西，但这部分抽象的东西谈不清楚，直接进展到软硬件的实体开发，多半会有以下几种结果： ?对于复杂性不高的系统，由软件或硬件团队承担一些更重的系统责任，最终还是能把产品开发完成。 ?对于复杂性极高的产品，可能产品只能推进到样件阶段，离量产还很遥远。 ?或者，对于复杂性极高的产品，最终还是开发到足以量产的程度，但付出的代价很高：不断的设计变更；改型；重测；规模巨大的样件测试。开发周期很长，试误成本也很高。 或者，产品根本就开发不出来，因为无法兜出合适的解决方案。 ? （二）实际项目的薄弱环节 ? 因为笔者多年来参与功能安全产品开发项目之故，并且涉及到的系统级产品种类多元，覆盖到了从车身域，底盘域，动力域，安全域到辅助或自动驾驶域的系统开发，对各公司平台环境或各不同产品的系统设计状况有着比较深刻的观察与体认，在这里分享一些笔者在项目上的总结。 其实一个好的功能安全项目，需要开发团队比较扎实的系统经验与基础，这包含系统开发流程；与对产品本质上的技术性理解。然而在笔者从事推动功能安全技术的10年时间，发现功能安全起到的作用刚好是反向的：它推动各制造商更加重视系统设计；正向开发，并且以逻辑演绎加上对产品的科学认识与实际验证结果来完成产品的定义与开发。 也因此，A-SPICE顺道成为了一个潮流，虽然这个标准是源于对软件质量的掌控，但它背后隐藏的是系统开发流程的思维。 汽车业的诸多制造商在多年的功能安全，A-SPICE与AUTOSAR洗礼下，对系统流程的观念其实已经相对清楚，但对真正落实系统设计仍然有不少的技术障碍。 举例来说，笔者发现在经手的诸多开发项目中，客户团队都会知道要设计阶层化的需求架构，层层从整车需求分解到相对应的软硬