Day04-04｜2.4.4 安全攸关软件的安全性设计：让失效进入可控状态

对应教材：上篇·综合知识·第 2 章“计算机系统基础知识”·2.4.4 安全攸关软件的安全性设计

学习定位：安全攸关软件一旦失效，可能造成人员伤害、设备损坏、环境事故或重大经济损失。它与普通软件的区别，不只是“测试更多”，而是从需求、架构、实现、验证、部署到维护，都要围绕危害识别、风险降低、故障隔离和安全状态建立证据链。本节中的“安全性”主要指功能安全和失效安全，同时也要关注网络攻击对安全功能的影响。

一、今日目标

完成本节后，应能解释安全攸关软件、危险和风险的基本概念；理解安全需求、危害分析、失效模式、故障树和风险控制；掌握冗余、隔离、监视、检错、容错、降级和安全停止等设计技术；了解安全生命周期、独立验证、配置管理和变更控制；在案例中分析控制系统失效、软件更新和传感器异常，并给出可验证方案。

二、什么是安全攸关软件

安全攸关软件是其功能或失效可能影响系统安全的软件。它可能位于飞机控制、列车信号、汽车制动、核电保护、医疗设备、工业安全仪表和机器人急停等系统中。软件本身不一定直接驱动执行器，即使只是采集、判断、通信或监控，也可能因错误输出、错误报警或未及时响应导致危险。

安全性不是“系统永不出错”，而是即使出现合理可预见的故障，系统也能避免不可接受后果，或把风险降低到目标范围。设计必须明确哪些失效必须被发现、哪些失效可以容忍、发现后进入什么状态以及如何恢复。

三、安全生命周期

安全攸关软件需要贯穿全生命周期的安全活动：概念和风险分析、系统需求、软硬件架构、详细设计、实现、集成、验证、确认、部署、运行维护和退役。安全不能在项目末期通过一次测试“补出来”。

不同领域有不同标准和安全完整性等级。架构师不应凭经验声称“达到某认证”，而应根据适用标准、等级和组织流程，明确独立性、验证深度、工具合格性和文档要求。

四、危害分析与风险控制

危害分析从系统功能和环境出发，识别可能的危险事件、触发条件、后果和现有防护。常用方法包括初步危害分析、失效模式与影响分析 FMEA、故障树分析 FTA、事件树分析和危险与可操作性分析。

FMEA 从部件或功能的失效模式向上分析影响，例如传感器卡死、通信延迟、执行器不响应、软件变量溢出；FTA 从顶层事故向下分解导致事故的组合原因。两者互补：FMEA 适合系统化检查单点失效，FTA 适合分析事故逻辑和冗余关系。

风险控制通常遵循顺序：消除危险、降低危险发生可能性、降低后果、增加检测和告警、提供人工或自动保护。软件不能只依赖用户及时发现错误，关键安全功能应具备自动检测和进入安全状态的能力。风险控制措施还要评估共因失效、依赖失效和误报警。

五、安全需求与可追踪性

安全需求应可测量、可验证并能追溯到危险和系统目标。例如“检测到制动传感器异常后，在 20ms 内切换到冗余通道，并将输出限制在安全范围”比“系统要安全”更可执行。需求还应规定失效检测覆盖、误报/漏报边界、响应时间、重启行为和人工干预。

可追踪性把危害、安全目标、系统需求、软件需求、设计、代码、测试用例和结果关联起来。需求变更时，可以知道影响哪些构件、接口和测试。没有追踪关系的测试通过，不能证明关键危险已经被覆盖。

安全需求与普通功能需求可能冲突。系统希望继续运行，但安全策略可能要求停止或限制功能；系统希望提高采样频率，但功耗和资源可能增加；系统希望远程更新，但更新过程可能影响保护功能。架构师应明确优先级和安全边界，必要时让安全功能具有独立资源和独立电源。

六、安全架构设计技术

1. 故障避免

通过简单化、标准化、严格接口、编码规范、静态分析、形式化方法和同行评审减少缺陷。降低复杂度本身就是安全技术，复杂的共享状态、隐式时序和难以测试的动态行为会增加风险。

2. 故障检测

使用范围检查、奇偶校验、CRC、看门狗、超时、心跳、序列号、数据新鲜度、状态一致性和合理性检查发现错误。检测机制要考虑自己是否可能失效，重要监视功能应独立或采用不同实现。

3. 故障容忍与冗余

通过硬件冗余、软件冗余、信息冗余、时间冗余和多版本设计，在部分部件故障时继续提供正确服务。冗余不是简单复制两份，若两份共享同一软件缺陷、时钟、电源或输入，可能同时失效，形成共因失效。

4. 安全降级

当系统无法继续提供完整功能时，转入预先定义的有限功能或安全停止状态。例如机器人停止运动、列车进入限速、医疗设备停止危险输出但保留报警。降级要有明确触发条件、状态保持、恢复条件和人工接管。

5. 隔离与分区

把不同安全等级、实时等级和可信程度的功能进行空间、时间、通信和权限隔离，限制故障传播。日志、联网、升级和用户界面等非关键功能不应耗尽安全控制域资源。

七、异常处理与安全状态机

安全攸关系统应把正常、降级、故障、恢复和维护状态显式建模，而不是在各处散落布尔变量。状态机要规定每个状态允许的输入、输出、转换条件、超时、重复进入和异常转移。

异常处理必须避免“默认继续执行”。输入不合法、传感器超范围、通信超时、时间戳过期、校验失败和资源不足时，应按照风险定义采取拒绝、隔离、使用备份、保持最后安全值、降低输出或停止。恢复也要谨慎，故障自动消失不等于可以立即恢复，可能需要连续健康检查和人工确认。

八、安全与网络安全的协同

网络攻击可能触发功能安全事故，例如伪造传感器数据、阻塞保护消息、篡改固件或占满资源。功能安全关注随机故障和系统失效，网络安全关注恶意行为，二者在威胁建模、访问控制、身份认证、完整性、可用性和事件响应上相互关联。

安全攸关设备应使用安全启动、签名固件、密钥保护、最小权限、通信认证、重放防护、分区、入侵检测和安全日志。网络安全机制不能破坏实时性和安全降级；例如证书更新失败时，关键控制不能因为依赖远程服务而停止在危险状态。

九、验证、确认与故障注入

安全验证不仅测试正常输入，还要测试边界、异常、故障组合、时序、资源耗尽、断电、通信中断、传感器漂移、时钟异常和升级失败。确认则关注系统是否满足真实使用和安全目标。二者都需要独立性和足够证据。

故障注入通过人为制造错误，观察检测、隔离、降级和恢复是否符合设计。例如断开一个传感器、延迟或重复报文、篡改校验、阻塞线程、耗尽内存、拔出存储介质和在更新时断电。故障注入不能只验证“系统报了错”，还要验证输出是否进入安全范围、报警是否明确、状态是否可恢复。

十、案例分析：列车信号系统通信中断

某列车控制系统依赖网络接收速度和区间信息。通信中断后，部分设备继续使用最后一次数据，导致在极端情况下出现超速风险。请分析并提出安全设计。

参考答案：使用最后一次数据必须受到数据新鲜度、最大保持时间和速度变化约束，不能无限期保持。系统应为通信消息增加序号、时间戳、完整性校验和来源认证，检测丢包、乱序、重复和延迟；对速度和区间数据设置合理范围和变化率检查。

当通信在规定时间内未恢复，应切换到预定义降级策略，例如限速、减速或安全停车；降级状态需要独立监视，并把控制输出限制在安全边界。若存在冗余通信链路或独立传感器，应进行一致性判断，防止共同错误输入。安全控制域应与乘客信息、日志和远程维护域隔离，避免网络拥塞影响关键任务。

验证要覆盖正常通信、丢包、乱序、延迟、伪造、链路切换、设备重启、断电和网络风暴，并测量检测时间、切换时间、最坏制动/限速响应和误报警率。论文答案必须写清“故障—检测—安全状态—恢复—验证”闭环。

十一、综合知识练习

练习 1

下列关于安全攸关软件的说法正确的是（ ）。

A. 只要测试用例数量多，就能证明系统安全

B. 冗余复制可以完全消除共因失效

C. 安全需求应与危害、设计和测试建立可追踪关系

D. 发生异常时系统应尽量继续提供全部功能

答案：C。 安全需要全生命周期证据；冗余可能受到共因失效影响；异常时应根据风险进入安全状态或降级。

练习 2

FMEA 和 FTA 的分析方向有什么差异？

答案： FMEA 从部件或功能的失效模式出发，分析影响和后果；FTA 从顶层事故或危险事件出发，向下分解可能原因及逻辑组合。二者可以结合，用于识别单点、组合和共因失效。

练习 3

为什么安全攸关系统不能无限期使用最后一次有效数据？

答案： 数据可能已经过期，真实状态可能发生变化；继续使用旧数据会把“未知状态”伪装成“正常状态”。应设置时间戳、新鲜度和最大保持时间，结合范围/变化率检查、冗余输入和超时后的安全降级策略。

十二、论文素材

在安全攸关系统设计中，我从系统边界和运行环境出发开展危害分析，识别故障模式、事故后果和安全目标，并将安全目标分解为可验证的需求。架构上采用分区、冗余、独立监视、看门狗、数据校验、超时和安全状态机，对通信、传感器和执行器异常设计隔离、降级与人工接管；同时通过安全启动、签名更新、最小权限和安全审计防止网络攻击触发功能风险。验证阶段覆盖正常、边界、组合故障、断电、断网、资源耗尽和升级失败，以检测时间、切换时间、最坏响应和安全输出范围形成完整证据链。

安全论文应避免绝对化表述，例如“系统绝不会失败”。更专业的写法是说明哪些失效在假设范围内可检测、可容忍或可降级，以及如何通过分析、测试和运行监控证明风险处于可接受范围。

十三、今日复盘

1. 安全攸关软件与普通应用软件的主要区别是什么？
2. 故障、失效、危害、风险和安全状态如何区分？
3. FMEA 与 FTA 分别适合从什么方向分析问题？
4. 安全生命周期为什么要从概念阶段开始？
5. 冗余为什么不能自动消除共因失效？
6. 故障检测、容错、隔离和安全降级如何形成闭环？
7. 安全需求为什么必须场景化并保持可追踪？
8. 网络安全和功能安全如何协同？
9. 故障注入应验证哪些结果，而不只是报警？

本节核心记忆句是：安全攸关软件的目标不是假设系统永不出错，而是识别危险、限制故障传播、及时检测并进入可接受的安全状态。设计、实现、验证、更新和维护都必须留下可追踪证据。