本文近14000字，将从以下几个方面来谈一谈处理器芯片的安全架构设计：
一. 芯片硬件安全设计
1.1 双核锁步架构(DCLS)
1.2 芯片的供电安全
1.2.1 嵌入式电压监控
1.3 芯片的时钟安全
1.3.1 低功耗振荡器时钟检测器(LPOCLKDET)
1.3.2 PLL差异检测
1.3.3 双时钟比较器(DCC)
1.3.4 外部时钟输出监控(ECLK)
1.4 芯片的存储安全
1.4.1 非存储数字组件故障模型
1.4.2 存储器故障模型
1.5 芯片温度监控
二. 芯片软件安全设计
2.1 温度检测
2.2 软件看门狗
2.3 ADC故障检测
2.4 安全通信
三. 芯片信息安全设计
3.1 硬件安全模块(HSM)
3.2 安全硬件扩展(SHE)
3.3 示例—安全板间通信（SecOC）
一、芯片硬件安全设计
微控制器(uC)的硬件安全设计一般通过“安全岛”(Safety/Security Island)来实现。安全岛是一个泛化的概念，类似于我们日常在十字路口等红绿灯时所在的专门为行人建设行人等候区，也是一种“安全岛”设施，它能为隔离人流和车流以及避免车辆失控撞向行人起到防护作用，芯片中的安全岛也是专门设计的“独立片区”用来实现安全相关功能，现在很多用于安全关键领域的芯片一般都会说明自己带有安全岛机制。
一般地，芯片上专门用于某个具有特定属性（如安全属性）的子系统或者内核，都可以用“Island”的概念来命名，主要强调局部设计的“独立性”和“特殊性”。而用于配套实现芯片专有安全功能的专属存储单元、供电模块、外设、通信总线等一系列IP的集合可以统称为“安全岛”。在“岛上”可以相对独立的执行安全相关的任务，安全岛就是这样一个给软件提供安全任务执行的一个物理环境。
安全岛模块一般独立于芯片中的其他系统和内核，需要有单独的电源域供电，单独的计算单元，内部模块和内存需要有物理隔离机制，优先级较高的中断机制，甚至是单独的安全诊断单元，可以实时诊断出“岛上”出现的问题，并且进入相应的安全状态。
接下来我们从最小系统为出发点，谈一谈芯片安全岛的实现方式。
1.1 双核锁步架构(DCLS)
双核锁步架构(DCLS)是一种片上冗余集成电路架构。在ISO26262并未针对片上冗余集成电路架构单独提要求，但在IEC61508-2中对于带片上冗余的集成电路特定架构提了相关要求。
为了允许在同 一个半导体衬底上使用片上冗余, 以下给出了一系列要求。出于安全的原因该方法相对保守, 例如 , 它被限制最高到SIL3并且规定一系列限制性要求。以下要求仅与数字集成电路有关。可使用单半导体衬底来实现带有硬件故障裕度大于零的子系统(片上冗余)。在这种情况下应履行所有以下要求 1) ~17), 并且E/E/PE 系统和集成电路的设计应满足这些要求。(参考 IEC61508-2, Annex E)
参考上表的要求，我们来看下车载领域的功能安全微控制芯片在架构层面一般都会部署哪些安全措施，看是否能覆盖上表的要求。
目前一些过了功能安全认证的微控制器芯片（如英飞凌的Aurix系列、NXP的MPC57XX/S32XX系列、TI的Hercules系列等）都采用了双核锁步架构设计，双核锁步作为处理器“安全岛”概念的一部分，是一种1oo1D架构模型，既可以用于探测处理器硬件的故障也可以用于探测在CPU上运行指令的故障。
双核锁步架构的简化示意可参考如下：
双核锁步架构的处理器一般具有如下特征：
目标：检测微控制器中的硬件故障；
两个核心都在同一个硅片（芯片）上实现，是一种片上冗余架构；
同一软件在两个核心上以同步模式运行；
在两个核的输出端配置有比较单元，在比较单元中对两个核的输出进行比较，如果检测到差异，则发出错误信号；
由于双核锁步架构属于片上冗余系统，为了减少相关失效的的影响，一般需要采取了以下措施：
- 物理多样性
- 物理核心硬件在空间上是分开的，至少距离100µm 远，形成物理上的“隔离带”，有的芯片称之为“Safety Lake”；
- 一个核相对于另一个核在物理上结构上进行翻转并旋转90°；
- 电源多样性
- 每个核心都有一个专用电源环；
- 时间多样性
- 一个核心相对于另一个运行延迟（例如2个时钟周期），一个输入延迟，一个输出延迟，以保证同步；
- CPU 时钟域被分成两个时钟树，这样时钟通过两个独立的路径被传递到两个 CPU。
基于以上设计特征，我们常见的双核锁步参考架构如下。
1.2 芯片的供电安全
供电模块作为一个典型的相关失效引发源（DFI），芯片在设计过程中出于安全考虑需要为内核逻辑电路和 I/O 逻辑电路提供独立的电源轨（包括模数转换器 (ADC)、闪存泵和振荡器），同时还会配备相应的电压监控模块用于对各自电源轨功能异常的监控。
1.2.1 嵌入式电压监控
安全芯片内部通常会设计嵌入式电压监控器，此监控器能够检测超出范围(OV/UV)的电源电压。当电源远远高于或者低于额定电压时，电压监控器将从内部驱动上电复位引脚，使处理器保持在安全运行状态。当电源处于范围之内，电压监控器将不会触发处理器复位。
由于供电模块在芯片内部属于通用基础设施，具有共用性。一般芯片中所有功能模块都需要有供电才能运行，不同模块需要的工作电压还不一样，怎么样控制不同模块件用电串扰的影响就是芯片设计过程中的安全考量之一。通常，为了消除/减轻其引发共因失效的影响，芯片设计上通常给冗余内核和I/O逻辑电路的供电是独立的。
提到相关失效，这里我们先介绍下该术语涉及的基本概念。
> 相关失效 dependent failures：不具有统计独立性的失效，即失效组合发生的概率不等于所有考虑的独立失效发生概率的乘积。
Jet Note: 简单理解，相关失效是指两个以上的独立事件发生失效的原因存在一定相关性/关联性，且导致该相关性的原因有多种。比如小王和老李在同一办公室办公，某一天小王出现了咳嗽、流鼻涕的感冒症状，隔天老李也出现了感冒症状，小王和老李都出现了感冒症状这事就存在一定的相关性。
由于导致失效存在相关性/关联性的方式不同，相关失效包括共因失效和级联失效。
> 共因失效（Common Cause Failures-CCF）：由于共同原因，两个或多个部件故障状态同时存在，或在短时间间隔内存在的相关失效子集。
共因失效是指冗余元件的独立通道上两个或多个元件的随机故障状态重合，导致定义的元件无法执行其预期安全功能，这是由单一事件或根本原因（偶然原因、不可分配原因、噪声、自然模式等）引起的。
Jet Note: 同样拿上面小王和老李的故事来举例。小王和老李在同一办公室办公，小王感冒后没多久老弟也出现了感冒症状，小王和老李都出现了感冒症状这事都要归因于流感病毒，所以是流感病毒导致小王和老李发生的”共因失效“。
> 共模失效（Common Mode Failure-CMF）：共因失效的一个子集。冗余通道中两个或多个（不一定相同）元件中随机故障的重合导致安全功能方面相同的重合错误行为。由于故障相同，比较器不会检测到故障。下图显示了两个不同但冗余的通道内的两个元件，其中一个根本原因导致两个不同的故障（fault1、fault2），从而导致两个元件和两个通道中的相同失效（failure a）。由于两个通道中都发生了相同的失效，功能安全比较器机制无法检测到失效。
Jet Note: 共模失效是一种特殊的共因失效，简单理解它是一种从结果上看以相同模式失效的共因失效。继续拿上面小王和老李的故事来举例。小王和老李在同一办公室办公，小王和老李都出现了感冒症状，受流感病毒的影响两人都出现了发烧、咳嗽及鼻塞流鼻涕的症状导致两人无法集中注意力办公于是中断当前工作都请假去了医院，这种情况下流感病毒导致小王和老李发生了”共模失效“。
> 级联失效（Cascading Failures-CF）：当系统中某个元件的局部故障波及互连元件，导致同一系统和同一通道内的另一个或多个元件发生故障时，就会发生级联失效。级联失效是非共因失效的相关失效。下图显示了一个通道内的两个元件，单一的根本原因导致一个元件中的故障（fault 1），从而导致某个失效（failure a）。然后，该失效级联到第二个元件，导致第二个故障（fault 2），进而导致另一个失效（failure b）。
Jet Note: 级联失效强调的是在同一系统/同一通道内的失效级联。接着上面小王和老李的故事来举例。小王和老李在同一办公室办公，老李出现了感冒症状，但小王未受到影响。受流感病毒的影响老李先是喉咙干痒导致咳嗽，接着出现严重鼻塞导致嗅觉失灵，还伴随间歇性的耳鸣导致听力下降，随着咳嗽不停病情加剧出现了呼吸道感染导致咽喉肿痛声带受损无法正常发声。这种情况下流感病毒导致老李身体中的耳、鼻、喉各功能模块发生了”级联失效“。
介绍完相关失效的相关概念，我们来看下芯片设计过程中对于供电模块可能导致的相关失效一般会采取什么措施。
如下有一处理器芯片的部分内部组件示意图，红框部分是芯片内部电压调节组件。
图中的EVR(Embedded Voltage Regulator)被识别为芯片内部的共享资源，由该调节器通过内部其他供电网络给芯片内部其他组件供电，示意图中还显示了该芯片内部有一个电压监控模块(EVR Monitor)用于对EVR的电压进行监控。
EVR（嵌入式稳压器）：除由“外部供电电源”供电的输入/输出焊盘外，EVR可以为处理器芯片内的每个硬件要素提供电源。
假设该芯片按照功能安全标准要求开发过程中有如下要求分配给了处理器。
MCU-REQ-2：导致 CPU 输出错误的随机硬件故障，应在 20 毫秒内被检测到[ASIL X]。
-MCU-REQ-2.1：“中央处理单元CPU应由冗余CPU监控。CPU和冗余CPU的输出通过硬件比较器在每个时钟周期都进行比较”；及
-MCU-REQ-2.2：“当CPU和冗余CPU的输出出现不匹配时，应生成错误事件”。
基于上方处理器内部组件模块对该安全要求[MCU-REQ-2]实施故障树分析如下。
根据上方的故障树分析识别出的共享资源和冗余要素，得到该处理器中关于供电模块的相关失效分析如下。
根据上方DFA分析结果，在原来芯片架构的基础上增加新的带隙监控元件，使与带隙漂移失效模式相关的相关失效被减轻。针对供电模块考虑了安全因素之后在架构上增加了相关安全模块，示例处理器芯片的内部架构更新如下。
以上示例只是为了说明芯片设计过程中对于安全属性的考量是如何实施的，从示例可以看出针对功能安全的芯片架构设计在哪些地方需要增加什么电路也是要经过一番安全分析来得到，从设计到实施再到验证也都需要遵照标准的流程来确保完整性、一致性和可追溯性。
1.3 芯片的时钟安全
芯片内部的时钟管理逻辑电路一般包括时钟源、时钟生成逻辑电路，此逻辑电路包括锁相环路 (PLL) 的时钟倍乘、时钟分配器、和时钟分配逻辑电路。
针对时钟管理电路的组成模块，以某一安全微控制器为例，芯片设计过程中一般会考虑以下检测电路用来应对时钟管理电路的各种可能的失效模式。
1.3.1 低功耗振荡器时钟检测器(LPOCLKDET)
低功耗振荡器时钟检测器 (LPOCLKDET) 是一个可被用于检测主时钟振荡器故障的安全诊断。
LPOCLKDET 采用嵌入式高频、低功耗振荡器 (HF LPO)。时钟检测电路工作方式为检验一个其它时钟上升沿之间的某一个时钟（振荡器或者 HF LPO）上的上升沿。结果就是除了标记不正确、频率重复，电路也会由于瞬态情况发生故障。
1.3.2 PLL差异检测
PLL 逻辑电路包括一个能够检测一个 PLL 输出时钟差异的嵌入式诊断。差异是由基准时钟和反馈时钟间的相位锁定损失造成。错误响应和指示取决于系统模块内的 PLL 控制寄存器的设计。
1.3.3 双时钟比较器(DCC)
一个或者多个双时钟比较器 (Dual Clock Comparator-DCC) 被使用为多用途安全诊断。DCC 可被用于检测不正确频率和时钟源之间的漂移。DCC 由两个计数器块组成：一个计数器块被用作一个基准时钟而另外一个被用作测试时钟。基准时钟和处于测试中的时钟均可由软件进行选择，可作为时钟频率的预计比率。与预计比率的偏差会生成一个错误信号。
处理器时钟电路也是一个典型的通用基础设施模块，其随机硬件失效导致的相关失效也是需要在芯片设计过程中给予考虑。
继续以上方处理器内部组件示例为例，先通过实施FTA识别出相关失效引发源(DFIs)，然后基于识别的DFIs开展相关失效分析。
根据上方的故障树分析识别出的时钟作为相关失效引发源，得到该处理器中关于时钟电路的相关失效分析如下。
根据上方DFA分析结果，在原来芯片架构的基础上增加新的振荡器元件，使与时钟漂移失效模式相关的相关失效被减轻。针对时钟模块考虑了安全因素之后在架构上增加了相关安全模块，示例处理器芯片的内部架构更新如下。
1.4 芯片的存储安全
数据在寻址、写、存储和读过程中的会经过芯片的数字电路组件和存储器，以下将从这两方面来谈一谈芯片设计过程中对于数据的存储有哪些安全考量。
1.4.1 非存储数字组件故障模型
芯片中的数字组件包括微控制器(uC)、片上系统（SoC）器件和专用集成电路（ASIC）等组件的数字电路部分，也包括现场可编程门阵列(FPGA)。
通常，芯片的非存储数字组件通常包括以下故障模型：（参考ISO 26262-11:2018, 5.1.2）
》永久性故障（permanent fault），也称为“硬错误/硬故障”，该故障类别的具体故障模型详细描述如下。
• 卡滞故障（stuck-at fault）：电路中的故障特征为不管输入激励如何变化，节点保持在逻辑高（1）或逻辑低（0）的状态；
• 开路故障（open-circuit fault）：通过将一个节点破坏为两个或多个节点，从而改变节点数量的电路故障；
• 桥接故障（bridging fault）：意外连接的两个信号。根据所采用的逻辑电路，可能导致“线或”或者“线与”的逻辑功能。通常仅限于设计中物理上相邻的信号；及
• 单粒子硬错误（Single Event Hard Error-SHE）：由单次辐射事件导致运行的不可逆变化，通常与器件中一个或多个要素的永久性损坏（如栅极氧化物破裂）有关。
》瞬态故障（transient fault），也称为“软错误/软故障”，该故障类别的具体故障模型详细描述如下。
• 单粒子瞬态脉冲（Single Event Transient-SET）：由于单个高能粒子穿过，造成集成电路某节点瞬时电压漂移（例如，电压尖峰）；
• 单粒子翻转（Single Event Upset-SEU）：由高能粒子穿过引发的信号所造成的软错误；
• 单比特位翻转（Single Bit Upset-SBU）：单粒子造成的单个存储单元翻转；
• 多单元翻转（Multiple Cell Upset-MCU）：单粒子引起集成电路中的多个比特位同时失效。错误位通常（但不总是）在物理上相邻；及
• 多比特位翻转（Multiple Bit Upset-MBU）：两个或多个由单粒子引起的同一个半字节、字节或字中的比特位错误。多比特位翻转不能通过简单的纠错码（ECC）进行校正（例如，单比特位错误校正）。
Jet Note: 单粒子瞬态脉冲（SET）、单粒子翻转（SEU）、单比特位翻转（SBU）、多单元翻转（MCU）和多比特位翻转（MBU）通常表示为“软错误”，之所以被称为软错误, 是因为电路本身并未受到辐射的永久损坏。
1.4.2 存储器故障模型
存储器故障模型可能因存储架构和存储技术而有所差异。半导体存储器的典型故障模型如下表所示。
该表并不完备，也可以根据其他已知故障或结合实际应用进行调整。
芯片内部或外部的存储模块都对高能粒子比较敏感，由上图可知Flash和RAM具有软错误故障模型，这是由其存储架构和技术所决定。
当辐射事件引起足够的电荷干扰扭转或翻转低能量的半导体存储单元、 寄存器、 锁存器或触发器的数据状态时, 软错误就会发生。
软错误可能和各类可变内存相关, 比如动态内 存( DRAM )、静态内 存( SRAM )、 微控制器中的寄存器组、 缓存( cache )、流水线( pipelines )、设备(如 ADC 、 DMA 、 MMU )配置寄存器、中断控制器、复杂定时器等。对alpha粒子和中子(Neutron)的敏感度由核心电压和物理结构决定。
标准给出了关于存储器故障的安全机制/措施的描述及其可实现的典型诊断覆盖率，参考如下。
ECC在现在的安全微控制器芯片中都会部署相关电路用于检测并纠正存储器中的位错误。
内存保护单元(MPU)也是现在的安全微控制器芯片中部署的专门用于实施内存分区、隔离的安全电路模块，防止不同数据存储区域未授权的访问。
由于软错误是在存储器身上非常具有代表性的故障，其他关于芯片设计过程中考虑的存储器包括软错误在内的故障防护的技术我们将在单独的文章中进行介绍。
1.5 芯片温度监控
最小系统中时钟、电源、存储器都是典型的共因失效引发源，除了这些芯片内部组件故障引发的相关失效需要在设计过程中给予考虑外，对于电气串扰和环境应力可能引发的相关失效在芯片设计过程中也需要加以考虑。
芯片内的或外部对芯片的电气串扰在芯片设计过程中会同步进行考虑，如采用低抖动的时钟源，减小时钟网络的干扰。在芯片内部采用金属屏蔽层或导电衬底来隔离敏感区域或噪声源，从而减小电磁干扰的影响等。
另外对于数据存取的免于干扰芯片设计过程中会考虑空间和时间上的隔离措施，比如上面提到的MPU就是使用了内存空间物理隔离或基于时间的存取隔离技术。
这里我们要谈一谈芯片设计过程中对于温度的考虑。
像动物一样在一个舒适的温度环境下动物生长的最快生态体征也最好，应用半导体技术的芯片在合适的温度下其功能和性能也表现为最佳。通常，高温会导致芯片发生不可逆的损坏，而低温导致的芯片功能异常往往是可恢复的。异常的温度(通常是高温)不仅会导致芯片工作异常，还会加速芯片的老化影响芯片的寿命，同时加大了系统功耗，使整个系统的可靠性降低。
所以芯片设计过程中往往会对温度的影响给予考虑。对于功能安全来说，温度这种环境应力是典型的相关失效引发源，所以实施安全设计的芯片基本都会在内部部署温度传感器来监控芯片的内部温度。典型地，双核锁步架构的微控制器中一般每个核都会部署一个专有的温度传感器用于监控核温，当检测到温度超出预设的范围值(如，-40℃~150℃)时输出一个温度状态信号，芯片自身进入fail-safe状态并输出一个故障信号给到上层系统。
在芯片内部部署温度传感器对核温进行监控属于探测措施，实际芯片设计过程中除了探测类的安全措施外，预防措施也会同步进行考虑，比如芯片的散热设计。
芯片内部的散热设计不仅可以降低功耗提升芯片性能，也有助于保证芯片的安全完整性要求。下方举了些常见的芯片散热技术，供参考。
> 增加散热层：在芯片封装中增加散热层，将芯片产生的热量传递到封装表面，再通过散热器将热量散发出去。散热层可以采用金属、陶瓷等导热材料。
> 热管技术：热管是一种高效的传热元件，可以在较小的空间内传递大量的热量。在芯片内部，可以将热管与芯片的散热区域连接，将热量快速传递到热管的另一端，再通过散热器散发出去。
> 热设计优化：通过优化芯片的热设计，减少热阻和散热路径，提高散热效率。例如，合理布局芯片内部的发热元件、优化芯片的散热通道、加强封装材料的导热性能等。
功能安全的微控制器架构内部还有很多其他硬件的安全措施，想要了解更多各位可以结合芯片安全手册去学习，然后映射到标准的相关要求中去，这可能是最便捷的芯片功能安全设计的方式。
二、芯片的软件安全设计
上文中提到的芯片硬件安全设计介绍了一些芯片在进行架构设计过程中对于安全方面会考虑的一些硬件安全措施，但芯片都是基于SEooC的方式进行开发和设计，所以一款能过功能安全认证的微控制器芯片需要对于其应用的上下文环境作一些假设，而这些假设往往是对系统层面的安全考量。
所以，在芯片内部部署了相关的硬件安全技术设施还不够，这些基础设施是要给软件用的，软件对于这些基础设施相关的寄存器进行合理的配置和应用才能正确地实现一个完整的安全相关的功能。
这里我们就挑几个芯片用于功能安全的设计过程中软件对于芯片实施的一些安全设计。
其实上一篇文章提到的芯片内部的电源、时钟、存储器、温度传感器这些都有对应的寄存器需要软件去进行设置，软件需要将故障报出去，由芯片内部的故障收集器收集后根据系统层面的策略来作出对应的故障响应。
2.1 温度检测
先拿上一篇文章提到的温度传感器举例。在芯片里面部署了两个温度传感器用于检测芯片的工作结温，软件的工作是根据传感器采集到的温度来判断当前芯片结温是否超过预设范围(e.g. -40~150℃)，并将计算得到的状态写入对应寄存器以表征芯片的温度状态，应用层软件根据该信号状态作出处理策略，比如进入复位状态、发出加大风扇转速指令进入强制冷却模式等。
另外，温度传感器作为芯片用于应对共因失效的一种安全机制，其本身的失效在设计过程中需要进行考虑，即需要考虑防止温度传感器成为潜伏故障的机制。这可以在硬件上实现，如果是在芯片内部实现无非就是进一步增加硬件，这会增加芯片设计成本还会动到现有的芯片架构，似乎不怎么合适。如果通过软件来实现呢？
对于潜伏故障，常用的措施便是在上电/下电过程中对安全相关的硬件组件进行检测，检测相关硬件是否具备行使正常功能的能力，这个措施对于作为安全机制的温度传感器当然也是适用的，这不仅不会增加什么软件开销也不会影响软件后续的正常运行。
可供参考的实施方式：系统上电过程中，软件读取两个温度传感器的信号，判断两个信号的值是否在量程范围且两个值的差是否在一定误差范围，任务一个不满足都任务当前传感器不可信。
Q: 对于温度传感器转换后的信号表征状态的判读软件在设计过程中会考虑什么来提高判断的准确性？
2.2 软件看门狗
不得不说“看门狗”一词用在技术上具有一定艺术性，所谓“艺术源于生活也高于生活”, 现实生活中狗狗也像人一样需要按时来个一日几餐，如果由于主人某种原因(如睡着了)超过时间没给它喂食，狗狗可能就会来咬裤脚或叫起来给主人一些“提示”，提醒主人该喂食了。嵌入式电子技术里的“看门狗”机制的灵感可能就源于类似生活中的示例。
“看门狗”全称是看门狗定时器(Watchdog Timer—WDT), 是一个定时器电路。一般有一个输入(WDI)，叫喂狗信号，一个输出(RST)，连到微控制器(uC)的复位脚, uC正常工作的时候, 每隔一段时间输出一个喂狗信号给WDT清零, 如果超过规定时间不喂狗, WDT就会给出一个复位信号到微控制器, 试图让系统重新恢复正常。
随着看门狗技术的发展，按照种类分可以分为硬件看门狗和软件看门狗；按相对于微控制器物理位置可将硬件看门狗分为内部看门狗和外部看门狗。
不管什么类型的看门狗，基本原理都是一样的，只是方式上的差异。软件看门狗包括一个喂狗(kicking the dog or service the dog)进程。喂狗进程按一定的周期执行喂狗操作，该周期小于等于定时器的周期。
具体地，当系统正常工作的时候，周期性地输出一个信号到喂狗端(WDI)，给定时器清零。如果超过规定的时间不喂狗，定时器超时，就会输出一个复位信号(RST)到微控制器，使系统复位，以防止系统死机。
功能安全的软件设计要求实施程序流分析(控制流+数据流)，用于验证软件架构设计/程序序列是否符合要求，这时对软件实施程序流分析就需要有专门的硬件支持。
芯片内部部署有专门的定时器以及对应的寄存器用于实现软件看门狗机制，用于功能安全的相关项设计时，该软件看门狗可用于对软件实施程序流分析，检查软件程序的运行行为是否符合既定的流程。
另外，功能安全对于各软件组件运行在同一个微控制器上有免于干扰(Freedom from Interference_FFI)的要求，所以如何实现免于干扰的软件设计要求既是芯片厂家要考虑的也是系统应用方要考虑的。
芯片内部部署的看门狗需要软件配置对应的寄存器起来才能起作用。当程序中的各个单元以错误的顺序或过长的时间段运行时，使用软件看门狗可用于检测有缺陷的程序序列。一旦软件看门狗被启用，它就需要定期和及时地执行看门狗服务程序。在服务超时到期之前，必须在配置的时间窗口内执行服务过程。
可供参考的实施方式：假设用两个定时器T0, T1来对主程序的运行进行监控。
对T0设定一定的定时时间，当产生定时中断的时候对一个变量进行赋值，而这个变量在主程序运行的开始已经有了一个初值，在这里我们要设定的定时值要小于主程序的运行时间，这样在主程序的尾部对变量的值进行判断，如果值发生了预期的变化，就说明T0中断正常，如果没有发生变化则使程序复位。
对于T1我们用来监控主程序的运行，我们给T1设定一定的定时时间，在主程序中对其进行复位，如果不能在一定的时间里对其进行复位，T1 的定时中断就会使单片机复位。在这里T1的定时时间要设得大于主程序的运行时间，给主程序留有一定的的裕量。
而T1的中断正常与否我们再由T0定时中断子程序来监视。这样就构成了一个循环，T0监视T1，T1监视主程序，主程序又来监视T0，从而保证系统的稳定运行。
2.3 ADC故障检测
ADC在芯片内部来说也属于共享资源（shared resource）的范畴，这意味着ADC的故障会引发相关失效，芯片的功能安全设计过程中当然需要考虑该失效导致的风险。
在上一篇文章功能安全的架构设计（七）芯片篇-上 (qq.com))中提到的BIST模块可用于ADC的自测，以验证ADC硬件行使功能的完整性。除了BIST，应用软件还可以使用ADC预采样(presampling)功能来实现对ADC故障的检测。
软件可以通过配置ADC相关寄存器来使能对里面每一通道转换电路的预采样。预采样允许在ADC内部电容器开始从芯片I/O管脚接收的模拟输入的采样和转换相位之前对其进行预充电或放电。
在预采样阶段，ADC对内部产生的电压进行采样。在采样阶段，ADC对来自I/O管脚的模拟输入进行采样。在转换阶段，最后一个采样值被转换为数字值。下图显示了两个通道的“预采样-采样-转换“操作顺序。
图中VADC_VDD_ref 或 VADC_GND_ref 假设是两个可用于预采样的参考电压。
如果ADC中模拟多路复用电路中存在开路故障，则ADC转换的信号不是来自I/O管脚的模拟输入，而是预采样参考电压（VADC_VDD_ref 或 VADC_GND_ref）。下图描述了模拟多路复用电路中用于预采样阶段和转换阶段的信号路径。
除了开路故障的检测，预采样功能还可以用于ADC内部短路故障的检测。
为了检测短路故障，ADC通过获取两个不同的电压，比较两电压预预期值的一致性。如果这些值与预期值不同，则认为ADC中多路复用电路上存在短路故障。
为了实现该检测方式，可以对ADC的预采样功能的操作顺序进行配置。软件通过配置相关寄存器将ADC预采样配置为通道的采样被旁路(通过I/O关键的输入采样被旁路)并且预采样参考电源电压被转换，如下。
2.4 安全通信
芯片内部部署了各种通信模块，如CAN, ETH, LIN, SPI, I2C等，用于同外部进行数据收发。如何保证各类总线的通信安全除了芯片设计本身要考虑基本的防护措施，更多的是要在软件应用层面/系统层面来保证安全通信。
先看下标准对于通信总线类要考虑哪些失效模式，如下。
像CAN, ETH, LIN, SPI, I2C等总线除了其协议规范中包含的机制之外，没有其他特殊的功能安全机制，光靠自身协议本身难以应对上图提到的失效模式。因此，需要在系统层面考虑在通信模块接口上提供功能安全机制，以满足功能安全要求。
通过在软件应用层扩充用于安全通信的总线的协议，使之具备一定的通信故障容忍和检测能力，形成额外的一层通信故障容错协议，实现这个目的方式就是我们常说的E2E保护机制。
应用软件、中间件软件或操作系统需要在相关通信IP模块的接口上提供以下功能安全机制，以满足功能安全要求。
• 端到端CRC，用于检测数据损坏；
• 序列编号，用于检测消息重复、删除、插入和错误排序；
• 用于检测消息延迟的确认机制或超时检测；
• 用于检测伪装的发送者身份标识；
关于E2E保护可以参考AUTOSAR中关于E2E库的软件需求规范，里面关于数据通信的各种失效模式都有描述并且有相关需求进行覆盖，能满足功能安全对于通信安全完整性的要求。
以上关于芯片功能安全软件设计就谈到这里，当然软件基于芯片的硬件安全设施要做的事远不止这些，比如还有寄存器的保护、中断控制、堆栈溢出检测、系统故障管理等等，都是软件要结合硬件实施的安全设计，水平有限，只能泛泛而谈啊！
三. 芯片信息安全设计
随着汽车的智能化、网联化程度越来越高，各种车用控制器的功能越来越丰富和复杂，其中当属自动驾驶对于车载电子控制单元(ECU)功能的复杂度和集成度要求最高。自动驾驶可谓是汽车技术的“集大成者”，涉及整车及电子电气控制技术的方方面面，也正因为自动驾驶催生了功能安全之外的对于汽车的其他安全相关要求，比如预期功能安全(SOTIF)、网络安全(CS)，并且陆续发布了相关标准。
为此，自动驾驶功能相关的电子电气系统不仅要满足汽车功能安全标准(ISO26262)的要求，还要满足预期功能安全标准(ISO 21448)的要求和网络安全(ISO/SAE 21434)的要求，实现整车电子电气系统的安全，我习惯称之为”大安全“。
接下来我们来谈一谈安全的微控制器芯片为满足汽车发展的趋势考虑了哪些信息安全的技术。
3.1 硬件安全模块(HSM)
由于自动驾驶对于整车各节点数据处理的能力有非常高的要求，比如数据吞吐量、传输及时性等，传统的以CAN总线为主的单一通信网络已不能满足自动驾驶汽车数据处理的要求，整车的通信网络为适应技术的发展也随之发生了一些变化，比如车载以太网的加入，不仅用于车内大容量数据的传输还用于远程数据的传输，这是实现车联网的非常重要的车内基础设施。
随着汽车电子电气架构越来越复杂，车与外部设备、云端设备交互场景也越来越多，车也变成了一个“自主移动的终端系统”，这个时候整车的信息安全也就变成了一个绕不开的话题。
信息安全的核心是密码学，密码学是一门对信息进行加解密的学科，里面涉及多种加密算法，比如AES, DES, SHA, RSA等，通过应用加密算法实现对信息的加解密从而保证信息的安全性（保密性）。
网络安全是系统信息安全的一部分，一般会根据系统架构及其通信网络来构建分层的网络安全架构，根据不同的网络层次来构建出系统的网络安全纵深防御体系。汽车电子电气架构中不同控制单元的功能由内到外基于整车通信网络也可以分为不同层次，从而构建整车电子电气网络的纵深防御体系。如下汽车电子网络安全的参考架构。
从上图可知，ECU处于汽车网络安全纵深防御的最底层，意味着ECU的设计得满足信息安全的要求，也就得保证ECU在网络上进行数据收发的安全，而其中的关键便是加密算法。迫于整车系统信息安全的要求，在IT领域常用的AES、SHA、RSA等加密算法被越来越多地应用到汽车上。但通常这类加解密算法都需要大量的数学运算，需要消耗很多CPU时间和资源，汽车上的ECU又有比较高的实时性要求，为了节省主CPU的资源，芯片厂家为了能在一颗微控制器芯片上提供ECU通信数据加解密的功能，于是在芯片内部专门开辟了一个能满足ECU信息安全开发要求的模块——HSM。
HSM是Hardware Security Module的缩写，硬件安全/安保模块，是微控制器上专门用于实现加解密算法的一个独立模块，你可以理解为它是一个“信息安全岛”（Security Island）。HSM一般会有一个独立的CPU，专门用来进行加解密运算，还有一些针对特定算法（如AES-128、SHA-256等）的硬件加速器(crypto engine)，它相当于给ECU提供了一个可信计算平台。
有了HSM模块，程序中就可以把加解密运算交给HSM来执行，主处理器就可以去做其他工作，一段时间后来查询结果，或等待HSM计算完成后通过中断等方式通知主处理器计算结果即可。
而且HSM通常还拥有单独的存储区，包括RAM和NVM，HSM的存储区在正常运行状态下应只允许HSM核读写，主功能核不能读写。这样就可以把算法秘钥等重要数据存储在HSM存储区，与主核进行隔离，进一步加强安全性。
根据EVITA（E-safety vehicle intrusion protected applications）项目给出的HSM基本结构，将HSM分为安全存储、硬件密码加速和应用核心三部分组成，如下。
根据HSM在汽车电子不同网络层次的应用，EVITA进一步把HSM分为三个等级/类别：
1）EVITA full HSM。对应结构如下：
2）EVITA medium HSM。对应结构如下：
与full HSM相比，medium HSM没有包括ECC-256和WHIRLPOOL 密码模块（NIST提出的基于AES 的hash函数），并且，medium HSM所包含的CPU性能要低一些。因此，medium HSM没有基于硬件加速的非对称密码和哈希算法。
3）EVITA light HSM（或是EVITA small HSM）。对应结构如下：
其中，EVI-TA full HSM主要用于V2X的通信单元，以及中央网关；EVITA medium HSM用于ECU之间通信场景的ECU；EVITA light HSM则用于传感器、执行器。
light HSM只包含基于AES-128的对称加解密模块，以满足传感器和执行器在成本和效率方面的严格需求（消息大小、时间、协议限制、处理器能力等）。基于light HSM，使得传感器和执行器能够保证通信数据的真实性、完整性和机密性。另外，同full和medium HSM相比，light HSM没有提供独立的处理和存储单元，应用处理器和应用软件可以完整访问所有的密码数据。
为此，可以考虑对light HSM进行安全增强，提供内部的非易失性存储器和RAM，以及基于AES的伪随机数生成器。这样，light HSM可以更加安全地生成、处理和存储密钥。
目前看到的带HSM的功能安全微控制器芯片的结构大部分是EVITA medium/high HSM类型的，如下Infineon AURIX TC39x系列微控制器集成的HSM结构。
TC39X系列的HSM具备以下特征：
- 满足Full EVITA HSM结构要求；
- 包含ARM Cotex-M3的处理器，AES加速引擎， PKC模块和Hash模块；
- AES加速引擎支持：AES128算法（对称加密算法），PKC支持ECC256（非对称加密算法），SHA256，和真随机数产生器。
3.2 安全硬件扩展(SHE)
除了HSM模块，一些微控制器芯片内部还部署有安全硬件扩展(SHE)固件，用于扩展微控制器的硬件安全策略。SHE的基本结构如下：
SHE可以提供以下功能：
- 对称数据加密/解密；
- MAC生成/验证；
- 安全MAC验证；
- 随机数管理；
- 安全引导；
- 用于开发的调试访问；
- 非对称加密/解密（可选）；
3.3 示例—安全板载通信（SecOC）
接下来以AUTOSAR中的安全板载通信(Secure On-board Communication-SecureOC)功能为例来看下芯片中集成的HSM在车载领域的实际应用。
安全板载通信（SecOC）模块的目的保证通过汽车通信网络交换信息的两个或多个ECU之间传输安全数据。
基于非对称密码算法和消息摘要算法的“数字签名”技术可以用于实现高安全等级的板间通信，数字签名的实现方式参考如下。
由于板间通信对实时性有一定要求，基于效率和成本方面的考虑，ECU之间通信的保护采用对称密码算法具备合理性。
因此，ECU在进行板间通信时，一般使用HSM中“AES128+CMAC”算法来对通信数据进行加密来保证消息来源的真实性和完整性，这是一种“对称加密+消息认证码”的算法，实施步骤参考如下：
1）在发送端，通过消息摘要算法对数据ID和PDU计算得到对应的消息摘要(MAC)，然后用加密算法(AES128)和私钥(PriKey)对MAC进行加密得到密文S，将密文S和数据一起发出。
2）在接收端，先用私钥(PriKey)将签名后的数据进行解密得到MAC，再用同样的摘要算法对签名后的数据计算得到新的消息摘要MAC ，将新摘要MAC 和接收到的摘要MAC比较。
3）结果确认，如果比较结果一样，数据就是合法且完整的，真实的；否则，数据是不可信的不予采用。
关于芯片架构设计过程中考虑的信息安全措施就和大家谈到这里，除了软硬结合的固件加密技术，当然还有其他措施来保证信息安全，如单次可编程(OTP)、遵守信息安全的流程、防物理攻击的措施等，另外在应用层面可以将功能安全中提到的MPU(内存保护单元)和加密技术相结合从各个环节来保证信任链的完整性，所有这些都是为了建立一个可信的安全系统而服务。
到这里，关于芯片的功能安全架构设计话题就要和大家告一段落了。功能安全是流程和技术的结合体，芯片设计过程中既要遵循该领域特定的流程，出于安全合规的考虑相关标准(如ISO26262,ISO21448,ISO/SAE 21434)的一些开发流程和技术要求也要一并考虑，由于芯片通常都是基于SEooC的方式进行，所以芯片的安全设计往往要系统性的考虑功能安全、预期功能安全和信息安全的要求以满足下游相关项系统对于这些安全领域(safety section)的要求。
参考：
[1] ISO 26262-5:2018 Product development at the hardware level
[2] ISO 26262-6:2018, Product development at the software level
[3] ISO 26262-9:2018, Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses
[4] ISO 26262-11:2018 Guidelines on application of ISO 26262 to semiconductors
[5] IEC61508-2:2010 Requirements for electrical/electronic/programmable electronic safety-related systems
[6] IEC61508-7:2010 Overview of techniques and measures
[7] MPC5746RRMAD Rev. 3, 06/2017
[8] Specification of SWC End to End Communication Protection Library AUTOSAR Release 4.2.1
[9] 汽车电子网络安全标准化白皮书
[10] AURIX™ Security Solutions
[11] 2nd Generation AURIX™ TC3xx Hardware Security Module, HSM Version 2.0
[12] 针对TMS570LS04x 和 03x的安全手册 Hercules™ARM® 安全微控制器的安全手册用户指南
[13] 信息安全工程师教程
作者：WF.WANG
文章来源：功能安全落地漫谈
推荐阅读
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
