功能安全应该如何考虑软件架构，什么样的架构符合功能安全标准的要求，软件架构工程师和功能安全工程师都很难解释清楚方面，本文从功能安全的角度谈了软件架构设计的基本要求。首先，功能安全软件的架构设计基于两个层面：第一：选择并建立定义明确、易于理解的软件架构；第二：在第一条的基础上，满足相应功能安全等级要求的软件设计要求。接下来，我们将以汽车功能安全标准ISO26262-6和轨道交通软件功能安全标准EN50128为基础，从以上两个层面谈谈标准是如何制定的。软件架构阶段的开始软件架构设计是软件生命周期的第二个阶段。前一阶段是软件需求规范阶段。在设计软件需求时，将整个软件视为一个黑盒子来确定软件需求规格说明书。所有的功能、性能、与硬件的接口定义、与其他外部系统的接口定义。在软件架构阶段，需要设计一个架构来满足软件需求，软件架构的组成部分用层次结构表示。他们如何互动。以下图为例，虚线框外是软件需求，虚线框内是软件架构。什么是软件组件？上图是用来说明软件架构所做的工作，将整个软件划分为功能和接口清晰的组件。ISO26262-6和EN50128都有软件组件（component）的概念。先来看看这个组件的定义：很多人把组件理解为一个函数，或者一个包含多个函数的文件。从定义上看，组件是软件功能需求的集合，有点类似于面向对象语言中类的概念。它在软件架构中是一个独立的个体，更新的基本元素可以独立更换。通过软件组件的应用可以达到重用和替换的目的，软件组件可以独立测试和版本化。软件架构设计原则软件架构中的组件如何设计，ISO26262-6中提出了以下设计原则：设计原则分为两个方面：单一组件：限制组件的大小，限制接口的数量，并限制中断的使用，目的是降低每个组件的复杂度，多个组件：组件内部强内聚，组件之间松耦合，组件之间空间隔离，组件之间共享资源的冲突管理。避免以下情况：系统的一个功能分散在不同的组件中，代码在多个地方更改同一个变量或状态；系统的中断功能不受限制，多次中断导致软件的时间限制失控；组件不具备可维护性，不可能对其中一个组件进行重构；组件封装不好或封装不合理，外部接口过于复杂或内部状态未知；组件设计缺乏可读性，只有专家才能看懂。可以理解；软件体系结构的内容软件体系结构在划分了层次化的组件之后，着重于描述组件之间的关系：静态关系和动态关系。组件之间的接口、与硬件的关系、组件的层次结构等静态设计方面通常都比较清晰。容易被忽视的是动态设计。软件的动态行为需要考虑：事件和行为的功能；数据处理的逻辑顺序；控制流程和并发进程；通过接口和全局变量的数据流；时序约束。这些内容如果只用文字表达，很容易产生歧义，难以准确描述。因此，建议使用建模和文本表达相结合的方式。下表是EN50128中推荐的建模方法表。虽然标准只要求至少使用一种方法，但是从软件架构需要表达的不同动态行为来看，强烈建议根据不同的行为采用合适的建模方法。例如，用文字表达很难准确描述不同系统之间通信和交互的时序关系，但是用SequenceDiagrams（时序图）可以清楚地表达交互关系。EN50128TableA.17建模技巧上表中，常用的建模方法有：数据流图——描述数据如何一步步从输入到输出的过程；控制流图——描述了从输入通过一系列控制动作到输出的过程；状态机图——描述系统不同状态之间的转换关系；真值表——描述复杂的组合逻辑关系；时序图——通过信息交互描述不同组件的时序关系；结构图——描述组件之间的层次关系。时序图示例这些软件建模方法属于软件的通用设计方法。上述建模方法存在于UML和SysML软件建模语言中，属于半形式化方法。注意这些建模方法在项目中使用，需要对项目中与软件架构相关的那些有一致的理解，需要建立建模方法的使用指南，规范它们的编写要求。以上是软件架构的一般要求。软件缺陷是系统性故障，不存在故障概率问题。因此，如果编写的代码没有错误，则100%按照定义的要求执行。但是，安全软件需要考虑两个问题。第一，软件难免会有bug；其次，软件的实现与其运行的硬件以及与之交互的外部系统相关联。外部环境的变化会对软件的预期行为产生影响。因此，安全软件不仅要考虑正常情况下的预期行为，还要考虑故障和干扰情况下的预期行为。EN50128的表A.3列出了软件架构设计和应用技术，列出了软件架构的备选技术方法。其中，2-14、16项为底层安全设计技术，其中FaultDetection&Diagnosis应用较多，与硬件或外部接口相关联；Gracefuldegradation作为fail-operational的一种实现，用于保证在发??生故障时功能仍然保持一定的可用性。对于软件安全技术，应正确选择和使用。毕竟，它增加了软件的复杂性和系统故障的可能性，而安全技术往往很难兼顾可测试性。作为SIL1-SIL4极力推荐的技术，防御性编程是最常用的软件安全技术，用于检查软件执行中不正确的数据流、控制流和数据值的预期行为。一类是防护软件自身设计缺陷导致的问题，如变量范围检查、输入值可信度检查、程序入口检查输入参数的类型、大小和范围等；二是防止不受控制的外部环境输入引起的问题，如检查物理变量值输入的有效性、过滤处理、配置数据的完整性和软件本身的完整性。EN50128A.3现有软件组件的使用ISO26262和EN50128都规定了如何在安全软件中重复使用现有软件组件。有两种情况会使用现有组件：来自公司外部的CTOS组件；重用以前开发的组件。首先，如果一个组件可以复用，那么它的接口必须清晰可辨，它的应用环境必须确定，它的实现规范必须明确。在EN50128中，如果应用于SIL3和SIL4，需要分析现有软件可能发生的故障对整体软件的影响，以及检测现有软件故障的策略，比如封装技术。在ISO26262.8中，第12章规定了现有组件的资格要求。这两个标准都需要对现有软件进行鉴定、确定可用功能、组件版本和配置、对应用环境的假设、相关的安全完整性级别、组件残留缺陷以及鉴定过程的验证。软件组件交互当软件由不同安全完整性等级的组件组成时，EN501287.3.4.9和ISO26262-67.4.8中的要求是一致的：除非有证据表明高层组件和低层组件是相互独立，从时间分区和空间分区两个维度出发，其他情况按最高层要求开发。在ISO26262-6中，有两种不同的组件划分方法。首先是软件分区，从执行时序、数据保护、组件间数据交互等方面考虑组件间干扰的影响。二是硬件保护机制。支持，如MPU；三是操作系统或虚拟化层对不同组件互不干扰的支持。最后回顾五个方面的主要内容：软件需求，软件体系结构与组件的关系；软件架构需要涵盖什么；安全软件应用技术；如何应用现有软件；不同标准对不同安全等级软件的影响分析，架构设计也各有侧重。ISO26262-6对软件安全分析有相应要求，EN50128安全分析是在系统层面进行的，需要从系统功能和接口的角度进行分析。EN50128在架构设计阶段对软件设计方法（建模指南、设计指南和编码规则）有更详细的定义，需要在架构阶段完成软件集成测试规范和软硬件集成测试规范。
