功能安全——硬件安全需求

admin 2026-01-20 01:09:48 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 本文阐述了汽车功能安全中硬件安全需求的内容、规范及管理。核心要点包括需求应涵盖安全机制有效性、失效率目标及设计验证准则,管理上需保持无歧义与可追溯性。通过电压监测实例分析,文章建议为优化BOM成本,应尽量降低硬件功能安全等级至QM,将诊断功能交由软件实现,利用软件灵活性及销量稀释开发成本,从而提升产品市场竞争力。 综合评分: 88 文章分类: 车联网安全,安全建设,技术标准


cover_image

功能安全——硬件安全需求

谈思实验室

2026年1月19日 17:58 上海

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

01

什么是硬件安全需求

硬件安全需求是硬件需求中关于功能安全硬件的需求,它是从系统安全需求(TSR)和系统安全架构设计中分解出来的,并保证硬件安全需求与技术安全概念和系统架构设计的一致性。

硬件安全需求应该包含与安全相关的每一条硬件需求,具体内容包括:

1.确保安全机制有效性所需的特性

  1. 为控制硬件内部失效的安全机制的硬件安全需求和相关属性,包括用来覆盖相关瞬态故障的内部安全机制(例如看门狗的定时和探测能力)
  2. 为确保要素对外部失效容错的硬件安全需求和安全机制的相关属性(例如某个输入开路时,ECU应具备的功能表现)
  3. 为符合其他要素的安全需求的硬件安全需求和安全相关属性(例如对传感器或执行器的诊断)
  4. 为探测内外部失效和发送失效信息的硬件安全需求及安全相关机制的相关属性 防止故障潜伏的安全机制(例如硬件元器件的故障响应时间要符合FTTI故障容错时间间隔,多点故障探测时间间隔)

2.没有定义安全机制的安全需求

  1. 硬件单点失效率、硬件潜伏失效率,随机硬件失效目标值的硬件安全需求
  2. 为避免特定行为的要求(例如某个传感器不应该有一个不稳定的输出)
  3. 分配给执行预期功能硬件的需求
  4. 定义线束或接插件的设计措施的需求

3.硬件的设计验证准则

  1. 环境条件,包括温度、震动、EMI等
  2. 运行环境:供电电压、工况概述
  3. 中等复杂性硬件组件或元器件的鉴定认证

02

硬件安全需求的规范和管理

硬件安全需求包含旨在达到并确保所要求的硬件ASIL等级的全部要求,

安全需求管理包括:管理需求,对需求达成一致,对需求的执行取得承诺和保持追溯性

为了支持对安全要求的管理,推荐使用合适的要求管理工具(例如Plorain)

1.硬件安全需求的目的

  1. 确保正确的定义硬件安全需求及其属性和特性
  2. 确保再整个安全生命周期内一致的管理硬件安全需求

2.硬件安全需求的规范定义

1.语言描述

硬件安全需求定义

非正式标记法:使用非正式的文字与数字结合进行描述

半正式标记法:使用伪代码或使用UML,SysML等工具进行描述

正式标记法:使用Simulink或Stateflow建模并辅以精准的数学运算或推导

2.特性:

1.无歧义并可以理解的

评价标准:

如果对需求的意思存在共同的理解,那么需求就是无歧义的

如果要求的利益相关者或要求使用者理解需求的意思,那么需求就是可以理解的

2.不可分割的

评价标准:当一个层面的安全需求再所考虑的层面上不能被分解为下一个层面的安全需求,那么这些要求就是不可分割的

3.内部一致的

评价标准:每个单独的安全需求不包含自相矛盾的内容

4.可行的

评价标准:如果在相关项的开发限制内,需求可被实施,则它是可行的

5.可验证的

评价标准:需求可以被某些测试方法或手段验证出来,则它是可验证的

3.属性

  1. 在整个安全生命周期内,具有唯一识别并保持不变
  2. 状态
  3. ASIL等级

3.硬件安全需求管理

1.分层结构

分层结构是指安全需求是由连续几个层面构建而成的,这些层面与相应的设计阶段保持一致。

2.依据恰当的编组原则建立的有组织的结构

安全要求的组织,表示通常依据架构将每个层面的要求组合在一起

3.完整性

完整性表示一个层面的安全需求完整的实施了上一层面的全部安全需求

4.外部一致性

外部一致性表示多个安全要求不互相抵触

5.分层结构中任意一层的信息不重复

信息不重复表示安全需求的内容不重复出现在分层结构同一层面的其他安全需求中,并且每个分层层面都得以实现

6.可维护性

可维护性表示需求可被修改或扩展,例如引入要求的新版本或增加/去掉要求集内的要求。

7.可追溯性

可追溯性表示可以通过某个需求可以追溯到各个层面的需求(包括更改时的影响分析和安全评估)

4.安全要求方法

安全需求验证的方法

03

谁负责完成硬件安全需求

硬件安全需求,一般在国外会有专门的硬件需求工程师来完成硬件安全需求的工作,而在国内,大家都懂的,硬件需求、硬件架构设计、硬件详细设计、PCB Layout、EMC、BOM,硬件调试,分析问题,甚至是写专利,这些工作可能都是同一个硬件工程师来完成的。

04

什么时间什么阶段完成硬件安全需求

硬件安全需求的前提条件:

安全计划

技术安全概念

技术安全需求

系统设计规范

系统软硬件接口规范

当以上这些产物确定完成并释放之后,硬件安全需求的工作就可以开始了,在硬件架构设计开始之前硬件需求需要完成并释放。

05

如何去做硬件安全需求

只要按照第一章和第二章的要求和规范去写硬件安全需求,应该就可以得到一份标准的硬件安全需求。当然在写之前起码还需要准备一份技术安全需求待分解。

1.举例

TSC中有一条技术安全需求:

TSR1.当低压电压在9V-18V之间,系统需要保证驱动电机能够正常工作,且应满足所有已定义的所有功能。(ASIL C)

这条需求会被系统架构分解成几个部分:

我们可以重点关注这一条 “低压电压(KL30)正常工作范围 为9V-18V之间”

我们可以先站在系统架构的角度分析下这一条系统需求的意义:

1:功能安全等级ASIL C

解释: 这个不用多说,这个电压范围是保证功能正常的前提条件,所以不能被其他同级别的需求降级分解,所以功能安全等级是ASIL C

2.低压电压的电压值需要被采样

解释:没有采样,就不能判断信号是否在正常的工作范围

3.可能需要进行双路采样,冗余校验

解释:电压电压采样达到 ASIL C,那么一路采样本身做诊断是很难达到ASIL C

4.硬件保护

解释:基本的硬件防反接保护是需要的。

根据以上信息简单画一个架构图

低压采样电路系统架构

在这里讨论以下硬件安全需求的功能安全等级,我在系统架构设计中并没有注明这些检查是需要软件执行还是硬件执行,所以这里当然需要分情况讨论方案:

  1. 如果诊断由硬件执行,当然是可以实现的,并且硬件可以直接达到对应的功能安全等级,但是实现可能会稍微有点复杂,会增加硬件的成本,软件可能只需要做一个故障上报即可;
  2. 如果诊断由软件执行,对硬件的功能安全等级要求会下降,需要与软件的诊断进行配合才能达到对应的功能安全等级,当然软件的功能安全成本会升高;
  3. 诊断由软件和硬件共同完成,各分配一部分诊断,属于方案1和方案2的折中方案。

那么在现实的工程中我们大多会选择方案2,原因有以下几点:

  1. 方案2的产品本身的成本最低,软件的开发成本可以被产量所稀释,而硬件的成本很难稀释;
  2. 方案2软件实现灵活度高,如果后续需求发生了小变化,只需要更改软件即可,对产品硬件影响较小;

在总结一下就会发现,分配硬件的功能安全等级越低,产品的成本就越低,在市场上就会更有竞争力,软件的开发成本更有可能会被销量稀释,所以从此处得出结论,分配给硬件的功能安全等级最理想的状态是QM,当然准确的说是QM(C)。

现在可以根据系统架构的设计来进行硬件安全需求的编写:

HSR1:应在预期生命周期内以给定精度和给定范围内测量 KL30 上的电压。(ASIL = QM(C))

HSR2:对KL30电压进行双路采样,并保证采样电路不同,ADC采样通道不同且通道不在同一组Port中。

(ASIL =QM(C)) (PS.这样做是为了保证数据的安全性和独立性,防止共因失效)

HSR3:对KL30进行硬件防反接保护。(ASIL =QM(C))

HSR4:关于FMEDA要求,SPFM≥97%, LFM≥80%, PMHF<100FIT。

作者:穷困潦倒的资本家

https://zhuanlan.zhihu.com/p/656035690

谈思-汽车出海安全合规(欧洲)

交流群

谈思 AutoSec Europe 峰会旨在搭建一个能融汇全球视野与中国实践、连接技术前沿与落地应用的国际性专业平台,以助力中国汽车应对在出海过程中面临的网络与数据安全合规痛点。从前沿技术研讨、合规要点解析到经验交流,都将通过本平台为您提供持续支持。社群已超过200人,需邀请加入,如需入群,欢迎添加社群小助手微信taaslabs01。

谈思-SDV&AIDV技术出海

交流群

诚邀行业同仁加入谈思SDV&AIDV出海技术交流群,聚焦软件定义汽车、AI定义汽车、下一代EEA、智能座舱、智能驾驶、软件架构、域控制器开发、芯片技术、软件工具等核心议题,欢迎大家加群交流探讨~~社群已超过200人,需邀请加入,如需入群,欢迎添加社群小助手微信taaslabs01。

end

谈思汽车媒体门户

精品活动推荐

AutoSec系列沙龙

专业社群

部分入群专家来自:

新势力车企:

特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……

外资传统主流车企代表:

大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……

内资传统主流车企:

吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……

全球领先一级供应商:

博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、……

二级供应商(500+以上):

中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……

人员占比

公司类型占比

文章

不要错过哦,这可能是汽车网络安全产业最大的专属社区!

关于涉嫌仿冒AutoSec会议品牌的律师声明

一文带你了解智能汽车车载网络通信安全架构

网络安全:TARA方法、工具与案例

汽车数据安全合规重点分析

浅析汽车芯片信息安全之安全启动

域集中式架构的汽车车载通信安全方案探究

系统安全架构之车辆网络安全架构

车联网中的隐私保护问题

智能网联汽车网络安全技术研究

AUTOSAR 信息安全框架和关键技术分析

AUTOSAR 信息安全机制有哪些?

信息安全的底层机制

汽车网络安全

Autosar硬件安全模块HSM的使用

首发!小米雷军两会上就汽车数据安全问题建言:关于构建完善汽车数据安全管理体系的建议


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:谈思实验室 《功能安全——硬件安全需求》

功能安全——硬件安全需求 网络安全文章

功能安全——硬件安全需求

文章总结: 本文阐述了汽车功能安全中硬件安全需求的内容、规范及管理。核心要点包括需求应涵盖安全机制有效性、失效率目标及设计验证准则,管理上需保持无歧义与可追溯性
评论:0   参与:  0