如果一味强调安全，而缺乏一个与之匹配的可靠性流程，这相当于为灾难性错误打开了大门。

 

2018 年 3 月 18 日，世界上首起自动驾驶汽车致行人死亡事故在美国亚利桑那州坦佩市发生。该事件引起了巨大轰动，全球范围内有关本次事故的文章达到了近一万篇，其中大多数均探讨了本次事故对优步（Uber）、自动驾驶汽车、公共道路自动驾驶汽车测试及更广泛社会的影响。

 

然而，没有多少文章真正探讨了自动驾驶汽车的传感器、软件和平台技术可以从这一悲惨事件中吸取哪些教训。事实上，自动驾驶汽车要想真正实现经济可行性，就必须从事故中吸取经验教训。

 

无论是为了从坦佩事故中吸取教训，还是真正理解 ISO 26262（道路车辆功能安全标准）的价值，我们其实面临着一个共同的基本挑战：清楚地认识“可靠性”和“安全性”之间的互补和矛盾之处。这并不单纯指字面意义：每位经理都明白，在任何一个软件和硬件设计周期中，流程、权力和责任的划分至关重要：谁做什么工作？向谁报告？何时进行？这些问题的处理方式不同都会导致截然不同的结果。

 

可靠性是什么？安全性又是什么？这两者在企业环境中又应保持何种关系？从可靠性工程师的视角来看，安全性不过是可靠性的一部分。为什么？因为可靠性团队关注的是故障发生的概率，而安全性团队则关注故障发生且导致灾难性后果（损失、受伤或死亡）的概率。

 

对于可靠性团队而言，预防并处理这些灾难性事件的概率，仅是他们工作中的一小部分而已。因此，在一个以可靠性为核心的环境中，安全工程师直接接受可靠性团队的管理，且在完整可靠性设计（DfR）流程走完前，不会采取行动。

 

可靠性和安全性的相互作用

 

显而易见，安全工程师并不认同这一观点。从他们的视角来看，可靠性分析只能提供特定失效机制（可靠性物理学）或部件（经验学）失效的概率。可靠性分析不会涉及故障发生的具体后果——这会是灾难性的吗？因此，可靠性分析只有深入到系统最下层时，才往往是最有效的。只有这时，分析人员才更能了解系统或用户对故障的反应，从而分析每个故障可能引发的后果严重性。因此，可靠性工程师应当接受安全团队的管理。

 

可靠性工程师的主要职责是计算故障率和基本故障模式。如果有时这些失败率不过只是数字而已，那么可靠性工程师有什么存在的必要呢？

 

此外，第三种观点是，可靠性和安全性之间的联系并没有人们想象的那么紧密。我们可以用这两个学科分别“如何解决风扇性能”的问题更好地陈述这两者之间的差别。可靠性工程师会采取可靠性物理分析（RPA）、降速或加速寿命试验（ALT）等措施，确保将风扇在预期环境中的故障率降至目标水平之下。对比之下，安全性工程师则会首先判断风扇故障是否会引发灾难性事件（及这将给系统其他部分带来哪些影响），然后采用“漂移”（drift）增加冗余或调整关键参数（如电流消耗、转速表、噪音）等方式，降低事故的严重程度。

 

这些不同观点恰好反映了科技公司在“如何处理可靠性和安全性之间关系”方面的犹豫。在一家正在向自动驾驶汽车转型的大型消费者技术公司中，可靠性和安全性团队汇报给同一位总监。另一家自动驾驶领导者公司则将安全性和可靠性团队完全分开，不过这两个部门主管的职位大致类似。我们了解的第三家公司，则是汽车电子领域中一家大力投入自主控制单元研发的中流砥柱。这家公司也将安全性和可靠性团队完全分开，但安全团队主管的职位明显更高，相较而言可靠性团队中职位最高的员工不过是经理或组长，这也反映了这家公司在这两支团队中的“偏重”。

 

如果无法清晰理解可靠性和安全性之间的相互作用和相互依赖，汽车行业可能会出现一些本可避免的冲突和误解，进而将顾客置于本不必要的风险之中，或导致自动驾驶系统的成本过高，甚至两者兼而有之。如果对可靠性过分缺乏信心，或者公司安全性团队的权力过大，自动驾驶汽车制造商往往会在整个车辆系统中引入大量冗余（包括传感、控制、动力、制动等）。据估算，一辆普通汽车的电子元器件成本超过 12000 美元，这些设计并不一定可以让车内人员或整个交通环境更加安全，但却一定会显著增加成本。

 

事实上，我们还可以用另一个很好的例子探讨安全性和可靠性之间的差异：那就是如何计算失败率。从 20 世纪 50 年代到 90 年代，在一些电子硬件公司中，大多数可靠性团队都是凭经验来估算故障率。这些手册只是现场故障数据的简单汇总，按零件类型（电阻器、电容器、二极管等等）进行区分。尽管概念简单、使用方便，但多项研究均表明这些手册在实际产品的应用上非常不准确，整体估算结果偏向保守，也往往因此导致预测的故障率过高。

 

原因很简单——这些手册的分析并不是基于导致失败真正发生的实际原因。进入 21 世纪之后，大多数有经验的可靠性领域专业人员也不再仅仅依靠经验数据来预测失败率。故障手册等过时的方法开始被可靠性物理分析（RPA）和加速寿命测试（ALT）等手段取代，这种趋势在汽车行业中最为明显。直到 ISO 26262 问世。

 

避免脱节

 

作为一项功能安全标准，ISO 26262 将根据“用一定方式计算出的故障率”以及“系统所采取的缓解措施”，预测评估车辆的安全完整性等级（SIL）。与可靠性工程师不同，安全性工程师强烈鼓励，甚至直接要求将经验手册作为 SIL 计算的基础。这种脱节的原因很明显——安全性和可靠性分属两个独立团队，也汇报给不同的管理层，双方缺乏最基本的沟通，沟通完全脱节，以至安全工程师仍在使用过时的方法来计算故障率。

 

如果两个团队之间不能进行合理的平衡，安全性团队往往倾向于给出更高的失败率，并因此要求采取更多的安全分析和安全威胁缓解措施，包括增加冗余等。此外，安全性团队过分专注于经验手册，也会导致他们忽略一些关键故障模式，使得安全威胁缓解机制不再有效。

 

不过，一切仍有改进的机会。无论主营半导体元件、电子模块还是完整的系统，所有自动驾驶技术价值链上的公司都必须认识到，如果一味强调安全，而缺乏一个与之匹配的可靠性流程，这相当于为灾难性错误打开了大门。

 

为了避免这种情况，我们第一步可以做的就是打破可靠性和安全性团队的物理障碍，将这两支团队放在同一支领导团队之下。双方应同意共同实施最佳做法，包括使用最先进的模拟、建模及可靠性物理学等，为适当且有效的风险识别和缓解奠定基础。