本文将结合本人的硕士论文选题，简要阐述对功能安全的理解，并以线控转向系统为例，探讨 Medini Analyze 工具在功能安全开发中的具体应用。

一、ISO 26262 标准

1.1 ISO 26262 标准 12 个部分整体架构

分类	部分编号	标准中文名称	核心定位	查用场景
核心过程类 （安全生命周期主线，产品开发的主干流程）	Part 3	概念阶段	项目安全起点，完成整车级危害分析与风险评估（HARA）、制定安全目标、输出功能安全概念	新项目立项、做HARA分析、定义安全目标、输出功能安全方案时
	Part 4	系统级产品开发	系统层面安全设计，将功能安全需求转化为技术安全需求，完成系统架构设计、集成与整车验证	系统级安全架构设计、技术需求分解、系统集成测试、整车安全确认时
	Part 5	硬件级产品开发	硬件层面安全设计与度量，覆盖硬件安全需求、架构设计、随机失效度量、硬件测试验证	硬件安全设计、计算SPFM/LFM/PMHF指标、硬件失效分析、硬件测试验证时
	Part 6	软件级产品开发	软件层面安全开发，覆盖软件安全需求、架构设计、安全编码、各层级软件测试验证	安全软件开发、软件架构设计、安全编码规范、软件单元/集成测试时
	Part 7	生产、运行、维护与退役	量产到报废全周期安全管控，保障生产不引入安全偏差，运维阶段维持安全功能	制定生产安全管控、售后维修流程、退役报废方案、运维安全要求时
支持类 （基础支撑与通用方法，保障核心过程合规落地）	Part 1	词汇	统一定义全标准的专业术语、缩写与概念，是整套标准的语义基础	遇到术语歧义、缩写含义不明、概念定义不明确时
	Part 2	功能安全管理	组织级+项目级的安全管理体系要求，覆盖全生命周期的管理活动	搭建安全管理体系、制定项目安全计划、划分安全职责、开展安全评审/审计时
	Part 8	支持过程	全生命周期通用支撑流程，含配置管理、变更管理、工具鉴定、文档管理、能力管理等	做工具置信度鉴定、配置管理、安全文档规范、变更管控、人员能力评估时
	Part 9	ASIL导向与安全分析	ASIL等级分解规则、各类安全分析方法（FTA/FMEA/DFA等）的详细要求	做ASIL分解、故障树分析、失效模式分析、相关失效分析、选型安全分析方法时
专项指南类 （特定领域适配指引，场景化补充参考）	Part 10	ISO 26262 实施指南	全标准的通用落地指引，对核心概念、流程方法补充解释与示例	对标准条款理解有歧义、需要落地示例、首次落地标准寻求方法论指导时
	Part 11	半导体应用指南	针对半导体器件的功能安全落地指南，适配芯片设计、制造、验证的特殊场景	芯片级功能安全开发、半导体器件安全认证、IP核安全评估时
	Part 12	摩托车适配规范	针对摩托车场景对标准的适配调整，匹配摩托车整车特性与风险场景	摩托车相关E/E系统功能安全开发、摩托车产品安全认证时

1.2 汽车安全完整性等级（ASIL）

1.2.1 评估维度

三大评估维度是危害分析与风险评估（HARA）的核心输入，每项分 4 个等级：

• 严重度（S）：故障导致的最坏伤害程度，从无伤害到危及生命递增
• 暴露率（E）：故障场景在车辆全生命周期内的发生概率 / 暴露频率
• 可控性（C）：驾驶员或相关人员通过干预规避伤害的能力

1.2.2 分级逻辑

由 S、E、C 组合查表得出等级，从高到低为：ASIL D > C > B > A > QM

• ASIL A~D：需按对应等级执行功能安全开发流程与技术要求
• QM（质量管理）：风险足够低，按常规质量流程开发即可，无强制功能安全专项要求

1.2.3 ASIL分解

• 核心原则：仅允许在冗余架构、子系统相互独立（无相关失效）的前提下，将高阶 ASIL 拆解为多个低阶等级，组合后安全完整性不低于原等级；必须通过相关失效分析（DFA）验证独立性。
• 适用场景：双路冗余、多传感器 / 控制器冗余架构，用于平衡安全要求与开发成本。

1.3 安全需求传递链

1. 安全目标（SG）：顶层整车级需求，源自危害分析与风险评估（HARA），对应危害事件的风险管控目标。例：避免车辆制动失效导致失控。
2. 功能安全需求（FSR）：由安全目标分解推导，聚焦系统 “要实现什么安全功能”，不涉及具体技术方案。例：制动主缸失效时，由备用回路提供制动力。
3. 技术安全需求（TSR）：由功能安全需求落地，明确 “具体怎么实现”，拆解为硬件、软件可执行的技术指标与约束，是开发与测试的直接依据。例：备用回路建压时间≤100ms，满足对应 ASIL 诊断覆盖率要求。

二、从危害分析到安全概念

2.1 ISO 26262-3 概念阶段

1. 相关项定义（Item Definition）
   • 内容：什么是 “相关项”；如何界定系统的功能边界、外部接口、运行环境、法律法规约束；强调这是所有安全分析的基础，边界模糊会导致后续分析全部失效。
2. 危害分析与风险评估（HARA）
   • 内容：HARA 的完整执行步骤；危害识别的常用方法（如 HAZOP）；风险场景的构建方法；S/E/C 三个维度的实操打分规则；从风险场景到 ASIL 定级的完整链路；附实操案例与常见定级误区。
3. 安全目标与功能安全概念
   • 内容：从危害场景导出顶层安全目标（Safety Goal），安全目标继承 ASIL 等级；功能安全概念（FSC）的核心要素：安全状态定义、容错时间间隔（FTTI）、安全机制框架、降级策略；多架构方案的安全评估与选型。

2.2 相关项定义

相关项是功能安全活动的最小分析单元，指实现一项或多项车辆功能的一个 / 一组 E/E 系统组合，例如整车制动系统、智能驾驶领航系统均可作为独立相关项。

2.3 危害分析与风险评估（HARA）

2.3.1 步骤

1. 输入承接：基于相关项定义，梳理全量功能与典型运行场景
2. 危害识别：枚举功能失效模式，识别潜在危害
3. 危害事件构建：将失效模式与运行场景组合，形成完整危害事件
4. 风险量化：对每个危害事件分别评定严重度（S）、暴露率（E）、可控性（C）
5. ASIL 定级：通过 SEC 组合查表确定对应安全完整性等级
6. 输出交付：导出安全目标并分配对应 ASIL 等级

2.3.2 危害识别常用方法

• HAZOP（危险与可操作性分析）：行业主流方法，通过「引导词 + 功能参数」系统枚举失效模式（如无功能、功能过度 / 不足、非预期触发、反向输出等），避免遗漏。

2.3.3 风险场景构建方法

遵循失效模式 + 运行场景 + 危害后果三要素原则，场景需明确车速、道路类型、交通环境等边界，例如：“高速直行车道行驶时，EPS 转向助力意外锁死，导致车辆偏离车道”。

2.3.4 S/E/C 打分规则

每个维度按风险程度分级，是 ASIL 判定的量化基础：

• 严重度（S）：S0（无伤害）→ S1（轻中度伤害）→ S2（重伤 / 生命危险）→ S3（致命 / 危及生命）
• 暴露率（E）：E0（几乎不可能）→ E1（极低概率）→ E2（低概率）→ E3（中等概率）→ E4（高概率，日常高频场景）
• 可控性（C）：C0（完全可控）→ C1（简单可控）→ C2（通常可控）→ C3（难以控制 / 不可控）

2.3.5 ASIL定级

将 S、E、C 等级代入标准判定矩阵直接得出等级：

• 任一维度为 S0/E0/C0 → 直接判定为QM（仅需质量管理，无强制功能安全要求）
• 风险组合从低到高对应 ASIL A → B → C → D，最高风险组合 S3+E4+C3 对应 ASIL D
• 示例：
  危害事件：高速公路行驶中，制动助力完全失效，车辆无法正常减速
  • 严重度 S：S3（高速追尾易造成致命伤害）
  • 暴露率 E：E3（高速工况占日常驾驶一定比例）
  • 可控性 C：C2（驾驶员可通过降档、手刹辅助避险）
  • 定级结果：ASIL C

2.4 安全目标与功能安全概念

2.4.1 安全目标（Safety Goal, SG）

• 由 HARA 输出的危害事件推导而来，是整车层面的顶层安全要求，继承对应危害事件的最高 ASIL 等级。
• 只描述 “要达成的安全结果”，不涉及具体实现方案，例如：“避免制动系统非预期失效导致车辆失控”。
• 一条安全目标可覆盖多个同类危害事件，取其中最高 ASIL 作为目标等级。

2.4.2 功能安全概念（FSC）核心要素

功能安全概念是安全目标到系统设计的桥梁，定义实现安全目标的顶层策略，核心包含 4 个要素：

• 安全状态定义：故障发生后，系统必须进入的无不可接受风险的稳定状态，如扭矩限制、跛行模式、功能安全下电等。
• 容错时间间隔（FTTI）：从故障发生时刻，到系统必须进入安全状态的最长允许时间，是所有安全机制响应速度的核心约束。
• 安全机制框架：覆盖故障检测（诊断、校验）、故障响应（切换冗余通道、触发降级）、故障告警（提示驾驶员）的完整策略。
• 降级策略：故障发生后功能逐步退化的逻辑，优先保留核心安全能力，逐步关闭非必要功能。

三、安全需求的架构落地

1. 技术安全需求规范（TSR）
   • 内容：从功能安全概念导出可落地的技术安全需求；需求的颗粒度要求与可验证性原则；安全机制在系统层面的定义（如故障检测、故障响应、故障隔离）。
2. 系统架构设计与安全分析
   • 内容：系统安全架构设计的核心原则（冗余、隔离、降级）；两大核心分析方法的系统级应用：
     • FTA（故障树分析）：自上而下的顶事件拆解，定位失效根因
     • FMEA（失效模式与影响分析）：自下而上的失效影响评估
   • 共因失效（CCF）与依赖分析，如何避免单点失效引发连锁安全问题。
3. 系统集成与安全验证
   • 内容：V 模型右侧的系统集成策略；系统级测试的核心类型（功能测试、故障注入测试、HIL 硬件在环测试）；安全确认（Safety Validation）的目标 。

3.1 技术安全需求规范（TSR）

TSR 必须严格追溯至上层的功能安全需求与安全目标，形成完整的需求追溯链。

• 上层输入（示例）
  • 安全目标（SG）：SG-001 防止车辆行驶中高压回路意外断开导致动力突然丢失（ASIL B）
  • 功能安全需求（FSR）：FSR-001 当高压互锁回路发生异常断开时，系统应在容错时间内进入安全状态，避免动力非预期中断
• TSR 导出逻辑：把 “异常断开识别”“安全状态执行”“时间约束” 等抽象功能要求，拆解为可落地的技术参数、接口定义、性能指标。
  导出后的 TSR 条目（示例）
  • TSR-001：VCU 应周期性采集高压互锁回路的导通状态，采集周期不大于 10ms
  • TSR-002：当高压互锁回路等效电阻＞100Ω 时，系统应判定为互锁故障
  • TSR-003：故障判定后，VCU 应在 50ms 内向 BMS 发送高压下电指令，同时触发仪表一级报警
  • TSR-004：高压互锁检测电路需满足 ASIL B 等级的单点故障度量要求

3.2 需求颗粒度与可验证性原则

ISO 26262 要求所有安全需求必须具备可验证性，即可以通过测试、分析、评审等方式明确证明 “需求已被满足”。

• 反例（不合格需求）：系统应可靠检测高压互锁故障
  • 问题：无量化指标、无判定阈值、无法设计测试用例，属于模糊描述
  • 正例（合格需求）：在 - 40℃~85℃工作温度、12V 电源电压 9~16V 范围内，VCU 对 HVIL 回路开路故障的识别准确率≥99.9%，识别时间≤20ms
• 特点：明确边界条件、量化指标、可通过环境试验 + 故障注入直接验证
• 每条 TSR 通常附带固定属性：需求 ID、ASIL 等级、追溯至的 FSR/SG、验证方法（测试 / 分析 / 评审）、需求版本、责任人。

3.3 系统层面的安全机制定义

TSR 阶段需要明确系统级的安全机制框架，不涉及软硬件具体实现，只定义 “系统要具备什么安全能力”，通常可分为三类：

安全机制类型	标准要求	HVIL 系统示例
故障检测	对可能导致安全目标违反的失效，需具备可检测性	1. 周期性检测互锁回路导通电阻 2. 对采样电压进行合理性校验（范围 0~5V） 3. 检测采样电路自身的开路 / 短路失效
故障响应	检测到故障后，需在容错时间内进入安全状态	1. 一级故障：仪表声光报警，限制电机功率至 50% 2. 二级故障：50ms 内执行高压下电，车辆进入跛行模式 3. 故障码存储，支持售后读取
故障隔离	单点故障不得扩散至其他安全相关功能	1. HVIL 采样电路与高压动力回路物理隔离 2. 采样电路故障不得影响 VCU 核心控制功能 3. 单路采样失效不导致系统误下电

3.4 系统架构设计与安全分析

1. FTA（故障树分析）：自上而下定位根因
   FTA 以 “违反安全目标的顶事件” 为起点，逐层拆解失效路径，用于识别单点故障、多点故障，计算故障发生概率。
   • 顶事件：行驶中高压意外断电导致动力突然丢失（违反 SG-001）
     简化拆解示例
   • 简化拆解示例

   顶事件：动力突然丢失
   ├─ 中间事件1：HVIL系统误判故障并触发下电
   │  ├─ 底事件：VCU采样电路短路（单点故障）
   │  ├─ 底事件：软件故障导致误判
   │  └─ 底事件：CAN总线干扰导致BMS信号错误
   ├─ 中间事件2：HVIL真实故障但未被检测到
   │  ├─ 底事件：两路采样电路同时失效（共因失效）
   │  └─ 底事件：故障处理逻辑卡死未执行
   └─ 中间事件3：接触器意外断开
   	└─ 底事件：接触器控制线圈断路	
   

2. FMEA（失效模式与影响分析）：自下而上评估影响
   系统级 FMEA 从每个组件的失效模式出发，分析其对上层系统、整车安全的影响，匹配对应的安全机制。

组件	失效模式	失效原因	局部影响	整车级影响	严重度	安全机制
VCU 采样电阻	开路	焊接不良、应力断裂	采样电压恒为 5V，误判为回路正常	HVIL 真实断开无法检测，违反安全目标	8	双路冗余采样；采样电压合理性校验
VCU 采样电阻	短路	引脚连锡、绝缘破损	采样电压恒为 0V，误判为回路断开	正常行驶中误触发高压下电，动力丢失	7	双路采样表决机制；单路故障仅报警不下电
互锁线束	接触电阻增大	连接器松动、氧化	回路电阻缓慢上升	临界状态下故障误报，动力受限	5	设置两级报警阈值；渐进式降级策略
光耦隔离芯片	失效	过压击穿、老化	高低压侧信号中断，采样值固定	故障无法检测或误报	6	定期自检光耦导通特性；诊断覆盖

3.5 共因失效

• 共因失效指一个共同原因导致多个独立组件同时失效，是冗余架构的核心杀手，也是系统分析的重点。
• HVIL 场景典型 CCF 风险：两路 HVIL 采样电路共用同一个 12V 电源，当电源出现过压、掉电时，两路采样同时失效，冗余设计完全失效。

四、实操

本章实操需使用menidi软件

4.1 项目定义

1. File → New Project
   

2. 选择完成后，下图为相应的目录结构
   
   3.首先进行项目定义 Item Definition
   

   1. 定义系统功能（Functions）
      • 根据驾驶员方向盘的输入转角，控制前轮/后轮转向
      • 向驾驶员手部提供模拟的路感反馈
   2. 定义系统边界（Boundary）和系统组成
      1. 内部：
         • 方向盘转角传感器 (Steering Wheel Angle Sensor)
         • 路感模拟电机 (Feedback Motor)
         • 线控转向控制器 (SbW ECU)
         • 转向执行电机 (Steering Actuator Motor)
         • 连接上述部件的内部线束
      2. 外部：
         • 驾驶员 (Driver)
         • 车辆的 12V/48V 供电电源 (Power Supply)
         • 整车 CAN/FlexRay 通讯网络
         • 整车控制器 (VCU) 或 智驾控制器 (AD ECU)
         • 轮胎和路面。
   3. 定义接口（Interfaces）
      • 物理/机械接口： 转向机与车架的硬点连接
      • 电气接口： 电池给 SbW ECU 供电的电源线。
      • 通讯接口： SbW ECU 通过 CAN/Ethernet 接收 VCU 发送的车速信号。
   4. 右键Item Definition → New → Item
      
      1. 可添加外部链接 External Link...
      
      2. 选择 External Document 可以添加适用于项目特定的文件
      
      已添加后
      
      3. 在Medini在项目中任意选择一个源元素和目标元素创建跟踪关系。选中下图的两个元素，右键，点击Link with Trace，即创建号两个元素的跟踪关系
      
      此时后面会出现该元素与多少个目标元素有跟踪关系
      

3. 创建系统功能模型来描述项目架构

   1. 右键Item Definition → New → System/Function Model
      

   2. 右侧的工具面板可拖拽需要元素到白色区域或者一个元素上（需要组成嵌套软件的话）
      

   3. 拖拽右侧的System（需要注意元素上的端口符号则表示实际中的接口）
      

   4. 模块类别

      • System
      • Controller
      • Actuator
      • Sensor
      • Component (组件) / Part (普通部件)

   5. 完成线控转向系统搭建
      

   6. 定义功能

      1. 右击Item Definition，在 New 的右边选项框中选择 System/Function Model 选项，输入和顶层架构有所区别的名称进行创建
         

      2. 右击创建好的功能架构，在 New 后面创建 Package 功能包，然后在功能包里创建功能(Function)
         
         在每个Pack下面创建Function
         
         创建所有的功能并补充相应描述
         

      3. 创建功能间的依赖关系网。右键Function → Show Dependency Net，打开依赖关系网编辑器
         

      4. 首先要根据各功能间的一个逻辑关系来选择左边的一个关系类型

         • Requires（必需依赖）
         • Uses（使用 / 调用依赖）
         • Allocate（分配 / 部署关系）
         • Other（其他 / 自定义依赖）
           

      5. 还需要将创建的相关功能分配到顶层架构中。继续右键功能（Function）选择Allocation Elements选项
         
         根据功能的实际情况分配到它所处的架构元素中
         

      6. 至此完成项目的定义工作

4.2 HARA 分析

1. 在进行HARA分析之前先创建引导词（Guideword）模板，为HARA分析。创建Guideword模板的目的是为了提供一套指导原则，帮助分析人员在进行HARA过程中更加系统和全面地识别潜在的危险情况

2. 右键 SbW_Syatem_Project → ProjectSettings
   

3. 打开界面中选择Guideword Templates
   
   
   关键词也可支持通过 Excel 文件的形式进行导入

4. 右击Hazard Analysis and Risk Assessment，在New选项后面选择GuideWord Analysis，在弹出的窗口中选择我们要使用的引导词模板
   

5. 正确填写
   

6. 还需创建一个操作情况目录，和创建引导词的步骤相似
   
   选择下图中的 Operational Situations Catalogs（注意在这个步骤的操作把定义ASIL等级三大要素之一的Exposure暴露率已确定进去了）
   
   

7. 完成上故障情况和操作请开给你梳理完毕后，就开始危害分析了。右击Hazard Analysis and Risk Assessment 在 New 选项后面，选择Hazard Analysis
   

   1. 将下方的相关情景从目录中拖放到上方的HARA表中
      
   2. 将下方的情景从下面拖到上面
      
   3. 将情境和故障情况进行结合，我可以在表中的Malfunctioning Behaviour的空白处双击添加我们各功能下的故障情况，也可以将故障拖入到表中
      
      
      
   4. 注意，这个步骤的操纵把定义ASIL等级三大要素之一的Controllability可控率就已经确定了（即可清楚地分析处在某个情景下出现某个故障情况会导致哪些危害）
      
      
   5. 需要在Hazards表中创建危害情况。打开Hazards表点击右边的按钮添加若干条危害情况
      
   6. 危害情况填写完毕后回到HARA表中将这些危害情况拖入到Hazard列
      
      

8. 这个操作后可将定义ASIL等级三大要素之一的Severity的危害程度即可确定
   

9. 上面三个重要要素均完成后，medini会根据每一条HARA表中的S、E、C值自动推算出其ASIL等级
   

4.3 安全目标

1. HARA分析后就需要为每一个具有ASIL等级的危害事件指定一个安全目标
2. 右击Safety Goals and Requirements，在New后面选择Requirements Model，创建一个空白的安全目标模型
   
3. 将安全目标拖入到左侧的面板中，即完成了一条安全目标的创建
   
   
4. 注意，也可以通过安全目标表格编辑器的方式来创建安全目标
   
   1. 在创建完毕的安全目标模型右键选择Open With，在选择Safety Goals List Editor，就可以通过编辑器的方式快速完成安全目标的创建
      
5. 当我们的安全目标建立完成后就需要确定相应的功能安全需求
   1. 回到之前的面板中将右边工具栏中，将功能安全需求拖放到安全目标上
      
   2. 以推导ASIL并创建贡献关系。注意当我们把一个功能安全需求拖放到另一个功能需求上时，创建的关系是为子要求关系(可将子模块放到父模块的上面，即可连线)
      
   3. 同时也可以通过功能需求表格编辑器来创建编辑需求
      
6. 另外，Medini也支持ASIL等级自动分解操作，对咬进行ASIL等级分解的功能安全需求上点击，在弹出的窗口中选择Decompose，根据实情况分解成两个不同等级的功能安全需求
   
7. 最后回到HARA表中，将我们布置好的安全目标拖至Safety Goal列