-
什么是硬件安全需求 -
硬件安全设计 -
硬件安全机制 -
硬件架构度量及随机失效的评估 -
硬件集成及验证
1
功能安全研究范围为电子电气系统，即E/E系统，所以这里的硬件特指控制器硬件，包括控制器I/O接口，控制器芯片等，非传统的机械硬件。
2
硬件同样存在系统失效，即由于人为设计疏忽导致的失效，需要对设计过程进行相应约束，包括开发流程，方法，测试验证等，保证硬件安全。
3
ISO 26262中基于概率论的定量危害分析仅限适用于硬件部分，因为只有硬件存在随机失效，并符合概率分布原理。
4
硬件开发和系统，软件开发一样，都基于V模型，但有两个过程区分于传统V模型开发流程，即概率论定量分析，包括硬件架构度量和随机硬件失效的评估。
01
什么是硬件安全需求？
HWSR包括哪些内容呢？一般来讲:
-
安全机制无关的硬件安全需求包括:
1
硬件架构度量及随机硬件失效目标值要求，一般根据可以直接查表即可确定。
例如: SPFM，LFM，PMHF等，这部分会在硬件架构度量及失效评估中阐述。
2
为避免特定行为的硬件安全要求。
3
分配给硬件的预期功能要求。
4
定义线束或接插件的设计措施的要求。
-
硬件安全机制包括:
1
针对内部硬件要素(包括传感器，控制器和执行器)失效的安全机制。
2
针对外部相关要素失效的容忍能力的安全机制。
3
针对内外部要素失效对应安全机制的响应特性需求。
例如: 安全机制中定义的硬件元器件的故障响应时间要符合ISO 26262-4:2018, 6.4.2中要求的故障容错时间间隔以及多点故障探测时间间隔。
怎么从TSR得到HSR呢？
-
为避免硬件内部失效措施 -
为避免外部相关失效对应的内部措施 -
为避免硬件随机失效的概率度量要求
02
硬件安全设计
硬件安全设计主要包括两个方面:
-
硬件安全架构设计
-
硬件安全详细设计
硬件安全架构和详细设计均基于HWSR，硬件安全架构的设计旨在描述硬件组件以及其彼此的相互关系，更重要的是将硬件架构相关的HWSR，尤其是安全机制应用于硬件架构，为后续硬件详细设计提供基础。
硬件安全机制是硬件安全设计中最核心的内容，我们会在第三部分单独阐述。除此之外，ISO 26262-5:2018第7部分还对硬件安全架构和详细实现设计提出了相关约束，主要包括:
对硬件安全架构设计而言:
-
硬件架构应能够承载HWSR。
-
HWSR应该被分配至硬件架构中的组件。
-
不同或非ASIL等级硬件组件开发需满足以下原则之一:
─ 要素共存FFI
-
对硬件安全要求和实施之间的可追溯性。
-
为避免系统失效, 硬件架构应具有下述特性:
─ 简单性。
-
在硬件架构设计时，应考虑安全相关硬件组件失效的非功能性原因，例如: 温度、振动、水、灰尘、电磁干扰、来自硬件架构的其他硬件组件或其所在环境的串扰。
-
为了避免常见的设计缺陷, 可运用相关的经验总结。
-
在硬件详细设计时, 应考虑安全相关硬件元器件失效的非功能性原因, 可包括以下的影响因素:温度、振动、水、灰尘、电磁干扰、噪声因素、来自硬件组件的其他硬件元器件或其所在环境的串扰。
-
硬件详细设计中, 硬件元器件的运行条件应符合它们的环境和运行限制规范。
-
应考虑鲁棒性设计原则。
03
硬件安全机制
硬件相关安全机制是组成HWSR最重要组成部分，是硬件安全设计最重要的体现，也是功能安全ISO 26262中最晦涩难懂的内容之一。
ISO 26262-5:2018附录D中列出了控制器硬件可能存在的故障，对应的安全措施及覆盖率，为后续硬件概率度量提供了基础，基本上涵盖了硬件通用的安全机制，强烈建议多看几遍。
-
自检
-
硬件冗余
-
看门狗
-
程序流监控
自检
根据自检方法，自检安全机制一般可以分为:
-
软件自检
对安全相关路径中的使用到的指令，利用预先设置好或自动生成的数据或代码，对物理存储(例如，数据和地址寄存器)或运算器及控制器(例如，指令解码器)，或者它们两者进行检测。
-
硬件自检
在控制单元内部集成专用自检硬件，最常见的就是内建自测试(BIST)，通过在芯片设计中加入额外自测试电路，测试时从外部施加控制信号，运行内部自测试硬件和软件，检查电路缺陷或故障，是防止故障潜伏的重要安全机制。
BIST一般仅在处理单元初始化或者下电时运行，所以不能覆盖瞬态故障，根据其自检时间一般可以分为:
1
Online Self-test: 在车辆启动时间限制内尽可能多地进行测试。
2
Offline Self-test: 车辆停机或诊断测试，最大的测试覆盖率，车辆断电时没有时间限制。
3
Periodic Self-test: 车辆在正常操作模式下，进行的诊断测试。
1
MBIST(Memory Built-In Self Test): 对memory，包括RAM或ROM，进行读写测试操作，判断Memory是否有制造缺陷，属于内存相关的安全机制。
2
LBIST(Logic Built-In Self Test): 对芯片内逻辑电路进行自检，属于处理器相关安全机制。
其中，LBIST是硬件自检非常重要的安全机制，其工作原理如下图所示:
硬件冗余
-
双(多)MCU硬件冗余
缺点在于: 配置复杂，成本高，再加上软件同步及PCB空间增加等因素，会给带来巨大的挑战和障碍。
示例: 双控制单元EPS控制系统。
来源: Freescale
-
单MCU硬件冗余
单MCU硬件冗余一般采用CPU冗余，形成双(多)核MCU，并采用双核锁步技术(Dual Core LockStep)。
双核: 两个相同的核镜像，90°旋转，隔离设计，间距100um。
锁步: 两个核运行相同程序并严格同步，一个输入延迟，另外一个输出延迟，延迟时间一般为2-3个时钟周期，计算结果利用比较逻辑模块进行比较，检测到任何不一致时，就会发现其中一个核存在故障，但不会确定是哪个核故障。
示例: 双核锁步(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指令测试安全机制相结合，对监控单元提出的问题各自提供部分答案，实现对功能安全控制硬件的有效监控。
写在最后:
，希望这篇能够给朋友们理解功能安全硬件开发带来帮助，下期我们继续看功能安全硬件开发阶段之概率化度量以及计算相关内容。
。
END
【点赞】和【在看】= 原创的动力
多谢【点赞】和【在看】
原文始发于微信公众号（AUTO世代）：07 – 汽车功能安全(ISO 26262)系列: 硬件开发 – 硬件安全需求，安全设计及安全机制
