1      OVERVIEW

The Flagship FC7300 series is a high performance automotive grade hyper-converged processor (HPU) based on the multi-core Arm® Cortex-M7, which meets the requirements of ISO 26262 ASIL-D, the highest level of functional safety. To achieve this stringent safety goal, the FC7300 chips integrate several key safety mechanisms inside the chip, of which EIM (Error Injection Module) and ERM (Error Reporting Module) play a crucial role.

l EIM：The main purpose is to perform power-up and periodic self-test of ECC function by simulating ECC fault injection.

l ERM: It is mainly used to respond to ECC faults and trigger interrupts for troubleshooting to prevent the faults from causing the system functions to fail.

Working closely together, these two modules are the core hardware foundation for the FC7300 to achieve ASIL-D certification and ensure the reliable operation of safety-critical applications such as automotive power, chassis, and domain control.

2      Introduction to the ECC mechanism

There are two failure modes for memory

1. Illegal access, which is usually protected by memory management using MPUs.

2. Memory corruption, which is usually diagnosed by ECC, the mechanism of which can be implemented by software or hardware.

ECC is a common mechanism used by chips to secure information, mainly to avoid situations where data stored in storage devices is tampered with due to hardware interference.

2.1  ECC Basic Concepts

ECC full name Error Checking and Correcting, belongs to an error checking and correcting algorithm. In digital circuits, the smallest unit of data is called “bit (bit)”, also called data ‘bit’, “bit” is also the smallest unit of memory, which is signaled by the “1” and “0” indicate the data high and low level signals. Wireless electromagnetic interference and circuit noise in the space can cause bit flipping (“0” to “1”, ‘1’ to “0”) when the memory interacts with the CPU. "Typical ECC algorithms can correct single-bit errors and check for 2-bit errors.

2.2  Composition of ECC Data

The number of bit bits required for ECC is determined by the number of bits in the data segment. 8-bit data requires 5 ECC bits for checksum, and for every doubling of the data bits, ECC increases by only one checksum bit. For example, the number of ECC parity bits for 32-bit data is 7 bits.

2.3  Latent Failure Problems from ECC

Latent faults are a common problem faced by ECC mechanisms, where corruption of read data may not be detected for a number of reasons when checking for redundant parity bits. When the hardware is unable to solve the problem brought about by itself, software is required to assist in covering the corresponding faults.

Taking the FC7300 chip as an example, the chip provides the EIM peripheral, which is specialized in providing the function of flipping the data bits through the bus, it inserts the error injection channel of the module in the read path between the memory and the EDC/ECC function to achieve the means of injecting ECC faults. The software can actively inject ECC faults at power-up and then check that the ECC monitoring mechanism is functioning correctly, thus reducing the latent fault rate.

3      EIM与ERM模块的应用Application of EIM and ERM modules

3.1  Startup Detection

Verification for the ECC monitoring function is usually performed during the power-up process, using the EIM module to inject ECC faults into specific areas (e.g., SRAM, FLASH, TCM, etc.), then actively reading the fault address to trigger an ECC fault, and finally observing whether or not the fault can be responded to by the ERM module (e.g., whether or not an interrupt is triggered, whether or not the fault address is logged, etc.).

3.2  Runtime Moniting

After the power-on self-test has passed, the ECC monitoring function of the ERM is usually considered to be operational, and the corresponding monitoring function of the ERM will then be turned on, and interrupt response will be turned on for ECC troubleshooting (e.g., active attempts to clear faults, record DTC information, trigger reset, and other actions).

3.3  Shutdown Detection

The process of power-down detection is similar to power-up detection, but it should be noted that since the ECU will go into hibernation or directly power down after the power-down detection is completed, the detection results will not be saved through the RAM area. Therefore, the additional step after the power-down test is to retain the test results in the form of FLASH storage, read the result information at the next power-up, and confirm whether the fault area still exists.

3.4  Precautions

During the self-test process, an ECC fault is injected into the target area, which causes anomalies in the data in this area. The impact scenarios are as follows:

lIf the data shared by multiple cores is in the fault injection target area, core 1 will trigger an exception due to reading this shared data while core 0 is doing self-test. Since core 1 is not doing self-test but executing the program normally, core 1 will think that there is an ECC fault on the current chip and hang.

lIf the stack data is stored in the target area of the fault injection, a function call after the fault is injected will result in an exception triggered by reading or writing to the stack, and due to the faulty stack data, this will also result in an exception transfer error, which will result in the program running away.

lIf the interrupt vector table is stored in the fault injection target area, if an interrupt (e.g., timing interrupt, CAN interrupt, etc.) is triggered after the fault is injected, an exception in the vector table data will result in an abnormal final interrupt jump, and the program will fly.

Therefore, when using EIM for fault injection testing, care should be taken to consider all aspects of fault injection. For example, the variables shared by multiple cores should be prevented from being affected by the ECC fault injection; if the stack is placed in the TCM area, the stack switching work should be added when performing TCM related tests; when doing the FLASH self-test, in order to avoid code data anomalies, the code should be considered to be placed in the RAM for execution.

4      Introduction to ZC MuNiu

Based on the latest ARTOP architecture and the basic platform provided by the latest AUTOSAR R21-11 standard, the MNU Configuration Tool realizes the whole process of ECU configuration from configuration, validation to code generation according to the ECU configuration steps defined in the AUTOSAR development methodology. The main advantages can be summarized in the following aspects: the realization of the whole process of configuration, verification and code generation has completely realized the development requirements of the ECU configuration stage in the AUTOSAR development method.

The EimErmTst module is implemented in the ZC MuNiu SafetyLibrary software, which utilizes the Eim and Erm peripherals to achieve the power-on self-test function. The following will briefly describe the process of configuring the EimErmTst module using ZC MuNiu:

4.1  Introduction to EimErmTst Configuration

4.1.1        Adding Test Set

Test collections can be added for specific CPU cores through the TestCore interface.

4.1.2        Configuring the EIM Test Channel

Multiple EIM test channels can be added under the corresponding Channel configuration page.

4.1.3        Configuration of Additional Security Mechanism Detection Functions

ZC MuNiu SafetyLibrary software is highly scalable. In response to the needs of customers for additional safety mechanisms, ZC can create targeted testing functions and provide the corresponding configuration items. In the ECCTestSets page, select the tests that need to be performed.

4.1.4        Generating Configuration Code

The EimErmTst related configuration code can be generated after all the functions are configured.

           4.2     Areas of application

The ZC MuNiu configuration tool provides a user-friendly HMI for ECU controller software development. It supports the configuration of standard AUTOSAR basic software code modules as well as the development of configuration interfaces for complex drivers. Currently, it is mainly used in the following scenarios:

Ø  ZC MuNiu Basic Software Platform Standard AUTOSAR Module Configuration

Ø  ZC MuNiu Basic Software Platform Complex Driver Module Configuration

u  SAFETY FRAME

u  CRYPTO LIBRARY

u  BCCIC

u  SBC

Ø  Collaboration with chip companies to provide configuration tools for MCU MCALs

1      概述

旗芯微FC7300系列是基于多核Arm® Cortex-M7的高性能车规级超融合处理器（HPU），满足ISO 26262 ASIL-D最高功能安全等级要求。为实现这一严苛的安全目标，FC7300芯片内部集成了多项关键安全机制，其中EIM（错误注入模块）和ERM（错误报告模块）扮演着至关重要的角色。

l  EIM：主要以通过模拟ECC故障注入，进行上电、周期性的ECC功能自检。

l  ERM：主要用于响应ECC故障，并触发中断进行故障处理，防止故障导致系统功能失效。

这两个模块紧密协作，是FC7300达到ASIL-D认证、确保汽车动力、底盘、域控制等安全关键应用可靠运行的核心硬件基础

2      ECC机制介绍

对于内存有两种失效模式

1. 非法访问，通常使用MPU进行内存管理进行保护

2. 内存损坏，一般通过ECC来进行诊断，ECC的机制可由软件或硬件实现

ECC是芯片用于保障信息安全的一种常用机制，主要是为了避免存储设备中存放的数据因为硬件干扰而被篡改的情况。

2.1  ECC基本概念

ECC全称 Error Checking and Correcting，属于一种错误检查和纠正算法。在数字电路中，最小的数据单位就是叫 “比特（bit）”，也叫数据 “位”，“比特” 也是内存中的最小单位，它是通过 “1” 和 “0” 表示数据高、低电平信号的。空间中的无线电磁干扰、电路噪声会导致内存与 CPU 在进行数据交互的时候发生比特翻转  (“0” 变为 “1”,“1” 变为 “0”)， 典型的ECC算法一般可以做到纠正单比特错误和检查2比特错误 。

2.2  ECC数据的构成

ECC需要的bit位数量由数据段的比特数决定，8位的数据需要5位的ECC位进行校验，数据位每增加一倍，ECC只增加一位校验位。例如，32位数据的ECC校验位数量位7位。

2.3  ECC带来的潜伏故障问题

潜伏故障是ECC机制面临的一个常见问题，在检查冗余校验位时可能会由于一些原因导致无法检测到读取数据的损坏。当硬件无法解决自身带来问题时，就需要软件协助覆盖相应的故障。

以FC7300芯片为例，该芯片提供了EIM外设，专门提供了通过总线翻转数据比特位的功能，它在存储器和 EDC/ECC 功能之间的读取路径中插入了该模块的错误注入通道来达到注入ECC故障的手段。软件可以在上电时主动注入ECC故障，然后检查ECC监控机制的功能是否正常，从而降低潜伏故障率。

3      EIM与ERM模块的应用

3.1  上电检测

针对ECC监控功能的验证通常在上电过程中进行检测，使用EIM模块对特定区域（例如SRAM、FLASH、TCM等）进行ECC故障注入，然后主动读取故障地址触发ECC故障，最后再观察故障是否能被ERM模块响应（如中断是否触发，故障地址是否被记录等）。

3.2  周期监控

当上电自检通过之后，通常认为ERM的ECC监控功能是可以正常运行的，随后会开启ERM对应的监控功能，并开启中断响应用于ECC的故障处理（例如主动尝试清除故障、记录DTC信息，引发复位等动作）。

3.3  下电检测

下电检测的过程与上电检测类似，但需要注意的是，由于下电检测完毕后ECU会进入休眠或直接掉电，检测结果将无法通过RAM区进行保存。所以下电检测完毕后额外的步骤是通过FLASH存储的形式将检测结果保留，在下次上电时读取结果信息，并确认故障区域的故障是否仍然存在。

3.4  注意事项

在自检过程中会往目标区域注入ECC故障，这个会导致这块区域的数据都产生异常。影响场景如下：

l  若多核共享的数据处于故障注入目标区域，则在核0做自检的时候，核1会由于读取了这个共享数据而触发异常。由于核1没有做自检而是在正常执行程序，因此核1会认为当前芯片存在了ECC故障，从而挂起。

l  若堆栈数据存放在了故障注入目标区域，则在注入故障后进行一次函数的调用会导致读写堆栈触发异常，并且由于堆栈数据故障，这还会导致异常调转错误，从而程序跑飞。

l  若中断向量表存放在了故障注入目标区域，则在注入故障后，若触发了中断（例如定时中断、CAN中断等），由于向量表数据异常则会导致最终中断跳转异常，从而程序跑飞。

因此在使用EIM进行故障注入测试的时候，应当小心谨慎，需要考虑的故障注入涉及到的各个方面。例如将避免将多核共享的变量防止在ECC故障注入影响的范围内；如果堆栈放置在TCM区域的话，那么在执行TCM相关测试时加入堆栈的切换工作；在做FLASH自检的时候，为了避免代码数据异常，应当考虑将代码放置在RAM中执行。

4      知从木牛介绍

知从木牛配置工具基于最新ARTOP架构，支持最新AUTOSAR R21-11标准所提供的基础平台上，根据AUTOSAR开发方法中定义的ECU配置步骤，实现了从配置、验证到代码生成的ECU配置全流程的功能。主要优势可以总结为以下几个方面：配置、验证和代码生成全流程功能的实现，完整的实现了AUTOSAR开发方法中ECU配置阶段的开发要求。

在ZC MuNiu SafetyLibrary软件中实现了EimErmTst模块，该模块运用Eim和Erm外设实现了上电自检功能，下面将简单介绍一下使用ZC MuNiu进行EimErmTst模块配置的过程：

4.1  EimErmTst配置简介

4.1.1        添加测试集合

通过在TestCore界面可以为指定的CPU核添加测试集合。

4.1.2        配置EIM测试通道

在对应的Channel配置页面下可以添加多个EIM测试通道。

4.1.3        额外安全机制检测功能配置

知从木牛功能安全具有高度的可扩展性，针对客户提出的额外安全机制需求，知从可以针对性地制作检测功能，并提供相应的配置项。在ECCTestSets页面中选择需要执行的检测项。

4.1.4        生成配置代码

在配置完所有功能后即可生成EimErmTst相关的配置代码。

           4.2     应用领域

知从木牛配置工具，给ECU控制器软件开发提供友好的人机界面。可以支持标准的AUTOSAR基础软件代码模块的配置以及复杂驱动的配置界面开发。目前主要应用于如下场景：

Ø  知从木牛基础软件平台标准AUTOSAR模块配置

Ø   知从木牛基础软件平台复杂驱动模块配置

u  SAFETY FRAME

u  CRYPTO LIBRARY

u  BCCIC

u  SBC

Ø  同芯片企业合作，提供MCU MCAL 的配置工具

Overview

FS85 is a kind of automotive grade SBC chip introduced by NXP to meet the functional safety requirements. The FS85 series SBC has the highest functional safety level ASIL-D, and is mainly used in automotive applications such as automotive radar, ADAS domain controller, and in-vehicle entertainment information system. This paper will briefly introduce the FCCU function of the chip, including the function introduction of FCCU, the FSP protocol supported by FCCU, the configuration method of FCCU and the example of FCCU application scenario.

1      the function introduction of FCCU

The FCCU provides a hardware interface to collect fault information from the MCU and place the device in a safe state if a device fault is detected. No CPU intervention is required during the collection and control operations. FCCU provides a systematic approach to fault collection and control. The FS85 chip supports two fault signal inputs FCCU1 and FCCU2 for collecting fault information from MCU, and support single and double wire FCCU fault monitoring.

2      FCCU BI-STABLE protocol

Under the Bi-stable protocol, the FCCU fault can also be judged by configuring the fault polarity of FCCU12, which can be configured as FCCU1 = 0 or FCCU2 = 1 to belong to the fault state, or as FCCU1 = 1 or FCCU2 = 0 to belong to the fault state.

3      FS85 FCCU configuration method

3.1     FCCU FUNCTION ENABLED

The FCCU monitoring function of FS85 must be enabled by using the FCCU_EN OTP bit through the OTP. If FS85 is used in combination with NXP S32 series chips and FCCU monitoring is enabled, the FS85 fault recovery function can be enabled by OTP using the FLT_RECOVERY_EN OTP bit, thus using the fault recovery strategy of the microcontroller.

3.2     Hardware configuration of FCCU

3.2.1        Hardware configuration by pair

To enable FCCU (bi-stable mode), the FCCU_CFG bit of the FS_I_SAFE_INPUTS register is set to 01.

3.2.2        Hardware configuration as single independent input

Enabling a single input to the FCCU requires setting the FCCU_CFG bit of the FS_I_SAFE_INPUTS register to 10/11.

3.2.3        Fault polarity configuration

When the input is configured in the pin-pair input mode, the polarity of the error signal can be configured via the FCCU12_FLT_POL bit.

When configured in separate input mode, the FCCU can detect 2-channel error signals, and the polarity of each channel error signal can be configured separately by FCCU1_FLT_POL and FCCU2_FLT_POL.

3.2.4        FCCU12 error impact configuration

The error response of the FCCU is configured through FCCU12_FS_IMPACT when the input is configured in the pin-pair input mode.

When configured in separate input mode, the error response of the FCCU is individually configured via FCCU1/2_FS_IMPACT.

3.2.5        MCU fault recovery strategy

The fault recovery strategy feature is enabled by OTP_FLT_RECOvERY_EN bit. This function extends the watchdog window to allow the MCU to perform a fault recovery strategy. The goal is to not reset the MCU while it is trying to recover the application after a failure event. When a fault is triggered by the MCU via its FCCU pins, the FSOB pin is asserted by the device and the watchdog window duration becomes automatically an open window (no more duty cycle). This open window duration is configurable with the WDW_RECOVERY [3:0] bits during the INIT_FS phase.

4      FCCU state machine

The transition from WDW_PERIOD to WDW_RECOVERY happens when the FCCU pin indicates an error and FSOB is asserted. If the MCU send a good watchdog refresh before the end of the WDW_RECOVERY duration, the device switches back to the WDW_PERIOD duration and associated duty cycle if the FCCU pins does not indicate an error anymore. Otherwise, a new WDW_RECOVERY period is started. If the MCU does not send a good watchdog refresh before the end of the WDW_RECOVERY duration, then a reset pulse is generated, and the fail-safe state machine moves back to INIT_FS.

5      Example of application scenario of FCCU

Application Scenarios：TC397_SMU + FS8530_FCCU

FCCU configuration：

FS_I_SAFE_INPUTS. FCCU_CFG = 01（Bi-statble）、

FS_I_SAFE_INPUTS. FCCU12_FLT_POL = 0 （FCCU1 = 0 or FCCU2 = 1 level is a fault）

FS_I_SAFE_INPUTS. FCCU12_FS_IMPACT = 0（FS0B only is asserted）

FS_WD_WINDOW. WDW_RECOVERY = 0x7（12ms）

Test Result：

6      ZC TC3XX SAFETYFRAME Product Introduction

The electrification and intelligent development of automobile electronic control system is becoming more and more complex, and the safety requirements of electronic and electrical architecture are becoming higher and higher. Through HARA analysis of road vehicle application scenarios, more and more attention is paid to vehicle functional safety in order to degrade and decompose safety objectives and keep the possibility of hazard occurrence lower than the risk limit. In recent years, reference has been made to ISO 26262 for functional safety standards; Refer to E-GAS layering for the software shelf security architecture. In electronic and electrical systems, For the common Element, the SEooC (safety element out of context) approach is usually adopted for its design and development.

ZC launched SAFETY FRAME to provide customers with ASIL level decomposition consultation, FMEDA analysis process support, chip-level self-check safety mechanism development, SafetyFrame configuration and software integration and other full-process functional safety services.

SAFETY FRAME consists of 3 components: the internal module self-checking test component of MCU (i.e. SF.MCU), the driver component of SBC's hardware security mechanism (i.e. SF.SBC), and the safety architecture component (i.e. SF.Architecture). The core module of SF.Architecture is Test Manager, which is used for the scheduling management of Safety Library for MCU and SBC, including Safety Wdgm, scheduling of Safety SBC/ASIC driver modules, and interfaces with application layer PFC (Program Flow Check), etc. SF.MCU contains 3 major modules:

l  TestLib-- Implementation of MCU chip module inspection.

l  DriverLib-- Implements the MCU chip module driver.

l SwLib-- Interfaces such as digital signature database and end-to-end protection database are commonly used by users.

In the principle of software modular layering, Function Controller and Monitoring Controller are implemented by SF.MCU and SF.SBC, respectively. It is also deployed at EGAS Level2 and Level3 levels, taking into account the application requirements of program flow monitoring and shutdown path design.

Software Architecture

The functional safety modules implemented by ZC SafetyFrame products include: Test Manager module, LBIST Test module, MBIST Test module, PFlash Test module, MCU Firmware Test module, Register Test module, DMA Test module, SRI Error Handling module, MONBIST Test module, Mcu Register Monitor module, Register Monitor Test module, Evadc Test module, Interrupt monitor Test module, Clock Plausibility Test module, DAM Test module, Convctrl Test module, CPU Internal BUS Test module, STM Test module, GTM TIM Clock Test module, Gtm IOM Alarm Test module, Gtm Tom Tim Test module, Port Test module, GptTst module, PMS configuration module, DTS Configuration module, OSC Clock Monitor module, SMU Error Handler module, SMU Software Alarm Drv module, IR FFI Control module, GTM IOM Configuration module, ERU Configuration module, TLF35584 Driver module, TLF35584 Error Handler module, E2E protection module, Safe Watchdog Manager module, Safe Watchdog Interface module, Safe Internal Watchdog module, Safe SBC Watchdog module.

ZC’s SafetyFrame product implements the watchdog monitoring WDGM module for the FS85 chip mentioned in this paper, and implements the SMUErrHdl module with the FCCU function in the TC3XX SMU module. The module implements the following security mechanisms.

概述

FS85 是 NXP 推出的一款满足功能安全要求的车规级 SBC 芯片，FS85 系列 SBC 的功能安全等级达到最高的 ASIL-D，其主要应用在汽车雷达、ADAS 域控制器、车载娱乐信息系统等汽车应用中。本文将针对该芯片的FCCU功能进行简要介绍，具体内容包含FCCU的功能介绍、FCCU支持的FSP协议、FCCU的配置方法、FCCU状态机以及FCCU的应用场景示例。

1      FCCU功能介绍

FCCU 提供了一个硬件接口，用于收集MCU的故障信息，并在检测到设备故障时将设备置于安全状态。在收集和控制操作过程中，无需 CPU 的干预。FCCU 提供了一种系统化的故障收集和控制方法。FS85芯片支持两路故障信号输入FCCU1和FCCU2用于收集来自MCU的故障信息，支持单、双线FCCU故障监控。

2      FCCU bi-stable协议

在Bi-stable协议下，通过配置FCCU12的故障极性还判断FCCU故障，其可以配置为FCCU1 = 0 或 FCCU2 = 1属于故障态，也可配置为FCCU1 = 1 或 FCCU2 = 0属于故障态。

3      FS85 FCCU配置方法

3.1     FCCU功能使能

必须通过 OTP 使用 FCCU_EN OTP 位来启用 FS85 的 FCCU 监控功能。如果将 FS85 与恩智浦 S32系列芯片结合使用，并且启用了 FCCU 监控功能，那么可以通过 OTP 使用 FLT_RECOVERY_EN OTP 位来启用 FS85 故障恢复功能，从而使用微控制器的故障恢复策略。 

3.2     FCCU硬件配置 

3.2.1        按对进行硬件配置

使能FCCU（bi-stable模式）需要将FS_I_SAFE_INPUTS寄存器的FCCU_CFG位设置为01。

3.2.2        硬件配置为单一独立输入模式

使能FCCU的单一输入需要将FS_I_SAFE_INPUTS寄存器的FCCU_CFG位设置为10/11。

3.2.3        故障极性配置

当输入配置为引脚对输入模式时，错误信号的极性可以通过 FCCU12_FLT_POL 位进行配置。

当配置为单独输入模式时，FCCU可以检测 2 路错误信号，每路错误信号的极性可以通过 FCCU1_FLT_POL 和 FCCU2_FLT_POL 单独配置。

3.2.4       FCCU12 错误影响配置

当输入配置为引脚对输入模式时，FCCU的错误响应通过FCCU12_FS_IMPACT进行配置。

当配置为单独输入模式时，FCCU的错误响应通过FCCU1/2_FS_IMPACT进行单独配置。

3.2.5        微控制单元故障恢复策略

故障恢复策略功能由 OTP_FLT_RECOVY_EN 位来启用。此功能会扩展看门狗窗口，以便微控制器能够执行故障恢复策略。其目的是在发生故障事件后，让微控制器在尝试恢复应用程序时不会进行复位操作。当微控制器通过其 FCCU 引脚触发故障时，设备会将 FSOB 引脚置高，此时看门狗窗口的持续时间会自动变为开放窗口（不再有占空比）。这种开放窗口的持续时间可在 INIT_FS 阶段通过 WDW_RECOVERY [3:0] 位进行配置。

4      FCCU状态机

当 FCCU 引脚显示有错误且 FSOB 被激活时，就会从 WDW_PERIOD 状态转换到 WDW_RECOVERY 状态。如果在 WDW_RECOVERY 期间结束前，微控制器发送了有效的看门狗刷新信号，那么设备会切换回 WDW_PERIOD 状态及其对应的占空比，前提是 FCCU 引脚不再显示错误。否则，将开始一个新的 WDW_RECOVERY 期间。如果在 WDW_RECOVERY 期间结束前微控制器没有发送有效的看门狗刷新信号，那么会生成一个复位脉冲，并且故障安全状态机会返回到 INIT_FS 状态。

5      FCCU的应用场景示例

应用场景：TC397_SMU + FS8530_FCCU

FCCU配置：

FS_I_SAFE_INPUTS. FCCU_CFG = 01（Bi-statble）、

FS_I_SAFE_INPUTS. FCCU12_FLT_POL = 0 （FCCU1 = 0 or FCCU2 = 1 level is a fault）

FS_I_SAFE_INPUTS. FCCU12_FS_IMPACT = 0（FS0B only is asserted）

FS_WD_WINDOW. WDW_RECOVERY = 0x7（12ms）

测试结果：

6      ZC TC3XX SafetyFrame产品介绍

汽车电控系统的电气化、智能化发展日趋复杂，对于电子电气架构的安全性要求也越来越高。通过对道路车辆应用场景的HARA分析，为了使安全目标被降级分解、保持危害发生可能性低于风险的受限值，汽车功能安全越来越受到重视。近年来，在功能安全标准上参考ISO 26262；在软件架安全架构上参考E-GAS分层。在电子电气系统中，对于通用的Element通常采用SEooC(safety element out of context)方法进行设计开发。

知从科技推出SAFETY FRAME为各车载控制器客户提供ASIL等级分解咨询、FMEDA分析过程支持、芯片级自检安全机制开发、SafetyFrame配置与软件集成等全流程功能安全服务。

SAFETY FRAME 包括 3个组件：MCU 内部模块自检测试组件（即 SF.MCU）、 SBC 硬件安全机制的驱动组件(即 SF.SBC)、安全架构组件(即SF.Architecture)。SF.Architecture 的核心模块为 Test Manager，用于 MCU&SBC 的 Safety Library 调度管理，包括 Safety WdgM、Safety SBC/ASIC 驱动模块调度、与应用层 PFC(Program Flow Check)接口等，SF.MCU包含 3 大模块：

lTestLib--实现 MCU 芯片模块的检测。

lDriverLib--实现 MCU 芯片模块的驱动。

lSwLib--用户常用的数字签名库、端到端保护库等接口。

SAFETY FRAME 在软件模块化分层原则上，将 Function Controller 和 Monitoring Controller 分别由 SF.MCU 和 SF.SBC 实现，并部署在 EGAS Level2 和 Level3 层级，充分考虑了程序流监控和关断路径设计的应用需求。

软件架构

知从SafetyFrame产品实现的功能安全模块包括：Test Manager模块、LBIST Test模块、MBIST Test模块、PFlash Test模块、MCU Firmware Test模块、Register Test模块、DMA Test模块、SRI Error Handling模块、MONBIST Test模块、Mcu Register Monitor模块、Register Monitor Test模块、Evadc Test模块、Interrupt monitor Test模块、Clock Plausibility Test模块、DAM Test模块、Convctrl Test模块、CPU Internal BUS Test模块、STM Test模块、GTM TIM Clock Test模块、Gtm IOM Alarm Test模块、Gtm Tom Tim Test模块、Port  Test模块、GptTst模块、PMS configuration模块、DTS Configuration模块、OSC Clock Monitor模块、SMU Error Handler模块、SMU Software Alarm Drv模块、IR FFI Control模块、GTM IOM Configuration模块、ERU Configuration模块、TLF35584 Driver模块、TLF35584 Error Handler模块、E2E保护模块、Safe Watchdog Manager模块、Safe Watchdog Interface模块、Safe Internal Watchdog模块、Safe SBC Watchdog模块。

知从SafetyFrame产品针对本文中提及的FS85芯片实现了看门狗监控WDGM模块，以及配合TC3XX SMU模块应用FCCU功能实现了SMUErrHdl模块，模块实现了以下安全机制。

知从木牛基础软件WDGM在功能安全中的应用

Application of ZC.MuNiu WdgM in Functional Safety

1      方案介绍

随着汽车行业的发展，汽车电子产品设计的复杂程度，特别是软件开发的复杂程度也随之大幅提升，行业对于安全性(Safety)的重视程度也越来越高。知从科技具备多年符合ISO 26262功能安全要求的控制器开发经验，并和国内知名汽车的公司建立战略合作伙伴关系。

针对满足ISO 26262功能安全要求过程中的痛点——E2E具体的项目实施，知从科技提供了相应的解决方案。

为了检测出信息交换中的各种失效状态，AUTOSAR提出了E2E机制，通过对通信数据增加DataID、CRC、Counter等控制字段，使得软件可以在运行时检测和处理通信链路故障。E2E保护可以实现：

1）        通过附加的控制数据来保护要通过RTE发送的安全相关的数据元素（data element）。

2）        通过控制数据来验证从RTE接收到的安全相关的数据元素。

3）        当接收到的安全相关的数据元素发生错误时，可以发出通知并由相关的SWC处理。

E2E保护是关键系统通信安全的基石，能够有效应对数据传输和处理过程中的多种风险，常见E2E保护方案如下：

Ø  CRC校验+计数器

n  使用CRC(Cyclic Redundancy Check)校验数据完整性

n  添加计数器检测数据新鲜度(防止重放攻击) 

n  简单易实现，适用于多数ASIL B-D应用

Ø  安全协议(如AUTOSAR E2E) 

n  AUTOSAR标准定义的E2E保护库

n  提供多种Profile(如Profile1-5等)适应不同ASIL等级

n  包含数据ID、计数器、CRC等机制

n  提供多种Profile变体(如Profile1A 1B 1C等) 

Ø  能够检测出来的失效状态

n  信息重复：信息被接收到不止一次

n  信息丢失：信息或部分信息从传输的信息流中删除

n  信息延迟：接收到的信息晚于预期

n  信息插入：将附加信息插入到所传输的信息流中

n  信息伪装：非真实信息被接收者接受为真实信息

n  信息的不正确寻址：信息从错误的发送方发送或被错误的接收方接收

n  信息次序不正确：修改传输信息流中的信息顺序

n  信息损坏：信息被改变内容

n  从发送方传送到多个接收方的信息不对称：多个接收方从同一发送方接收到不同的信息

n  发送方发送的信息只能被部分接收方接收：部分接收方没有接收到信息

n  通信信道阻塞：对通信通道的访问被阻塞

2      E2E Applications

知从科技可以为客户提供E2E完整方案，并可针对项目特定需求定制开发：

l  基于CAN/CANFD/LIN/ FlexRay通信保护方案

l  基于UART/SPI等通信保护方案

l  基于ETH通信保护方案

3      知从木牛E2E功能安全库

3.1     E2E协议栈

知从木牛E2E议栈栈主要由E2E、CRC两个模块构成。E2E模块通过配置实现用户所需的通信保护等，并且调用接口进行发送或接收。CRC模块功能为E2E模块进行CRC运算，得到具体CRC的结果。

4      证书

1      Introduction to the Solution

In order to detect various failure states in information exchange, AUTOSAR puts forward the E2E mechanism, which adds DataID, CRC, Counter and other control fields to the communication data, so that the software can detect and deal with communication link failures at runtime. E2E protection enables:

1)    Security related data elements to be sent via RTE are protected by additional control data.

2)    Verify security related data elements received from RTE through control data.

3) When an error occurs in the received security-related data element, a notification can be issued and processed by the relevant SWC.

With the development of the automotive industry, the complexity of the design of automotive electronic products, especially the complexity of software development, has also been greatly improved, and the industry has paid more and more attention to Safety. ZC Technology has many years of experience in controller development in line with ISO 26262 functional safety requirements, and has established strategic partnerships with well-known domestic automotive companies.

To meet the ISO 26262 functional safety requirements in the process of pain point - E2E specific project implementation, ZC technology provides the corresponding solution.

E2E protection is the cornerstone of communication security for critical systems and can effectively address multiple risks during data transmission and processing，the common E2E protection schemes are as follows:

Ø  CRC check + counter：

n  Cyclic Redundancy Check (CRC) is used to verify data integrity

n  Add counters to detect data freshness (prevent replay attacks)

n  Simple to implement and suitable for most ASIL B-D applications

Ø   Security protocols (such as AUTOSAR E2E)：

n  E2E protected library defined by AUTOSAR standard

n  Various profiles (such as Profile1-5, etc.) are available for different ASIL levels

n  Includes data ID, counter, CRC and other mechanisms

n  Multiple Profile variants available (e.g., Profile1A 1B 1C, etc.)

Ø  A failure state that can be detected：

n  Repetitionof information：The message is received more than once

n  Loss of information：The information or part of the information is deleted from the transmitted information flow

n  Delay of information：The message received was later than expected

n  Insertionof information：Inserts additional information into the transmitted information stream

n  Masquerading：Inauthentic information is accepted by the recipient as true information

n  Incorrect addressing：The message was sent from the wrong sender or received by the wrong receiver

n  Incorrect sequence of information：Modify the order of information in the transmission flow

n  Corruption of information：Information is changed content

n  Asymmetric information sent from a sender to multiple receivers：Multiple receivers receive different messages from the same sender

n  Information from a sender received by only a subset of the receivers：Some recipients did not receive the message

n  Blocking access to a communication channel）：Access to the communication channel is blocked

Secure Update ensures that only authorized software can be used by the controller, and when paired with Secure Boot, it can effectively prevent the execution of unofficial programs by the controller.

2      E2E Applications

ZC Technology can provide customers with a complete E2E solution, and can be customized for the specific needs of the project:

l  Communication protection scheme based on CAN/CANFD/LIN/ FlexRay

l  Communication protection scheme based on UART/SPI etc

l  Communication protection scheme based on ETH

3    ZC.MuNiu E2E SafetyLibrary

3.1      E2E Protocol Stack

The E2E stack is mainly composed of E2E and CRC modules. The E2E module is configured to implement the communication protection required by the user, etc., and calls the interface to send or receive. The CRC module performs CRC operations for the E2E module and obtains specific CRC results. 

4      CERTIFICATE

1      OVERVIEW OF SAF

The S32K3 safety software is an official software package provided by NXP, designed to help customers meet functional safety requirements for automotive electronic control unit products based on the S32K3 microcontroller. The S32K3 safety software fulfills most chip-level functional safety requirements specified in the S32K3xx Safety Manual, which includes SAF (Safety Application Framework), SPD (Safety Peripheral Driver), SCST (Core Self-Test Code), and RTD (Real-Time Drivers).

The S32 Safety Software Framework provides multiple software modules at both hardware safety layer and service safety layer, as follows:

l  BIST: Power-on self-test management module, including Logic Built-In Self-Test (LBIST) and Memory Built-In Self-Test (MBIST).

l  eMCEM: Extensible Microcontroller Error Management module, which integrates the FCCU (Fault Collection and Control Unit) module driver functionality of S32K3 microcontroller.

l  Mode Selector: Mode Selection Module. mSel performs a safety analysis based on the error source information and decides the MCU operation state based on the analysis result.

l  sBoot: Secure Boot module, responsible for verifying the correct configuration values of safety-related registers after power-on initialization.

l  SquareCheck: Secondary check module, used for fault injection testing of hardware mechanisms.

l  SW Recovery: Software Recovery module, responsible for executing functional reset of the microcontroller when critical faults are detected.

1.1     OVERVIEW OF STARTUP SEQUENCE AFTER SAFETY LIBRARIES INTEGRATION

Figure 1.1 Block diagram of the startup process

1.1.1  POR

POR (Power On Reset) is a type of Destructive Reset in the microcontroller's reset categories. During this stage, the MCU formally starts up. If HSE (Hardware Security Engine) functionality is enabled, the MCU enters the HSE Boot phase; if HSE functionality is disabled, it directly enters the Boot to Safety phase.

1.1.2  HSE Boot

During power-up, the MCU performs a series of information security-related operations through HSE (if enabled), including encryption/decryption, certificate verification, and key parsing validation.

1.1.3  Boot to Safety

In this phase, the MCU first performs BIST (Built-In Self-Test) and obtains the BIST results through the mSel (Mode Selector) module.

Meanwhile, the mSel module is also used to invoke the power-on self-test functions of sCheck (Square Check), which typically includes ECC fault detection for RAM, FLASH, and bus-related components, clock self-test, FCCU channel self-test, and CRC self-test functionalities.

After the self-test completion, mSel determines whether to switch the MCU state mode based on the overall self-test results, with Normal mode and Degraded mode available as shown in the figure.

Normal Mode

In this mode, all application task functions are executed. Before entering this mode, the sBoot (Secure Boot) module is used to verify peripheral configurations. If the verification fails, the sReco (Software Recovery) module will be called to perform a functional reset. If the verification passes, the OS (if present) will be started to execute MCU's periodic tasks. As for the SAF package, it will perform specific periodic self-tests, such as SCST (Safety Core Self-Test) and sCheck (Square Check) periodic detection.

Degraded Mode

In this mode, certain functionality trimming operations are performed, which are entirely customized by users based on their actual requirements. Multiple degraded modes can be configured to handle different safety tasks in various fault scenarios.

1.1.4  ShutDown

The sCheck (Square Check) module is also designed with detection capabilities during power-down phase. Faults detected during self-test can be recovered in the next power-up cycle. After self-test completion, the results can be stored in NVM (Non-Volatile Memory) through the mSel (Mode Selector) module, allowing the results to be retrieved during the next power-up sequence.

2      Overview of SCST (Structural Core Self-Test)

The SCST (Structural Core Self-Test) component is used to detect various MCU core sub-modules (such as Load/Store units, Forwarding logic units, Floating-point units, etc.) during runtime to determine whether permanent core faults exist in the MCU core. Its diagnostic coverage typically reaches 90%. The integration is compiler-independent, and the detection code is written in assembly language. It can cover all required diagnostic test items without expensive fault simulation tools. The achievable safety level is ASIL B.

Figure 2.1 Overview of SCST library materials 

3      INTEGRATION ISSUES GUIDANCE

This chapter demonstrates the SAF (Safety Application Framework) integration and troubleshooting process through a common issue encountered during SAF integration.

3.1.1  TCM (Tightly Coupled Memory) Fault

One of the most common issues encountered during SAF (Safety Application Framework) integration is TCM (Tightly Coupled Memory) related faults. For instance, after integration, during normal power-up, the FCCU (Fault Collection and Control Unit) module reports TCM faults causing continuous resets, while the code appears normal. How should we troubleshoot this situation?

First, let's look at the error information, as shown in the figure below:

Figure 3.1 FCCU fault information

The FCCU (Fault Collection and Control Unit) is the fault collection unit of the S32K3 microcontroller, where most chip fault information can be read. Here, we observe that channel 2 status register is set to 1, and subsequent debugging reveals that a fault occurred when accessing the TCM (Tightly Coupled Memory) address. Referring to the chip manual, we can determine that the TCM component generated an ECC (Error Correction Code) fault, which was then reported to the FCCU.

3.1.2  ECC (Error Correction Code) Fault

Let's first briefly introduce the ECC mechanism. There are two failure modes for memory:

1. Illegal access, which is typically protected through memory management using MPU (Memory Protection Unit)

2. Memory corruption, which is generally diagnosed through ECC, and the ECC mechanism can be implemented in either software or hardware.

ECC (Error Checking and Correcting) is an error detection and correction algorithm. In digital circuits, the smallest data unit is called a "bit", which is also the smallest unit in memory, representing data through high and low level signals using "1" and "0". Wireless electromagnetic interference in space and circuit noise can cause bit flips ("0" changing to "1", "1" changing to "0") during data interaction between memory and CPU. Typical ECC algorithms can generally achieve Single-Bit Error Correction and Double-Bit Error Detection (SECDED). 

Structure of ECC (Error Correction Code)

The number of required ECC bits is determined by the number of bits in the data segment. 8-bit data requires 5 ECC bits for verification, and for each doubling of data bits, only one additional ECC check bit is needed. For example, 32-bit data requires 7 ECC check bits.

ECC (Error Correction Code) Verification Process

The ECC encoding logic unit generates a 7-bit ECC check code during write operations. When data is read through the AHB (Advanced High-performance Bus) bus, the ECC decoding logic unit uses the same algorithm to calculate the check code for the read data, then compares it with the original check code to verify if they match.

Figure 3.2 ECC Mechanism Verification Path of S32K3 Microcontroller

Figure 3.3 Conventional ECC Verification Mechanism

Therefore, the fault was triggered by accessing a TCM (Tightly Coupled Memory) address with an ECC (Error Correction Code) error, which resulted in the exception being generated.

3.1.3   TCM (Tightly Coupled Memory) Initialization）

Similar to SRAM, TCM (Tightly Coupled Memory) must also be initialized before use, otherwise ECC (Error Correction Code) faults may occur.

Figure 3.4 Debug View of ECC Fault Region

Below is a screenshot of the startup code from the demonstration project. We can observe that the startup code performs a zero-writing operation from __INT_DTCM_START to __INT_DTCM_END. As explained in section 3.1.2, the corresponding ECC check codes are refreshed during the write operation, which constitutes the initialization process of TCM.

Figure 3.5 Screenshot of Startup Code

Finally, we can eliminate this fault by adjusting the linker script to extend the initialization range to cover the entire TCM (Tightly Coupled Memory) region.

3.1.4  Conclusion

During the integration of SAF (Safety Application Framework) safety package, similar ECC (Error Correction Code) issues are frequently encountered, which may involve SRAM, TCM, FLASH, or other components. The troubleshooting and resolution approaches are generally similar. By following the analysis steps mentioned above, most issues can be effectively resolved.

4      ZC Integration Services

We provide integration testing services for NXP S32K3 series MCU's S32K3 safety software. Given that S32K3 Safety software requires dynamic configuration based on customer safety requirements to fully cover their application needs, we can perform configurations according to different project requirements, ultimately meeting the functional safety engineering needs of our customers.

Currently, our services support the following microcontrollers:

5      Technical Services

5.1     Functional Description

Figure 5.1 Safety Pack Software Architecture Diagram

During the integration of SAF & SCST safety package, a Test Manager module is added at the upper layer to call interface functions of each self-test module according to the startup sequence. At the user level integration, the entire SAF & SCST safety package functionality can be executed simply through the Test Manager interface, significantly improving integration efficiency.

5.2     Introduction to ZC Test Manager Module

The Test Manager module is a core management and scheduling module added by ZC when integrating Safety Pack into actual projects. It is used to manage the Safety Pack test process and handle interfaces with the application layer. Additionally, it is paired with ZC's MuNiu configuration tool, which facilitates quick configuration of required detection modules.

Figure 5.2 MuNiu Configuration Tool Interface

功能安全产品支持哪些芯片呢？