ANNUOVITA-CSDN博客

原创 She‘s Coming ！

【新书推荐】《一本书讲透汽车功能安全：标准详解与应用实践》正式出版，为汽车行业从业者提供功能安全标准落地指南。本书由16章组成，分为功能安全详解和分析两大板块，涵盖从概念阶段到系统/硬件/软件开发的全流程，结合FMEA、FTA等分析方法，并融入网络安全与ASPICE的协同考量。多位国际安全专家联袂推荐，特别适合汽车电子开发、芯片设计、项目管理等专业人员，以及相关领域学生和研究机构参考。该书侧重实践应用，通过具体案例解析标准条款，帮助读者解决功能安全实施中的实际问题。京东、当当等平台已上架销售。

2025-07-02 18:39:18 757

原创功能安全的架构设计（六）

在《功能安全的架构设计（一）》一文中我们介绍fail-operational概念时特意提到了自动驾驶，系统的安全和可用性对于高阶自动驾驶都是无法回避的话题，fail-operational架构自然而然也就成了高阶自动驾驶系统设计的必选项，本文我们就来和大家谈谈自动驾驶系统的安全架构设计。

2025-06-24 07:30:00 544

原创功能安全的架构设计（五）

IEC 62061中定义了四种机械安全控制系统(SCS)的基本架构模型，这四种架构模型分别为子系统架构A, 子系统架构B, 子系统架构C和子系统架构D。接下来我们就来看看该标准里的安全架构长什么样？它们又和前面文章提到的架构概念有什么区别？如指定架构(designated architecture)、MooN架构、fail-safe/fail-operational架构。

2025-06-09 07:30:00 2008

原创功能安全的架构设计（四）

E-GAS监控架构作为汽车功能安全领域的经典设计，采用三层架构模式：功能层实现控制逻辑，功能监控层校验功能正确性，控制器监控层确保硬件可靠性。该架构通过扭矩连续性和加速度比对原则，有效预防非预期加速等危险场景。第三层监控结合芯片内置机制与外部独立监控模块，实现处理器运行状态的双重保障。文中对比了MooN(D)架构与指定架构的异同，并探讨了E-GAS架构在fail-safe与fail-operational特性上的表现。

2025-06-03 07:15:00 838

原创功能安全的架构设计（三）

此篇我们来谈谈《功能安全的架构设计（一）》一文中提到的另一种架构概念——指定架构(designated architecture), 看看这种架构概念和MooN(D), fail-safe及fail-operational这些架构概念又有什么区别与联系。

2025-05-30 07:15:00 710

原创功能安全的架构设计（二）

在《功能安全的架构设计（一）》一文中我们谈了谈fail-safe, fail-operational, fail-silent, MooN，EGAS等架构的概念，其实合并来讲对应的架构就两类——fail-safe或fail-operational。fail-operational架构涉及到冗余，由于冗余的方式多种多样，所以这种架构的表现形式也是多样化的，通常应用MooN(D)架构可以实现不同形式的fail-operational。

2025-05-23 07:15:00 919

原创功能安全的架构设计（一）

本篇开始来我们谈谈功能安全的架构设计和常规的功能性架构设计有什么不一样，系统架构和软硬件架构又有什么区别和联系，尤其是和硬件架构。一提到安全架构设计大家可能就会想到E-GAS，fail-safe , fail-operational，MooN，Designated architecture等概念，这些概念对应的架构有什么区别与联系？有没有针对不同ASIL的一些指定架构？

2025-05-16 07:15:00 778

原创关于ALARP, GAMAB和MEM(二)

在上一篇《关于ALARP, GAMAB和MEM(一)》我们介绍过ALARP原则，这一期我们继续谈谈另外两种风险可接受性评估原则——GAMAB和MEM。顺便介绍下英国HSE发布的社会风险标准。

2025-05-12 07:15:00 882

原创关于ALARP, GAMAB和MEM(一)

我们在《ISO26262功能安全概述(一)》(ISO 26262 功能安全概述(一)-CSDN博客)一文中谈安全和风险的概念时提到过ALARP, GAMAB和MEM这三个词，有读者问到过这三个词是什么意思，今天这篇我们就谈谈这三个词背后的“故事”。安全问题最终都要转化成风险问题来评估，因为不存在绝对安全的系统，只能尽力做到“足够安全”（safe enough），而怎样才算safe enough?

2025-05-07 07:15:00 843

原创 ISO/SAE 21434对汽车意味着什么？

网络安全本身在其他行业，比如金融，IT行业已经是历史悠久，但对于汽车行业算是其安全领域的一个新合规方向，这是行业发展趋势的必然，生命毕竟要排在安全的第一考量，因为没有网络安全汽车的网联化没有什么价值可言，试想一下一辆声称具备高级别自动驾驶的车辆其网络安全没有保证的话你愿意掏钱购买吗？或者说你敢驾驶这样一辆车辆上路吗？

2025-04-28 07:15:00 669

原创功能安全之系统开发

Q: 什么样的系统设计是符合功能安全要求的？可以从以下方面评估所开发产品系统的功能安全要求满足性：所在系统层面的安全要求符合FSR故障处理机制符合FSC和SG系统层面的失效都有安全机制进行覆盖（单点、潜藏、共因）考虑通讯、供电、接口…考虑时间、精度…一定程度上考虑了硬件随机失效

2025-04-23 07:15:00 2282

原创 “万里长征”第一步-从SG到FSC

SG作为相关项顶层的安全需求，他是相关项最终要达成的在安全这块的“目的”，要实现这些目的就得将顶层的安全需求逐级分解，直到分解出在零部件层级用于具体实现的需求。谈完概念阶段的HARA我们算是开启了功能安全”万里长征“的旅程，接下来将开启安全需求“万里长征”的第一步——从SG到FSC。本期话题包含以下几部分：什么是FSR？如何从SG得到FSR？什么是FSC？

2025-04-14 00:12:41 1079

原创 Requirement & Concept 谁是谁的谁？

安全和非安全的能不能用一份输出物，硬件、软件阶段可不可以定义HSC、SSC这样的输出物之类的问题，理论上的答案都是可以的，取决于组织的成熟度、公司的组织架构以及组织具备自己的一套方法论的开发流程，只要能满足标准的要求，怎么输出、如何定义都是组织自己的事。

2025-04-11 07:15:00 904

原创 ASIL B vs ASIL D

大家都知道ASIL A, B, C, D对相关项系统的安全要求越来越高，类似IEC61508里的SIL 1,2,3,4 或ISO13849里的PL(a,b,c,d,e)，那么问题来了：Q1: ASIL B和ASIL D在设计上区别是什么？区别有多大？Q2: 做过ASIL D项目的”大神“是不是就比做过ASIL B的厉害？

2025-04-09 07:15:00 927

原创 ISO26262 中的HARA分析（下）

在上一篇《 ISO 26262中的HARA分析（上）》中我们谈了谈HARA分析的目的及步骤，笔者将其称为“HARA分析四步法”，并介绍了前面两步，讲了讲通过HAZOP进行危害识别，通过“Operating modes”，“Operational Situations”及“Environmental conditions ”来综合进行场景识别。接下来我们继续谈谈后面两步，即结合危害和场景进行风险评估，对分析结果进行整理，梳理出安全目标。

2025-04-02 07:15:00 1071

原创 ISO 26262中的HARA分析（上）

在前面的文章《功能安全管理之需求管理（落地篇）》一文中我们提到过功能安全中安全需求的追溯链，对该追溯链中SG(Safety Goal)怎么得到的在文中顺带提了下通过HARA分析来得到SG。SG作为顶层的安全需求，是主机厂在概念阶段的工作成果之一，其生成的过程是需要站在整车层级的角度来分析相关项需要达到什么样的安全目的，这就需要分析人员具备一定的整车系统架构知识及车辆动力学的一些知识，以“上帝视角”来审视相关项的风险问题。

2025-03-31 07:15:00 874

原创功能安全管理之需求管理（落地篇）

需求是产品开发工作的主线，产品整个生命周期各个阶段的工作都有需求的影子，所以能把各个阶段的需求整明白、写清楚、实现好、验证全，这侧面反映了组织具备了一定的成熟度，这种情况下整个功能安全管理工作的质量差不到哪去。

2025-03-26 07:15:00 931

原创功能安全管理之需求管理（标准篇）

需求提清楚了，项目开发起来神清气爽。需求提不清楚，项目开发起来一团乱麻。可见需求不仅得定义好还得管理好。个人觉得需求的编写和创建过程中“颗粒度”和“完整性”是困扰大家的两大问题，如果能把需求的这两个问题“完美地”处理好，那需求的其他属性/特性的满足及实现都是水到渠成的事。

2025-03-24 07:15:00 1204

原创 ISO26262的功能安全管理（三）

功能安全针对生产、运营、维护和报废的要求有哪些？功能安全对于传统的PFMEA和控制计划有什么特殊要求？本篇我们来聊一聊功能安全管理在生产、运营、维护和报废阶段的要求该如何满足标准的要求。

2025-03-22 18:30:00 709

原创 ISO 26262的功能安全管理（二）

要完整地证明产品实现了安全目标的要求，除了认可措施外, 还需进行验证评审，两者在关注对象和目标上有一些差异。GB/T34590—2017的其他部分也要求这些评审, 目的是验证相关的工作成果满足项目的要求, 以及与应用案例和失效模式相关的技术要求。Q: 想想在日常工作中你有用过哪些验证评审的方法？怎么称呼这种验证评审方法？

2025-03-21 07:15:00 964

原创 ISO 26262的功能安全管理（一）

项目实践过程中要详尽地写好一份安全档案并非易事，安全档案的编写是一项持续性的工作，伴随着开发、验证阶段的各项活动。组织在流程上需要提供良好的配置管理系统或方法以便安全档案更好、更准确的收集当前阶段的活动状态证据，这些证据的需要各个板块基于支持，比如系统、测试团队、质量等。输出物版本基本不动或频繁变动、人员变动、多变种项目、工具系统变更等等这些都会影响过程证据的收集。

2025-03-19 07:15:00 1340

原创 ISO 26262 功能安全概述(三)

从整个概述中的描述来看功能安全要做的就是一堆的“paper work”, 文档工作确实是功能安全的设计阶段的主要工作，但这只是“理论指导实践”的“理论”部分。标准要求的不仅是产品全生命周期的各个过程的活动都要有明确的规范及定义，还要求根据这些规范及定义来实施对应层级的设计，这是"实践"。除了这些还不够，还需要通过占据V模型“半壁江山”的验证环节来对各层级的开发、设计成果进行验证和确认，每一个过程都要有对应的文档输出，通过过程来把控结果，通过结果来反向验证过程，如此迭代完善。

2025-03-17 07:15:00 2581