从ISO26262看缺失的系统设计

前言：

笔者刚踏入汽车业的时候，就急迫想了解何谓系统设计，以及系统设计是如何落实成一辆有吸引力及竞争力的车型……

十多年后，我终于理解….

（一）功能安全与系统设计

翻开ISO26262 Ed. 1(2011)与ISO26262 Ed. 2 (2018)，当中有些许显著不同的地方。其中一处便是发生在系统开发阶段的要求：第一版在安全合规交付物的产出中，要求输出System Design Specification（系统设计规格）；第二版仅只是客气的提及System Architecture Design Specification（系统架构设计规格）。

为啥会有这样的变化？这种变化又代表何事？

首先，汽车业在经过多年的系统工程方法论洗礼（如A-SPICE）及功能安全导入经验之后，多半已认识到「安全」仅只是系统的一个属性，尽管这个属性在某些系统开发工作中被视为是最重要的属性（下图为笔者在迪拜参与自动驾驶研讨会时，现场参与嘉宾投票的自动驾驶落地最重要关键要素为何：明确可见，安全的地位比技术亮点本身还高许多）。

除了这个属性，依照系统功能的不同，系统还要能照顾到其他许多属性。诸如，当我们谈论的是动力总成相关系统时，「可靠性」与「舒适性」也是必须要照顾到的属性；当目标是仪表显示系统时，「直观易理解」则是重要的系统属性。

既然安全始终就只是系统的一个属性，我们在实施安全标准的时候，若把完整的系统设计及与其相关的系统设计规格定义成为符合安规的必要交付物，似乎就显得小题大做与不知所谓何事。然而，系统的全貌及方方面面确实会跟安全特性之间有某种程度的耦合关系：一个HMI人机接口设计的不够人性化，不只是难用而已，可能也会因为安全报警的不清楚而影响到安全性；AEB设计的强度阶梯变化很舒适，但也可能造成面对危害事件时的响应不及而降低安全性。

为了能充分考虑安全是否已在系统中充分达成，基于系统设计的一些交互资讯反馈给安全团队开发人员仍然是必要的，为此，ISO26262 Ed. 2 (2018)做了一个还不错的折衷方案：它把系统级别的交付物限缩到仅剩SystemArchitectureDesign Specification-系统架构设计规格

依笔者之见，系统架构设计规格足够反应出相当程度的「安全要素」与「非安全要素」间的依赖关系，对判定系统安全特性的达成程度有很大帮助。

然而，对于未来的标准Ed.3; Ed.4……甚至更久远的未来，关于系统设计的交付物是否就会冻结在SystemArchitectureDesign Specification-系统架构设计规格？笔者认为难说，因为时至今日，我们对于「何谓系统」的样貌及理解诠释方式都还在演进中，尤其对于复杂的系统更是如此：自动驾驶；高度自动化机器人；先进武器系统；大型航空载具……等等，这些东西都不比20-30年前的车身控制系统；电动窗控制系统，简简单单地仅需一份System Design Specification就能总结。

笔者过去曾参与过战斗机开发团队的技术讨论，光谈论系统的功能层面，就有好几种不同的规格：功能需求规格；功能分解规格；功能集成规格……

系统是抽象的东西，但这部分抽象的东西谈不清楚，直接进展到软硬件的实体开发，多半会有以下几种结果：

对于复杂性不高的系统，由软件或硬件团队承担一些更重的系统责任，最终还是能把产品开发完成。
对于复杂性极高的产品，可能产品只能推进到样件阶段，离量产还很遥远。
或者，对于复杂性极高的产品，最终还是开发到足以量产的程度，但付出的代价很高：不断的设计变更；改型；重测；规模巨大的样件测试。开发周期很长，试误成本也很高。
或者，产品根本就开发不出来，因为无法兜出合适的解决方案。

（二）实际项目的薄弱环节

因为笔者多年来参与功能安全产品开发项目之故，并且涉及到的系统级产品种类多元，覆盖到了从车身域，底盘域，动力域，安全域到辅助或自动驾驶域的系统开发，对各公司平台环境或各不同产品的系统设计状况有着比较深刻的观察与体认，在这里分享一些笔者在项目上的总结。

其实一个好的功能安全项目，需要开发团队比较扎实的系统经验与基础，这包含系统开发流程；与对产品本质上的技术性理解。然而在笔者从事推动功能安全技术的10年时间，发现功能安全起到的作用刚好是反向的：它推动各制造商更加重视系统设计；正向开发，并且以逻辑演绎加上对产品的科学认识与实际验证结果来完成产品的定义与开发。

也因此，A-SPICE顺道成为了一个潮流，虽然这个标准是源于对软件质量的掌控，但它背后隐藏的是系统开发流程的思维。

汽车业的诸多制造商在多年的功能安全，A-SPICE与AUTOSAR洗礼下，对系统流程的观念其实已经相对清楚，但对真正落实系统设计仍然有不少的技术障碍。

举例来说，笔者发现在经手的诸多开发项目中，客户团队都会知道要设计阶层化的需求架构，层层从整车需求分解到相对应的软硬件需求。这种流程性认识大家是有的，但对应的工程体悟却没那么深刻：这造成需求定义上的阻碍感与推进不顺畅。

功能安全因为已经变成业界关注的热点主题，所以在系统开发项目上，安全需求的制定可以找到不少参照或资源，一些比较成熟的系统：如BMS；EPS；MCU……安全目标或安全需求都相对比较一致。在这样的背景下，制造商也不必太伤脑筋去导出需求。

但真正要完成一个产品开发，系统设计过程中需要照顾的需求种类，远不止安全需求，在第一章中说到的其他产品属性，也需要有相对应的需求去规范约束或者定义设计。

举个简单的例子，当某整车厂总工提出一条非常高阶的需求，如：开发一台好开的车。这样的需求就好似安全领域的安全目标，是一切设计的起点，但功能安全方法论会要求我们基于安全目标去导出后续一切层级的safety concept，覆盖软硬件的策略。但在安全以外的产品属性，一样可以有类似的系统设计方式去展开它的设计。

当我们做整车规划，承接的需求是「开发一台好开的车」时，系统设计的任务就是把这样的抽象目标落实成为一个系统方案，里面包含必要的机械；装置；软硬件特性……等等，这样才算是完成了恰当的系统设计。但这种强正向设计，对国内很多客户都是非常困难的过程。因为这样的设计过程，没有标准答案，是一整路的自我辩证自我推翻与自我迭代，然后收敛到一个大家都满意的设计点上。

这里面有几点迷思供大家参考：

越热爱或依赖参考设计的人/组织，越难展开正向系统设计
越怕在设计上犯错的人/组织，也越难发动正向系统设计

（三）系统设计的难点与必要性

正向系统设计的一个自我辩证过程，大概会是用类似如下的方式展开。

如果要开发一台好开的车，我们大概得对以下问题提出观点，想法与解决方案：

这车是对谁而言好开？男人；女人；老人？
怎样的车会被认知为好开的车？越省力的车？越不需要操控技巧越直观的车？
这车需要考虑自动驾驶辅助带来的效应跟影响吗？
如何对好开定KPI？转向，制动，加速与HMI又各自占比怎样的比重？

经过一连串的边界定义；功能定义与性能定义，可能在规格上我们会收敛出一些结论与方向，如；

转向必须要软，不能硬；
转向程度要与车速联动；
刹车行程不能太长
……etc

也是透过这样逐步细化的过程，我们会推导出各个阶层的系统需求甚至是最终的系统级解决方案。

但也由此可见，系统设计的复杂性肯定很高，做不好很容易顾此失彼：如刹车行程不能太长来达到更高的驾驶可控性，但也有可能容易触发过重的刹车冲突了SOTIF的安全问题。这就需要我们在系统设计过程中不断以各种视角自我辩证推翻与迭代，最终让设计能收敛到一个特定的点上。

在这样的辩证过程中，各个岗位的专家意见就变得相对重要，如果专家水平不够以至于给出的意见是误导或扭曲的，可能会造成系统设计的方向偏离：原本应该是好开的车变成了硬核（hardcore)的车，销量于是减少一半，并且公司还难以定位与追踪销量不及预期的原因。

另外要做好系统设计的另外一个关键点，就在于有效视角的建立，并针对这些视角提出如「安全生命周期」一般的可操作模式。毕竟，一个好的系统应该是平衡的，能经得起各个视角的检验，并已充分考虑了各个视角的冲突及解决方案。说个极端一点的：「成本」肯定也是检验系统设计的一个视角，但若把成本这个视角抬升成众多视角中最高的优先级，我们恐怕只能坐出一台卖得动但卖不久的车。或许30年前的国内汽车市场最重视这个视角，但今日恐怕行不通。

如何设定这些视角，并平衡这些视角，也是公司整体竞争力的展现。

这里也可以做个总结：系统设计就像是在下一局棋，有好的系统设计手法与能力，才有棋盘与套路可言。会的套路越多，手法越灵活，产品相对于市场也更有竞争力。甚至，对应到未来软件定义汽车的快速迭代世界时，系统设计的功力与优化程度更是直接决定这间车企的命运与发展。

（四）在V模型以外的世界

根据我们的传统认知，掌握了V模型，就掌握了系统设计的主要精神。多年前，曾经有客户询问笔者叫笔者简单总结下V模型的思路到底是啥？记得当时笔者回复的是：设计要自上而下，验证要自下至上。这样的思路很直观，也相当有益于复杂性管理。但就目前笔者的观察，大部分客户能够妥善地实现自下至上的验证，却无法有效实现自上而下的设计，原因，我们在前几章也已经解释过。

另外，对于系统设计的手法，不是仅有V模型一种，还有一些其他的可能性

在笔者近期的项目中，发现越是到复杂系统的领域（如自动驾驶），系统设计就越发重要；但也更加难以百分之一百的自上至下完成开发。

系统设计在复杂系统中之所以重要的原因，主要在于复杂系统需要能够清楚描述情境；用例；系统运行环境；支撑系统在环境下运作的必要功能；性能……这些都要能够谈清楚，不然堆叠出来的软硬件仅是无意义的浪费。举例来说，人也是个系统，我们的硬件就是身体的各式器官；我们的软件就是我们的思维能力经验知识等等让我们能发挥功能的必要智能。我们人类这样的一个系统，也必须应付处理许多复杂的情境与用例，但与一般复杂系统的差别在于，我们人类是一个自适应系统：我们的软件与硬件都可以不断地迭代演进来应付环境的需求，而这样的自适应能力，目前世界上的技术并无法做到，也因此系统规划者的肩上就承担着巨大责任，要替复杂系统在生命周期内将遭遇的挑战都提前分析应对以确保系统的正确工作。这，又谈何容易？

幸好，汽车业兴起了一股“软件定义汽车”的风潮，能够提升软件迭代的速度，一定程度弥补系统规划的不充分，达到初步的“自适应”效果。

笔者也打算在接下来的文章系列中，更深入地去谈软件定义汽车下的系统设计；以及如何达成一个好的系统设计。

关于作者：

Bentley Lin，雅析安全系統/執行董事

Bentley.Lin@exida.com

雅析安全系统成立于2016年，公司目前聚焦在各式车用安全系统的技术解决方案上，为客户提供安全设计，系统规划与方案推导选择的服务。