Virtual electronic control unit simulation apparatus and method
Patent Information
- Application Number
- KR1020240020598
- Authority / Receiving Office
- KR · KR
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2023-12-22
- Filing Date
- 2024-02-13
- Publication Date
- 2026-10-13
- Estimated Expiration
- 2044-02-13
Smart Images

Figure 112024016702624-PAT00002_ABST
Abstract
Description
Technology Field
[0001] The present invention relates to a virtual ECU (Electronic Control Unit) simulation device and method. Background Technology
[0003] The automotive industry is developing various ECUs to enhance vehicle performance and safety. ECUs play a role in controlling electrical systems or components such as the engine, transmission, brakes, and airbags. Recently, with the electrification of vehicles and the advancement of autonomous driving technology, the types and number of ECUs are increasing, and the amount of automotive software running on them is also growing.
[0004] In the development of automotive systems, hardware development lags behind software development; consequently, even if software development proceeds first, there is a problem in that there is no physical environment available for testing. Therefore, a simulation environment capable of testing developed software in advance is essential. Furthermore, with the introduction of autonomous driving, the complexity of testing and evaluation required for the development of electronic control systems and the volume of test cases have increased exponentially, further heightening the need for simulation in a virtual environment.
[0005] Accordingly, there has been a recent increase in the adoption of virtual ECUs in virtual vehicle environment simulations. A virtual ECU is an ECU implemented in software for the verification of automotive microcontrollers, and simulations using virtual ECUs offer several advantages.
[0006] First, software development and testing can be carried out in parallel even before the actual ECU hardware development is completed, which can save development time and costs.
[0007] Second, since it provides the same functions and interfaces as the actual ECU hardware, it can reduce compatibility issues with the actual vehicle.
[0008] Third, because it can be integrated with various simulation tools, it is possible to set up and test various situations and conditions.
[0009] However, since simulation tools for these virtual ECUs are developed in each developer's own way, it is difficult to integrate various tools for simulation.
[0010] Therefore, research is needed on methods to simulate virtual ECUs by integrating various simulation tools. Prior art literature
[0012] Korean Registered Patent Publication No. 10-2586821 The problem to be solved
[0013] The present invention has been devised to solve the above-mentioned problems, and the objective of the present invention is to provide a virtual ECU simulation device and method. means of solving the problem
[0015] A virtual ECU simulation device according to an embodiment of the present invention for achieving the above objective comprises: a master unit that initializes at least one slave model including functions that define simulation operations; and a wrapper FMU that connects the virtual ECU and a socket CAN; wherein the master unit executes a function of the slave model to receive a CAN message transmitted from the virtual ECU through the wrapper FMU, receives the result of the execution of the function from the slave model, and updates the input of the slave model at the next simulation time step based on the result of the execution of the function.
[0016] A virtual ECU simulation method of a simulation device comprising a master unit and a wrapper FMU according to an embodiment of the present invention for achieving the above objective comprises: a step in which the master unit initializes at least one slave model including functions that define simulation operations; a step in which the wrapper FMU connects the virtual ECU with a socket CAN; a step in which the master unit executes a function of the slave model and receives a CAN message transmitted from the virtual ECU through the wrapper FMU; and a step in which the master unit receives the execution result of the function from the slave model and updates the input of the slave model at the next simulation time step based on the execution result of the function. Effects of the invention
[0018] According to one aspect of the present invention described above, by providing a virtual ECU simulation device and method, the scope of application of the virtual ECU is expanded and integration with various simulation platforms supporting FMI is possible, thereby improving the reusability and portability of the virtual ECU.
[0019] In addition, the quality and efficiency of integrated simulation are improved, and since virtual ECUs and other models interact in an accurate and consistent manner through FMI, the reliability and accuracy of the integrated simulation can be enhanced.
[0020] In addition, by using a wrapper FMU, separate work is unnecessary to apply the virtual ECU to other simulation platforms, thereby reducing the time and cost of building integrated simulations. Brief explanation of the drawing
[0022] FIG. 1 is a conceptual diagram of an overall system including a simulation device and a virtual ECU according to an embodiment of the present invention, FIG. 2 is a diagram illustrating the operation of a simulation device according to an embodiment of the present invention performing a simulation of a virtual ECU. FIG. 3 is a diagram for explaining the operation of a connection setting / unsetting block constituting the wrapper FMU of FIG. 2. FIG. 4 is a diagram for explaining the operation of a decoder and a first message conversion block constituting the wrapper FMU of FIG. 2. FIG. 5 is a diagram for explaining the operation of a second message conversion block and an encoder constituting the wrapper FMU of FIG. 2. And, FIG. 6 is a flowchart illustrating the virtual ECU simulation operation of a simulation device according to an embodiment of the present invention. Specific details for implementing the invention
[0023] The following detailed description of the invention refers to the accompanying drawings, which illustrate specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that various embodiments of the invention are different but need not be mutually exclusive. For example, specific shapes, structures, and characteristics described herein may be implemented in other embodiments without departing from the spirit and scope of the invention in relation to one embodiment. It should also be understood that the location or arrangement of individual components within each disclosed embodiment may be changed without departing from the spirit and scope of the invention. Accordingly, the following detailed description is not intended to be limiting, and the scope of the invention is limited only by the appended claims, including all equivalents to those claimed therein, provided appropriately described. Similar reference numerals in the drawings refer to the same or similar functions across various aspects.
[0024] The components according to the present invention are defined by functional distinction rather than physical distinction, and can be defined by the functions each performs. Each component may be implemented as hardware or as program code and processing units that perform each function, and the functions of two or more components may be included and implemented in a single component. Therefore, it should be noted that the names assigned to the components in the following embodiments are not intended to physically distinguish each component but are assigned to imply the representative function performed by each component, and that the technical concept of the present invention is not limited by the names of the components.
[0025] Before describing the present invention, we will briefly explain the Functional Mock-up Interface (FMI). FMI is a standard interface created to develop complex Cyber-Physical Systems (CPS) in simulation.
[0026] In addition, FMI is used to create a container in the form of a ZIP file consisting of XML (Extensible Markup Language), binary data, and C code, which is called a Functional Mock-up Unit (FMU). The FMU is integrated simulationd by exchanging dynamic simulation models of the corresponding FMU in the FMI integrated simulation environment, and supports Co-Simulation (CS) and Model Exchange (ME) methods.
[0027] The CS method refers to a system where each FMU performs simulations using its own internal solver and exchanges information with other FMUs only at communication points with fixed time intervals. While this CS method offers fast and stable simulation speeds, it may result in time synchronization errors.
[0028] The ME method refers to a technique where each FMU provides a model consisting of numerical equations describing its state, and an external solver integrates this to perform the simulation. Because the external solver calculates the state and state change rate of each FMU and determines appropriate time intervals, this ME method offers high simulation accuracy but can be slow and unstable.
[0029] Preferred embodiments of the present invention will be described in more detail below with reference to the drawings.
[0030] FIG. 1 is a conceptual diagram of an overall system including a simulation device and a virtual ECU according to an embodiment of the present invention.
[0031] The illustrated system includes a simulation device (110) and a virtual ECU (vECU) (120). The simulation device (110) is composed of a master unit (112) and a wrapper FMU (114), and the virtual ECU (120) is composed of a slave model (122) containing functions that define simulation operations. Here, it is assumed that the simulation device (110) performs FMI simulation through a CS method.
[0032] FIG. 2 is a diagram illustrating the operation of a simulation device according to an embodiment of the present invention performing a simulation of a virtual ECU.
[0033] The illustrated simulation device (110) is composed of a master unit (112) and at least one wrapper FMU (114-1, 114-2), said wrapper FMU (114-1, 114-2) is connected to a socket CAN (Controller Area Network) (130) based on a Linux Kernel through a socket CAN interface and is connected to the master unit (112) through a Functional Mock-up Interface (FMI).
[0034] Also, the socket driver of at least one illustrated virtual ECU (120-1, 120-2) is connected to the socket CAN (130) through the socket CAN interface.
[0035] When examining the simulation operation for the virtual ECU (120-1, 120-2) of the simulation device (110), first, the master unit (112) initializes at least one slave model that includes functions defining the simulation operation and configuring the virtual ECU (120-1, 120-2). That is, the master unit (112) creates a slave model instance through the fmi2Instatiate function, defines initial simulation conditions through the fmi2SetupExperiment function, and then enters the initialization mode by executing the fmi2EnterInitializationMode function. At this time, the wrapper FMU (114-1, 114-2) connects the virtual ECU (120-1, 120-2) with the socket CAN (130).
[0036] The master unit (112), having initialized the slave model in this way, executes the fmi2SetXXX function to set the state and input of the slave model. Here, XXX represents the specific type of function, and there are various versions such as fmi2SetReal, fmi2SetInteger, fmi2SetBoolean, and fmi2SetString. The fmi2SetReal function is used to set the input of a real type variable, the fmi2SetInteger function is used to set the input of an integer type variable, the fmi2SetBoolean function is used to set the input of a boolean type variable, and the fmi2SetString function is used to set the input of a string type variable.
[0037] Subsequently, the master unit (112) executes the fmi2DoStep function included in the slave model to receive a CAN message transmitted from the virtual ECU (120-2) through the wrapper FMU, and receives the execution result of the function from the slave model. That is, the master unit (112) receives the execution result of the fmi2DoStep function through the fmi2GetXXX function.
[0038] Then, the master unit (112) updates the state and input of the slave model at the next simulation time step based on the execution result of the fmi2DoStep function through the fmi2SetXXX function.
[0039] Finally, the master unit (112) terminates the simulation session using FMI through the fmi2Terminate function and releases the slave model instance through the fmi2FreeInstance function.
[0040] Meanwhile, the wrapper FMU (114-1, 114-2) may be composed of a connection setting / unsetting block, a decoder, a first message conversion block, a second message conversion block, and an encoder, and below, the operation of the wrapper FMU (114-1, 114-2) will be explained in more detail through FIGS. 3 to 5.
[0041] Figure 3 is a diagram illustrating the operation of a connection setting / unsetting block that constitutes the wrapper FMU of Figure 2.
[0042] The illustrated connection setup / disconnection block operates once at the start and end of the simulation for the virtual ECU. That is, when the simulation starts, the virtual ECU and the socket CAN are connected, and when the simulation ends, the connection is disconnected.
[0043] The above connection setup / release block is implemented as a C function and creates a socket using Posix's socket() function. It also initializes an address structure, selects a CAN family and interface, and binds each socket to the corresponding address.
[0044] FIG. 4 is a diagram illustrating the operation of the decoder and the first message conversion block constituting the wrapper FMU of FIG. 2.
[0045] The illustrated decoder receives and decodes a CAN message according to FMI simulation from the master unit, and the illustrated first message conversion block parses the decoded CAN message and converts it into a CAN message compatible with socket CAN and outputs it.
[0046] To explain in more detail, the decoder decodes the received CAN message, classifies it into SOF (Start of Frame), ID (Identifier), DLC (Data Length Code), and data fields, and transmits the decoded CAN message to the first message conversion block. At this time, the first message conversion block receives the CAN message when the SOF value is 1, and does not receive the CAN message when the SOF value is 0.
[0047] The first message conversion block stores ID and DLC values in the CAN message, converts the data by calling the FMIDataDecoder() function, copies the converted data to the CAN message, and outputs the CAN message through the socket CAN interface by calling the Write() function. Here, the output CAN message refers to a CAN message converted to be compatible with socket CAN.
[0048] FIG. 5 is a diagram illustrating the operation of the second message conversion block and encoder constituting the wrapper FMU of FIG. 2.
[0049] The illustrated second message conversion block parses a CAN message received through the socket CAN and converts it into a CAN message compatible with FMI, and the illustrated encoder encodes and outputs the converted CAN message.
[0050] To explain in more detail, the second message conversion block calls the Select() function to wait for data reception from the socket CAN, and determines the state in which data reception is possible based on the return value of the Select() function. That is, the second message conversion block determines the state to be an error state if the return value of the Select() function is less than 0, determines the state to be a waiting timeout state if it is 0, and determines the state to be in which data reception is possible if it is greater than 0.
[0051] Accordingly, the second message conversion block calls the read() function when the return value of the Select() function is greater than 0 to receive the CAN message of the socket CAN, sets the SOF value to 1, sets the ID and DCL fields to the values stored in the CAN message, calls the SocketDataDecoder() function to convert the data, and copies the converted data to the CAN message.
[0052] The encoder encodes and outputs the above CAN message, and the output CAN message refers to a CAN message converted to be compatible with FMI.
[0053] FIG. 6 is a flowchart illustrating the virtual ECU simulation operation of a simulation device according to an embodiment of the present invention.
[0054] The master unit initializes at least one slave model containing functions that define simulation operations (S601), and the wrapper FMU connects the virtual ECU and the socket CAN (S603).
[0055] Then, the master unit executes a function of the slave model to receive a CAN message transmitted from the virtual ECU through the wrapper FMU. (S605)
[0056] Subsequently, the master unit receives the execution result of the function from the slave model and updates the input of the slave model at the next simulation time step based on the execution result of the function. (S607)
[0057] The virtual ECU simulation method of the present invention as described above can be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc., either individually or in combination.
[0058] The program instructions recorded on the above-mentioned computer-readable recording medium may be those specifically designed and configured for the present invention, or they may be those known and available to those skilled in the art of computer software.
[0059] Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, and flash memory.
[0060] Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware device may be configured to operate as one or more software modules to perform processing according to the present invention, and vice versa.
[0061] Although various embodiments of the present invention have been illustrated and described above, the present invention is not limited to the specific embodiments described above. It is understood that various modifications can be made by those skilled in the art without departing from the essence of the invention as claimed in the claims, and such modifications should not be understood individually from the technical spirit or perspective of the present invention. Explanation of the symbols
[0063] 110: Simulation device 112: Master Unit 114, 114-1, 114-2: Rapper FMU 120, 120-1, 120-2: Virtual ECU 122: Slave model 130: Socket CAN
Claims
Claim 1 A virtual ECU simulation device comprising: a master unit that initializes at least one slave model including functions that define simulation operations; and a wrapper Functional Mock-up Unit (FMU) that connects a virtual Electronic Control Unit (ECU) and a socket Controller Area Network (CAN); wherein the master unit executes a function of the slave model to receive a CAN message transmitted from the virtual ECU through the wrapper FMU, receives the result of the execution of the function from the slave model, and updates the input of the slave model at the next simulation time step based on the result of the execution of the function. Claim 2 A virtual ECU simulation device according to claim 1, wherein the wrapper FMU includes a connection setting / unsetting block, and the connection setting / unsetting block connects the virtual ECU and the socket CAN when the simulation for the virtual ECU starts, and disconnects the connection when the simulation for the virtual ECU ends. Claim 3 A virtual ECU simulation device according to claim 1, wherein the wrapper FMU includes a decoder and a first message conversion block, the decoder receives and decodes a CAN message according to FMI (Functional Mock-up Interface) simulation from the master unit, and the first message conversion block parses the decoded CAN message and converts it into a CAN message compatible with the socket CAN and outputs it. Claim 4 A virtual ECU simulation device according to claim 1, wherein the wrapper FMU includes a second message conversion block and an encoder, the second message conversion block parses a CAN message received through the socket CAN and converts it into a CAN message compatible with FMI (Functional Mock-up Interface), and the encoder encodes and outputs the converted CAN message. Claim 5 A virtual ECU simulation device according to claim 1, characterized in that the wrapper FMU is connected to the master unit via FMI (Functional Mock-up Interface) and connected to the virtual ECU via a socket CAN interface. Claim 6 A virtual ECU (Electronic Control Unit) simulation method comprising a simulation device composed of a master unit and a wrapper FMU (Functional Mock-up Unit), the method comprising: a step in which the master unit initializes at least one slave model including functions that define simulation operations; a step in which the wrapper FMU connects the virtual ECU with a socket CAN (Controller Area Network); a step in which the master unit executes a function of the slave model and receives a CAN message transmitted from the virtual ECU through the wrapper FMU; and a step in which the master unit receives the execution result of the function from the slave model and updates the input of the slave model at the next simulation time step based on the execution result of the function. Claim 7 A virtual ECU simulation method according to claim 6, characterized in that the virtual ECU and the socket CAN are connected when the simulation for the virtual ECU starts, and the connection is released when the simulation for the virtual ECU ends. Claim 8 A virtual ECU simulation method according to claim 6, further comprising, prior to the step of receiving the CAN message, the step of the wrapper FMU receiving and decoding a CAN message according to FMI (Functional Mock-up Interface) simulation from the master unit, and parsing the decoded CAN message to convert it into a CAN message compatible with the socket CAN and outputting it. Claim 9 A virtual ECU simulation method according to claim 6, wherein the step of receiving the CAN message comprises the step of the wrapper FMU parsing the CAN message received through the socket CAN and converting it into a CAN message compatible with FMI (Functional Mock-up Interface), and encoding and outputting the converted CAN message. Claim 10 A virtual ECU simulation method according to claim 6, characterized in that the wrapper FMU is connected to the master unit via FMI (Functional Mock-up Interface) and connected to the virtual ECU via a socket CAN interface.
Citation Information
Patent Citations
System and method for verifying virtual ECU for automotive embedded system
KR102595323B1