基于功能安全的车载计算平台开发：软件层面_e-gas架构

对于功能安全软件设计而言，软件架构设计一个重要的目标是使软件需求的实现过程以一种完整的、正确的同时尽可能简单、可理解和可验证的方式展现，从而在软件需求实现过程中，尽可能降低由于设计错误造成违反功能安全需求的可能性。功能安全要求软件架构的设计具备以下属性：可理解性，一致性，简单性，可验证，模块化，层次化，按层逐步细化、封装，低耦合性，可维护性。对于可理解性，ISO 26262中按照不同的ASIL等级规定了不同的软件架构设计的表示方式。

常见的几种软件架构安全分析方法包括SW-FMEA、SW-FTA及SW-DFA。
1、SW-FMEA
SW-FMEA以硬件组件和软件模块之间的接口或软件模块和软件模块之间的接口为分析对象，列举硬件组件接口或软件模块的失效模式，分析失效模式对后续软件模块或者软件需求的影响，尤其是与功能安全相关的影响。在明确失效模式和失效后果的基础上，去寻找造成硬件组件接口或软件模块的原因，并且对原因施加控制措施。
2.SW-FTA**
SW-FTA探究的重点是软件架构中多点错的发生对软件功能安全需求的影响。SW-FTA分析过程从软件功能安全需求出发，从软件架构设计中所有软件模块和软件接口的失效模式中去寻找和当前软件功能安全需求相关的失效模式，并且识别出这些失效模式和当前软件功能安全需求的相关性（单点失效还是多点失效）。
**3.SW-DFA
SW-DFA在标准中定义的从属故障（Dependent failure）包括级联故障（Cascading failure）和共因故障（Common cause failure）。通常可以从以下几个方面来考虑Dependent failure 中Cascading failure的部分：
时间和调度问题造成Cascading failure。比如，由于其他模块运行时间过长导致目标模块无法运行，死锁、活锁、饥饿等现象导致模块运行停滞或者延迟，软件模块之间的同步性问题或者优先级问题导致调度次序出现问题。
存储空间问题造成Cascading failure。比如，目标存储区域被其他软件模块误篡改，软件模块之间对于同一存储空间的读写操作配合问题导致数据不一致（读数据的同时允许写数据），栈溢出等问题。
软件模块之间的通信（ 尤其是ECU 间的通信） 问题造成Cascading failure。时间和调度问题造成Cascading failure。
随着ASIL等级的提升，ISO 26262从语法和语义两个维度出发，从最低要求的自然语言描述到半正式的表述方式，逐步加强对表述方式的理解一致性的要求。为了避免系统性失效，ISO 26262对软件架构设计提出了一些设计原则。

ISO 26262对软件架构设计验证方法