KR20240077722A - Method for generating and verifying automotive embedded software based on autosar - Google Patents

Abstract

A verification method for Autosa-based automotive embedded software is provided. The method includes the steps of emulating RTE and BSW among the layers constituting Autosa for the vehicle embedded software that is a verification target according to a predetermined test environment; Verifying the operation of the Autosa-based vehicle embedded software implemented to correspond to a predetermined test target function; and, if there is no abnormality as a result of the verification, loading the vehicle embedded software into the target ECU.

Description

Method for generating and verifying embedded software for vehicles based on Autosar {METHOD FOR GENERATING AND VERIFYING AUTOMOTIVE EMBEDDED SOFTWARE BASED ON AUTOSAR}

The present invention relates to a method for generating and verifying embedded software for vehicles based on Autosa.

Recently, as vehicles move from being mechanically structured to more computer-like, the importance of software to control them is increasing, and the complexity of the software is also continuously increasing.

To reduce this complexity and coupling, the AUTomotive Open System Architecture (AUTOSAR) standard was established to ensure reliability and reusability of automotive embedded software.

Autosa is a standard software platform for automotive electronics developed for reliability and reusability, and many vehicle companies are currently working to install platforms developed based on Autosa into their vehicles.

Meanwhile, the traditional automotive embedded software development process has the problem of requiring a lot of time and cost, so there is a need to reduce the effort required to develop and verify automotive embedded software through modeling and simulation.

Public Patent Publication No. 10-2016-0047147 (2016.05.02)

The problem to be solved by the present invention is to provide an Autosa-based automotive embedded software generation and verification method that can generate and verify automotive embedded software through a virtual environment when the image file of the target ECU does not exist. will be.

However, the problem to be solved by the present invention is not limited to the problems described above, and other problems may exist.

In the first aspect of the present invention to solve the above-described problem, the verification method of automotive embedded software based on Autosar involves verifying RTE and BSW among the layers constituting Autosa for the vehicle embedded software that are subject to verification according to a predetermined test environment. emulating; Verifying the operation of the Autosa-based vehicle embedded software implemented to correspond to a predetermined test target function; and, if there is no abnormality as a result of the verification, loading the vehicle embedded software into the target ECU.

In some embodiments of the present invention, the step of emulating RTE and BSW among the layers constituting Autosa for the vehicle embedded software that is the subject of verification according to a predetermined test environment is operated on a PC with the predetermined test environment. OSEK may be driven based on a POSIX-based operating system interface, and the Autosa may be driven based on the API of the OSEK.

In some embodiments of the present invention, the step of emulating RTE and BSW among the layers constituting Autosa for the automotive embedded software that are subject to verification according to a predetermined test environment includes supporting FMI in the BSW among the layers of Autosa. You can.

In some embodiments of the present invention, the step of emulating RTE and BSW among the layers constituting Autosa for the vehicle embedded software that is the subject of verification according to a predetermined test environment includes creating an Autosa communication stack in the BSW. The step of generating an Autosa communication stack in the BSW includes configuring a COM module that transmits data received from the RTE to a PduR module in the form of a PDU; Constructing a PduR module that transmits data received from the COM module to the CANIF_FMU module or transmits data received from the CANIF_FMU module to the COM module; Configuring a CANIF_FMU module that selects an internal channel based on the PDU identifier and delivers the PDU to a Hardware Object Handle (HOH) connected to each channel; And it may include configuring a CAN module that records the PDU delivered through the CANIF_FMU module to a hardware object of the CAN control unit.

In some embodiments of the present invention, the CANIF_FMU module calls the FMU write function to convert the data in the PDU format to the FMU format and transmits it to the CAN module, and the CAN module sends a reception indicator function to the CANIF_FMU module. The call generates an interrupt regarding reception of data in the FMU format, and the CANIF_FMU module can convert the data converted into the FMU format into data in the PDU format and transmit it to the PduR module.

In some embodiments of the present invention, the step of creating an Autosa communication stack in the BSW includes configuring a socket module that provides a socket function from a certain manufacturer to support a CAN network with the CAN module; Constructing a CAN library module provided between the socket module and the CAN module to simulate a data communication environment on a CAN-based hardware interface; And it may include configuring a socket adapter module that supports TCP/IP-based data communication in an environment where the CAN-based hardware interface is not provided.

In addition, the method of generating embedded software for a vehicle based on Autosar according to the second aspect of the present invention includes the step of emulating RTE and BSW among the layers constituting Autosa for the embedded software for the vehicle according to a predetermined test environment, Among the above Autosa layers, BSW supports FMI.

In some embodiments of the present invention, the step of emulating RTE and BSW among the layers constituting Autosa for the automotive embedded software to suit a predetermined test environment includes the COM module, PduR module, CANIF_FMU module, and It may include creating an Autosa communication stack including a CAN module.

In some embodiments of the present invention, the step of creating an Autosa communication stack including a COM module, a PduR module, a CANIF_FMU module, and a CAN module in the BSW includes converting the data received from the RTE to the PduR module in the form of a PDU. Configuring the passing COM module; Constructing a PduR module that transmits data received from the COM module to the CANIF_FMU module or transmits data received from the CANIF_FMU module to the COM module; Configuring a CANIF_FMU module that selects an internal channel based on the PDU identifier and delivers the PDU to a Hardware Object Handle (HOH) connected to each channel; And it may include configuring a CAN module that records the PDU delivered through the CANIF_FMU module to a hardware object of the CAN control unit.

In addition, the computer program according to another aspect of the present invention is combined with a computer, which is hardware, to execute the verification method of the Autosa-based embedded software for a vehicle, and is stored in a computer-readable recording medium.

Other specific details of the invention are included in the detailed description and drawings.

According to the above-described present invention, it is possible to verify the software itself and perform verification that simulates the target ECU environment before mounting it on the actual ECU, so that development and verification by the software itself is possible even in an environment where hardware does not exist, and is based on Autosa. It has the advantage of reducing the time and cost required for the development and verification process of embedded software for vehicles.

The effects of the present invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below.

Figure 1 is a diagram showing the Otosa standard structure.
Figure 2 is a diagram showing Auto's standard BSW structure.
Figure 3 is a flowchart of a method for generating and verifying embedded software for a vehicle according to an embodiment of the present invention.
Figure 4 is a flowchart of a method for generating and verifying embedded software for a vehicle according to another embodiment of the present invention.
Figure 5 is a diagram for explaining the entire system in which an embodiment of the present invention is implemented.
Figures 6a and 6b are diagrams for explaining the configuration of embedded software for vehicles at the source level.
Figures 7a and 7b are diagrams for explaining the configuration of embedded software for vehicles at the binary level.
Figure 8 is a diagram showing the configuration of an embedded software package for a vehicle for ECU virtualization in an embodiment of the present invention.
Figure 9 is a diagram for explaining the Autosa configuration tool included in an embedded software package for a vehicle in one embodiment of the present invention.
Figure 10 is a diagram showing a portion of the BSW structure according to an embodiment of the present invention.
Figure 11 is a diagram for explaining the CAN and CAN FD parts of the BSW structure in one embodiment of the present invention.
Figure 12 is a diagram for explaining the process of creating an Autosa communication stack in BSW in an embodiment of the present invention.
Figures 13a and 13b are diagrams showing the CAN communication substructure of the BSW structure in an embodiment of the present invention.
Figure 14 is a diagram for explaining the CAN communication software call structure in one embodiment of the present invention.
Figure 15 is a diagram for explaining the diagnostic module portion of the BSW structure in one embodiment of the present invention.
Figure 16 is a diagram showing an example of an integrated simulation environment to which an embodiment of the present invention is applied.
FIG. 17 is a diagram for explaining the data exchange process in the integrated simulation environment of FIG. 16.

The advantages and features of the present invention and methods for achieving them will become clear by referring to the embodiments described in detail below along with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. The present embodiments are merely provided to ensure that the disclosure of the present invention is complete and to provide a general understanding of the technical field to which the present invention pertains. It is provided to fully inform the skilled person of the scope of the present invention, and the present invention is only defined by the scope of the claims.

The terminology used herein is for describing embodiments and is not intended to limit the invention. As used herein, singular forms also include plural forms, unless specifically stated otherwise in the context. As used in the specification, “comprises” and/or “comprising” does not exclude the presence or addition of one or more other elements in addition to the mentioned elements. Like reference numerals refer to like elements throughout the specification, and “and/or” includes each and every combination of one or more of the referenced elements. Although “first”, “second”, etc. are used to describe various components, these components are of course not limited by these terms. These terms are merely used to distinguish one component from another. Therefore, it goes without saying that the first component mentioned below may also be a second component within the technical spirit of the present invention.

Unless otherwise defined, all terms (including technical and scientific terms) used in this specification may be used with meanings commonly understood by those skilled in the art to which the present invention pertains. Additionally, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless clearly specifically defined.

Below, to help those skilled in the art understand, the background of the present invention will be described, and then based on this, the Autosa-based vehicle embedded software generation and verification method according to an embodiment of the present invention will be described in detail.

Figure 1 is a diagram showing the Otosa standard structure.

Autosa is a global partnership in the automotive field created in 2003 that aims to develop and establish an open standard software architecture for vehicle ECUs. Specific goals include scalability for multiple vehicle and platform variants, software transferability, consideration of availability and safety requirements, cooperation between various partners, sustainable use of natural resources and maintainability across the entire product life cycle.

The structure of the general vehicle system guided by Autosa consists of BSW (102, Basic Software), RTE (103, Runtime Environment), and ASW (104, Application Software).

ASW (104) is an application software layer and is a set of software components. ASW (104) is a software component that implements the core functions unique to the controller to be developed by OEMs and suppliers.

RTE (103) serves to exchange and connect data between ASW (104) components and between ASW (104) and BSW (102). Software components implemented in the ASW (104) can be used through an API call without any modification through the RTE (103).

The BSW 102 separates hardware and software and serves to provide hardware-independent application services. In other words, the BSW 102 is a standardized software layer that provides services necessary for software components to perform necessary tasks, and provides services related to input/output, memory, communication, etc. to software components.

Lastly, ECU (101, Electronic Control Unit) is the actual hardware on which vehicle embedded software runs, and is the basic unit of vehicle control.

Figure 2 is a diagram showing Auto's standard BSW structure.

Among the Autosa layers, BSW is largely composed of a service layer (201), ECU abstraction layer (202), MCAL (204, Microcontroller Abstraction Layer), and CDD (203, Complex Device Drivers).

The service layer 201 is the highest layer among the BSW layers and provides system services, memory services, and communication services for system operation and overall control of modules in other BSWs.

At this time, the system service performs the function of managing tasks and interrupts. The memory service performs functions to read and write to memory. Communication services provide the functions necessary to use various communication protocols in automotive embedded systems.

Next, the ECU abstraction layer 202 provides an ECU-independent interface to the service layer and the ASW layer. In one embodiment, various memory interfaces and communication interfaces may be implemented depending on the ECU through the ECU abstraction layer 202.

Next, MCAL 204 provides a specific interface independent of the microcontroller to the abstraction layer. When applying Autosa to a microcontroller with a different design, the driver of MCAL (204) can be used to call communication, memory, and input/output modules, etc., regardless of the microcontroller.

Lastly, the CDD 203 is a layer that forms a direct interface from the microcontroller to the RTE without being connected to a specific layer, allowing information from the BSW to be directly transmitted to the ASW through the RTE. The CDD 203 can be utilized by adding drivers for functions not defined in Autosa.

Hereinafter, a method for generating and verifying embedded software for a vehicle based on Autosa according to an embodiment of the present invention will be described with reference to FIGS. 3 to 9.

Figure 3 is a flowchart of a method for generating and verifying embedded software for a vehicle according to an embodiment of the present invention.

First, among the layers that make up Autosa for automotive embedded software, RTE and BSW are emulated according to a predetermined test environment to generate embedded software for vehicles (301).

Next, the operation of the Autosa-based vehicle embedded software implemented to correspond to a predetermined test target function is verified (302), and if there are no abnormalities as a result of the verification, the vehicle embedded software is mounted on the target ECU (S303).

Figure 4 is a flowchart of a method for generating and verifying embedded software for a vehicle according to another embodiment of the present invention.

First, the binary file built to correspond to the target ECU information is virtualized through QEMU (401), and on the virtualized ECU (hereinafter referred to as virtual ECU), the Autosar-based automotive embedded software to be verified is installed in a predetermined test environment. Embedded software for vehicles is created through emulation (402).

Next, the operation of Autosa implemented to correspond to a predetermined test target function is verified (403), and if there are no abnormalities as a result of the verification, the vehicle embedded software is mounted on the target ECU (404).

At this time, the embodiment described in FIG. 3 corresponds to the source level generation and verification method (CAT 1), and the embodiment described in FIG. 4 corresponds to the binary level generation and verification method (CAT 2).

Figure 5 is a diagram for explaining the entire system in which an embodiment of the present invention is implemented.

The Autosa-based automotive embedded software verification system 500 according to an embodiment of the present invention includes a virtual ECU 501, an integrated development environment providing unit 502, an integrated simulation middleware unit 503, and a vehicle communication network simulation unit ( 504) and an automatic verification environment provision unit 505.

The virtual ECU 501 refers to all virtualized hardware and vehicle embedded software to be created or verified through source level or binary level. The virtual ECU 501 may include a plurality of virtualized ECUs depending on the functions provided.

The integrated development environment unit 502 is connected to the virtual ECU 501, and image files built through source level (CAT 1) or binary level (CAT 2) methods can be debugged using Eclipse and QEMU plugins. there is.

The integrated simulation middleware unit 503 operates by being connected to a plurality of virtualized ECUs (vECUs, 501) and the vehicle communication network simulation unit 504 through FMI (Functional Mockup Interface), and functions as a functional mockup unit (FMU) through FMI. exchange. At this time, the FMU becomes a simulator of a specific unit, but since the FMU is independent of the processor, if the hardware is connected instead of the FMU when actual hardware is available, the simulation can naturally be HILS (Hardware In the Loop Simulation).

The vehicle communication network simulation unit 504 analyzes information collected from the virtual ECU 501 and simulates a specific communication interface between ECUs to enable data exchange. As an example, the vehicle communication network simulation unit 504 may include vCAN, vCAN FD, vLIN, and vEthernet.

Lastly, the automatic verification environment providing unit 505 supports the ASAM XIL-MA interface to support test case exchange between the vehicle communication network simulation unit 504 and third party tools.

Hereinafter, the method of generating and verifying embedded software for vehicles at the source level and binary level performed by the entire system described above will be described in more detail.

Figures 6a and 6b are diagrams for explaining the configuration of embedded software for vehicles at the source level.

First, Figure 6a shows the configuration of embedded software for vehicles at the source level, and this method is a structure that allows development and verification of embedded software for vehicles when it is difficult to obtain an image file of the target ECU. The source level technique is a method of emulating RTE (602), BSW (601), OS, and MCAL, excluding ASW (603), with operable software in a PC/server environment to implement a vehicle ECU virtualization environment. In other words, the source level technique focuses on verifying the operation of the ASW (603), BSW (601), and RTE (602) and does not take into account the ECU.

r die Elektronik in Kraftfahrzeugen)가 구동되고, OSEK(630)의 API를 기반으로 오토사 기반 차량용 임베디드 소프트웨어가 구동될 수 있다.Next, Figure 6b shows the configuration of Figure 6a in more detail. One embodiment of the present invention is based on a POSIX (620, Portable Operating System Interface)-based operating system interface operated on a PC (610) as a predetermined test environment and OSEK (630, Offene Systeme und deren Schnittstellen f

r die Elektronik in Kraftfahrzeugen) is run, and Autosa-based vehicle embedded software can be run based on the API of OSEK (630).

That is, in the case of the source level method in one embodiment of the present invention, Autosa is run based on POSIX (620) on the PC (610). At this time, POSIX (620) is an application interface standard established by IEEE for the purpose of developing highly portable Unix applications by organizing common APIs of different Unix OSs. POSIX (620) allows you to run applications regardless of the operating system.

In addition, OSEK (630) is an operating system for automotive embedded systems, and is a standard that creates a communication stack and network management protocol, and refers to a real-time operating system for vehicles.

One embodiment of the present invention allows OSEK (630) to operate based on POSIX (620) based on each of these operating systems, and can run Autosa using the API of OSEK (630). However, an embodiment of the present invention is characterized by supporting FMI (640) within Autosa, unlike the existing Autosa standard.

Figures 7a and 7b are diagrams for explaining the configuration of embedded software for vehicles at the binary level.

First, referring to Figure 7a, in the case of the binary level, if there is specific hardware to run embedded software for a vehicle, but the actual hardware does not exist, the specific hardware is virtualized on QEMU and emulated. In other words, vehicle embedded software can be verified by running the binary file of the vehicle embedded software on virtualized hardware. This binary level method can verify the entire operation of the binary file of a given automotive embedded software before it is mounted on the target ECU.

Next, Figure 7b shows the configuration of Figure 7a in more detail. In one embodiment of the present invention, OSEK (730) is run on a virtualized ECU (701) through QEMU (720) on a PC (710) in a predetermined test environment, and Autosaga is run based on the API of OSEK (730). It can be. At this time, since the QEMU 720 is in an isolated state, a communication port must be opened on the QEMU 720 for communication. One embodiment of the present invention can transmit and receive network data through the virtualized PCI (740) formed for communication of the QEMU (720).

FIG. 8 is a diagram illustrating the configuration of a vehicle embedded software package 800 for ECU virtualization in an embodiment of the present invention.

Figure 8 shows an embedded software package 800 for a vehicle configured to support data exchange according to the Autosa 3 version standard. At this time, an embodiment of the present invention replaces CANIF defined in the Autosa standard with CANIF_FMU for network simulation (840). Details related to this will be described later.

In one embodiment, communication between the virtual ECUs 821 and 822 on the vehicle embedded software package 800 may exchange data through the virtual network 810. At this time, the virtual network 810 corresponds to the integrated simulation middleware unit and the vehicle communication network simulation unit.

The data exchange process between virtual ECUs 821 and 822 is as follows. To exchange data between vECU1 (821) and vECU2 (822), data is first transmitted from vECU1 (821) to the virtual network (810). Next, the integrated simulation middleware unit and the vehicle communication network simulation unit process the transmitted data and then transmit the data to vECU2 (822).

At this time, the vehicle communication network simulation unit can acquire information such as the operating status of the vECU (821, 822). In addition, when the vehicle communication network simulation unit generates and transmits data to be simulated to a specific vECU, vECU simulation is possible using the data in the vECU. The test cases used in this process can be provided through a vehicle communication network simulator tool, or can also be provided through a third-party tool.

Meanwhile, exchanging test cases may be difficult because the interfaces for executing test cases generated through each tool are different. In order to solve this problem, one embodiment of the present invention provides the ASAM XiL-MA interface to enable test case exchange. This was made possible.

Additionally, the vehicle embedded software package in one embodiment of the present invention may include an Autosa configuration tool (830). The Autosa configuration tool (830) is provided as part of the software package (800) for creating a virtual ECU, a GUI (Graphic User Interface (831)) for executing the configuration tool (830), and ARXML generation for generating the source code of the Autosa software. Unit 832, a DBC input/output unit 833 (import/export) that reflects CANDB containing data transmission information for CAN communication in software or extracts and stores signals, and a source code generation unit that generates code using ARXML ( 834, Code Generator).

Figure 9 is a diagram for explaining the Autosa configuration tool included in the embedded software package for a vehicle in one embodiment of the present invention.

Figure 9 is a diagram for explaining the build process and debugging process of the Autosa configuration tool 900 in the present invention. To configure embedded software for a vehicle, first, preset Arxml is read through the GUI 901 for Arxml settings. and import or export dbc files for CAN communication.

When Arxml configuration through the ARXML generator 902 is completed (910), source code is generated through the source code generator 904 (920). The generated source code is created as an executable file through a compilation and build process (930). At this time, in the case of the source level method, the automotive embedded software running on POSIX is created as an executable file, and in the case of the binary level method, the virtual ECU and the automotive embedded software running in the virtual ECU are created as an executable file.

If the executable file created in this way is loaded into the Eclipse IDE in plug-in format, emulation and debugging of the executable file are possible (940).

Hereinafter, with reference to FIGS. 10 to 17, the BSW portion of the vehicle embedded software package configuration for ECU virtualization in FIG. 7 described above will be described in more detail.

FIG. 10 is a diagram illustrating a BSW structure portion 1000 according to an embodiment of the present invention.

One embodiment of the present invention supports Auto's standard API, and the BSW as shown in FIG. 10 is constructed by reconfiguring the vehicle embedded software package (1000).

First, the process of creating an Autosa communication stack during BSW configuration will be described with reference to FIGS. 11 to 13.

Figure 11 is a diagram for explaining the CAN and CAN FD portions of the BSW structure in one embodiment of the present invention. Figure 12 is a diagram for explaining the process of creating an Autosa communication stack in BSW in an embodiment of the present invention.

In one embodiment, the Autosa communication stack in BSW includes a COM module 1101, a PduR (1102, Pdu Router) module, a CANIF_FMU module 1103, and a CAN module 1104.

First, a COM module 1101 is created that transmits the data received from the RTE to the PduR module 1102 in the form of a PDU (1201). At this time, PDU refers to an abstracted protocol for inter-layer message transmission.

Signal data transmitted from the COM module 1101 refers to the message itself to be transmitted internally and externally. The signal transmitted through RTE from the software component is stored in the I-PDU buffer in the COM module 1101 and is transmitted to the PduR module 1102 in the form of an I-PDU, or the signal included in the I-PDU is stored in the I-PDU buffer. It is analyzed and delivered to the software component connected to the signal.

Next, configure the PduR module 1102 to transfer the data received from the COM module 1101 to the CANIF_FMU module 1103 or to transfer the data received from the CANIF_FMU module 1103 to the COM module 1101 (1202) ).

The PduR module 1102 configures a routing table. At this time, the routing table is a table that defines a bundle of signals to be exchanged through communication and defines the destination point of the bundle of signals. Accordingly, the PduR module 1102 transfers the signal transmitted from the RTE to the COM module 1101 to the CANIF_FMU module 1103, which is the destination of the signal, or transfers the signal received from the CANIF_FMU module 1103 to COM, which is the destination of the signal. It can be delivered (routed) to the module 1101.

Next, the CANIF_FMU module 1103 is configured to select an internal channel based on the PDU identifier and deliver the PDU to the HOH (Hardware Object Handle) connected to each channel (1203).

Next, the CAN module 1104 is configured to write the PDU transmitted through the CANIF_FMU module 1103 to the hardware object of the CAN controller (1204). At this time, the object flag is set to 1, and if the object flag value is 1, CAN data is transmitted through the transceiver.

Meanwhile, one embodiment of the present invention is characterized in that CANIF_FMU is applied instead of CANIF in the Autosa standard, and has the feature that data exchange of FMU is possible through the CANIF_FMU module 1103.

Figures 13a and 13b are diagrams showing the CAN communication substructure of the BSW structure in one embodiment of the present invention.

Referring to FIGS. 13A and 13B, one embodiment of the present invention requires virtualizing a transceiver for CAN communication to enable operation at the source level and binary level.

To this end, an embodiment of the present invention may configure a socket module 1300 that provides a socket function from a certain manufacturer to support a CAN network with a CAN module. At this time, examples of sockets for the CAN network may be Vector's VXL CAN (1302), Peak's Peak (1301), and ZLG's Can hardware interface (1303). Here, communication simulation of CAN FD is possible through VXL CAN (1302). Meanwhile, the socket may include sockets for Linux and Windows that enable support on Windows and Linux.

Additionally, an embodiment of the present invention can configure a socket adapter module 1310 to support TCP/IP-based data communication in an environment where a CAN-based hardware interface is not provided.

Meanwhile, in the Autosa communication stack in one embodiment of the present invention, in the case of the source level method, a CAN library module 1320 is provided between the socket module and the CAN module and simulates the data communication environment on the CAN-based hardware interface. It is characterized by configuring (Figure 13a). On the other hand, the binary level method includes information on the target ECU, so unlike the source level method, there is no need to provide a CAN library module 1320 (FIG. 13b).

Figure 14 is a diagram for explaining the CAN communication software call structure in one embodiment of the present invention.

Referring to FIG. 14, in an embodiment of the present invention, as the CAN communication API is called, the COM module 1401 transmits the data received from the RTE to the PduR module 1402 in the form of a PDU through the PduR_ComTransmit function.

Next, the PduR module 1402 calls the CanIf_FMU_Transmit function to transmit data in the form of a PDU to the CANIF_FMU module 1403.

Next, the CANIF_FMU module 1403 calls the Can_FMU_Write function, which is an FMU write function, to convert the data in PDU format to FMU format and then transfers it to the CAN module 1404.

Next, the CAN module 1404 records the data received from the CANIF_FMU module 1403 in the CAN control unit 1405.

Afterwards, when a reception-related interrupt (Rx interrupt) is generated from the CAN control unit 1405 and the CAN module 1404 receives it, the CAN module 1404 calls the CanIf_FMU_RxIndication function, which is a reception indicator function, to the CANIF_FMU module 1403. Generates an interrupt regarding reception of FMU type data.

Next, the CANIF_FMU module 1403 calls the Pdur_CanIf_FMU_RxIndication function to convert the data converted into FMU format into PDU format data and transmit it to the Pdur module 1402, and the data is transmitted to the RTE through the COM module 1401. It can be.

Figure 15 is a diagram for explaining the diagnostic module portion of the BSW structure in one embodiment of the present invention.

Among the BSW structures according to an embodiment of the present invention, a diagnostic module that performs a diagnostic function may include a DEM module 1510, a DET module 1520, and a DCM module 1530.

In one embodiment, the DEM module 1510 is included in the service layer (system service) of BSW, processes diagnostic events, and stores information related to the events in the NvM (1540, NVRAM Manager). Additionally, the DEM module 1510 may transmit diagnostic information to the DCM module 1530.

In one embodiment, the DET module 1520 is a module used in the development process and provides an API for reporting errors. When the DET module 1520 function is utilized, a function for collecting errors may be added to modules belonging to the BSW.

In one embodiment, the DCM module 1530 is included in the service layer (communication service) and is used to test communication with external tools. The DCM module 1530 receives a request from a test tool and returns information according to the request. Additionally, the DCM module 1530 may return a code indicating positive or negative through validation in the process of processing the request (i.e., processing errors related to communication).

Hereinafter, an application example of an embodiment of the present invention will be described with reference to FIGS. 16 and 17.

Figure 16 is a diagram showing an example of an integrated simulation environment to which an embodiment of the present invention is applied. FIG. 17 is a diagram for explaining the data exchange process in the integrated simulation environment of FIG. 16.

Figure 16 shows a simulation environment in which Autosa-based automotive embedded software for DDM (1610, Door Drive Module), BCM (1620, Body Control Module), and cluster 1610 is mounted on a virtual ECU. The integrated development environment providing unit 1601 extracts signals from data simulating CAN and CAN FD through the FMU received through FMI, executes commands according to the signals, and then sends the results to the vehicle communication network simulator unit through FMI. returns Additionally, test data can be transmitted and received with third-party apps through ASMA XiL MA.

Referring to FIG. 17, first, in the case of DIO_{Signal}SW, a digital input/output signal, it means a signal generated by a software component utilizing {Signal}. For example, DIO_TurnSignalSW is a signal generated when the turn signal (TurnSignal) is turned on and off in the vehicle.

When any of the TurnSignal, SideMirror, HeatLamp, FogLamp or Seatbelt signals are generated, the FMU containing the CAN frame is delivered to the virtual network. In a virtual network, information about the signal is stored and FMUized information is transmitted.

Since each virtual ECU has predefined signals that can be received from CANIF_FMU, among the generated signals, each virtual ECU only receives data that it can use. Therefore, if the DIO_TurnSignalSW signal is generated in the BCM module 1720, it transmits CAN_TurnSignal on the virtual network, and the DDM module 1710 provides a PWM signal through PWM_TurnSignalLamp according to the CAN_TurnSignal signal generation, causing the turn signal lamp of the side mirror to blink. A signal can be provided. Additionally, as the CAN_TurnSignal signal is transmitted to the cluster module 1730, the DISPLAY_TurnSignalLamp signal is generated, and through this, the light on the turn signal icon blinks.

As another example, if a door opening is detected by the door open detection sensor of the DDM module 1710, the DIO_DoorOpenSW signal is generated, and a signal is generated from the data stored in the I-PDU in the PduR module to operate the lamp on the door side according to the door opening. is extracted and delivered to the software component through RTE, a PWM signal is generated through PWM_DoorOpenLamp, and the lamp lights up. In addition, a CAN_DoorOpen signal is sent through the virtual network, and the signal is transmitted to the cluster module 1730 to generate a DISPLAY_DOOROPEN signal, so that the door open icon of the cluster lights up.

The method for verifying embedded software for a vehicle based on Autosa in an embodiment of the present invention described above may be implemented as a program (or application) and stored in a medium in order to be executed in combination with a computer, which is hardware.

The above-mentioned program is C, C++, JAVA, Ruby, and It may include code encoded in a computer language such as machine language. These codes may include functional codes related to functions that define the necessary functions for executing the methods, and include control codes related to execution procedures necessary for the computer's processor to execute the functions according to predetermined procedures. can do. In addition, these codes may further include memory reference-related codes that indicate at which location (address address) in the computer's internal or external memory additional information or media required for the computer's processor to execute the above functions should be referenced. there is. In addition, if the computer's processor needs to communicate with any other remote computer or server in order to execute the above functions, the code uses the computer's communication module to determine how to communicate with any other remote computer or server. It may further include communication-related codes regarding whether communication should be performed and what information or media should be transmitted and received during communication.

The storage medium refers to a medium that stores data semi-permanently and can be read by a device, rather than a medium that stores data for a short period of time, such as a register, cache, or memory. Specifically, examples of the storage medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc., but are not limited thereto. That is, the program may be stored in various recording media on various servers that the computer can access or on various recording media on the user's computer. Additionally, the medium may be distributed to computer systems connected to a network, and computer-readable code may be stored in a distributed manner.

The description of the present invention described above is for illustrative purposes, and those skilled in the art will understand that the present invention can be easily modified into other specific forms without changing the technical idea or essential features of the present invention. will be. Therefore, the embodiments described above should be understood in all respects as illustrative and not restrictive. For example, each component described as single may be implemented in a distributed manner, and similarly, components described as distributed may also be implemented in a combined form.

The scope of the present invention is indicated by the claims described below rather than the detailed description above, and all changes or modified forms derived from the meaning and scope of the claims and their equivalent concepts should be construed as being included in the scope of the present invention. do.

501: Virtual ECU
502: Integrated development environment provision department
503: Integrated simulation middleware unit
504: Vehicle communication network simulation unit
505: Automatic verification environment provision department

Claims (9)

In the verification method of Autosa-based automotive embedded software,
A step of emulating RTE and BSW among the layers constituting Autosa for the vehicle embedded software to be verified according to a predetermined test environment;
Verifying the operation of the Autosa-based vehicle embedded software implemented to correspond to a predetermined test target function; and
If there is no abnormality as a result of the verification, including the step of mounting the vehicle embedded software on the target ECU,
Verification method of Autosa-based automotive embedded software.
According to paragraph 1,
The step of emulating RTE and BSW among the layers that make up Autosa for the vehicle embedded software that is the subject of verification according to a predetermined test environment is,
OSEK is driven based on a POSIX-based operating system interface operated on a PC in the predetermined test environment, and the Autosa is driven based on the API of the OSEK,
Verification method of Autosa-based automotive embedded software.
According to paragraph 2,
The step of emulating RTE and BSW among the layers that make up Autosa for the vehicle embedded software that is the subject of verification according to a predetermined test environment is,
Characterized in that FMI is supported in BSW among the Autosa layers,
Verification method of Autosa-based automotive embedded software.
According to clause 3,
The step of emulating RTE and BSW among the layers that make up Autosa for the vehicle embedded software that is the subject of verification according to a predetermined test environment is,
Including creating an Autosa communication stack in the BSW,
The step of creating an Autosa communication stack in the BSW is,
Configuring a COM module to transmit data received from the RTE to a PduR module in the form of a PDU;
Constructing a PduR module that transmits data received from the COM module to the CANIF_FMU module or transmits data received from the CANIF_FMU module to the COM module;
Configuring a CANIF_FMU module that selects an internal channel based on the PDU identifier and delivers the PDU to a Hardware Object Handle (HOH) connected to each channel; and
Comprising the step of configuring a CAN module that records the PDU delivered through the CANIF_FMU module to a hardware object of the CAN control unit,
Verification method of Autosa-based automotive embedded software.
According to clause 4,
The CANIF_FMU module calls the FMU write function to convert the data in the PDU format into FMU format and transmits it to the CAN module,
The CAN module calls a reception indicator function with the CANIF_FMU module to generate an interrupt regarding reception of data in the FMU format, and the CANIF_FMU module converts the data converted to the FMU format into data in the PDU format and transmits the data to the PduR. Passing it as a module,
Verification method of Autosa-based automotive embedded software.
According to paragraph 3,
The step of creating an Autosa communication stack in the BSW is,
Constructing a socket module that provides a socket function from a certain manufacturer to support a CAN network with the CAN module;
Constructing a CAN library module provided between the socket module and the CAN module to simulate a data communication environment on a CAN-based hardware interface; and
Including the step of configuring a socket adapter module that supports TCP/IP-based data communication in an environment where the CAN-based hardware interface is not provided.
Verification method of Autosa-based automotive embedded software.
In the method of generating embedded software for vehicles based on Autosa,
Comprising the step of emulating RTE and BSW among the layers constituting Autosa for the vehicle embedded software according to a predetermined test environment,
Characterized in that FMI is supported in BSW among the Autosa layers,
How to create embedded software for vehicles based on Autosa.
In clause 7,
The step of emulating RTE and BSW among the layers that make up Autosa for the automotive embedded software according to a predetermined test environment is,
Including creating an Autosa communication stack including a COM module, a PduR module, a CANIF_FMU module, and a CAN module in the BSW,
How to create embedded software for vehicles based on Autosa.
According to clause 8,
The step of creating an Autosa communication stack including the COM module, PduR module, CANIF_FMU module, and CAN module in the BSW is,
Configuring a COM module to transmit data received from the RTE to a PduR module in the form of a PDU;
Constructing a PduR module that transmits data received from the COM module to the CANIF_FMU module or transmits data received from the CANIF_FMU module to the COM module;
Configuring a CANIF_FMU module that selects an internal channel based on the PDU identifier and delivers the PDU to a Hardware Object Handle (HOH) connected to each channel; and
Comprising the step of configuring a CAN module that records the PDU delivered through the CANIF_FMU module to a hardware object of the CAN control unit,
How to create embedded software for vehicles based on Autosa.

Images