汽车功能安全软件开发阶段软件架构安全设计

上一篇我们已经聊完了软件安全需求SWSR相关内容，接下来以此为基础，我们需要对软件架构进行安全设计，将安全机制相关的SWSR应用于软件架构当中，为后续软件详细设计提供基础，是软件功能安全开发重要内容。

01

软件架构安全设计任务

软件安全架构旨在刻画出实现软件功能安全基本的软件框架，需要在系统架构的基础上，对其软件部分进行进一步细化，开发满足软件功能安全要求的软件架构设计。  

一般来讲，软件架构设计需要同时考虑安全相关和非安全相关的软件要求，安全相关的需求甚至很大程度上决定了软件架构的形式，例如，是否需要分层设计，软件分区等。  

对于分层式软件架构设计，功能安全架构部分可以相对独立进行设计。但不管安全或非安全相关软件架构的设计，其任务都在于描述：  

软件架构要素的静态设计方面，包括；

 ─ 分级层次的软件结构；  ─ 数据类型和它们的特征参数；  ─ 软件组件的外部接口；  ─ 嵌入式软件的外部接口；  ─ 全局变量；  ─ 包括架构的范围和外部依赖的约束。  

软件架构要素的动态设计方面，包括：

 ─ 事件和行为的功能链；  ─ 数据处理的逻辑顺序；  ─ 控制流和并发进程；  ─ 通过接口和全局变量传递的数据流；  ─ 时间的限制。  

所以，不管系统还是软件架构，都包含静态和动态特性，这两方面特性描述越全面，越利于后续软件详细设计，在实际应用中可根据需要选择。  

02

软件架构开发常见视图

为了描述软件架构静态和动态特性，ISO 26262对软件架构设计的标记法进行明确规定，包括: 自然语言，非半形式，半形式(伪代码，UML,SysML，Simulink等)，形式记法(可运行代码)，其中对于ASIL等级C和D软件安全需求对应的架构设计强烈推荐采用半形式法进行。  

在实际架构设计过程中，一般采用通用化建模语言UML或SysML，目前大部分架构设计软件都支持这两种设计语言，如Enterprise Architect， Cameo等。  

此外，这些架构设计语言及软件和后续软件设计一脉相承，可以将相应的软件架构视图直接导入AUTOSAR或SIMULINK等软件开发工具，以此为基础直接用于软件详细设计。

当然，也可以直接采用AUTOSAR等软件开发工具链进行，进行软件架构设计，形成ARXML描述文件，其图形化设计语言也属于半形式标记法。  

为了刻画软件架构静态和动态特性，往往需要采用不同的软件视图，即从不同的角度，描述软件架构的行为。  

UML或SysML为描述架构静态和动态特性，分别引入了两大类视图：  

1

结构视图: 描述架构静态结构和接口。 常见的结构视图包括，类图，组件图，复合结构图，包图等。

2

行为视图: 描述架构动态行为，例如数据流，控制流，不同状态切换等。

常见的行为视图包括，用例图，活动图，时序图，状态图，交互纵览图等。

如下图所示，一般来讲，UML和SysML视图类型存在部分重叠，也存在一定差异，例如需求及参数视图属于SysML独有。二者在视图语言规则类似，UML多用于软件架构设计，而SysML多用于系统设计，二者可以混合使用。

 

在实际应用过程中，可根据需要，采取不同视图，描述软件架构的不同特性，之后可以专门给朋友们聊聊UML和SysML视图。

以一个组件为例，其UML组件图如下图所示，用于描述组件内部子组件及其接口关系。

疑问解答: 在软件定义汽车，为应对不断增加的软件复杂度，架构的重要性毋庸置疑，但很多朋友可能会好奇，为什么非要采取UML/SysML等半形式标记法描述架构，真的有必要吗?

1

图比传统语言，代码更清晰，易懂。

2

ISO 26262 对架构设计标记法明确，对于ASIL C和D的系统，强烈推荐使用半形式标记法，即UML或SysML。

3

图可以描述复杂系统或者过程，统一建模语言及视图统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。

4

为基于AUTOSAR的系统设计阶段提供输入和后续软件详细设计提供基础。

03

软件架构安全设计

软件架构安全的设计的本质是将和架构相关的软件安全需求SWSR应用于软件架构设计，初步确定软件功能安全实现的基本框架和方式，为后续软件详细设计提供基础。  

除经典AUTOSAR的软件架构，将软件整体分为应用层，TRE通讯层，基础软件层外，为实现软件功能安全，还会将功能安全和非功能安全软件进行分层设计。例如E-Gas三层架构，将软件整体分为功能层，功能监控层和控制器监控层，其中功能层和功能监控层均属于AUTOSAR中应用软件层，控制器监控层为基础软件层，二者相互统一，并不矛盾。  

总体来讲，根据不同的软件分层，软件架构安全设计基本分为两大部分：

功能监控层安全设计

基础软件安全设计

 3.1 功能监控层安全设计  

对于软件监控层架构安全设计而言，主要是将软件架构相关的SWSR，即错误探测和错误处理安全机制，应用于软件监控层的架构设计。  

功能监控层属于独立于软件功能实现的功能安全开发内容，一般按照相应ASIL等级进行独立开发，对功能层中功能安全相关部分进行监控，包括输入输出诊断，逻辑监控，故障分类及故障优先级仲裁等。  

在功能监控层软件架构设计，主要是将和架构相关的错误探测和错误处理等安全机制，应用于功能监控层架构设计。虽然根据不同类型的控制器，其安全机制具体实施有所差别，但总体而言，主要包含以下安全机制：  

用于错误探测的安全机制包括：

─ 输入输出数据的范围检查； ─ 合理性检查(例如，使用期望行为参考模型、断言检查、或不同来源信号比较)； ─ 数据错误探测（例如，检错码和多重数据存储）； ─ 外部要素监控程序执行，例如，通过专用集成电路（ASIC）或者其他软件要素来执行看门狗功能。监控可以是逻辑监控或时间监控，或者两者的结合； ─ 程序执行的时间监控； ─ 设计中的异构冗余；或 —在软件或硬件中实施的访问冲突控制机制，与授权访问或拒绝访问安全相关共享资源有关。  

用于错误处理的安全机制可能包括：

─ 为了达到和维持安全状态的功能关闭； ─ 静态恢复机制（例如，恢复块、后向恢复、前向恢复以及通过重试来恢复）； ─ 通过划分功能优先级进行平稳降级，从而最小化潜在失效对功能安全的不利影响； ─ 设计中同构冗余，主要侧重于控制运行相似软件的硬件中瞬态故障或随机故障的影响(例如，软件在时间上的冗余执行)；   具体来讲，在功能监控层架构设计过程中，可以根据具体监控的功能，进行相应的异构冗余计算，对其输入，输出，进行范围及合理性检查，异构冗余计算程序执行过程进行时内部或外部要素的时间或逻辑监控，一旦发现错误，通过错误处理机制，将系统导入安全状态。  

实例：以整车控制器加速踏板信号为例，其ASIL等级要求一般为D，为了实现该安全需求，需要从软件和硬件两个方面着手: 硬件安全方面主要是加速度传感器本身冗余及双路冗余采样等。软件安全方面主要是以上述安全机制的具体应用，例如，两路加速踏板传感器信号自身故障诊断，信号电压范围是否在有效范围内，和制动踏板信号之间的合理性检验，双路信号是否同步等等。  

同样，在软件开发过程中，ISO 26262并没有也没办法明确哪个ASIL等级应该采取哪些软件安全机制，根据个人经验，一般存在以下两种方式可以进行参考：  

ISO 26262第5部分硬件开发附件中对不同类型安全机制诊断覆盖率进行高中低分类，可以依据安全机制覆盖率的中高低分别应用于ASIL D，C，B类型的安全需求。

依靠以往开发经验，一般对于ASIL D或C的安全需求，需要根据适用性采取目前State of Art的所有或大部分安全机制，对于ASIL B或A的安全需求，则没有明确要求。

3.2 基础软件安全设计

基础软件多和控制器硬件相关，是保证上层软件(应用层，功能监控层)正常运行基本条件。

在经典的AUTOSAR软件平台，为实现独立于控制器硬件，多平台软件复用，采用了RTE层和基础软件层，通过标准化接口规范，逐级对硬件进行抽象，对上提供统一访问接口，以此实现软硬件分离。

对于基础软件安全设计而言，主要是对基础软件提出的更高的功能安全方面的需求，从ISO 26262角度而言，依据非或不同ASIL等级要素共存原则，基础软件开发存在两种方式：

3.2.1 全部依据最高ASIL等级开发

以AUTOSAR为例，如下图所示，全部基础软件，包括OS，内存分配，通讯等均统一按照最高ASIL等级开发。

优点: 安全性能高，软件主体为功能安全组件，之间无需额外安全机制保护，运行效率高。

缺点: 底层模块需按ASIL等级开发，成本高，但随着软件复杂度不断提高，为降低开发复杂度和增加软件可靠性，逐渐成为趋势。

3.2.2 采用Partition，使用免于干扰(FFI)，要素共存措施

为降低开发成本，目前基于功能安全和非功能安全的Partion类型开发也尤为常见。为了实现非或不同ASIL等级要素共存，除了在功能监控层对其开发进行区别对待外，还需要在基础软件部分采用相应的安全措施，避免高ASIL等级软件受到低ASIL等级或QM软件的干扰，进而破坏安全需求，具体如下图所示:

3.2.2.1 FFI干扰类型

ISO 26262共定义以下三种类型的干扰: 

执行和时序(Timing &Execution)干扰

软件在执行和调度过程中出现的组件间的干扰主要包括:

─ 执行阻塞 (blocking of execution): 一个任务有CPU控制，阻塞了另外一个任务。

─ 死锁 (deadlocks): 每一个处于等待状态的任务相互等待释放已经被锁定的资源。

─ 活锁 (livelocks) :  进程状态不断变化，但仍相互依赖，永远无法完成它们的任务。

─ 执行时间的不正确分配 (incorrect allocation of execution time)。

─软件要素间的不正确同步 (incorrect synchronization between software elements)。

其对应的安全机制包括:

─ 内外部看门狗(Internal/External Watchdog)

─ 程序监控(Program Flow Monitor)

内存(Memory)干扰

软件组件内存干扰类型主要包括:

─ 内容损坏(corruption of content)

─ 数据不一致(inconsistent data (e.g. due to update during data fetch))

─ 堆栈溢出或下溢(stack overflow or underflow)

─ 对已分配给其他软件要素的内存进行读写访问(read or write access to memoryallocated to another software element)

其对应的安全机制包括:

─ 内存分区，使用内存保护单元(MemoryProtection Unit , MPU)来实现软件分区。

信息交换(Exchange of information)干扰

发送方(Sender)和接收方(Receiver)之间的数据交换对系统的功能安全造成影响:

─ 信息重复 (repetitionof information)

─ 信息丢失 (lossof information)

─ 信息延迟 (delayof information)

─ 信息插入 (insertionof information)

─ 信息次序不正确 (incorrectsequence of information)

─ 信息伪装或不正确寻址(masquerade or incorrectaddressing of information)

─ 信息损坏 (corruptionof information)

─ 从发送方传送到多个接收方的信息不对称(asymmetric information sent from a senderto multiple receivers)

─ 发送方发送的信息只能被部分接收方接收(information from a senderreceived by only a subset of the receivers)

─ 通信信道阻塞(blocking access to a communicationchannel)。

其对应的安全机制包括:

─ 循环冗余校验(cyclic redundancy check)

─ E2E保护 (End2End Protection)

3.2.2.2 要素共存(FFI)解决方案

看完这些FFI干扰类型，大家先不要慌，基础软件多标准化开发，在不同软件平台直接采用开发工具链配置即可。

例如，Vector提供AUTOSAR的ECU解决方案，包括源代码MICROSAR和DaVinci系列配置工具，其中和功能安全相关的软件模块 MICROSAR Safe如下图所示:

针对FFI不同干扰类型以及安全机制，分别对应相应的基础软件安全模块，包括:

Safe OS，SafeRTE， SafeWDG，SafeE2E等等，具体使用需要根据相应开发工具链进行配置就可，但相对成本也较高。

除此之外，ISO 26262对功能安全相关的软件架设计，还根据不同ASIL等级，提出了其他相关约束，包括:  

1

软件架构细致程度应能够承载SWSR。

2

软件架构设计原则，包括: 适当分层，限制软件组件规模和复杂度，限制接口规模，组内高内聚，组间低耦合，限制中断使用等。

3

软件架构设计验证方法，包括: 设计走查，设计检查，控制流，数据流分析，仿真，快速原型等。

4

HWSR应被分配至软件架构中的组件。

5

不同或非ASIL等级软件组件开发需满足以下原则之一:

─ 按最高ASIL等级。

─ 要素共存FFI，例如软件分区。

6

对SWSR和具体实施之间的可追溯性。

架构设计约束详细内容及表格可以直接查看ISO 26262-6:2018 第7章节内容，在此不再赘述。

审核编辑：刘清