聊聊硬件安全设计以及硬件安全机制相关的内容

今天我们先聊硬件安全需求，硬件安全设计以及硬件安全机制相关的内容，硬件架构度量及随机失效的评估，我们下一篇单独聊。   正式聊之前，为便于理解，先说明以下几点:

1

功能安全研究范围为电子电气系统，即E/E系统，所以这里的硬件特指控制器硬件，包括控制器I/O接口，控制器芯片等，非传统的机械硬件。

2

硬件同样存在系统失效，即由于人为设计疏忽导致的失效，需要对设计过程进行相应约束，包括开发流程，方法，测试验证等，保证硬件安全。

3

ISO 26262中基于概率论的定量危害分析仅限适用于硬件部分，因为只有硬件存在随机失效，并符合概率分布原理。

4

硬件开发和系统，软件开发一样，都基于V模型，但有两个过程区分于传统V模型开发流程，即概率论定量分析，包括硬件架构度量和随机硬件失效的评估。

01

什么是硬件安全需求？

功能安全硬件开发始于需求，即硬件安全需求(Hardware Safety Requirement, HWSR)，而HWSR源于分配至硬件组件的TSR，是硬件相关的TSR在硬件层面的进一步细化。

HWSR包括哪些内容呢？一般来讲: 

硬件安全需求HWSR = 安全机制无关的硬件安全需求 + 硬件安全机制 

安全机制无关的硬件安全需求包括: 

1

硬件架构度量及随机硬件失效目标值要求，一般根据可以直接查表即可确定。

例如: SPFM，LFM，PMHF等，这部分会在硬件架构度量及失效评估中阐述。

2

为避免特定行为的硬件安全要求。

例如:一个特定传感器不应有不稳定输出。

3

分配给硬件的预期功能要求。

例如: 控制器必须能够外部reset。

4

定义线束或接插件的设计措施的要求。

例如: 线束或插件最大电流需求。  

硬件安全机制包括:

1

针对内部硬件要素(包括传感器，控制器和执行器)失效的安全机制。

例如: 看门狗，比较器，双核锁步 (dual-core lockstep)，传感及执行器诊断等。

2

针对外部相关要素失效的容忍能力的安全机制。

例如: ECU 的输入开路时，要求 ECU 应具备的功能表现。

3

针对内外部要素失效对应安全机制的响应特性需求。

例如: 安全机制中定义的硬件元器件的故障响应时间要符合ISO 26262-4:2018, 6.4.2中要求的故障容错时间间隔以及多点故障探测时间间隔。

怎么从TSR得到HSR呢？

HWSR属于由硬件相关的TSR细化得到硬件层面安全需求，只要在系统开发阶段有效识别出硬件相关的TSR，HWSR导出相对比较容易。   具体来说，根据硬件相关TSR，对其进行安全分析或直接根据经验，分别针对组成HWSR的三个部分进行分析：

为避免硬件内部失效措施

为避免外部相关失效对应的内部措施

为避免硬件随机失效的概率度量要求

将其作为HWSR即可，具体见下图:

02

硬件安全设计

硬件安全设计主要包括两个方面:

硬件安全架构设计

硬件安全详细设计

硬件安全架构和详细设计均基于HWSR，硬件安全架构的设计旨在描述硬件组件以及其彼此的相互关系，更重要的是将硬件架构相关的HWSR，尤其是安全机制应用于硬件架构，为后续硬件详细设计提供基础。

硬件安全机制是硬件安全设计中最核心的内容，我们会在第三部分单独阐述。除此之外，ISO 26262-5:2018第7部分还对硬件安全架构和详细实现设计提出了相关约束，主要包括:

对硬件安全架构设计而言:

硬件架构应能够承载HWSR。

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

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

─ 按最高ASIL等级

─ 要素共存FFI

对硬件安全要求和实施之间的可追溯性。

为避免系统失效, 硬件架构应具有下述特性:

─  模块化; ─  适当的粒度水平;及

─  简单性。

在硬件架构设计时，应考虑安全相关硬件组件失效的非功能性原因，例如: 温度、振动、水、灰尘、电磁干扰、来自硬件架构的其他硬件组件或其所在环境的串扰。

对硬件详细实现设计而言:

为了避免常见的设计缺陷, 可运用相关的经验总结。

在硬件详细设计时, 应考虑安全相关硬件元器件失效的非功能性原因, 可包括以下的影响因素:温度、振动、水、灰尘、电磁干扰、噪声因素、来自硬件组件的其他硬件元器件或其所在环境的串扰。

硬件详细设计中, 硬件元器件的运行条件应符合它们的环境和运行限制规范。

应考虑鲁棒性设计原则。

03

硬件安全机制

硬件相关安全机制是组成HWSR最重要组成部分，是硬件安全设计最重要的体现，也是功能安全ISO 26262中最晦涩难懂的内容之一。

ISO 26262-5:2018附录D中列出了控制器硬件可能存在的故障，对应的安全措施及覆盖率，为后续硬件概率度量提供了基础，基本上涵盖了硬件通用的安全机制，强烈建议多看几遍。

一般来讲，一个E/E系统中硬件主要包括: 传感器(D.9)，继电器/连接件(D.3)，Digital输入/输出(D.5)，Analog输入/输出(D.5)，总线(D.6)，处理器(D.4)，时钟(D.8)，执行器(D.10)，具体如下图所示: 

由于内容过多，我们接下来以其中最重要的硬件之一，即处理器(D.4)为例，介绍处理器相关的硬件安全机制。   处理器(CPU)是微控制器(MCU)的核心，是负责读取指令，对指令译码并执行指令的核心部件，ISO 26262-5:2018附录D中，处理器相关的安全机制及诊断覆盖率如下所示: 

CPU主要由运算器，控制器，寄存器组成，所以针对处理器的安全机制也主要针对这三大部分。由于表格里的处理器相关安全机制分类存在一定重叠，且不是很好理解，个人将其进行总结分类如下: 

自检

硬件冗余

看门狗

程序流监控

自检  

根据自检方法，自检安全机制一般可以分为: 

软件自检

对安全相关路径中的使用到的指令，利用预先设置好或自动生成的数据或代码，对物理存储(例如，数据和地址寄存器)或运算器及控制器(例如，指令解码器)，或者它们两者进行检测。

硬件自检

在控制单元内部集成专用自检硬件，最常见的就是内建自测试(BIST)，通过在芯片设计中加入额外自测试电路，测试时从外部施加控制信号，运行内部自测试硬件和软件，检查电路缺陷或故障，是防止故障潜伏的重要安全机制。

BIST一般仅在处理单元初始化或者下电时运行，所以不能覆盖瞬态故障，根据其自检时间一般可以分为:

1

Online Self-test: 在车辆启动时间限制内尽可能多地进行测试。

2

Offline Self-test: 车辆停机或诊断测试，最大的测试覆盖率，车辆断电时没有时间限制。

3

Periodic Self-test: 车辆在正常操作模式下，进行的诊断测试。

而根据其自检的内容，BIST又可以分为:

1

MBIST(Memory Built-In Self Test): 对memory，包括RAM或ROM，进行读写测试操作，判断Memory是否有制造缺陷，属于内存相关的安全机制。

2

LBIST(Logic Built-In Self Test): 对芯片内逻辑电路进行自检，属于处理器相关安全机制。

其中，LBIST是硬件自检非常重要的安全机制，其工作原理如下图所示:

具体来讲，首先利用测试生成器，生成测试向量，然后将测试向量输入被测试电路，最后BIST控制器将测试电路输出结果和预存的结果进行对比，一旦二者存在差异，则表明被测试电路存在故障。

硬件冗余

硬件冗余是处理器或控制器最重要的安全机制之一，根据硬件冗余的形式，控制器硬件冗余一般可以分为以下两大类:  

双(多)MCU硬件冗余

使用两个相同或不同类型的MCU，进行硬件冗余，二者相互独立，构成主，副功能链路，其中一个MCU负责功能实现，另外一个对功能安全要求较高的MCU负责功能安全需求实现，二者输出结果进行相互比较并控制安全输出。   优点在于: 物理复制安全相关和非安全相关的功能与特性，避免相关失效鲁棒性高，可以实现Fail Operational 系统架构，当其中一个MCU失效后，另外一个MCU可以实现全部或部分功能，维持系统继续运行，多用于高级辅助和自动驾驶控制系统。  

缺点在于: 配置复杂，成本高，再加上软件同步及PCB空间增加等因素，会给带来巨大的挑战和障碍。

示例: 双控制单元EPS控制系统。

来源: Freescale

单MCU硬件冗余

单MCU硬件冗余一般采用CPU冗余，形成双(多)核MCU，并采用双核锁步技术(Dual Core LockStep)。

双核: 两个相同的核镜像，90°旋转，隔离设计，间距100um。

锁步: 两个核运行相同程序并严格同步，一个输入延迟，另外一个输出延迟，延迟时间一般为2-3个时钟周期，计算结果利用比较逻辑模块进行比较，检测到任何不一致时，就会发现其中一个核存在故障，但不会确定是哪个核故障。

双核锁步是一种综合性的硬件安全机制，可以有效覆盖CPU执行指令，设计电路等相关失效，具体如下图所示:

在E-Gas三层功能安全架构中，第二层，即功能监控层可以采用双核锁步安全机制，并且功能安全相关和非相关的软件可以进行分区，使用不同的硬件资源(例如,不同的 RAM、ROM 存储范围)可提高诊断覆盖率。  

示例: 双核锁步(Dual core Lookstep)EPS控制系统。

来源: Freescale

其中，MCU采取双核锁步模式，并且存在独立的监控单元，工作于低功耗模式，对双核MCU进行电源管理和安全监控。

看门狗 

看门狗定时器 (WDT) 是一种定时器，用于监视微控制器 (MCU)程序，查看它们是否失控或停止运行，充当监视MCU 操作的“看门狗”。

MCU正常工作的时候，每隔一段时间输出一个信号到喂狗端，给WDT清零，如果超过规定的时间不喂狗，WDT就会给出一个复位信号到MCU，使MCU复位。

看门狗基本类型及主要特点如下图所示:

对于功能安全而言，主要采用硬件看门狗作为安全机制。根据其实现复杂度，它可以工作于不同模式:

计时模式(Time out mode)

时间窗模式(Window mode)

问答模式(Q&A mode)

从上往下，其可靠度和复杂度依次上升。

除此之外，还必须注意以下几点:

看门狗必须在系统初始化中进行测试，避免看门狗自身故障。

看门狗输入为喂狗(kicking the dog/service the dog)，必须在特定的时间或时间窗内喂狗，否则会触发相应Reset端或功能降级。

程序流监控 

程序流监控的实现的本质是看门狗，用于检查程序是否按照预期的执行顺序执行。如果监控实体以不正确的顺序执行，或在规定的截止时间或时间窗内没有被执行就出现不正确的程序流。

具体应用过程中，可以在功能安全相关的一个或多个监测实体中按照程序预期的执行顺序设置一个或多个Checkpoint，如果在特定的时间限制内，Checkpoint没有被依次执行，则会触发相应的复位或错误处理机制。

需要注意的是:

1

在ISO 26262-5:2018附录D中，将看门狗和程序流监控这部分安全机制归为时钟(D.8)故障的安全机制，但它们还是主要应用于处理器(D.4)，所以本文将其归类到处理器相关的硬件安全机制。

2

实际应用中，程序流监控一般直接包含于看门狗安全机制，例如AUTOSAR中看门狗管理器WdgM，可以实现周期性，非周期性以及逻辑监控。

3

硬件相关安全机制很多并不是单独存在的，例如，看门狗安全机制可以和其他硬件安全机制相互结合使用，利用看门狗问答模式(Q&A mode)可以将程序流监控和功能安全相关的CPU指令测试安全机制相结合，对监控单元提出的问题各自提供部分答案，实现对功能安全控制硬件的有效监控。

审核编辑：刘清