A chassis domain-oriented HIL open system architecture and standardized design method

Abstract

The application relates to the field of automobile electronic control technology, in particular to a chassis domain-oriented HIL open system architecture and a standardized design method.The architecture comprises a measured equipment interface abstraction layer, a test bench resource mapping layer and a software tool adaptation layer; the measured equipment interface abstraction layer is used for the measured part, and converts software interface definition and physical sample installation parameters of a chassis domain electronic control unit into standardized requirements capable of being recognized by a test bench side; the test bench resource mapping layer is used for mapping interface requirements output by the measured equipment interface abstraction layer into configurable execution instructions of specific test bench equipment resources; the software tool adaptation layer is used for encapsulating interaction with HIL software tools and providing a standardized tool calling interface to an upper layer application; the application can solve the problems that, due to coupling of various layers and lack of a standardized mechanism, the existing HIL test system causes measured part access to depend on manual configuration, the system is difficult to transplant across platforms, and repeated development cost is high.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control technology, specifically to an open system architecture and standardized design method for chassis domain HIL. Background Technology

[0002] With the development of vehicle electrification and intelligence, modern chassis systems have evolved into highly integrated and complex electronic control systems, integrating key controllers such as Electronic Stability Program (ESP / ESC), Electric Power Steering (EPS), Electronically Controlled Air Suspension, and Brake-by-Wire, which have stringent requirements for functional safety and real-time performance. Hardware-in-the-loop (HIL) testing, as the core means of developing and verifying chassis domain electronic control units (ECUs), can connect real controllers with virtual vehicle models in a controlled laboratory environment to complete key tasks such as control strategy verification, fault injection testing, and automated testing.

[0003] Meanwhile, the software development of chassis domain ECUs has generally followed the AUTOSAR specification, with highly standardized signal names and interface definitions. Although HIL testing is widely used, existing technologies still have the following shortcomings in their architectural design: Current HIL bench designs do not use the pre-defined AUTOSAR interface definitions on the ECU side as standardized inputs for bench design. Instead, they still rely on manually configuring bench interfaces by consulting ECU manuals item by item. When faced with ECUs from different vehicle models or platforms, engineers need to perform repetitive interface parsing and configuration work, which is inefficient, error-prone, and highly dependent on engineer experience.

[0004] Existing standards such as ASAM and XIL only define abstract interfaces for the test framework at the API level, but do not penetrate to the physical layer. Operations such as fault injection ("ECU Pin_A short circuit to ground for 100ms") and sensor simulation ("motor speed signal simulation 0-6000rpm") still rely on manufacturer-specific instruction formats or scripting languages, making them impossible to express across platforms. Once a test script contains physical layer operation descriptions, it becomes strongly bound to a specific hardware platform, making test code difficult to reuse when replacing or upgrading HIL hardware, resulting in high migration costs.

[0005] The components tested in the chassis domain HIL (High-Intensity Interchange) test include not only ECUs but also actual physical samples provided by OEMs (such as steering assemblies, brake calipers, and shock absorber struts). The mounting hole positions, bolt locations, and hole diameters of these samples are entirely determined by the OEM's mechanical design and are not constrained by electronic architecture standards such as AUTOSAR. Existing HIL benches require the separate design and fabrication of mounting fixtures for each sample, necessitating redesign and fabrication when changing OEMs or vehicle models. The mechanical mounting system becomes the biggest repetitive bottleneck in bench construction, resulting in high physical integration costs, long cycles, and slow response times. Summary of the Invention

[0006] The purpose of this invention is to propose an open system architecture and standardized design method for chassis domain HIL, which can solve the problems of existing HIL test systems, such as the dependence on manual configuration for accessing the device under test, difficulty in cross-platform portability, and high cost of repeated development, due to the coupling of each layer and the lack of standardization mechanism.

[0007] To achieve the above objectives, in a first aspect, the present invention proposes an open system architecture for chassis domain HIL, comprising: an interface abstraction layer for the device under test, a bench resource mapping layer, and a software tool adaptation layer; The interface abstraction layer of the device under test is used to convert the software interface definition of the chassis domain electronic control unit and the installation parameters of the physical sample into standardized requirements that can be recognized by the test bench. The bench resource mapping layer is used to map the interface requirements output by the interface abstraction layer of the device under test into configurable executable instructions for specific bench equipment resources. The software tool adaptation layer is used to encapsulate the interaction with HIL software tools and provide standardized tool call interfaces for upper-layer applications. The device under test interface abstraction layer, bench resource mapping layer, and software tool adaptation layer communicate with each other through a standardized data interaction protocol.

[0008] The beneficial effects of the basic solution: This invention divides the chassis domain HIL test system into three independent layers: the device under test (DUT) interface abstraction layer, the bench resource mapping layer, and the software tool adaptation layer. Each layer has a single responsibility and clear boundaries, changing the closed architecture of existing HIL systems where the DUT description, bench resource configuration, and tool interaction logic are deeply coupled. When a certain layer changes (such as replacing the DUT, adjusting bench equipment resources, or replacing software tools), only the corresponding layer needs to be adjusted locally, while the other layers can remain unchanged, reducing the cost and risk of system maintenance and upgrades.

[0009] The Device Under Test (DUT) Interface Abstraction Layer (IUPAL) unifies the software interface definitions and physical prototype installation parameters of chassis domain electronic control units (ECUs) into standardized requirements recognizable by the test bench. This allows chassis domain ECUs and physical prototypes with varying forms and interface definitions to be recognized and accepted by the test bench in a unified, standardized manner. This solves the problem of needing to customize interface adaptations for each different DUT when connecting to the HIL test bench, shortens the test bench connection cycle for new DUTs, and improves the test bench's compatibility with diverse DUTs.

[0010] The bench resource mapping layer automatically maps standardized interface requirements to configurable executable instructions for specific bench equipment resources, separating requirements from implementation: the upper layer only needs to express what is needed, and the mapping layer handles which device and how to implement it. This allows the same set of standardized requirements to be flexibly mapped to bench equipment resources of different sizes and from different vendors. When bench hardware resources are expanded or replaced, there is no need to modify the upper-layer application, improving the resource configuration flexibility and reusability of the testing system.

[0011] The software tool adaptation layer encapsulates the interaction details with various HIL software tools, providing standardized tool call interfaces to upper-layer applications and shielding them from the differences in interface protocols and operation methods among different HIL software tools. Upper-layer application and test developers do not need to master the private interfaces of each tool to carry out testing work. On the one hand, this lowers the threshold for use and learning costs, and on the other hand, it makes the testing system no longer tied to a specific HIL software tool, possessing cross-tool portability.

[0012] The three layers communicate via a standardized data interaction protocol, rather than through private, coupled calls, ensuring the consistency, standardization, and verifiability of data interaction between layers. Each layer can be independently developed, upgraded, or replaced according to the standardized protocol, supporting third parties to access and replace components in a specific layer according to the protocol. This enhances the openness of the overall architecture, forming a technical system of "open architecture + standard protocol," laying the foundation for building a composable and scalable chassis domain HIL testing ecosystem.

[0013] As a feasible preferred embodiment, the device under test interface abstraction layer includes: The chassis domain device under test interface template library contains pre-set standard interface templates for three types of devices under test: braking, steering, and suspension. Each template includes an electrical interface template and a physical installation parameter module. The electrical interface template is based on the AUTOSAR software component interface description of the corresponding electronic control unit type, defining the general requirements specifications for bus, power supply, and hard-wired signals. The physical installation parameter template records the typical external dimensions and installation methods of the physical sample. The bench resource mapping engine is used to read the description file of the electronic control unit under test, extract the software component port definition, bus signal attribute and hardwire signal attribute, and match them with the electrical interface templates in the chassis domain device under test interface template library to automatically generate the bench electrical interface resource list required by the electronic control unit.

[0014] As a feasible preferred embodiment, the bench resource mapping engine includes: The ARXML parsing module is used to load and verify ARXML files, traverse the XML document object tree to extract software component identifiers, port lists, controller LAN packets and signal attributes, hard-wired signal attributes, establish the mapping relationship between signals and software component ports, and output the electronic control unit signal set. The template matching and difference recognition module is used to normalize the names and calculate the similarity between the parsed signal set and the standard signals in the template library, constructing a matching set, a template non-matching set, and an electronic control unit non-matching set, and calculating the signal difference using the following formula:

[0015] in, This represents the number of elements in the collection that the template did not match. The number of unmatched elements in the set for the electronic control unit. For template signal set, This is a set of ECU signals; based on the comparison result between the difference and a preset threshold, it determines whether the matching is successful or unsuccessful, and outputs a matching report; The electrical interface resource requirement generation module is used to generate corresponding bench resource requirement entries based on the signal categories and attribute sets in the matching report, and output a set of resource requirements. The bench resource allocation module is used to allocate the demand items in the resource demand set to the available resource pool defined in the bench configuration description file based on the constraint-optimal adaptive decreasing allocation algorithm, and generate a resource allocation table.

[0016] As a feasible preferred embodiment, the bench resource mapping layer includes: The Hardware-in-the-Loop Interface Description Language (HIL) parsing engine is used to interpret and execute physical interface description scripts written in HIL. The scripts use a common syntax to uniformly describe physical layer operations such as fault injection, sensor simulation, and load simulation, and are decoupled from specific hardware devices. The interface resource mapper is used to receive the list of rack interface resources and match the interface requirements to the specific hardware channels of the rack according to the resource allocation rules defined in the rack configuration description file. A standardized rack resource pool defines the standard interface specifications for various hardware resources in the rack. The physical mounting fixture system is a self-assembly, multimodal, modular mechanical fixing platform, comprising a base frame, adjustable support arms, and standardized mounting holes for fixing physical prototypes and electronic control units to the platform.

[0017] As a feasible preferred embodiment, the software tool adaptation layer includes: The simulation modeling tool interface is used to encapsulate the controlled object model loading and parameter configuration interface of the modeling tool, and realizes the loading and running of the model in different HIL platform software environments through a standardized model configuration description format. The test management tool interface is used to encapsulate the test case loading and execution interface of the test management tool, translating the platform-independent abstract description of test cases into executable scripts of the target tool; The bus monitoring tool interface is used to encapsulate the bus signal observation and calibration interface of the bus monitoring tool, providing a unified signal read and write channel; The Real-Time Execution Environment (RTE) interface is used to encapsulate the target machine deployment and operation control interface of the RTE.

[0018] As a feasible and preferred option, the standardized data interaction protocol includes: The interface requirement description format message is generated by the interface abstraction layer of the device under test and sent to the bench resource mapping layer. It includes basic information of the device under test, a list of electrical interface requirements, a set of physical installation parameters, a list of fault injection requirements, and a summary of template matching results. The resource configuration description format message is generated by the bench resource mapping layer and sent to the software tool adaptation layer. It includes a resource allocation result list, an unallocated resource requirement list, hardware-in-the-loop interface description language compilation artifacts, configuration mapping tables of each software tool, and fixture system adjustment parameters.

[0019] Secondly, the present invention also provides a standardized design method for a chassis domain HIL open system, applied to the aforementioned chassis domain HIL open system architecture, comprising the following steps: Perform description file parsing to extract the full signal set of the electronic control unit; Perform template matching and difference identification, match the parsed signal set with the standard templates in the chassis domain test device interface template library, calculate the signal difference degree and output a matching report; Physical sample installation parameters are collected, the actual installation hole coordinates, hole diameter and external dimensions of the physical sample are measured, and the data are entered into the template library of the equipment under test; Generate a list of electrical interface resource requirements, and generate bench resource requirement entries based on the signal categories and attributes in the matching report; Perform bench resource allocation, and allocate resource requirements to the available resource pool based on the constraint-optimal adaptive decreasing allocation algorithm to generate a resource allocation table; Generate standardized interface requirement description messages and transmit them between layers to the rack resource mapping layer; Generate a hardware-in-the-loop interface description language script and compile it to generate a sequence of hardware instructions executable by the target platform; Generate adjustment parameters for a self-assembling multimodal fixture system, and calculate the support arm position and orifice plate selection for a modular mechanical fixing platform; Generate standardized resource configuration description messages and transmit them between layers to the software tool adaptation layer; Complete software tool adaptation and full system deployment, and configure simulation modeling, test management, bus monitoring and real-time execution environment through standardized tool interfaces.

[0020] As a feasible and preferred approach, the specific process for calculating signal difference and outputting a matching report includes: Perform name normalization preprocessing on all signal names in the signal set and template; Calculate signal similarity and construct matching sets, template mismatch sets, and electronic control unit mismatch sets; Calculate the signal according to the formula. :

[0021] in, This represents the number of elements in the collection that the template did not match. The number of unmatched elements in the set for the electronic control unit. For template signal set, For ECU signal set; If the difference is less than or equal to the preset threshold, the match is considered successful, and the unmatched signals are marked as missing general standard signals or newly added non-standard signals respectively; if the difference is greater than the preset threshold, the match is considered unsuccessful, and a new domain template draft is automatically generated.

[0022] As a feasible and preferred solution, the specific process of resource allocation based on the constrained optimal adaptive decreasing allocation algorithm includes: Pre-screen and prioritize resource requirements; Define a compatibility check function to verify the type matching and specification compatibility between the requirement items and the resource items; Sort the resources by priority from high to low to obtain a high-priority demand queue. Iterate through the high-priority demand queue and select the resource with the smallest number of remaining channels from the resources that meet the compatibility check and have a greater than 0 number of remaining available channels, but still fully meet the requirements, for allocation. Process unassigned requests and generate a list of unassigned requests that includes reason codes and recommended solutions.

[0023] As a feasible and preferred solution, it also includes interactive steps during the operational phase after the entire system is deployed: Initiate a periodic heartbeat survival mechanism between different layers; During the runtime phase, inter-layer interaction switches to an asynchronous publish-subscribe mode. The bench resource mapping layer publishes hardware resource status change events in real time through the event bus. The software tool adaptation layer subscribes to the event and performs corresponding test control operations according to the event type. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of an architecture for a chassis domain HIL open system.

[0025] Figure 2 This is a logical diagram of a standardized design method for chassis domain HIL open systems. Detailed Implementation

[0026] To make the technical solution and advantages of this application clearer, the technical solution of the present invention will be further described in detail below with reference to the accompanying drawings. It is understood that the specific embodiments described herein are only some embodiments of the present invention, and are only used to explain this application, not to limit it. It should be noted that the technical features or combinations of technical features described in the following embodiments should not be considered isolated; they can be combined with each other to achieve better technical effects. The same reference numerals appearing in the accompanying drawings of the following embodiments represent the same features or components, and can be applied to different embodiments.

[0027] Furthermore, unless otherwise defined, the technical or scientific terms used in this invention description shall have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains.

[0028] The present invention will now be described in further detail with reference to the accompanying drawings.

[0029] Reference Figure 1 This embodiment provides an open system architecture for chassis domain HIL, including a device under test interface abstraction layer, a bench resource mapping layer, and a software tool adaptation layer.

[0030] The interface abstraction layer of the device under test (DUT) is directed towards the DUT. The AUTOSAR signal definitions of the chassis domain (DCU) electronic control unit and the installation parameters of the physical sample are converted into standardized requirements that can be identified on the bench side, including the chassis domain DUT interface template library and the bench resource mapping engine.

[0031] The chassis domain's interface template library for devices under test (DUTs) includes pre-set standard interface templates for three types of DUTs: braking, steering, and suspension. Each template includes an electrical interface template and a physical installation parameter module.

[0032] The electrical interface template is based on the AUTOSAR software component interface description of the corresponding electronic control unit type, defining the general requirements specifications for the controller area network (CAN) bus, power supply, and hardwired signals.

[0033] The physical installation parameter template records the typical dimensional ranges and common installation methods (bracket mounting / flange mounting / shaft mounting, etc.) of common physical components (such as steering gear assemblies, brake calipers, and shock absorbers) as a reference for initial fixture configuration. The physical installation parameters are not constrained by AUTOSAR; the template only provides industry-statistical reference values, and the actual measured dimensions of the components shall prevail.

[0034] The bench resource mapping engine reads the ARXML description file of the electronic control unit under test (ECU), extracts the software component (SWC) port definitions, Controller Area Network (CLAN) signal attributes (ID, period, DLC, signal list), and hardwired signal attributes (level, type, precision), and matches them with electrical interface templates in the chassis domain ECU interface template library to automatically generate the bench electrical interface resource list required for the ECU. Because the AUTOSAR signal naming and attributes of chassis domain ECUs are highly consistent, ECUs of the same type from different OEMs can use the same template for mapping, requiring only minor parameter adjustments. The following details the engine's four core algorithms.

[0035] The ARXML (AUTOSAR XML, AUTOSAR Extensible Markup Language) parsing algorithm takes the ARXML file path P of the electronic control unit under test as input. arxml The execution steps are as follows.

[0036] Load the ARXML file and perform XML schema validation (based on the AUTOSAR 4.x official standard schema definition file). If the validation fails, throw an "ARXML file parsing exception" error.

[0037] Traverse the XML document object tree, locate the software component element, and extract the short name of the software component as the unique logical identifier of the electronic control unit.

[0038] Iterate through all prototypes that provide ports <p-port-prototype>and demand port prototype <r-port-prototype>The sub-element extracts the short name (signal name) and type (associated interface type reference) of each port to construct the port list P. list .

[0039] Traverse the controller LAN cluster <can-cluster>→ Controller Area Network (LAN) Communication Connector Path <can-communication-connector>Extract the identifier (CAN ID), cycleTime (message transmission cycle), and dlc (data length code, message byte length) of each frame of the Controller Area Network (CAN) message, as well as each CAN signal within the frame. <can-signal>The signal name is signalName, startBit is startBit, length is data length, factor is scale factor, offset is offset, and unit is physical unit.

[0040] Traversal <i-signal-to-i-port-mapping>The association table establishes the mapping relationship between controller LAN signals and software component ports.

[0041] Traverse the physical channel definition elements of the hardwire interface ( <physical-channel>The element (if it exists in ARXML) extracts the channel name, signal type (analog / digital / pulse width modulation PWM), voltage range, and resolution of the hard-wired signal.

[0042] Output: Electronic control unit signal set Each signal = (name, category, attributes), where category ∈ {Controller Area Network (CAN), Analog Input (ANALOG_IN), Analog Output (ANALOG_OUT), Digital Input (DIGITAL_IN), Digital Output (DIGITAL_OUT), Pulse Width Modulation Input (PWM_IN), Pulse Width Modulation Output (PWM_OUT)}. The physical attribute set of this signal includes type, range, precision, and unit.

[0043] The algorithm has a time complexity of O(n), where n is the total number of nodes in the ARXML document object model tree.

[0044] Template matching and difference recognition algorithm, input to the set of electronic control unit signals S obtained through parsing. e The corresponding type of template T in the chassis domain device under test interface template library e = {t1, ..., t M (M is the number of standard signals in the template), the execution steps are as follows.

[0045] Name normalization, for S e and T e All signal names undergo a unified preprocessing operation, removing all underscore characters, converting all characters to lowercase, and expanding all industry-standard abbreviations, such as automatically completing "VehSpd" to "VehicleSpeed". After preprocessing, a normalized name field is stored for each signal.

[0046] Similarity calculation is performed for each template signal t in T_e. j In S e Search for the corresponding signal s in the template whose normalized name is exactly the same, whose category is exactly the same, and whose signal attributes are compatible (e.g., the voltage range of the electronic control unit signal falls exactly within the allowable range defined by the template). {e,i} If no perfect match is found, the most similar candidate is calculated using the edit distance (Levenshtein distance), with a similarity threshold of 0.85.

[0047] Construct a signal matching set, which includes all perfectly matched signal pairs (t) j , s {e,i} Add to matching set M pairs Signals in the template that cannot be matched in the electronic control unit signal set are recorded in the template mismatch set U. template Signals that fail to find a matching match in the general template from the signals parsed by the electronic control unit are recorded in the electronic control unit's unmatched set U. ecu .

[0048] Calculate the difference degree using the formula:

[0049] in, This represents the number of elements in the collection that the template did not match. The number of unmatched elements in the set for the electronic control unit. For template signal set, This is the set of ECU signals.

[0050] In the result determination and branching, if Δ ≤ preset threshold θ (a value of 0.3 is recommended in this embodiment), the match is considered successful. Signals in the template mismatch set are marked as "a missing general standard signal for this electronic control unit" (generally due to OEM function cutoffs), and signals in the electronic control unit mismatch set are marked as "a newly added non-standard signal for this electronic control unit" (it needs to be confirmed whether special test bench resources are required). A matching report is output, including the set of matched signal pairs, the template mismatch set, the electronic control unit mismatch set, the difference value, and a matching success indicator.

[0051] If Δ>θ, the matching is deemed to have failed, triggering a "template matching difference exceeds threshold" alarm. A new domain template draft is automatically generated and named in the format "corresponding electronic control unit type_draft". All unmatched signals are marked as "pending manual annotation". After the engineer confirms the signal attributes, the template is stored in the template library. Existing templates can still be used in the subsequent mapping process of matched signals.

[0052] The algorithm has a time complexity of O(N). e ×M), which is the product of the total number of signals of the electronic control unit and the total number of template signals.

[0053] The algorithm for generating electrical interface resource requirements takes as input data a matching report (successful matching status) and a set of matching pairs. The execution steps are as follows.

[0054] For each matching pair (t) in the matching set j , s {e,i} According to s {e,i} Based on the category and attribute set, generate a rack resource requirement entry: If the signal type is Controller Area Network: Generate Controller Area Network channel requirements, specifying baud rate, terminating resistor configuration, and number of channels; If the signal type is analog input / analog output: generate analog channel requirements, specifying voltage range, resolution, and sampling rate parameters; If the signal type is digital input / digital output: generate digital channel requirements, specify the voltage level, and whether bidirectional transmission parameters are supported; If the signal type is pulse width modulation input / pulse width modulation output: generate pulse width modulation channel requirements, specifying frequency range, duty cycle range, and voltage level parameters.

[0055] For each unmatched signal in the set of unmatched electronic control units, generate a labeled requirement item, mark it as "awaiting manual confirmation", and require engineers to confirm the specific attributes of the signal and the corresponding bench resource requirements; For each missing signal in the template mismatch set, generate an optional class requirement entry and mark it as "optional configuration"; Output: Resource requirement set REQ = {req1, ..., req} K }, where K is the total number of requirement items, and the value of K is approximately equal to the total number of signals N of the electronic control unit. e .

[0056] The bench resource allocation algorithm (Constrained Best-FitDecreasing) takes as input a resource requirement list (REQ) and an available resource pool (R) obtained by parsing the bench configuration description file. pool = {r_1, ..., r_M}, where each resource r k Includes attributes (type, spec, C) k C k To determine the remaining available channels, follow these steps.

[0057] Pre-screening temporarily moves all requirements in the REQ with a status of OPTIONAL to the candidate requirement queue Q. optional The remaining demands are sorted in descending order according to resource demand priority (e.g., voltage accuracy requirements from high to low, sampling rate requirements from high to low) to obtain a high-priority demand queue Q. required .

[0058] A compatibility check function is defined, which is a boolean type check function that takes requirement items and resource items as inputs. Check whether the required resource type matches the resource item type exactly; If the resource type is analog: check that the voltage range of the demand is completely contained within the voltage range of the resource, and that the resolution index of the demand is better than or equal to the resolution index of the resource. If the resource type is Controller Area Network: check that the required baud rate is exactly equal to the baud rate of the resource, or that the resource itself supports dynamic multi-rate configuration. If the resource type is pulse width modulation: check if there is a non-empty intersection between the frequency range of the requirement and the frequency range of the resource; return true if all conditions are met, and return false if any condition is not met.

[0059] The optimal allocation strategy iterates through each requirement in the high-priority requirement queue and then through all resources in the resource pool that meet the compatibility check and have a remaining available channel count greater than 0. It selects the resource with the smallest remaining channel count that still fully satisfies the requirement. This strategy prioritizes filling partially used resources to avoid resource fragmentation. After finding a suitable resource, it assigns the corresponding channel ID to the requirement, updates the remaining available channel count for that resource, and records the allocation entry (requirement ID, resource ID, channel ID, channel availability), where the channel availability is... The calculation formula is:

[0060] in, This is the upper limit of the specification. Demand value, Maximum size.

[0061] To handle unassigned requirements, after traversing all unassigned requirements (including those that cannot be satisfied in the high-priority queue and some requirements in the optional queue), a set of unassigned requirements is generated. Each entry is accompanied by a corresponding reason code, with possible values ​​for the reason code being {no compatible resources, all channels are occupied, specifications do not match}.

[0062] The output is a complete resource allocation table, including a list of allocated resources and a list of unallocated requirements (each item is accompanied by a corresponding reason code and recommended solution).

[0063] The algorithm has a time complexity of O(K log K + K×M), where the time complexity of the sorting operation is O(K log K) and the time complexity of the allocation operation is O(K×M).

[0064] For physical installation parameter acquisition, for physical samples (steering gears, brake calipers, shock absorbers, etc.), operators measure the actual mounting hole coordinates, hole diameters, and external dimensions of the sample and enter them into the physical installation parameter table of the tested equipment template library. This step is outside the coverage of the AUTOSAR standard and requires manual operation. The measured data will be used for calculating the support arm position of the drive fixture system and selecting the orifice plate.

[0065] The bench resource mapping layer is an intermediate layer of HOSAR (HIL Open System Architecture) used to map the interface requirements output by the interface abstraction layer of the device under test into configurable executable instructions for specific bench device resources.

[0066] The Hardware-in-the-Loop Interface Description Language (HIDL) parsing engine is used to interpret and execute physical interface description scripts written in HIDL. This language provides a general syntax for uniformly describing physical layer operations such as fault injection, sensor simulation, and load simulation, decoupling them from specific hardware devices.

[0067] The Hardware-in-the-Loop Interface Description Language (HIL) reserves a set of keywords: all keywords have exclusive semantics in the script and are prohibited from being used as custom identifiers. Keyword classification and semantic descriptions are shown in Table 1.

[0068] Table 1:

[0069] The interface resource mapper receives the bench interface resource list generated by the mapping engine and, according to the resource allocation rules defined in the bench configuration description file (HOSAR-BDF, HOSAR Bench Description File), matches each interface requirement (e.g., "ECU brake pedal sensor signal, analog 0-5V, accuracy ±5mV") to a specific hardware channel on the bench (e.g., "NI PXI-6229 board, channel AI0, range ±10V"). This includes a standardized bench resource pool and a physical mounting fixture system. The standardized bench resource pool defines the standard interface specifications for various hardware resources in the bench, including power interfaces (electrical specifications, protection characteristics), fault injection box interfaces (switch matrix configuration, short circuit / open circuit type support), hard-wired signal interfaces (analog, digital, pulse width modulation type definition), and controller area network bus interfaces (channel allocation, terminating resistor configuration).

[0070] The physical mounting fixture system is a self-assembly, multimodal, modular mechanical fixing platform, consisting of a base frame, adjustable support arms, and standardized mounting hole plates. It is used to physically fix physical prototypes and electronic control units (ECUs) to the bench. Physical prototypes include steering gear assemblies, brake calipers, and shock absorbers. The support arms can be freely adjusted in the X, Y, and Z directions along the slide rails of the base frame. The mounting hole plates provide standard screw holes with various diameters and spacings. Unlike traditional custom fixtures designed for single ECUs, this fixture system is designed for any real physical prototype in the chassis domain—whose mounting hole positions are entirely determined by the OEM's mechanical design and are not constrained by AUTOSAR—covering this uncertainty through mechanical adjustability. The adjustment parameters of the fixture system (coordinates of each support arm, hole plate selection, number and distribution of support arms) are recorded in the bench configuration description file according to the prototype model. The general design parameters of the fixture system are shown in Table 2.

[0071] Table 2:

[0072] The HOSAR BDF (Hospital-In-the-Loop Configuration Description File) is a rack resource description file based on a structured data format (such as YAML / JSON). It records the type, model, channel capacity, and current allocation status of each device in the rack. The BDF file is key to HOSAR's platform independence. When changing the HIL platform, only the part of the BDF file corresponding to the specific hardware needs to be updated; the upper-layer device-under-the-loop interface template, mapping rules, and hardware-in-the-loop interface description language script do not need to be modified.

[0073] The software tool adaptation layer encapsulates the interaction with specific HIL software tools and provides standardized tool calling interfaces to upper-layer applications, including simulation modeling tool interfaces, test management tool interfaces, bus monitoring tool interfaces, and real-time execution environment interfaces.

[0074] This simulation modeling tool interface encapsulates the controlled object model loading and parameter configuration interfaces for modeling tools such as MATLAB / Simulink and CarSim. Through a standardized model configuration description format (HOSAR-MCF), it enables the same controlled object model (such as a vehicle dynamics model) to be loaded and run in different HIL platform software environments.

[0075] The test management tool interface encapsulates the test case loading and execution interfaces for test management tools such as ECU-TEST and TestStand. Test cases are written in platform-independent abstract descriptions (such as test description formats based on ASAM XIL API or HOSAR), and are translated into executable scripts for the target tool by the adaptation layer.

[0076] The bus monitoring tool interface is used to encapsulate the Controller Area Network (CAN) signal observation and calibration interface of bus monitoring tools such as CANape and TSmaster, providing a unified CAN signal read / write channel and shielding the differences in application programming interface (API) between different tools.

[0077] The Real-Time Execution Environment Interface is used to encapsulate the target machine deployment and operation control interfaces for real-time execution environments such as VeriStand and Simulink Real-Time.

[0078] Inter-layer data interaction protocol and exception handling: The HOSAR three-layer architecture communicates loosely through a standardized data interaction protocol. The data format, calling relationship and exception handling mechanism between each layer are defined as follows.

[0079] The interface abstraction layer of the device under test and the bench resource mapping layer: Interface requirement description format. After the device under test completes ARXML signal parsing, template matching and physical sample parameter acquisition, it transmits the interface resource requirements to the bench resource mapping layer in a structured message. The message adopts JSON Schema definition, and the core common fields are shown in Table 3 below.

[0080] Table 3:

[0081] The IRD (Interface Requirement Description) message is automatically generated by the mapping engine after step 3 and sent to the interface resource mapper of the rack resource mapping layer in a synchronous request-response mode via the internal message bus (supporting ZeroMQ REQ-REP mode or DDS RTPS protocol).

[0082] Bench Resource Mapping Layer and Software Tool Adaptation Layer: Resource Configuration Description Format (RCD) After the bench resource mapping layer completes resource allocation and HIDL compilation, it transmits the complete deployable configuration to the software tool adaptation layer via RCD messages. RCD also uses JSON Schema for definition, with core fields shown in Table 4.

[0083] Table 4

[0084] The call relationships and timing, the interactions between the three layers follow the following call pattern: The configuration phase follows a synchronous request-response pattern: The software tool adaptation layer initiates a request to build the test environment → The interface resource mapper of the bench resource mapping layer queries the bench configuration description file and calls the interface abstraction layer conversion engine of the device under test to generate the interface requirement message → The matcher performs resource allocation and calls the hardware-in-the-loop interface description language parsing engine to complete the compilation → A complete resource configuration message is returned. The entire configuration chain operates in synchronous blocking mode, with a preset timeout threshold of 30 seconds.

[0085] Asynchronous publish-subscribe mode during runtime: The bench resource mapping layer publishes hardware resource status change events in real time via the event bus (event topic: "Bench / Resource / Status"). The test management tool interface of the software tool adaptation layer subscribes to this event topic and determines whether to execute a pause test sequence based on the event type (channel failure, over-temperature protection, communication link interruption). A general heartbeat keep-alive mechanism is in place: each layer maintains a periodic heartbeat signal. The heartbeat period between the device under test interface abstraction layer and the bench resource mapping layer is set to 500ms, and the heartbeat period between the bench resource mapping layer and the software tool adaptation layer is set to 200ms to meet higher real-time requirements. The heartbeat message format is {layer identifier, message sequence number, timestamp, status code}, and the status code can be {normal, performance degradation, busy, error}.

[0086] The exception handling mechanism, with all exception codes and corresponding handling strategies serving as mandatory interface specifications for the implementation of each layer of this open architecture, as shown in Table 5, ensures that the behavior of compatible components developed by different vendors under abnormal scenarios is completely predictable.

[0087] Table 5:

[0088] Reference Figure 2 This invention also provides a standardized design method for chassis domain HIL open systems, including the following steps.

[0089] Step S1: Perform ARXML file parsing to extract the full signal set of the ECU. This is accomplished by the ARXML parsing algorithm in the AUTOSAR signal → bench resource mapping engine, with an algorithm complexity of O(n), where n is the total number of nodes in the ARXML DOM tree. The detailed operation process is as follows: Input the ARXML file paths P of the three tested ECUs arxml Perform the following parsing operations independently on the files of each ECU: Load the ARXML file and perform XML schema validation (based on the AUTOSAR 4.x official standard schema definition file). If validation fails, throw an "ARXML file parsing exception" error. Return the specific location of the syntax error (line number, element tag name, expected data type), prompt the user to check the file integrity and AUTOSAR Schema version compatibility. This step aborts execution and does not enter the degraded running mode.

[0090] Traverse the XML document object tree to locate software components <swc>The element extracts the short name of the software component as the unique logical identifier for the electronic control unit.

[0091] Traverse all <p-port-prototype>and <r-port-prototype>The sub-element extracts the shortName (signal name) and type (associate interface type reference) of each port to construct a complete port list P. list .

[0092] Traverse the controller LAN cluster <can-cluster>→ Controller Area Network (LAN) Communication Connector Path <can-communication-connector>Extract the identifier (CAN ID), cycleTime (message transmission cycle), and dlc (data length code, message byte length) of each frame of the Controller Area Network (CAN) message, as well as each CAN signal within the frame. <can-signal>The signal name is signalName, startBit is startBit, length is data length, factor is scale factor, offset is offset, and unit is physical unit.

[0093] Traversal <i-signal-to-i-port-mapping>The association table establishes a one-to-one mapping relationship between CAN signals and SWC ports.

[0094] Traverse the physical channel definition elements of the hardwire interface ( <physical-channel>The element (if it exists in ARXML) extracts the channel name, signal type (analog / digital / pulse width modulation PWM), voltage range, and resolution of the hard-wired signal.

[0095] Output electronic control unit signal set Each signal = (name, category, attributes), where category ∈ {Controller Area Network (CAN), Analog Input (ANALOG_IN), Analog Output (ANALOG_OUT), Digital Input (DIGITAL_IN), Digital Output (DIGITAL_OUT), Pulse Width Modulation Input (PWM_IN), Pulse Width Modulation Output (PWM_OUT)}. The physical attribute set of this signal includes type, range, precision, and unit.

[0096] After performing ARXML parsing on the braking ECU, steering ECU, and suspension ECU respectively, we obtain the independent signal sets S for each of the three ECUs. e_br S e_st S e_sp .

[0097] Step S2 involves performing template matching and difference recognition, and outputting a matching report. This is accomplished by the template matching and difference recognition algorithm, which has a complexity of O(Ne × M), which is on the order of the product of the number of ECU signals and the number of template signals. The detailed operation process is as follows: The set of analytical signals S for each ECU e Load the corresponding type of standard electrical interface template T from the chassis domain device under test interface template library. e = {t1, ..., t M }, where M is the total number of standard signals defined in the template; Perform name normalization preprocessing operation on S e and T e All signal names are preprocessed uniformly, removing all underscores, converting all characters to lowercase, and expanding all common abbreviations, such as automatically expanding VehSpd to VehicleSpeed. After preprocessing, the normalized norm_name field is stored for each signal. Perform similarity calculation: T e Each template signal t in j In S e Search for the corresponding signal s in the template whose normalized name is exactly the same, whose category is exactly the same, and whose signal attributes are compatible (e.g., the voltage range of the electronic control unit signal falls exactly within the allowable range defined by the template). {e,i} If no perfect match is found, the most similar candidate is calculated using the edit distance (Levenshtein distance). In this embodiment, the similarity threshold is set to 0.85.

[0098] Construct three sets of signals, and then select all perfectly matched signal pairs (t). j , s {e,i} Add to matching set M pairs Signals in the template that cannot be matched in the electronic control unit signal set are recorded in the template mismatch set U. template Signals that fail to find a matching match in the general template from the signals parsed by the electronic control unit are recorded in the electronic control unit's unmatched set U. ecu .

[0099] The signal difference Δ is calculated using the following formula:

[0100] in, This represents the number of elements in the collection that the template did not match. The number of unmatched elements in the set for the electronic control unit. For template signal set, This is the set of ECU signals.

[0101] The branch decision is executed based on the value of Δ: If Δ ≤ preset threshold θ (a value of 0.3 is recommended in this embodiment), the match is considered successful. Signals in the template mismatch set are marked as "a missing general standard signal for this electronic control unit" (generally due to OEM function cutoffs), and signals in the electronic control unit mismatch set are marked as "a newly added non-standard signal for this electronic control unit" (it needs to be confirmed whether special test bench resources are required). A matching report is output, including the set of matched signal pairs, the template mismatch set, the electronic control unit mismatch set, the difference value, and a successful match indicator.

[0102] If Δ>θ, the matching is deemed to have failed, triggering a "template matching difference exceeds threshold" alarm. A new domain template draft is automatically generated and named in the format "corresponding electronic control unit type_draft". All unmatched signals are marked as "pending manual annotation". After the engineer confirms the signal attributes, the template is stored in the template library. Existing templates can still be used in the subsequent mapping process of matched signals.

[0103] For the three types of ECUs in this embodiment, after completing the template matching operation, for example, during the matching process of the braking ECU, if it is found that the accuracy requirement of a certain wheel speed sensor is higher than the default value of the template, the signal is classified into U. ecu The signal points marked "resource configuration needs adjustment" are then matched with the other steering ECUs and suspension ECUs in the same way, resulting in matching reports R for each of the three ECUs. match .

[0104] Step S3, Physical sample installation parameter acquisition, for three types of physical samples: steering gear assembly, brake caliper, and shock absorber, the following operations are performed: Using professional measuring tools, measure the actual mounting hole coordinates, hole diameter, and external dimensions (length / width / height) of each physical sample. All measured data were entered into the physical installation parameter table of the DUT template library. The final reference parameters measured in this embodiment are as follows: the steering gear assembly mounting holes are 6×M10 specifications with a mounting hole spacing of 300×180mm; the brake caliper mounting holes are 2×M12 specifications with a mounting hole spacing of 140mm; the shock absorber top mounting holes are 3×M8 specifications with a mounting hole spacing that meets the 120mm PCD distribution. All collected measurement data will be used for subsequent calculation of the support arm position and selection of the orifice plate in the driving fixture system. It is not subject to the constraints of the AUTOSAR standard and will only serve as the input basis for fixture adjustment.

[0105] Step S4: Generate an electrical interface resource requirement list, which is completed by the electrical interface resource requirement generation algorithm. The input is all matching reports R where the verdict field is ACCEPT. match and matching pair set M pairs The detailed operating procedure is as follows: For each matching pair (t) in the matching set j , s {e,i} According to s {e,i} Based on the category and attribute set, generate a rack resource requirement entry: If the signal type is Controller Area Network: Generate Controller Area Network channel requirements, specifying baud rate, terminating resistor configuration, and number of channels; If the signal type is analog input / analog output: generate analog channel requirements, specifying voltage range, resolution, and sampling rate parameters; If the signal type is digital input / digital output: generate digital channel requirements, specify the voltage level, and whether bidirectional transmission parameters are supported; If the signal type is pulse width modulation input / pulse width modulation output: generate pulse width modulation channel requirements, specifying frequency range, duty cycle range, and voltage level parameters.

[0106] For each unmatched signal in the set of unmatched electronic control units, generate a labeled requirement item, mark it as "awaiting manual confirmation", and require engineers to confirm the specific attributes of the signal and the corresponding bench resource requirements; For each missing signal in the template mismatch set, generate an optional class requirement entry and mark it as "optional configuration"; Output resource requirement set REQ = {req1, ..., req} K }, where K is the total number of requirement items, and the value of K is approximately equal to the total number of signals N of the electronic control unit. e .

[0107] In this embodiment, the resource requirements of the three ECUs are considered, and the core parameters of the final requirement list are as follows: physical installation parameters (installation parameters of the three types of samples measured in step 3 above), CAN bus channel requirement of 2-3 channels, power supply requirement to support 12V / 5V multi-channel power supply, approximately 40-60 analog input channels, approximately 15-25 analog output channels, approximately 30-50 digital I / O channels, approximately 8-15 PWM channels, and a preset fault injection requirement item is also included.

[0108] Step S5: Perform bench resource allocation and generate a resource allocation table. This is accomplished by the bench resource allocation algorithm (Constrained Best-Fit Decreasing), with a time complexity of O(K log K + K × M). The time complexity of the sorting operation is O(K log K), and the time complexity of the allocation operation is O(K × M). The inputs are the resource requirement list (REQ) and the available resource pool obtained by parsing the bench BDF file. The detailed operation process is as follows: Perform a pre-screening operation; temporarily transfer all requirements with the status "OPTIONAL" in the REQ to the candidate requirement queue Q. optional The remaining demands are sorted in descending order according to resource demand priority (e.g., voltage accuracy requirements from high to low, sampling rate requirements from high to low) to obtain a high-priority demand queue Q. required .

[0109] A compatibility check function is defined, which is a boolean type check function that takes requirement items and resource items as inputs. Check whether the required resource type matches the resource item type exactly; If the resource type is analog: check that the voltage range of the demand is completely contained within the voltage range of the resource, and that the resolution index of the demand is better than or equal to the resolution index of the resource. If the resource type is Controller Area Network: check that the required baud rate is exactly equal to the baud rate of the resource, or that the resource itself supports dynamic multi-rate configuration. If the resource type is pulse width modulation: check if there is a non-empty intersection between the frequency range of the requirement and the frequency range of the resource; return true if all conditions are met, and return false if any condition is not met.

[0110] The optimal allocation strategy iterates through each requirement in the high-priority requirement queue and then through all resources in the resource pool that meet the compatibility check and have a remaining available channel count greater than 0. It selects the resource with the smallest remaining channel count that still fully satisfies the requirement. This strategy prioritizes filling partially used resources to avoid resource fragmentation. After finding a suitable resource, it assigns the corresponding channel ID to the requirement, updates the remaining available channel count for that resource, and records the allocation entry (requirement ID, resource ID, channel ID, channel availability), where the channel availability is... The calculation formula is:

[0111] in, This is the upper limit of the specification. Demand value, Maximum size.

[0112] To handle unassigned requirements, after traversal, a set of all unassigned requirements (including those that cannot be satisfied in the high-priority queue and some requirements in the optional queue) is generated. Each entry is accompanied by a corresponding reason code, with possible values ​​for the reason code being {no compatible resources, all channels are occupied, specifications do not match}.

[0113] The output is a complete resource allocation table, including a list of allocated resources and a list of unallocated requirements (each item is accompanied by a corresponding reason code and recommended solution).

[0114] The algorithm has a time complexity of O(K log K + K×M), where the time complexity of the sorting operation is O(K log K) and the time complexity of the allocation operation is O(K×M).

[0115] For physical installation parameter acquisition, for physical samples (steering gears, brake calipers, shock absorbers, etc.), operators measure the actual mounting hole coordinates, hole diameters, and external dimensions of the sample and enter them into the physical installation parameter table of the equipment under test template library. This step is a necessary manual operation outside the coverage of the AUTOSAR standard. The measured data will be used for calculating the support arm position of the drive fixture system and selecting the orifice plate.

[0116] In this embodiment, for example, for the requirement of analog signal (0-5V, accuracy ±5mV) from brake pedal position sensor, the mapping engine searches for available analog output channels that meet the specifications in BDF, and finally maps and assigns them to channel AI0 of NI PXI-6229 board, with a range of ±10V. The corresponding calculated channel margin is (10V-5V) / 10V=0.5.

[0117] After allocation, perform exception handling: If at least one critical requirement cannot be allocated, throw an E_RESOURCE_INSUFFICIENT exception and return a detailed list of resource gaps (missing resource type, required quantity, minimum specification requirements), providing two recovery paths: Degraded operation mode, skipping tests for non-CRITICAL signals; Hardware supplementation suggestions, listing the required board models and minimum number of channels. If some resource requirements are allocable while others are not, an E_RESOURCE_PARTIAL exception is thrown. Allocated resources are marked as RESERVED to prevent conflicts, and unallocated items are included in subsequent RCD messages, allowing the test environment to continue building in degraded mode.

[0118] Step S6: Generate a standardized IRD message and transmit it between layers to the rack resource mapping layer. After the DUT abstraction layer completes all the above operations, it automatically generates an Interface Requirement Description (IRD) message. The message is defined using JSON Schema and includes all core fields: ird_id: A unique identifier for this requirement description, in the format IRD-{ECU type}-{timestamp}; dut_info: Basic information about the device under test, including ECU type enumeration (BR / ST / SP), ARXML file version number, physical sample model and serial number; electrical_requirements: A list of electrical interface requirements, each item being a four-tuple of {signal_name, signal_type, attributes, priority}, where priority can take values ​​of {CRITICAL, HIGH, NORMAL, LOW}. mounting_parameters: A set of physical installation parameters, including the coordinate array of mounting hole positions for each sample [{x,y, z, diameter, pitch}], the envelope of external dimensions {length, width, height}, and the mass weight; fault_injection_requirements: A list of fault injection requirements, each item containing the fault point identifier target_pin, fault type enumeration, duration, and triggering conditions; timestamp: A demand generation timestamp in ISO 8601 format; template_match_result: A summary of the template matching results, including the template name of the matching domain, the difference Δ value, and a list of difference signals.

[0119] Once generated, the IRD message is sent to the interface resource mapper of the rack resource mapping layer in synchronous request-response mode via the internal message bus. The timeout threshold for this synchronous link during the configuration phase is set to 30s by default.

[0120] Step S7: Generate the HIDL description script and complete the compilation. After the rack resource mapping layer receives the IRD message, it starts the HIDL parsing engine to perform the following operations: Based on the fault injection requirements, sensor simulation requirements, and load simulation requirements in the IRD, a physical interface description script written in HIDL (HIL Interface Description Language) is generated. The script must use only the reserved keywords defined in HIDL and must not use reserved keywords as custom identifiers. Operator keywords include FAULT (fault injection operation), SIGNAL (sensor simulation operation), LOAD (load simulation operation), MEASURE (measurement operation), CONNECT (connection operation), DISCONNECT (disconnection operation), SET (setup operation), WAIT (wait operation), and ASSERT (assertion operation). Fault type keywords include SHORT_TO_GND (short circuit to ground), SHORT_TO_VBAT (short circuit to power supply), OPEN_CIRCUIT (open circuit), SHORT_TO_SIGNAL (short circuit between signals), RESISTIVE_SHORT (resistive short circuit), and PIN_PAIR_SHORT (specifies a short circuit between two pins). Signal type keywords include ANALOG (analog signal), DIGITAL (digital signal), PWM (pulse width modulation signal), CAN_FRAME (CAN bus message frame), CAN_SIGNAL (single signal within a CAN frame), LIN_FRAME (LIN bus message frame), and SENT (Single Edge Nibble Transmission protocol signal).

[0121] The typical HIDL script example fragments generated in this embodiment include: FAULT SHORT_TO_VBAT brake fluid pressure sensor 200ms, SIGNAL ANALOG crankshaft position sensor 0-6000rpm frequency sweep, and other scenario definitions. The entire script is written with ECU and signal as semantic units, rather than with board channels, to ensure that the script can be reused on different HIL platforms.

[0122] Perform HIDL syntax validation. If the script does not conform to BNF syntax rules, throw an E_HIDL_SYNTAX exception, return the specific location of the syntax error (script line number, error token, expected syntax production), provide the correction suggestion for the closest valid statement, interrupt compilation, and do not allow further operation. After the syntax check passes, the semantic check is performed. If there is a case where the syntax is correct but the semantics are invalid, such as referencing a non-existent ECU port or a parameter value that is out of the physical range, an E_HIDL_SEMANTIC exception is thrown, and the semantic error details (reference target, conflict constraint) are returned, prompting you to check whether the port name is consistent with the signal list extracted by ARXML. After all verifications pass, the hardware description file of the target platform (provided by the platform SDK) is loaded, the HIDL script is compiled into a hardware instruction sequence or configuration file that can be executed by the target platform, and a complete compilation log is output.

[0123] Step S8: Generate adjustment parameters for the self-assembled multimodal fixture system. Based on the physical installation parameters of the test sample in the mounting_parameters field of the IRD message, calculate all adjustment parameters of the modular mechanical fixing platform. This fixture system consists of three modular components: a base frame, an adjustable support arm, and a standardized mounting hole plate. The base frame is a rigid metal frame fixed to the platform. The XY plane slide rails on the surface are divided into standard grids. The X-direction slide rail spacing (grid step) is 10mm, which is the spacing between adjacent locking positions. The slide rails themselves are continuously adjustable, and the locking positions are in 10mm steps. The X-direction positioning accuracy is ±1.0mm, which is the deviation between the actual position and the target position of the support arm base in the X direction. The Y-direction positioning accuracy is ±1.0mm, which is the deviation between the actual position and the target position of the support arm base in the Y direction. The Z-direction adjustment range is 100–800mm, which is the range of the support arm's extension stroke measured from the top surface of the base frame. The Z-direction positioning accuracy is ±2.0mm, which is the deviation between the actual height and the target height of the support arm's top mounting surface in the Z direction. The slide rail locking bolts are M10 8.8 grade bolts, and the recommended tightening torque is 25±2N·m.

[0124] Depending on the weight and installation method (bracket installation / flange installation / shaft installation) of the sample being tested, configure 2-8 support arms. According to the actual measured coordinates of the mounting holes of the sample, adjust the locking position of each support arm on the XY slide rail of the base, and extend and retract the Z-direction height of the support arm to the target installation height. Based on the measured hole diameter of the sample mounting hole, select the corresponding standardized mounting hole plate. The standard hole diameter specifications provided by the hole plate include M5×0.8, M6×1.0, M8×1.25, M10×1.5, and M12×1.75. Install and fix the hole plate on the top of the support arm, align it with the mounting hole position of the sample, and tighten it.

[0125] Finally, all adjustment parameters of the fixture system, including the XYZ coordinates of each support arm, orifice plate specification numbers, and recommended locking torques, were compiled and archived. The mechanically adjustable range of this fixture system can cover the installation requirements of more than 90% of common chassis components, eliminating the need for custom-made fixtures for different OEM models.

[0126] Step S9: Generate a standardized RCD message and transmit it between layers to the software tool adaptation layer. After the rack resource mapping layer completes all the above operations, it automatically generates a Resource Configuration Description (RCD) message. The message also uses JSON Schema definition and fully includes the core fields: rcd_id: A unique identifier for this configuration description, directly associated with the ird_id of the corresponding IRD; allocation_table: A list of resource allocation results. Each item is a 5-tuple of {requirement_id, resource_id, channel_id, channel_index, margin}. Margin represents the channel margin, i.e., the percentage of range utilization. unallocated_requirements: A list of resource requirements that could not be successfully allocated, each containing {requirement_id, reason_code, suggested_remedy}; hidl_compiled_output: HIDL compilation output, including the executable hardware instruction sequence (binary or text configuration file) and compilation log for the target platform; tool_configs: Configuration mapping table for each software tool, indexed by tool name, containing fields such as simulink_io_map, veristand_channels, ecutest_env, canape_signals; fixture_adjustment_params: Fixture system adjustment parameter table, including the XYZ coordinates of each support arm, orifice plate specification number, and recommended locking torque; warnings: A list of non-fatal warning messages, each containing {warning_code, message, affected_requirement}; timestamp: Configures the generation of timestamps in ISO 8601 format.

[0127] Once generated, the RCD message is sent to the software tool adaptation layer to complete the transfer of configuration information between the three-layer architecture.

[0128] Step S10: Complete software tool adaptation and full system deployment. After receiving the RCD message, the software tool adaptation layer completes all software-side configurations through four types of standardized tool interfaces, providing standardized tool call interfaces to upper-layer applications. Simulation modeling tool interface operation: Encapsulates the controlled object model loading and parameter configuration interfaces of modeling tools such as MATLAB / Simulink and CarSim. Through the standardized model configuration description format HOSAR-MCF (Model Configuration Format), it enables the same controlled object model (such as a vehicle dynamics model) to be loaded and run in the current HIL platform software environment, and completes the I / O mapping table configuration of the Simulink model. Test management tool interface operation: Encapsulates the test case loading and execution interface of test management tools such as ECU-TEST and TestStand. The pre-written platform-independent abstract description test cases (based on ASAM XIL API or HOSAR custom test description format) are automatically translated into executable scripts of the current target tool by the adaptation layer to complete the test environment configuration of ECU-TEST. Bus monitoring tool interface operation: Encapsulates the CAN signal observation and calibration interface of bus monitoring tools such as CANape and TSmaster, provides a unified CAN signal read and write channel, shields the API differences between different tools, and completes the mapping configuration of CANape signal channel; Real-time execution environment interface operations: Encapsulates the target deployment and operation control interfaces of VeriStand and Simulink Real-Time, and completes the generation of VeriStand channel configuration files and target machine deployment.

[0129] If problems such as API version incompatibility, configuration file format change, or tool process unresponsiveness occur during the operation, an E_TOOL_ADAPT exception will be thrown, returning the name of the failed tool, API version, and specific error reason. The system will automatically perform up to 3 retries with a 2-second exponential backoff strategy between retries. After all retries fail, the system will enter manual configuration rollback mode and generate a standard format template for engineers to manually import and complete the configuration.

[0130] Step S11: After the entire system is deployed, start the periodic heartbeat keep-alive mechanism between each layer. The heartbeat period between the DUT abstraction layer and the rack resource mapping layer is set to 500ms, and the heartbeat period between the rack resource mapping layer and the software tool adaptation layer is set to 200ms to meet higher real-time requirements. The heartbeat message format is defined as {layer_id, seq_num, timestamp, status_code}, where the value range of status_code is {OK, DEGRADED, BUSY, ERROR}.

[0131] Once the runtime phase begins, inter-layer interaction switches to an asynchronous publish-subscribe mode: the bench resource mapping layer publishes hardware resource status change events in real time via the event bus, corresponding to the Topic of bench / resource / status. The test management tool interface of the software tool adaptation layer subscribes to this Topic and determines subsequent operations based on the received event type (CHANNEL_FAULT, OVER_TEMPERATURE, COMM_LOSS). If a hardware channel malfunction occurs (e.g., analog output deviates from the set value by more than ±5% or ±10mV, digital output level mismatch, CAN channel error frame rate exceeds 1%), the system will detect it in real time and automatically mark the faulty channel as state: FAULTY. It will then search for a backup channel of the same type in the BDF resource pool and attempt to switch automatically. If there is no backup channel, it will send a TEST_PAUSE suggestion event to the test management tool. If a communication timeout occurs (E_COMM_TIMEOUT), meaning no response is received for three consecutive heartbeat cycles (1500ms for DUT-bench layer and 600ms for bench-software layer), the system determines that the communication link is interrupted. Each layer enters a local security state, retains the current configuration snapshot, stops new resource allocation requests, and automatically reconnects after the heartbeat resumes. After reconnection, a configuration consistency check is performed, comparing the snapshot with the current BDF file. If the configuration is inconsistent, an E_CONFIG_STALE alarm is triggered.

[0132] After completing all the above steps, the entire chassis domain HIL open testing system will be built, ultimately achieving automatic generation of bench interface requirements. Upper-level models, test cases, and HIDL scripts can all be reused across platforms, and test results from different teams and different vehicle models can remain consistent and comparable, adapting to the subsequent technical iteration needs of intelligent chassis.

[0133] The above content is merely an embodiment of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can improve and implement the present invention based on the guidance provided in this application and their own capabilities. Typical well-known structures or operating systems should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention, and these should also be considered within the scope of protection of the present invention. These modifications and improvements will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims. < / swc>

Claims

1. A chassis domain HIL open system architecture, characterized in that, include: The device under test interface abstraction layer, bench resource mapping layer, and software tool adaptation layer; The interface abstraction layer of the device under test is used to convert the software interface definition of the chassis domain electronic control unit and the installation parameters of the physical sample into standardized requirements that can be recognized by the test bench. The bench resource mapping layer is used to map the interface requirements output by the interface abstraction layer of the device under test into configurable executable instructions for specific bench equipment resources. The software tool adaptation layer is used to encapsulate the interaction with HIL software tools and provide standardized tool call interfaces for upper-layer applications. The device under test interface abstraction layer, bench resource mapping layer, and software tool adaptation layer communicate with each other through a standardized data interaction protocol.

2. The chassis domain HIL open system architecture according to claim 1, characterized in that, The interface abstraction layer of the device under test includes: The chassis domain test device interface template library contains pre-set standard interface templates for three types of test devices: braking, steering, and suspension. Each template includes an electrical interface template and a physical installation parameter module. The electrical interface template is based on the AUTOSAR software component interface description of the corresponding electronic control unit type, defining the general requirements specifications for bus, power supply, and hard-wired signals. The physical installation parameter module records the typical external dimensions and installation methods of the physical sample. The bench resource mapping engine is used to read the description file of the electronic control unit under test, extract the software component port definition, bus signal attribute and hardwire signal attribute, and match them with the electrical interface templates in the chassis domain device under test interface template library to automatically generate the bench electrical interface resource list required by the electronic control unit.

3. The chassis domain HIL open system architecture according to claim 2, characterized in that, The bench resource mapping engine includes: The ARXML parsing module is used to load and verify ARXML files, traverse the XML document object tree to extract software component identifiers, port lists, controller LAN packets and signal attributes, hard-wired signal attributes, establish the mapping relationship between signals and software component ports, and output the electronic control unit signal set. The template matching and difference recognition module is used to normalize the names and calculate the similarity between the parsed signal set and the standard signals in the template library, construct matching sets, template non-matching sets, and electronic control unit non-matching sets, and calculate the signal difference degree. The calculation formula is as follows: in, This represents the number of elements in the collection that the template did not match. The number of unmatched elements in the set for the electronic control unit. For template signal set, This is a set of ECU signals; based on the comparison result between the difference and a preset threshold, it determines whether the matching is successful or unsuccessful, and outputs a matching report; The electrical interface resource requirement generation module is used to generate corresponding bench resource requirement entries based on the signal categories and attribute sets in the matching report, and output a set of resource requirements. The bench resource allocation module is used to allocate the demand items in the resource demand set to the available resource pool defined in the bench configuration description file based on the constraint-optimal adaptive decreasing allocation algorithm, and generate a resource allocation table.

4. The chassis domain HIL open system architecture according to claim 2, characterized in that, The bench resource mapping layer includes: The Hardware-in-the-Loop Interface Description Language (HIL) parsing engine is used to interpret and execute physical interface description scripts written in HIL. These scripts use a common syntax to uniformly describe physical layer operations such as fault injection, sensor simulation, and load simulation, and are decoupled from specific hardware devices. The interface resource mapper is used to receive the list of electrical interface resources on the test bench and match the interface requirements to the specific hardware channels of the test bench according to the resource allocation rules defined in the test bench configuration description file. A standardized rack resource pool defines the standard interface specifications for various hardware resources in the rack. The physical mounting fixture system is a self-assembly, multimodal, modular mechanical fixing platform, comprising a base frame, adjustable support arms, and standardized mounting holes for fixing physical prototypes and electronic control units to the platform.

5. The chassis domain HIL open system architecture according to claim 1, characterized in that, The software tool adaptation layer includes: The simulation modeling tool interface is used to encapsulate the controlled object model loading and parameter configuration interface of the modeling tool, and realizes the loading and running of the model in different HIL platform software environments through a standardized model configuration description format. The test management tool interface is used to encapsulate the test case loading and execution interface of the test management tool, translating the platform-independent abstract description of test cases into executable scripts of the target tool; The bus monitoring tool interface is used to encapsulate the bus signal observation and calibration interface of the bus monitoring tool, providing a unified signal read and write channel; The Real-Time Execution Environment (RTE) interface is used to encapsulate the target machine deployment and operation control interface of the RTE.

6. The chassis domain HIL open system architecture according to claim 1, characterized in that, The standardized data interaction protocol includes: The interface requirement description format message is generated by the interface abstraction layer of the device under test and sent to the bench resource mapping layer. It includes basic information of the device under test, a list of electrical interface requirements, a set of physical installation parameters, a list of fault injection requirements, and a summary of template matching results. The resource configuration description format message is generated by the bench resource mapping layer and sent to the software tool adaptation layer. It includes a resource allocation result list, an unallocated resource requirement list, hardware-in-the-loop interface description language compilation artifacts, configuration mapping tables of each software tool, and fixture system adjustment parameters.

7. A standardized design method for chassis domain HIL open systems, applied to a chassis domain HIL open system architecture as described in any one of claims 1-6, characterized in that, Includes the following steps: Perform description file parsing to extract the full signal set of the electronic control unit; Perform template matching and difference identification, match the parsed signal set with the standard templates in the chassis domain test device interface template library, calculate the signal difference degree and output a matching report; Physical sample installation parameters are collected, the actual installation hole coordinates, hole diameter and external dimensions of the physical sample are measured, and the data is entered into the interface template library of the device under test in the chassis domain; Generate a list of electrical interface resource requirements, and generate bench resource requirement entries based on the signal categories and attributes in the matching report; Perform bench resource allocation, and allocate resource requirements to the available resource pool based on the constraint-optimal adaptive decreasing allocation algorithm to generate a resource allocation table; Generate standardized interface requirement description messages and transmit them between layers to the rack resource mapping layer; Generate a hardware-in-the-loop interface description language script and compile it to generate a sequence of hardware instructions executable by the target platform; Generate adjustment parameters for a self-assembling multimodal fixture system, and calculate the support arm position and orifice plate selection for a modular mechanical fixing platform; Generate standardized resource configuration description messages and transmit them between layers to the software tool adaptation layer; Complete software tool adaptation and full system deployment, and configure simulation modeling, test management, bus monitoring and real-time execution environment through standardized tool interfaces.

8. A standardized design method for a chassis domain HIL open system according to claim 7, characterized in that, The specific process of calculating signal difference and outputting a matching report includes: Perform name normalization preprocessing on all signal names in the signal set and template; Calculate signal similarity and construct matching sets, template mismatch sets, and electronic control unit mismatch sets; Calculate the signal difference using the formula. : in, This represents the number of elements in the collection that the template did not match. The number of unmatched elements in the set for the electronic control unit. For template signal set, For ECU signal set; If the difference is less than or equal to the preset threshold, the match is considered successful, and the unmatched signals are marked as missing general standard signals or newly added non-standard signals respectively; if the difference is greater than the preset threshold, the match is considered unsuccessful, and a new domain template draft is automatically generated.

9. A standardized design method for a chassis domain HIL open system according to claim 7, characterized in that, The specific process of resource allocation based on the constrained optimal adaptive decreasing allocation algorithm includes: Pre-screen and prioritize resource requirements; Define a compatibility check function to verify the type matching and specification compatibility between the requirement items and the resource items; Sort the resources by priority from high to low to obtain a high-priority demand queue. Iterate through the high-priority demand queue and select the resource with the smallest number of remaining channels from the resources that meet the compatibility check and have a greater than 0 number of remaining available channels, but still fully meet the requirements, for allocation. Process unassigned requests and generate a list of unassigned requests that includes reason codes and recommended solutions.

10. A standardized design method for a chassis domain HIL open system according to claim 7, characterized in that, It also includes the interactive steps during the runtime phase after the entire system is deployed: Initiate a periodic heartbeat survival mechanism between different layers; During the runtime phase, inter-layer interaction switches to an asynchronous publish-subscribe mode. The bench resource mapping layer publishes hardware resource status change events in real time through the event bus. The software tool adaptation layer subscribes to the event and performs corresponding test control operations according to the event type.

Images