天天快播：功能安全的架构设计（一）

在《功能安全之系统开发》一文中我们提到过TSR导出后要分配到系统架构中去，这是系统安全架构设计非常重要的一环，架构设计是系统开发阶段绕不开的一个话题，它是产品开发过程中对产品进行抽象化且全局性描述的一项非常重要的活动。

接下来我们谈谈功能安全的架构设计和常规的功能性架构设计有什么不一样，系统架构和软硬件架构又有什么区别和联系，尤其是和硬件架构。

(相关资料图)

一提到安全架构设计大家可能就会想到E-GAS，fail-safe , fail-operational，MooN，Designated architecture等概念，这些概念对应的架构有什么区别与联系？有没有针对不同ASIL的一些指定架构？

架构设计是门艺术，它代表的是不同阶段(系统、软件、硬件)的高层设计(high-level design)，它体现了资源与功能、性能之间的一种平衡，需要设计师系统性的考虑如何选取组成要素、要素的资源、要素间的交互、冗余与诊断、安全关断路径等等来满足分配到架构中各组成要素的需求，最终架构的成形往往是经过多种验证后的迭代优化后的结果。

接下来我们谈谈架构设计的基本出发点，基于此来谈谈E-GAS监控架构、Fail-Safe/Fail-Operational Architecture、MooN、Designated architecture等概念所表征的架构到底都长啥样，希望能对各位在安全架构设计过程中起到点抛砖引玉的效果。

谈具体的架构设计形式之前我们先介绍下fail-safe、fail-operational、fail-secure、fail-silent等术语的概念，以便后面我们介绍架构设计形式时大家能快速的与这些概念对应。

fail-safe — 失效安全

也称为故障保险，指一个设备或是事物，即使有特定失效下，也不会造成对人员或其他设备的伤害（或者将伤害最小化），失效安全是安全系统的一部分。

fail-safe对应架构设计的基本原则是系统及其主要组成部分，如传感器、电子控制单元和执行器由各种诊断功能监控，如果发生故障，系统将关闭(shut/cut off)以使系统进入安全状态，这意味着要系统要赶在发生危害事件前进入安全状态，所以fail-safe的FTTI指标应被合理的定义。

可能低级别(L2级)自动驾驶车辆相关的安全ECU大都是fail-safe设计，失效安全的系统不表示系统不会失效或是不可能失效，失效安全的系统是指系统的设计在其失效时避免或减轻其不安全的结果。

例如，针对防止单体过充这个安全目标，当BMS检测到单体过压时断开(cut off)高压回路使电池包系统进入安全状态；或者当激光雷达(LiDAR)控制单元检测到发送模块温度超过预设的安全限值时，控制停止激光发射和电机停转使雷达进入安全状态。

在机械安全领域fail-safe的设计尤其常见。

例如，电梯的刹车一般连接到电梯钢缆的张力检测器。若钢缆断裂，张力消失，会启动刹车使电梯停止，这是一种典型的fail-safe设计，这个例子用故障保险这个概念听起来更贴切。

再比如，智慧工厂里的机器人作业区防护门上的联锁装置，当有人开门进入作业区时触发了联锁信号机器人控制器收到信号后控制机器停止作业，这也是一种典型的fail-safe设计。

防爆轮胎在车辆上的应用也是一种典型的fail-safe设计，相对于普通轮胎，防爆轮胎具有良好的漏气性能，不会发生爆发性的漏气而导致车辆失稳，如果结合胎压监测系统(TPMS)那对于行车安全有更好的贡献。

Q：你所了解或设计过的产品有哪些fail-safe的设计，或者你在生活中见过哪些fail-safe设计？

fail-operational — 失效可运行

在系统出现故障的情况下，如果系统无法通过功能关闭来到达安全状态，则有必要使系统继续运行并维持在可控的活动状态。

例如线控制动系统，这是一种需要保证高可用性的安全系统，其故障和关闭制动功能导致的结果一样，故此系统不能通过功能关闭来达到安全状态，而是要保证制动功能故障后系统可运行。

对于SAE Level 3，尤其是SAE Level 4及以上，通过深思熟虑的精巧的解决方案对于功能安全、系统可用性和失效可运行相关的系统冗余是必要的。

根据SAE Level 3，驾驶员不能立即接管车辆的控制，并且根据SAE Level 4，驾驶员不能被视为系统后备(fallback)。

因此，在SAE Level 3的情况下，在驾驶员没有参与驾驶任务的时间段内，以及在SAE Level 4和Level 5的情况下（在驾驶员不可用的情况下），系统必须确保安全。这使得失效可运行(fail-operational)系统对于自动驾驶至关重要。系统安全性和系统可用性对于自动驾驶非常重要，应该通过失效可运行(fail-operational)架构来提高。

Q: 想想你接触的产品设计中是否有应用fail operation的设计概念？

如上所述，在发生故障的情况下，并不总是能够通过关闭系统来达到安全状态。失效可运行(fail-operational)安全架构可以实现为多样性冗余或同质冗余架构。

多样性是通过两个或多个不同的硬件和软件应用程序实现的，这些应用程序由不同的公司或团队开发，或者基于不同的规范。在同质冗余系统中，硬件（如处理器）由同一家公司和同一开发团队开发，软件由两个或多个相等的设计实例生成。

自动驾驶系统的fail-operational状态通常是一种降级(degradation)运行状态，所以fail-operational状态从系统层面来讲其实也是一种紧急运行(emergency operation)状态，只不过这种紧急运行的过渡相对平滑。

另外，通过多通道冗余实现的fail-operational其实在某种意义上来讲也有fail-safe的意思，比如冗余通道中某一路因故障而关闭从而切换到另一通道以维持系统继续运行，故障的那路被shut off了，另一路使系统进入了安全状态，这么看来fail-operational里确实有fail-safe的影子。

自动驾驶fail-operational设计，是兼顾了安全和可用性的要求，进入fail-operational状态时其实依托可用性来满足安全性。可用性设计往往又和可靠性设计存在交叉关系，也许从概念上两者不同，但实际设计过程中两者的很多方法是相通的，比如冗余设计，在可用性和可靠性设计中都是常用设计方式。

车辆上有很多冗余设计的例子，比如车大灯和尾灯的冗余设计、货车的双轮胎设计等。

除了冗余，可靠性设计中的降额设计也是一个非常好的设计手段，它能降低系统失效率，提高系统寿命，使系统对故障的容忍度更高，对系统的可靠性、可用性和安全性似乎都能做出贡献。

不知道上面的描述是否让大家对于冗余(redundancy)、fail-safe、降额(derating)、fail-operational和故障容忍(fault-tolerant)这些概念有个基本的理解？

fail-silent — 失效静默

这个概念有点类似机械安全领域的muting(抑制/静默)机制，传统IT服务器操作系统容错架构设计也用到过这个概念，即调用服务失败后，就默认该服务一定时间内无法再对外提供服务，不再向它分配请求流量，将错误隔离开来，避免对其他服务产生影响。

例如，经常超时的服务可以使用faile-silent容错机制，防止请求堆积而消耗大量的线程、内存、网络等资源，进而影响到整个系统的稳定。

按照这个解释，如果将这个机制放到汽车电子控制器或系统上，那fail-silent就类似fail-safe了。例如，使用多传感器融合的自动驾驶系统，当ADU(Autonomous Driving Unit 自驾控制器)没法收到激光雷达(LiDAR)的点云数据或收到标记为错误的点云数据时，停止LiDAR的点云数据收、发请求，并标记LiDAR为故障状态，此时ADU应动态调整为使用剩余传感器数据的融合作为感知层的数据，LiDAR的故障没有清除前其控制器本身及与ADU的收发路径(如，Ethernet, CAN)应处于fail-silent状态。

简单理解，当智能驾驶域控中的某个冗余通道故障时，处于fail-operational的目的，将该故障通道功能抑制/静默，此时该故障通道就处于fail-silent状态。

fail-secure — 失效安保

fail-secure的中文也是失效安全，由于secure更多的是信息安全的保护措施故我个人倾向于将fail-secure翻译为失效安保，以免和fail-safe混淆。

fail-secure概念上不同于fail-safe，fail-safe如上所述，fail-secure强调的是信息系统的安全状态，是指信息系统失效时不会将资料或是存取权落入坏人之手。有时fail-secure和fail-safe导致的结果会完全不同。例如大楼失火，fail-safe系统会自动开锁，让人员可以快速逃出，消防人员可以尽快进入，但fail-secure系统会自动上锁，避免未授权的人员进入建筑物。

MooN — N选M架构

MooN是M out of N的简写，表示N通道冗余中取M个通道数据进行逻辑处理，其中M表示需要执行安全功能的通道数，而N代表整个可用的通道数，当N大于等于2时，对应架构是一种冗余架构。

如装有三台发动机的喷气式飞机，只要有两台发动机工作正常即可保证安全飞行和降落，这是一种2oo3架构设计概念的应用。

Q: 由上面描述可知MooN也会涉及冗余，它和上面的fail-safe, fail-operational架构概念有些什么关系？

MooN中不同的冗余形式将带来不同的安全性能，MooN的架构还可以引申出带诊断的MooN架构形式，用MooND表示。常见的MooN(D)架构形式有1oo1, 1oo2, 1oo2D, 2oo2, 2oo2D, 2oo3等，我将在后面的文章中给大家谈谈这些架构的表现形式及特点。

Designated architecture — 指定架构

这个概念在ISO 13849-1(机械安全控制系统的安全设计原则)中提到过，“designated”按照字面理解是“指定的”的意思，这里的“指定“是为机械系统不同PL(Performance Level)等级的系统指定对应的架构范式。

Jet Note: PL(Performance Level) — 性能等级，可简单理解为车载领域的ASIL或工业领域的SIL等级，机械应用领域有其自身的特点，比如场景固定、机械设备安装位置、基本功能、基本操作模式等都已固定，针对设备的在运行过程中保证机械安全的性能等级标准指定了对应的机械系统安全设计架构，相当于不同性能等级的机械系统的架构设计模式标准直接给出来对应的架构样式。

ISO 13849中给出了5类(Category B, 1, 2, 3, 4)designated architecture, 分别用于满足不同PL等级的要求。

后面用专门的文章给大家介绍下这5类指定架构。

E-GAS 监控架构

汽车行业的小伙伴对这个概念应该比较熟悉，也经常会提到。这是由欧洲的几大一线主机厂和tire 1提出一种用于动力域系统设计的三层电子监控架构。

所谓三层，是指这种架构设计形式将功能层、功能监控层和控制器监控层分三层设计，是一种安全架构设计的良好实践，在汽车电子领域尤其是动力域相关的系统具有非常好的参考意义。

以上这些基本概念就先和大家谈到这，本篇先给大家梳理下这些术语的概念，后面文章将给大家谈谈每种概念对应的架构设计形式。

参考：

[1] ak-egas-v6-0

[2] Automotive Vehicle Safety

[3] Fail-operational Safety Architecture for ADASAD Systems

[4] ISO 26262

[5] ISO 13849

标签：