如今，汽车领域的许多创新都是通过软件和电子系统实现的。可靠的测试流程是开发流程中不可或缺的一部分，用于验证所实施的软件是否按预期运行。ISO 26262或 ASPICE等标准要求一致的测试文档。测试文档的一个重要部分是测试用例规范，它由软件测试标准ISO 29119定义。测试用例规范包含一组从特定测试对象的测试基础派生出来的测试用例。应随时避免测试用例规范的失效和误解。虽然可以使用突变测试等技术来评估自动化测试的质量，但用于评估非正式测试用例规范质量的自动化方法很少或仅限于特定领域的测试语言，即测试和测试控制符号(TTCN-3)。为了确定汽车测试用例规范的潜在改进领域，本文旨在研究如何使用给定的测试用例规范模板来评估质量。

分析基于从测试用例规范中提取的数据，这些数据适合作为测试用例规范质量评估的指标。分析提供了对汽车测试用例规范的洞察，并确定这些测试用例规范中是否有足够的形式化来实现质量的自动评估。

作为数据源，从汽车OEM收集了总共16个不同项目的816个测试用例规范。所包含的测试用例规范要么是内部创建的，要么是由供应商创建的。

在第2节中，我们概述了测试用例规范，并提供了一个示例。第4节包含分析得出的潜在质量指标的描述，包括选定测试用例规范的定量数据。此后，我们在第5节总结并提出了对未来工作的一些展望。

测试用例规范是汽车环境中测试文档的核心部分。它们用于记录要执行的测试用例。测试用例规范包含一组测试用例，这些测试用例对于根据定义的测试目标充分测试特定测试对象是必不可少的。测试用例的基本特征是具有唯一标识符、先决条件和后置条件、输入、预期结果、测试执行的优先级和可追溯性信息（例如对相关需求的引用）。除了这些测试用例基本属性外，还经常指定其他领域或公司特定的测试用例属性，例如状态、测试目标、作者、模型系列或测试平台。这些属性称为测试用例元数据。

测试用例元数据和基本属性与测试用例相关，可以在测试用例规范模板中定义。图1显示了汽车测试用例的示例和测试用例规范模板的应用。雨刮器和清洗系统的测试用例由其基本属性和汽车特定的测试用例元数据（例如车辆系列、测试平台）描述。测试用例属性由列表示，行用于定义不同的对象类型，例如文本、标题、测试用例或测试步骤。并非所有属性都与每种对象类型相关，因此某些单元格应为空（图1中的深灰色单元格）。不同的对象类型彼此之间具有层次关系。例如，必须将测试步骤分配给测试用例。

（a）测试用例基本属性

（b）测试用例元数据属性（虚线边框）

图1.使用测试用例规范模板的汽车测试用例定义示例

我们从汽车OEM的IBM Rational DOORS数据库中收集了数据，并确定了总共2435个测试用例规范。此后，过时的测试用例规范已被排除，将测试用例规范的数量减少到972个。过时的测试用例规范是指那些不基于当前测试用例规范模板或其最后修改日期在2015年之前的规范。此外，未包括重复项、备份或按名称标记为过时的测试用例规范，导致测试用例规范进一步减少到816个，共16个不同的项目。项目与车辆领域有关，例如动力传动系统、底盘或舒适系统。

基于测试用例规范模板确定的测试用例规范如图1所示。测试用例源自自然语言需求，因此相关的测试用例属性也是使用自然语言指定的。

我们根据可以通过编程确定的信息对收集的数据进行了定量分析。因此，我们使用DOORS可扩展语言(DXL)从已识别的测试用例规范中提取定量数据。

基于代表性项目详细介绍了分析结果。所选项目包括来自动力传动系统领域的总共12个测试用例规范，这些规范代表了汽车测试用例规范。图2-5显示了该项目的分析结果。接下来，将根据所检查的各种标准讨论已识别的质量指标。

A. 标准1：测试用例规范相对于需求规范的大小

测试用例规范中的平均测试用例数为511（参见图2中的测试用例数）。但是，非常大的测试用例规范包含超过2200个，小的测试用例规范只能包含31个测试用例（参见图2）。但是，测试用例规范的大小意义不大，并且不会对测试用例的正确性做出任何陈述。因此，必须将它们与相应需求规范中指定的可测试需求相关联考虑。例如，具有856个测试用例的测试用例规范（参见图2，TCS 12）可归类为大型。与测试用例规范12相关联的需求规范包含2462个可测试需求。建议至少用一个测试用例测试一个需求。因此，显然应该有更多的测试用例来验证2462个相关需求。但是，测试用例规范的大小与可测试需求数量之间的关系只能作为测试用例规范完整性的指标。可以通过系统先前的测试用例规范确定测试用例规范适当大小的参考值。

B. 标准2：所含对象类型的分布

测试用例规范包含大量测试用例和测试步骤，如图2中的绿色条所示。基本场景类型的对象表示可由多个测试用例引用的可重用先决条件。分析表明，测试用例规范中通常只有极少量的基本场景，或者根本不使用基本场景。相反，先决条件通常会从一个测试用例复制到另一个测试用例，而不是在基本场景中存储和引用可重用的结构。这在大型测试用例规范中尤其明显。通过使用基本场景，可以减少重复，并增加已建立结构的重用。减少重复还可以最大限度地减少对重用部分进行更改所需的时间和精力，因为更改可以集中进行。测试用例规范还包含未定义的对象，这些对象未分配任何对象类型（例如TCS 11，图2）。少数测试用例规范包含单独的对象类型，并且模板未预定义。这违反了模板，可能会影响导出到下游工具。

C. 标准3：测试用例的大小

测试用例的平均大小（以要执行的测试步骤数量来衡量）为3.83个测试步骤。但是，在代表性项目中也可以识别出最多包含76个测试步骤的测试用例（参见TCS 8，图3）。大型测试用例在后期的测试执行中更容易出错，并使调试更加困难。例如，手动执行76个测试步骤以重现失败的步骤非常耗时。此外，过多的测试步骤可能表明多个测试用例已合并为一个大型测试步骤。因此，将它们分成几个测试用例是有意义的。

D. 标准4：测试用例规范的类型

测试用例通常具有构建测试用例流程的测试步骤。这样做的好处是可以避免非常庞大、广泛和连贯的测试过程描述。它还支持将记录的预期结果分配给明确定义的一组输入和操作。对于非常小的测试用例，用于分析的测试用例规范的模板允许在不使用测试步骤的情况下定义操作和预期结果。分析表明，当完全省略测试步骤时，测试用例规范就会存在（参见TCS 3，图3）。在这种情况下，通常可以观察到输入和预期结果超载。多对输入和预期结果组合在一个测试步骤中。这意味着不再可能明确地将输入与预期结果关联起来。当测试用例规范同时使用两种方法时，情况也是如此。在大多数情况下，在测试用例规范中会发现两种方法的混合（例如图3中的12个）。这种形式更容易出错，并且难以理解。

E. 标准5：链接对象类型的类型

对链接对象类型的分析揭示了测试用例和工件之间的链接。图5中的表格显示了允许链接的链接方案。一般来说，这些是外部链接（例如，工件是需要验证其正确实施的需求，参见图4中的TCS 8）或内部链接，即由测试用例引用的基本场景等工件，参见图4中的TCS 11）。在某些情况下，没有链接任何需求（参见图4中的TCS 5、6和7）。在这种情况下，需求覆盖范围不足。链接分析还可以用作质量指标，以检测记录需求中的错误，即，如果未为需求设置对象类型（未定义的链接，例如图4中的TCS 6、7和11）或需求规范不是基于标准模板（未知链接，例如图4中的TCS 5）。在考虑的测试用例规范和链接的需求规范的情况下，必须为需求设置对象类型需求。此外，可以检测到不符合模板和不正确的链接（参见图4中的黑条）。这包括在基于需求的测试方法中不能被视为可测试的标题、信息或流程需求的链接。

F. 标准6：链接对象类型的数量

一个测试用例平均链接到1.68个需求。这也符合每个需求应由至少一个测试用例检查的前提。但是，当一个测试用例链接了121个需求时，也存在巨大的偏差。如此多的链接需求可以看作是检查此类测试用例的指标，要么是因为它太大，可以分成几个测试用例，要么是因为单个测试用例似乎不太可能涵盖这么多需求。根据我们的经验，超过20个链接需求可以被视为关键。

G. 标准7：模板一致性

分析发现了几项违反模板指南的行为。这些对测试用例规范的进一步处理有显著的负面影响（例如，自动验证机制不适用或导出到下游工具失败）。例如，自定义章节结构（添加或重命名章节）意味着测试用例未包含在导出中或导出失败。此外，如果某些强制属性没有填写（例如输入、预期结果、测试平台、模型系列），它可以作为测试用例规范质量的指标。

我们的调查显示，测试用例规范没有完全按照所用测试用例规范模板的指南进行记录。因此，需要进一步调查根本原因。测试用例规范的自动化质量评估需要充分的形式化。由于测试用例规范的属性集高度个性化，基于模板的结构评估似乎并不适用于所有测试用例规范。由于测试用例通常是以散文形式编写的，因此很难以编程方式评估测试用例的内容并将其与需求和测试概念的内容进行比较。为了进行自动化质量评估，必须将测试用例形式化，并必须满足模板指南。此外，应该注意的是，测试概念和底层需求的内容在测试用例规范的质量评估中起着重要作用。由于这些信息不是以相同的数据格式提供的（例如需求、DOORS中的测试用例和Word中的测试概念），因此无法自动评估是否符合指南。分析表明，存在一些标准，可以用作对测试用例规范结构的检查进行初步质量评估的质量指标。这尤其包括相对于需求规范的测试用例大小、链接需求的数量、对给定链接方案的遵守情况或测试概念中定义的测试目标和测试平台的实施。这些标准可用于获得对测试用例规范质量的初步印象。这可能是在给定时间进行更详细检查是否合理的条件。

我们未来的工作将集中在测试用例描述的定性分析上，这些描述大多基于自然语言。需要机制来支持和加速对测试用例规范的审查。

嵌入式系统已经融入我们的日常生活，并在汽车、航空航天、医疗保健、制造业、能源或消费电子等所有领域发挥着核心作用。目前的高档汽车每辆车配备90多个电子控制单元(ECU)，软件代码接近1 GB，这些电子控制单元占汽车成本的25%，并带来40%至75%的附加值。在汽车领域，利用现代嵌入式系统实现日益复杂的软件功能，取代传统机械系统，这种趋势从未间断。同样，对更复杂的软件工具的需求也在增长，这些工具以整体方式支持这些系统和软件开发流程。因此，处理现代实时系统即将出现的问题，也与ISO 26262相关，基于模型的开发(MBD)似乎是以更结构化的方式支持正在开发的系统描述的**方法。基于模型的开发方法为不同的利益相关者提供了不同的视图、不同的抽象级别，并提供了信息的中央存储。这提高了系统规范的一致性、正确性和完整性。然而，这种基于模型的开发的无缝集成仍然是例外，而不是规则，MBD方法常常由于缺乏概念和工具级别的集成而无法达到要求。

本文的目的是提出一种工具方法，该方法能够无缝描述安全关键软件，从系统级需求到软件组件实现，双向进行。利用所提供的工具，可以使用硬件-软件接口(HSI)信息来生成基本软件(BSW)组件配置，以及自动生成运行时环境层(RTE；应用软件(ASW)和基本软件之间的接口)。

该工具由一个基本软件配置生成器和一个软件接口生成器组成，后者生成用于链接ASW和BSW的.c和.h文件。为了确保工具的多功能性，可以从HSI电子表格模板或系统模型表示中导入所需的HSI信息。一方面，目标是支持从早期概念阶段到软件实施的一致且可追溯的改进；另一方面，双向结合电子表格工具（如Excel）的多功能性和直观性以及MDB工具的属性（例如，不同的视图、抽象级别、中央信息源和信息重用），以支持BSW配置和SW-SW接口层（在AUTOSAR符号中称为运行时环境- RTE）的半自动生成。

文档组织如下：

第2节概述了相关工作以及该方法所基于模型的开发工具链。在第3节中，提供了所提议工具的描述以及贡献部分的详细描述。第4节介绍了该方法的应用和评估。最后，第5节总结了这项工作，并概述了所提出的方法。

汽车嵌入式软件的开发以及底层基础软件和嵌入式系统的配置是工程领域和研究课题，旨在将开发流程转移到自动化工作流程，以提高一致性并解决跨专业知识和领域边界的软件开发流程的复杂性。

由于过去几年软件复杂性不断增加，管理汽车嵌入式软件开发过程变得越来越必要。为了处理这种复杂性，AUTOSAR联盟成立了，AUTOSAR方法在不同软件组件之间提供了标准化和明确定义的接口。AUTOSAR方法具有三种不同的实现类（ICC -实现一致性类）。与完整的AUTOSAR方法(ICC3)相比，AUTOSAR ICC1方法的主要优势显然在于节省时间，因为无需额外熟悉通常非常复杂且耗时的AUTOSAR工具。ICC1方法没有利用AUTOSAR的完整工具链支持工具的RTE配置和通信接口优势，而是利用标准化组件接口在ASW和BSW之间交换数据，因此具有应用程序特定和硬件特定软件部分分离的特点（如原生非AUTOSAR开发）。ICC1主要关注SW工程，更具体地说是将ASW集成到给定的SW架构中。但是，与控制系统工程（包括HW/SW协同设计）相关的方面并未集成，并且必须手动执行诸如HW/SW接口定义等方面，如图1所示。本文介绍的工具方法通过提供一个框架来增强这方面，该框架用于可视化ASW和BSW接口配置并自动生成这些接口.c和.h文件（参见图2）。此外，可用的硬件-软件接口(HSI)信息可用于生成基本软件(BSW)组件配置，HSI信息导入功能还可以处理HSI电子表格模板，以确保工具的多功能性。

总而言之，已研究的诸多方法均不支持(1)源代码生成和(2)从系统级和系统模型中可用的信息配置基本软件。相比之下，我们提出的方法不仅支持自动生成RTE源代码，还支持从系统模型自动生成嵌入式系统的基本软件配置。

该方法的基本概念是拥有一个一致的信息存储库作为中央信息源，以结构化的方式存储嵌入式汽车系统开发中涉及的所有工程学科的所有信息。该概念侧重于允许不同的工程师以自己的特定方式完成工作，但提供有关整个系统的功能（例如功能安全性、网络安全性或可靠性）的跟踪和依赖性分析。该方法源于常见的基于AUTOSAR的方法，此外还支持非AUTOSAR或AUTOSAR ICC1方法，这些方法经常因缺乏支持工具而受到阻碍。不采用完整AUTOSAR方法的决定一方面是基于不仅要关注基于AUTOSAR的汽车软件开发，另一方面，由于AUTOSAR标准的复杂性，并非所有开发工具都完全支持整个标准，这会导致一些相互不兼容和互操作性问题。

图2显示了该方法的概述并突出显示了主要贡献。

本文介绍的工具方法提供了一个框架，用于可视化ASW和BSW接口配置以及自动生成这些接口.c和.h文件（见图2）。此外，可用的硬件-软件接口(HSI)信息可用于生成基本软件(BSW)组件配置，并且HSI信息导入功能还可以处理HSI电子表格模板，以确保该工具的多功能性。更具体地说，这项工作中提出的贡献包括以下部分：

• AUTOSAR对齐的UML建模框架：

增强UML配置文件以定义AUTOSAR特定工件，更准确地说，用于定义组件接口（基于虚拟功能总线抽象层），参见图2 – HW和SW建模框架。

• BSW和HW模块建模框架：

增强UML配置文件以描述BSW组件和HW组件。为确保整个控制系统的规范和实施的一致性，参见图2 – HW和SW建模框架。

• RTE生成器：

支持在特定于应用程序和特定于硬件的软件功能之间生成接口文件（.c和.h），参见图2 –ASW/BSW接口生成器。

• 基本软件配置生成器：

根据HSI定义中的规范生成BSW配置，参见图2 – BSW配置器。

• 电子表格信息导入器：

支持导入电子表格格式的HSI定义信息，参见图2 –电子表格信息导入器。

这种提议的方法通过支持系统工程工具和软件工程工具之间的一致信息传输，缩小了抽象UML类表示的系统级开发与软件级开发之间的差距。此外，该方法最大限度地减少了工具之间冗余的手动信息交换，并有助于根据ISO 26262简化开发系统的无缝安全论证。这种开发方法的好处在重新设计周期、工具更改和具有交替依赖关系的开发工件重新加工方面非常明显。

本研究提出的贡献是提出的框架的一部分，旨在实现汽车环境中的软件开发。该方法的实现基于多功能C#类库(dll)和API命令实现，以确保工具和工具版本独立于通用UML建模工具（如Enterprise Architect或Artisan Studio）和其他相关工具（如电子表格工具和软件开发框架）。以下各节将更详细地描述该方法中做出关键贡献的部分。

A. AUTOSAR对齐的UML建模框架

该方法的第一部分是一个特定的UML建模框架，它使软件架构设计能够像在先进的系统开发工具（在本例中为Enterprise Architect）中一样以AUTOSAR的形式进行表示。特定的UML配置文件将UML可能性限制在安全关键系统的软件架构开发需求范围内，并允许在系统开发工具（Enterprise Architect）中像在AUTOSAR中一样以AUTOSAR的形式进行软件架构设计。除了AUTOSAR VFB抽象层之外，该配置文件还允许明确定义组件、组件接口以及接口之间的连接。这提供了定义软件架构的可能性，并确保了架构工件之间通信的正确定义，包括接口规范（例如上限、初始值、公式）。因此，EA中的SW架构表示可以链接到系统开发工件，并且可以轻松建立对需求的跟踪。这在约束检查、开发决策的可追溯性（例如安全档案生成）、重用方面带来了更多好处，并确保了多功能性，也支持AUTOSAR对齐开发。图3显示了Enterprise Architect中所表示的软件架构工件和接口信息的示例。从描述中可以看出，建模SW架构所需的所有工件都已表示并以标记值的形式继承所需的信息。

B. BSW和HW模块建模框架

AUTOSAR架构方法确保应用软件模块的硬件独立开发直到开发阶段的最后阶段，因此使应用软件开发人员和基础软件开发人员能够并行工作。该方法的硬件配置文件允许以图形方式表示硬件资源（例如ADC、CAN）、计算引擎（核心）和与软件交互的连接外围设备。分配特殊的基础软件(BSW)和硬件模块表示以建立与底层基础软件和硬件层的链接。这允许以直观的图形方式建立软件和硬件依赖关系以及硬件-软件接口(HSI)，如ISO 26262所要求的那样。BSW模块的软件信号可以通过专用映射链接到HW端口引脚。第一点，这可以实现HW细节和SW信号的建模和映射，参见图4；第二点，此映射建立了可跟踪的端口引脚配置链接。第三点是，此HW依赖关系可用于互连调度和任务分配分析工具，以分析和优化资源利用率。

C.运行时环境生成器

所提出方法的第三部分是SW/SW接口生成器。此基于dll的工具基于建模的HSI工件生成.c和.h文件，定义应用软件信号和基本软件信号之间的SW/SW接口。此外，此生成消除了在没有足够语法和语义支持的情况下手动生成SW/SW接口的需要，并确保了这些配置的可重复性和可追溯性。

图5显示了生成文件的概念概览。应用软件级别的.c和.h文件是通过基于模型的软件工程工具（例如Matlab/Simulink）生成的。基本软件级别的文件通常由硬件供应商提供。而SW/SW接口层中引用的文件则由我们的方法生成。

生成的文件采用两步方法设计。

接口方法的第一步（interface.c和interface.h）基于AUTOSAR RTE调用建立ASW和BSW之间的接口。第二步（AV LIL BSW a.c和AV LIL BSW a.h）将这些基于AUTOSAR RTE的调用映射到基本SW驱动程序的HW特定实现。这确保了独立于BSW驱动程序的实现，并且在需要时还具有AUTOSAR ICC1方法。

D.基本软件配置生成器

基本软件配置生成器也是基于dll的工具的一部分，该工具生成BSW驱动程序特定的∗cfg.c文件。这些文件根据HSI规范配置硬件设备的供应商特定低级驱动程序（基本软件驱动程序）。HSI规范到低级驱动程序配置的映射是特定于硬件和低级驱动程序实现的，需要针对每个硬件设备和支持的低级驱动程序包完成一次。

讯享网

E. HSI电子表格信息导入器

HSI定义需要硬件和软件领域的相互知识，并且是硬件、软件和系统专家集体研讨会的工作成果，并将充当不同开发级别之间的纽带。如果同时进行硬件和软件开发，并且异步更新间隔存在交叉依赖关系，那么一致性和正确实施HSI的证据可能具有挑战性。因此，这种方法能够以实用且直观的方式在电子表格工具(Excel)中设计HSI定义，并将它们转换为MDB工具(Enterprise Architect)中可重复使用和可版本化的表示形式。电子表格模板以项目特定的可定制方式定义数据表示的结构。一方面，这能够以实用且直观的方式使用电子表格工具设计HSI定义，而其机器和人类可读的符号确保了通常复杂的专用工具的成本和时间节约的替代方案，另一方面，它能够生成SW/SW接口文件和BSW配置，而无需基于模型的开发工具链。图6描绘了用于准备HSI定义数据的独立于项目的模板结构。

图6. HSI定义的项目独立电子表格模板结构示例

本节展示了所介绍的方法对汽车嵌入式系统开发的好处。

我们使用汽车电池管理系统(BMS)作为评估该方法的用例。此用例是说明性材料，出于内部培训目的而缩减，并不旨在详尽无遗或代表尖端技术。

软件架构的定义通常由软件系统架构师在软件开发工具(Matlab/Simulink)中完成。在我们的方法中，此工作包包含在系统开发工具中（如图3所示）。这不会妨碍软件架构师的工作，但还可以将现有的HSI映射信息链接到SW架构（如图4所示）。

用例由10个ASW模块和7个BSW模块组成，ASW和BSW之间有19个接口定义，并使用3个基本的低级HW功能（数字输入/输出、模拟输入/输出和PWM输出）。表1给出了更完整的用例概述。

19个HW/SW接口的定义，每个SW信号有10个参数，每个HW引脚有13个参数，在HSI电子表格模板或MDB工具中总共有437个参数配置，可用于生成ASW/BSW接口和BSW配置。这产生了图7中所示的文件架构。使用该方法，生成了8个额外的接口文件，其中包含481行代码(LoC)源代码和288个LoC配置。

在开始AUTOSAR一致开发或支持非AUTOSAR SW开发方面，我们的方法采用了ICC1 AUTOSAR的平稳第一步方法，并生成了一个接口层（类似于AUTOSAR RTE），而无需依赖完整的AUTOSAR工具支持。在安全关键型开发方面，所提出的方法支持BSW配置与HSI信息之间的可追溯性链接，并消除了手动接口源代码返工的需要，这进一步克服了ICC1 AUTOSAR方法的主要缺点。

嵌入式汽车系统开发的一个重要挑战是确保设计决策、软件实现和驱动程序配置的一致性，尤其是在安全相关开发的背景下。这项工作提出了一种无缝描述安全关键软件的方法，从系统级需求到软件组件实现，都以可追溯的方式进行。因此，可用的硬件-软件接口(HSI)信息可用于生成基本软件(BSW)组件配置，以及自动软件接口层生成（应用软件和基本软件之间的接口）。考虑到这一目标，我们提出了一个由基本软件配置生成器和软件接口生成器组成的框架，用于生成用于链接ASW和BSW的.c和.h文件，该框架也可与基于电子表格的HSI定义结合使用。这种增强的主要好处是：从系统级的初始设计到单CPU驱动程序配置，一致性和可追溯性得到提高，同时减少了系统开发流程中繁琐且容易出错的手动工作。该方法的进一步改进包括软件开发配置（如驱动程序配置和SW-SW接口）的可重复性和可追溯性方面的进步。

已利用汽车BMS用例演示了所提出方法的应用，该用例旨在用于学生和工程师的培训目的，并不代表详尽或商业敏感的项目。虽然作者并不声称分析的完整性（由于保密问题），但该方法的好处已经显而易见。

新车辆互联功能的开发以及ISO 26262的使用需要提高安全分析的可追溯性。因此，系统工程(SE)提出了管理需求可追溯性的设计流程模型，以及涵盖功能和功能障碍需求以及将安全措施映射到逻辑架构的产品模型。根据ISO 26262，安全对应于“不存在不合理风险”两项主要安全活动是：危害的识别和分类；寻找其可能的原因正如Kemmann所通知的那样，可追溯性问题涉及这两项安全活动。

研究提出了一种定义安全目标(SG)的方法，并结合系统运行视图的定义。SG是识别危害的高级安全需求。“意外加速”危害的SG示例是“驾驶员意图和车辆加速度之间的差异必须小于Y%”。每个SG都有一个关联的ASIL（汽车安全完整性等级），这是对相应危害（例如意外加速）的真实性进行分类的标准。一旦识别并分类了危害，就可以寻找其可能的原因。为此目的，可以使用众所周知的方法，例如定义故障树、FMEA等。不幸的是，这些安全方法与定义车辆逻辑架构的系统架构师的活动是分开的。这就是为什么我们在本文中建议一种能够定义与逻辑架构相关的功能安全概念的方法。正如ISO 26262中提到的那样，功能安全概念是“功能安全需求的规范，包括相关信息、它们在架构元素中的分配以及实现安全目标所必需的相互作用”，功能安全需求是“独立于实施的安全行为或独立于实施的安全措施的规范，包括其与安全相关的属性”。

所提出的方法支持安全逻辑架构定义(SLA)的流程，它是安全系统工程流程(SSEP)的一部分。SLA可以被认为是架构定义(SLA)，它是安全的一部分。所提出的方法支持安全逻辑的流程，作为一种与系统（在我们的例子中是汽车）的逻辑架构相关的功能安全需求的推导方法。SLA定义将应用于一个具体案例，即动力传动系统“产生机械能”功能的意外燃油喷射。最后，我们将讨论所提方法的原创性。虽然这一贡献是基于ISO 26262，但所提方法的成果可以轻松扩展到汽车行业以外的其他行业。

传统上，逻辑架构的安全分析是功能视图的故障树分析和行为视图的失效模式和影响分析。这些活动不是基于模型的。此外，它们之间的联系很少，并且没有模型反馈到逻辑模型。

然而，关于SE与安全之间的联系存在许多研究。研究人员开发了一种名为Hip Hops（分层执行的危害起源和传播研究）的工具，用于根据功能结构确定功能失调的传播路径。这使得观察逻辑架构功能视图的功能失调方面成为可能。然而，行为视图并未得到解决。

在与法国汽车设备制造商Valéo合作的一项研究项目中，Abraham Cherfi提出了一种基于马尔可夫图的功能级安全机制模型。这允许进行准确而具体的定量功能失调研究。然而，马尔可夫****对系统架构师来说并不全面，因此不适合与安全工程师进行方便的协作和反馈。

另一种方式涉及定义像AltaRica这样的形式语言，它将成为系统架构师和安全工程师之间的枢纽语言。事实上，AltaRica允许通过对系统进行建模来进行定量分析，从而进行彻底的可靠性分析。

最后，可以建立介绍中提到的安全流程（危害识别、分类和解释）与系统架构师操作的流程之间的联系。主要目的是提高安全逻辑架构的实现效率。然而，在这项工作中，安全活动对SEone的反馈仍然存在差距。

为了总结这一简洁的新进展，可以注意到有几项研究提出了从SE到功能安全的途径。然而，缺乏反馈。这就是为什么我们将在本文中讨论如何通过安全（基于模型）系统工程流程(SSEP)来实现功能安全需求以填补这一空白的原因。

3.1 SSEP定义

在定义构建功能安全需求的方法之前，需要SSEP。在本文中，我们将仅考虑系统架构的逻辑视图。此SSEP基于ISO 15288、ISO 26262和SEBoK（BKCase编辑委员会）。在表1中，我们列出了与逻辑架构定义流程相关的拟议SSEP的一部分。我们可以将此流程与SEBoK中推荐的流程进行比较。这将决定我们在参考SE框架时方法的独创性。

3.2 SSEP描述

拟议的SSEP的第一步是定义系统逻辑架构的功能视图，即功能树或功能网络。

这涉及功能失调失效模式和关键传播路径的定义。通过添加安全概念（例如满足SG的安全功能），可以完善所获得的系统模型。ISO 26262将安全机制定义为“由E/E功能或元素实现的技术解决方案”。这个概念的范围很模糊。因此，我们选择将此概念保留为物理架构，并使用安全功能的概念作为逻辑架构。

然后，需要将更高级别的技术需求（包括SG）推导并分配给逻辑元素（包括安全功能）。这也意味着可以像使用 (Papadopoulos et al.,)那样推导和分配ASIL。

在第二步中，可以指定包括安全功能在内的功能的行为（逻辑架构的行为视图）。为此，可以基于设计模式来完成。这将允许将功能合并到逻辑块中，从逻辑块中得出功能安全需求(FSR)，以定义功能安全概念。

在第三步中，可以开发和评估替代方案，以选择最合适的方案。最后，一旦在物理层面上详细说明了对组件的首次功能分配，就可以根据物理选择更新逻辑架构。

既然已经定义了流程，就可以确定实现该流程的方法。

ISO 26262没有明确说明如何定义FSR。在文献中，没有提出相关方法。在本节中，我们提出了一种帮助系统架构师定义FSR的方法。

4.1 一般方法

安全逻辑架构的开发（如下所示）包括多项活动。为了便于阅读，图1中未显示与不同视图之间连续丰富相关的循环。

第一项活动(A1)是确定逻辑架构的功能视图。我们必须首先确定不同的功能、接口和它们之间的流程。然后，可以根据危害的因果关系确定关键的功能障碍路径（下一节将解释选择）。这使我们能够识别出功能障碍行为可能产生危害的功能，并提出包括安全功能在内的替代安全概念。因此，不会保留具有非关键结果的传播路径。然后，可以通过开发各种功能的模式和状态或可能的功能场景来定义安全逻辑架构的行为视图（活动A2），这些场景可以描述功能继承的动态。这些可能是名义上的，也可能是功能失调的。在将功能元素集成到逻辑块中（活动A3）之后，就可以得出技术需求，即 FSR（活动A4）。可以评估它们对不同候选架构的满意度，以便选择最合适的架构（活动A5）。最后，一旦开发了物理架构，就可以更新逻辑架构（活动A6），以便考虑在物理架构设计（第一个实施方案设计）期间做出的选择。

在本文的其余部分，我们将通过细化流程中的活动来提供有关这些模型的更多详细信息。为了更简洁地介绍，我们将细化一些先前定义的活动，即需要主要方法的活动，即需要新贡献的A1和A2活动。

4.2 确定功能视图

所提方法的输入是功能及其接口和流程，以及与相关危害和可能产生的关键后果相关的安全目标。在上层流程中识别出系统功能流的偏差后，就可以识别出产生这些流偏差的技术功能（活动A131）。实际上，与功能的输入流相比，功能的每个输出流都有预期的标准（扭矩、速度……）。如果预期输出流和实际输出流之间存在差距，则该输出流存在偏差（更多、更少、之前、早期……）。因此，可以对被视为相关的给定功能进行局部功能障碍分析（活动A132）。该分析确定了输出偏差、功能失效模式和输入偏差之间的关系。识别出导致危害的输入。执行局部分析后，系统架构师应对上游功能进行相同的分析，将所研究的功能输入偏差与其他架构输出偏差联系起来（活动A133）。必须执行列出的活动（活动A132和A133），直到没有更多未研究的输出偏差。

其次，当使用所提出的方法处理功能失调的关键路径时，可能会出现功能失调路径的循环。这些循环可能来自控制/命令或返回流，例如，泵回油箱的多余燃料。一种解决方案是像Martin Walker那样通过设置断点来解决它，即使已经研究了输出偏差。这些断点允许所有清晰的功能失调路径。过渡到行为视图可能是处理此问题的解决方案。最后，可以确定关键传播路径并可视化关键功能。顺便说一句，可以遵循关键传播路径，然后添加安全需求或安全功能以确保整个系统安全。

4.3 确定行为视图

行为视图的定义始于根据行为模型模式确定所研究功能的功能性和功能失调行为（活动A211）。这是为了定义不同的状态和功能模式，这些模式可能是正常的、功能失调的或安全的。然后可以确定模式和状态之间的转换。这些转换可能取决于与功能本身或其输入相关的内部或外部事件。通过告知这些元素，可以定义下图左侧的案例研究（图7）。为了实现这一点，正如SEBok中所讨论的，行为视图能够定义功能序列及其在场景中的激活。有两种方法和几种类型的模型可用于执行此操作：

1. 使用eFFBD图，如SEBok或Charlotte Seidner提出的。这允许通过流控制定义功能序列及其激活。研究表明，eFFBD可以很容易地用SysML中的活动图表示，

2. 使用 Harel基于SysML的状态机中的状态图确定功能的不同模式和状态及其激活。

eFFBD和状态机是互补的工具。前者有助于状态图的开发。关于此图，可以区分功能的四种状态：

1. ON状态，即功能被激活并转换流程的状态，

2. OFF状态，即功能在用户操作后不改变流程的状态，

3. SUSPEND状态，即功能被激活但不转换流程的状态，它正在等待，

4. FAIL状态，即由于失效而功能未产生预期流程的状态。

然后，这些状态可以通过功能模式来丰富，这些模式被定义为以一定性能水平激活功能。因此，ON状态可以具有对应于多个性能水平的多个标称模式以及多个安全模式。根据流程的期望性能水平，可以更改功能模式。

然后，可以识别功能的输出行为以及功能视图中显示的输出的不同状态之间的转换（活动A212）。这些将基于来自功能输入的外部事件或其模式和状态的变化。处理获得的信息以定义安全功能的期望行为以及功能与安全功能的交互（活动A213）。这意味着可以对安全功能的失调行为进行建模（潜在失效-未检测到的失效，例如没有雨的挡风玻璃雨刷失效），然后对其进行监控。

在最后一个活动中，有必要验证是否考虑了功能与其相关安全功能之间的交互（活动A214）。最后，可以模拟和验证逻辑架构的整体行为（活动A215）。从功能失调的角度来看，值得检查安全功能是否不会导致输出的不良状态。如有必要，可以调整时间方面和转换以实现所需行为。这些调整可以在实施设计阶段进行。

为了说明FSR定义流程的主要关键步骤，我们将其应用于车辆意外加速的常见示例。

在我们之前的工作中，我们定义了与运行架构相关的安全目标(SG)。我们现在关注车辆意外加速的可能原因：意外燃油喷射。

5.1功能视图的确定

因此，作为当前流程的输入，有一个关于动力传动系统功能输出流的SG，称为“产生机械能”(GME)，这是车辆的主要功能之一。如图4所示，GME分为四个子功能，即“提供燃料燃烧”、“提供空气燃烧”、“执行燃烧”和控制功能（活动A11和A12）。

鉴于上面定义的SG，现在我们感兴趣的是GME输出流的意外偏差。研究功能失调方面时要考虑的第一个子功能是“执行燃烧”。为该流量偏差确定的逻辑方程在图5所示的参数图中定义（活动A13）。

完成后，可以在逻辑架构的功能视图中定义安全功能的替代方案（活动A14）。

一个选项应该在“提供燃料燃烧”和“执行燃烧”功能之间定义安全功能。但是，在此视图上进行模拟后，这种选择对整体功能的性能产生了负面影响，如图6所示。

因此，选择引入一个安全功能，该功能可检测流量偏差，并通知控制命令功能以安全模式更改“产生机械能”功能的运行模式。

5.2 确定行为视图

在上一步中，引入了安全功能。当前步骤包括对包括安全功能在内的功能行为进行建模（活动A21）。对于此示例，以下行为表示为“产生机械能”功能的状态图（图7）。

最后，我们确定了拥有SLA所需的所有视图。这允许定义与车辆意外加速的SG相关的功能安全需求，从而定义功能安全概念。在这种情况下，与GME功能相关的功能安全需求必须包含一个安全功能，当输出流量与需求相比偏离X m3/s时，该安全功能会发出警报。

图7.GME行为视图

本文的一个原始特点是在安全逻辑架构的定义中将功能和功能障碍方面联系起来。事实上，许多关于功能安全概念（或更普遍的功能FMEA）定义的研究可能会提取实现功能障碍活动所需的信息。然而，将其结果恢复到安全逻辑架构的定义并不容易。因此，使用所提出的方法，系统架构师可以考虑逻辑架构的功能障碍方面。此外，行为方面不一定仅基于静态视图（例如经典故障树）来处理。尽管如此，如果系统架构师能够理解所提出的流程和图表，那么完成功能安全概念并不是这一责任的核心。然而，实现功能障碍丰富的功能视图是非常积极的，因为它有助于描述系统设计。

人们可能会问，所提出的方法是否允许进行安全定量分析。通过基于Open PSA等格式绘制SSEP概念，可以添加缺失的元素，即失效和修复概率、失效规律等。因此，可以将通过所提方法创建的模型传输给安全专家进行定量分析。

本文提出了一种定义功能安全概念的方法，该方法与系统逻辑架构的定义相结合。它依赖于一个共同实现功能和功能障碍活动的过程。在应用于意外喷射燃料后，讨论了该方法的独创性和局限性。支持此流程的验证工具正在原型化。他们应该识别关键路径，并验证引入的安全功能是否能够删除关键路径并满足安全目标。