聊聊汽车功能安全系统开发阶段系统安全架构

我们详细地介绍了系统开发阶段，TSR，安全机制，TSC，安全分析等相关的内容，今天我们聊系统开发阶段最后一部分内容，即系统安全架构:

系统架构作用

系统架构相关安全机制

系统安全架构

01

系统架构作用

架构是一门艺术，在整车汽车系统，软/硬件开发过程中非常重要，尤其在基于模型的系统开发(MBSE)中，架构是整个开发过程的核心之一。

一般来讲，系统架构一般采用通用化建模语言UML或SysML在相关架构开发软件，如Enterprise Architect， Cameo等，进行开发。但可惜的是，目前大部分车企都没有完整的系统架构或多基于PowerPoint等形式的简单架构描述。

在功能安全第三部分概念开发和第四部分系统开发过程中，都需要系统架构作为输入条件，借助系统架构进行安全分析，导出功能安全需求(FSR)和技术安全需求(TSR)，并将相应的安全需求分配至系统架构。

但在系统开发阶段，我们还需要对系统架构进行功能安全相关内容进一步开发，将架构相关的安全机制融入系统架构当中，形成系统安全架构(Safety Architecture)，以此勾勒出实现系统技术安全需求所需要的核心技术框架，为后续软件和硬件架构的详细设计提供基础。

02

系统架构相关安全机制

很多朋友一直有个疑问，对于不同的ASIL等级应该具体采取哪些安全机制呢?

这是个很好的问题，一般来说ASIL等级越高，需要采取的安全机制数目及质量要求越高。

但ISO 26262并没有，其实也没有办法明确哪个ASIL等级应该具体采取哪些安全机制，只有对硬件部分，不同覆盖率(中，高，低)对应的安全机制的推荐。

主要原因在于: 

虽然有一些通用的安全机制，但研究对象不同，采用的安全机制也不尽相同。

为功能安全技术实施多样性提供更多空间和选择，便于不同企业根据自身技术积累和开发条件进行实施。

为技术更新换代提供可能性。随技术发展，很多新的安全机制得以实现或得以在汽车行业应用。

如果ASIL等级和安全机制一一挂钩，强制执行，可能很多车企的车都没办法上市了(你懂的)。

我们先看看不含安全机制的系统架构长什么样? 

系统架构旨在描述相关项组成和相互作用和约束。根据ISO 26262定义，相关项由一到多个系统构成，而一个系统应该至少包括一个传感器，一个控制单元，一个执行器。当然，一个系统也可以包含多个子系统。

所以一个最简单的系统架构如下:

那有哪些系统层面的安全机制可以融入系统架构，进而形成系统安全架构呢？

既然一个最简单的系统由三个部分构成，那么系统级别和架构相关的安全机制肯定也是和这三个部分以及三者之间的通讯安全相关。

下面我们一起看看系统层面和架构相关的常见的安全机制:

传感器

─ 传感器硬件冗 ─ 独立供电 ─ 多通道冗余采集 ─ 信号质量检测

控制单元

─ 在线诊断

─ 比较器

─ 多数投票器

执行器

─ 执行器硬件冗余

─ 执行器控制信号质量检测

通讯

─ 冗余发送

─ 信息冗余(CRC)

─ 时间监控

─ 问答机制

需要注意的是，系统阶段的安全机制主要作用是勾勒出实现系统功能安全所需的核心技术框架，明确应该采取哪些技术手段实现相应的安全目标，不会涉及具体的实施细节，这个会在后续软件和硬件开发阶段进一步明确。

从上述安全机制可以看出，虽然安全机制的种类有很多，但无非都源于以下三个角度: 

1

冗余性: 使用相同的功能组件(多指硬件)降低硬件随机失效，增加功能安全的可靠性，例如传感器，执行器冗余等。

2

多重性: 多用于故障关闭路径，使用多个关闭路径或保护设备，提供了防止单个设备失效的保护。

3

多样性: 使用不同类型的设备或者软件多样化设计，降低共因失效的可能性。

03

系统安全架构设计

了解系统架构相关的安全机制，接下来我们就将这些安全机制融入原有的系统架构，分别看看系统不同组成部分，融入安全机制后形成的系统安全架构长什么样？

3.1 传感器部分

首先，我们在系统中融入传感器部分安全机制，需要注意的是，此处的传感器代表广义的输入信息，可以是具体传感器信号，也可以是其他类型通讯信息，例如CAN，SENT等。

传感器的硬件冗余(当然传感器必须独立供电)多适用于对于ASIL等级要求非常高的信号，如ASIL  C, D，尤其是D，其主要目的是为避免传感器硬件随机失效，通过信号相互校验，增加系统输入信息可靠性。

这里的传感器硬件冗余采集，可以是利用相同的两个传感器，对同一信号进行重复采集(例如，踏板信号)，也可以是利用不同类型传感器，对强相关的两个信号分别进行采集(例如，制动踏板位置和压力信息等)。

当然，传感器输入冗余信息，在控制单元中，必须进行多路采集，除传感器本身提供诊断信息外，还需要对其信号有效性进行检验，包括数值有效范围检测，在线监控，Test Pattern，输入对比，相关性，合理性检测等。

3.2 控制单元

控制单元属于整个系统中最重要的部分，控制单元相关的安全机制其实很大程度上决定了系统安全架构和系统复杂程度。

提到控制单元相关的安全机制，很多朋友第一反应是，控制器软件分层，控制器硬件冗余(双控制器，Dual Core LockStep双核锁步等)，看门狗，程序流监控等。

虽然这些都是控制单元常用的安全机制，但从系统角度而言，它们相对过于具体，只是针对某一类故障而设计的软件或硬件安全机制，需要在系统安全架构基础上具体明确。

接下来我们从系统角度，先看看系统级别安全架构，后续无非就是将具体的软件和硬件安全机制逐步应用于系统架构当中去。

一般来说，所有的安全机制本质上都服务于两类安全架构:

Fail to safe 

Fail to operational 

3.2.1 Fail to safe 

Fail to safe是目前汽车行业应用最广泛的安全架构，最典型的应用就是在线监控，将整个控制单元分为功能实现和在线监控两部分，即所谓的的1oo1D类型系统，具体如下图所示:

其中: 

功能实现部分一般按正常开发流程就行开发，主要实现系统的功能性需求，不需要考虑功能安全需求(也就是全部QM)。

监控单元用于实现系统功能安全相关的需求，主要目的在于对功能实现部分进行安全监控，在线监测功能实现部分是否按照预期运行。一旦发现问题，就将系统导入安全状态，停止提供系统原有功能或者维持最必要的功能。

需要注意的是，监控单元非功能层全部功能的多样化复现，不能独立于功能实现部分单独存在，ASIL等级则直接决定了监控单元的硬件及软件复杂度。

对于ASIL等级要求较高的系统，监控单元软件一般独立于功能层。为实现有效监控，在监控单元不仅需要对功能层中，和功能安全相关的输入和输出进行诊断，还需要对功能安全相关的计算逻辑进行监控，计算执行器关键控制信号的安全输出范围，并和功能层计算结果进行对比，甚至需要对控制器硬件进行额外的硬件监控。

如下图所示，发动机控制单元最常见的E-Gas三层安全架构就属于典型的1oo1D的应用，包括功能应用层，功能监控层，控制器监控层。

E-Gas三层安全架构，虽然是针对发动机控制单元，但属于非常经典安全架构，广泛应用于传统控制系统(例如传动，整车控制)当中，三层分层架构本质为原有ASIL等级的分解，即QM (ASILD)+ X(ASILX):

1

功能层: 功能实现部分，使得较为复杂的功能实现部分得以按照QM开发，无需考虑功能安全需求，专注于复杂功能软件的开发和复用。

2

功能监控层: 按照原有ASIL等级进行独立开发，对功能层中功能安全相关部分进行监控，包括输入输出诊断，逻辑监控，故障分类及故障优先级仲裁等。

3

控制器监控层: 对功能控制器，尤其是功能监控层控制器硬件进行监控，一般采用独立的监控单元(一般采用ASIC基础芯片)对功能控制器中内存，CPU，通讯，定时器等进行监测和保护。

目前E-Gas三层安全架构已经更新了很多版，强烈建议朋友们多读几遍，一定会深受启发，之后有机会也可以给朋友们专门介绍一下。

当然，分层安全架构只是1oo1D其中一种实现方式，对于ASIL等级要求不高或者功能简单的控制系统，不一定非得采用分层架构，监控层也可以相应简化。

3.2.2 Fail to operational 

Fail to operational 属于相对高级的安全架构，比较器和多数投票器都属于这类安全架构，整个系统由相对独立的两条或多条功能链路构成，每条功能链路都有拥有自己独立的传感器，控制单元，甚至执行器。当其中一条功能链路出现异常，控制系统可以切换到其他功能链路，保证系统继续正常工作或者降级运行。

独立功能链路的实现需要大量的硬件冗余和多样化的软件设计，直接提高了系统成本，所以Fail to operational在汽车产品一般最多有两个独立功能链路，主要应用在对功能安全要求极高或者功能极为复杂的系统，例如自动驾驶。其中最典型的是1oo2架构，如果每个功能链路拥有独立的诊断单元(和在线监控类似)，则可以实现1oo2D安全架构，如下图所示:

其中: 

两条功能链路功能可以保持一致，通过多样化软件设计保证系统安全，或者形成主副功能链路，主功能链路利用高性能计算单元实现复杂的功能计算，副功能链路对控制器硬件安全性及可靠性要求高，承担系统功能安全任务，只实现系统功能安全相关的功能，一旦主功能链路出现故障，则系统切换至副功能链路。

3.3 执行器

执行器属于系统功能实现终端，执行器冗余会极大增加系统成本，一般在Fail to operational 安全架构中才会采用。例如EPS系统，制动系统等，除电动执行单元外，还必须保留机械执行路径。这也是目前自动驾驶系统，为什么还必须保留驾驶员自主驾驶所需要的全部执行输入(例如，踏板，方向盘)的根本原因。

3.4 通信安全

系统组件之间以及组件内部的通信安全，也是系统功能安全的重要内容，一般都采用信息冗余(CRC)，时间监控，问答机制等安全保护机制，主要应用就是AUTOSAR中的E2E保护，利用数据控制信息，保证信息通讯安全。

审核编辑：刘清