作者|booksoser

来源|汽车电子硬件设计

e.3.执行分析的主题

软件架构设计提供高级规则和决策(例如。组件的功能安全分类，组件之间的访问规则)，支持实现和论证功能安全的实现。

实现有意义分析的共同主题取决于：

Ø 分析的目标-见E.3.1；

Ø 范围和边界-见E.3.2；

Ø 用于进行分析的方法-见E.3.3；和

Ø 支持分析的有意义、客观和严谨的手段或标准-见E.3.4。

E.3.1确定分析目标

目标由(软件架构设计)和(Analysis of dependent failures)和(Safety analyses)提供。

示例：违反在分析范围内分配给软件的安全相关功能或属性，如健壮性或确定性执行。

E.3.2确定待分析的具体架构设计的范围和边界

根据分析的目标，确定范围，并将重点放在架构设计的相关部分。

分析的范围可以受到以下影响：

Ø 相关的交付范围和DIA中定义的各自责任；

Ø 分析的具体目标；

Ø 由“良好”设计原则支持的架构策略；或

Ø 架构设计所要求的属性，这是由于更高层次的安全概念，在实现免受干扰或充分独立方面。

示例1适当的端到端数据保护机制可以用作一个论点，即在安全分析期间考虑与外部发送者或接收器交换安全相关数据时，基本软件可以被视为“黑匣子”。

示例2具有操作模式的软件函数的相关关系，例如安全相关函数，该函数仅在另一个“关键”函数被安全模式切换函数安全停用的模式下“活动”。

图例

软件组件(SWC)在分析的范围内

具有分配安全要求的软件组件(SWC)

软件组件(SWC)被排除在基于AN的分析范围之外争论

功能相互作用(例如。数据流)

图E.3-关于安全论证的分析范围

示例3：图E.3显示了要分析的软件，根据安全概念，安全相关功能仅在SWCU中实现，并由SWCV中实现的监视功能控制确定对架构的分析范围澄清了所需的安全参数，并支持以下章节所示的进一步步骤。在这个例子中，只有当SWCX、SWCV和SWCU的分析能够确认假定的免受干扰的自由时，SWCY才能免于进一步的详细分析。在护卫M中没有关于错误信号A1到AN的级联故障的弱点)。

E.3.3确定用于进行分析的方法

由于软件的特定性质(例如。没有随机故障，因为磨损或老化和缺乏成熟的概率方法)，在系统或硬件层面为这种分析建立的方法往往不能在没有修改的情况下转移到软件上，或者不会产生同样有意义的结果。

安全分析方法的共同因素是，它们通常包括一种手段，以执行结构化的方法，存储所获得的知识，并得出结论。

示例：语法和语义来描述故障树或FMEA中使用的函数网或元素列表或风险优先级编号中的故障及其相关关系。

安全分析和相关故障分析的基础是描述静态方面的软件架构设计(例如。用框图表示，显示功能元素及其接口/关系)以及动态方面(例如。用相关软件的顺序、定时或调度图或状态图表示)。

根据软件架构设计进行的安全分析和相关故障分析可以遵循考虑静态和动态两个方面的功能链和/或处理链。在这种分析中，软件故障模型或问题，如“来自或影响该软件组件的特定故障或故障可能导致违反指定的安全要求”，可用于确定设计中与安全有关的弱点。

软件架构设计的细化可以支持安全分析和相关的故障分析，以获得足够的细节，以确定较低级别的故障或故障。

这种分析所需的详细程度相关于：

Ø 在架构设计的改进过程中充分选择范围；

Ø 支持实现分析的具体目标的属性；

Ø 基于由“良好”设计原则支持的架构策略的论点；或

Ø 由充分的独立性引起的论点，包括获得免受干涉。

E.3.4支持分析的有意义、客观性和严谨性的方面

E.3.4.1DFA的耦合因子类符合ISO26262-9：2018

在ISO26262-9：2018，附件C中，定义了具有相应软件级示例的耦合因子类，可用于改进对需要独立的软件的功能或处理链进行的相关故障分析的结果。

E.3.4.2使用附件D的内容

附件D提供了软件故障模型，供分析软件要素之间的干扰时考虑，例如：

Ø 时序和执行；

Ø 内存；或

Ø 交换信息。

E.3.4.3使用引导词支持的分析

指南词可以用来系统地检查可能偏离特定设计意图的情况，并确定其可能的后果。在面向安全的分析中，引导词用于生成用于检查架构元素的特定功能或属性的问题。在使用指导词时，每个指导词都会重复对每个设计元素的特定功能或特性进行面向安全的分析，直到预定的指导词都被检查过。因此，指导词是系统地进行这种分析和支持完整性论点的一种手段。

数据流或类似的图表通常用于描述软件架构设计的功能方面(例如。功能链或加工链)。图E.4显示了软件组件Y、U和V以及相关功能或处理链的交互(例如。基于数据流)。

引导词可以用来识别弱点、错误和失败。选择合适的引导词取决于所检查的函数、行为、属性、接口或交换数据的特性。

图例

软件组件(SWC)在分析的范围内

具有分配安全要求的软件组件(SWC)

软件组件(SWC)被排除在基于AN的分析范围之外的争论

功能相互作用(例如。数据流)

图E.4-软件架构设计框图

以设计意图为基础，结合设计属性、相关导词及其解释，导出导词，以达到分析的共同理解。表E.1显示了图E.4中用于设计的指导词的选择示例。

表E.1-选择与软件执行、调度或通信有关的指导词的示例

在分析过程中，引导词可以使用演绎或归纳的方法来应用。在分析过程中，如果需要，可以进一步完善指导词(例如。更好地匹配特定的设计方面)。

在分析过程中，根据选定的方法使用指导词(例如。遵循功能或处理链)生成将检查设计并揭示可能的弱点及其后果的问题。表E.2显示了支持分析信号A1至A的导字示例。

表E.2-支持分析的指导词示例

e.4.在安全和相关故障分析（DFA）中发现的弱点的缓解策略

软件架构层面的安全分析和相关故障分析的结果允许选择适当的安全措施，以防止或检测和控制可能违反安全要求或安全目标的故障和故障。

安全措施确定策略可以基于以下考虑：

Ø 每个识别的故障的临界性，基于它是否可以违反分配给架构元素的安全目标或安全要求及其分配的ASIL；

Ø 架构设计是否可以改进，以消除已识别的弱点或减少已识别故障的临界性；

Ø 确定的开发时间安全措施的有效性，以及它们是否能够根据其临界性和相应的理由充分减轻所识别的故障(例如。考虑到分析过程中使用的软件故障模型，确定验证活动有效性的理由)；

Ø 确定的安全机制的有效性，以减轻已确定的关键故障，其中开发时间措施被认为是不够的；和

Ø 软件架构设计的复杂性(例如。接口和软件组件的数量)或软件组件(例如。分配的需求数量或组件的大小)。

例如：对于更复杂的软件，仅仅基于开发时间度量的论证是不太合适的。

根据上述策略，并不总是需要实现能够在运行时预防、检测和控制此类故障或失效的安全机制。