CN118708488A - Virtual simulation method, device and equipment based on Autosar architecture - Google Patents

Abstract

The application provides a virtual simulation method, device and equipment based on Autosar architecture. The method comprises the following steps: transmitting the compiled executable file to a file system of the virtual machine; starting an execution program of a virtual machine, loading an executable file in a virtual machine environment, and simulating an interactive function between a functional module of an application layer and simulation hardware; executing the virtual simulation test and obtaining a virtual simulation test result. The method can simulate the scene of loading the executable file to the real ECU in the virtual machine environment so as to test, verify and debug the software. The method can also help users to find potential problems before actual deployment, and improves the development efficiency of software.

Description

Virtual simulation method, device and equipment based on Autosar architecture

Technical Field

The present application relates to vehicle technology, and in particular to a virtual simulation method, device and equipment based on the AUTOSAR architecture.

Background Art

Automotive Open System Architecture (AUTOSAR) is an engineering standard for networking automotive electronic systems. It provides a complete software development and deployment process, making communication between automotive electronic control units more flexible and standardized.

During the development and testing of Autosar code, it is necessary to integrate various software components and test their ability to work together, including interface testing, functional testing, etc., and deploy the software to the actual Electronic Control Unit (ECU) to perform hardware and software integration testing and test the performance of the system on the actual hardware platform. However, testing in the actual vehicle environment requires a lot of time and resources.

Therefore, how to improve the development and testing efficiency of Autosar code is an urgent problem to be solved.

Summary of the invention

The present application provides a virtual simulation method, device and equipment based on the Autosar architecture, which is used to solve the problem that a lot of time and resources are consumed during the development and testing of Autosar codes in an actual vehicle environment.

In a first aspect, the present application provides a virtual simulation method based on the Autosar architecture, the method comprising:

The compiled executable file is transferred to the file system of the virtual machine, wherein the executable file includes the functional modules of the basic software layer, the functional modules of the application layer and the runtime environment layer in the Autosar architecture;

Starting the execution program of the virtual machine, loading the executable file in the virtual machine environment, and simulating the interactive function of the basic software layer;

Execute virtual simulation tests and obtain virtual simulation test results.

Optionally, performing the virtual simulation test and obtaining the virtual simulation test result includes:

Sending a virtual debugging instruction of a debugger to the virtual machine;

The virtual debugging instruction is run in the virtual machine to obtain a virtual simulation test result of the virtual modulation instruction.

Optionally, the method further includes:

The virtual simulation test result is displayed in a two-dimensional simulation image or a three-dimensional simulation image.

Optionally, performing the virtual simulation test and obtaining the virtual simulation test result includes:

Obtaining an input signal test case, wherein the input signal test case includes multiple input signals and an expected value of each input signal;

According to the preset mapping relationship between the input signal and the communication protocol, the input signal test case is encapsulated into a plurality of simulation messages, each simulation message corresponding to a communication protocol of an input signal;

Sending the multiple simulated messages to the virtual machine;

A test value of the virtual machine for an input signal in each simulation message is obtained.

Optionally, the method further includes:

Compare the test value and expected value of each input signal to see if they are the same;

If the test value and expected value of each input signal are the same, the virtual simulation test passes;

If the test value of any input signal is different from the expected value, the virtual simulation test fails, and the configuration file corresponding to the executable file is modified.

Optionally, performing the virtual simulation test and obtaining the virtual simulation test result includes:

Obtaining an output signal test case, wherein the output signal test case includes a plurality of output signals and an expected value of each output signal;

Generate a test code for each output signal according to a preset test code generation software toolkit, wherein the test code for each output signal is used to simulate and generate the output signal in a virtual machine;

Compile the test code of each output signal to generate an executable file for each output signal;

The executable file of each output signal is loaded into the virtual machine for execution, and the test value of each output signal is obtained.

Optionally, the test code includes a test function, and the test function can reference different output signals.

Optionally, the method further includes:

Acquire hardware attribute data configured by a user, wherein the hardware attribute data includes: processor architecture, number of processors and memory size, and the hardware attribute data is used to simulate the hardware configuration of the target system;

A virtual machine environment of an advanced reduced instruction set computer ARM architecture is simulated in a virtual machine according to the hardware attribute data.

In a second aspect, the present application further provides a virtual simulation device based on the Autosar architecture, the device comprising:

A transmission module, used to transmit the compiled executable file to the file system of the virtual machine, wherein the executable file includes the functional modules of the basic software layer, the functional modules of the application layer and the runtime environment layer in the Autosar architecture;

A simulation module starts the execution program of the virtual machine, loads the executable file in the virtual machine environment, and simulates the interactive function of the basic software layer;

The simulation test module is used to perform virtual simulation tests and obtain virtual simulation test results.

In a third aspect, the present application further provides an electronic device, the electronic device comprising: a processor, and a memory communicatively connected to the processor;

The memory stores computer-executable instructions;

The processor executes the computer-executable instructions stored in the memory to implement the virtual simulation method based on the Autosar architecture as described in any one of the first aspects.

In a fourth aspect, the present application also provides a computer-readable storage medium, in which computer execution instructions are stored. When the computer execution instructions are executed by a processor, they are used to implement the virtual simulation method based on the AUTOSAR architecture as described in any one of the first aspects.

The virtual simulation method, device and equipment based on the Autosar architecture provided by the present application can simulate the scenario of loading an executable file into a real ECU in a virtual environment to test, verify and debug the software. It can avoid the problem of consuming a lot of time and resources for testing in an actual vehicle environment. Potential problems can be discovered before real deployment, and advanced software design can be performed through simulation before the chip function is realized, thereby improving the efficiency of software development.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

FIG1 is a schematic diagram of the software module architecture of a virtual simulation system based on the Autosar architecture provided by the present application;

FIG2 is a flow chart of a first embodiment of a virtual simulation method based on the Autosar architecture provided by the present application;

FIG3 is a flow chart of a second embodiment of a virtual simulation method based on the Autosar architecture provided by the present application;

FIG4 is a flow chart of a third embodiment of a virtual simulation method based on the Autosar architecture provided by the present application;

FIG5 is a flow chart of a fourth embodiment of a virtual simulation method based on the Autosar architecture provided by the present application;

FIG6 is a schematic diagram of the structure of a first embodiment of a virtual simulation device based on the Autosar architecture provided by the present application;

FIG. 7 is a schematic diagram of the structure of an electronic device provided by the present application.

The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments.

DETAILED DESCRIPTION

Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

Automotive Open System Architecture (AUTOSAR): is an open standard architecture for automotive electronic systems, which aims to promote the standardization, reusability and interoperability of automotive electronic software. AUTOSAR defines a set of unified standards and specifications, including interface definitions, data formats, communication protocols, etc.

The AUTOSAR layered architecture mainly consists of the following layers:

Application Layer: The application layer contains software components related to specific automotive functions, such as engine control, braking system, infotainment, etc. These software components are responsible for implementing specific automotive functions and interact with other layers through standardized interfaces.

Runtime Environment Layer: The runtime environment layer provides a standardized runtime support environment for managing and scheduling software components in the application layer. This layer is responsible for handling task scheduling, resource management, communication protocol stack, and diagnostic and self-test functions.

Basic Software Layer (BSW): The basic software layer provides abstract interfaces and services related to hardware, including drivers for the underlying hardware, operating system functions, communication protocol stacks, diagnostic services, network management, etc. These software components shield the details of the underlying hardware, allowing the application layer and runtime environment layer to be developed and deployed independently of the hardware platform.

Microcontroller Abstraction Layer (MCAL): The MCAL includes abstract interfaces and driver components for specific microcontroller architectures, which are used to access the hardware resources of the microcontroller. The AUTOSAR architecture decouples the application layer and runtime environment layer from the hardware platform through the basic software layer, achieving software portability and hardware replacement flexibility.

However, during the development and testing of Autosar code, it is necessary to integrate various software components and test their ability to work together, including interface testing, functional testing, etc., and deploy the software to the actual ECU to perform hardware and software integration testing and test the performance of the system on the actual hardware platform. However, testing in the actual vehicle environment requires a lot of time and resources.

In addition, the processing power of existing chips is sometimes unable to meet the ultra-large-scale computing volume and computing speed expected by software design. For example, large-scale neural network codes or large operating systems often require chips with stronger processing power. The existing processing power based on existing hardware will limit advanced software design and cannot perform preliminary software design verification.

In view of this, the inventor proposes to simulate hardware through a virtual machine to develop and test Autosar code. Specifically, the virtual machine environment of the Advanced RISC Machine (ARM) architecture can be simulated through the virtual machine, so that the virtual electronic control unit (ECU) can run in the environment, and the code of the Autosar architecture can be imported into the virtual machine environment to perform virtual signal input and output simulation tests. Through the virtual machine, the software of the Autosar architecture can be developed in advance for virtual testing, and it can be quickly adapted after the chip is updated and iterated. It can also find errors in the Autosar code during the simulation process, correct the errors in time, and improve the development efficiency of software components and ECUs.

FIG1 is a schematic diagram of the software module architecture of the virtual simulation system based on the Autosar architecture provided by the present application. The system can be deployed in any terminal device, such as a computer, a server, etc. As shown in FIG1 , the system includes the following software modules:

User interface module: This module provides a human-computer interaction interface, allowing users to easily control the operation of the simulation system.

Virtual chip configuration module: configures the virtual chip type and chip parameters, such as clock frequency, memory size, peripheral configuration, etc. The virtual chip configuration module can also call the chip image file, which contains the chip firmware, operating system and other necessary software environments. By loading the appropriate chip image, the virtual machine environment can simulate an operating environment similar to the actual hardware. Through the virtual chip configuration module, the chip in the virtual machine environment can be flexibly configured as needed to meet different simulation requirements and test scenarios.

Virtual machine environment module: This component is responsible for simulating the virtual machine environment of the ARM architecture, so that the simulated ECU can run in this environment, providing hardware-level support for the entire simulation system.

2D simulation engine module: This module is responsible for performing comprehensive 2D simulation tests on ECU according to the requirements of Autosar engineering.

3D simulation engine module: This module is responsible for performing comprehensive 3D simulation testing on ECU according to the requirements of Autosar engineering.

Virtual communication interface module: This module is responsible for communicating with other simulation systems or actual hardware to achieve data interaction.

Debugger module: This module is responsible for real-time analysis and debugging of the data generated during the simulation process in order to discover and correct errors in a timely manner.

Test result analysis module: generates batch test results and analyzes test result data.

Autosar code loading module: used to load Autosar code for virtual debugging.

The virtual simulation system based on the Autosar architecture of the present application can perform virtual simulation at the hardware level, and the development software code of the Autosar architecture can be simulated and tested on virtual hardware to improve development efficiency.

The executor of the virtual simulation method based on the Autosar architecture of the present application can be any terminal device integrated with a virtual simulation system based on the Autosar architecture, or a chip with processing capabilities.

The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

FIG2 is a flow chart of a first embodiment of a virtual simulation method based on the Autosar architecture provided by the present application, as shown in FIG2 , comprising the following steps:

S101, transferring the compiled executable file to the file system of the virtual machine, wherein the executable file includes the functional modules of the basic software layer, the functional modules of the application layer and the runtime environment layer in the Autosar architecture.

In this step, according to the parameters in the Autosar architecture configured by the user, the software components defined by the Autosar standard or the custom modules are used to compile and generate a binary executable file. The executable file includes the function modules of the compiled basic software layer, the runtime environment layer, the function modules of the application layer and the microcontroller abstraction layer (MicroControllerAbstraction Layer, referred to as: MCAL), and the microcontroller abstraction layer includes a variety of driver groups; the function modules of the application layer (i.e., the software components of the application layer) include the code of the specific application software, for example, the car window corresponds to a function module, and the seat corresponds to a function module; the runtime environment layer includes the runtime environment required to support the program running. The executable file can be deployed to the actual automotive electronic control unit (ECU). In this solution, the executable file is deployed in the simulated ECU.

Get the IP address or host name of the virtual machine, connect to the virtual machine through the network, select the appropriate file transfer tool, run the corresponding transfer command on the development machine according to the IP address or host name of the virtual machine, and transfer the compiled executable file to the file system of the virtual machine.

Optionally, the executable file can be compiled from source code in the Autosar architecture to generate an executable file.

Exemplary:

Get the C language source code file (usually with a .c extension) and the related header file (usually with a .h extension) that need to be compiled. The source code file contains the actual program logic and function implementation, while the header file contains information such as function declarations, macro definitions, and structure definitions.

Create a CMakeLists.txt file that describes the configuration and dependencies that need to be built.

Select a compiler for the ARM architecture, or a custom compiler toolkit, and add it to the system path.

Use a compiler to compile the C source code (.c file) into an object file (.o file) or an executable file (.elf file). Specifically, the source code is translated into machine code, and symbol resolution and optimization are performed.

Download the generated executable file to the bin directory in the target file system of the virtual machine.

S102: Start the execution program of the virtual machine and load the executable file in the virtual machine environment to simulate the interaction function between the functional modules of the application layer and the simulated hardware.

In this step, open a terminal or command prompt in a virtual machine environment, switch to the directory where the executable file is stored through a command, and find the executable file. Use the corresponding command to execute the executable file, for example, enter the name of the executable file in the terminal and press the Enter key. After the executable file is run, the functional modules of the application layer can be simulated under the runtime environment conditions through the basic software layer and the microcontroller abstraction layer and the interaction between the simulation hardware, and the specific simulation process is the subsequent simulation process.

S103: Execute a virtual simulation test and obtain a virtual simulation test result.

In this step, the executable file is loaded into the development board of the virtual environment, which can simulate the scenario of loading the executable file into the real ECU. In this scenario, simulation testing can be performed. Specifically, the interaction between the application layer software and the simulation hardware can be simulated through test cases or user input of test instructions. In this process, the entire basic software link, signal packaging and unpacking, signal routing, operating system scheduling, and network status can also be simulated.

Optionally, you can build a virtual machine through user configuration, specifically:

The hardware attribute data configured by the user is obtained. The hardware attribute data includes: processor architecture, number of processors and memory size. The hardware attribute data is used to simulate the hardware configuration of the target system.

When users need to perform virtual simulation, they first need to determine the hardware configuration and hardware environment to be simulated. Users can enter or select hardware attributes in the user interface, or send a configuration file containing hardware attributes to the terminal device, which reads the hardware attributes.

Among them, the hardware attribute data includes the attribute data of the simulation development board, the selected processor architecture (cortex-A, cortex-M, cortex-R, etc.), the number of processors, the memory size, the storage location of the kernel image, the additional parameters of the kernel startup, and the image location of the root file system.

A simulated development board is a board that simulates the functions and features of an actual hardware development board through virtualization technology, allowing users to develop, debug, and test software without actual hardware devices. The attribute data of the development board includes the hardware features of the development board, such as the processor architecture, peripheral interfaces, and pin assignments. Users select a specific development board model or type to simulate the hardware configuration and features of the development board in a virtual environment. By simulating the development board, software development and testing can be performed in a virtual environment to verify the compatibility and stability of the software on a specific hardware platform, while speeding up the development cycle.

Users can configure the number of processors simulated in the virtual machine through hardware attribute data, for example, single-core, dual-core, quad-core, octa-core, etc. Different numbers of processors affect the computing performance and parallel processing capabilities of the virtual machine. Increasing the number of processors can improve the computing performance and response speed of the virtual machine.

The storage location of the kernel image file specified in the hardware attribute data is used to load the corresponding kernel when starting the virtual machine. The kernel is the core component of the virtual machine system and has the functions of providing system resources and services. It must be loaded correctly to start the virtual machine system.

The location of the root file system image file specified in the hardware attribute data is used to provide file system support and operating environment after the virtual machine is started. The root file system contains the core files and directory structure of the operating system.

The hardware attribute data also includes the virtual chip type that needs to be configured, chip parameters such as clock frequency, memory size, peripheral configuration, etc.

A virtual machine environment of an advanced reduced instruction set computer ARM architecture is simulated in a virtual machine according to hardware attribute data.

Select virtualization software that supports ARM architecture simulation. In one implementation, the virtualization software is selected through user operation; in another implementation, only one virtualization software is configured in the terminal device.

According to the hardware attribute data provided by the user, a new virtual machine instance is created using the virtualization software. When creating a virtual machine, the processor architecture is set to ARM architecture (such as cortex-A, cortex-M, cortex-R, etc.), the number of processors, the memory size and other parameters according to the hardware attribute data provided by the user.

Set the kernel image and root file system: Place the kernel image file and the root file system image file in the specified location of the virtual machine to ensure that the virtual machine can load the correct kernel and file system image. The kernel image file and the root file system image file can be entered by the user or downloaded from the website.

The virtual chip is configured according to the virtual chip type configured in the hardware attribute data, chip parameters such as clock frequency, memory size, peripheral configuration, etc.

Start the configured virtual machine and wait for the virtual machine system to start up.

This embodiment provides a virtual simulation method based on the Autosar architecture, which includes: obtaining hardware attribute data configured by the user, the hardware attribute data including: processor architecture, number of processors and memory size, and the hardware attribute data is used to simulate the hardware configuration of the target system; simulating the virtual machine environment of the advanced reduced instruction set computer ARM architecture in the virtual machine according to the hardware attribute data; transferring the compiled executable file to the file system of the virtual machine, the executable file including the functional modules of the basic software layer, the functional modules of the application layer and the runtime environment layer in the Autosar architecture; starting the execution program of the virtual machine, loading the executable file, simulating the interaction function between the functional modules of the application layer and the simulated hardware; performing a virtual simulation test, and obtaining the virtual simulation test result. Through this method, the scenario of loading the executable file into the real ECU can be simulated in a virtual environment, so as to test, verify and debug the software. It can avoid the problem of consuming a lot of time and resources for testing in the actual vehicle environment. It helps users to find potential problems before real deployment, and can perform advanced software design through simulation before the chip function is realized, so as to improve the development efficiency of software and ECU hardware.

During the virtual simulation test process, the simulation test can be performed manually by the user. The manual simulation test is introduced below with an embodiment.

FIG3 is a flow chart of a second embodiment of a virtual simulation method based on the Autosar architecture provided by the present application, as shown in FIG3 , comprising the following steps:

S201, sending a virtual debugging instruction of a debugger to a virtual machine.

In this step, the user sets debugging parameters through the debugger module, including the program to be debugged, breakpoints, watchpoints, etc. The debugging parameters are used to guide the behavior and goals during the debugging process. The debugger module sends the set debugging parameters to the virtual machine module.

The debugger module adopts any debugger in the prior art.

The program to be debugged is the application layer program in the Autosar architecture, which interacts with the BSW layer and the simulated hardware through the runtime environment layer. Users can perform functions verification, debug problems, optimize performance, etc. to ensure the correctness and stability of the program.

The communication protocol between the debugger and the virtual machine can adopt any reliable communication protocol.

S202: Run a virtual debugging instruction in a virtual machine to obtain a virtual simulation test result of the virtual modulation instruction.

In this step, in the virtual environment, the virtual machine executes the program to be debugged (the program of the application layer in the executable file), and feeds back the running state of the program to the debugger module in real time. The user can observe the running state of the program through the debugger module and debug the program in real time. When the debugging is completed, the user can export the debugging results through the debugger module, including various states of the program during operation, abnormal information, etc.

Exemplarily, a virtual debugging instruction is written through the debugger module to simulate the signal sending and receiving process. For example, the sending end is set to send specific data, and then the receiving end is simulated to receive and verify the correctness of the data. By executing the written virtual debugging instruction in the virtual machine, the user can observe the signal transmission process, check whether the receiving end successfully receives and processes the sent signal data, and generate the results of the virtual simulation test, including whether the received data is consistent with the expected value, whether the transmission is stable, etc.

Another example of a virtual debugging instruction is that the user sets a breakpoint in the program to be debugged, that is, when the program executes to a specific line of code, it will automatically stop and wait for further operation by the user. For example, the user wants to pause when the program executes to a critical part of the calculation logic in order to check the value of the variable and the program execution path. The user observes the real-time running status of the program through the debugger module, and can also export the debugging results through the debugger module, including various states of the program during operation, exception information, etc.

In another exemplary embodiment, the user sets an observation point in the program to be debugged through the debugger module to monitor the value of a specific variable or memory address, and monitors the value change of the variable in real time during the execution of the program. During the execution of the program to be debugged, the debugger module monitors the set observation point in real time, records and displays the value change of the specific variable or memory address, which can be observed through the variable monitoring window or log output provided by the debugger.

It should be noted that the virtual simulation results generated by the virtual machine are returned to the modulator module for display.

S203: Display the virtual simulation test result in a two-dimensional simulation image or a three-dimensional simulation image.

In this step, in order to facilitate users to obtain the results of the simulation test, the virtual simulation test results are displayed in a two-dimensional image or a three-dimensional image model. For example, if the virtual debugging instruction is a left turn signal of a traffic light, the result of running the virtual modulation instruction is displayed in a two-dimensional simulation model or a three-dimensional simulation model.

Exemplarily, the simulation is edited in advance through the two-dimensional simulation engine editor, including the arrangement and configuration of the electronic devices in the car, the allocation of each simulated signal, the signal type, signal parameters, etc. For example, for a left turn signal, it is necessary to edit the module as a light, and then add the signal attributes of the module, the signal state, etc. (such as: 0, 1). When the two-dimensional simulation engine is running (i.e., virtual simulation test), the virtual debugging instruction is a left turn signal. When the virtual simulation test result is "the signal state is 0", the left turn light in the two-dimensional simulation image is not on. When the virtual simulation test result is "the signal state is 1", the left turn light in the two-dimensional simulation image is on, achieving the simulation effect. The user can observe the simulation two-dimensional image module and perform real-time simulation analysis of the automotive electronic signal. In addition, the user can operate the simulation image through the human-computer interaction module, such as zooming in, zooming out, rotating, etc., in order to analyze the automotive electronic signal more deeply.

The above-mentioned two-dimensional simulation engine can also be converted into a three-dimensional simulation engine, and a three-dimensional image can be generated through a three-dimensional model, which is more convenient for users to observe.

This embodiment provides a user manual virtual simulation test method, which sends virtual debugging instructions to a virtual machine through a debugger; runs virtual debugging instructions in the virtual machine to obtain virtual simulation test results of virtual debugging instructions; and displays virtual simulation results. During the simulation process, the debugger will perform real-time analysis and debugging on the generated data, and finally display the simulation results to the user through the user interface. Users can debug and test the program to be debugged on-site without real hardware, which improves development efficiency. In addition, two-dimensional or three-dimensional display can make it more convenient for users to observe and debug.

The following is an example of an implementation to introduce the process of performing an automatic simulation test operation.

FIG4 is a flow chart of a third embodiment of a virtual simulation method based on the Autosar architecture provided by the present application, as shown in FIG4 , comprising the following steps:

S301: Obtain an input signal test case, where the input signal test case includes multiple input signals and an expected value of each input signal.

In this step, the user does not need to perform manual debugging during the virtual simulation process, and the test case is run for automatic testing. First, the input signal test case is obtained. The test case can be stored by the user in the virtual machine system file, which can be automatically obtained by the virtual machine, or it can be a test case that receives user input each time a virtual test is performed.

For example,

"Input signal: 3;

Expected result: The door should be in the open position;

Input signal: 25;

Expected Result: The window should be closed. ”

S302: Encapsulate the input signal test case into a plurality of simulation messages according to a preset mapping relationship between the input signal and the communication protocol, each simulation message corresponding to a communication protocol of the input signal.

In this step, different input signals follow different communication protocols. Therefore, according to the preset mapping relationship between input signals and communication protocols, the input signal test cases are encapsulated into multiple simulation messages. Each simulation message corresponds to a communication protocol for an input signal. That is, different input signals are carried on different protocol stacks according to the signal matrix table in the test routine, such as Local Interconnect Network (LIN), Controller Area Network (CAN), CAN Flexible Data-rate (CANFD), Ethernet, Flexray, etc. Specifically, a virtual message is created in the built-in simulation tool, and the virtual message can contain various signal values, periodicity, and expected values of signal values to simulate the CAN data flow in the actual vehicle. Simulate the corresponding communication protocol to send a signal to the virtual machine, for example, serialize the signal into a CAN protocol signal and send it to the virtual machine; serialize the signal into a LIN protocol signal and send it to the virtual machine; serialize the signal into an Ethernet protocol signal and send it to the virtual machine; serialize the signal into a Flexray protocol signal and send it to the virtual machine, etc.

Take CAN FD message as an example. The steps of packaging the signal into a message frame according to the test case are as follows: for each signal, construct a frame that complies with the CAN FD protocol specification according to the value range in the test case; each signal can be assigned a unique frame identifier so that the virtual receiving end can identify and process different signals. Fill the value in the test case as the data payload into the data segment in the CAN FD Frame, where the data in the data segment includes the test signal data and the expected value. Select the appropriate data frame format according to the data range of the signal, and encapsulate the constructed CAN FD Frame into a CAN FD message, ready to be sent to the corresponding communication medium. Send the encapsulated CAN FD message to the CAN FD bus, or send it to other protocol stacks (such as LIN, Ethernet, Flexray, etc.) after conversion through the gateway for simulation testing.

S303: Send multiple simulated messages to the virtual machine.

The prepared simulation message is sent to the virtual control unit of the virtual machine through the corresponding communication interface.

S304: Obtain a test value of the virtual machine for an input signal in each simulation message.

In this step, after receiving the simulated message, the virtual machine parses the data in it. According to the signal data in the data segment of the message frame, the required input signal is extracted. The input signal usually refers to a specific data field or parameter agreed in advance, which is used to represent a certain state, command or control information. According to the extracted signal information, the virtual machine can perform corresponding operations, such as: updating the corresponding interface value in the software component; triggering a specific function or logical operation; sending messages or data to other system components.

In a specific implementation, the virtual machine sends a request to the currently running software component (SWC) to obtain a specific interface value corresponding to the input signal after execution. The request usually includes information such as identification of the interface to be obtained and data format.

Optionally, the virtual machine prints out the extracted interface value and saves it to a log file for subsequent reference and analysis.

S305: Compare the test value and expected value of each input signal to see if they are the same.

In this step, the obtained interface value (ie, the test value of the input signal) is compared with the expected value in the data segment of the virtual message frame, or the interface value in the log file is read and compared with the expected value in the data segment of the virtual message frame.

S306: If the test value and the expected value of each input signal are the same, the virtual simulation test passes.

S307: If the test value of any input signal is different from the expected value, the virtual simulation test fails, and the configuration file corresponding to the executable file is modified.

In this step, once the test value of the input signal is found to be different from the expected value, it means that there may be errors in the logic inside the executable file, such as interface configuration errors. The user needs to manually correct the corresponding configuration file, or an automated tool or script can be used to check the configuration file and try to automatically correct the problems found, and regenerate the source code and executable file of the Autosar architecture.

The present embodiment provides a virtual simulation method based on the Autosar architecture, obtaining an input signal test case, the input signal test case includes multiple input signals and the expected value of each input signal; according to the preset mapping relationship between the input signal and the communication protocol, the input signal test case is encapsulated into multiple simulation messages, each simulation message corresponds to a communication protocol of an input signal; multiple simulation messages are sent to a virtual machine; the test value of the virtual machine for the input signal in each simulation message is obtained; the test value and the expected value of each input signal are compared to see whether they are the same; if the test value and the expected value of each input signal are the same, the virtual simulation test passes. If the test value and the expected value of any input signal are not the same, the virtual simulation test fails, and the configuration file corresponding to the executable file is modified. In this way, multiple virtual messages are constructed according to the input signal in the test case, and the input signal and the expected value of the input signal are written into the data segment of the virtual message, so that the virtual machine executes the input signal after receiving the virtual message, and compares the test value with the expected value in the virtual message, so that the input signals of different protocols can be automatically simulated and tested, and errors can be found and corrected in time.

The third embodiment introduces the process of simulation test for input signal. The following embodiment introduces the process of simulation test for output signal.

FIG5 is a flow chart of a fourth embodiment of a virtual simulation method based on the Autosar architecture provided by the present application, as shown in FIG5 , comprising the following steps:

S401. Obtain an output signal test case, where the output signal test case includes multiple output signals and an expected value of each output signal.

Input signals are usually data generated by the external environment and sent to the software components of the virtual machine, while output signals are generated by the processing logic and algorithms inside the software components of the virtual machine. Therefore, the test of output signals requires the generation of executable files that can generate output signals in the virtual machine.

Get the test cases of output signals. Each test case contains multiple output signals and their corresponding expected values. By executing the test cases of output signals, it is possible to verify whether the corresponding output signals of software components in different situations meet the expected values, thereby ensuring the correctness and stability of software components.

Exemplary, test case 1:

Output signal 1: signal_1

Expected value: 100

Output signal 2: signal_2

Expected value: The window state is open.

S402: Generate a test code for each output signal according to a preset test code generation software toolkit, wherein the test code for each output signal is used to simulate the generation of the output signal in the virtual machine.

In this step, the data output by the software component can be directly controlled through the test code file, which is convenient for result verification and comparison. The generated test code file is automatically generated according to each output signal in the specific test routine, which can simulate different output signals in a targeted manner and better cover various test scenarios.

Specifically, a test code software development kit (SDK) is used to automatically generate a test code file (example file) according to the output signal in the test case. The test code includes a test function, and the test function can reference different output signals in the output signal test case, that is, the output signal in the test function is cyclically assigned, and then a test code file corresponding to each output signal is generated. The test code file also includes the expected value of each output signal.

S403: Compile the test code of each output signal to generate an executable file of each output signal.

Use the corresponding compilation tool to compile the test code of each output signal to generate the corresponding executable file.

S404: Load the executable file of each output signal into the virtual machine for execution, and obtain the test value of each output signal.

In this step, the target program in the virtual machine executes the executable file of each output signal, calls the message monitoring tool (such as wireshark) to obtain the virtual message frame sent by the virtual machine, wherein the message segment in the virtual message frame includes the test value of the test result, and saves it as a log file. Specifically, according to the protocol of the message (CAN, LIN, Ethernet, Flexray), the signal payload is deserialized and the signal group is parsed to obtain the message segment data therein, and the test value of the output signal is saved as a log file. The test value in the log file is compared with the expected value in the executable file. If the comparison is consistent, the simulation test passes. If the test value in the log does not match the expected value, the simulation test fails.

This embodiment provides a virtual simulation method based on the Autosar architecture. According to the test case of the output signal, the test code is cyclically assigned through a test code generation tool to generate an executable file for each output signal, and the test value of the output result is obtained according to the executable file. By performing automatic simulation test on the output signal of the software component in a virtual simulation manner, the efficiency can be improved and errors and vulnerabilities of the executable file or software component can be discovered in advance.

FIG6 is a schematic diagram of the structure of a first embodiment of a virtual simulation device based on the Autosar architecture provided by the present application. As shown in FIG6 , a virtual simulation device 600 based on the Autosar architecture includes:

A transmission module 613, used to transmit the compiled executable file to the file system of the virtual machine, wherein the executable file includes the functional modules of the basic software layer, the functional modules of the application layer and the runtime environment layer in the Autosar architecture;

The simulation module 614 starts the execution program of the virtual machine and loads the executable file in the virtual machine environment, wherein the executable file loaded in the virtual machine environment is used to simulate the interaction function between the functional module of the application layer and the simulation hardware through the basic software layer and the microcontroller abstraction layer under the runtime environment condition;

The simulation test module 615 is used to perform virtual simulation tests and obtain virtual simulation test results.

Optionally, the device further includes: an acquisition module 611 and a virtual module 612:

The acquisition module 611 is used to acquire the hardware attribute data configured by the user, wherein the hardware attribute data includes: processor architecture, number of processors and memory size, and the hardware attribute data is used to simulate the hardware configuration of the target system;

The virtual module 612 is used to simulate a virtual machine environment of an advanced reduced instruction set computer ARM architecture in a virtual machine according to the hardware attribute data.

Optionally, the simulation test module 615 is specifically used for:

Sending a virtual debugging instruction of a debugger to the virtual machine;

The virtual debugging instruction is run in the virtual machine to obtain a virtual simulation test result of the virtual modulation instruction.

Optionally, the device further includes a display module 616, and the display module 616 is used to:

The virtual simulation test result is displayed in a two-dimensional simulation image or a three-dimensional simulation image.

Optionally, the simulation test module 615 is further used for:

Obtaining an input signal test case, wherein the input signal test case includes multiple input signals and an expected value of each input signal;

According to the preset mapping relationship between the input signal and the communication protocol, the input signal test case is encapsulated into a plurality of simulation messages, each simulation message corresponding to a communication protocol of an input signal;

Sending the multiple simulated messages to the virtual machine;

A test value of the virtual machine for an input signal in each simulation message is obtained.

Optionally, the simulation test module 615 is further used for:

Compare the test value and expected value of each input signal to see if they are the same;

If the test value and expected value of each input signal are the same, the virtual simulation test passes;

If the test value of any input signal is different from the expected value, the virtual simulation test fails, and the configuration file corresponding to the executable file is modified.

Optionally, the simulation test module 615 is further used for:

Obtaining an output signal test case, wherein the output signal test case includes a plurality of output signals and an expected value of each output signal;

Generate a test code for each output signal according to a preset test code generation software toolkit, wherein the test code for each output signal is used to simulate and generate the output signal in a virtual machine;

Compile the test code of each output signal to generate an executable file for each output signal;

The executable file of each output signal is loaded into the virtual machine for execution, and the test value of each output signal is obtained.

Optionally, the test code includes a test function, and the test function can reference different output signals.

The virtual simulation device based on the Autosar architecture provided in the embodiment of the present application is used to implement the virtual simulation method based on the Autosar architecture described in any of the aforementioned method embodiments. Its implementation principle and technical effect are similar and will not be elaborated here.

FIG. 7 is a schematic diagram of the structure of an electronic device provided by the present application. The electronic device may be a computer, a server, a vehicle-mounted terminal, a tablet, etc. As shown in FIG. 7 , the electronic device 700 includes:

A processor 701, a memory 702 in communication with the processor, and a communication interface 703 for interacting with other devices;

The memory 702 stores computer-executable instructions;

The processor 701 executes the computer-executable instructions stored in the memory to implement the virtual simulation method based on the Autosar architecture described in any of the above method embodiments.

Optionally, the above-mentioned components of the electronic device 700 may be connected via a system bus.

The memory 702 may be a separate storage unit or a storage unit integrated in the processor. The number of the processor 701 may be one or more.

Optionally, the electronic device also includes a multimedia component, which includes a touch display screen that provides an output interface between the electronic device and the user. In some embodiments, the touch display screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor can not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

Optionally, the electronic device also includes a power supply component that provides power to various components of the electronic device. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device.

It should be understood that the processor 703 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

The system bus may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

All or part of the steps of the above-mentioned method embodiments can be completed by hardware related to program instructions. The above-mentioned program can be stored in a readable memory. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the above-mentioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid state drive, magnetic tape, floppy disk, optical disc and any combination thereof.

The electronic device provided in the embodiment of the present application is used to implement the virtual simulation method based on the Autosar architecture as described in any of the aforementioned method embodiments. Its implementation principle and technical effect are similar and will not be described in detail here.

The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement a virtual simulation method based on the AUTOSAR architecture as described in any of the aforementioned method embodiments.

It can be understood that the memory in the embodiments of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus RAM (DR RAM). It should be noted that the above references to memory are intended to include, but are not limited to, these and any other suitable types of memory.

An embodiment of the present application also provides a computer program product, which includes a computer program, which is stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when at least one processor executes the computer program, it can implement any one of the virtual simulation methods based on the AUTOSAR architecture described in the aforementioned method embodiments.

Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims (10)

1. A virtual simulation method based on Autosar architecture, the method comprising:

Transmitting the compiled executable file to a file system of a virtual machine, wherein the executable file comprises a function module of a basic software layer, a function module of an application layer and a runtime environment layer in Autosar architecture;

starting an execution program of the virtual machine, loading the executable file in the virtual machine environment, and loading the executable file in the virtual machine environment for simulating an interactive function between a functional module of the application layer and simulation hardware;

executing the virtual simulation test and obtaining a virtual simulation test result.

2. The method of claim 1, wherein performing the virtual simulation test and obtaining virtual simulation test results comprises:

Sending a virtual debugging instruction of a debugger to the virtual machine;

And running the virtual debugging instruction in the virtual machine, and obtaining a virtual simulation test result of the virtual modulation instruction.

3. The method of claim 1, wherein performing the virtual simulation test and obtaining virtual simulation test results comprises:

Acquiring an input signal test case, wherein the input signal test case comprises a plurality of input signals and expected values of each input signal;

According to a preset mapping relation between input signals and communication protocols, encapsulating the input signal test cases into a plurality of analog messages, wherein each analog message corresponds to one communication protocol of one input signal;

sending the plurality of simulation messages to a virtual machine;

and obtaining a test value of the virtual machine on the input signal in each simulation message.

4. A method according to claim 3, characterized in that the method further comprises:

comparing whether the test value and the expected value of each input signal are the same;

if the test value and the expected value of each input signal are identical, the virtual simulation test is passed;

If the test value and the expected value of any input signal are different, the virtual simulation test fails, and the configuration file corresponding to the executable file is modified.

5. The method of claim 1, wherein performing the virtual simulation test and obtaining virtual simulation test results comprises:

acquiring an output signal test case, wherein the output signal test case comprises a plurality of output signals and expected values of each output signal;

generating test codes of each output signal according to a preset test code generating software tool package, wherein the test codes of each output signal are used for simulating the generation of the output signal in a virtual machine;

Compiling the test code of each output signal to generate an executable file of each output signal;

And loading the executable file of each output signal into the virtual machine for execution, and obtaining the test value of each output signal.

6. The method of claim 5, wherein the test code includes test functions that can reference different output signals.

7. The method according to any one of claims 1 to 6, further comprising:

Obtaining hardware attribute data configured by a user, wherein the hardware attribute data comprises: the processor architecture, the number of processors and the memory size, wherein the hardware attribute data are used for simulating the hardware configuration of the target system;

And simulating the virtual machine environment of the advanced reduced instruction set computer ARM architecture in the virtual machine according to the hardware attribute data.

8. A virtual simulation apparatus based on Autosar architecture, the apparatus comprising:

an acquisition module for acquiring hardware attribute data configured by a user, the hardware attribute data includes: the processor architecture, the number of processors and the memory size, wherein the hardware attribute data are used for simulating the hardware configuration of the target system;

The virtual module is used for simulating the virtual machine environment of the ARM architecture of the advanced reduced instruction set computer in the virtual machine according to the hardware attribute data;

the transmission module is used for transmitting the compiled executable file to a file system of the virtual machine, wherein the executable file comprises a function module of a basic software layer, a function module of an application layer and a runtime environment layer in Autosar architecture;

the simulation module is used for starting an execution program of the virtual machine, loading the executable file in the virtual machine environment, and loading the executable file in the virtual machine environment for simulating an interactive function between a functional module of an application layer and simulation hardware;

The simulation test module is used for executing the virtual simulation test and obtaining a virtual simulation test result.

9. An electronic device, the electronic device comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes the computer-executable instructions stored by the memory to implement the Autosar architecture-based virtual simulation method of any one of claims 1 to 7.

10. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are for implementing the Autosar architecture based virtual simulation method of any one of claims 1 to 7.