现代汽车系统依赖于分布式ECU在CAN、LIN和汽车以太网等网络上交换数据，使得通信行为对于整个系统功能至关重要。但是,在开发过程中,很少有完整的车辆系统可用,从而限制了工程师验证ECU之间交互的能力。这种情况通常会导致集成延迟、测试覆盖率降低以及后期问题风险增加。
Restbus仿真可重现丢失的网络节点的通信行为，实现真实和可重复的测试环境，从而解决该挑战。随着汽车网络复杂性的提高和基于AUTOSAR的通信的采用,为确保准确、可靠的ECU验证，需要可扩展的数据库驱动方法。NI VCOM直接从车辆数据库中执行基于信号的Restbus仿真，为跨CAN、LIN和汽车以太网环境的ECU验证奠定了一致、可维护的基础。
VCOM剩余总线仿真的精度直接取决于其生成的通信数据的质量。VCOM无需手动开发通信模型，而是直接从车辆通信数据库中执行行为，使数据库成为整个测试环境的基础。
VCOM中的Restbus仿真完全由定义网络、节点、协议数据单元(PDU)、帧、信号、定时和保护规则的通信数据库驱动。VCOM支持DBC、LDF和AUTOSAR ARXML格式。
在现代汽车程序中，AUTOSAR ARXML是Restbus仿真的主要来源，因为它描述了汽车网络上的通信关系。为了进行准确的仿真，VCOM需要包含所有相关通信参与者的系统级提取。ECU提取通常是不够的，因为Restbus的行为取决于传输和接收关系。
实际上，ARXML文件在使用前通常需要检查和清理。VCOM提供了将这些数据库定义转换为可执行Restbus行为的框架，有助于保持测试环境和预期车辆通信架构的一致性。
现代ECU很少单独运行。在HIL和台架测试中，工程师必须重现车辆网络行为，以在现实条件下验证ECU功能。
VCOM是一款为HIL和台架测试系统提供基于信号的Restbus仿真的软件套件。它基于NI-XNET驱动程序层构建，可直接执行来自车辆数据库的通信，再现丢失的网络节点的行为，以便工程师能够在完整的车辆系统可用之前验证ECU功能。通过处理特定协议的详细信息（例如，定时、消息打包和保护机制），VCOM允许工程师专注于ECU验证而不是通信实现。
VCOM使用用于CAN、LIN和汽车以太网的NI-XNET接口在Microsoft Windows PC和NI Linux RT终端上运行，使其可在开发台和基于机架的HIL环境中部署。可选诊断(UDS)和测量与校准(CCP/XCP)工具包进一步扩展了测试自动化功能。
VCOM不是依赖于自定义编码的通信逻辑，而是直接从导入的数据库导出所有传输和接收行为。每个仿真网络节点均按照定义运行，使用配置的网络、定时参数和保护规则，无需工程师手动实现协议行为。
对于CAN，输出帧是通过根据换算、偏移量、位布局、endianness和相关校验和、计数器或AUTOSAR端到端保护对信号值进行编码生成的。输入帧被解码为信号，并可用于测试逻辑、脚本或观察器。消息定时是显式的，包括具有定义周期和偏移量的循环传输，以及由状态改变或外部请求触发的事件驱动传输。
在LIN上，帧调度控制哪些帧出现在哪个插槽中，以什么速率出现。在汽车以太网上，VCOM执行ARXML中定义的SOM/IP通信，包括服务发现、事件传输和调用方法（如适用）。在所有情况下，VCOM执行通信规范，但不执行ECU内部行为。
假设待测发动机控制器从其余总线消耗Motor_Speed，并根据通信规范传输扭矩请求和油门位置消息。
在工作台上，Motor_Speed由Restbus仿真从空闲状态驱动至红线，而外部空气温度模型从冷启动状态转换至正常运行状态。VCOM按照数据库中的定义对所有Restbus通信进行编码和传输，包括定时、换算、计数器和保护。
为了评估鲁棒性，测试引入了受控干扰，5%的Motor_Speed消息被丢弃1秒钟。在通信层可严格遵守成功标准。引擎控制器必须在发生故障后100毫秒内进入定义的安全策略，并在有效流量恢复后200毫秒内恢复正常操作。恢复后，无诊断故障代码可用。
该场景演示了典型的Restbus用例。VCOM提供通信上下文和故障注入点，ECU行为和物理模型则位于Restbus仿真之外。
VCOM支持当前和新兴车辆程序中常用的协议。该覆盖允许单个Restbus环境重现与被测ECU相关的网络行为，而无需为每种协议使用单独的工具。
支持的协议包括CAN、LIN和汽车以太网。对于汽车以太网，根据ARXML中的服务定义（包括所需的服务发现机制）支持SOM/IP通信。J1939支持重型应用中的基本多路复用和网络管理。
发送行为自动源自数据库定义，包括循环、事件驱动和自发消息。VCOM以本机方式执行多路复用PDU、容器PDU和AUTOSAR通信结构，允许无需手动协议编码即可运行复杂的系统定义。计数器信号、CRC和AUTOSAR端到端保护配置文件可在运行时自动生成并评估，从而提供确定性的高性能执行，避免了自定义用户代码通常引入的延迟、CPU负载和维护开销。
信号值可通过API写入或重写，以驱动测试场景，同时系统继续一致地应用保护机制。
车辆程序越来越多地要求在ECU验证期间（而不仅仅是在生产中）存在通信完整性机制并正常运行。VCOM将这些要求作为正常Restbus执行的一部分来处理，而不是作为单独的工程任务来处理。
VCOM实现多个OEM的内置安全板载通信(SecOC)配置文件，并可根据要求提供其他配置文件。根据每个PDU的通信规范自动计算校验和、计数器和AUTOSAR端到端保护信息。
对于需要链路级安全性的汽车以太网设置，支持的NI XNET以太网接口可启用MACsec。在这些配置中，VCOM继续在应用程序和PDU级别运行，而加密和链路保护由驱动程序和硬件透明地处理。
要使被测ECU正常运行，周围的网络必须反映真实的状态转移。不考虑休眠、唤醒和网络模式转换的Restbus环境会产生真实车辆中不存在的测试条件，从而导致误导性结果。
VCOM为数据库中定义的CAN和汽车以太网执行AUTOSAR网络管理行为，确保待测ECU在节点状态转换时感知一致的系统环境。
汽车以太网（如TC10）的物理休眠和唤醒机制由NI XNET驱动程序和支持的硬件处理。VCOM在该层之上运行，对产生的网络状态变化作出反应，而不是直接控制物理唤醒行为。
VCOM旨在集成到现有的HIL和工作台环境中，而不是替换它们。在典型的HIL设置中,VCOM与NI VeriStand或NI LabVIEW等系统级工具一起部署。这些环境通过VCOM API控制测试执行并与运行的Restbus仿真交互。操作包括开始和停止仿真、读取和写入信号值以及响应网络事件。
VCOM提供Restbus仿真层和可选诊断和校准功能。NI-XNET开放物理CAN、LIN和汽车以太网接口，DUT与汽车的连线方式相同。WebUI支持数据库检查和实时流量监控，简化了工作台启动和故障排除。
随着汽车通信网络复杂性的提高,开发和维护Restbus仿真的工作往往成为瓶颈。在许多测试环境中，通信行为是通过自定义脚本或应用程序专用逻辑实现的。虽然此方法对单个工作台有效，但随着通信定义的不断演变，在多个测试系统中保持一致变得越来越困难。
VCOM通过数据库驱动的方法解决了这一难题。通信行为直接从DBC、LDF和AUTOSAR ARXML定义执行，包括信号编码、定时、多路复用、计数器、CRC和AUTOSAR保护机制。当通信需求发生变化时，工程师将更新数据库定义，而不是修改多个测试台之间的通信逻辑。
缩放验证活动时，该方法尤其有用。在开发台上验证的Restbus配置可使用相同的通信定义和行为部署至其他HIL系统。由于通信执行仍与数据库绑定，因此所有工作台均基于同一真实源进行操作，降低了由独立维护的脚本或配置引入的不一致性风险。
VCOM项目在Windows和NI Linux RT终端上运行，并通过通用API与LabVIEW和VeriStand集成。这允许在桌面、基于机架和自动化测试环境中重用通信配置，同时保持一致的网络行为。
随着测试容量的增长，结果不仅提高了吞吐率，而且提高了可重复性和可追溯性。工程可以继续专注于ECU验证和测试覆盖范围，而不是在多个工作台之间维护通信基础设施。
在新工作台上部署VCOM需要一组可预测的早期验证步骤。下列指南反映了常见的启动模式，可帮助团队高效地从初始配置转变为验证的通信行为。
在整个车辆程序中保持精确、一致的Restbus仿真是一项持续的工程挑战，随着通信定义的发展、测试台的增多以及协议复杂度的增加而不断增加。
挑战很少在于通信协议本身。通常，维护仿真逻辑、同步测试台、处理数据库修订，以及跨项目一致地实现协议细节（例如，信号编码、计数器、CRC、网络管理和保护机制）将消耗大量的工程精力。
VCOM通过数据库驱动的通信架构来应对这些挑战。通过直接从DBC、LDF和AUTOSAR ARXML定义中执行通信行为，VCOM为CAN、LIN、汽车以太网、SOM/IP和J1939通信提供了统一的框架，同时自动管理特定协议的行为，例如定时、多路复用、计数器、CRC、AUTOSAR端到端保护和支持的SecOC配置文件。工程团队无需开发和维护自定义通信实现，而是可在单个通信基础上实现标准化，从而与不断发展的汽车网络定义保持一致。
随着验证活动在多个团队、项目和测试环境中的扩展，此架构变得越来越有价值。可在桌面开发系统、HIL工作台和自动化测试基础架构之间部署相同的通信配置、API和自动化工作流程，减少重复，同时有助于在整个验证过程中保持一致。
实际上,这能够实现:
该值超出了仿真网络流量的范围。VCOM提供了可扩展和维护的通信基础，减少了工程开销，提高了验证环境的一致性，并允许团队将精力集中于验证ECU功能而不是管理通信基础设施。