ISO26262 Part 6 之 软件架构设计颗粒度

原创 已于 2024-08-05 10:27:51 修改 · 580 阅读 · 10 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#安全

于 2024-08-05 10:27:06 首次发布

1. 标准要求

1.1 标准ISO 26262 Part6 – 7.4.4针对软件架构设计的颗粒度描述如下：

  • 7.4.4 The software architectural design shall be developed down to the level where the software units are identified.
    7.4.4 软件架构设计应被开发到能够识别出软件单元的程度。

1.2 标准ISO 26262 Part6 – 7.4.6针对软件安全需求的分配到的颗粒度描述如下：

  • 7.4.6 The software safety requirements shall be hierarchically allocated to the software components down to software units. As a result, each software component shall be developed in compliance with the highest ASIL of any of the requirements allocated to it.
    7.4.6 软件安全要求应按层次分配给软件组件,直至软件单元。因此,每个软件组件应按照分配给它的任何需求的最高的ASIL等级来进行开发。

其中，针对Software unit软件单元的定义为：

software unit
atomic level software component (3.157) of the software architecture (3.1) that can be subjected to stand-alone testing (3.169)
软件单元
软件架构(3.1)中的最低层级且可被独立测

最低0.47元/天 解锁文章
ISO26262 Part6 之 软件测试安全汇总详解
Aleeex_Zhao的博客
08-06 1105
如V model中所示，软件阶段包括：6-9 Software unit verification6-10 Software integration and verification6-11 Testing of the embedded software 为了提高测试效率及合理性，可以对测试进行分组 数据流的分析可以包括被0除，不可达的路径，死循环，数值越界等 等价类：在连续的信号，如车速，可以分为低速，中速，高速，分别抽一个点来测试； 边界值 参考B
ISO26262 Part 9 之 DFA的输入确定方法
Aleeex_Zhao的博客
08-06 1297
在进行DFA分析的时候，可基于演绎分析法,例如,割集检查或者FTA中重复的相同事件。,例如,在FMEA中多次出现的具有相似失效模式的相似元器件或组件。GB/T34590.11—2022的4.7。
ISO 26262-6 Part 6_Product development at the software level
09-30
ISO 26262-6 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment.
ISO26262 Part 6 之 软件集成和验证
Aleeex_Zhao的博客
08-05 647
在此子阶段,按照软件架构设计,对软件要素之间特有的。软件要素的集成和验证的步骤直接对应着软件的分层架构。
ISO26262 Part 6 之 文档管理
Aleeex_Zhao的博客
08-05 343
应计划文档管理过程，以获得文档：– 用于在整个生命周期的每个阶段中有效完成各阶段及验证活动；– 用于功能安全的管理；– 作为认可措施的输入；
ISO26262 Part 6 之 软件架构设计的验证Verification
Aleeex_Zhao的博客
08-05 440
a) 软件架构设计满足对应ASIL等级的软件安全要求;（架构设计本身）b) 软件架构设计的评审或研究能够为设计满足对应;（支持软件安全需求）c) 与目标环境的兼容性;注:目标环境是指软件运行的环境,包含了操作系统、基础软件以及在7.4.13中详细描述的目标硬件及其资源。d) 与设计指南保持一致。
汽车电子功能安全标准ISO26262解析（五）——FTA
pianpian_zct的博客
01-11 8799
Evaluation of safety goal violations due to random hardware failures. FTA是用来验证随机硬件失效导致的违背安全目标。 The objective of the requirements in this clause is to make available criteria that can be used in a ra...
DO-254与ISO 26262对比分析：航空与汽车功能安全异同点深度解读（跨行业合规必知的6大差异维度）
# DO-254 与 ISO 26262：功能安全标准的跨行业碰撞与融合 在波音787驾驶舱内，一块小小的FPGA芯片正默默执行着飞行控制逻辑——它必须在零下55℃的高空、强电磁干扰和宇宙射线轰击下依然保持100%正确。而在千里之外...
跨部门BOM协同破局之道：化解研发、采购、生产鸿沟的6大机制设计
[跨部门BOM协同破局之道：化解研发、采购、生产鸿沟的6大机制设计](https://sarci.in/wp-content/uploads/2020/01/bom-sourcing-1.png) # 1. 跨部门BOM协同的挑战与本质 在复杂产品开发体系中，BOM不仅是物料清单，...
听飞哥聊聊ISO 26262的那些事儿
认真你就输了
07-13 2824
这篇文章想从系统开发的角度，聊聊汽车功能安全相关的话题。汽车目前几乎是我们社会中部署最广泛的和最复杂的系统。然而实际上，驾驶员的培训往往只是驾驶过程中可能遇到的各种情况的最小集合，而汽车却变的愈发的复杂。目前，随着互联及自动驾驶车辆的部署，这些对驾驶员及人身安全相关系统提出了进一步的挑战。
ISO 26262 and ECU Software with Autosar 软件架构概述（英文）
07-28
该文档是博主初次接触AutoSAR时，同行分享的学习资料，现在分享给刚入门的同行参考，该文档主要包含以下信息： 1）ISO 26262 软件策略 2）IS0 26262涵盖的失效模型 3）ISO 26262 解决方案和建议
iso26262硬件层面设计 高清中文电子版-
01-31
iso26262硬件层面设计 高清中文电子版-
基于ISO26262的软件架构设计要求
小鱼仙倌的博客
07-27 1916
记住重点一：软件架构设计的目的是划分软件层次结构，确定软件各模块及模块之间的相互关系。 记住重点二：软件架构设计应与软件需求形成双向追溯关系，确保软件需求实实在在落实到设计里。 记住重点三：ISO26262中对软件架构设计提出了一系列如下规则，按照不同的SIL等级可以选择使用。 对于强烈推荐的内容，在实际开发过程中应保证完全遵循与使用，如果有些规则没有运用到，需要给出合理的解释与证明，证明即使没有使用这项规则，依然可以通过其他方式保证功能安全性。 关于这些规则的运用，很多同学也是充满迷惑。例如，适宜的软件
电子电气架构 --- 基于ISO 26262的车载电子软件开发流程
Soly_kun的博客
09-16 1931
电子电气架构 --- 基于ISO 26262的车载电子软件开发流程
MUNIK解读ISO26262--系统架构
m0_61714886的博客
07-05 1468
通过在设计阶段就充分考虑安全需求，采用分层的安全策略，设计安全关键组件，以及进行严格的安全验证和确认，可以有效地提高系统的安全性。个模块之间少不了有通讯或者系统层级需要有程序的烧录等情况出现，模块可能会通过CAN，CAN-FD，UART，I2C，SPI，PHY等进行片内或片外、板内或板外的通讯或者程序的烧录，下面以串口UART举例说明通讯模块的安全机制都有哪些。综上所述，系统架构设计是我们在产品开发中不可忽视的重要阶段，下面我们着重探讨“系统的架构类型”和“系统架构层级相关的安全机制”。
敏捷管理（2）- 敏捷价值、需求、估算、计划、监控、风险管理
Su_Levi_Wei的博客
11-22 3772
敏捷的工作价值 在Scrum的工作流程图中可以看到，PO的主要职责是排列用户故事的优先级，确保价值最优，不会落后于市场，所以敏捷讲的是价值驱动交付。 合理的项目是要保证产生商业价值，并去创造收益或提高服务品质。在每一个组织所选择的项目中，没有一个项目是不会带来价值的。价值可以是经济上的价值，也可以是提升了组织能力的价值，如品牌知名度等。在商业价值中，项目的安全性和合规性可以用商业风险和无法承担的影响来理解。所以，如果做项目的原因是创造价值，那么价值驱动的交付必须贯穿于整个项目规划、执行和监控工作中..
【软件体系结构】重用的粒度的定义
柳婼 の blog
11-15 1630
软件重用是指在两次或者多次不同的软件开发过程中重复使用相同或相近软件元素的过程。软件元素包括程序代码、测试用例、设计文档、设计过程、需求分析文档甚至领域知识。通常，把这种可重用的元素称为软构件，课重用的软件元素越大，我们就说重用的粒度（granularity）越大。
ISO 26262国际安全规范简介及其应用
热门推荐
选择的专栏
11-25 1万+
近年来，汽车电子产业开始发现系统失效的问题，一旦发生失效，就有可能导致乘客生命安全受到威胁，而车辆厂商也将面临官司赔偿与商誉受损的巨大风险。为防止系统失效的发生，必须有一套严谨且可靠的开发流程来让系统开发工程师依循，因此车辆领域专家们开始着手开发车辆领域的功能安全标准，ISO 26262便在此环境与需求下应运而生。
框架设计的粒度
supeng686的专栏
04-18 600
    框架设计的粒度到底应该划分的多细是一个需要考虑的问题，当然根据不同的项目所需要划分的粒度也不相同。这边文章只是为了记录此时此刻的思想，希望各位csdn上的牛人看过之后不要群起而攻之。    先拿一个常见的OA中的权限管理举例，常规的设计方式无非就是权限、角色、人这三层，关系如下： 那么这样的权限设计是可以基本满足一个OA的需要的，那么只需要做一个Filter去进行权限的控制就O
解释ISO 26262标准中“软件架构设计”（Software Architectural Design）的概念，并说明其在软件开发中的作用。
最新发布
06-11
<think>嗯，用户这次的问题很明确，是关于ISO26262中软件架构设计的专业内容。虽然引用的材料有点杂乱（夹杂了功能安全和心灵鸡汤的混合体），但核心诉求很清晰：理解软件架构设计在功能安全标准中的定位和作用。用户可能是个汽车电子领域的工程师，正在学习ISO26262标准。ta特意强调要关注软件架构部分，说明可能遇到了具体的设计或审核需求。有趣的是前文讨论的PMHF是硬件指标，现在转向软件架构，可见用户需要的是系统级安全知识整合。从专业角度，这个问题需要拆解三层回答：先明确ISO26262对软件架构的特殊要求（区别于普通软件架构），再说明具体设计方法（半形式化描述等），最后落脚在安全机制实现（如监控层设计）。特别要注意用户提供的引用[3]提到的形式化方法，这个在安全关键系统里越来越重要。用户引用的材料里有个关键线索：fail-operational/fail-silent架构模式。这其实是回答的突破口，可以结合故障处理策略来说明架构设计如何承载安全需求。另外必须关联前文提到的ASIL等级，不同等级对软件架构的要求差异很大。需要警惕的是用户给出的引用[1]内容混杂了非技术内容（“屏蔽力”那段明显是误贴），但正好可以忽略无关信息专注技术点。反而引用[2]的架构分类图和引用[3]的形式化方法描述才是真正的答题依据。最后准备在回答时强调两个实际案例：监控层设计（针对潜伏故障）和分区机制（防止级联失效），这都是车载软件架构的核心安全特性。安全机制覆盖率（前文讨论的DC值）其实也适用于软件层，这点可以埋个伏笔。</think> 以下基于ISO 26262标准，解析**软件架构设计概念及作用**，结合系统安全目标与开发流程说明： --- ### 一、软件架构设计的核心目标 软件架构设计需实现**故障控制与安全约束**的双重目标： 1. **故障抑制机制** - 通过分层设计隔离故障传播，如监控层（Monitoring Layer）检测应用层异常 - 示例：$ \text{监控层覆盖率} \geq 99\% \rightarrow \text{残余风险} \lambda_{\text{res}} <10^{-8}\,/\text{小时} $[^1] 2. **安全机制载体** 架构需内置安全机制（如E2E保护、逻辑监控）以满足ASIL目标： - ASIL D要求：**单点故障度量（SPFM）≥99%**，潜伏故障度量（LFM）≥90%[^2] - **冗余架构示例**： $$ \text{主通道} \xrightarrow{\text{比较器}} \text{安全状态} \quad vs. \quad \text{副通道} \quad (\text{Fail-Operational架构}) $$[^2] --- ### 二、关键设计方法（ISO 26262 Part 6） #### 1. **形式化/半形式化描述** - **形式化**：使用数学语言定义组件交互逻辑（如有限状态机模型） ```mermaid stateDiagram-v2 [*] --> Normal Normal --> Error : λ_fault ≥ 10^{-9} Error --> SafeState : DC ≥ 99% ``` - **半形式化**：UML时序图描述安全监控流程（监控周期 $ T_{\text{mon}} \leq 100\text{ms} $）[^3] #### 2. **安全机制融合设计** | 机制类型 | 架构实现方式 | 典型覆盖率 | |----------------|-----------------------------|------------| | 逻辑测试 | 任务层添加运行时自检 | DC=85~95% | | 数据校验 | 通信层增加CRC32/E2E保护 | DC≥99% | | 冗余执行 | 双核锁步（Lockstep） | DC>99.9% |[^1] --- ### 三、对功能安全的支撑作用 1. **量化安全达标** 架构设计直接决定安全机制的有效性： $$ \text{PMHF} = \sum(\lambda_i \times (1 - \text{DC}_i)) < 10\,\text{FIT} $$ **DC值提升1% → PMHF降低可达20%**（高失效率元件）[^1] 2. **防御共因失效（CCF）** - 采用**空间隔离**（如内存分区保护） - 时间隔离（关键任务与非关键任务分离调度） $$ \text{任务优先级：安全监控} > \text{功能任务} $$[^3] 3. **安全状态转换保障** 通过架构层定义**故障响应路径**： ```plaintext 检测故障 → 触发安全机制 → 进入安全状态（Fail-Silent） ``` --- ### 四、典型架构模式与安全等级适配 | 架构类型 | 适用ASIL等级 | 特点 | 实现示例 | |-----------------|--------------|--------------------------|-----------------------| | Fail-Silent | ASIL B/C | 故障即停机 | 关断电源模块 | | Fail-Operational| ASIL D | 故障时备份系统接管 | 冗余转向控制ECU | | Degraded Mode | ASIL C/D | 功能降级维持基本安全 | 制动系统仅保留ABS功能 |[^2] --- ### 总结：软件架构的核心作用 > **转化安全需求为可执行方案，通过分层防护、冗余控制与形式化建模，实现残余风险概率（PMHF）与单点故障防护（SPFM）的硬性指标[^1][^2]** --- **相关问题** 1. 如何在软件架构设计中平衡**实时性要求**（如AUTOSAR OS周期）与**安全监控延迟**？ 2. 采用模型形式化描述时，如何验证**软件架构模型**与**安全需求**的一致性？ 3. 混合ASIL等级系统中（如ASIL D模块+QM模块），**分区隔离机制**需满足哪些条件？ 4. 如何通过软件架构设计降低**多点失效**（MPF）导致的系统性风险？
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值