Code parsing apparatus and method for simulation of automotive software platform

Abstract

The present invention relates to a code parsing device and method for simulating a vehicle software platform, wherein the device comprises: a configuration file receiving unit that receives a configuration file of vehicle software created through a software development tool; a configuration file classification unit that classifies the type of the configuration file; and a code parsing unit that parses the configuration file according to the type of the configuration file and extracts information for the execution of the vehicle software on a virtualized software platform.

Description

Technology Field

[0001] The present invention relates to software simulation technology, and more specifically, to a technology for parsing essential information from a configuration file to enable 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 code parsing device and method for simulating a vehicle software platform that can extract information essential for the operation of vehicle software from a configuration file of vehicle software for ECU simulation based on an AUTOSAR platform. means of solving the problem

[0013] Among the embodiments, a code parsing device for simulating a vehicle software platform comprises: a configuration file receiving unit that receives a configuration file of vehicle software created through a software development tool; a configuration file classification unit that classifies the type of the configuration file; and a code parsing unit that parses the configuration file according to the type of the configuration file and extracts information for the execution of the vehicle software on a virtualized software platform.

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

[0015] The above configuration file classification unit can classify the ARXML file into any one of an ASW design ARXML file containing settings for the ASW (Application SoftWare layer) of the software platform, a BSW design ARXML file containing settings for the BSW (Basic SoftWare layer), and an RTE design ARXML file containing settings for the RTE (RunTime Environment).

[0016] The code parsing unit can extract first parsing information including Composition Software Component (CSWC), Software Component (SWC), Runnable, Event, Port, Interface, and DataType from the ASW design ARXML file, extract second parsing information including Alarm, Task, App Mode, Application (OsApplication), Counter (OsCounter), Interrupt Service Routine (ISR), and Resource from the BSW design ARXML file, and extract third parsing information including Event-Task Mapping and Software Component Instance (SWC Instance) from the RTE design ARXML file.

[0017] If the code parsing unit fails to extract at least one of the first to third parsing information, it may request re-input of the configuration file through the configuration file receiving unit.

[0018] The code parsing device may further include 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.

[0019] 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.

[0020] The code parsing device may further include: 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 executable 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 based on the output through a graphic interface.

[0021] 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.

[0022] Among the embodiments, a code parsing method for simulating a vehicle software platform comprises: receiving a configuration file of vehicle software created through a software development tool via a configuration file receiving unit; classifying the type of the configuration file via a configuration file classification unit; and parsing the configuration file according to the type of the configuration file via a code parsing unit to extract information for executing the vehicle software on a virtualized software platform.

[0023] The above code parsing method may further include the step of generating execution codes for the execution of the vehicle software operating on a virtualized software platform based on the parsed information through a code generation unit.

[0024] The above code parsing method may further include: a step of implementing virtualization of the software platform through an AUTOSAR platform virtualization unit and simulating the operation of the vehicle software according to the execution of the executable codes; and a step of receiving the output of the vehicle software according to the simulation through an ECU virtualization processing unit and visualizing the operation of the virtualized ECU based on the output through a graphic interface. 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 code parsing device and method for simulating a vehicle software platform according to one embodiment of the present invention can be expected to be highly useful for the development and verification testing of vehicle software by extracting essential information from a configuration file of vehicle software and conducting a simulation in a PC environment, and can enable 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 stage.

[0028] A code parsing device and method for simulating a vehicle software platform according to one embodiment of the present invention can predict errors that may occur in hardware, such as ECUs, through software-based simulation, thereby reducing errors by correcting errors that occur before verification in the EILS and HILS stages. Through this, the time or cost required for building hardware test equipment can be reduced, resulting in the benefits of reduced unit costs for vehicle software development and shortened development cycles. Additionally, the ease of debugging and correction in the event of errors can be improved. Brief explanation of the drawing

[0030] 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 code parsing device of Figure 1. Figure 3 is a diagram illustrating the functional configuration of the code parsing 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 a code parsing process according to the present invention. FIG. 8 is a diagram illustrating an embodiment of an OS virtualization process according to the present invention. Specific details for implementing the invention

[0031] 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.

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

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

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

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

[0042] 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.

[0043] 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 according to the purpose of simulating the operation of vehicle software developed through a software development tool in a Windows environment.

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

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

[0046] The code parsing device (130) may be implemented as a server corresponding to a computer or program that performs a code parsing method for simulating a vehicle software platform according to the present invention. In particular, the code parsing device (130) may be implemented by being included in a device capable of Windows-based vehicle software simulation, and accordingly, during the Windows-based vehicle software simulation process, it may independently process a code parsing operation to extract information for the execution of vehicle software on a virtualized software platform from a configuration file of vehicle software.

[0047] Additionally, the code parsing device (130) can be connected to the user terminal (110) via a wired network or a wireless network such as Bluetooth, WiFi, LTE, etc., and can transmit and receive data with the user terminal (110) through the network.

[0048] Additionally, the code parsing device (130) may be implemented to operate in connection with an independent external system (not shown in FIG. 1). In one embodiment, the code parsing device (130) may be implemented by being included in a cloud server that performs simulation of vehicle software.

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

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

[0052] Figure 2 is a diagram illustrating the system configuration of the port virtualization device of Figure 1.

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

[0054] The processor (210) can execute a code parsing procedure during the simulation process of a vehicle software platform 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 code parsing device (130) and can control the data flow between the memory (230), user input / output unit (250), and network input / output unit (270) by being electrically connected to them. The processor (210) can be implemented as a CPU (Central Processing Unit) or GPU (Graphics Processing Unit) of the code parsing device (130).

[0055] 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 code parsing device (130), and may include a main memory device implemented as volatile memory such as RAM (Random Access Memory). Additionally, the memory (230) may store a set of instructions that execute a code parsing method during the simulation process of the vehicle software platform according to the present invention by being executed by an electrically connected processor (210).

[0056] 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 code parsing device (130) may be performed as an independent server.

[0057] 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.

[0059] Figure 3 is a diagram illustrating the functional configuration of the code parsing device of Figure 1.

[0060] Referring to FIG. 3, the code parsing device (130) may be implemented to include a configuration file receiving unit (310), a configuration file classification unit (320), a code parsing unit (330), and a control unit (not shown in FIG. 3). In one embodiment, the code parsing device (130) may be implemented to further include a code generation unit (340), an AUTOSAR platform virtualization unit (350), and an ECU virtualization processing unit (360).

[0061] At this time, the code parsing 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 code parsing device (130) may be implemented as an independent module that selectively includes some of the above configurations, and may perform a code parsing method for simulating a vehicle software platform according to the present invention through interoperability between each module. The operation of each configuration will be described in detail below.

[0062] The configuration file receiving unit (310) can receive a configuration file of vehicle software created through a software development tool. 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.

[0063] 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. A configuration file for vehicle software can be generated on a device where the software development tool is executed. If a configuration file for vehicle software is generated on a user terminal (110), a configuration file receiving unit (310) can receive the configuration file for vehicle software from the user terminal (110).

[0064] In one embodiment, the configuration file receiving unit (310) can receive an ARXML (AUTOSAR eXtensible Markup Language) file of AUTOSAR-based software as a configuration file for vehicle software. The configuration file receiving unit (310) can provide an independent user interface (UI) for receiving the ARXML file and can also receive input through a user terminal (110). The vehicle software can be created based on an AUTOSAR platform corresponding to an open automotive standard software architecture, and the AUTOSAR platform can manage software configuration files in the form of ARXML files.

[0065] For example, when software components for vehicle software are created using an AUTOSAR-based software development tool, the components can be stored in an ARXML file, which is a standardized digital exchange format based on the AUTOSAR specification set by the user. At this time, the created ARXML file may include contents such as tasks, alarms, events, interrupts, priorities, periods, ports, and data elements. Additionally, ARXML files can be classified into ASW (Application Software layer) design ARXML files, BSW (Basic Software layer) design ARXML files, and RTE (RunTime Environment) design ARXML files.

[0066] In one embodiment, the configuration file receiving unit (310) may restrictively receive only a file of a specific format as a configuration file for vehicle software. For example, the configuration file receiving 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.

[0067] The configuration file classification unit (320) can classify the type of the configuration file. The configuration file classification unit (320) can analyze the type of the ARXML file before performing code parsing based on the ARXML file. Once the type of the ARXML file is determined by the configuration file classification unit (320), the code parsing unit (330) can perform independent code parsing operations according to the file type. For example, the information extracted through code parsing may differ depending on the file type of the ARXML.

[0068] In one embodiment, the configuration file classification unit (320) may be implemented by being included in the configuration file receiving unit (310). That is, the configuration file classification unit (320) may be implemented as an independent module included in the configuration file receiving unit (310) that performs the operation of classifying the type of the received configuration file.

[0069] In one embodiment, the configuration file classification unit (320) may classify the ARXML file into any one of an ASW design ARXML file containing settings for the ASW (Application SoftWare layer) of a software platform, a BSW design ARXML file containing settings for the BSW (Basic SoftWare layer), and an RTE design ARXML file containing settings for the RTE (RunTime Environment).

[0070] First, the ASW design ARXML file may correspond to an ARXML file containing configuration details regarding the ASW of the AUTOSAR platform. The ASW layer of the AUTOSAR platform can be composed of runnables, which are the smallest scheduling targets with unit functions, and software components (SWCs), which are modules capable of independent operation formed by combinations of runnables.

[0071] In addition, the BSW design ARXML file may correspond to an ARXML file containing configuration details regarding the BSW of the AUTOSAR platform. The BSW layer of the AUTOSAR platform may be composed of Hardware Abstraction Layer (HAL) modules, services, and schedulers that abstract hardware-dependent input / output functions, such as ADC (Analog to Digital Converter), digital input / output, and CAN (Controller Area Network), and provide interfaces to upper layers.

[0072] Additionally, the RTE design ARXML file may correspond to an ARXML file containing configuration details regarding the RTE of the AUTOSAR platform. The RTE layer of the AUTOSAR platform may correspond to the layer responsible for the integration of ASW and BSW.

[0073] The code parsing unit (330) can parse the configuration file according to the type of configuration file to extract information for the execution of vehicle software on a virtualized software platform. That is, the code parsing unit (330) can selectively extract only the information necessary for the operation of vehicle software from the configuration values ​​for ASW, RTE, and BSW, and use it in the process of reconstructing RTE API, Static Code, etc. into a form for simulation.

[0074] In one embodiment, the code parsing unit (330) can perform a code parsing operation by applying a parsing rule that predefines target information to be extracted according to the ARXML file type. To this end, the code parsing unit (330) can process the code parsing by referring to the results classified by the configuration file classification unit (320).

[0075] In one embodiment, the code parsing unit (330) can extract first parsing information including a Composition Software Component (CSWC), a Software Component (SWC), a Runnable, an Event, a Port, an Interface, and a DataType from an ASW design ARXML file, extract second parsing information including an Alarm, a Task, an App Mode, an Application (OsApplication), an OsCounter, an Interrupt Service Routine (ISR), and a Resource from a BSW design ARXML file, and extract third parsing information including an Event-Task Mapping and a Software Component Instance (SWC Instance) from an RTE design ARXML file.

[0076] In one embodiment, if the code parsing unit (330) fails to extract at least one of the first to third parsing information, it may request re-entry of the configuration file through the configuration file receiving unit (310). That is, if some of the information required for the execution of the vehicle software is not extracted, the code parsing unit (330) may update the configuration file of the vehicle software and repeat the parsing operation. To this end, the code parsing unit (330) may operate in conjunction with the configuration file receiving unit (310), and the configuration file receiving unit (310) may provide a user interface for re-entry of the configuration file in response to the request of the code parsing unit (330).

[0077] The code generation unit (340) can generate executable codes for the execution of vehicle software running on a virtualized software platform based on parsed information. 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 (340) can perform the operation of generating executable codes necessary for the vehicle software to run on a virtualized software platform and for simulation to be performed in a Windows environment.

[0078] In one embodiment, the code generation unit (340) can generate RTE (RunTime Environment) APIs and static code necessary 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 (340) 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. At this time, the RTE API and static code may be generated as a c file (.c), but are not necessarily limited thereto.

[0079] The AUTOSAR platform virtualization unit (350) can implement virtualization of the software platform and simulate the operation of vehicle software according to the execution of executable codes on the virtualized software platform. 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 executable code including 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 generate outputs according to the operation results. At this time, the RTE APIs and static codes may correspond to executable codes generated for the simulation of vehicle software.

[0080] In one embodiment, the AUTOSAR platform virtualization unit (350) can operate in conjunction with independent modules that perform the operation of generating executable code. That is, the independent modules receive 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, and can generate executable code for the execution of vehicle software that runs on a virtualized software platform based on the parsed information. As a result, the AUTOSAR platform virtualization unit (350) can enable simulation of the operation of vehicle software even in a Windows environment through the virtualization of the software platform.

[0081] 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 (.c). 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 the RTE (Run-Time Environment) and BSW (Basic Software Layer) 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.

[0082] 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 code parsing 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 of the virtualized AUTOSAR platform can be generated according to the operation result.

[0083] In one embodiment, the AUTOSAR platform virtualization unit (350) can simulate the operation of a software component implementing vehicle software and determine the value of a virtual port variable that virtualizes the output of vehicle software in conjunction with the operation of the software component. Vehicle software may be designed to include at least one software component (SWC, Software Component) according to the functional component (Application SWC) to be implemented. That is, vehicle software may be defined through a set of interconnected software components.

[0084] Accordingly, the AUTOSAR platform virtualization unit (350) can simulate the operation of software components on the virtualized software platform and determine the value of a virtual port variable connected to a software component based on the operation result. At this time, the virtual port corresponding to the output of the virtualized vehicle software platform may correspond to the output port of the last software component according to the operation sequence of the vehicle software, and the value of the virtual port variable may be changed to the output value output from the corresponding output port.

[0085] The ECU virtualization processing unit (360) 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 (360) can apply various graphic elements, such as visualizing the blinking operation of an LED or visualizing the screen output of a display panel on the virtualized ECU based on the output of the simulation.

[0086] In one embodiment, the ECU virtualization processing unit (360) 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 (360) 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.

[0087] A control unit (not shown in FIG. 3) controls the overall operation of the code parsing device (130) and can manage the control flow or data flow between the configuration file receiving unit (310), the configuration file classification unit (320), the code parsing unit (330), the code generation unit (340), the AUTOSAR platform virtualization unit (350), and the ECU virtualization processing unit (360).

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

[0090] Referring to Fig. 4, a Windows-based vehicle software simulation method generates an AUTOSAR simulation file that can be simulated on a virtualized AUTOSAR platform and can visually provide simulation results through a virtualized ECU graphic simulator.

[0091] More specifically, the vehicle software simulation method can parse essential information required for software execution through an arxml parser based on a configuration file of vehicle software, namely an arxml file, created through an AUTOSAR development tool. At this time, the arxml parser can be implemented through a code parsing device (130) according to the present invention. That is, the configuration file of the vehicle software can be transmitted to the code parsing device (130), and the code parsing device (130) can extract and provide essential information required for software execution from the configuration file.

[0092] For example, the configuration file of automotive software may include settings for software components (data types, connection status with interfaces, etc.), settings for ECUs (hardware and resource configurations, etc.), and settings for the system (bus signals, topology, mapping between SWCs and ECUs, network settings, etc.). In addition, the settings for software components may include task operations and trigger conditions for the implementation of the automotive software.

[0093] In addition, the vehicle software simulation method can generate RTE APIs and static code required for AUTOSAR-based software execution through a code generator using parsed information.

[0094] Subsequently, the vehicle software simulation method can generate an AUTOSAR simulation file executable in a Windows environment by integrating and building the Virtual AUTOSAR Platform Code provided by the virtualized AUTOSAR Platform and the executable code generated through a code generator.

[0095] Finally, the vehicle software simulation method can execute an executable file (.exe) generated in a Windows environment, receive the results of a simulation running on a virtual AUTOSAR platform, and visualize and display them through a virtualized ECU graphic simulator (Virtual ECU Graphic Simulation).

[0096] Meanwhile, the code parsing method according to the present invention can be executed through a code parsing device (130), in which case an arxml parser may correspond to the code parsing device (130). In addition, a code generator may correspond to the code generation unit (340) of FIG. 3, a virtualized AUTOSAR platform may correspond to the AUTOSAR platform virtualization unit (350), and an ECU virtualization processing unit (360) may correspond to a virtual ECU graphic simulator.

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

[0099] Referring to FIG. 5, the code parsing device (130) can be implemented by being included in a simulation device that performs a Windows-based vehicle software simulation, and accordingly, can perform the operation of extracting information necessary for the simulation from a configuration file of the vehicle software during the Windows-based vehicle software simulation process.

[0100] Specifically, the user can design vehicle software using an AUTOSAR development tool, and an ARXML file can be generated accordingly. Once the ARXML design is complete, 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. In the simulation device, a virtual AUTOSAR simulation file executable in a Windows environment can be generated as a result of integrating the RTE API, static code, and virtualized AUTOSAR platform code.

[0101] In addition, the simulation device 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. In particular, the code parsing device (130) can parse and extract essential information required for the operation of the software from the configuration file of the vehicle software during the simulation process of the vehicle software.

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

[0104] Referring to FIG. 6, the code parsing method according to the present invention can parse and extract essential information required for the execution of vehicle software on a virtualized AUTOSAR platform from the configuration file of the vehicle software. 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).

[0105] 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).

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0111] FIG. 7 is a diagram illustrating an embodiment of a code parsing process according to the present invention.

[0112] Referring to FIG. 7, the code parsing device (130) can generate RTE API and source code information by parsing information essential for the operation of AUTOSAR-based software from an ARXML file so that software designed based on the AUTOSAR-based vehicle software platform can be simulated in a virtual environment without being used on a target board.

[0113] In particular, the code parsing device (130) can extract different parsing information depending on the type of ARXML file. To this end, the code parsing device (130) can determine the target information to be parsed by applying a parsing rule defined according to the type of ARXML file.

[0114] For example, information such as CSWC, SWC, Runnable, Event, Port, Interface, and Data Type can be extracted from an ASW design ARXML file, information such as Alarm, Task, AppMode, OsApplication, OsCounter, ISR, and Resource can be extracted from a BSW design ARXML file, and information such as Task-Event Mapping and SWC Instance can be extracted from an RTE design ARXML file.

[0115] Additionally, the code parsing device (130) can generate RTE API codes for software simulation on a virtualized platform using information parsed through the code generation unit (340). The code parsing device (130) can generate static code as well as RTE APIs for implementing software execution, and can then build them together with virtual AUTOSAR platform code that supports execution on a virtualized platform to generate an AUTOSAR simulation file.

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

[0118] Referring to FIG. 8, the vehicle software simulation system (100) can virtualize the OS functions of a virtualized AUTOSAR platform. Specifically, the vehicle software simulation system (100) can be implemented by including independent modules that virtualize a scheduler (OsScheduler), an alarm (OsAlarm), a task (OsTask), and a resource (Resource).

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] A task module (e.g., OsTask Thread of FIG. 8) 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.

[0125] The vehicle software simulation system (100) supports the virtualization of the 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.

[0127] 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

[0129] 100: Automotive Software Simulation System 110: User terminal 130: Code parsing device 150: Database 210: Processor 230: Memory 250: User I / O Section 270: Network I / O Section 310: Configuration file receiving unit 320: Configuration file classification unit 330: Code Parsing Unit 340: Code Generation Unit 350: AUTOSAR Platform Virtualization Unit 360: ECU Virtualization Processing Unit

Claims

Claim 1 In a code parsing device for simulating a vehicle software platform implemented on a cloud server, which independently processes a code parsing operation to extract information for the execution of said vehicle software from a configuration file of said vehicle software on a virtualized software platform during a vehicle software simulation process, the device comprises: a configuration file receiving unit that may be restricted to receiving only an ARXML file as a configuration file of said vehicle software created through a software development tool, and which receives said configuration file or refuses to receive said other file if a file other than said ARXML file is input; a configuration file classification unit that classifies the type of said configuration file into one of an ASW design ARXML file containing settings for the ASW (Application Software layer) of said virtualized software platform, a BSW design ARXML file containing settings for the BSW (Basic Software layer), and an RTE design ARXML file containing settings for the RTE (RunTime Environment), wherein said ASW design ARXML file is composed of a combination of runnables, which are the smallest scheduling targets having unit functions, and is capable of independent operation; and target information to be extracted according to the type of said configuration file A code parsing unit that applies predefined parsing rules and parses the configuration file to selectively extract only the information necessary for the operation of the vehicle software from among the configuration values ​​for the ASW, RTE, and BSW for the execution of the vehicle software on the virtualized software platform; and an ECU virtualization processing unit that receives an output value from a virtual port of the virtualized software platform according to the simulation process and visualizes the operation corresponding to the output value as the operation of the virtualized ECU through a graphic interface.A code generation unit that generates executable codes for the execution of the vehicle software operating on the virtualized software platform based on parsed information; and an AUTOSAR platform virtualization unit that implements the virtualization of the vehicle software platform and simulates the operation of the vehicle software according to the execution of the executable codes; wherein the code parsing unit extracts essential information from a configuration file, which includes at least one of the configuration content of a software component, the configuration content of an ECU, and the configuration content of a system as information required for the operation of the vehicle software, and the configuration content of the system includes at least one of a bus signal, topology, mapping between the software component and the ECU, and network settings; wherein the code parsing unit is configured to generate an AUTOSAR simulation file for conducting a software-based simulation performed in a PC environment using the extracted essential information, wherein RTE API code, static code, and virtual AUTOSAR platform code are built to enable simulation on a virtualized AUTOSAR platform and are generated in the format of an executable file that runs in a Windows environment, and the ECU virtualization processing unit the AUTOSAR A code parsing device for simulating a vehicle software platform configured to predict errors that may occur in the ECU using output values ​​generated according to the execution of a simulation file. Claim 2 A code parsing device for simulating a vehicle software platform, wherein, in claim 1, the configuration file receiving unit receives an ARXML (AUTOSAR eXtensible Markup Language) file of AUTOSAR-based software as a configuration file of the vehicle software. Claim 3 delete Claim 4 A code parsing device for simulating a vehicle software platform according to claim 1, wherein the code parsing unit extracts first parsing information including a Composition Software Component (CSWC), a Software Component (SWC), a Runnable, an Event, a Port, an Interface, and a DataType from the ASW design ARXML file, extracts second parsing information including an Alarm, a Task, an App Mode, an Application (OsApplication), an Counter (OsCounter), an Interrupt Service Routine (ISR), and a Resource from the BSW design ARXML file, and extracts third parsing information including an Event-Task Mapping and a Software Component Instance (SWC Instance) from the RTE design ARXML file. Claim 5 A code parsing device for simulating a vehicle software platform, wherein, in claim 4, the code parsing unit requests re-input of the configuration file through the configuration file receiving unit when the extraction of at least one of the first to third parsing information fails. Claim 6 delete Claim 7 In claim 1, the code generation unit, based on the parsed information, is necessary for the execution of the vehicle software The above RunTime Environment (RTE) API and The above A code parsing device for simulating a vehicle software platform characterized by generating static code. Claim 8 delete Claim 9 delete Claim 10 delete Claim 11 delete Claim 12 delete

Images