A 10,000-word long article | Automotive ECU functional safety engineering practice

Latest update time：2024-02-22

Reads：

Author: Li Mochen

1 Introduction

Since I came into contact with the ISO26262 standard in 2016 , I have repeatedly studied the "software part" of PART 6 , but I have never been able to find the connection between it and the automotive embedded software design. For a long time, I did not know how to develop a solution that meets the requirements of the ISO26262 standard. Functionally safe vehicle ECU software; even in 2020 , my electronic control team successfully obtained the ISO26262 ASIL D process certification, but my understanding of functional safety is only at the level of "writing a series of documents".

From April 2022 to December 2023 , I was fortunate to participate in a complete vehicle electronic control module functional safety project - based on a certain pure electric vehicle of the company, I developed a VCU that meets the functional safety ASIL C/D level ( the entire car controller) products. In this article, I will sort out part of the development process based on my own practice in the project, hoping to provide some reference for colleagues like me who are confused about the implementation of the ISO26262 standard.

2Basic concepts

The terminology of the ISO26262 standard is described in detail in sequence in PART 1. Table 2-1 only lists the basic concepts needed in this article.

Table 2-1: VCU Functional Safety Project Terminology

serial number	Terminology / Abbreviation	full name	Remark
1	BD	Behavior Design
2	FIT	Failures In Time
3	FSC	Functional Safety Concept
4	FSR	Function Safety Requirement
5	FHTI	Fault Handling Time Interval
6	FTA	Fault Tree Analysis
7	FTTI	Fault Tolerant Time Interval
8	HARA	Hazard Analysis and Risk Assessment
9	HAZOP	HAZard and OPerability analysis
10	HSI	Hardware Software Interface
11	MF	Functional failure description ( Malfunction )
12	SM	Safety Mechanism
13	TSC	技术安全概念（ Technical Safety Concept ）
14	TSR	技术安全需求（ Technical Safety Requirement ）

3 功能安全概念开发

VCU 功能安全项目只进行了概念（ ISO26262 PART3 ）、系统（ ISO26262 PART4 ）、硬件（ ISO26262 PART5 ）和软件（ ISO26262 PART6 ）阶段的开发，本章整理概念阶段的工作内容，系统和软件的工作将分别在第 4 章和第 5 章整理。

功能安全概念阶段应输出相关项定义、危害分析和风险评估、功能安全概念等工作产品。

3.1 相关项定义

相关项指实现整车层面功能或部分功能的系统或系统组合；相关项定义指在整车层面对相关项进行定义和描述，包括功能及其与驾驶员、环境和其他相关项的依赖性和交互。

概念阶段的开发是从相关项定义（ Item Definition ）开始的，相关项定义是对系统的描述，此系统也是标准中“安全”要求应用的对象。

项目定义的目的是定义和描述相关项，以及对其他相关项和环境的依赖和相互作用。因此，需要描述功能和非功能需求、边界、接口和其他系统相互作用的假设。

相关项定义为危害分析和风险评估（ HARA ）提供输入参数，在 HARA 中通过对 E/E 系统功能故障的定义和分析，识别整车级别的潜在危害。

对于相关项（ Item ）的边界，相关项与其他相关项或环境的相互作用，相关项内部的元素以及涉及到元素的功能分配，需要在相关项文档进行描述。

表 3-1 列出相关项定义的主要内容。

表 3-1: 相关项定义主要内容

序号	内容	描述
1	车辆环境描述	用于描述车辆的配置、性能、使用环境、投放市场、相似功能，作为 HARA 分析和后续其他阶段的必要输入信息
2	法规要求	列出相关项需要满足相关法律法规的要求，用于指导系统设计
3	相关项描述	描述 VCU 的工作原理和执行器特性
4	运行模式	描述车辆运行模式及切换条件
5	功能行为设计描述	识别和描述相关项在整车级别的所有功能行为；识别整车级别功能与驾驶员和车辆的交互以及车辆的预期行为。包含蠕行控制、车辆加速控制、定速巡航控制、车辆滑行能量回收、车辆制动能量回收、坡起辅助控制、限速控制、切换驾驶模式、制动优先、响应外部请求、驾驶员离车或插枪时自动回 P 、挡位控制 N 挡进入、挡位控制 D 挡进入、挡位控制 R 挡进入、挡位显示、续航里程计算、远程锁车控制（限速）、行驶高压上电控制、行驶高压下电控制、交流充电高压上电控制、交流充电高压下电控制、直流充电高压上电控制、直流充电高压下电控制、主动放电使能控制、 DC/DC 使能控制、空调制冷控制、空调制热控制、驱动电机及高压附件冷却控制、动力电池冷却控制、动力电池加热控制、制动真空泵控制
6	整车级功能描述及架构设计	整车级功能：蠕行控制、车辆加速控制、定速巡航控制、车辆滑行能量回收、车辆制动能量回收、制动优先、坡起辅助控制、限速控制、挡位控制、切换驾驶模式、续驶里程计算、行驶高压上下电控制、充电高压上下电控制、主动放电使能控制、 DC/DC 使能控制、空调热管理使能控制、动力电机及高压附件热管理控制、动力电池热管理控制、制动真空泵控制；架构设计：车辆扭矩管理、挡位控制、切换驾驶模式、续驶里程计算、高压上下电控制、主动放电使能控制、 DC/DC 使能控制、热管理控制、制动真空泵控制
7	系统架构	根据功能架构汇总得到整车级系统架构，包含整体架构、元素接口（ VCU 与外部相关项进行信息交互的接口定义，即不同相关项之间进行信息交互所使用接口的描述）、功能分配（分配到架构各个元素的功能，即实现整车级功能的每个组成元素的需求）
8	质量 / 性能 / 可用性需求	描述功能的质量、性能和可用性需求
9	操作和环境约束	描述相关项的应用环境和操作的约束
10	功能相关性	描述相关项对外部相关项的要求及来自外部相关项的要求
11	运行情景	列出系统常见使用情景，用于指导 HARA 和系统设计，如乡村公路车辆直线行驶、城市道路车辆直线行驶、高速公路直线行驶、湿滑路面行驶、停车场等
12	失效后果及影响	描述相关项已知的潜在危害，用于指导 HARA 和系统设计

3.2 HARA 分析

危害分析、风险评估和 ASIL 等级的评定用于确定相关项的安全目标。为此，根据相关项的潜在危害事件，对相关性进行评估。通过对危害事件进行系统性的评估确定安全目标及分配给他们的 ASIL 等级。 ASIL 等级的确定需要考虑严重度、暴露概率和可控性。

HARA 分析的输出物是《危害分析和风险评估报告》。

3.2.1 危害分析

表 3-2 为危害分析示例。

表 3-2: 危害分析示例

危害分析
功能编号 Function ID	功能 Function	HAZOP ^①	checked	功能故障描述 Malfunction	失效的影响 Effect of failure	功能故障编号
VF-004	车辆滑行能量回收功能	No	X	滑行能量回收功能无法提供制动（负）扭矩	电机滑行制动力矩非预期消失，刹车距离增加	MF001
		No	X	滑行能量回收功能无法进入	失效表现与 MF001 相同，不重复讨论	MF002
		No	X	滑行能量回收功能无法退出	失效表现与 MF008 相同，不重复讨论	MF003
		Less	X	滑行能量回收功能提供制动（负）扭矩过小	电机滑行制动力矩过小，刹车距离增加	MF004
		More	X	滑行能量回收功能提供制动（负）扭矩过大（ ≤0.6m/s2 ）	电机滑行制动力矩过大，滑行减速度过大	MF005
		More	X	滑行能量回收功能提供制动（负）扭矩过大（ >0.6m/s2 ）	1 . 电机滑行制动力矩过大，滑行减速度过大 2 . 车辆横向运动失控	MF006
		Part of	X
		As Well As	X
		Reverse	X	滑行能量回收功能提供扭矩反向（扭矩为正）	车辆非预期加速行驶	MF007
		Unintended	X	滑行能量回收功能提供非预期制动（负）扭矩	1 . 车辆无法加速行驶，车辆减速 2 . 车辆横向运动失控	MF008
		Unintended	X	滑行能量回收功能非预期进入	失效表现与 MF008 相同，不重复讨论	MF009
		Unintended	X	滑行能量回收功能非预期退出	失效表现与 MF001 相同，不重复讨论	MF010
		Early	X	NA	NA
		Later	X	NA	NA
		Before	X	NA	NA
		After	X	NA	NA
		Stuck	X	NA	NA
		Misuse	X	NA	NA
		From Experienc e	X	NA	NA

① 如表 3-3 和图 3-1 所列

表 3-3: 危害分析引导字说明

Guideword	含义
No	功能突然丢失
Less	功能输出少于预期
More	功能输出大于预期
Part of	预期执行 A+B 功能时，实际只执行了 A 功能
As Well As	预期执行 A 功能时，同时非预期的执行了 B 功能
Reverse	与预期功能的逻辑相反
Unintended	非预期的功能输出
Early	功能输出比预期的时间早
Later	功能输出比预期的时间晚
Before	功能输出相对于顺序或序列提前
After	功能输出相对于顺序或序列延后
Stuck	功能卡滞
Misuse	无意误用 A 功能
From Experience	以上 guideword 以外的失效

图 3-1: 危害分析引导字图示

3.2.2 风险评估

对不含内部安全机制的相关项进行评估，表 3 - 4 为风险评估示例。

表 3-4: 风险评估示例

序号	评估项	内容
1	ID	HE013
2	Function	[VF-004] 滑行能量回收扭矩控制
3	Malfunctioning Behavior	[MF006] 滑行能量回收功能提供制动扭矩过大（ >0.6m/s2 ）
4	Hazard	[H004] 车辆横向运动失控
5	Location	NA
6	Road Conditions	F 冰雪路面 -E2 ISO26262
7	Environment	NA
8	Item Usage	F 直线行驶 -E4 Experience
9	Traffic and People	F 通畅（正常车距） -E4 VDA702
10	Potential Effect	车辆制动力过大，车辆偏离车道并与其他车辆、行人或物体发生碰撞的可能性
11	Assumptions and Coments	NA
12	Exposure	E2
13	Exposure Comment	车辆在冰雪路面准备滑行
14	Severity	S3
15	Severity Comment	车辆失去道路抓地力，前轮抱死时车无法转向，后轮抱死时车会侧滑，导致车辆偏离车道并与其他车辆、行人或物体发生碰撞，对应 S3
16	Controllability	C3
17	Controllability Comment	车辆失去抓地力，驾驶员无法重新控制车辆，没有可控性
18	ASIL	ASIL B
19	Safety Goal	[SG001] 避免滑行能量回收功能输出的制动（负）扭矩过大（ ∆a 减速度＞ 0.6m/s2 ）导致车辆失稳（ ASIL B ）

3.2.3 计算过程

确定每个危害事件的严重度等级、暴露概率等级和可控性等级，并根据这三者确定其 ASIL 等级。本步对所有不含内部安全机制的相关项进行风险评估。

表 3-5 、表 3-6 、表 3-7 和表 3-8 分别列出与 ASIL 等级确定的知识点。

表 3-5: 严重度等级

等级

描述

无伤害

轻度和中度伤害

严重的和危及生命的伤害（有存活的可能）

危及生命的伤害（存活不确定）

致命的伤害

表 3-6: 关于运行场景的暴露概率等级

等级	E0	E1	E2	E3	E4
描述	不可能	非常低的概率	低概率	中等概率	高概率

表 3-7: 可控性等级

等级	C0	C1	C2	C3
描述	可控	简单可控	一般可控	难以控制或不可控

表 3-8: ASIL 等级确定

严重度等级	暴露概率等级	可控性等级
严重度等级	暴露概率等级	C1	C2	C3
S1	E1	QM	QM	QM
	E2	QM	QM	QM
	E3	QM	QM	A
	E4	QM	A	B
S2	E1	QM	QM	QM
	E2	QM	QM	A
	E3	QM	A	B
	E4	A	B	C
S3	E1	QM	QM	A
	E2	QM	A	B
	E3	A	B	C
	E4	B	C	D

3.2.4 安全目标

应为具有 ASIL 等级的每个危害事件确定一个安全目标，该 ASIL 等级从危害分析和风险评估中得出。如果所确定的安全目标是类似的，可将其合并为一个安全目标。

表 3-9 为安全目标示例。

表 3-9: 安全目标示例

编号

安全目标

Safety Goal

ASIL 等级

ASIL

安全状态

Safe State

故障容错时间间隔

FTTI

故障处理时间间隔

FHTI

SG001

避免滑行能量回收功能输出的制动（负）扭矩过大（ ∆a 减速度＞ 0.6m/s2 ）导致车辆失稳

ASIL B

关闭滑行能量回收功能，并报警提醒驾驶员

300ms

SG002

避免滑行能量回收功能提供的扭矩反向（提供正扭矩）导致车辆非预期加速

ASIL A

关闭滑行能量回收功能，并报警提醒驾驶员

2130ms

200ms

3.3 功能安全概念

为了满足安全目标，功能安全概念包括安全措施（含安全机制），这些安全措施将在相关项的架构要素中实现，并在功能安全要求中规定。

功能安全概念包含以下内容。

3.3.1 安全分析

针对每个安全目标，对系统的初始架构进行安全分析，找出影响安全目标的子系统故障，作为后续导出功能安全需求的依据。安全分析工具可以是 FTA 或 FMEA ，图 3-2 为采用 FTA 方法的示例。

图 3-2: FTA 安全分析示例

3.3.2 功能安全需求

根据安全分析的结果，针对每个安全目标导出相应的功能安全需求。表 3-10 为功能安全需求的编写示例。

表 3-10: 功能安全需求示例

序号	需求项	内容
1	ID	FSR062
2	Name	滑行能量回收控制
3	Description	VCU 应正确计算滑行能量回收目标扭矩
4	Kind	FUNCTIONAL
5	ASIL	B
6	Time constraint	周期： TBDms
7	Related Goals	VF004_SG001 （ ASIL B ） VF004_SG002 （ ASIL A ）
8	Event	[E69] [ 滑行能量回收控制 ] [MF026] 滑行能量回收计算目标扭矩（绝对值）过大 [E73] [ 滑行能量回收控制 ] [MF027] 滑行能量回收计算目标扭矩反向（为正扭矩）
9	Allocations	VCU （ ASIL C ）
10	Status	PROPOSED
11	接收准则	Test

3.3.3 外部系统功能安全需求

外部系统功能安全需求分为“相关项对外部系统的功能安全需求”和“外部系统对相关项的功能安全需求”，表 3-11 和表 3-12 分别为这两者的示例。

表 3-11: 相关项对外部系统的功能安全需求示例

编号 ID	名称 Name	描述 Description	时间约束 TimeConstraint
1	BMS	BMS 的热管理系统应能提供过温保护的安全机制，防止热失控带来的危害，安全等级达到 ASIL C 等级	5000ms
2	维修操作手册	维修手册应详细说明交流充电关联系统的维修流程，必须完全断开充电高压回路后方可进行维修作业	NA
3	MCU	MCU 应正确接收 VCU 发送的蠕行目标扭矩，安全等级达到 ASIL B 等级	周期： TBDms

表 3-12: 外部系统对相关项的功能安全需求示例

编号 ID	名称 Name	描述 Description	时间约束 TimeConstraint
1	TBD （继承 ID 文档）	VCU 上高压的状态信号、车速信号的功能安全等级为 ASIL A	NA
2	ADU	VCU 应对 ADU 发送的扭矩请求信号进行 E2E 诊断，安全等级达到 ASIL B （ D ）等级	NA
3	ADU	VCU 应响应 ADU 发送的扭矩请求信号，安全等级达到 ASIL B （ D ）等级。	TBD

3.3.4 报警和降级

当系统诊断到相应的故障后，应该立刻进入到安全状态，如不能直接进入安全状态，则需要进入紧急操作模式，或降级模式，再进入安全状态，同时也要规定紧急操作模式的时间长度。另外，当故障出现后，驾驶员需要作何反应，有何行为要求也需要描述。

表 3-13 为报警和降级的编写示例。

表 3-13: 报警和降级示例

整车级功能	编号	安全目标	失效模式	过渡到安全状态	紧急措施 / 降级	紧急措施时间间隔	恢复到正常状态	驾驶员动作	报警
VF001	SG001	避免蠕行控制输出的驱动扭矩过大，导致追尾前车	[MF033] 蠕行扭矩计算过大	禁止蠕行控制	/	/	下一点火周期故障消除	/	/
			蠕行扭矩信号通信故障，导致输出蠕行扭矩过大				故障消除

3.3.5 功能安全需求汇总和分配

对所有安全目标导出的功能安全需求进行汇总和 ASIL 等级的合并，确定相关项的功能安全需求，同时将功能安全需求分配到系统架构中去。

表 3-14 为功能安全需求汇总和分配示例。

表 3-14: 功能安全需求汇总和分配示例

序号	需求项	内容
1	ID	FSR062
2	Name	滑行能量回收控制
3	Description	VCU 应正确计算滑行能量回收目标扭矩
4	Kind	FUNCTIONAL
5	ASIL	B
6	Time constraint	周期： TBDms
7	Related Goals	VF004_SG001 （ ASIL B ） VF004_SG002 （ ASIL A ）
8	Event	[E69] [ 滑行能量回收控制 ] [MF026] 滑行能量回收计算目标扭矩（绝对值）过大 [E73] [ 滑行能量回收控制 ] [MF027] 滑行能量回收计算目标扭矩反向（为正扭矩）
9	Allocations	VCU
10	Status	PROPOSED
11	接收准则	Test

3.3.6 功能安全架构

根据所提出的 FSR ，更新系统架构，并将功能安全需求分配到架构的模块上去，从而使得系统的架构满足功能安全需求。

4 功能安全系统开发

功能安全系统阶段的工作包括技术安全需求、技术安全概念、系统架构设计规范和软硬件接口规范等。

4.1 技术安全需求

技术安全需求应定义系统对影响安全需求实现的激励的响应。这包括在各种相关运行模式和所定义的系统状态下，激励与失效的组合。

表 4-1 为技术安全需求示例。

表 4-1: 技术安全需求示例

序号	需求项	内容
1	ID	TSR30
2	Name	制动踏板比较监控，故障确认
3	Description	当制动踏板 1 与制动踏板 2 采集到的有效结果不一致，并持续 60ms 时，故障确认
4	ASIL	C
5	Contributes To	FSR038-042 ， FSR084 ：制动开关非预期未踩下； FSR044-047 巡航无法退出
6	Allocations	MicroController-L2
7	Type	ASW
8	Operation Mode	行驶模式
9	Time Constraint	60ms

4.2 软硬件接口规范

软硬件接口规范包含以下内容。

4.2.1 操作模式

操作模式包括操作模式转换图（ Operating Modes Transfer Diagram ）、操作模式描述（ Operating Modes Description ）和操作模式转换条件（ Operating Modes Transfer Condition ）等。图 4-1 、表 4-2 和表 4-3 分别为三者的示例。

图 4-1: 操作模式转换图示例

表 4-2: 操作模式示例

Mode	Description	Use in the project
Run Mode	至少有一个主 CPU 没有请求睡眠模式或待机模式，并且处于运行模式。所有外围模块都处于活跃状态	Y
Sleep Mode	CPU 代码执行暂停，进入 CPU 空闲状态。如果在相应的 CLCx.EDIS 位中进行了配置，则外围设备将进入睡眠状态。端口保持各自先前的状态	N
Standby Mode	构成备用 RAM 和唤醒单元的备用域保持活动供电。芯片其余部分的电源完全关闭	N

表 4-3: 操作模式转换条件示例

当前模式	下一时刻模式	转换条件（ OR ）
CPU Run Mode	CPU Idle Mode	当 CPU 没有活动任务要执行时，通过设置寄存器位 PMCSRx.REQSLP = 01B 发出 SW 空闲请求
		在另一个 CPU 发出的软件空闲请求（ PMCSRy.REQSLP = 01B ）
		在 SMU 空闲请求下，如果检测到 CPU 故障，则会触发安全警报，该警报在 SMU 中配置为将 CPU 设定为空闲状态
CPU Idle Mode	CPU Run Mode	当 CPU 发生中断时
		当发生 Trap （如 NMI Trap 事件）时
		当 CPU 看门狗或安全看门狗定时器溢出事件触发 SMU 警报进而导致 CPU 中断时
		CPU 看门狗计数器发生 MSB 位换行时
		当应用程序复位、系统复位或任何更高级别的复位发生时

4.2.2 配置参数

列出 IC 相关配置参数（如： MCU 、通信、存储器、 I/O ）。例如： AURIX TC275 的描述内容包括 MCAL 、 SafeTlib 、 MCU-SM 。

4.2.3 独立性要求

软件进行相关失效分析（ Dependent Failure Analysis ）后识别到支持软件独立性要求的硬件特性。

表 4-4 为 AURIX-TC275 的描述内容（部分）。

表 4-4: AURIX-TC275 独立性要求描述

Dependent Failure Initiator

Hardware features

Safety mechanisms

Clock

For safety reasons clock monitors are available.Each of these clocks is monitored by its own counter.

As reference clock the back-up clock is used as diverse clock source.

SM1[HW].VADC:CLKMON

SM1[HW].GTM:CLKMON

SM1[HW].STM:CLKMON

SM1[HW].SPB:CLKMON

SM1[HW].SRI:CLKMON

SM1[HW].SystemPLL:CLKMON

SRAM

The SRAM monitoring is based on error detection and correction codes.

SM1[HW].SRAM:ECC

SM1[HW].SRAM:EDC

SM1[HW].SRAM:ADDRMON

SM1[HW].SRAM.ECC:LOCKSTEP

4.2.4 相互免干扰

软件进行相关失效分析（ Dependent Failure Analysis ）后识别到支持软件相互免干扰要求的硬件特性。

表 4-5 为 AURIX-TC275 的描述内容（部分）。

表 4-5: AURIX-TC275 相互免干扰描述

Dependent Failure Initiator	Hardware features	Safety mechanisms
Timing and execution	Enable the application to verify that the static timing properties of the safety related tasks are met during run-time. Provides internal watchdogs. There is one internal watchdog per CPU, plus one Safety watchdog.	SM1[HW].WDT
		SM1[HW].SWDT
		SM1[HW].CPU:TPS
Memory	Supported by the Memory Protection Unit (MPU) of the TriCore CPU. Each shared memory implements a region accessprotection mechanism.	SM1[HW].CPU.DATA:MPU
		SM1[HW].CPU.CODE:MPU
		SM1[HW].CPU.BUS:MPU
Resource	The modules connected on the SPB implements a register access protection. With this safety mechanism all the configuration registers can only be written by selected masters. Write accesses from forbidden masters are blocked and cause a bus error.	SM1[HW].<module>:AP
		SM1[HW].CPU:SV
		SM1[HW].CPU:USER1
		SM1[HW].CPU:USER0

4.2.5 输入输出

描述 ECU 级别的硬件信号与 MCU 的端口 / 引脚和软件输入 / 输出变量之间的关系，表 4-6 为其示例。

表 4-6: AURIX-TC275 软硬件接口输入输出示例

序号	层	描述项	内容
1	追溯信息	Relevant TSRs	TSR267
2		Relevant HSRs	FT_FUN_022
3		Relevant SSRs	SSR_xxx
4	概念层	Signal Name	DIL_8 （ HW ）； HVILFlg
5		Signal ASIL	QM
6		Signal Description	高压互锁信号
7		Signal Direction	in
8		Remark	低有效开关
9	物理层	Physical Signal property	Boolean[Open, Close]
10		Input Signal Property of ECU	Close ： Input voltage = INT_PULLUP Open ： Input voltage = GND 输入电压范围： 0~36V 滤波时间常数： 1ms 1 ： Vin ＞ 3.4 0 ： Vin ＜ 2.3
11		ECU pin	pin47
12		Processing Module	高压互锁信号采样处理
13		Processing Module Description	内部上拉，滤波时间常数 80ms
14		Property of Processing Module	内部上拉，滤波时间常数 80ms
15		MCU pin	pin77
16		MCU Peripheral/module number/ Channel number	P33.7
17		Input Signal Property of MCU	NA
18		Config of MCU Peripheral Module	Port 、 Dio
19		Remark	NA
20	数据层	Data Register Name and Address	MCAL P33.7
21		Data Type	NA
22		Data Range	NA
23		Trigger Event and time constraint	NA
24		Remark	NA
25	表达层	Variable name	NA
26		Variable type	NA
27		Default value	NA
28		Variable range	NA
29		Update period	10ms
30		Remark	NA

4.2.6 中断

描述系统所有中断分配情况，包括中断源、中断频率、中断服务程序的职责，以及其他相关的信息等，表 4-7 为其示例。

表 4-7: AURIX-TC275 软硬件接口中断示例

序号	描述项	内容
1	Module	GPT_Atom0_Ch0
2	No	10
3	ISR	GTMATOM0SR0_ISR
4	Description	GPT 中断，用于生成 OS 时钟
5	ASIL	ASIL D
6	CAT Configuration	二类中断
7	Priority Number	10
8	ISR frequency (nominal)	100Hz
9	ISR frequency (worst-case)	100Hz

4.2.7 内存分配

描述系统所有用到的 RAM 空间、 FLASH 空间、 EEPROM 空间的分配方案，表 4-8 为其示例。

表 4-8: AURIX-TC275 软硬件接口内存分配示例

序号	描述项	内容
1	Start Address / 起始地址	0xA0028000
2	Size / 存储空间	64K
3	Type / 存储类型	PFlash
4	Access / 访问方式	Read Only / Programming
5	ASIL	ASIL D
6	MPU	Y
7	ECC/EDC	N
8	Usage in Project / 项目中的用途	标定区
9	SW Independent Requirement / 软件对独立性的要求	Y

4.2.8 访问机制

描述硬件设备间的访问机制（ Serial ， parallel ， slave ， master/slave ），表 4-9 为其示例。

表 4-9: 软硬件接口访问机制示例

MCU

Other hardware devices

Access mechanism

MCU

SBC （ FS8510 ）

通讯类型： SPI

通信属性： MCU 为 master ， SBC 为 slave

MCU

Low-Side （ TLE8110 ）

通信类型： SPI

通信属性： MCU 为 master ， TLE8110 为 slave

4.2.9 硬件诊断

描述硬件的诊断特性和响应的安全机制及软件的实现，表 4-10 为其示例。

表 4-10: 软硬件接口硬件诊断示例

Diagnostic features	Safety mechanisms	Configuration OF SW
L9945 过温故障	ssr_xxx	通过软件启用：寄存器读取
FS8510 过温故障	ssr_xxx	通过软件启用：寄存器读取

4.2.10 时间约束

描述系统安全机制中硬件与软件所用时间，表 4-11 为其示例。

表 4-11: 软硬件接口硬件诊断示例

Sequence No / 顺序号	HW Side / 硬件	SW Side / 软件	Time Consume(ms) / 所用时间	Total Reaction time(ms) / 总共反应时间
1	Sample Switch signal and converter it to digital value	SW calucate the switch state and Signal Valid check	80	80

4.3 技术安全概念

技术安全概念的目的是从功能安全概念中导出技术安全需求，设计技术安全概念，并且将技术安全需求分配到相关项的初始架构中。

4.3.1 系统功能描述

系统功能如表 4-12 所列，文档中需要对每项功能进行详细描述。

表 4-12: 系统功能描述示例

功能 ID	功能名称	功能描述	和其他 Item/Element 的依赖关系（信号接收对象）
F001	蠕行控制	根据当前挡位状态、车速计算蠕行需求扭矩，使车辆在水平路面能维持稳定车速在 5km/h 附近。	MCU
F002	车辆加速控制	结合挡位信息、驾驶模式、车速与油门踏板深度信息，计算当前驾驶员需求扭矩。	MCU
F011	挡位控制	根据从挡位操纵器采集到的 R/N/D 挡信号有效性及制动开关、充电枪插枪信号、主驾车门开关信号、车速等信息判断是否进行挡位切换以及是否发送驻车请求信号	MCU 、 EPB
F044	充电高压上下电控制	当插入充电枪给车辆进行充电，车辆满足充电要求时， VCU 控制整车高压上下电，将高压连接指令发给 BMS ，由 BMS 闭合高压继电器	BMS 、 OBC

4.3.2 系统初始架构设计

设计 VCU 整体初始系统架构并按照表 4-13 、表 4-14 和表 4-15 分别进行功能、外部接口和内部接口描述。

表 4-13: VCU 初始架构功能描述示例

模块名称 Element Name	功能 ID Function ID	功能描述 Function Description
EMC 处理电路	F195	低压电源输入 EMC 处理
电源管理	F136	休眠、唤醒功能
	F100	内部功能模块供电
	F135	外部传感器、功能模块供电
直流充电口唤醒信号处理	F178	直流充电口唤醒信号处理

表 4-14: VCU 外部接口描述示例

逻辑接口	接口类型	方向	Connector Name
低压电池电压输入	Power （ 6-28V ）	Input （ LV Battery→VCU ）	接插件 1
KL15 ON 信号	高有效输入	Input （启动开关 →VCU ）	接插件 1
Start 信号	高有效输入	Input （启动开关 →VCU ）	接插件 1
N 档请求信号	数字信号（低有效）	Input （挡位控制器 →VCU ）	接插件 1

表 4-15: VCU 内部接口描述示例

逻辑接口	接口类型	方向
Torque request 信号输入	CAN （ 0-5V ）	CAN Transceiver→MCU
Operating Mode 信号输入	CAN （ 0-5V ）	CAN Transceiver→MCU
Crash Signal 信号输入（ VCU ）	CAN （ 0-5V ）	CAN Transceiver→MCU
KL15 唤醒信号	数字信号	KL15 唤醒信号处理 →275

4.3.3 基于系统初始架构的安全分析

安全分析首先需要设计功能失效列表；再依次进行外部非电气接口失效矩阵分析、约束性需求失效矩阵分析、配置功能失效矩阵分析和共享资源安全完整性分析；最后分别对系统失效顶事件进行安全分析。

（ 1 ） 功能安全目标

表 4-16 为功能安全目标的设计示例。

表 4-16: 功能安全目标设计示例

序号	描述项	内容
1	整车级功能	VF002 车辆加速控制
2	编号	SG001
3	安全目标	避免驱动控制提供驱动扭矩过大，导致车辆碰撞或车轮打滑
4	ASIL	ASIL B
5	安全状态	切断扭矩输出
6	单点故障	≥ 90 %
7	潜在故障	≥ 60 %
8	失效率	< 100Fit
9	FTTI	300ms
10	FHTI	300ms

（ 2 ） 功能失效列表

根据功能安全目标提炼出功能失效列表，这是进行安全分析的基础，如表 4-17 所列。

表 4-17: 功能失效列表示例

序号	VCU 系统失效顶事件	SG 追溯
1	驱动扭矩正过大/非预期输出正扭矩	VF001-SG001 、 VF002-SG001 、 VF002-SG003 、 VF003-SG002
2	制动优先功能无法激活	VF006-SG001

（ 3 ） 顶事件安全分析

使用与图 4-2 类似的 FTA 进行安全分析，输出表 4-18 所示的单点故障和潜伏故障列表。

图 4-2: FTA 安全分析示例

表 4-18: 单点故障和潜伏故障列表示例

IDs of Events

Events of Cut Set

SM Design

2nd level SM Design

E205

• [E205] [ 为 VCU 软件算法提供硬件平台 ] [MF068] 为软件提供的硬件平台故障

SM_SPF_003

SM_SPF_004

SM_SPF_006

SM_LF_001

SM_LF_003

E230

• [E230] [ 内部功能模块供电 ] [MF081] MCU 控制器供电过压

SM_SPF_001

SM_LF_002

4.3.4 安全机制设计

分别设计单点故障和潜伏故障的安全机制，参见表 4-19 和表 4-20 。

表 4-19: 单点故障安全机制设计示例

SM ID	SM_SPF_001
SM Name	Microcontroller 供电电压监控
Fault detection / tolerance method	SBC 监测到 Microcontroller 供电电压（ 3.3V ）低于 2.97V （ 10% ）并持续 40us ，确认其欠压故障；检测到 Microcontroller 供电电压高于 3.63V （ 10% ）并持续 45us ，确认其过压故障
FDTI	40us
Fault handling	（ 1 ）供电电压出现欠压故障，向 L1 层发送故障信息，寄存器 VMON3 报告欠压故障（须手动清除）； FS0B 引脚拉低通知 Microcontroller 芯片，同时停止 CAN 通讯（此时 MCU 可以正常工作）（ 2 ）供电电压出现过压故障，向 L1 层发送故障信息，寄存器 VMON3 报告过压故障（须手动清除）；为了保护芯片， Microcontroller 供电电压监控模块需要关断电压输出，同时停止 CAN 通讯（此时 MCU 可以正常工作）
Fault warning (related to LF)	ICU 检测到 VCU CAN 通信停止，在 200ms 内点亮红灯闪烁 + 蜂鸣
FRTI	TBD
Fault Recover	下个点火循环
Degraded Mode	Degraded 4
SPF Diagnostic Coverage	99%
LF Diagnostic Coverage	99%
Remark

表 4-20: 潜伏故障安全机制设计示例

SM ID	SM_LF_001
SM Name	Microcontroller 潜伏故障监控
Fault detection / tolerance method	Microcontroller 应采用针对单点故障或双点故障的二级安全机制
FDTI	上电初始化完成
Fault handling	Microcontroller 进入不可恢复的故障模式
Fault warning	Microcontroller 在 200ms 内将故障指示红灯常亮警告信息发送给 IC 。 IC 红灯常亮并用文字或故障码提示驾驶员。
FRTI	上电初始化完成
Fault Recover	Microcontroller 重启且自检无故障后恢复
SPF Diagnostic Coverage	N.A
LF Diagnostic Coverage	90%
Remark

4.3.5 其他

技术安全概念还应包含下列内容：系统降级策略；非功能相关的技术安全需求（试验需求、机械结构安装需求、硬件指标需求、共存需求、独立性需求等）；生产、运行、服务和报废需求规范；最终输出系统安全整体架构。

5 功能安全软件开发

VCU 功能安全软件阶段设计按照 V 流程的步骤进行，包括软件需求分析、软件架构设计、软件单元设计、软件单元测试、软件集成等步骤，软件集成测试和嵌入式软件测试分别由 HIL 和实车测试工程师负责。

5.1 软件安全需求

本阶段定义或细化由技术安全概念和系统架构设计规范导出的软件安全需求，并描述软件实现所需的安全相关功能和特性。

5.1.1 需求列表

表 5-1 为软件需求列表的示例。

表 5-1: 软件需求列表示例

编号	功能项	ASIL 等级	备注
1	加速踏板传感器信号范围诊断	ASIL B	X.X 节
2	加速踏板传感器信号比较监控	ASIL D	X.X 节
3	加速踏板传感器信号合理性校验	ASIL D	X.X 节
4	制动踏板传感器信号诊断	ASIL D	X.X 节
5	E2E 保护	ASIL D	X.X 节

5.1.2 模式转换

主要用于描述当前系统不同行为模式（例如上电模式、下电模式、运行模式、故障模式等）及各个行为模式的功能，模式之间的切换条件等。

5.1.3 功能描述

对软件功能进行详细描述，表 5-2 为功能描述示例。

表 5-2: 软件安全需求功能描述示例

SSR_ID	VCU_SSR104
Corresponding TSR ID	TSR166
ASIL Class	ASIL B
Function Description	[VCU_ECU_SW] 应该根据上一时刻挡位信号、当前挡位信号、车速信号、扭矩信号和制动踏板信号等判断挡位是否跳转，判断逻辑如下：车辆静止时（车速小于 0.5km/h ）需同时满足以下条件： 1) 上一时刻挡位信号为 N 挡，当前挡位信号为 D 挡； 2) 挡位故障标志位 =0 ； 3) KL15 信号 =ON ； 4) 制动踏板信号 =1 ； 5) 充电线未连接（ A+ 信号以及 OBC_CC 信号）；车辆非静止时（车速大于 0.5km/h ）需同时满足以下条件： 1) 上一时刻挡位信号为 N 挡，当前挡位信号为 D 挡； 2) 挡位信号故障标志位 =0 ； 3) KL15 信号 =ON ； 4) 扭矩绝对值＜ 6 Nm ； 5) 充电线未连接；当以上条件满足时，输出 N 挡转 D 挡允许标志位 =1
Operation Mode
Status	PROPOSED
Verification Method	Software test & Review
Comments	0 ： OFF ， 2 ： ON ， 3 ： START

5.1.4 设计约束

设计约束包括功能启动时间、负载率、内存空间使用率、空间分配、共存需求和独立性需求等，表 5-3 为其设计示例。

表 5-3: 软件安全需求设计约束示例

SSR_ID	VCU_SSR183
ASIL Class	QM
Function Description	[VCU_ECU_SW] 应满足如下负载率的要求： CPU 使用率： <80% ；中断负载率： <50% 。
Status	PROPOSED
Verification Method	Software test & Review or Review 使用测试工具评（如 RVS ）估出 CPU 使用率和中断负载率是否满足要求。
Comments

5.2 软件架构设计

软件架构设计以层次结构的形式表示软件架构要素以及他们的交互方式。描述了静态方面，如软件组件之间的接口；动态方面，如进程序列和时序行为。

软件架构设计既要满足软件安全要求，又要满足其他软件要求。因此，在该子阶段中，与安全相关和非安全相关的软件要求在同一个开发过程中处理。

5.2.1 软件架构总体描述以及分层视图

本项目的软件架构基于 AUTOSAR 架构开发，应用层开发方式为基于模型设计（ MBD ），底层购买自第三方（ ETAS AUTOSAR ）。

VCU 软件架构如图 5-1 所示。

图 5-1: VCU 软件架构图

5.2.2 软件组件设计

分别描述软件架构中各组件的组件描述、组件图和接口描述等，表 5-4 、图 5-2 、表 5-5 和表 5-6 分别为对应的示例。

表 5-4: 组件概览示例

Component ID		VCU_031
分层 Layer		App layer
组件职责 Responsibility		1. 将模拟量采样结果传递给应用层 2. 将开关量采样结果传递给应用层
对应需求文档章节 Matching Requirement		ALL
实现方式 Source		Coding
ASIL 等级 ASIL Class		ASIL_D
资源消耗 Resource Consumption	Flash	N.A
	RAM	N.A
	EEPROM	N.A
	CPU	N.A

图 5-2: 软件组件图示例

表 5-5: 软件组件数据接口描述示例

名称 Name	描述 Description
hld_Mw_AccPdl2Vcc	参考附录 [ 数据字典 ]
hld_Mw_AccPdl1	参考附录 [ 数据字典 ]
hld_Mw_AccPdl1Vcc	参考附录 [ 数据字典 ]

表 5-6: 软件组件函数接口描述示例

Function Prototype 函数原型
void RE_AccPdl2Vcc_func (uint16 *hld_Mw_AccPdl2Vcc)
Parameter Specification 参数说明
hld_Mw_AccPdl2Vcc	加速踏板 2 电源电压信号指针
Return Value 返回值
Void	None
Functional Description 功能描述
该 API 函数的主要功能是：将加速踏板 2 电源电压信号传递给应用层

5.2.3 动态行为

动态行为常见的描述方式有以下三种：时序图（ Sequence Diagram ）、活动图（ Activity Diagram ）和交互纵览图（ Interaction Overview Diagram ）。动态行为描述的对象基于系统级功能列表，对其功能进行描述。

图 5-3 为动态行为图示例。

图 5-3: 动态行为图示例

5.2.4 任务调度和任务分配

描述系统所有任务的调度策略及任务划分，抢占属性，调度周期和优先级等。任务划分时，需考虑便于实现不同 ASIL 等级之间的免干扰性。

5.2.5 资源预估

计算 CPU 在不同调度周期（如： 1ms 、 5ms 、 10ms 、 100ms 、 1s ）的使用率以及软件系统所用到 RAM 空间、 FLASH 空间、 EEPROM 空间的分配方案。

5.2.6 资源冲突和控制流监控

所有存储在同一个字节中的全局标志应视为共享资源，对于有共享资源冲突的使用需要保护。

控制流监控有三种类型：活跃性监控（ Alive Supervision ）、最后期限监控（ Deadline Supervision ）和逻辑监控（ Logic Supervision ）。

本步制定在资源冲突和控制流监控时的安全机制。

5.3 软件单元设计和实现

软件单元设计和实现的目的是按照软件架构设计、设计准则和所分配的支持软件单元实施和验证的软件要求，进行软件单元设计；并实现所定义的软件单元。

5.3.1 软件功能简述

描述软件单元实现的功能。

5.3.2 组件源码文件

罗列程序文件名称及其实现的功能，表 5-7 为组件源码文件示例。

表 5-7: 组件源码文件示例

No. 编号	Filename 文件名称	Description 描述
1	AccPedal_Mon . c	该组件功能的实现 . c 文件，包含该组件运行时所有函数的定义 The implementation of the component's function. c file, containing definitions of all the functions that the component runs on
2	AccPedal_Mon . h	该组件功能的实现 .h 文件 , 包含该组件所有变量、函数的声明 H file containing the declaration of all variables and functions of the component
3	Vcu _ADC.h	该组件功能的实现包含的 .h 文件，包含 ADC 转换组件所有变量、函数的声明 The implementation of the component's functionality includes an. H file that contains declarations of all variables and functions of the ADC conversion component
......	……	......

5.3.3 静态框图

可以通过约定的方式展示组件静态框图，包括组件内单元的结构关系及单元之间的接口，且保持整个组件设计与架构中组件定义保持一致。图 5-4 为静态框图示例。

图 5-4: 软件单元静态框图示例

5.3.4 单元接口

描述单元间输入、输出信息，或使用表格的形式展示，也可单独管理接口信息，参见数据字典。表 5-8 为软件单元接口示例。

表 5-8: 软件单元接口示例

序号

N o.

Interfaces

DataType

InitValue

Dim

Units

Min

Max

Resolution

D e scription

Ex/I nter

AccPosVoltage

U nit 16

0.7

4.5

0. 01

加速踏板信号

Accelerator pedal signal

I n/Ex

ReAccPosVoltage

U nit 16

0 .35

2.25

0. 0 1

冗余加速踏板信号

Redundant accelerator pedal signals

I n /Ex

5.3.5 动态行为

基于 SWC 在架构设计中的动态行为及要求实现的软件功能需求及非功能需求，描述组件内单元之间的动态行为；动态行为描述可以采用时序图、状态机等形式进行。图 5-5 为软件单元动态行为示例。

图 5-5: 软件单元动态行为示例

5.3.6 变量定义

描述本组件或某单元内部的局部变量、标定量、常量、宏、复合数据等；也可单独管理接口信息，参见数据字典。表 5-9 为变量定义示例。

表 5-9: 软件单元变量定义示例

Name 数据定义	Type 数据类型	InitValue 初始值	Description 数据项描述
Local_count_1	Static Uint8	0	加速踏板位置故障恢复计数 Accelerator pedal position fault recovery count
Loca2_count_2	Static Uint8	0	冗余加速踏板位置故障恢复计数 Redundant accelerator pedal position fault recovery count
True	Macro	1	故障位真 Fault bit true

5.3.7 配置项设计

描述可在线配置和离线配置的配置项，离线指修改参数后再次编译，在线是通过诊断服务的方式进行配置项修改。表 5-10 为配置项设计示例。

表 5-10: 软件单元配置项设计示例

Name

名称

Description

描述

类型

Range

范围

Definition 定义

配置方式

ASIL

驱动防滑与稳定协调控制功能

通过配置来使能 / 禁能该功能

Boolean

0-1

1 ：使能功能；

0 ：禁能功能

离线

ASIL B

5.3.8 函数单元设计

对软件单元所含各函数的函数原型、输入输出参数、返回值、功能描述、设计思路、实现方法等逐一说明。

5.4 软件单元验证

本步提供证据证明软件单元设计满足分配的软件要求且适合于实施，验证安全分析得出的安全措施得到适当实施，提供证据证明所实现的软件单元符合单元设计，并满足根据所需的 ASIL 等级分配的软件要求。

5.4.1 软件验证计划和策略

表 5-11 、表 5-12 、表 5-13 和表 5-14 分别为软件验证计划（ Software Verification Plan ）、软件单元测试范围（ Software Unit Test Scope ）、测试工具列表及环境（ Test Tool List and Environment ）和软件单元验证策略（ SW Unit Test ）的示例。

表 5-11: 软件验证计划示例

一级任务 Level 1 task	二级任务（具体工作安排） Level 2 task (Specific work schedule)	工作产品输出 Work product output	是否裁剪 Whether to crop	完成情况	是否评审	备注 Remarks
文档审核 Document Auditing	软件需求审核 Software requirements review	AXXXXX_BBB_ 软件需求评审检查单 AXXXXX_BBB_Software Requirements Review Checklist
文档审核 Document Auditing	软件方案审核 Software Scheme Auditing	AXXXXX_BBB_ 软件架构评审检查单 AXXXXX_BBB_Software Architecture Review Checklist
......

表 5-12: 软件单元测试范围示例

测试模块名称

Test module name

软件单元名称

Software Unit Name

是否裁剪（可复用）

Whether to clip (reusable)

复用说明

Whether to clip (reusable)

是否需要

测试环境

Is it necessary

testing environment

测试环境说明

Test environment description

备注

Remarks

ADC Driver 模块

Initial_ADC

xxx 项目的 xxx.c 的 xxx 版本

表 5-13: 测试工具列表及环境示例

测试工具名称 Test Tool Name	型号 ( 规格 ) Model (Specification)	供应商 Supplier	工具资质 Tool Qualification	备注 Remarks
Polyspace	R2014b	MathWorks		代码静态验证 / 语义分析
......
测试阶段 Test Phase	测试环境 Test Environment			备注 Remarks
单元 / 模型静态验证 Unit/Integration Model Static Validation	MIL			模型静态验证 / 规则检查 Model static validation/rule checking
......

表 5-14: 软件单元验证策略示例

Test Case ID

Verification Method

Test Case Name

Test Case Description

Criteria

Verification

Environment

Verification

Resource

SW_UT_0xx

Walk-through

Pass

......

5.4.2 软件单元测试用例和报告

表 5-15 为软件单元测试用例和报告的示例。

表 5-15: 软件单元测试用例和报告示例

用例唯一标识符

Use Case Unique Identifier

类型

Type

用例名称

Use Case Name

级别

Level

测试步骤

Testing step

期望结果

Expected results

实际结果及其他说明

Actual results and other explanations

实际结果及其他说明

Actual results and other explanations

A10000-001-001

用例 Case

接口 + 边界测试 Interface + boundary testing

高

t=0ms ，设置 sigIn=1 ；

t=0-100ms ，保持 sigIn=1 ；

t=110ms ，保持 sigIn=2

t=0ms ，设置 sigOut=100 ；

t=0-100ms ，保持 sigOut=100 ；

t=110ms ，保持 sigOut=200

......

5.4.3 软件模型和代码静态验证报告

表 5-16 和表 5-17 分别为软件模型和代码静态验证报告的示例。

表 5-16: 软件模型静态验证报告示例

Simulink 建模规范（版本： V2.0 ）

章节 -3

规范内容

Specification Content

复杂性度量

Complexity Metrics

ISO26262:2018

检查方法

是否符合

违反规范模型内容描述

Description of the content of the breach model

说明

HR_cmply_1

圈复杂度度量 Cyclomatic complexity measure

[ISO 26262, Table1,1a]

Pass

......

表 5-17: 软件代码静态验证报告示例

C 语言编程规范 ( 版本 :C1 ）

章节

规范内容 Specification content

MISRA

2012

ISO26262:2018

检查方法

是否符合

违反规范代码内容描述

Description of the content of the code violation

说明 Description

3.1.11

在可互换的情况下，应优先使用函数而非宏函数。

In the case of interchangeability, functions should be preferred over macrofunctions.

[Dir 4.9] [A]

[ISO 26262, Tablex,2h]

QAC

......

5.5 软件集成和验证

本步定义集成步骤并集成软件要素，直至嵌入式软件完全集成；验证是确保软件架构层面的安全分析得出的已定义的安全措施得到适当实施。

5.5.1 软件集成

软件集成的方法应定义和描述将各个软件单元分层集成到软件组件中的步骤，直到整个嵌入式软件全部被集成。

对于 AUTOSAR 工具链方式设计的车载嵌入式软件而言，软件集成主要包括基础软件模块间的集成以及基础软件与应用层软件的集成。

5.5.2 集成测试范围

表 5-18 为软件集成测试范围示例。

表 5-18: 软件集成测试范围示例

软件需求

Software Requirements

集成模块名称

Integration module name

集成类型

Integration type

测试内容

Test Content

是否需要

测试环境

Is it necessary

testing environment

测试环境说明

Test environment description

备注

Remarks

填写软件需求 ID

Fill in the software requirement ID

Integration :

ADC , PWM , OVP , DIO , OS

Integration of some software units

Software integration testing

Software requirements testing

Software Integration Testing

Software requirements testing

5.5.3 Integration test report

Same format as software unit test report.

6 Overview of the core work of functional safety basic software

The main tasks of the VCU functional safety project basic software are listed below .

6.1 Concept stage

In the functional safety concept stage, basic software engineers have less work. They mainly check and learn the definition of relevant items and develop functional safety concepts, and assist in drawing the functional safety architecture.

6.2 System stage

The work of the basic software in the functional safety system stage is listed in Table 6-1 .

Table 6-1: Basic software work in the system stage

serial number	work item	Work content
1	System architecture diagram	Assist system engineers to draw the VCU initial architecture diagram and security architecture diagram, focusing on sorting out the outer layer (input and output) part of the architecture diagram
2	Software and hardware interface	One of the core tasks of basic software, the conceptual layer and physical layer can be written by hardware or basic software engineers; the data layer and expression layer are usually written by basic software engineers
3	Technical security requirements	Compile underlying technical security requirements, including watchdogs, main control chip security mechanisms, power chip security mechanisms, peripheral chip fault diagnosis, bus communication faults, program flow monitoring, program flash faults, etc.
4	Technology security concept	Write security mechanisms for underlying related modules, such as power supply voltage monitoring, single point fault monitoring, external watchdog monitoring, communication security integrity, etc.

6.3Software stage

The work of the basic software in the functional safety software stage is listed in Table 6-2 .

Table 6-2: Basic software work in the software phase

serial number	work item	Work content
1	Software security requirements	Write the functional description of the following modules in the software safety requirements specification: E2E protection, SBC power supply overvoltage and undervoltage detection, software program flashing, external watchdog, internal watchdog, fault code conversion and storage, SBC chip requirements, MCU Chip requirements, etc.; load rate, space allocation, memory space usage, etc. in design constraints
2	Software architecture design	Write an overall description and hierarchical view of the software architecture; complete the design of underlying module components; design task scheduling and task allocation; interrupt resource allocation; CPU usage and storage space estimation; control flow monitoring; design of different ASIL level software module partitions
3	Software unit design and implementation	Functional safety is the core part of basic software design. Design and implementation of BSW modules ( Wdg , WdgM , E2E ); OS task design and implementation (the design principle is that software modules with different ASIL levels must exist in different APPLICATIONs of different cores or the same core ); Implementation of power chip security mechanism; Main Control chip security mechanism implementation; fault signal upload, etc.
4	Software unit verification	Write the underlying module software unit verification strategy; write test cases and reports; software module practical testing, etc.
5	Software integration and verification	Integration of basic software modules; integration of basic software and application layer software ( all modules of L1 and L2 layers); programming software integration verification strategy, writing software and hardware integration test test cases related to the underlying modules, including software flashing and hardware single points Fault monitoring, external watchdog monitoring, program flow monitoring, microprocessor latent failure, power supply monitoring latent failure, SPI communication failure, CAN communication failure, etc.

7 project summary

The development process of the new energy VCU functional safety project is listed above . Here is a brief summary.

7.1 Standards and Projects

The functional safety specification is only a guiding document. Learning the automotive electronics design method that meets functional safety is inseparable from the engineering practice of specific projects. This process can be carried out under the guidance of a professional consulting company.

7.2 Documentation and Program Engineering

Functional safety design is not just about writing documents, but using documents to formulate safety goals, design safety mechanisms, and then meet vehicle safety requirements through software and hardware design. The final output program needs to meet mass production requirements after being verified by HIL and real vehicle testing.

7.3 Capability requirements

Judging from the work on the basic software part of the functional safety project, Wdg module development requires MCAL design capabilities; WdgM and E2E module development requires BSW design capabilities; software integration requires RTE design capabilities; task allocation at different ASIL levels requires OS design capabilities; The implementation of the security mechanism of control chips and power chips requires manual reading and manual programming capabilities ... The work of application layer software and hardware engineers is similar. Therefore, developing a vehicle ECU that meets ISO26262 requires relevant engineers to have comprehensive design capabilities and documentation capabilities.

Functional safety is not a separate technology, but an expansion and sublimation of software and hardware design.

7.4 Functional safety certification

Finally, let’s talk about the vehicle functional safety engineer exam. The highly valuable functional safety certificate exam has high difficulty and a huge amount of questions (it is said that no Chinese candidate can complete the questions), and the content of the examination involves various chapters of the standard (including terminology, concepts, systems, hardware, software , production, etc.). There must be a division of labor when doing projects, but if you want to pass the exam, you must master as much key knowledge as possible in each part of the standard.

Latest articles about

■Understanding the OSI Model Using Logistics

■Talk about the controversy of the maximum load of 375 kg for new energy vehicles

■What is the car moose test?

■Live Preview | AUTOSAR SOME/IP Technology Interpretation

■AP AUTOSAR Hard-Core Technology (5): Diagnostic Management

■How much does it cost to customize an automotive-grade ECU?

■Live broadcast today | CAN XL International Seminar

■“Customers are not afraid, so what are you afraid of?” - Reflection on the value of static analysis of automotive software

■Detailed explanation of the control algorithm of the electromechanical brake system (EMB) - Taking Tongyu Automobile and Feige Intelligent as examples

■[Opening this week] SAE-AWC 2024 Automotive EEA Innovation Technology Forum | Free registration

A 10,000-word long article | Automotive ECU functional safety engineering practice

Author: Li Mochen

1 Introduction

2Basic concepts

The terminology of the ISO26262 standard is described in detail in sequence in PART 1. Table 2-1 only lists the basic concepts needed in this article.

3 功能安全概念开发

3.1 相关项定义

3.2 HARA 分析

3.2.1 危害分析

3.2.2 风险评估

3.2.3 计算过程

3.2.4 安全目标

3.3 功能安全概念

3.3.1 安全分析

3.3.2 功能安全需求

3.3.3 外部系统功能安全需求

3.3.4 报警和降级

3.3.5 功能安全需求汇总和分配

3.3.6 功能安全架构

4 功能安全系统开发

4.1 技术安全需求

4.2 软硬件接口规范

4.2.1 操作模式

4.2.2 配置参数

4.2.3 独立性要求

4.2.4 相互免干扰

4.2.5 输入输出

4.2.6 中断

4.2.7 内存分配

4.2.8 访问机制

4.2.9 硬件诊断

4.2.10 时间约束

4.3 技术安全概念

4.3.1 系统功能描述

4.3.2 系统初始架构设计

4.3.3 基于系统初始架构的安全分析

4.3.4 安全机制设计

4.3.5 其他

5 功能安全软件开发

5.1 软件安全需求

5.1.1 需求列表

5.1.2 模式转换

5.1.3 功能描述

5.1.4 设计约束

5.2 软件架构设计

5.2.1 软件架构总体描述以及分层视图

5.2.2 软件组件设计

5.2.3 动态行为

5.2.4 任务调度和任务分配

5.2.5 资源预估

5.2.6 资源冲突和控制流监控

5.3 软件单元设计和实现

5.3.1 软件功能简述

5.3.2 组件源码文件

5.3.3 静态框图

5.3.4 单元接口

5.3.5 动态行为

5.3.6 变量定义

5.3.7 配置项设计

5.3.8 函数单元设计

5.4 软件单元验证

5.4.1 软件验证计划和策略

5.4.2 软件单元测试用例和报告

5.4.3 软件模型和代码静态验证报告

5.5 软件集成和验证

5.5.1 软件集成

5.5.2 集成测试范围

5.5.3 Integration test report

6 Overview of the core work of functional safety basic software

6.1 Concept stage

6.2 System stage

6.3Software stage ​

7 project summary

7.1 Standards and Projects

7.2 Documentation and Program Engineering

7.3 Capability requirements

7.4 Functional safety certification

Latest articles about

6.3Software stage