KR20240009783A - Code parsing apparatus and method for simulation of automotive software platform - Google Patents

Abstract

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

Description

Code parsing device and method for simulation of vehicle software platform {CODE PARSING APPARATUS AND METHOD FOR SIMULATION OF AUTOMOTIVE SOFTWARE PLATFORM}

The present invention relates to software simulation technology, and more specifically, to simulate applications based on automotive software platforms to enable SILS (Software-In-the-Loop Simulation) verification without hardware equipment such as a target board, which is required in the configuration file. It's about techniques for parsing information.

Due to the development of in-vehicle infotainment and the electronicization of vehicles, the number of ECUs inside the vehicle is increasing and the structure is becoming more complex, and the source code that operates in the ECU is also becoming longer. Due to this complexity, automakers have established vehicle software standards and applied standards and development methodologies for functional safety.

Typically, a development methodology using the V-model can be used in the development and testing of vehicle software. The V-model consists of design, implementation, and verification stages, and the design stage can be divided into requirements specification, system design, and model design. After the design is completed, the system is developed and implemented and goes through a verification stage. At this time, verification may begin with a small scope of module testing and gradually expand to integration testing and system testing.

Additionally, when developing using a V-model, a simulation that virtually predicts the operation of the system can be conducted to verify the results from each step. There are simulation verification stages such as MILS, SILS, EILS, and HILS to satisfy functional safety, and development costs and periods can be reduced by verifying errors through simulation at each stage.

MILS (Model-In-the-Loop Simulation) is the step of first conducting system modeling based on the requirements specification and mathematically verifying the model. Afterwards, the designed system model is implemented in software and the implemented source code operation is verified. The SILS (Software-In-the-Loop Simulation) stage may proceed. After going through the SILS step, error verification can be performed through EILS (ECU-In-the-Loop Simulation), which is a step to check whether the implemented software program operates correctly using the ECU.

Once the EILS stage is completed, the HILS (Hardware-In-the-Loop Simulation) process can be performed, which simulates operations implemented at the hardware level by actually combining hardware before the entire system is completed. At this time, separate debugging equipment is required in the EILS or HILS stage, which requires the actual ECU or hardware device, and when an error is detected, many factors such as related hardware, target ECU, and software problems such as source code must be considered, so error correction is required. The cost incurred as a result can be very large.

To reduce these costs, simulation may be needed on a virtual ECU that virtualizes the target ECU, rather than the actual target ECU. Additionally, as the application of the automotive software platform AUTOSAR expands, a virtual simulator linking the AUTOSAR platform and ECU may be needed.

Korean Patent No. 10-1134735 (2012.04.02)

An embodiment of the present invention seeks to provide a code parsing device and method for simulation of a vehicle software platform that can extract information essential for driving vehicle software from a configuration file of vehicle software for ECU simulation based on the Autosa platform.

Among embodiments, a code parsing device for simulating a vehicle software platform includes a configuration file receiver that receives a configuration file of vehicle software created through a software development tool; a configuration file classification unit that classifies the types of configuration files; and a code parsing unit that parses the configuration file according to the type of the configuration file and extracts information for executing the vehicle software on a virtualized software platform.

The configuration file receiving unit may receive an ARXML (AUTOSAR eXtensible Markup Language) file of AUTOSAR-based software as a configuration file of the vehicle software.

The configuration file classification unit divides the ARXML file into an ASW design ARXML file including settings for the ASW (Application SoftWare layer) of the software platform, a BSW design ARXML file including settings for the BSW (Basic SoftWare layer), and an RTE (RunTime It can be classified as one of the RTE design ARXML files that contain settings for the environment.

The code parsing unit extracts composition software component (CSWC, Composition SoftWare Component), software component (SWC, SoftWare Component), runnable, event, port, and interface from the ASW design ARXML file. And extract first parsing information including DataType, and extract Alarm, Task, App Mode, Application (OsApplication), Counter (OsCounter) from the BSW design ARXML file, Extracts second parsing information including an interrupt service routine (ISR) and resources, and includes event-task mapping and a software component instance (SWC Instance) from the RTE design ARXML file. Third parsing information can be extracted.

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.

The code parsing device may further include a code generation unit that generates executable codes for executing the vehicle software operating on a virtualized software platform based on the parsed information.

The code generator may generate a RunTime Environment (RTE) API and static code necessary for executing the vehicle software based on the parsed information.

The code parsing device includes an Autosa platform virtualization unit that implements virtualization of the software platform and simulates the operation of the vehicle software according to 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 through a graphic interface based on the output.

The ECU virtualization processing unit may 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.

Among embodiments, a code parsing method for simulation of a vehicle software platform includes receiving a configuration file of vehicle software created through a software development tool through a configuration file receiving unit; Classifying the type of configuration file through a configuration file classification unit; and extracting information for executing the vehicle software on a virtualized software platform by parsing the configuration file according to the type of the configuration file through a code parser.

The code parsing method may further include generating executable codes for executing the vehicle software operating on a virtualized software platform based on the parsed information through a code generator.

The code parsing method includes implementing virtualization of the software platform through an Autosa platform virtualization unit and simulating the operation of the vehicle software according to execution of the executable codes; and 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.

The disclosed technology can have the following effects. However, since it does not mean that a specific embodiment must include all of the following effects or only the following effects, the scope of rights of the disclosed technology should not be understood as being limited thereby.

The code parsing device and method for simulating a vehicle software platform according to an embodiment of the present invention has great utility in the development and verification testing of vehicle software by extracting essential information from the configuration file of vehicle software and conducting simulation in a PC environment. This can be expected, and SILS-based verification may be possible through a simulator that virtualizes the target ECU without being dependent on test equipment or debugging equipment, such as the EILS or HILS verification stage.

The code parsing device and method for simulating a vehicle software platform according to an embodiment of the present invention can predict errors that may occur in hardware such as ECU through software-based simulation, thereby correcting errors that occur before verification of the EILS and HILS stages. By doing this, errors can be reduced. Through this, the time and cost required to build hardware test equipment can be reduced, resulting in the benefit of reducing vehicle software development costs and shortening the development cycle. Additionally, the ease of debugging and correction when errors occur can be improved.

1 is a diagram explaining a vehicle software simulation system according to the present invention.
FIG. 2 is a diagram explaining the system configuration of the code parsing device of FIG. 1.
FIG. 3 is a diagram explaining the functional configuration of the code parsing device of FIG. 1.
Figure 4 is a diagram explaining the overall concept of vehicle software simulation in the present invention.
Figure 5 is a diagram illustrating an embodiment of a vehicle software simulation process according to the present invention.
Figure 6 is a diagram explaining an embodiment of a vehicle software simulation system according to the present invention.
Figure 7 is a diagram illustrating an embodiment of the code parsing process according to the present invention.
Figure 8 is a diagram explaining an embodiment of the OS virtualization process according to the present invention.

Since the description of the present invention is only an example for structural or functional explanation, the scope of the present invention should not be construed as limited by the examples described in the text. In other words, since the embodiments can be modified in various ways and can have various forms, the scope of rights of the present invention should be understood to include equivalents that can realize the technical idea. In addition, the purpose or effect presented in the present invention does not mean that a specific embodiment must include all or only such effects, so the scope of the present invention should not be understood as limited thereby.

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

Terms such as “first” and “second” are used to distinguish one component from another component, and the scope of rights should not be limited by these terms. For example, a first component may be named a second component, and similarly, the second component may also be named a first component.

When a component is referred to as being “connected” to another component, it should be understood that it may be directly connected to the other component, but that other components may exist in between. On the other hand, when a component is referred to as being “directly connected” to another component, it should be understood that there are no other components in between. Meanwhile, other expressions that describe the relationship between components, such as "between" and "immediately between" or "neighboring" and "directly neighboring" should be interpreted similarly.

Singular expressions should be understood to include plural expressions unless the context clearly indicates otherwise, and terms such as “comprise” or “have” refer to implemented features, numbers, steps, operations, components, parts, or them. It is intended to specify the existence of a combination, and should be understood as not excluding in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

For each step, identification codes (e.g., a, b, c, etc.) are used for convenience of explanation. The identification codes do not explain the order of each step, and each step clearly follows a specific order in context. Unless specified, events may occur differently from the specified order. That is, each step may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the opposite order.

The present invention can be implemented as computer-readable code on a computer-readable recording medium, and the computer-readable recording medium includes all types of recording devices that store data that can be read by a computer system. . Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, and optical data storage devices. Additionally, the computer-readable recording medium can be distributed across computer systems connected to a network, so that computer-readable code can be stored and executed in a distributed manner.

All terms used herein, unless otherwise defined, have the same meaning as commonly understood by a person of ordinary skill in the field to which the present invention pertains. Terms defined in commonly used dictionaries should be interpreted as consistent with the meaning they have in the context of the related technology, and cannot be interpreted as having an ideal or excessively formal meaning unless clearly defined in the present application.

1 is a diagram explaining a vehicle software simulation system according to the present invention.

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

The 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, in Figure 1, it is represented as one user terminal 110, but the first user is the first user terminal, the second user is the second user terminal, ..., the nth (where n is a natural number) user is the first user terminal. n may each correspond to a user terminal.

In addition, the user terminal 110 may be implemented as a device constituting the vehicle software simulation system 100 according to the present invention, and the vehicle software simulation system 100 may operate the vehicle software developed through a software development tool. It can be modified and operated in various forms depending on the purpose of simulating in a Windows environment.

In addition, the user terminal 110 may be implemented as a smartphone, laptop, or computer that can be operated by being connected to the code parsing device 130, but is not necessarily limited thereto, and may also be implemented as a variety of devices, including a tablet PC. .

Meanwhile, the user terminal 110 may be connected to the code parsing device 130 through a network, and a plurality of user terminals 110 may be connected to the code parsing device 130 at the same time.

The code parsing device 130 may be implemented as a server corresponding to a computer or program that performs a code parsing method for simulation of a vehicle software platform according to the present invention. In particular, the code parsing device 130 may be included and implemented in a device capable of Windows-based vehicle software simulation. Accordingly, in the Windows-based vehicle software simulation process, the vehicle software may be configured on a virtualized software platform from the configuration file of the vehicle software. The code parsing operation that extracts information for execution can be processed independently.

Additionally, the code parsing device 130 may be connected to the user terminal 110 through a wired network or a wireless network such as Bluetooth, WiFi, or LTE, and may transmit and receive data with the user terminal 110 through the network.

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 and included in a cloud server that performs simulation of vehicle software.

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 about a vehicle software platform or information about a virtualization simulation, but is not necessarily limited thereto, and the code parsing device 130 may store information about a vehicle software platform according to the present invention. In the process of performing the code parsing method for simulation, information collected or processed can be stored in various forms.

In addition, in FIG. 1, the database 150 is shown as a device independent of the code parsing device 130, but is not necessarily limited thereto, and may be implemented as a logical storage device included in the code parsing device 130. Of course.

FIG. 2 is a diagram explaining the system configuration of the port virtualization device of FIG. 1.

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

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

The memory 230 may be implemented as a non-volatile memory such as a solid state disk (SSD) or a hard disk drive (HDD) and may include an auxiliary memory used to store all data required for the code parsing device 130, It may include a main memory implemented as volatile memory such as RAM (Random Access Memory). In addition, the memory 230 is executed by the electrically connected processor 210 and can store a set of instructions for executing the code parsing method during the simulation of the vehicle software platform according to the present invention.

The user input/output unit 250 includes an environment for receiving user input and an environment for outputting specific information to the user, and includes an input adapter such as, for example, a touch pad, a touch screen, an on-screen keyboard, or a pointing device. It may include an output device including a device and 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 through a remote connection, and in such case, the code parsing device 130 may be performed as an independent server.

The network input/output unit 270 provides a communication environment for connection to the user terminal 110 through a network, for example, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), and It may include an adapter for communication such as 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.

FIG. 3 is a diagram explaining the functional configuration of the code parsing device of FIG. 1.

Referring to FIG. 3, the code parsing device 130 may be implemented including a configuration file receiving unit 310, a configuration file classifying unit 320, a code parsing unit 330, and a control unit (not shown in FIG. 3). there is. In one embodiment, the code parsing device 130 may be implemented by further including a code generation unit 340, an Autosa platform virtualization unit 350, and an ECU virtualization processing unit 360.

At this time, the code parsing device 130 does not have to include all of the above functional components at the same time, and depending on each embodiment, some of the above components are omitted or some or all of the above components are selectively included. It can also be implemented. In addition, the code parsing device 130 may be implemented as an independent module that selectively includes some of the above components, and performs a code parsing method for simulation of a vehicle software platform according to the present invention through linkage between each module. You may. Hereinafter, the operation of each component will be described in detail.

The configuration file receiving unit 310 may 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. In other words, developers can develop vehicle software using software development tools and perform various operations such as correcting errors or performing maintenance. A software development tool can manage settings made by the user while developing vehicle software by creating a configuration file.

For example, developers can perform system and ECU design through software development tools. For system design, settings for software components (SWC) and target ECU can be determined, and for ECU design, settings for ECU system configuration, RTE communication, and BSW module can be determined. Configuration files for vehicle software may be created on a device running a software development tool. If the configuration file of the vehicle software is created on the user terminal 110, the configuration file receiving unit 310 may receive the configuration file of the vehicle software from the user terminal 110.

In one embodiment, the configuration file receiving unit 310 may receive an AUTOSAR eXtensible Markup Language (ARXML) file of AUTOSAR-based software as a configuration file of 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 the user terminal 110. Automotive software can be created based on the AUTOSAR platform, which corresponds to an open automotive standard software structure, and the AUTOSAR platform can manage software configuration files in the form of ARXML files.

For example, when a software component of vehicle software is created through an Autosar-based software development tool, the component components can be saved in an ARXML file, a standardized digital exchange format based on the AUTOSAR specification set by the user. there is. At this time, the created ARXML file contains contents such as task, alarm, event, interrupt, priority, period, port, and data element. This may be included. 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.

In one embodiment, the configuration file receiving unit 310 is limited to receiving only files of a specific format as configuration files of vehicle software. For example, the configuration file receiving unit 310 may be limited to receiving only an ARXML file as a configuration file, and when a file other than an ARXML file is input, the configuration file may be re-input or may refuse to receive the file.

The configuration file classification unit 320 can classify types of configuration files. The configuration file classification unit 320 may analyze the type of the ARXML file before performing code parsing based on the ARXML file. When the type of the ARXML file is determined by the configuration file classification unit 320, the code parsing unit 330 can perform an independent code parsing operation depending on the file type. For example, depending on the ARXML file type, the information extracted through code parsing may be different.

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 that is included in the configuration file receiving unit 310 and performs an operation of classifying the type of the received configuration file.

In one embodiment, the configuration file sorting unit 320 stores the ARXML file as an ASW design ARXML file containing settings for the Application SoftWare layer (ASW) of the software platform, and a BSW design containing settings for the Basic SoftWare layer (BSW). It can be classified as either an ARXML file or an RTE design ARXML file, which contains settings for the RunTime Environment (RTE).

First, the ASW design ARXML file may correspond to an ARXML file containing settings related to the ASW of the Autosa platform. The ASW layer of the Autosa platform consists of a runnable, which is the smallest scheduling object with a unit function, and a combination of runnables, and modules that can operate independently can be composed of software components (SWC).

Additionally, the BSW design ARXML file may correspond to an ARXML file containing settings related to the BSW of the Autosa platform. The BSW layer of the Autosa platform is a hardware abstraction layer (hardware abstraction layer) that abstracts hardware-dependent input/output functions such as ADC (Analog to Digital Converter), digital input/output, and CAN (Controller Area Network) and provides an interface to the upper layer. It can be composed of HAL (Hardware Abstraction Layer) modules, services, and schedulers.

Additionally, the RTE design ARXML file may correspond to an ARXML file containing settings related to the RTE of the Autosa platform. The RTE layer of the Autosa platform may correspond to the layer responsible for the integration of ASW and BSW.

The code parsing unit 330 may parse the configuration file according to the type of configuration file and extract information for executing vehicle software on a virtualized software platform. In other words, the code parsing unit 330 selectively extracts only the information necessary for driving the vehicle software from among the configuration values for ASW, RTE, and BSW, and reorganizes the RTE API, Static Code, etc. into a form for simulation. It can be used for .

In one embodiment, the code parsing unit 330 may 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 may process code parsing with reference to the results classified by the configuration file classification unit 320.

In one embodiment, the code parsing unit 330 extracts a composition software component (CSWC, Composition SoftWare Component), a software component (SWC, SoftWare Component), a runnable, an event, and a port ( Extract the first parsing information including Port, Interface, and DataType, and extract Alarm, Task, App Mode, and OsApplication from the BSW design ARXML file. , extracts second parsing information including counter (OsCounter), interrupt service routine (ISR), and resource, and event-task mapping and software component instance (SWC) from the RTE design ARXML file. Third parsing information including instance) can be extracted.

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-input of the configuration file through the configuration file receiving unit 310. That is, if some of the information required for execution of the vehicle software is not extracted, the code parsing unit 330 may update the configuration file of the vehicle software and then repeatedly perform 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-entering the configuration file at the request of the code parsing unit 330. can be provided.

The code generator 340 may generate execution codes for executing vehicle software operating on a virtualized software platform based on the parsed information. For example, in the development process of automotive software on an existing software platform, when a project is compiled using a software development tool, a c file and a header file are created based on the created ARXML, and flashed on the target board. The process may proceed by creating a binary file for flashing and finally operating it on the target board. The code generator 340 may operate on a software platform in which vehicle software is virtualized to generate executable codes necessary for simulation to be performed in a Windows environment.

In one embodiment, the code generator 340 may generate a RunTime Environment (RTE) API and static code required to execute vehicle software based on the parsed information. Here, the RTE API is a runtime environment API that can provide a specific interface between components or between components and BSW (Basic Software). Additionally, static code may correspond to source code that implements the function of a component. The code generator 340 can generate static code that implements detailed functions of vehicle software using information parsed from the configuration file, and can generate an RTE API for the static code. At this time, the RTE API and static code can be created as a c file (.c), but of course, it is not limited to this.

The Autosa platform virtualization unit 350 can implement virtualization of a software platform and simulate the operation of vehicle software according to the execution of executable codes on the virtualized software platform. For example, a virtualized software platform may correspond to a virtualized AUTOSAR platform. Here, the virtualized Autosa platform may correspond to platform software on which executable code including the RTE API and static code can be executed, and the existing Autosa platform structure is mimicked to execute logic according to the contents of the RTE API and static code. can be performed, and output according to the operation results can be generated. At this time, the RTE API and static code may correspond to executable code generated for simulation of vehicle software.

In one embodiment, the Autosa platform virtualization unit 350 may operate in conjunction with independent modules that perform an operation to generate executable code. In other words, the independent modules can receive the configuration file of the vehicle software written through a software development tool, parse information for executing the vehicle software from the configuration file, and virtualize the vehicle software based on the parsed information. Executable codes for executing vehicle software running on a software platform can be generated. As a result, the Autosa platform virtualization unit 350 can enable simulation of the operation of vehicle software even in a Windows environment through virtualization of the software platform.

In one embodiment, the Autosa platform virtualization unit 350 may generate virtual Autosa platform code that implements virtualization for each module of the software platform. At this time, the virtual Autosa platform code can be implemented as a c file (.c). That is, the Autosa platform virtualization unit 350 can virtualize the existing Autosa platform into a Windows environment and provide it in order to simulate vehicle software in a Windows environment. Specifically, the Autosa platform virtualization unit 350 can provide virtualization of lower layers such as RTE (Run-Time Environment) and BSW (Basic SoftWare Layer) of the Autosa platform. For example, the Autosa platform virtualization unit 350 may provide vRTE, vOSEK OS, vService, vI/O, vMCAL, vPortpin, etc. as virtualized modules.

In one embodiment, the Autosa platform virtualization unit 350 uses executable codes and virtualized Autosa platform code to perform the operation logic of vehicle software during simulation and generate a simulation file that can operate in a Windows environment. there is. That is, the Autosa platform virtualization unit 350 can integrate executable codes and virtualized Autosa platform codes and then build them to generate an Autosa simulation file in '.exe' format that runs in a Windows environment. Thereafter, the Autosa simulation file can be executed in the Windows environment of the user terminal 110 and, if necessary, in the code parsing device 130. When the simulation file is executed, the operation logic of the vehicle software can be executed according to the contents of the RTE API and static code on the virtualized Autosa platform, and the output of the virtualized Autosa platform can be generated according to the operation results.

In one embodiment, the Autosa platform virtualization unit 350 may simulate the operation of a software component implementing vehicle software and determine the value of a virtual port variable that virtualizes the output of the 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) depending on the functional component (Application SWC) to be implemented. In other words, vehicle software can be defined through a set of interconnected software components.

Accordingly, the Autosa platform virtualization unit 350 can simulate the operation of each software component on the virtualized software platform and determine the value of the virtual port variable connected to the software component according to 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 order of the vehicle software, and the value of the virtual port variable may be changed by the output value output from the corresponding output port. You can.

The ECU virtualization processing unit 360 can receive the output of vehicle software according to simulation and 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 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 on a virtualized ECU or visualizing the screen output of a display panel, based on the output according to simulation.

In one embodiment, the ECU virtualization processing unit 360 may 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 graphics according to the operation result through a visualized interface.

The control unit (not shown in FIG. 3) controls the overall operation of the code parsing device 130 and includes a configuration file receiving unit 310, a configuration file sorting unit 320, a code parsing unit 330, and a code generating unit 340. ), control flow or data flow between the Autosa platform virtualization unit 350 and the ECU virtualization processing unit 360 can be managed.

Figure 4 is a diagram explaining the overall concept of vehicle software simulation in the present invention.

Referring to FIG. 4, the Windows-based vehicle software simulation method generates an AUTOSAR Simulation File that can be simulated on a virtualized AUTOSAR Platform and creates a graphic simulator for the virtualized ECU. Simulation results can be provided visually through the ECU Graphic Simulator.

More specifically, the vehicle software simulation method can parse essential information required for software execution through the arxml Parser based on the arxml file, the configuration file of vehicle software created using the Autosa development tool. At this time, the arxml parser can be implemented through the 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.

For example, the configuration file of vehicle software includes software component settings (data type, connection status with interface, etc.), ECU settings (hardware and resource configuration, etc.), and system settings (bus signals, topology, SWC). and ECU mapping, network settings, etc.) may be included. Additionally, the settings of the software component may include task operations and trigger conditions for implementing vehicle software.

Additionally, the vehicle software simulation method can generate the RTE API and static codes necessary for executing Autosa-based software through a code generator using parsed information.

Afterwards, the vehicle software simulation method is built by integrating the Virtual AUTOSAR Platform Code provided by the virtual AUTOSAR Platform and the executable codes generated through the code generator to build the Windows environment. You can create an executable AUTOSAR Simulation File.

Lastly, the vehicle software simulation method can run an executable file (.exe) created in a Windows environment, receive the results of the simulation run on the virtual Autosa platform, and use the virtualized ECU graphic simulator (Virtual ECU Graphic Simulation). It can be visualized and displayed.

Meanwhile, the code parsing method according to the present invention can be executed through the code parsing device 130, and in this case, the arxml parser (Parser) may correspond to the code parsing device 130. Additionally, the code generator may correspond to the code generator 340 of FIG. 3, the virtualized Autosa platform may correspond to the Autosa platform virtualization unit 350, and the ECU virtualization processing unit 360 may correspond to a virtual ECU graphic simulator.

Figure 5 is a diagram illustrating an embodiment of a vehicle software simulation process according to the present invention.

Referring to FIG. 5, the code parsing device 130 may be implemented by being included in a simulation device that performs Windows-based vehicle software simulation. Accordingly, in the Windows-based vehicle software simulation process, the code parsing device 130 may be implemented in the simulation from the configuration file of the vehicle software. An operation can be performed to extract necessary information.

Specifically, users can design vehicle software using Autosa development tools, and ARXML files can be generated accordingly. Once the ARXML design is completed, the RTE API can be created, and codes related to the operation of vehicle software can be created using information extracted by parsing the ARXML file. In the simulation device, a simulation file (Virtual AUTOSAR Simulation FILE) executable in a Windows environment can be created as a result of integrating the RTE API, static code, and virtualized AUTOSAR platform code (Virtual AUTOSAR Platform Code).

In addition, the simulation device can visualize the simulation results of vehicle software through a graphic simulator, which enables 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 running the software from a configuration file of the vehicle software during a simulation of the vehicle software.

Figure 6 is a diagram explaining an embodiment of a vehicle software simulation system according to the present invention.

Referring to FIG. 6, the code parsing method according to the present invention can extract essential information required for execution of vehicle software on a virtual AUTOSAR platform by parsing it from a configuration file of vehicle software. Specifically, the virtualized Autosa platform can provide virtualization to perform simulation of automotive software in a Windows environment. The virtualized Autosa platform may include a virtualized RTE layer (vRTE) and a virtualized BSW layer (vBSW).

Here, the virtualized BSW layer may correspond to a layer that virtualizes functions commonly used in various ECUs, including a virtualized service layer (Service Layer), a virtualized ECU abstraction layer (EAL), and virtualization It may include a microcontroller abstraction layer (MCAL).

Meanwhile, the content shown in FIG. 6 is an embodiment according to the present invention and is intended to supplement the understanding of the communication-related module, and of course, the content does not limit the scope of the present invention.

First, the virtualized service layer can virtualize services such as system, memory, and communication for system operation and overall control of modules in other BSW. System services can mainly include functions to manage tasks and interrupts, memory services can include functions for reading and writing to memory, and communication services use communication protocols such as CAN and LIN. It may contain the functions necessary to do so.

Additionally, the virtualized ECU abstraction layer can virtualize an abstraction layer that provides an interface to the upper layer of virtualized MCAL drivers. The virtualized ECU abstraction layer can also provide interfaces with external devices other than the microcontroller. For example, external devices may include EEPROM, Flash, Watchdog drivers, etc.

Additionally, the virtualized microcontroller abstraction layer can virtualize internal drivers for using microcontroller internal devices. Accordingly, the virtualized Autosa platform can exchange data (vPortpin data) with the virtualized ECU graphic simulator through the virtualized driver modules of the virtualized microcontroller abstraction layer. Meanwhile, virtualized driver modules may include vCAN drivers, vFlexRay drivers, vEthernet drivers, and vLIN drivers.

Figure 7 is a diagram illustrating an embodiment of the code parsing process according to the present invention.

Referring to FIG. 7, the code parsing device 130 parses information essential for running Autosar-based software from an ARXML file in order to simulate software designed based on the automotive software platform AUTOSAR in a virtual environment without using it on the target board, and provides RTE API and source code information can be created.

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 may determine target information to be parsed by applying parsing rules defined according to the type of ARXML file.

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

Additionally, the code parsing device 130 may generate RTE API codes for software simulation on a virtualized platform using information parsed through the code generator 340. The code parsing device 130 can generate static codes as well as RTE APIs to implement the execution of software, and is then built together with the virtual Autosa platform code to support execution on a virtualized platform. You can create an Autosa simulation file.

Figure 8 is a diagram explaining an embodiment of the OS virtualization process according to the present invention.

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

The scheduler (OsScheduler) module virtualizes the scheduler, updates the status of tasks according to priority based on task information, and determines the execution order by examining the status of the tasks. The alarm (OsAlarm) module can virtualize the alarm function and generate a creation request signal for the mapped task according to the execution order at each setting cycle. In one embodiment, the alarm module may generate a generation request signal by calling a callback function through a timer function at each set cycle.

The task (OsTask) module can create a task thread corresponding to the task according to the creation request signal, virtualize it, and process execution according to the state of the task. The task module can create a task thread in the form of a structure and manage the task's priority, periodicity/non-periodic status, and function pointer.

The Resource module can manage resource use according to task execution by virtualizing resources. In one embodiment, when a resource is used by a specific task, the resource module can perform mutual exclusion for acquisition of the resource through a mutex and change the priority of the task owning the resource by the scheduler. .

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

As a result, the task to be executed can be determined by the scheduler module, and the corresponding task information can be transmitted to the task thread (OsTask Thread) module through the scheduler module.

A task module (eg, OsTask Thread in FIG. 8) may execute the operations of the corresponding task thread according to the execution control of the scheduler module. A task thread can perform periodic and aperiodic operations depending on the corresponding task type. A task thread that performs periodic operations can be created by a creation request signal from the alarm module, and can be terminated after executing the mapped event once. In contrast, a task thread that performs aperiodic operations can execute mapped events while activated by the alarm module's activation request signal, and even if the event execution is completed, it does not terminate and its operation state remains in the suspended state. It can be changed to wait for the next activation signal.

The vehicle software simulation system 100 supports virtualization of the vehicle software platform and can provide high convenience in the development and verification testing of vehicle software through simulation of vehicle software in a Windows PC environment.

Although the present invention has been described above with reference to preferred embodiments, those skilled in the art may make various modifications and changes to the present invention without departing from the spirit and scope of the present invention as set forth in the claims below. You will understand that you can do it.

100: Automotive software simulation system
110: User terminal 130: Code parsing device
150: database
210: Processor 230: Memory
250: user input/output unit 270: network input/output unit
310: Configuration file receiving unit 320: Configuration file classification unit
330: code parsing unit 340: code generation unit
350: Autosa platform virtualization unit 360: ECU virtualization processing unit

Claims (12)

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 types of configuration files; and
A code parsing unit that parses the configuration file according to the type of the configuration file and extracts information for executing the vehicle software on a virtualized software platform. Code parsing device for simulating a vehicle software platform comprising a.
The method of claim 1, wherein the configuration file receiving unit
A code parsing device for simulation of a vehicle software platform, characterized in that it receives an ARXML (AUTOSAR eXtensible Markup Language) file of AUTOSAR-based software as a configuration file of the vehicle software.
The method of claim 2, wherein the configuration file classification unit
The ARXML file is an ASW design ARXML file containing settings for the Application SoftWare layer (ASW) of the software platform, a BSW design ARXML file containing settings for the Basic SoftWare layer (BSW), and settings for the RunTime Environment (RTE). A code parsing device for simulation of a vehicle software platform, characterized in that it is classified into one of the RTE design ARXML files containing.
The method of claim 3, wherein the code parsing unit
From the ASW design ARXML file, composition software component (CSWC, Composition SoftWare Component), software component (SWC, SoftWare Component), runnable, event, port, interface, and data type ( Extract first parsing information including DataType),
From the BSW design ARXML file, it includes Alarm, Task, App Mode, Application (OsApplication), Counter (OsCounter), Interrupt Service Routine (ISR), and Resource. extracts the second parsing information,
A code parsing device for simulation of a vehicle software platform, characterized in that third parsing information including event-task mapping and software component instance (SWC Instance) is extracted from the RTE design ARXML file.
The method of claim 4, wherein the code parsing unit
A code parsing device for simulating a vehicle software platform, characterized in that, when extraction of at least one of the first to third parsing information fails, a re-input of the configuration file is requested through the configuration file receiver.
According to paragraph 1,
A code parsing device for simulating a vehicle software platform, further comprising a code generator that generates executable codes for executing the vehicle software operating on a virtualized software platform based on the parsed information.
The method of claim 6, wherein the code generator
A code parsing device for simulating a vehicle software platform, characterized in that it generates RTE (RunTime Environment) API and static code required for execution of the vehicle software based on the parsed information.
In clause 7,
an Autosa platform virtualization unit that implements virtualization of the software platform and simulates the operation of the vehicle software according to execution of the executable codes; and
Code parsing for simulation of the vehicle software platform, further comprising: 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. Device.
The method of claim 8, wherein the ECU virtualization processing unit
A code parsing device for simulating a vehicle software platform, characterized in that it 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.
Receiving a configuration file of vehicle software created using a software development tool through a configuration file receiving unit;
Classifying the type of configuration file through a configuration file classification unit; and
Parsing the configuration file according to the type of the configuration file through a code parser to extract information for executing the vehicle software on a virtualized software platform; Code parsing for simulation of the vehicle software platform including method.
According to clause 10,
A code parsing method for simulating a vehicle software platform, further comprising: generating executable codes for executing the vehicle software operating on a virtualized software platform based on the parsed information through a code generator. .
According to clause 11,
Implementing virtualization of the software platform through an Autosa platform virtualization unit and simulating the operation of the vehicle software according to execution of the executable codes; and
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 through a graphic interface based on the output; a simulation of the vehicle software platform further comprising: How to parse code for.