Virtual compiling integration method, simulation device, computer equipment and storage medium

Abstract

The invention belongs to the technical field of vehicle engineering, and particularly discloses a virtual compiling integration method, which is used for compiling and integrating a plurality of vehicle-mounted ECUs (Electronic Control Unit) and a plurality of controlled objects in the same software simulation framework for simulation, and comprises the following steps of: respectively generating FMU library files based on source codes of the vehicle-mounted ECUs and the controlled objects, the FMU library file further comprises an FMU library file of a stub function written for the first vehicle-mounted ECU to be tested; in the predefined software simulation framework, integrating and compiling the plurality of FMU library files into an executable file; a process is started, execution of the executable file is started, each FMU library file generates an independently running thread, and the threads are started in response to different triggering conditions. The method has the advantage that the compiling and running efficiency can be remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle engineering, and in particular to a virtual compilation integration method, a simulation device, a computer device, and a storage medium. Background Art

[0002] Smart vehicles are the general trend of vehicle development. They need to undergo a lot of testing and verification work before mass production and delivery to ensure the safety and stability of smart driving vehicles. At present, the testing and verification methods include software in the loop SIL (Software in the Loop) testing, hardware in the loop HIL (Hardware in the Loop) testing, real vehicle in the loop VIL (Vehicle in the Loop) testing, real vehicle field testing and public road testing according to different R&D stages.

[0003] Among them, the simulation of embedded software running in each ECU (Electronic Control Unit) is the most important step. At present, the market for embedded software virtualization compilation integration tools refers to the ASAM XIL standard specification, mainly based on FMU (Functional Mock-Up Unit) technology and TCP / IP server-client communication method to achieve software integrated compilation. That is, the embedded software and the controlled object model are compiled separately, and then interactive simulation is performed through a custom Ethernet communication protocol. The characteristics of this method are that it is easy to expand FMU and can be compatible with multiple types of operating systems to achieve cross-platform simulation testing, but the disadvantages are also obvious, that is, the simulation efficiency is low, the running rate is relatively slow, and the bottleneck lies in the communication rate between multiple FMUs.

[0004] In view of the above problems, it is urgent to propose a method to improve the simulation efficiency. Summary of the invention

[0005] In order to solve the above problems and improve the simulation efficiency, the present invention proposes a virtual compilation integration method, which compiles and integrates multiple vehicle-mounted ECUs and multiple controlled objects in the same software simulation framework for simulation, including the following steps:

[0006] Generate FMU library file respectively based on the source code of described on-board ECU and described controlled object, described FMU library file also comprises the FMU library file of the pile function written for the first on-board ECU to be tested;

[0007] In the predefined software simulation framework, integrating and compiling the plurality of FMU library files into one executable file;

[0008] A process is started to execute the executable file, wherein each of the FMU library files generates an independently running thread, and the thread is started in response to different trigger conditions.

[0009] In the above method, multiple threads implement cross-thread data exchange through shared memory.

[0010] In the above method, a shared memory area is set in the system memory, and a status information card is set for each shared data. The thread determines whether the shared memory area can be read and written according to the information of the status information card.

[0011] In the above method, for the specified data, whether the check code is correct is verified during the reading and writing process.

[0012] In the above method, for security-related data, a data encryption method is used to encrypt the data to ensure data security during the process of reading and writing data.

[0013] The present application also discloses a virtual simulation device, which runs as a process in an operating system, including: a software simulation framework and multiple threads, wherein the software simulation framework provides a basic operating environment for the multiple threads, and one thread implements the function of an on-vehicle ECU.

[0014] In the above device, the thread is compiled from the FMU library file and corresponds one-to-one with the FMU library file. One FMU library file contains the software content of one vehicle-mounted ECU.

[0015] The present application also discloses a computer device, comprising:

[0016] at least one memory for storing computer instructions;

[0017] At least one processor implements the above method when the at least one processor executes the computer instructions.

[0018] The present application also discloses a computer-readable storage medium, in which at least one computer instruction is stored. The at least one instruction is loaded and executed by a processor to implement the above method.

[0019] Compared with the prior art, the present invention centrally compiles the ECU and the controlled object into one executable file. During the simulation operation, the communication between multiple ECUs and between the tested ECU and the controlled object is changed from the network communication in the prior art to the communication between threads, and the communication efficiency is greatly improved. The simulation bottleneck of the prior art is that network communication takes too much time, which affects both the running speed and the real-time performance of the simulation. The present application solves the problem of utilizing the characteristics of efficient communication between threads (compiling the embedded software of the ECU into threads) to greatly save the communication waiting time, thereby improving the simulation efficiency and running speed. According to practical data, the running efficiency depends on the processor running speed and memory access speed of the PC and the server, and the single-step running speed of the local PC is no more than 1ms. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a schematic diagram of an OSI architecture based on network protocol simulation in the prior art;

[0021] Figure 2 It is a system block diagram of virtual compilation and integrated embedded software in this application;

[0022] Figure 3 is a schematic diagram of shared memory between virtual controllers in this application;

[0023] Figure 4 It is a flowchart of the virtual compilation integration in this application;

[0024] Figure 5 It is a schematic diagram of the hardware structure in this application. DETAILED DESCRIPTION

[0025] The following specific embodiments illustrate the implementation of the present invention, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. Although the description of the present invention will be introduced in conjunction with the preferred embodiment, this does not mean that the features of this invention are limited to this implementation. On the contrary, the purpose of introducing the invention in conjunction with the implementation is to cover other options or modifications that may extend based on the claims of the present invention. In order to provide a deep understanding of the present invention, the following description will include many specific details. The present invention can also be implemented without using these details. In addition, in order to avoid confusion or blurring the focus of the present invention, some specific details will be omitted in the description. It should be noted that the embodiments of the present invention and the features in the embodiments can be combined with each other without conflict.

[0026] It should be noted that in this specification, similar numbers and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings and is assumed to be the same definition.

[0027] It should also be stated that the methods and processes in the present invention are numbered for ease of reference, rather than to limit the order of precedence. If there is an order between the steps, the text description shall prevail.

[0028] In order to make the objectives, technical solutions and advantages of the present invention more clear, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0029] Figure 1 It is a schematic diagram of the OSI architecture based on network protocol simulation in the prior art. As described in the background technology, the current embedded software virtualization compilation integration tools are carried out in accordance with the ASAM XIL standard specifications, and mainly based on FMU (Functional Mock-Up Unit) technology and TCP / IP server-client communication methods to achieve integrated software compilation. That is, the embedded software and the controlled object model are compiled separately, and then interactive simulation is performed through a custom Ethernet communication protocol. As shown in the figure, when server 1 and users 2a-c are connected through the network, the data sent by server 1 must pass through the 7 layers of the OSI network model and be sent down layer by layer, and then pass through the 11 layers of the TCP / IP model to send data outward. The user 2a end must reversely pass through the above 11 layers of transmission to receive data. Among them, if there are many users communicating with server 1 at the same time in the same time period, the network transmission will be more time-consuming. Obviously, Figure 1 In the simulation method shown, FMU can be flexibly expanded and has great compatibility with the operating system, and can realize cross-platform simulation testing. However, it also has obvious disadvantages. The simulation efficiency is not high. The bottleneck is that the communication between multiple FMUs depends on network communication. When network communication is used in the laboratory simulation stage, the communication rate / efficiency is relatively low.

[0030] The present application proposes a compilation integration method, which puts multiple FMUs and controlled objects together and compiles them into executable files. Thus, multiple FMUs and multiple controlled objects are included in a program / process, and the TCP / IP mechanism can be eliminated between multiple FMUs and multiple controlled objects, as long as they communicate in the same single machine. Among them, FMU is a standard data interaction file, which can be understood as a compressed folder, including executable files such as DLL, xml and interface information description files. An FMU can be packaged into a client (Client). In theory, there can be an unlimited number of FMUs (i.e., there can be an unlimited number of clients). In other words, any number of clients with different functions can be expanded as needed, and the expansion of the simulation system is more flexible. During compilation, since the original controller was developed according to the embedded system, many of the underlying programs were written with reference to the requirements of the peripheral hardware used, but the operating environment of the compiled executable program in the present application is the PC end, so it is necessary to rewrite the underlying basic driver under the premise of retaining the controller software logic and configuration to the greatest extent, so that the controller software code can run on the PC, while not changing the original running logic of the software, such as scheduling time mode, priority, etc.

[0031] Figure 2 It is a system block diagram of virtual compilation and integrated embedded software in this application. As shown in the figure, in the operating system 40, a virtual simulation device (process) 20 is included. When simulation is required, the device is started, and each thread in the device starts or pauses work according to the instruction to verify whether the logic of the tested vehicle-mounted ECU is reasonable in the computer environment. The operating system 40 can be a stand-alone machine or a server, and can be installed with a Windows operating system or a Linux system. When generating FMU, you can freely choose to export it as an adapted operating system.

[0032] The virtual simulation device (process) 20 includes multiple threads, such as FMU 31a for simulating a vehicle battery management system (BMS), FMU 31b for simulating a vehicle control unit (Control Unit), FMU 31c for simulating a road condition (Control Unit), FMU 31d for BMS testing, and other threads.

[0033] In order to realize the above functions, it is also necessary to write stub functions to simulate peripheral hardware. In the stub functions, the operation codes of the peripheral registers in many chips are modified into function bodies that can be run on the PC side to simulate the functions of these registers in the hardware chips, such as simulating SPI bus communication and CAN bus communication.

[0034] Assuming the application scenario based on BMS virtualization technology, the operation architecture of single-machine multi-thread is adopted, and the data interaction between different controller virtualization modules (FMU / DLL) is realized by data sharing. First, the software configuration and vehicle controller architecture information are imported, and the distribution software thread (one ECU one thread) is automatically created according to the simulation requirements and the number of vehicle controllers. Each thread simulates the logical behavior of a specific controller, and the simulation pile function required for testing the BMS software is merged at the same time, and a specific thread is generated for auxiliary testing. In the present embodiment, the pile function is used to simulate the register operation function of the embedded system (each vehicle-mounted ECU), such as simulating the read / write function of the CAN transceiver. Taking CAN communication as an example, in an embedded system, the bottom driver software directly operates the register of the controller peripheral to realize the read-write function. For example, when writing data, the signal data is directly filled into the mailbox of the register, or when reading data, the letter is directly read from the mailbox. And there is no transceiver chip used in the embedded system on the PC or server, and the data in the PC or server is realized by reading and writing memory. Shared memory can be opened and used according to a custom communication protocol, and memory reading and writing can be protected during the process to implement the sending and receiving functions. In order to ensure the equivalence of software virtualization, driver functions with the same name as the embedded Autosar software can be used to simulate their functions, namely stub functions.

[0035] Figure 4 The flowchart of virtual compilation integration in the present application is shown. Based on the virtual simulation device (process) 20, the present application also proposes a simulation method, which compiles and integrates multiple vehicle-mounted ECUs and multiple controlled objects in the same software framework for simulation, including the following steps:

[0036] S1, based on the source code of the on-board ECU and the controlled object, FMU library files are respectively packaged and generated by FMU, and the FMU library files also include the FMU library files of the pile function written for the first on-board ECU to be tested.

[0037] S2, integrating and compiling the plurality of FMU library files into one executable file in a predefined software simulation framework. The predefined software simulation framework refers to Figure 1 The same architecture, but the communication core is replaced by network communication Figure 3 The communication method through shared memory is shown in the figure. When compiling, you can use the standard GCC or MS compiler to compile to ensure that the stub function is compiled correctly, so that the generated target file can be run on the PC. When compiling, first unpack the FMU library file, then load the DLL file contained in the library file, and generate an executable file.

[0038] The S3 operating system 10 starts / runs / terminates the executable file, i.e., starts a process and starts executing the executable file, wherein each of the FMU library files generates an independently running thread, and the thread is started in response to different trigger conditions. Multiple threads realize cross-thread data exchange through shared memory.

[0039] Exchanging data between threads through shared memory can make data exchange faster, so as to simulate the working state of the physical ECU as realistically as possible (the typical execution time of an instruction is in milliseconds). In this embodiment, a shared memory area is set in the system memory, and a status information card is set for each shared data. The thread determines whether to read and write the shared memory area according to the information of the status information card. For example, a queuing strategy similar to calling numbers in a restaurant can be adopted, and a status information card can be set for each shared data. At each idle moment, a number can be provided to the thread that needs to read / write data, and the information card status is set at the same time. When the number obtained by the thread is consistent with the information card, the data can be accessed, otherwise it enters a waiting state. When the subsequent data is idle and the card number is updated to be consistent with the card number held, the thread can access the data. Figure 3 A schematic diagram of shared memory between virtual controllers is shown. FMU 31a occupies a private memory alone, and FMU 31d also occupies a private memory alone. FMU 31a, FMU 31b, and FMU 31d can also use the shared memory area at the same time. Since multiple users have the right to read and write the shared memory, it is easy to cause read-write conflicts, and incorrect data may also be read. Therefore, this application adopts the above-mentioned information card mechanism to prompt that there is currently a thread occupying the read and write, and the later-arriving thread needs to wait.

[0040] For designated data, such as important data, it is also necessary to prevent the data from being interfered with or modified by mistake during the reading and writing process. It is necessary to set data accuracy verification, such as CRC verification. When the data is read and written, it is necessary to verify whether the CRC is correct at the same time to determine whether the data is valid. The CRC verification value can also be saved in the status information card. The following table shows a representation of the status information card:

[0041]

[0042] For security-related data, private protocols can be specified and special data encryption methods can be developed to ensure the confidentiality of data during the reading and writing process.

[0043] The above-mentioned embodiments use multi-threading and shared memory technology to improve operation efficiency. A mature operating system architecture is used to improve the stability of operation, and multi-task priority configuration is supported. A private communication protocol (such as setting a status information card) is used to achieve data interaction and encryption. The fault tolerance is strong. When a single thread fails and cannot run, it does not affect other threads to continue working, and the simulation can continue. After the system restarts the error thread again, the simulation can return to the normal working mode.

[0044] Moreover, as the vehicle's ECU, this device is also highly compatible with the Autosar software architecture.

[0045] The embodiments provided by the present invention may be run in an electronic device 100. Specifically, the electronic device 100 may be a computer device or a server for running the virtual compilation integration method and apparatus described in the present application. Figure 5 A basic hardware structure diagram of the electronic device 100 is given.

[0046] like Figure 5 As shown, the electronic device 100 at least includes a main processor 101 and a storage medium 103. According to different actual use requirements, the electronic device 100 may also include a coprocessor 102, an I / O unit 104, a network communication unit 105, and some other expansion units 106. The selectivity of the coprocessor 102, the I / O unit 104, the network communication unit 105, and other expansion units 106 is shown in the figure by dotted lines.

[0047] The main processor 101 and / or the coprocessor 102 are used to execute computer instructions stored in the storage medium 103 to implement the method proposed in the present invention. The main processor 101 is the control center of the electronic device 100, which is usually a general-purpose processor (for example, Intel's CPU series), which can achieve logical processing and arithmetic calculations in a relatively balanced manner. The main processor 101 uses various interfaces to connect various parts of the entire electronic device 100, and realizes various functions of the electronic device 100 by running or executing software programs stored in the storage medium 103, and calling data stored in the storage medium 103, thereby managing the electronic device 100 as a whole.

[0048] The coprocessor 102 is usually a dedicated processor (e.g., a user-programmable embedded microprocessor) used to implement a single function. For example, the coprocessor 102 may be a graphics processor (GPU) dedicated to processing graphics and images. The main processor 101 does not directly process information about graphics and images at this time, but provides data from other units to the coprocessor 102 or sends management instructions to the coprocessor 102 to instruct the coprocessor 102 to obtain data from other units, and after the coprocessor 102 processes the data, the main processor 101 receives the processing result from the coprocessor 102 so that other decisions can be made based on the processing result. For different professional fields, the coprocessor 102 can also be a signal processor, a network communication processor, a complex computing processor, etc. Usually, the hardware implementation basis of the coprocessor 102 is a digital signal processing (DSP) chip, or a complex programmable logic device (CPLD), a field programmable gate array (FPGA), and other application-specific integrated circuits (ASIC, Application Specific Integrated Circuit).

[0049] The storage medium 103 may include an internal memory and an external memory, or may also include a volatile memory and a non-volatile memory, or may also include a magnetic storage device, a solid-state memory, a flash memory, a floppy disk, and a hard disk. The storage medium 103 may be used to store an operating system (e.g., it may be executed by the main processor 101) and data generated during the operation of the operating system, a software program of an application software and data generated during the operation of the application software, and a software program of a dedicated module (e.g., it may be executed by a certain coprocessor 102) and data generated during the operation of the program. For example, in one embodiment of the present invention, the main processor 101 executes various functional applications and data processing by running a monitoring program stored in the storage medium 103. In some embodiments, the storage medium 103 may also be a remote memory (relative to a memory in the usual sense) remotely arranged relative to the main processor 101, and these remote memories may be connected to the main processor 101 or a certain coprocessor 102 via a network connection (e.g., via a network communication device 105). Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0050] The I / O (Input / Output) unit 104 includes an information input device and an information output device, which enables a user to interact with the electronic device 100. The input device can be used to receive input digital or character information, and specifically can include: a keyboard, a mouse, a joystick, a touch input device or a trackball, etc. The output device can be used to output / display a processing result processed by the electronic device 100, and the processing result can be made based on the information input by the input device. Specifically, the output device can include: a liquid crystal display (Liquid Crystal Display, LCD), an organic light-emitting diode (Organic Light-Emitting Diode, OLED), etc.

[0051] The network communication unit 105 realizes communication between the electronic device 100 and various remote devices through the connection of the wired / wireless network, so that the electronic device 100 can also exchange data with the remote device (for example, the remote storage described above). Alternatively, the electronic device 100 can also realize connection with the server through the network communication unit 105, so that the electronic device 100 can interact with the server as part of a large system.

[0052] Other expansion units 106 include a variety of peripheral components and interfaces thereof, so that the electronic device 100 can interact with a variety of devices. For example, through a Bluetooth interface, it can be connected to a Bluetooth headset, so that the audio played by the electronic device 100 can be received by the Bluetooth headset. For another example, through a bus interface (such as an RS-485 bus), the electronic device 100 can be connected to some sensors to obtain some monitoring data to assist the electronic device 100 in implementing specific functions. In various embodiments, other expansion interfaces 106 can exist alone or be integrated with other components of the electronic device 100. At the same time, other expansion interfaces 106 are optional, and their optional nature is represented in the figure by dotted lines.

[0053] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.

[0054] Similarly, it should be understood that in order to streamline the present invention and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed method should not be interpreted as reflecting the intention that the claimed invention requires more features than those expressly recited in each claim. Rather, as reflected in the claims, inventive aspects lie in less than all of the features of the individual embodiments previously disclosed. Therefore, the claims that follow the detailed description are hereby expressly incorporated into the detailed description, with each claim itself serving as a separate embodiment of the present invention.

[0055] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and in addition they may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive, all features disclosed in this specification (including the accompanying claims, abstracts and drawings) and all processes or units of any method or device disclosed in this manner may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstracts and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0056] In addition, those skilled in the art will appreciate that, although some embodiments described herein include certain features included in other embodiments but not other features, the combination of features of different embodiments is meant to be within the scope of the present invention and form different embodiments. For example, in the claims, any one of the claimed embodiments may be used in any combination.

Claims

1. A virtual compilation integration method, characterized in that: Compiling and integrating multiple vehicle-mounted ECUs and multiple controlled objects in the same software simulation framework for simulation includes the following steps: Generate FMU library file respectively based on the source code of described on-board ECU and described controlled object, described FMU library file also comprises the FMU library file of the pile function written for the first on-board ECU to be tested; In the predefined software simulation framework, integrating and compiling the plurality of FMU library files into one executable file; A process is started to execute the executable file, wherein each of the FMU library files generates an independently running thread, and the thread is started in response to different trigger conditions.

2. The method according to claim 1, characterized in that Cross-thread data exchange between multiple threads is achieved through shared memory.

3. The method according to claim 2, characterized in that A shared memory area is set in the system memory, and a status information card is set for each shared data. The thread determines whether the shared memory area can be read and written according to the information of the status information card.

4. The method according to claim 1, characterized in that For the specified data, verify whether the checksum is correct during the reading and writing process.

5. The method according to claim 1, characterized in that For security-related data, data encryption methods are used to encrypt the data to ensure data security during the reading and writing process.

6. A virtual simulation device, characterized in that: As a process running in the operating system, it includes: a software simulation framework and multiple threads, the software simulation framework provides a basic running environment for the multiple threads, and one thread realizes the function of one vehicle-mounted ECU.

7. The device according to claim 7, characterized in that The threads are compiled from FMU library files and correspond one-to-one to the FMU library files. One FMU library file is used to simulate the logical behavior of one vehicle-mounted ECU.

8. A computer device, characterized in that: include: at least one memory for storing computer instructions; At least one processor, when the at least one processor executes the computer instruction, performs the virtual compilation integration method according to any one of claims 1-5.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer instruction, and the at least one instruction is loaded and executed by a processor to implement the virtual compilation integration method according to any one of claims 1 to 5.

Images