汽车电子：SEooC使用案例-电子发烧友网

9.2.使用案例

9.2.1.概述

开发SEooC涉及对产品开发中相应阶段的前提条件作出假设，例如。对于软件组件，它是软件架构设计的一部分，相应的阶段是【配置管理】（ISO26262-8：2018的第7条）。没有必要对所有前提条件作出假设，例如安全计划。

图21显示了假设与SEooC开发之间的关系。开发一个SEooC可以从一定层次的需求和设计开始。每个单独的要求或设计前提是预先确定的状态“假定”。

在SEooC开发过程中，将验证SEooC的需求的正确实现(来自对SEooC以外的设计的假设、高层需求和假设)。

图21-假设与SEooC开发之间的关系

然后在相关项开发过程中确定这些需求和假设的验证。

同样，验证活动表明，在任何级别上，开发的SEooC都与使用它的使用环境中的要求一致。例如，当使用独立于使用环境开发的软件组件时，对软件规范的验证可以证明软件架构设计规范中的要求得到满足。当SEooC的开发完成，相关项开发达到对安全元件的要求的阶段时，可以生成此验证报告。

下面给出了SEooC的一些典型示例，即系统、硬件组件和软件组件。

9.2.2.开发一个作为SEooC的系统

本节旨在说明如何将SEooC概念的裁剪应用于一个新的E/E系统，该系统可以由不同的车辆制造商集成。

为了本示例的目的，系统包括在某些车辆条件下激活功能和允许在适当的驾驶员请求下解除功能的功能。流程如图22所示。

注1：根据SEooC的确切性质，可能需要对需求进行一些额外的裁剪。

注2：根据SEooC的确切性质，ISO26262-3和ISO26262-4的一些要求不能适用，因此只作了零元器件考虑。

注3：虽然ISO26262系列标准的所有条款都没有显示，但这并不意味着它们不适用。

图22-SEooC系统开发

步骤1a-定义SEooC的范围

基于假设，SEooC的开发者定义了SEooC的目的、功能和外部接口。

关于SEooC范围的这些假设的举例可以是：

Ø该系统是为总质量不超过1800公斤的车辆而设计的。

Ø该系统是为前轮驱动的车辆设计的。

Ø该系统设计最大道路坡度为32%而设计的。

Ø系统具有与其他外部系统的接口，以获得所需的车辆信息。

Ø功能要求：

l当驾驶员在特定车辆条件下提出要求时，系统启动该功能；

l当驾驶员请求时，系统会解除功能。

步骤1b-关于SEooC的安全需求的假设

开发SEooC对相关项定义、相关项的安全目标和与SEooC功能相关的相应功能安全需求作出假设，以确定SEooC的技术安全需求。

分配给SEooC的功能安全需求假设的示例可以是：

Ø系统在高车速不会时激活该功能(ASILx)。

Ø当没有检测到驾驶员请求时，系统不会解除该功能(ASILy)。为了实现假定的安全目标，定义了关于使用环境的具体假设。

关于SEooC使用环境的假设示例可以是：

Ø外部源可以提供具有所需 ASIL 等级的信息，使系统能够检测适当的车辆状况(ASILx)。

Ø外部源可以提供关于驾驶员请求的信息,且该信息达到所需的 ASIL等级(ASILy。

步骤2-SEooC的开发

当技术安全需求已从该相关项的假定功能安全需求中导出时，SEooC是按照ISO26262系列标准的要求开发的。

步骤3-工作成果

在SEooC开发结束时，提供了表明所导出的技术安全需求得到满足的工作成果。然后将工作成果中的所有必要信息提供给相关项集成商，包括SEooC的安全需求和在使用环境中所做的假设。

步骤4-将SEooC集成到相关项中

在相关项开发过程中，规定了安全目标和功能安全需求。该相关项的功能安全需求与SEooC假定的功能安全需求相匹配，以确定其有效性。

在SEooC假设不匹配的情况下，从影响分析开始，进行变更管理活动，如【变更管理】（ISO26262-8：2018的第8条）所述。潜在成果包括：

Ø在实现安全目标方面，这种差异可以被认为是可以接受的，并且不采取任何行动。

Ø这种差异可以被认为影响安全目标的实现，对于相关项定义或功能安全概念来说，可能需要进行变更。

Ø这种差异可以被认为影响安全目标，需要对SEooC组件进行变更（可能包括组件的变更）。

9.2.3.开发一个作为独立于环境的安全要素的硬件组件

9.2.3.1概述

本节使用微控制器(MCU)作为示例硬件组件SEooC。流程如图23所示。

注1：根据SEooC的确切性质，例如，需要对需求进行一些额外的裁剪。为了适应由于随机硬件故障而违反安全目标的概率的目标值。

注2：根据SEooC的确切性质，ISO26262-5的一些要求不适用，因此只作了零元器件考虑。

注3：虽然ISO26262系列标准的所有条款都没有显示，但这并不意味着它们不适用。

图23-SEooC硬件组件开发

9.2.3.2步骤1-系统层面的假设

单片机的开发（见图23）作为SEooC开始（步骤1），并假设

系统层面属性和要求按照ISO26262-2：2018的6.4.5.7。

根据对一些参考应用的分析，该阶段可以分为两个子步骤(1a和1b)。这些要求是关于硬件产品开发的前提条件(ISO26262-5：2018的表A。1)；示例如下。

9.2.3.3步骤1a-关于技术安全需求的假设

下面是一些为MCU创建的假定技术安全需求的示例。

关于技术安全需求的假设(步骤1a)：

a.CPU指令存储器的故障通过至少具有目标值（例如）的硬件中的安全机制来减轻。分配给硬件元器件层面的单点故障度量(也可以用所需的DC表示)。

b.单片机对违反安全目标的总概率的贡献不超过相关ASIL指示概率的10%。

c.为了实现安全状态，当断言复位时，MCU将所有I/O输出驱动到低状态。

d.与处理功能相关的任何安全机制都在不到10毫秒内完成（系统架构中适当级别上的故障处理时间间隔的指定零元器件）。

e.存在一个内存保护单元，以提供用不同的ASIL分离软件任务的可能性。

在这一步建立了ASIL能力。

9.2.3.4步骤1b-系统层面的设计的假设

一些系统层面设计假设的示例，对SEooC的外部：

A.该系统将在单片机电源上实现安全机制，以检测过电压和欠电压故障模式。

B.该系统将在单片机外部实现一个窗口看门狗安全机制，以检测单片机的时钟或程序序列故障。

C.针对单片机EDC安全机制中的潜在故障，将进行软件测试。

D.在关键时刻执行基于SW的测试，以验证CPU程序序列的逻辑监控中没有潜在故障。

E.在与安全有关的操作中，不使用单片机的调试接口。因此，调试逻辑中的任何故障都将被视为安全故障。

9.2.3.5步骤2-硬件开发的执行

在这些决定的基础上(假定的技术安全需求和与SEooC以外的设计相关的假设)，以ISO26262-5描述的SEooC被开发（步骤2），并准备每个适用的工作成果。例如，由于随机硬件故障而违反安全目标的评估(见ISO26262-5：2018的9.5.1中描述的工作成果)是考虑到SEooC假设的，包括假定的技术安全需求中发现的FIT率的任何预算。在SEooC假设的基础上，参照ISO26262-9对单片机内部相关故障进行了安全分析和分析。

9.2.3.6步骤3-工作成果

在MCU产品开发结束（步骤3），将工作成果中的必要信息提供给系统集成商。这包括以下文件：假设要求、与SEooC以外的设计有关的假设以及ISO26262系列标准的适用工作成果(例如，关于由于随机硬件故障而违反安全目标的概率的报告)。

9.2.3.7步骤4-将SEooC集成到系统中

当在相关项硬件产品开发阶段考虑作为SEooC开发的MCU时，所有SEooC假设的有效性，包括SEooC假设的技术安全需求和与SEooC外部设计相关的假设（步骤4）。可能的是，SEooC假设和系统需求之间会发生不匹配。例如，相关项开发者可以决定不实现假定的外部组件。因此，由于SEooC开发者所做的随机硬件故障而导致的安全目标违规的评估可能不再与该相关项一致。

在SEooC假设不匹配的情况下，从影响分析开始的变更管理活动按照【变更管理】（ISO26262-8：2018的第8条）进行。潜在成果包括：

Ø在实现安全目标方面，这种差异可以被认为是可以接受的，不采取任何行动。

Ø这种差异可以被认为影响了安全目标的实现，对功能安全概念或技术安全需求都可能需要改变。

Ø差异可视为影响安全目标的实现，并需要对SEooC组件进行变更（可能包括组件的变更）。

Ø差异可以被视为影响安全目标的实现，因此安全度量被重新计算，但重新计算的度量表明设计满足系统目标，因此不需要变更。

9.2.4.开发一个作为独立于环境安全要素的软件组件示例

9.2.4.1概述

这个条款说明了将SEooC概念应用于新的中/低级别软件组件的不同步骤。流程如图24所示。