1.6 X-in-the-Loop场景设计

X-in-the-Loop方法可集成仿真模型和真实组件，并充分应用现有工具和方法，可充分考虑驾驶员和外界环境对于需求和开发过程的影响。该方法的核心是当测试中出现部件缺失的情况时，利用模型或代码替代缺失部件，实现软硬件结合测试。

构建合适的应用场景是X-in-the-Loop方法的重点之一，因此构建合适且典型的测试场景，确定哪些测试项目可以实现，是应用X-in-the-Loop方法的重要工作。

X-in-the-Loop方法中的Model-in-the-Loop，即模型在环，意指被测对象的存在形式为模型，利用环内其他部件的软件或硬件形式，对模型进行验证和标定。模型在环的测试结果是软件在环的重要参考。Software-in-the-Loop，即软件在环，意指被测对象的存在形式为代码，利用实时仿真平台与环内其他部件的软硬件进行数据交互，从而对代码的准确性进行验证。Hardware-in-the-Loop，即硬件在环，在传统V模式开发中，指实际控制器与虚拟控制对象组成的仿真系统。在X-in-the-Loop方法中，硬件在环的范围由狭义的控制器扩展到广义的硬件，即被测对象的存在形式为硬件，利用环内其他部件的软硬件对被测硬件进行测试验证^[98]。

在燃料电池动力系统的测试验证中，主要涉及的模型包括燃料电池模型、蓄电池模型、DC/DC模型、电机模型、整车模型、控制策略模型、驾驶员模型等，其主要信息见表1.5。

1.6.1 同步性方法设计

由于测试设备包含众多硬件设备，并且硬件设备的通信协议不同。因此还需对测试设备的同步性进行设计。

首先，基于燃料电池汽车动力系统的测试需求，构建出通信架构及网络拓扑，如图1.8所示。该通信架构包括系统协调网络、业务核心网络、数据核心网络、车载兼容网络和设备控制局域网。其中，系统协调网络采用以太网通信，业务核心网络采用MODBUS通信；数据核心网络用于模型数据的通信和燃料电池发动机测试数据的通信，对数据实时性要求较高，因此采用反射内存的通信方式；车载兼容网络采用CAN通信；设备控制局域网络即为测功机和服务器等高速设备与主控系统的通信网络，采用EtherCat通信。

该系统应用NTP（Network Time Protocol，网络时间协议）网络同步技术。NTP是由RFC 1305定义的时间同步协议，用来在分布式时间服务器和客户端之间进行时间同步。NTP基于UDP报文进行传输。使用NTP的目的是对网络内所有具有时钟的设备进行时钟同步，使网络内所有设备的时钟保持一致，从而使设备能够提供基于统一时间的多种应用。对于运行NTP的本地系统，既可以接收来自其他时钟源的同步，又可以作为时钟源同步其他的时钟，并且可以和其他设备互相同步。

设备可以采用多种NTP工作模式进行时间同步，这里选择“客户端/服务器模式”（Client/Server，C/S）。在客户端/服务器模式中，客户端向服务器发送时钟同步报文，服务器端收到报文后会自动工作在服务器模式，并发送应答报文，客户端收到应答报文后，进行时钟过滤和选择，并同步到优选的服务器。

接着，进行系统实时性保障与设计。在一般情况下，一个操作系统负责管理计算机的硬件资源和在计算机上运行的应用程序。该操作系统主要部署在实时性保障计算机中，其对于通信数据和系统状态的判断最终会产生诊断策略和故障信息，指导协调系统解决当前问题。

其次，实施管理配置层在实时测试中将实时操作系统作为测试系统的一部分。与使用通用操作系统相比，推动实时测试系统最常见的需求是需要实现更高的可靠性和更高的性能。

最后，进行同步授时方法与规则的设计。整个系统授时工作是基础性设计，涉及诸多关键数据同步。授时工作主要包含如下部分业务：网络授时协议支持、时间标记、同步时钟（心跳脉冲）。同步授时方法示意图如图1.9所示。

主服务器作为网络通信的服务器和数据库所在地主要负责服务器搭建和数据存储的功能。数据以固定格式和寄存器地址传递，格式中包含数据校验和协议固有特征，在应用层每段数据都由时间标签和有效时间组成。实时性保障计算机校验每段数据自有效性以及相互校验，相互校验过程基于网络设计的冗余性，同时系统状态上通过总线回传心跳脉冲，心跳脉冲是系统同步性和活跃性的重要指标，本系统设计中处于任务状态的执行主机都要发送心跳信号；凡是接入系统的任务主机也要更新心跳信号和状态标识。

1.6.2 Model-in-the-Loop

Model-in-the-Loop（模型在环）的测试验证对象为模型，组成环的其他部分为硬件或软件。可利用动力系统主要部件模型作为测试验证对象，模型运行环境为实时仿真器。当燃料电池模型/蓄电池模型作为测试验证对象时，主控系统将燃料电池模型/蓄电池模型与电源模拟器相连，电源模拟器产生的电能由负载系统（电驱动系统或电子负载）消耗，从而实现燃料电池/蓄电池模型在环。当电驱动系统模型作为被测对象时，电驱动系统需求功率由工况信息决定，该需求功率直接由电源模拟器提供，由负载系统消耗，不受电源模型的电流电压特性约束。

图1.10为一种模型在环典型场景，即燃料电池模型测试验证，该场景利用实时仿真器、电源模拟器和测功机等硬件和蓄电池模型、电驱动模型、整车模型等模型来实现燃料电池模型的验证。工况信息可由驾驶模拟器采集，或由后台数据库提供。主控系统的主要功能为任务调度、运行整车模型与控制策略模型、通信调理等。实时仿真器主要运行动力系统关键部件模型，包括燃料电池及辅助系统和蓄电池等。电源模拟器的主要功能为根据模型数据提供电流电压信号，并向电驱动系统输出。其中燃料电池模型、蓄电池模型、电驱动模型和主控系统中的整车模块（实现整车模型功能），构成了一个完整的燃料电池动力系统模型。

主控系统调用数据库中的工况信息，由主控系统的整车模块计算行驶阻力。根据行驶阻力，由电驱动模型提出功率要求，并由燃料电池发动机模型给出功率响应，该功率响应发往电源模拟器，该电源模拟器根据燃料电池发动机模型的输出特性，产生模拟燃料电池发动机的电压信号，该部分产生的能量由负载系统消耗。若负载系统为电机-测功机系统，则输出实时转速信号，由驾驶员模型根据期望车速和实际车速的差值调整电机转矩。利用此类架构，可实现燃料电池模型的测试验证，特别是燃料电池汽车动力系统的匹配测试，即在燃料电池缺失的情况下，利用模型与电源模拟器，构成完整动力系统。

与全仿真和纯实物测试相比，使用模型在环的测试方法，可完成测试链中部分测试设备实体缺失情况下的测试验证；在测试验证过程中，可充分利用现有测试设备，将被测模型的输出信号输入相关测试设备中，实现模型信号的实时动态检测。

1.6.3 Software-in-the-Loop

Software-in-the-Loop（软件在环）的被测对象为代码，组成环的其他部分为硬件或软件。当被测对象为系统控制策略时，将系统控制策略生成代码，利用软件在环平台，与动力系统模型连接，实现策略验证功能，如图1.11所示。当被测对象为系统控制策略和动力系统模型时，可将系统控制策略与动力系统模型均生成代码，利用软件在环平台验证。当被测对象为动力系统关键部件控制策略时（如电驱动系统），则将该部分控制策略生成代码，其他部分仍为模型。

软件在环测试可进一步实现模型的测试验证，使得被测模型所生成的代码可应用于硬件。软件在环测试举例中，代码和模型均运行在实时仿真器中，在虚拟实时环境中将生成的C代码用于控制部件模型，实现软件在环平台与Simulink仿真平台的联合仿真，借助实时仿真，改进和测试控制策略。

在X-in-the-Loop方法指导下的软件在环，可将代码验证平台与动力系统测试设备连接，将被测代码的输出信号输入相关测试设备中，实现实时动态检测。由于实验条件所限，基于该测试平台的软件在环场景局限于包含被测代码-模型、被测代码-模型代码两类场景。

1.6.4 Hardware-in-the-Loop

Hardware-in-the-Loop（硬件在环）的被测对象为硬件，组成测试环的其他部分为硬件或软件。由于测试手段的软硬件组合方式灵活，可完成多种硬件在环测试验证。

当被测对象为燃料电池发动机或动力蓄电池，即动力源部件时，可调用电源模拟器充当负载，或使用真实的电驱动系统充当负载。当被测对象为电驱动系统时，可利用真实的燃料电池发动机或动力蓄电池，或调用电源模拟器，作为动力源。测试所需其他部件可使用模型或实物。当被测对象为控制器时，该测试场景符合传统意义上的硬件在环，除控制器为实体，其他部分均为模型。

图1.12为基于该测试平台应用的一种硬件在环典型场景，即利用实时仿真器、电源模拟器和测功机等硬件和燃料电池模型/蓄电池模型等模型来实现电驱动系统的匹配与性能测试。

在该类场景下，主控系统从综合数据管理模块调用工况信息，并利用系统控制策略模块和整车模块求得燃料电池发动机和蓄电池的需求功率，电源模拟器根据燃料电池发动机模型和动力蓄电池模型并联后的特性产生电流电压信号，并为电驱动系统提供能量，电驱动系统工作并拖动测功机。利用此类架构可实现在动力源部件缺失的情况下，燃料电池汽车动力系统的电驱动部分的匹配与性能测试。

在X-in-the-Loop方法中，硬件在环的定义由硬件仅指代控制器扩展为硬件指代被测对象，测试链中的其他部分可以为真实对象，也可用模型代替。因此利用X-in-the-Loop方法可构建灵活的硬件在环测试系统，实现动力系统关键部件的匹配和性能测试。

通过以上场景分析可总结：①模型在环：可利用动力系统主要部件模型作为测试验证对象，当燃料电池模型/蓄电池模型作为测试验证对象时，主控系统将燃料电池模型/蓄电池模型与电源模拟器相连，电源模拟器产生的电能由负载系统（电驱动系统或电子负载）消耗，从而实现燃料电池/蓄电池模型在环；②软件在环：当被测对象为系统控制策略时，将系统控制策略生成代码，利用软件在环平台，与动力系统模型连接，实现策略验证功能；③硬件在环：当被测对象为燃料电池发动机或动力蓄电池，即动力源部件时，可调用电源模拟器充当负载，或使用真实的电驱动系统充当负载，当被测对象为电驱动系统时，可利用真实的燃料电池发动机或动力蓄电池，或调用电源模拟器，作为动力源。

1.6.5 X-in-the-Loop在分布式系统框架内的场景用例

根据分布式系统的文献综述可知，在互联网上进行远距离测试验证是可行的。原则上，X-in-the-Loop的每个组件都可以在不同地理位置分布并与其他组件联网。但是，根据验证目标和边界条件，应对X-in-the-Loop框架内的场景用例进行讨论，以便确定应该怎样结合分布式系统与X-in-the-Loop方法，哪些应用使用网络验证是有意义的，以及哪些影响因素对结果产生影响。

文献[112]提出了在分布式系统架构中应用远程连接的三种场景：两系统操作层与操作层的连接，一系统操作层与另一系统业务层的连接，两系统业务层与业务层的连接。

两系统操作层与操作层的连接：该类场景中，主机不仅处理操作层本身的业务功能，同时也完成不同系统之间的通信业务。例如运用主机中的MATLAB/Simulink软件，完成测试与通信业务，MATLAB/Simulink软件与测试台控制软件具有良好的兼容性，可实现建立分布式主机之间的通信，以及实现通信软件对测试设备数据的访问。测试设备软件通常具有与MATLAB/Simulink软件集成的接口，也可用于在线数据传输。大多数情况下不需要额外的硬件和软件且编程工作量较少。主机可能需要额外的网卡来分离与测试设备的通信以及与其他主机的通信。

一系统操作层与另一系统业务层的连接：该情况下，一台主机可以控制多个测试设备，节省了主机的成本。所有涉及的测试设备允许访问中央主机。出于安全等原因，在许多情况下，仍然需要本地主机来监控本地测试设备并在紧急情况下进行本地控制。测试设备的通信发生在中央主机内。因此，必须在主机中实现不同特定测试软件之间的数据交换。

两系统业务层与业务层的连接：该类场景中，由于测试设备的数据处理时间总是在一定的时间间隔内得到保证，因此该类场景的连接是三类场景中最快和最稳定的。但是该类场景下必须为测试设备提供用于在线数据传输的通信接口。由于测试设备的控制应该同时从操作层开始，因此不得中断目标与其自己的主机之间的连接。出于安全原因，交换的信号也应操作层可见。

分析三种场景，可知第一种场景最容易实现，只需将两系统的主机进行连接即可，可实现跨部门和公司使用。第二种场景往往适用于内部使用，第三种场景二者均可使用。

此外，分布式系统应用X-in-the-Loop方法还需考虑以下三个因素：是否需要考虑系统间耦合，将系统整合到本地的成本，以及网络连接。因此根据以上因素，可用图1.13度量分布式系统网络化原则^[113]。