ISO 26262 道路车辆安全标准与其他工程标准一样，旨在为安全关键系统的开发提供指导。在这一背景下，提供涵盖不同工作成果的一致、正确且完整的系统规范证据至关重要。其中一项必需的工作成果是硬件 - 软件接口（HSI）定义。硬件 - 软件接口定义尤为重要，因为它定义了不同工程领域（如系统开发、硬件开发和软件开发）之间的接口。基于模型的开发（MBD）是最有前景的方法，能够以结构化的方式支持对所开发系统的一致描述。因此，本文提出了一种符合 ISO 26262 标准的硬件 - 软件接口定义工具方法，该方法双向结合了电子表格工具（如 Excel）的多功能性和直观性以及模型库工具的特性（例如不同视图、抽象级别、信息的中央来源和信息重用）。所提出的方法能够定义符合 ISO 26262 标准的硬件 - 软件接口，并能根据这些接口定义自动推导基础软件配置。

多年来，电子控制单元（ECU）在汽车市场的价值稳步上升。汽车电子成本已上升至整车成本的 30%。与此同时，更高程度的集成以及控制应用的安全关键性带来了新的挑战。必须保证不同应用和安全概念的正确性证据，而对安全性和保密性日益增长的需求也需要额外的开发努力。诸如针对道路车辆电气和电子系统的 ISO 26262等安全标准已经制定，为安全关键系统的开发过程提供指导。这些标准提供了基于危害识别和缓解的明确安全生命周期，并定义了一长串需要生成的工作成果。在众多定义的工作成果中，硬件 - 软件接口（HSI）定义是一项重要的工作成果。硬件 - 软件接口根据技术安全概念规定了硬件和软件的交互，其中包括由软件控制并支持软件执行的硬件组件。ISO 26262 强调了硬件 - 软件接口规范的重要性和必要性，强调在系统设计阶段对其进行定义，并在硬件和软件开发阶段进一步细化。硬件 - 软件接口文档是系统开发的最后一个开发成果，也是硬件和软件并行开发的起点。

因此，硬件 - 软件接口定义需要硬件和软件的共同领域知识，通常是硬件、软件和系统专家集体研讨的结果。硬件 - 软件接口是不同开发级别之间的纽带，用于协调与硬件和软件开发相关的主题。硬件 - 软件接口定义不足可能导致开发团队之间出现多个额外的迭代周期和沟通问题。基于模型的开发（MBD）支持以更结构化的方式描述所开发的系统，为不同利益相关者提供不同视角、不同抽象级别以及信息的中央来源，而且它似乎也是解决这些硬件 - 软件接口定义问题的最佳方法。然而，迄今为止尚未实现无缝的基于模型的解决方案，主要原因是工具链支持不足（例如冗余、不一致和缺乏自动化），这阻碍了基于模型的开发方法充分发挥其潜力。因此，本文提出了一种符合 ISO 26262 标准的硬件 - 软件接口定义工具方法。所提出的方法双向结合了电子表格工具（如 Excel）的多功能性和直观性以及模型库工具的特性（例如不同视图、抽象级别、信息的中央来源和信息重用）。

本文的结构如下：下一部分描述相关工作和硬件 / 软件接口定义的最新技术。第三部分详细介绍硬件 - 软件接口定义的拟议增强功能。第四部分通过一个汽车用例评估所提出的方法。最后一部分对所取得的成果进行概述，以此结束本文。

尽管硬件 / 软件接口定义这一主题在汽车领域极为重要，但近期相关的出版物却为数不多。King 等人提出了在片上系统（SoC）开发的早期开发步骤中定义硬件 / 软件接口的问题。首先，在没有详细的软件和硬件知识的情况下，难以详细指定接口。其次，这些详细的接口会阻碍接口功能的后续迁移和功能的添加。

在汽车领域，硬件和软件的开发周期长度存在显著差异，软件开发通常分为几个抽象层（如应用软件、微控制器抽象层、基本功能驱动程序）。这种方法隐藏了硬件的具体细节，使专注的软件开发团队（例如基础软件开发者、应用软件工程师、软件集成商）得以建立，但另一方面，它有时掩盖了硬件 - 软件接口开发的重要性。

AUTOSAR 架构方法明确采用这种方法，支持在很晚的开发阶段实现与硬件无关的应用软件开发。AUTOSAR 规范旨在通过定义软件架构、接口和交换格式来支持软件的交换和重用，并使应用软件开发者、基础软件开发者和硬件开发者能够并行工作。

可以找到硬件 / 软件协同设计方法和工具的全面概述。Teich 的工作利用了硬件和软件的协同作用，重点关注成本和性能约束，并强调了主要的研究方向和成果。

基于契约的设计范式是一种新兴的独立于领域的接口定义范式。契约规定了组件的输入和输出行为，并提供有保障的行为。这种方法可用于软件组件安全契约以及基于契约的嵌入式系统开发。这些基于契约的方法促进了基于模型的开发和开发决策的可追溯性。然而，这种方法对于硬件 - 软件接口定义研讨会而言不够简单易用。由于其简单易用的特性，许多硬件 / 软件接口定义仍然在电子表格工具中或以文本形式在需求管理工具中完成。尽管 Chen 等人声称，基于社交和文本的通信在处理未来嵌入式汽车系统及其高级接口定义约束方面无法扩展。

本文提出的硬件 - 软件接口定义工具允许在电子表格工具（如 Excel）中以实用且直观的方式定义符合 ISO 26262 标准的硬件 - 软件接口。所提出的工具能够将这些硬件 - 软件接口定义转换为模型库工具（如 Enterprise Architect）中可重用且可版本化的模型表示。电子表格工具和模型库工具可以通过特定于程序的 API 进行双向对齐，这支持所提出方法的工具独立性。

图 1 展示了该成果主要部分的概述，以下各节将更详细地描述每个部分。

图1:HSI定义方法的概念概述

A. 应用软件建模框架

该方法的第一部分是一个特定的 UML 建模框架，旨在在系统开发工具（Enterprise Architect）中实现类似 AUTOSAR 的软件架构设计表示。UML 配置文件利用了 AUTOSAR 虚拟功能总线（VFB）抽象层，并能够明确定义 AUTOSAR 组件、组件接口以及接口之间的连接。类似 AUTOSAR 的表示可以与系统开发成果和需求表示相关联，这有助于这些不同类型开发成果之间的可追溯性。这些明确的链接还可用于自动约束检查，并便于开发决策的可确认性（例如用于安全案例生成）。这提供了定义软件架构的可能性，并确保正确定义架构成果之间的通信，包括接口规范（例如上限、初始值、公式）。

图 2 展示了用于软件模块（AUTOSAR 组合）及其信号接口定义建模的 EA 模型配置文件。从图中可以看出，软件模块包含其相关 ASIL 的声明和特性声明。此特性将模块确定为分层组合或原子软件模块，这为软件分配和分析带来了额外优势。ASIL 分配通过为安全相关软件模块添加值和视觉标签，为安全工程师的工作提供支持。端口配置成果（图 2 下部）意味着接口规范的定义，并能够自动生成与基础软件模块的接口。模型库工具中软件架构和模块接口的模型表示支持约束检查功能，并支持对硬件 - 软件接口定义和需求的追踪。

图2：软件体系结构建模的EA模型

硬件 - 软件接口导出器模型库工具扩展通过 API 调用与电子表格工具建立链接，并能够将建模的硬件 / 软件接口导出到电子表格文档（.csv 或.xls 文件）。模型库工具扩展以 dll 类库的形式开发，并通过 API 链接，这为多个程序的重用提供了手段，并确保导出器（分别为特定电子表格工具）的模型库工具独立性。

B. 基础软件和硬件模块建模框架

为了对基础软件（BSW）和硬件模块表示进行建模，还定义了额外的模型成果。分配这些表示是为了建立从应用软件模块到底层基础软件和硬件层的链接。因此，硬件配置文件能够以直观的图形方式建立硬件 - 软件接口（HSI），并通过专用映射将基础软件模块的软件信号链接到硬件端口引脚。图 3 描述了完成硬件 - 软件接口模型表示所需的硬件和基础软件成果。图的上部显示了基础软件模块表示，这能够对应用软件和基础软件层（运行时环境）之间的接口进行建模。第二个成果是带有可能的引脚配置列表的硬件引脚表示。可以使用第三个成果对硬件引脚的硬件 - 软件接口配置进行建模。

图3: BSW和HW再现信息建模的EA模型

C. 硬件 - 软件接口定义导出器和导入器

硬件 - 软件接口导出器模型库工具扩展通过应用程序编程接口（API）调用与电子表格工具建立链接，能够将建模的硬件 / 软件接口导出到电子表格文档（.csv 或.xls 文件）中。该模型库工具扩展以动态链接库（dll）类库的形式开发，并通过 API 链接实现，这为多个程序的重用提供了途径，同时确保了导出器（分别对应特定的电子表格工具）的模型库工具独立性。

硬件 - 软件接口电子表格导入器是硬件 - 软件接口导出器的对应组件。它同样利用电子表格工具的 API 以 dll 类库的形式实现，能够导入信息并选择性地更新硬件 / 软件接口模型成果，从而支持电子表格与模型库工具中硬件 - 软件接口表示之间的双向工程。通用的电子表格文件扩展名（如.csv 或.xls）均可导入，这与电子表格模板的通用结构相匹配。

D. 电子表格模板

电子表格模板以通用、特定于项目且可定制的方式定义数据表示的结构。这确保了使用电子表格工具进行硬件 - 软件接口定义的实用且直观的方法。此外，电子表格的机器和人类可读符号能够将此信息转换为模型库工具中可重用且可版本化的表示。因此，这种方法统一了不同项目和参与合作伙伴之间特定于项目的硬件 - 软件接口定义过程，而不需要采用完全相同的开发工具或流程，这确保了一种替代通常复杂的专用工具的节省成本和时间的方法。

E. 软件 / 软件接口生成器

软件 / 软件接口生成器从建模的硬件 - 软件接口成果生成定义应用软件信号和基础软件信号之间软件 / 软件接口的.c 和.h 文件。这消除了在没有足够语法和语义支持的情况下手动生成软件 / 软件接口的需求，并确保了这些配置的可重复性和可追溯性。此生成器是另一个基于 dll 类库的模型库工具扩展，也可以由其他框架实现或被其他工具重用。

为了评估该方法，选择了（混合）电动汽车电池管理系统（BMS）原型中的中央控制单元（CCU）这一汽车用例。出于商业敏感性原因，项目的具体细节已进行抽象处理。该用例的中央控制单元软件架构由应用软件层上的 10 个软件模块和基础软件层上的 7 个软件模块组成。应用软件模块有 54 个输入和 32 个输出，定义了应用软件层上的 48 个软件 / 软件接口以及到基础软件和硬件连接的 19 个接口。

这总共需要超过 30 行代码（LoC）来进行硬件 / 软件接口定义，使用所提出的方法可以自动生成到 interface.c 和 interface.h 文件中。对应用软件层上的 32 个输出接口和 54 个输入接口的一致性检查可以确保这些信号路由的点对点一致性。对于每个信号 9 个可定义的特征，总共有 774 个定义，使用此方法会自动检查其一致性。

对于这种特定的软件架构，硬件 / 软件接口映射包括 19 个接口。这些映射包括每个引脚 23 个设置，这些设置可以自动导出到电子表格中，并通过导入器功能与模型表示保持一致。这确保了相关开发成果的时效性，并简化了开发决策的追踪。

表 1 总结了所提出的方法为电池管理系统用例提供的额外功能。

表 1：该方法提供的额外功能以及在电池管理系统用例中的出现次数

本文提出了一种符合 ISO 26262 标准的硬件 / 软件接口定义工具方法。该方法双向结合了电子表格工具（如 Excel）的多功能性和直观性以及模型库工具的特性（例如不同视图、抽象级别、信息的中央来源和信息重用）。这使得能够以实用、独立于工具且直观的方法使用电子表格工具设计硬件 - 软件接口定义，并将生成的信息转换为可重用和可版本化的模型表示。电子表格的机器和人类可读符号确保了一种替代通常复杂的专用工具（如 AUTOSAR 工具）的节省成本和时间的方法。此外，通过一个简短的电池管理系统用例，评估了该方法定义符合 ISO 26262 标准的硬件 - 软件接口以及根据这些接口定义自动推导基础软件配置的能力。