Software-in-the-loop test method, device and equipment, storage medium and product

Abstract

The invention provides a software-in-the-loop test method and device, equipment, a storage medium and a product. The software-in-the-loop testing method comprises the following steps: acquiring to-be-tested application layer software information; acquiring a service name and a service interface from the application layer software information under the condition that the application layer software information is determined to be service software; respectively defining the service name and the service interface to obtain a service identifier and an interface identifier; establishing a corresponding relationship among the service name, the service interface, the service identifier and the interface identifier to obtain a macro chain table; and defining an application program interface function in the application layer software information according to the macro linked list, and executing a software-in-the-loop test process of the application layer software information according to the application program interface function. According to the method and the device, the SCL test can be performed on the software of the servitization architecture.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a software-in-the-loop testing method, a software-in-the-loop testing apparatus, a software-in-the-loop testing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Software-in-the-loop (SCL) testing methods in related technologies are designed for non-service architecture software. This involves automatically supplementing the necessary Real-Time Execution (RTE) layer code according to the AUTOSAR standard specification and configuring underlying scheduling functions to schedule the application layer modules. The supplemented RTE layer code and underlying scheduling functions are then compiled to generate an executable file (VECU) that can run on a PC, thus enabling SCL testing of the non-service architecture software. For service-oriented software in vehicle controllers, the service modules in the software architecture can be deployed independently. Services communicate remotely through clearly defined interfaces and network protocols, exhibiting mechanisms such as dynamic service registration and deregistration, service discovery, and service requests. This makes it impossible to configure fixed scheduling functions to call each service module, thus hindering SCL testing of service-oriented architecture software. Summary of the Invention

[0003] This application provides a software-in-the-loop (SCL) testing method, a software-in-the-loop (SCL) testing apparatus, a software-in-the-loop (SCL) testing device, a computer-readable storage medium, and a computer program product, which can perform SCL testing on service-oriented architecture software.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a software-in-the-loop testing method, the method comprising:

[0006] Obtain information about the application layer software to be tested;

[0007] If the application layer software information is determined to be service software, the service name and service interface are obtained from the application layer software information.

[0008] Define the service name and the service interface respectively to obtain the service identifier and the interface identifier;

[0009] Establish the correspondence between the service name, the service interface, the service identifier, and the interface identifier to obtain a macro linked list;

[0010] The application programming interface (API) functions in the application layer software information are defined according to the macro linked list, and the software-in-the-loop testing process of the application layer software information is executed according to the API functions.

[0011] In the above scheme, after obtaining the application layer software information to be tested, the method further includes:

[0012] If it is determined that the application layer software information is not service software, determine whether the application layer software information conforms to the standardized automotive software architecture;

[0013] If the application layer software information is determined to conform to the standardized automotive software architecture, the runtime environment code of the application layer software code is determined based on the application layer software information.

[0014] A synchronization function is generated based on the correspondence table between the interfaces and signal pools of the standardized automotive software architecture; the correspondence table for the signal pools is the information of the service software carried in the application layer software information.

[0015] Establish the association between the preset test interface information and the synchronization function;

[0016] The software-in-the-loop testing process of the application layer software information is executed based on the association, the synchronization function, and the runtime environment code.

[0017] In the above scheme, the software-in-the-loop testing process of executing the application layer software information based on the association relationship, the synchronization function, and the runtime environment code includes:

[0018] The underlying scheduling function is generated based on the association, the synchronization function, and the runtime environment code;

[0019] The runtime environment code, the underlying scheduling function, and the application layer software code in the application layer software information are compiled to obtain a compiled file;

[0020] The compiled file was tested in a simulation environment, and the test results were obtained.

[0021] In the above scheme, determining the runtime environment code for retrieving the application layer software code based on the application layer software information includes:

[0022] Obtain the description file of the application layer software code from the application layer software information;

[0023] Runtime environment code is generated based on the description file.

[0024] In the above scheme, the software-in-the-loop testing process of executing the application layer software information according to the application programming interface function includes:

[0025] The underlying scheduling function that generates the application layer software information based on the application programming interface function;

[0026] The underlying scheduling function is compiled to obtain a compiled file;

[0027] The compiled file was tested in a simulation environment, and the test results were obtained.

[0028] In the above scheme, the service interface includes a global signal pool variable interface and an Ethernet signal structure interface. The process of defining the service name and the service interface respectively to obtain the service identifier and interface identifier includes:

[0029] The service name is defined to obtain the service identifier;

[0030] Macros are defined for the global signal pool variable interface and the structure interface respectively to obtain the global signal pool variable interface identifier and the structure interface identifier;

[0031] The global signal pool variable interface identifier and the structure interface identifier are determined as the interface identifier.

[0032] This application provides a software-in-the-loop testing apparatus, comprising:

[0033] The acquisition unit is used to acquire application layer software information to be tested; if it is determined that the application layer software information is service software, the service name and service interface are acquired from the application layer software information.

[0034] The definition unit is used to define the service name and the service interface respectively, to obtain the service identifier and the interface identifier; and to define the application programming interface functions in the application layer software information according to the macro linked list.

[0035] A creation unit is used to establish the correspondence between the service name, the service interface, the service identifier, and the interface identifier, thereby obtaining the macro linked list;

[0036] An execution unit is used to perform a software-in-the-loop test process for the application layer software information according to the application interface function.

[0037] In the above scheme, the device further includes a determining unit and a generating unit;

[0038] The determining unit is configured to, if it is determined that the application layer software information is not service software, determine whether the application layer software information conforms to the standardized automotive software architecture; and, if it is determined that the application layer software information conforms to the standardized automotive software architecture, determine the runtime environment code of the application layer software code based on the application layer software information.

[0039] The generation unit is used to generate a synchronization function based on the correspondence table between the interfaces and signal pools of the standardized automotive software architecture; the correspondence table between the signal pools is the information of the service software carried in the application layer software information.

[0040] The establishment unit is used to establish the association between the preset test interface information and the synchronization function;

[0041] The execution unit is used to perform a software-in-the-loop test process for the application layer software information based on the association, the synchronization function, and the runtime environment code.

[0042] In the above scheme, the device further includes a compilation unit and a testing unit;

[0043] The generation unit is used to generate a low-level scheduling function based on the association relationship, the synchronization function, and the runtime environment code.

[0044] The compilation unit is used to compile the runtime environment code, the underlying scheduling function, and the application layer software code in the application layer software information to obtain a compiled file;

[0045] The test unit is used to test the compiled file in a simulation environment and obtain test results.

[0046] In the above scheme, the acquisition unit is used to acquire the description file of the application layer software code from the application layer software information;

[0047] The generation unit is used to generate runtime environment code based on the description file.

[0048] In the above scheme, the generation unit is used to generate the underlying scheduling function of the application layer software information according to the application programming interface function;

[0049] The compilation unit is used to compile the underlying scheduling function to obtain a compiled file;

[0050] The test unit is used to test the compiled file in a simulation environment and obtain test results.

[0051] In the above scheme, the service interface includes a global signal pool variable interface and an Ethernet signal structure interface.

[0052] A definition unit is used to define the service name to obtain the service identifier; and to perform macro definitions on the global signal pool variable interface and the structure interface to obtain the global signal pool variable interface identifier and the structure interface identifier, respectively.

[0053] The determining unit is used to determine the global signal pool variable interface identifier and the structure interface identifier as the interface identifier.

[0054] This application provides a software-in-the-loop testing device, the software-in-the-loop testing device comprising:

[0055] Memory is used to store executable instructions for a computer;

[0056] A processor, when executing computer-executable instructions stored in the memory, implements the method provided in the embodiments of this application.

[0057] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implements the software-in-the-loop testing method provided in this application.

[0058] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the software-in-the-loop testing method provided in this application.

[0059] The embodiments of this application have the following beneficial effects: When the application layer software information is determined to be service software, this application obtains the service name and service interface from the application layer software information, defines the service name and service interface respectively, obtains the service identifier and interface identifier, and then establishes the correspondence between the service name, service interface, service identifier and interface identifier to obtain a macro linked list. Thus, the application programming interface functions in the application layer software information can be defined according to the macro linked list. The application programming interface functions include service registration event functions, deregistration event functions, event call functions, registration cycle functions, deregistration cycle functions, and cycle function call functions. This allows the underlying scheduling function corresponding to the application layer software information to be generated according to the multiple functions contained in the application programming interface functions. Finally, the scheduling of the application layer software information is realized according to the underlying scheduling function, and the software-in-the-loop testing process of the application layer software information according to the underlying scheduling function is completed, thereby realizing SCL testing of the service-oriented architecture software. Attached Figure Description

[0060] Figure 1 This is a schematic flowchart of a prior art software-in-the-loop testing method provided in an embodiment of this application;

[0061] Figure 2 This is a flowchart of a software-in-the-loop testing method provided in an embodiment of this application;

[0062] Figure 3 This is a block diagram of an exemplary VECU integration scheme provided in an embodiment of this application;

[0063] Figure 4 This is a schematic flowchart of an exemplary software-in-the-loop testing method provided in an embodiment of this application;

[0064] Figure 5 This is a schematic diagram of the composition structure of a software-in-the-loop testing device provided in an embodiment of this application;

[0065] Figure 6 This is a schematic diagram of the composition structure of a software-in-the-loop testing device provided in an embodiment of this application. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0067] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0068] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0069] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0070] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0071] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0072] 1) ECU: Electronic Control Unit, also known as a controller, is responsible for controlling a certain function and system in a car. It includes a microprocessor, memory, input / output interface, and software.

[0073] 2) SIL: Software in the loop, refers to testing and verifying embedded software through simulation without the involvement of ECU hardware.

[0074] 3) VECU: Virtual ECU. In SIL testing, the test object is the ECU code. The software project that can run in the SIL test environment (on a personal PC) is obtained by making appropriate adjustments to the software code of the real ECU.

[0075] 4) Autosar CP software architecture: An open and standardized automotive software architecture, which mainly consists of three parts: Application Layer, Runtime Environment (RTE), and Basic Software Layer (BSW).

[0076] Application layer: Contains all application software components (SWCs), which are independent software modules that implement specific functions.

[0077] Runtime environment: Acts as middleware between the application layer and the underlying software modules, handling communication and data exchange between components.

[0078] Basic Software Layer: Responsible for low-level activities, including drivers, system services, diagnostic communication, etc. The Base Software Layout (BSW) sits above the Hardware Abstraction Layer, providing unified services and interfaces to higher layers.

[0079] 5) Vehicle Controller Service-Oriented Software: The controller software adopts a service-oriented architecture, where the controller application is decomposed into multiple independent services. These services interact through interfaces and protocols. Services operate according to a proxy mechanism, and the proxy layer can implement advanced service registration, service deregistration, service discovery, routing policies, and security policies.

[0080] A flowchart of a software testing method in the prior art is shown below. Figure 1 As shown:

[0081] Step 1: Obtain the application layer code (header file and source file) to be tested;

[0082] Step 2: If the application layer code conforms to the Autosar CP architecture, then based on the module's ARXML file (Autosar standard description file) and in accordance with the architecture specifications, generate the RTE layer code for SIL testing (this step can be automated with the help of mature commercial tools).

[0083] Step 3: Generate underlying scheduling functions based on time-triggered or event-triggered methods, according to the outermost function name, scheduling period, and order of each module / component.

[0084] Step 4: Integration and compilation, which compiles the code files into a program (VECU) that can run on a PC, such as a dynamic link library file or an FMI standard file.

[0085] Step 5: Set up its simulation environment on the PC, run the VECU on the environment, perform the test, and draw the test conclusions.

[0086] This solution targets non-service architecture software and can automatically supplement the necessary RTE layer code according to the AUTOSAR standard specification. It enables the scheduling of various application layer modules by configuring the underlying scheduling functions. Using the supplemented RTE layer code and underlying scheduling functions, an executable file (VECU) that can run on a PC is finally compiled, thereby enabling SIL testing.

[0087] Existing solutions are designed for non-service-oriented software. However, for service-oriented software for vehicle controllers (not only software consisting entirely of service-oriented modules, but also software with both service-oriented and non-service-oriented modules), existing technologies cannot enable the correct simulation and operation of service-oriented modules. Their shortcomings are reflected in the following aspects:

[0088] 1. Lack of a service invocation mechanism. Specifically, non-service-oriented code is a tightly coupled monolithic application that invokes the outermost functions of various modules / components in a fixed, scheduled order based on time or event triggers to ultimately achieve software functionality. In contrast, service-oriented software architectures allow for independent deployment of service modules. Services communicate remotely through clearly defined interfaces and network protocols, possessing mechanisms for dynamic service registration and deregistration, service discovery, and service requests. This makes it impossible to invoke service modules using fixed scheduling functions.

[0089] 2. Lack of communication and data exchange mechanisms for service-oriented modules. Specifically, traditional Autosar CP can automatically generate RTE layer code from ARXML files. The RTE layer defines interface variables and interface update functions, and application layer modules update the interface by directly calling these functions, thus achieving communication and data exchange between modules. However, service-oriented modules are not part of the Autosar architecture and cannot be automatically generated using existing tools. Existing solutions do not specify how service-oriented modules exchange data, or how service-oriented modules exchange data with non-service-oriented modules.

[0090] The problems existing in the prior art can be solved by means of the following embodiments.

[0091] This application provides a software-in-the-loop testing method, which is applied to a software-in-the-loop testing apparatus. Figure 2 A flowchart of a software-in-the-loop testing method provided in this application embodiment is shown below. Figure 2 As shown, software-in-the-loop testing methods may include:

[0092] S101. Obtain information about the application layer software to be tested.

[0093] The software-in-the-loop testing method provided in this application embodiment is applicable to scenarios where SCL testing is performed on software with a service-oriented architecture.

[0094] In the embodiments of this application, the software-in-the-loop testing apparatus can be implemented in various forms. For example, the software-in-the-loop testing apparatus described in this application may include devices such as vehicle-mounted systems and servers. The specific software-in-the-loop testing apparatus can be determined according to the actual situation, and the embodiments of this application do not limit it in this regard.

[0095] In this embodiment of the application application, the application layer software information includes application layer software code, interface tables related to the application layer software code, and ARXML files corresponding to the application layer software code.

[0096] In this embodiment, application layer software information can be obtained from other devices, from user input information, or through other means. The specific method of obtaining application layer software information can be determined according to the actual situation, and this embodiment does not limit it.

[0097] S102. If the application layer software information is determined to be service software, the service name and service interface are obtained from the application layer software information.

[0098] In this embodiment of the application, after the software-in-the-loop testing device obtains the application layer software information to be tested, if it determines that the application layer software information is service software, it can obtain the service name and service interface from the application layer software information.

[0099] In this embodiment, whether the application layer software information is service software can be identified according to the naming rules of the application layer software information file, or according to the function name in the application layer software information, or other methods can be used to identify whether the application layer software information is service software. The specific identification method can be determined according to the actual situation, and this embodiment does not limit it.

[0100] For example, if the naming rules of the application layer software information files match the naming rules of the service software files, then the application layer software information is determined to be service software. Alternatively, if the function names in the application layer software information match the naming rules of the function names in the service software, then the application layer software information is determined to be service software.

[0101] In this embodiment of the application, the service name and service interface are specifically obtained from the interface table related to the application layer software code in the application layer software information.

[0102] It should be noted that the service interface includes the global signal pool variable interface and the Ethernet signal structure interface.

[0103] In this embodiment, after the software-in-the-loop testing device acquires the application layer software information to be tested, if it determines that the application layer software information is not service software, it determines whether the application layer software information conforms to the standardized automotive software architecture. If it determines that the application layer software information conforms to the standardized automotive software architecture, it determines the runtime environment code of the application layer software code based on the application layer software information; it generates a synchronization function based on the correspondence table between the interfaces and signal pools of the standardized automotive software architecture; it establishes an association between preset test interface information and the synchronization function; and it executes the software-in-the-loop testing process of the application layer software information based on the association, the synchronization function, and the runtime environment code.

[0104] It should be noted that the correspondence table of the signal pool is the service software information carried in the application layer software information. The correspondence table of the signal pool is an interface table related to the application layer software code, specifically the correspondence between data in the service-oriented code module and data in the non-service-oriented code module.

[0105] In this embodiment of the application, the standardized automotive software architecture can be the Autosar CP architecture.

[0106] In this embodiment, it can be determined whether the application layer software information conforms to the standardized automotive software architecture based on whether the application layer software information includes an ARXML file; it can also be determined by comparing whether the application layer software information conforms to the architecture specification of the Autosar CP architecture; other methods can also be used to determine whether the application layer software information conforms to the standardized automotive software architecture; the specific determination method can be determined according to the actual situation, and this embodiment does not limit it.

[0107] For example, if the application layer software information includes an ARXML file, then the application layer software information is determined to conform to a standardized automotive software architecture. Alternatively, if the application layer software information conforms to the Autosar CP architecture specification, then the application layer software information is determined to conform to a standardized automotive software architecture.

[0108] Understandably, when the application layer software information is not service software and conforms to the standardized automotive software architecture, a synchronization function is generated using the correspondence table between the interfaces and signal pools of the standardized automotive software architecture. This correspondence table for the signal pools contains the service software information carried in the application layer software information. When generating runtime environment code, the interface information of the standardized automotive software architecture is the runtime environment interface variable. In other words, the synchronization function achieves numerical synchronization between the global signal pool variables and the RTE interface variables, thereby ensuring that the modules corresponding to the code of the service-oriented software can interact with the modules corresponding to the code of the non-service-oriented software.

[0109] In this embodiment of the application, the process by which the software-in-the-loop testing device determines the runtime environment code of the application layer software code based on the application layer software information includes: obtaining a description file of the application layer software code from the application layer software information; and generating runtime environment code based on the description file.

[0110] It should be noted that the description file for the application layer software code is the ARXML file corresponding to the application layer software code.

[0111] It should be noted that runtime environment code can be RTE code, i.e., Runtime Environment code.

[0112] In this embodiment of the application, runtime environment code conforming to the normative requirements of standardized automotive software architecture is generated based on the description file.

[0113] In the embodiments of this application, the method of generating RTE code from ARXML file is the method in the prior art, and the specific implementation process is not limited here.

[0114] In this embodiment of the application, the software-in-the-loop testing device executes a software-in-the-loop testing process of the application layer software information based on the association relationship, the synchronization function, and the runtime environment code, including: generating a low-level scheduling function based on the association relationship, the synchronization function, and the runtime environment code; compiling the runtime environment code, the low-level scheduling function, and the application layer software code in the application layer software information to obtain a compiled file; and testing the compiled file in a simulation environment to obtain test results.

[0115] In this embodiment of the application, the preset test interface information includes system input / output interface definitions and initialization functions, mapping functions, etc.

[0116] In this embodiment, after the software-in-the-loop testing device determines whether the application layer software information conforms to the standardized automotive software architecture, if it determines that the application layer software information does not conform to the standardized automotive software architecture, it generates a low-level scheduling function based on the application layer software code in the application layer software information; it compiles the low-level scheduling function and the application layer software code to obtain a compiled file; and it tests the compiled file in a simulation environment to obtain test results.

[0117] S103. Define the service name and the service interface respectively to obtain the service identifier and the interface identifier.

[0118] In this embodiment of the application, after the software-in-the-loop testing device obtains the service name and service interface from the application layer software information, it can define the service name and the service interface respectively to obtain the service identifier and the interface identifier.

[0119] In this embodiment of the application, service interface variables can be defined; service names and service interfaces can be macro-defined, so that each service and service interface has its own unique ID (i.e., identifier).

[0120] In this embodiment, the service interface includes a global signal pool variable interface and an Ethernet signal structure interface. The process of defining the service name and the service interface to obtain the service identifier and the interface identifier includes: defining the service name to obtain the service identifier; performing macro definitions on the global signal pool variable interface and the structure interface to obtain the global signal pool variable interface identifier and the structure interface identifier; and determining the global signal pool variable interface identifier and the structure interface identifier as the interface identifier.

[0121] S104. Establish the correspondence between the service name, the service interface, the service identifier, and the interface identifier to obtain a macro linked list.

[0122] In this embodiment of the application, the software-in-the-loop testing device defines the service name and the service interface respectively, and after obtaining the service identifier and the interface identifier, it can establish the correspondence between the service name, the service interface, the service identifier and the interface identifier to obtain a macro linked list.

[0123] In this embodiment, the correspondence between services, interfaces, and their macro IDs is stored in a linked list. This allows for indexing of target service or interface variables using macro IDs.

[0124] S105. Define the application programming interface (API) functions in the application layer software information according to the macro linked list, and execute the software-in-the-loop test process of the application layer software information according to the API functions.

[0125] In this embodiment, after the software-in-the-loop testing device establishes the correspondence between the service name, the service interface, the service identifier, and the interface identifier to obtain the macro list, it can define the application programming interface functions in the application layer software information according to the macro list, and execute the software-in-the-loop testing process of the application layer software information according to the application programming interface functions.

[0126] In this embodiment of the application, the application programming interface functions include various types of service functions, such as: service registration event functions, deregistration event functions, event call functions, registration cycle functions, deregistration cycle functions, cycle function call functions, structure data sending functions, and signal pool read / write functions.

[0127] In this embodiment, the software-in-the-loop testing device executes a software-in-the-loop testing process for the application layer software information according to the application programming interface (API) function, including: generating a low-level scheduling function for the application layer software information according to the API function; compiling the low-level scheduling function to obtain a compiled file; and testing the compiled file in a simulation environment to obtain test results.

[0128] For example, such as Figure 3As shown, the software architecture of the VECU implementation scheme can be abstracted into three layers: application layer, middle layer, and bottom layer. The application layer consists of the directly input software code to be tested, including both non-service modules (SEC1, SEC21) and service modules (Service1, Service2, Service3). The software-in-the-loop testing scheme in this application is applicable not only to software systems with both non-service and service modules, but also to software systems entirely composed of service modules. The middle layer is derived from the RTE layer code of the AUTSAR standard, with extensions and supplements to the service-oriented scheme. The middle layer comprises three parts: RTE code, Global Signal Pool (GSP), and Structure Data. Its function is to enable communication and data exchange between service modules, between non-service modules, and between service modules and non-service modules. The bottom layer comprises three parts: OS, system input / output interface management (Inport / Outport), and Service Proxy.

[0129] It should be noted that in the middle layer, the RTE code is automatically generated using relevant tools based on the input ARXML file, conforming to the AUTSAR architecture specification. The RTE layer code implements communication and data exchange between non-service modules by defining RTE layer interface variables and variable read / write functions. The global semaphore pool is a collection of all variables interacting between modules, where each variable has its own unique ID. IDs are defined using macros, and a linked list establishes the correspondence between each ID and its variable pointer. Variables in the global semaphore pool are read and written via API, and can also be read and written directly by variable ID. Service modules can directly read and write variables in the global semaphore pool via API, enabling communication and data exchange between service modules. Non-service modules use specific synchronization functions to synchronize the values ​​of global semaphore pool variables and RTE interface variables. The sequential execution of input signal synchronization, application layer module calls, and output signal synchronization ensures communication and data exchange between non-service and service modules. Structure data is a collection of structure variables used to transmit signals related to in-vehicle Ethernet communication and also for requesting services. Specifically, each structure corresponds to a set of Ethernet signals, and each structure has a unique ID. These IDs are defined using macros, and a linked list establishes a correspondence between each ID and a pointer to a structure variable. Structure variables can be sent or retrieved via their IDs. Each service module can be associated with a structure ID during registration. If there is an internal or external update to structure data, a request will be made to invoke the service module associated with that structure ID.

[0130] It's important to note that the underlying OS is the operating system. In the SIL simulation environment, the OS's role is to schedule the various software modules. In this solution, it's responsible for scheduling the initialization functions, periodic functions, and event functions of non-service modules. Furthermore, the service proxy ultimately calls relevant functions through the OS. System input / output interface management establishes corresponding global variables based on the interface names desired for testing and maps them to variables in the intermediate layer. Centralized interface management allows for quick, convenient, and flexible modification of test interfaces, improving the solution's applicability. The service proxy is the application programming interface function of the service module; it implements service registration, deregistration, and service invocation by defining corresponding APIs.

[0131] Specifically:

[0132] Registering event functions: When registering, you need to provide the service ID, function pointer, and structure ID. Save these three pieces of information in a local file (such as XML format, JSON format, etc., and write the three into the file according to a fixed hierarchical relationship).

[0133] Unregister event function: When unregistering, a service ID and a structure ID are required. The information saved during registration will be deleted from the local file.

[0134] Call the event function: If the data of the structure is updated, read the function pointer to be called from the local file, call the function pointer, and pass the pointer of the structure as a parameter to the function.

[0135] Registering a lifecycle function: When registering, you need to provide the service ID, the function pointer, and the lifecycle. These three pieces of information are saved in a local file (such as XML format, JSON format, etc.).

[0136] Unregister periodic function: When unregistering, a service ID and period are required. The information saved during registration will be deleted from the local file.

[0137] Calling a periodic function: Define a periodic function that needs to read a local file, extract the function pointer of the periodic function from it, and then call the function pointer.

[0138] Sending Structure Data: Given a structure ID and a pointer to the data to be sent, this API updates the specified data pointer in the structure data of the intermediate layer and triggers the event function.

[0139] Signal pool read: Given the variable ID and pointer of the global signal pool, this API reads the value of the global signal pool variable back to the pointer.

[0140] Signal pool write: Given a variable ID and pointer to the global signal pool, this API writes the value of the pointer to the corresponding variable in the global signal pool.

[0141] In this application embodiment, an exemplary software-in-the-loop testing method is as follows: Figure 4 As shown, first, the application layer software information to be tested is obtained (including the application layer software code to be tested, and related interface tables and ARXML files); then, services are identified, specifically, from the application layer software information (i.e., the application layer software code to be tested), it is identified whether each module is a service. If so, the service is processed in step a and d; after step a and d are completed, the application interface function obtained after step d is used to generate the underlying scheduling function of the application layer software information. If it is not a service, the Autosar component is further identified. If it is an Autosar component, the ARXML file is obtained from the application layer software information, and according to AR... The XML file is used to automatically generate RTE code with the help of tools (mature commercial solutions already exist); based on the correspondence table between the Autosar interface and the signal pool (i.e., the relevant interface table), synchronization functions (i.e., the data synchronization code of the Autosar component) are generated; according to the expected test interface (which can be input from a table), system input / output interface definitions, initialization functions, and mapping functions are generated, that is, the association between the preset test interface information and the synchronization functions is established; then, the underlying scheduling functions are generated (the underlying scheduling functions include: initialization functions, synchronization functions, and periodic functions of non-service modules, initialization functions of service modules, periodic task functions of service proxies, etc.); the application layer software code, RTE code, and underlying scheduling functions generated in the above process are integrated, and compiled using a compiler (such as GCC, Visual Studio, etc.) to output a program that can run on a PC (i.e., to obtain an executable VECU file, that is, to obtain a compiled file); finally, the test is executed (i.e., the VECU is placed on a simulation test platform (such as commercial simulation software) and the test results are obtained). If the AUTSAR component is identified, and if it is determined not to be an AUTSAR component, then the underlying scheduling function is directly generated based on the application layer software code. This is then compiled using a compiler to output a program that can run on a PC. Finally, tests are performed to obtain the test results. This application can integrate and compile 'vehicle controller service software' into a VECU that can be simulated and run on a PC. Specifically, it can solve the problem of how to implement the service proxy mechanism, communication, and data exchange mechanism of the service software module in the VECU, enabling the service module and non-service modules to run correctly in the SIL simulation environment. Specifically, the service proxy mechanism in this application embodiment can realize service registration, service deregistration, service discovery, and service invocation of the service application layer module in the SIL environment, correctly verifying its functionality. The communication and data exchange mechanism proposed in this invention can realize SIL testing of application layer software systems where service and non-service modules coexist.

[0142] Step a, identify service attributes: From the table input from the upstream, identify its service name, global semaphore pool variable interface, and Ethernet signal structure interface.

[0143] Step b, Service Interface Definition and Macro Definition: Define service interface variables; define service names and service interfaces using macros, so that each service and service interface has its own unique ID.

[0144] Step c, establish a macro list: Store the correspondence between services, interfaces, and their macro IDs in the linked list. This allows you to index target service or interface variables using macro IDs.

[0145] Step d, define the service-related APIs: implement the service proxy mechanism through APIs, specifically including: registering event functions, unregistering event functions, calling event functions, registering periodic functions, unregistering periodic functions, calling periodic functions, sending structure data, and reading and writing to the signal pool.

[0146] Understandably, this application, upon determining that the application layer software information is service software, obtains the service name and service interface from the application layer software information, defines the service name and service interface respectively, obtains the service identifier and interface identifier, and then establishes the correspondence between the service name, service interface, service identifier, and interface identifier to obtain a macro linked list. This macro linked list allows the definition of application programming interface (API) functions in the application layer software information. These API functions include service registration event functions, deregistration event functions, event call functions, registration cycle functions, deregistration cycle functions, and cycle function calls. This enables the generation of underlying scheduling functions corresponding to the application layer software information based on the multiple functions contained in the API functions. Finally, the scheduling of the application layer software information is implemented based on these underlying scheduling functions, completing the software-in-the-loop (SCL) testing process for the application layer software information based on these underlying scheduling functions, thereby achieving SCL testing of the service-oriented architecture software.

[0147] Based on the same inventive concept as the above-mentioned software-in-the-loop testing method, this application provides a software-in-the-loop testing apparatus 1, corresponding to a software-in-the-loop testing method; Figure 5 This application provides a schematic diagram of the composition structure of a software-in-the-loop testing device 1, which may include:

[0148] The acquisition unit 11 is used to acquire application layer software information to be tested; if it is determined that the application layer software information is service software, the service name and service interface are acquired from the application layer software information.

[0149] Definition unit 12 is used to define the service name and the service interface respectively to obtain the service identifier and the interface identifier; and to define the application programming interface functions in the application layer software information according to the macro linked list;

[0150] Establishment unit 13 is used to establish the correspondence between the service name, the service interface, the service identifier and the interface identifier, and obtain the macro linked list;

[0151] Execution unit 14 is used to perform a software-in-the-loop test process for the application layer software information according to the application interface function.

[0152] In some embodiments of this application, the apparatus further includes a determining unit and a generating unit;

[0153] The determining unit is configured to, if it is determined that the application layer software information is not service software, determine whether the application layer software information conforms to the standardized automotive software architecture; and, if it is determined that the application layer software information conforms to the standardized automotive software architecture, determine the runtime environment code of the application layer software code based on the application layer software information.

[0154] The generation unit is used to generate a synchronization function based on the correspondence table between the interfaces and signal pools of the standardized automotive software architecture; the correspondence table between the signal pools is the information of the service software carried in the application layer software information.

[0155] The establishment unit 13 is used to establish the association between the preset test interface information and the synchronization function;

[0156] The execution unit 14 is used to perform a software-in-the-loop test process for the application layer software information based on the association relationship, the synchronization function, and the runtime environment code.

[0157] In some embodiments of this application, the apparatus further includes a compilation unit and a testing unit;

[0158] The generation unit is used to generate a low-level scheduling function based on the association relationship, the synchronization function, and the runtime environment code.

[0159] The compilation unit is used to compile the runtime environment code, the underlying scheduling function, and the application layer software code in the application layer software information to obtain a compiled file;

[0160] The test unit is used to test the compiled file in a simulation environment and obtain test results.

[0161] In some embodiments of this application, the generation unit is configured to generate a low-level scheduling function based on the application layer software code in the application layer software information when it is determined that the application layer software information does not conform to the standardized automotive software architecture.

[0162] The compilation unit is used to compile the underlying scheduling function and the application layer software code to obtain a compiled file;

[0163] The test unit is used to test the compiled file in a simulation environment and obtain test results.

[0164] In some embodiments of this application, the acquisition unit 11 is used to acquire a description file of the application layer software code from the application layer software information;

[0165] The generation unit is used to generate runtime environment code based on the description file.

[0166] In some embodiments of this application, the generation unit is configured to generate a low-level scheduling function for the application layer software information based on the application programming interface function;

[0167] The compilation unit is used to compile the underlying scheduling function to obtain a compiled file;

[0168] The test unit is used to test the compiled file in a simulation environment and obtain test results.

[0169] In some embodiments of this application, the service interface includes a global signal pool variable interface and an Ethernet signal structure interface;

[0170] Definition unit 12 is used to define the service name to obtain the service identifier; and to perform macro definitions on the global signal pool variable interface and the structure interface to obtain the global signal pool variable interface identifier and the structure interface identifier, respectively.

[0171] The determining unit is used to determine the global signal pool variable interface identifier and the structure interface identifier as the interface identifier.

[0172] It should be noted that, in practical applications, the aforementioned acquisition unit 11, definition unit 12, establishment unit 13, and execution unit 14 can be implemented by the processor 16 of the software-in-the-loop test equipment, specifically by a CPU (Central Processing Unit), MPU (Microprocessor Unit), DSP (Digital Signal Processor), or FPGA (Field Programmable Gate Array), etc.; the aforementioned data storage can be implemented by the memory 17 of the software-in-the-loop test equipment.

[0173] This application also provides a software-in-the-loop testing device, such as... Figure 6 As shown, the software-in-the-loop testing device includes a processor 16, a memory 17, and a communication bus 18. The memory 17 communicates with the processor 16 through the communication bus 18. The memory 17 stores programs executable by the processor 16. When the program is executed, the processor 16 performs the software-in-the-loop testing method as described above.

[0174] In practical applications, the aforementioned memory 17 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the processor 16.

[0175] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of a software-in-the-loop testing device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the software-in-the-loop testing device to perform the software-in-the-loop testing method described above in this application.

[0176] This application provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are executed by a processor, they cause the processor to execute the software-in-the-loop testing method provided in this application. For example, ... Figure 2 The software-in-the-loop testing method is shown.

[0177] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEP ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0178] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0179] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0180] Understandably, this application, upon determining that the application layer software information is service software, obtains the service name and service interface from the application layer software information, defines the service name and service interface respectively, obtains the service identifier and interface identifier, and then establishes the correspondence between the service name, service interface, service identifier, and interface identifier to obtain a macro linked list. This macro linked list allows the definition of application programming interface (API) functions in the application layer software information. These API functions include service registration event functions, deregistration event functions, event call functions, registration cycle functions, deregistration cycle functions, and cycle function calls. This enables the generation of underlying scheduling functions corresponding to the application layer software information based on the multiple functions contained in the API functions. Finally, the scheduling of the application layer software information is implemented based on these underlying scheduling functions, completing the software-in-the-loop (SCL) testing process for the application layer software information based on these underlying scheduling functions, thereby achieving SCL testing of the service-oriented architecture software.

[0181] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0182] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0183] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0184] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0185] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A software-in-the-loop testing method, characterized in that, The method includes: Obtain information about the application layer software to be tested; If the application layer software information is determined to be service software, the service name and service interface are obtained from the application layer software information. Define the service name and the service interface respectively to obtain the service identifier and the interface identifier; Establish the correspondence between the service name, the service interface, the service identifier, and the interface identifier to obtain a macro linked list; The application programming interface (API) functions in the application layer software information are defined according to the macro linked list, and the software-in-the-loop testing process of the application layer software information is executed according to the API functions.

2. The method according to claim 1, characterized in that, After obtaining the application layer software information to be tested, the method further includes: If it is determined that the application layer software information is not service software, determine whether the application layer software information conforms to the standardized automotive software architecture; If the application layer software information is determined to conform to the standardized automotive software architecture, the runtime environment code of the application layer software code is determined based on the application layer software information. A synchronization function is generated based on the correspondence table between the interfaces and signal pools of the standardized automotive software architecture; the correspondence table for the signal pools is the information of the service software carried in the application layer software information. Establish the association between the preset test interface information and the synchronization function; The software-in-the-loop testing process of the application layer software information is executed based on the association, the synchronization function, and the runtime environment code.

3. The method according to claim 2, characterized in that, The software-in-the-loop testing process, which executes the application-layer software information based on the association, the synchronization function, and the runtime environment code, includes: The underlying scheduling function is generated based on the association, the synchronization function, and the runtime environment code; The runtime environment code, the underlying scheduling function, and the application layer software code in the application layer software information are compiled to obtain a compiled file; The compiled file was tested in a simulation environment, and the test results were obtained.

4. The method according to claim 2, characterized in that, The step of determining the runtime environment code of the application layer software code based on the application layer software information includes: Obtain the description file of the application layer software code from the application layer software information; Runtime environment code is generated based on the description file.

5. The method according to claim 1, characterized in that, The software-in-the-loop testing process that executes the application layer software information according to the application programming interface function includes: The underlying scheduling function that generates the application layer software information based on the application programming interface function; The underlying scheduling function is compiled to obtain a compiled file; The compiled file was tested in a simulation environment, and the test results were obtained.

6. The method according to claim 1, characterized in that, The service interface includes a global signal pool variable interface and an Ethernet signal structure interface. The service name and the service interface are defined respectively to obtain a service identifier and an interface identifier, including: The service name is defined to obtain the service identifier; Macros are defined for the global signal pool variable interface and the structure interface respectively to obtain the global signal pool variable interface identifier and the structure interface identifier; The global signal pool variable interface identifier and the structure interface identifier are determined as the interface identifier.

7. A software-in-the-loop testing apparatus, characterized in that, The device includes: The acquisition unit is used to acquire application layer software information to be tested; if it is determined that the application layer software information is service software, the service name and service interface are acquired from the application layer software information. The definition unit is used to define the service name and the service interface respectively, to obtain the service identifier and the interface identifier; and to define the application programming interface functions in the application layer software information according to the macro linked list. A creation unit is used to establish the correspondence between the service name, the service interface, the service identifier, and the interface identifier, thereby obtaining the macro linked list; An execution unit is used to perform a software-in-the-loop test process for the application layer software information according to the application programming interface function.

8. A software-in-the-loop testing device, characterized in that, The software-in-the-loop testing equipment includes: Memory is used to store executable instructions for a computer; A processor, when executing computer-executable instructions stored in the memory, implements the software-in-the-loop testing method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed by a processor, they implement the method described in any one of claims 1 to 6.

10. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method according to any one of claims 1 to 6.

Images