# 安全扩展需求(Requirements on Safety Extensions) | 字段 | 内容 | |---|---| | **文档标题** | 安全扩展需求(Requirements on Safety Extensions) | | **文档所有者** | AUTOSAR | | **文档责任方** | AUTOSAR | | **文档标识号** | 670 | | **文档状态** | Final(正式发布) | | **所属 AUTOSAR 标准** | Classic Platform(经典平台) | | **所属标准版本** | 4.4.0 | --- ## 文档变更历史(Document Change History) | 日期 | 版本 | 变更人 | 变更描述 | |---|---|---|---| | 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 | | 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更;详细信息请参考 ChangeDocumentation | | 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更;详细信息请参考 ChangeDocumentation | | 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更;详细信息请参考 ChangeDocumentation | | 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 基于概念"Safety Extensions"的初始发布 | --- ## 目录(Table of Contents) 1. [引言](#1-引言) - 1.1 [范围](#11-范围) - 1.2 [文档约定](#12-文档约定) - 1.3 [指南](#13-指南) 2. [用例追踪](#2-用例追踪) 3. [需求追踪](#3-需求追踪) 4. [需求](#4-需求) - 4.1 [安全需求](#41-安全需求) - 4.2 [安全完整性等级](#42-安全完整性等级) - 4.3 [安全措施与安全机制](#43-安全措施与安全机制) - 4.4 [可追溯性与分配](#44-可追溯性与分配) - 4.5 [方法论与使用](#45-方法论与使用) 5. [支持的用例](#5-支持的用例) --- ## 参考文献 - **[1]** ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition http://www.iso.org - **[2]** Specifications of Safety Extensions `AUTOSAR_TPS_SafetyExtensions` - **[3]** Standardization Template `AUTOSAR_TPS_StandardizationTemplate` - **[4]** Requirements on AUTOSAR Features `AUTOSAR_RS_Features` - **[5]** Methodology `AUTOSAR_TR_Methodology` --- ## 1 引言 ### 1.1 范围 本文档收集了对 AUTOSAR 模型安全方面的需求,以及将其纳入 AUTOSAR 模板的要求。 安全扩展(Safety Extensions)的主要目标是支持作为 AUTOSAR 模板一部分的 AUTOSAR 系统的安全相关信息交换。这将为安全需求到 AUTOSAR 元素、安全措施和 AUTOSAR 安全机制的可追溯性奠定基础。它还将确保在系统设计、实现和配置期间可获得 AUTOSAR 元素的适当安全完整性等级(Safety Integrity Levels),并且它们可以作为约束检查的对象。 在本文档的上下文中,**功能安全机制**(functional safety mechanisms)是具体的产品部件,例如内存保护。它们被视为功能安全措施(functional safety measures)的专门化,后还包括流程步骤,例如评审。此定义与 ISO 26262-1 [1] 中给出的这些术语的定义一致。 本文档中收集的需求将由 AUTOSAR 安全扩展规范 [2] 来满足。 ### 1.2 文档约定 AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表,参见标准化模板的"Support for Traceability"章节([3])。 应使用 [TPS_STDT_00053] 中指定的义务表达的口头形式来表示需求,参见标准化模板的"Support for Traceability"章节([3])。 ### 1.3 指南 应引用现有的规范(以单一需求的形式)。与这些规范的差异被指定为附加需求。所有需求应具有以下属性: - **冗余性(Redundancy)**:需求不应在一个需求内或其他需求中重复。 - **清晰性(Clearness)**:所有需求应仅允许一种解释的可能性。使用的未在词汇表中的技术术语必须定义。 - **原子性(Atomicity)**:每个需求应仅包含一个需求。如果需求不能进一步拆分为更多需求,则该需求是原子的。 - **可测试性(Testability)**:需求应通过分析、评审或测试进行测试。 - **可追溯性(Traceability)**:在任何时候都应可见需求的来源和状态。 --- ## 2 用例追踪 下表引用第 5 章中指定的用例,并将其链接到相关需求。 > **翻译说明**:原文档的"Use Case Tracing"表较长,包含约 8 个用例,每个用例链接到多个需求(`RS_SAFEX_xxxxx`)。下表列出每个用例的代表性需求映射;完整表请参见原文 PDF 第 9-11 页。 | 用例 | 描述 | 由以下需求满足 | |---|---|---| | **[UC_SAFEX_00001]** | 在 AUTOSAR 系统的分布式开发中交换安全信息 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`(完整集合) | | **[UC_SAFEX_00002]** | 在 AUTOSAR 中管理安全需求 | `RS_SAFEX_00001` ~ `RS_SAFEX_00010` | | **[UC_SAFEX_00003]** | ASIL 约束检查 | `RS_SAFEX_00008`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00018`、`RS_SAFEX_00022` | | **[UC_SAFEX_00004]** | AUTOSAR SEooC 开发 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`(完整集合) | | **[UC_SAFEX_00005]** | 为 AUTOSAR 系统提供安全文档 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`(完整集合) | | **[UC_SAFEX_00006]** | 为 AUTOSAR 系统提供适当的安全机制 | `RS_SAFEX_00008`、`RS_SAFEX_00009`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00017`、`RS_SAFEX_00018`、`RS_SAFEX_00022`、`RS_SAFEX_00023` | | **[UC_SAFEX_00007]** | 观察应用的 ASIL 分解产生的约束 | `RS_SAFEX_00008`、`RS_SAFEX_00009` | | **[UC_SAFEX_00008]** | 获取 AUTOSAR 元素的 ASIL 信息 | `RS_SAFEX_00011` | --- ## 3 需求追踪 下表引用 [4] 中指定的需求,并将其链接到这些需求的实现。 | 需求 | 描述 | 由以下需求满足 | |---|---|---| | **[RS_BRF_02068]** | AUTOSAR 方法论应允许将安全属性分配给模型元素 | `RS_SAFEX_00001`、`RS_SAFEX_00002`、`RS_SAFEX_00003`、`RS_SAFEX_00004`、`RS_SAFEX_00005`、`RS_SAFEX_00006`、`RS_SAFEX_00007`、`RS_SAFEX_00008`、`RS_SAFEX_00009`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00017`、`RS_SAFEX_00018`、`RS_SAFEX_00020`、`RS_SAFEX_00021`、`RS_SAFEX_00022`、`RS_SAFEX_00023`、`RS_SAFEX_00024` | --- ## 4 需求 本章描述了驱动安全扩展规范 [2] 定义工作的所有需求。 ### 4.1 安全需求 #### [RS_SAFEX_00001] AUTOSAR 模型中可表达的安全需求 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全需求应通过 AUTOSAR 元模型在 AUTOSAR 模型和文档中表达。 | | **基本原理** | AUTOSAR 中所有需求(包括安全需求)及其规范项的一致规范和表示。 | | **用例** | [UC_SAFEX_00002]、[UC_SAFEX_00001] | | **依赖性** | – | | **支持材料** | 参见 ISO 26262-8 [1]。 | c(`RS_BRF_02068`) #### [RS_SAFEX_00002] 安全需求至少与其他需求一样具有表达力 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全需求至少应能够携带与 AUTOSAR 中其他需求相同种类的信息。此外,遵循 ISO 26262-8 中对需求管理的要求,参见 [1]。 | | **基本原理** | 像 ISO 26262 [1] 这样的安全标准定义了对安全需求定义的最低要求。此外,在 AUTOSAR 中使用类似结构对安全和非安全需求进行协调定义是可取的。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00003] 通过 URI 描述的安全需求 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以通过 URI 将 AUTOSAR 模型内的安全需求定义与该 AUTOSAR 模型外部的需求规范相关联。 | | **基本原理** | 实践中使用了多种需求交换的技术方法。这包括需求交换格式(ReqIF)或基于专有工具的交换。通过通过 URI 引用外部需求定义的可能性,可以在 AUTOSAR 模型中建立可追溯性,同时避免数据复制及其典型的负面影响。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00004] 可区分的安全需求 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全需求应可与 AUTOSAR 模型中的其他需求区分开来。 | | **基本原理** | 安全标准的规则仅适用于安全需求。例如,这适用于可追溯性或 ASIL 相关措施或约束。因此,有必要明确标识安全需求。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | 参见 ISO 26262-8 [1]。 | c(`RS_BRF_02068`) #### [RS_SAFEX_00005] 安全需求的唯一标识 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全需求应具有唯一标识。 | | **基本原理** | 这是满足安全标准要求的必要条件。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | 参见 ISO 26262-8 [1]。 | c(`RS_BRF_02068`) #### [RS_SAFEX_00006] 安全需求的状态信息 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以指定安全需求的状态。 | | **基本原理** | 这是满足安全标准要求的必要条件。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00004] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | 参见 ISO 26262-8 [1]。 | c(`RS_BRF_02068`) #### [RS_SAFEX_00007] 安全需求的层次结构 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以指定安全需求的层次结构。 | | **基本原理** | 这是满足安全标准要求的必要条件。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | 参见 ISO 26262-8 [1]。 | c(`RS_BRF_02068`) #### [RS_SAFEX_00008] 安全需求的分解 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以将安全需求分解为两个独立的安全需求。 | | **基本原理** | ASIL 分解是 ISO 26262 中提供的概念,通过将安全需求拆分为独立的安全需求来降低安全需求的 ASIL。ASIL 分解也应可用于 AUTOSAR 系统。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00007] | | **依赖性** | [RS_SAFEX_00010]、[RS_SAFEX_00001] | | **支持材料** | 参见 ISO 26262-9 [1] | c(`RS_BRF_02068`) #### [RS_SAFEX_00009] 独立性需求的规范 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以指定作为特殊安全需求的独立性需求,并将其与安全需求的分解相关联。 | | **基本原理** | 仅当可以确保具有较低 ASIL 的所得安全需求的独立性时,才允许 ASIL 分解。这导致对独立性的要求,这些要求显然与分解相关。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00007] | | **依赖性** | [RS_SAFEX_00001]、[RS_SAFEX_00008] | | **支持材料** | 参见 ISO 26262-9 [1] | c(`RS_BRF_02068`) ### 4.2 安全完整性等级 #### [RS_SAFEX_00010] 安全需求的 ASIL 属性 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以为安全需求指定 ASIL 属性。属性的值应至少以明确的方式携带 ISO 26262 中列出的可能 ASIL 值。 | | **基本原理** | 确保系统功能安全所需的必要措施取决于适用的 ASIL。ASIL 到系统元素的分配通过安全需求完成。未能遵守 ASIL 可能导致不安全的系统。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00008] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | 参见 ISO 26262-3 [1] | c(`RS_BRF_02068`) #### [RS_SAFEX_00011] AUTOSAR 元素的 ASIL 属性 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以为作为 AUTOSAR 模型一部分的任何 AUTOSAR 元素指定 ASIL 属性。属性的值应至少以明确的方式携带 ISO 26262 中列出的可能 ASIL 值。 | | **基本原理** | 这允许在安全需求和 AUTOSAR 元素之间交叉检查 ASIL 值。例如,这对于使用上下文外安全元素方法(SEooC)非常重要,参见 ISO 26262-10 [1]。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00008] | | **依赖性** | – | | **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] | c(`RS_BRF_02068`) ### 4.3 安全措施与安全机制 #### [RS_SAFEX_00015] AUTOSAR 模型中可表达的安全措施 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全措施应在 AUTOSAR 模型中可表达。 | | **基本原理** | AUTOSAR 提供了许多安全机制。它们应与 AUTOSAR 模型中的安全需求相关联,以证明安全需求的正确实现。此外,能够处理 AUTOSAR 外部但对 AUTOSAR 系统很重要的安全措施也很重要。通过对安全措施进行建模,它可以用作 AUTOSAR 模型中可追溯性的代理和终点。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00006] | | **依赖性** | – | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00016] 安全措施的文本描述 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全措施应至少具有文本描述。 | | **基本原理** | 文本描述提供了一种非正式的方式来描述安全措施。未来可能会定义其他形式属性。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] | | **依赖性** | [RS_SAFEX_00015] | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00017] 安全措施的唯一标识 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全措施应具有唯一标识。 | | **基本原理** | 安全措施是可追溯到安全需求的对象。没有唯一标识符,不可能建立这种可追溯性。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] | | **依赖性** | [RS_SAFEX_00015] | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00023] 作为特殊安全措施的安全机制 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全机制应在 AUTOSAR 模型中作为安全措施的专门化来表达。 | | **基本原理** | ISO 26262 区分了安全措施和安全机制,其中安全措施包括安全机制。该术语应反映在安全扩展中。(参见 ISO 26262-1,第 1.110 条 [1]) | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] | | **依赖性** | [RS_SAFEX_00015] | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00018] 安全需求和安全措施之间的关系 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以将安全需求与安全措施相关联。这样的关系应可与 AUTOSAR 模型中的任何其他关系明确区分开来。 | | **基本原理** | 为了证明系统安全,显式建模安全需求和安全措施之间的关系是有利的。这简化了文档编制并支持一致性检查(例如观察适用的 ASIL 相关规则)。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00006]、[UC_SAFEX_00005]、[UC_SAFEX_00004] | | **依赖性** | [RS_SAFEX_00015]、[RS_SAFEX_00001] | | **支持材料** | – | c(`RS_BRF_02068`) ### 4.4 可追溯性与分配 #### [RS_SAFEX_00012] 安全需求的可追溯性 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全需求应根据 ISO 26262 [1] 可追溯。 | | **基本原理** | 安全需求的可追溯性是像 ISO 26262 [1] 这样的安全标准的主要要求。直接在 AUTOSAR 模型中建立可追溯性可提高一致性并减少工作量。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00005] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | 参见 ISO 26262-8 [1] | c(`RS_BRF_02068`) #### [RS_SAFEX_00013] 安全措施的可追溯性 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全措施应根据 ISO 26262 [1] 可追溯。 | | **基本原理** | 可追溯性是安全标准的主要要求(参见 ISO 26262-8 第 6.4.3.2 条 [1])。安全措施是支持安全需求实现的活动或技术解决方案,包括 AUTOSAR 提供的安全机制。直接在 AUTOSAR 模型中建立可追溯性可提高一致性并减少提供安全文档的工作量。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00004]、[UC_SAFEX_00005] | | **依赖性** | [RS_SAFEX_00015] | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00014] 安全需求的分配 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以将技术安全需求分配给 AUTOSAR 模型的元素。这样的分配应可与 AUTOSAR 模型中的其他关系区分开来。 | | **基本原理** | 所有安全需求必须分配给硬件、软件或两者。那些要由 AUTOSAR 系统实现的安全需求应分配给相应的 AUTOSAR 元素。这是例如检查有关 ASIL 的约束或执行适当的安全分析的基础。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00005] | | **依赖性** | [RS_SAFEX_00001] | | **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] | c(`RS_BRF_02068`) #### [RS_SAFEX_00022] 安全措施的分配 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以将安全措施分配给 AUTOSAR 模型的元素。这样的分配应可与 AUTOSAR 模型中的其他关系区分开来。 | | **基本原理** | 安全措施信息元素描述了可由 AUTOSAR 系统实现的安全措施(例如 AUTOSAR 安全机制,如 E2E 通信保护)。在这种情况下,有必要将实现安全措施的 AUTOSAR 元素与安全措施信息元素相关联。这种关系的存在将简化所需的验证过程(与安全措施相关的安全需求),并支持约束检查(例如 ASIL 义务)。 | | **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005] | | **依赖性** | [RS_SAFEX_00015] | | **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] | c(`RS_BRF_02068`) ### 4.5 方法论与使用 #### [RS_SAFEX_00024] AUTOSAR 方法论解释安全扩展的使用 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 安全扩展的使用应由 AUTOSAR 方法论解释。 | | **基本原理** | 安全扩展可以促进通常在 AUTOSAR 系统开发期间执行的许多活动。AUTOSAR 方法论描述了这些活动。如果现有活动需要执行安全信息,或需要新的活动或任务来消费或生成安全信息,则应由方法论解释。 | | **用例** | – | | **依赖性** | [5] | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00020] 安全扩展不破坏 AUTOSAR 模型处理 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 使用安全扩展不应破坏现有 AUTOSAR 模型的处理。 | | **基本原理** | 安全扩展作为可与现有模型一起使用的扩展提供。这确保了向后兼容性。对于某些生成目的,可能不需要将安全扩展包含到生成过程中以节省资源。 | | **用例** | – | | **依赖性** | – | | **支持材料** | – | c(`RS_BRF_02068`) #### [RS_SAFEX_00021] 用于现有 AUTOSAR 模型的安全扩展 | 字段 | 内容 | |---|---| | **类型** | valid | | **描述** | 应可以为现有 AUTOSAR 模型指定安全扩展。 | | **基本原理** | 由于许多 AUTOSAR 系统与安全相关,这将允许通过安全扩展扩展现有 AUTOSAR 模型。 | | **用例** | – | | **依赖性** | – | | **支持材料** | – | c(`RS_BRF_02068`) --- ## 5 支持的用例 ### [UC_SAFEX_00001] 在 AUTOSAR 系统的分布式开发中交换安全信息 分布式开发是 AUTOSAR 系统的典型特征。对于最终系统(项目),必须证明其满足功能安全的需求。 与 AUTOSAR 系统相关的安全需求作为 AUTOSAR 模型的一部分在参与分布式开发的组织之间交换。安全需求还包含 ASIL 属性以及它们到 AUTOSAR 元素的明确分配。确保安全相关信息不会丢失。适当时建立可追溯性。最后,AUTOSAR 模型中包含许多用于系统安全文档的信息,并且可以加以利用。 c() ### [UC_SAFEX_00002] 在 AUTOSAR 中管理安全需求 在 AUTOSAR 中,所有需求都以唯一 ID 在需求文档(RS/Feature/SRS)中正式捕获。规范文档(SWS)包含正式追溯到需求的形式规范项。同一级别的需求之间的依赖关系通过提供对相关需求的引用在需求块本身中表达。安全需求(可能包括安全目标)被捕获在单独的安全需求文档中或与同一文档中的其他需求一起捕获。在两种情况下,在这些安全需求与安全相关的规范元素之间建立可追溯性。 c() ### [UC_SAFEX_00003] ASIL 约束检查 AUTOSAR 元素的 ASIL(即用于它们的开发)必须与为这些元素分配的安全需求的 ASIL 匹配。匹配意味着元素的 ASIL 等于或高于所分配的安全需求的 ASIL。在 AUTOSAR 模型中拥有所有信息(安全需求、ASIL、分配),可以执行约束检查以查找无效的分配。这在分布式开发或要集成现有组件的上下文中特别有用。 c() ### [UC_SAFEX_00004] AUTOSAR SEooC 开发 根据 ISO 26262-10([1]),上下文外安全元素(Safety Element out of Context, SEooC)的开发特征在于对 SEooC 环境的假设是在不知道 SEooC 所集成到的实际上下文(项目)的情况下做出的。这样的 SEooC 的开发人员将以安全需求的形式提供假设,并附带适当的 ASIL 和 AUTOSAR 模型中的状态信息。此外,将描述并提供安全措施 / 安全机制。集成商将利用这些信息执行 SEooC 所嵌入的环境满足假设的分析。同样,可追溯性、分配和映射关系在 AUTOSAR 模型中使用。 c() ### [UC_SAFEX_00005] 为 AUTOSAR 系统提供安全文档 OEM 可以使用 AUTOSAR 系统的 AUTOSAR 模型,并提取模型中关于安全需求、安全措施、它们到 AUTOSAR 元素的分配以及安全需求和安全措施之间的映射的信息,以创建 ISO 26262-8([1])所要求的安全文档。 c() ### [UC_SAFEX_00006] 为 AUTOSAR 系统提供适当的安全机制 OEM 可以在系统级别指定对安全机制的要求。在 ECU 级别工作的供应商可以提供此类适当的安全机制并建立所需的可追溯性。同样可能的是,AUTOSAR 堆栈(BSW 组件)的供应商提供并描述供应商特定的安全机制。由于安全机制的信息作为 AUTOSAR 模型的一部分交换,因此可用于验证过程。 c() ### [UC_SAFEX_00007] 观察应用的 ASIL 分解产生的约束 OEM 在其技术安全概念中应用 ASIL 分解。这对预期系统的软件组件的独立性有影响。有关应用的分解以及独立性要求的信息都由供应商作为 AUTOSAR 模型的一部分提交。供应商能够满足独立性要求,因为它们是明确已知的,并且由于可追溯性,验证要容易得多。 c() ### [UC_SAFEX_00008] 获取 AUTOSAR 元素的 ASIL 信息 被要求实现软件组件的供应商需要知道该组件的 ASIL,以便应用适当的开发过程。此外,需要实现的安全需求应该是已知的。这两个信息都使用安全扩展作为 AUTOSAR 模型的一部分进行交换。 c() --- ## 翻译说明 - **翻译完整性**:本文档为 AUTOSAR 安全扩展需求(RS)的中文翻译版本,完整翻译了 1-5 章全部内容。 - **保留的英文术语**:所有需求 ID(`RS_SAFEX_xxxxx`、`UC_SAFEX_xxxxx`、`RS_BRF_02068`、`TPS_STDT_xxxxx`)、模块缩写(OEM、ECU、BSW、E2E、SEooC)、安全标准引用(ISO 26262-1/3/4/6/8/9/10、ASIL)、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。 - **省略的内容**:免责声明(Disclaimer)按要求未翻译。 - **关键概念**: - **安全扩展**(Safety Extensions):AUTOSAR 模板的一部分,用于支持安全相关信息的交换和追溯。 - **ASIL**(Automotive Safety Integrity Level,汽车安全完整性等级):从 A 到 D 的等级,源自 ISO 26262。 - **SEooC**(Safety Element out of Context,上下文外安全元素):一种开发模式,安全元素在没有具体应用上下文的情况下开发。 - **安全机制**(Safety Mechanisms)是**安全措施**(Safety Measures)的专门化。 - **ASIL 分解**(ASIL Decomposition):将高 ASIL 需求拆分为具有较低 ASIL 的独立需求。