Windows-based automotive software simulation device and method through autosar stack virtualization

Abstract

The present invention relates to a Windows-based vehicle software simulation device and method through AUTOSAR stack virtualization, wherein the device comprises: a code parsing unit that receives a configuration file of vehicle software created through a software development tool and parses information for the execution of the vehicle software from the configuration file; a code generation unit that generates execution codes for the execution of the vehicle software operating on a virtualized software platform based on the parsed information; an AUTOSAR platform virtualization unit that implements the virtualization of the software platform and simulates the operation of the vehicle software according to the execution of the execution codes; and an ECU virtualization processing unit that receives the output of the vehicle software according to the simulation and visualizes the operation of the virtualized ECU through a graphic interface based on the output.

Description

Technology Field

[0001] The present invention relates to software simulation technology, and more specifically, to a technology that enables Software-In-the-Loop Simulation (SILS) verification without hardware equipment such as a target board by simulating an application based on a vehicle software platform. Background Technology

[0003] Due to advancements in automotive infotainment and the electrification of vehicles, the number of internal ECUs has increased and their structures have become more complex, while the source code running within these ECUs is also becoming longer. As a result of this complexity, automakers have established automotive software standards and implemented standards and development methodologies for functional safety.

[0004] Typically, a development methodology utilizing the V-model can be used for the development and testing of automotive software. The V-model consists of design, implementation, and verification phases, and the design phase can be divided into requirements specification, system design, and model design. Once the design is complete, the system is developed and implemented, followed by a verification phase. During this verification, the process can begin with small-scale module testing and gradually expand to integration testing and system testing.

[0005] In addition, when developing using a V-model, simulations that virtually predict the operation of the system may be conducted to verify the results from each stage. There are simulation verification stages such as MILS, SILS, EILS, and HILS to satisfy functional safety, and development costs and time can be reduced by verifying errors through simulation at each stage.

[0006] Model-In-the-Loop Simulation (MILS) is a stage where system modeling is performed first based on the requirements specification and the model is mathematically verified. Subsequently, the Software-In-the-Loop Simulation (SILS) stage may proceed, which involves implementing the designed system model into software and verifying the operation of the implemented source code. After going through the SILS stage, error verification can be performed through ECU-In-the-Loop Simulation (EILS), a stage that verifies whether the implemented software program operates correctly using the ECU.

[0007] Once the EILS phase is completed, a Hardware-In-the-Loop Simulation (HILS) process may be performed to simulate operations implemented at the hardware level by actually combining the hardware components before the entire system is completed. At this time, separate debugging equipment is required during the EILS or HILS phases, which involve actual ECUs or hardware devices. Furthermore, if an error is detected, the cost incurred due to error correction can be very high because many factors, such as related hardware, target ECUs, and software issues like source code, must be considered.

[0008] To reduce these costs, it may be necessary to perform simulations on a virtual ECU that virtualizes the target ECU, rather than on the actual target ECU. Furthermore, as the application of the automotive software platform AUTOSAR expands, a virtual simulator linking the AUTOSAR platform with the ECU may be required. Prior art literature

[0010] Korean Registered Patent No. 10-1134735 (2012.04.02) The problem to be solved

[0011] One embodiment of the present invention aims to provide a Windows-based automotive software simulation device and method through AUTOSAR stack virtualization, which is expected to be highly useful for the development and verification testing of automotive software by virtualizing an AUTOSAR software platform and conducting simulations in a PC environment. means of solving the problem

[0013] Among the embodiments, a Windows-based vehicle software simulation device through AUTOSAR stack virtualization comprises: a code parsing unit that receives a configuration file of vehicle software created through a software development tool and parses information for the execution of the vehicle software from the configuration file; a code generation unit that generates execution codes for the execution of the vehicle software operating on a virtualized software platform based on the parsed information; an AUTOSAR platform virtualization unit that implements the virtualization of the software platform and simulates the operation of the vehicle software according to the execution of the execution codes; and an ECU virtualization processing unit that receives the output of the vehicle software according to the simulation and visualizes the operation of the virtualized ECU through a graphic interface based on the output.

[0014] The above code parsing unit can receive an ARXML (AUTOSAR eXtensible Markup Language) file of AUTOSAR-based software as a configuration file of the above vehicle software.

[0015] The code generation unit above can generate RTE (RunTime Environment) APIs and static code required for the execution of the vehicle software based on the parsed information.

[0016] The above AUTOSAR platform virtualization unit can generate virtual AUTOSAR platform code that implements virtualization for each module of the above software platform.

[0017] The above AUTOSAR platform virtualization unit can use the above execution codes and the above virtualized AUTOSAR platform code to perform the operation logic of the vehicle software during the simulation and generate a simulation file that can be operated in a Windows environment.

[0018] The above ECU virtualization processing unit can receive an output value from a virtual port of the virtualized software platform and output an operation corresponding to the output value through the virtualized ECU.

[0019] Among the embodiments, a Windows-based vehicle software simulation method through AUTOSAR stack virtualization comprises: a step of receiving a configuration file of vehicle software created through a software development tool in a code parsing unit and parsing information for the execution of the vehicle software from said configuration file; a step of generating execution codes for the execution of said vehicle software that operates on a virtualized software platform based on said parsed information in a code generation unit; a step of implementing virtualization of said software platform in an AUTOSAR platform virtualization unit and simulating the operation of said vehicle software according to the execution of said execution codes in a AUTOSAR platform virtualization unit; and a step of receiving an output of said vehicle software according to said simulation and visualizing the operation of said virtualized ECU through a graphic interface based on said output in an ECU virtualization processing unit.

[0020] The above parsing step may include receiving an ARXML (AUTOSAR eXtensible Markup Language) file of AUTOSAR-based software as a configuration file of the vehicle software.

[0021] The step of generating the above-mentioned executable codes may include the step of generating RTE (RunTime Environment) APIs and static code required for the execution of the vehicle software based on the above-mentioned parsed information.

[0022] The above-mentioned simulation step may include the step of generating virtual AUTOSAR platform code that implements virtualization for each module of the software platform.

[0023] The above-mentioned simulating step may include the step of performing the operation logic of the vehicle software during the simulation using the above-mentioned execution codes and the above-mentioned virtualization AUTOSAR platform code, and generating a simulation file that can be operated in a Windows environment.

[0024] The above visualization step may include receiving an output value from a virtual port of the virtualized software platform and outputting an operation corresponding to the output value through the virtualized ECU. Effects of the invention

[0026] The disclosed technology may have the following effects. However, this does not mean that a specific embodiment must include all of the following effects or only the following effects; therefore, the scope of the rights of the disclosed technology should not be understood as being limited by this.

[0027] A Windows-based automotive software simulation device and method using AUTOSAR stack virtualization according to an embodiment of the present invention enables SILS-based verification through a simulator that virtualizes a target ECU, without being dependent on test equipment or debugging equipment, such as in the EILS or HILS verification stages. Furthermore, errors that may occur in hardware, such as ECUs, can be predicted through software-based simulation, allowing for the reduction of errors by correcting errors that occur prior to the EILS and HILS verification stages. This reduces the time and cost required for building hardware test equipment, thereby providing the benefits of reduced development costs and shortened development cycles for automotive software. Additionally, it improves the ease of debugging and correction in the event of errors. Brief explanation of the drawing

[0029] FIG. 1 is a diagram illustrating a vehicle software simulation system according to the present invention. Figure 2 is a diagram illustrating the system configuration of the simulation device of Figure 1. Figure 3 is a diagram illustrating the functional configuration of the simulation device of Figure 1. Figure 4 is a diagram illustrating the overall concept of vehicle software simulation according to the present invention. FIG. 5 is a diagram illustrating an embodiment of a vehicle software simulation process according to the present invention. FIG. 6 is a drawing illustrating an embodiment of a vehicle software simulation system according to the present invention. FIG. 7 is a diagram illustrating an embodiment of an OS virtualization process according to the present invention. Specific details for implementing the invention

[0030] The description of the present invention is merely an example for structural or functional explanation, and therefore the scope of the present invention should not be interpreted as being limited by the examples described in the text. That is, since the examples are subject to various modifications and may take various forms, the scope of the present invention should be understood to include equivalents capable of realizing the technical concept. Furthermore, the objectives or effects presented in the present invention do not imply that a specific example must include all of them or only such effects; therefore, the scope of the present invention should not be understood as being limited by them.

[0031] Meanwhile, the meaning of the terms described in this application should be understood as follows.

[0032] Terms such as "first," "second," etc., are intended to distinguish one component from another, and the scope of rights shall not be limited by these terms. For example, the first component may be named the second component, and similarly, the second component may be named the first component.

[0033] When it is stated that one component is "connected" to another component, it should be understood that it may be directly connected to that other component, or that there may be other components in between. Conversely, when it is stated that one component is "directly connected" to another component, it should be understood that there are no other components in between. Meanwhile, other expressions describing the relationships between components, such as "between" and "exactly between," or "adjacent to" and "directly adjacent to," should be interpreted in the same way.

[0034] A singular expression should be understood to include a plural expression unless the context clearly indicates otherwise, and terms such as "include" or "have" are intended to specify the existence of the implemented features, numbers, steps, actions, components, parts, or combinations thereof, and should be understood not to preclude the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0035] In each step, identifiers (e.g., a, b, c, etc.) are used for convenience of explanation and do not describe the order of the steps; the steps may occur differently from the specified order unless a specific order is clearly indicated in the context. That is, the steps may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

[0036] The present invention may be implemented as computer-readable code on a computer-readable recording medium, and the computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. Additionally, the computer-readable recording medium may be distributed across networked computer systems, so that computer-readable code can be stored and executed in a distributed manner.

[0037] Unless otherwise defined, all terms used herein have the same meaning as generally understood by those skilled in the art to which this invention pertains. Terms defined in commonly used dictionaries should be interpreted as having meanings consistent with the context of the relevant technology and should not be interpreted as having an ideal or overly formal meaning unless explicitly defined in this application.

[0039] FIG. 1 is a diagram illustrating a vehicle software simulation system according to the present invention.

[0040] Referring to FIG. 1, a vehicle software simulation system (100) may include a user terminal (110), a simulation device (130), and a database (150).

[0041] A user terminal (110) may correspond to a terminal device operated by a user. In an embodiment of the present invention, a user may be understood as one or more users, and each of the one or more users may correspond to one or more user terminals (110). That is, although it is represented as one user terminal (110) in FIG. 1, the first user may correspond to the first user terminal, the second user to the second user terminal, ..., the nth user (where n is a natural number) may correspond to the nth user terminal.

[0042] Additionally, the user terminal (110) can be implemented as one device constituting the vehicle software simulation system (100) according to the present invention, and the vehicle software simulation system (100) can be modified and operated in various forms depending on the purpose of operating vehicle software developed through a software development tool in a Windows environment.

[0043] Additionally, the user terminal (110) can be implemented as a smartphone, laptop, or computer that is connected to and operable with the simulation device (130), and is not necessarily limited thereto, but can also be implemented as various devices including a tablet PC.

[0044] Meanwhile, a user terminal (110) can be connected to a simulation device (130) via a network, and multiple user terminals (110) can be connected to the simulation device (130) simultaneously.

[0045] The simulation device (130) may be implemented as a server corresponding to a computer or program that performs a Windows-based vehicle software simulation method through AUTOSAR stack virtualization according to the present invention. Additionally, the simulation device (130) may be connected to a user terminal (110) via a wired network or a wireless network such as Bluetooth, WiFi, LTE, etc., and may transmit and receive data with the user terminal (110) through the network.

[0046] Additionally, the simulation device (130) may be implemented to operate in connection with an independent external system (not shown in FIG. 1). In one embodiment, the simulation device (130) may be implemented as a cloud server.

[0047] The database (150) may correspond to a storage device that stores various information required during the operation of the simulation device (130). For example, the database (150) may store information regarding a vehicle software platform or information regarding virtualization simulation, but is not necessarily limited thereto, and may store information collected or processed in various forms during the process in which the simulation device (130) performs a Windows-based vehicle software simulation method through AUTOSAR stack virtualization according to the present invention.

[0048] In addition, in FIG. 1, the database (150) is shown as a device independent of the simulation device (130), but it is not necessarily limited to this and can be implemented as a logical storage device included in the simulation device (130).

[0050] Figure 2 is a diagram illustrating the system configuration of the simulation device of Figure 1.

[0051] Referring to FIG. 2, the simulation device (130) may include a processor (210), memory (230), user input / output unit (250), and network input / output unit (270).

[0052] The processor (210) can execute a vehicle software simulation procedure according to an embodiment of the present invention, manage memory (230) that is read or written during this process, and schedule the synchronization time between volatile memory and non-volatile memory in memory (230). The processor (210) can control the overall operation of the simulation device (130) and is electrically connected to the memory (230), user input / output unit (250), and network input / output unit (270) to control the data flow between them. The processor (210) can be implemented as a CPU (Central Processing Unit) or GPU (Graphics Processing Unit) of the simulation device (130).

[0053] The memory (230) may include an auxiliary storage device implemented as non-volatile memory such as an SSD (Solid State Disk) or HDD (Hard Disk Drive) and used to store all data required by the simulation device (130), and may include a main memory implemented as volatile memory such as RAM (Random Access Memory). Additionally, the memory (230) may store a set of instructions that execute the vehicle software simulation method according to the present invention by being executed by an electrically connected processor (210).

[0054] The user input / output unit (250) includes an environment for receiving user input and an environment for outputting specific information to the user, and may include an input device including an adapter such as a touch pad, touch screen, virtual keyboard, or pointing device, and an output device including an adapter such as a monitor or touch screen. In one embodiment, the user input / output unit (250) may correspond to a computing device connected via remote access, and in such case, the simulation device (130) may be performed as an independent server.

[0055] The network input / output unit (270) provides a communication environment for connecting to a user terminal (110) through a network and may include an adapter for communication such as a LAN (Local Area Network), MAN (Metropolitan Area Network), WAN (Wide Area Network), and VAN (Value Added Network). Additionally, the network input / output unit (270) may be implemented to provide short-range communication functions such as WiFi and Bluetooth, or wireless communication functions of 4G or higher, for wireless transmission of learning data.

[0057] Figure 3 is a diagram illustrating the functional configuration of the simulation device of Figure 1.

[0058] Referring to FIG. 3, the simulation device (130) may include a code parsing unit (310), a code generation unit (330), an AUTOSAR platform virtualization unit (350), an ECU virtualization processing unit (370), and a control unit (390).

[0059] At this time, the simulation device (130) does not need to include all of the above functional configurations simultaneously, and depending on each embodiment, some of the above configurations may be omitted, or some or all of the above configurations may be selectively included. Additionally, the simulation device (130) may be implemented as an independent module that selectively includes some of the above configurations, and may perform the Windows-based vehicle software simulation method according to the present invention through the interoperability between each module. The operation of each configuration will be described in detail below.

[0060] The code parsing unit (310) receives a configuration file of vehicle software created through a software development tool and can parse information for the execution of vehicle software from the configuration file. Here, the software development tool may correspond to a program that provides various functions to support the development of vehicle software. That is, a developer can develop vehicle software using the software development tool and perform various operations such as correcting errors or performing maintenance. The software development tool can generate and manage configuration files containing content set by the user during the development of vehicle software.

[0061] For example, a developer can perform system and ECU design through a software development tool. In the case of system design, settings regarding software components (SWC) and target ECUs can be determined, and in the case of ECU design, settings regarding ECU system configuration, RTE communication, and BSW modules can be determined. Accordingly, the code parsing unit (310) can extract information necessary to simulate the operation of vehicle software from a configuration file generated by the software development tool.

[0062] In one embodiment, the code parsing unit (310) may receive an ARXML (AUTOSAR eXtensible Markup Language) file of AUTOSAR-based software as a configuration file of vehicle software. Vehicle software may be generated based on an AUTOSAR platform corresponding to an open automotive standard software structure, and the AUTOSAR platform may manage software configuration files in the form of ARXML files.

[0063] For example, when software components for automotive software are created using an AUTOSAR-based software development tool, the corresponding components can be stored in an ARXML file, which is a standardized digital exchange format based on the AUTOSAR specification configured by the user. In this case, the generated ARXML file may include contents such as tasks, alarms, events, interrupts, priorities, periods, ports, and data elements.

[0064] That is, the code parsing unit (310) can receive an ARXML (AUTOSAR eXtensible Markup Language) file as a configuration file for AUTOSAR-based vehicle software. The code parsing unit (310) can provide an independent user interface (UI) for receiving the ARXML file and can also receive input through a user terminal (110).

[0065] In one embodiment, the code parsing unit (310) may restrictively receive only a file of a specific format as a configuration file for vehicle software. For example, the code parsing unit (310) may be restricted to receiving only an ARXML file as a configuration file, and if a file other than an ARXML file is input, it may receive the configuration file again or refuse to receive the file.

[0066] The code generation unit (330) can generate executable codes for the execution of vehicle software that operates on a virtualized software platform based on information parsed from the configuration file of the vehicle software. For example, the development process of vehicle software on an existing software platform can proceed as follows: when a project is compiled using a software development tool, a C file and a header file are generated based on the written ARXML, and a binary file is generated to flash it onto a target board, and finally, the process is executed on the target board. The code generation unit (330) can perform the operation of generating executable codes necessary for the vehicle software to operate on a virtualized software platform.

[0067] In one embodiment, the code generation unit (330) can generate RTE (RunTime Environment) APIs and static code required for the execution of vehicle software based on parsed information. Here, the RTE API is a runtime environment API that can provide specific interfaces between components or between a component and BSW (Basic Software). Additionally, the static code may correspond to source code that implements the functions of a component. The code generation unit (330) can generate static code that implements detailed functions of vehicle software using information parsed from a configuration file, and can generate an RTE API for the static code.

[0068] The AUTOSAR platform virtualization unit (350) can implement virtualization of the software platform and simulate the operation of the vehicle software according to the execution of the executable codes. For example, the virtualized software platform may correspond to a virtualized AUTOSAR platform. Here, the virtualized AUTOSAR platform may correspond to platform software in which RTE APIs and static codes can be executed, and by mimicking the existing AUTOSAR platform structure, it can perform logic according to the contents of the RTE APIs and static codes and perform the role of changing the output of the virtual port and transmitting it to a virtual target board. The AUTOSAR platform virtualization unit (350) can enable simulation of the operation of the vehicle software even in a Windows environment through the virtualization of the software platform.

[0069] In one embodiment, the AUTOSAR platform virtualization unit (350) can generate virtual AUTOSAR platform code that implements virtualization for each module of the software platform. At this time, the virtual AUTOSAR platform code can be implemented as a C file. That is, the AUTOSAR platform virtualization unit (350) can provide the existing AUTOSAR platform by virtualizing it into a Windows environment in order to simulate vehicle software in a Windows environment. Specifically, the AUTOSAR platform virtualization unit (350) can provide virtualization for lower layers such as RTE and BSW of the AUTOSAR platform. For example, the AUTOSAR platform virtualization unit (350) can provide vRTE, vOSEK OS, vService, vI / O, vMCAL, vPortpin, etc. as virtualized modules.

[0070] In one embodiment, the AUTOSAR platform virtualization unit (350) can use executable codes and virtualized AUTOSAR platform codes to perform operation logic of vehicle software during simulation and generate a simulation file that can be operated in a Windows environment. That is, the AUTOSAR platform virtualization unit (350) can integrate the executable codes and virtualized AUTOSAR platform codes and then build them to generate an AUTOSAR simulation file in the '.exe' format that runs in a Windows environment. Subsequently, the AUTOSAR simulation file can be executed in the Windows environment of a user terminal (110), and can also be executed on a simulation device (130) as needed. When the simulation file is executed, operation logic of vehicle software can be executed on the virtualized AUTOSAR platform according to the contents of the RTE API and static code, and output can be generated through the virtual port of the virtualized AUTOSAR platform according to the operation result.

[0071] The ECU virtualization processing unit (370) receives the output of the vehicle software based on the simulation and can visualize the operation of the virtualized ECU based on the output through a graphic interface. Here, the virtualized ECU can be created based on ECU design information extracted from the configuration file of the vehicle software, and the graphic interface can be implemented as a virtual ECU graphic simulator. For example, the ECU virtualization processing unit (370) can visualize the blinking operation of an LED on the virtualized ECU based on the output of the simulation or visualize the screen output of a display panel.

[0072] In one embodiment, the ECU virtualization processing unit (370) can receive an output value from a virtual port of a virtualized software platform and output an operation corresponding to the output value through the virtualized ECU. The ECU virtualization processing unit (370) can simulate the operation of the virtualized ECU according to the output value received from the virtual port of the virtualized software platform and then display a graphic based on the operation result through a visualized interface.

[0073] The control unit (390) controls the overall operation of the simulation device (130) and can manage the control flow or data flow between the code parsing unit (310), the code generation unit (330), the AUTOSAR platform virtualization unit (350), and the ECU virtualization processing unit (370).

[0075] Figure 4 is a diagram illustrating the overall concept of vehicle software simulation according to the present invention.

[0076] Referring to FIG. 4, the Windows-based vehicle software simulation method through AUTOSAR stack virtualization according to the present invention generates an AUTOSAR simulation file capable of simulation on a virtualized AUTOSAR platform and can visually provide simulation results through a virtualized ECU graphic simulator.

[0077] More specifically, the simulation method according to the present invention can parse essential information required for software execution through an arxml parser based on a configuration file, i.e., an arxml file, of vehicle software created through an AUTOSAR development tool. Additionally, the simulation method can generate RTE APIs and static codes required for AUTOSAR-based software execution through a code generator using the parsed information. Subsequently, the simulation method can generate an AUTOSAR simulation file executable in a Windows environment by building the Virtual AUTOSAR Platform Code provided by the Virtual AUTOSAR Platform and the executable code generated through the code generator. Finally, the simulation method can execute the executable file (.exe) generated in a Windows environment, receive the results of the simulation executed on the Virtual AUTOSAR Platform, and visualize and display them through a Virtual ECU Graphic Simulation.

[0078] Meanwhile, the simulation method according to the present invention can be executed through a simulation device (130), in which case the code parsing unit (310) of FIG. 3 is implemented as an arxml parser and the code generation unit (330) is implemented as a code generator, the AUTOSAR platform virtualization unit (350) is implemented as a virtualized AUTOSAR platform and the ECU virtualization processing unit (370) can be implemented as a virtual ECU graphic simulator.

[0080] FIG. 5 is a diagram illustrating an embodiment of a vehicle software simulation process according to the present invention.

[0081] Referring to FIG. 5, the user can design vehicle software using an AUTOSAR development tool, and an ARXML file can be generated accordingly. Once the ARXML design is completed, an RTE API can be generated, and code regarding the operation of the vehicle software can be generated using information extracted by parsing the ARXML file. The simulation device (130) can generate a virtual AUTOSAR simulation file executable in a Windows environment by integrating the RTE API, static code, and virtual AUTOSAR platform code.

[0082] As a result, the simulation device (130) can visualize the simulation results of the vehicle software through a graphic simulator, thereby enabling SILS-based verification through a simulator that virtualizes the target ECU without being dependent on test equipment or debugging equipment.

[0084] FIG. 6 is a drawing illustrating an embodiment of a vehicle software simulation system according to the present invention.

[0085] Referring to FIG. 6, the vehicle software simulation method according to the present invention can output results resulting from simulation operations on a virtualized AUTOSAR platform through a virtualized ECU graphic simulator. Specifically, the virtualized AUTOSAR platform can provide virtualization for performing simulation of vehicle software in a Windows environment. The virtualized AUTOSAR platform may include a virtualized RTE layer (vRTE) and a virtualized BSW layer (vBSW).

[0086] Here, the virtualized BSW layer may correspond to a layer that virtualizes functions commonly used in various ECUs, and may include a virtualized Service Layer, a virtualized ECU Abstraction Layer (EAL), and a virtualized Microcontroller Abstraction Layer (MCAL).

[0087] Meanwhile, the content illustrated in FIG. 6 is intended to supplement the understanding of a communication-related module as an embodiment according to the present invention, and it goes without saying that such content does not limit the scope of the rights of the present invention.

[0088] First, the virtualized service layer can virtualize services such as System, Memory, and Communication for system operation and overall control of other modules within the BSW. System services may primarily include functions for managing tasks and interrupts, memory services may include functions for reading and writing to memory, and communication services may include functions necessary for using communication protocols such as CAN and LIN.

[0089] In addition, the virtualized ECU abstraction layer can virtualize an abstraction layer that provides an interface to the upper layer of the virtualized MCAL drivers. The virtualized ECU abstraction layer may also provide an interface with external devices other than the microcontroller. For example, external devices may include EEPROM, Flash, and Watchdog drivers.

[0090] In addition, the virtualized microcontroller abstraction layer can virtualize internal drivers for utilizing the microcontroller's internal devices. Accordingly, the virtualized AUTOSAR platform can exchange data (vPortpin data) with the virtualized ECU graphic simulator through the virtualized driver modules of the virtualized microcontroller abstraction layer. Meanwhile, the virtualized driver modules may include vCAN drivers, vFlexRay drivers, vEthernet drivers, and vLIN drivers.

[0092] FIG. 7 is a diagram illustrating an embodiment of an OS virtualization process according to the present invention.

[0093] Referring to FIG. 7, the simulation device (130) can virtualize the OS functions of a virtualized AUTOSAR platform. Specifically, the simulation device (130) may be implemented by including independent modules that virtualize a scheduler (OsScheduler), an alarm (OsAlarm), a task (OsTask), and a resource (Resource).

[0094] The Scheduler (OsScheduler) module virtualizes the scheduler to update the status of tasks according to priority based on task information and can determine the execution order by examining the status of the tasks. The Alarm (OsAlarm) module virtualizes the alarm function to generate a creation request signal for mapped tasks according to the execution order at set intervals. In one embodiment, the Alarm module can generate a creation request signal by calling a callback function through a Timer function at set intervals.

[0095] The Task (OsTask) module can virtualize task threads corresponding to a task based on a creation request signal and handle execution according to the task's state. The Task module creates task threads in the form of a structure to manage the task's priority, periodicity, and function pointers.

[0096] The resource module can virtualize resources to manage resource usage according to task execution. In one embodiment, when a specific task uses a resource, the resource module can perform mutual exclusion of the acquisition of the resource through a mutex and allow the scheduler to change the priority of the task owning the resource.

[0097] More specifically, the scheduler module can manage the execution order of tasks by referencing a task info array that manages task information and a priority queue that manages task priorities. Specifically, the scheduler module can change the status of tasks to RUNNING, READY, WAITING, or SUSPENDED according to the priority of the tasks. The scheduler module can determine the next task to execute by checking the status and priority of all tasks in the READY and RUNNING states and checking the tasks in the Ready state existing in the priority queue (FIFO Queue). In one embodiment, the scheduler module can manage the execution and suspension of tasks using the WinAPI functions ResumeThread and SuspendThread.

[0098] Consequently, the task to be executed can be determined by the scheduler module, and the task information can be transmitted to the task thread (OsTask Thread) module through the scheduler module.

[0099] A task module (e.g., OsTask Thread of FIG. 7) can execute the operation of a corresponding task thread according to the execution control of a scheduler module. The task thread can perform periodic and non-periodic operations depending on the corresponding task type. A task thread that performs periodic operations can be created by a creation request signal from an alarm module and can be terminated after executing a mapped event once. In contrast, a task thread that performs non-periodic operations can execute a mapped event while activated by an activation request signal from an alarm module, and even after the event execution is completed, it does not terminate but changes its operation state to a suspended state to wait for the next activation signal.

[0100] The simulation method according to the present invention supports the virtualization of a vehicle software platform, thereby providing high convenience in the development and verification testing of vehicle software through the simulation of vehicle software in a Windows PC environment.

[0102] Although the present invention has been described above with reference to preferred embodiments, those skilled in the art will understand that various modifications and changes can be made to the invention without departing from the spirit and scope of the invention as described in the following claims. Explanation of the symbols

[0104] 100: Automotive Software Simulation System 110: User terminal 130: Simulation device 150: Database 210: Processor 230: Memory 250: User I / O Section 270: Network I / O Section 310: Code Parsing Unit 330: Code Generation Unit 350: AUTOSAR Platform Virtualization Unit 370: ECU Virtualization Processing Unit 390: Control unit

Claims

Claim 1 A code parsing unit that restrictively receives only ARXML (AUTOSAR eXtensible Markup Language) files of AUTOSAR-based software as configuration files of vehicle software written through a software development tool, and is configured to either receive the configuration file again or refuse file reception if a file of a format other than the ARXML file is input, and parses information for the execution of the vehicle software from the configuration file; a code generation unit that generates execution codes for the execution of the vehicle software operating on a virtualized software platform based on the parsed information, generates static code that implements detailed functions of the vehicle software using the execution codes, and generates a RunTime Environment (RTE) API for the static code; a code generation unit that implements the virtualization of the software platform, simulates the operation of the vehicle software according to the execution of the execution codes, generates Virtual AUTOSAR Platform Code that implements virtualization for each module of the software platform, and the execution codes and the Virtual AUTOSAR Platform Code An AUTOSAR platform virtualization unit that builds after integration to execute the operation logic of the vehicle software according to the contents of the RTE API and static code during the simulation and generates an AUTOSAR simulation file executable in the Windows environment of a user terminal; and an ECU virtualization processing unit that receives the output of the vehicle software according to the simulation and visualizes the operation of the virtualized ECU based on the output through a graphic interface.A Windows-based automotive software simulation device through AUTOSAR stack virtualization, comprising: a virtualization layer for performing simulation of the automotive software in the Windows environment, wherein the virtualization layer comprises a virtualized Service Layer, a virtualized ECU Abstraction Layer (EAL), and a virtualized Microcontroller Abstraction Layer (MCAL). Claim 2 delete Claim 3 delete Claim 4 delete Claim 5 delete Claim 6 A Windows-based vehicle software simulation device using AUTOSAR stack virtualization, wherein, in claim 1, the ECU virtualization processing unit receives an output value from a virtual port of the virtualized software platform and outputs an operation corresponding to the output value through the virtualized ECU. Claim 7 A method for simulating vehicle software performed on a Windows-based vehicle software simulation device, comprising: a step of parsing information for the execution of the vehicle software from the configuration file of the vehicle software created through a software development tool, wherein a code parsing unit restrictively receives only an ARXML (AUTOSAR eXtensible Markup Language) file of AUTOSAR-based software as a configuration file of the vehicle software, and if a file of a format other than the ARXML file is input, the configuration file is re-inputted or file reception is rejected; a step of a code generation unit, wherein executable codes for the execution of the vehicle software operating on a virtualized software platform based on the parsed information are generated, static code implementing detailed functions of the vehicle software is generated using the executable codes, and a RunTime Environment (RTE) API for the static code is generated; and an AUTOSAR platform virtualization unit, wherein the virtualization of the software platform is implemented, the operation of the vehicle software is simulated according to the execution of the executable codes, and virtualization of each module of the software platform A step of generating a Virtual AUTOSAR Platform Code to be implemented, integrating the executable codes and the Virtual AUTOSAR Platform Code, and then building to perform the operation logic of the vehicle software according to the contents of the RTE API and static code during the simulation and generating an AUTOSAR simulation file executable in a Windows environment of a user terminal; and a step in which, in an ECU virtualization processing unit, the output of the vehicle software according to the simulation is received and the operation of the virtualized ECU based on the output is visualized through a graphic interface.A Windows-based automotive software simulation method through AUTOSAR stack virtualization, comprising: a step of generating an AUTOSAR simulation file, wherein the step of generating the AUTOSAR simulation file provides virtualization for performing simulation of the automotive software in the Windows environment and includes a virtualized BSW layer (vBSW) comprising a virtualized Service Layer, a virtualized ECU Abstraction Layer (EAL), and a virtualized Microcontroller Abstraction Layer (MCAL). Claim 8 delete Claim 9 delete Claim 10 delete Claim 11 delete Claim 12 A Windows-based vehicle software simulation method through AUTOSAR stack virtualization, characterized in that, in claim 7, the visualization step includes receiving an output value from a virtual port of the virtualized software platform and outputting an operation corresponding to the output value through the virtualized ECU.

Images