Virtual ECU diagnosis method using communication protocol bridge, and device and system therefor

Abstract

A virtual electronic control unit (ECU) verification system according to an aspect of the present invention may comprise: a first apparatus equipped with software for a virtual ECU and generating an IP packet including an ECU frame corresponding to an in-vehicle communication protocol supported by the virtual ECU; a second apparatus equipped with server software and generating the IP packet including a user datagram protocol (UDP) frame; and a third apparatus connected to the first apparatus and the second apparatus through Ethernet and performing communication protocol conversion between the first apparatus and the second apparatus by using mounted communication protocol conversion software when the IP packet is received through the Ethernet.

Description

Virtual ECU diagnostic method using a communication protocol bridge and device and system for the same

[0001] The present invention relates to a vehicle controller software diagnostic technology, and more specifically, to a technology for verifying a Virtual Electronic Control Unit (VCU) by utilizing communication protocol bridge software without using a separate physical converter.

[0002] SIL stands for 'Software In the Loop,' a method of testing and verifying code in a simulation environment to improve software quality. In other words, SIL is a method that allows for the rapid and cost-effective identification and correction of errors within software. Generally, SIL testing is performed during the early stages of the software development process, whereas the more complex and costly HIL—or 'Hardware In the Loop'—testing is conducted in the later stages by installing the software on actual target hardware.

[0003] Recently, SIL is gaining importance in the automotive industry as automotive OEMs shift their development direction toward Software Defined Vehicles (SDVs), which implement vehicle functions through software.

[0004] Vehicle software consists of hundreds of millions of lines of code, and companies developing applications for the automotive industry must periodically perform builds and tests in accordance with the latest software development principles: CI (Continuous Integration), CD (Continuous Deployment), and CT (Continuous Test).

[0005] However, as shown in FIG. 1, the conventional SIL test environment for verifying software of a virtual vehicle ECU (Electric Control Unit) had the inconvenience of requiring a hardware converter—e.g., a CAN-USB converter—for converting to the communication protocol of the ECU—e.g., a CAN (Controller Area Network) communication protocol—and a specific cable for physical connection between the PCs and the hardware converter in order to create a test environment between a server PC and a client PC equipped with a virtual ECU.

[0006] Replacing and installing corresponding hardware converters and cables according to the communication protocols supported by the ECU under test was inefficient in terms of time and cost.

[0007] The object of the present disclosure is to provide a virtual ECU diagnostic method using a communication protocol bridge, and an apparatus and system for the same.

[0008] Another objective of the present disclosure is to provide a virtual ECU diagnostic method using a communication protocol bridge capable of adaptively converting the communication protocol between a server and a client according to the communication protocol type of the ECU to be diagnosed for SIL testing, and an apparatus and system for the same.

[0009] Another objective of the present disclosure is to provide a software-based communication protocol bridge that enables SIL testing for various ECUs via Ethernet communication alone, without using a separate hardware converter for communication protocol conversion and a dedicated cable corresponding to the communication protocol.

[0010] Another objective of the present disclosure is to provide a cloud server equipped with a communication protocol bridge function that enables software diagnosis through interaction with a virtual ECU in a cloud environment.

[0011] The technical problems of the present invention are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art from the description below.

[0012] The technical problems to be solved by the present invention are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art to which the present invention belongs from the description below.

[0013] A virtual ECU verification system according to one aspect of the present invention may include a first device equipped with software for a virtual ECU (Electronic Control Unit) to generate an IP packet containing an ECU frame corresponding to a vehicle internal communication protocol supported by the virtual ECU, a second device equipped with server software to generate the IP packet containing a UDP (User Datagram Protocol) frame, and a third device connected to the first device and the second device via Ethernet, and performing a communication protocol conversion between the first device and the second device using installed communication protocol conversion software when the IP packet is received via the Ethernet.

[0014] As an example, the vehicle internal communication protocol may include at least one of a CAN (Controller Area Network) communication protocol, a LIN (Local Interconnect Network) communication protocol, and a FlexRay communication protocol.

[0015] In an exemplary embodiment, the third device may determine an operating mode and identify a related ECU type through data interpretation of the received IP packet, and perform a communication protocol conversion based on the determined operating mode and the identified ECU type.

[0016] In an exemplary embodiment, the third device may include means for creating a UDP socket, means for receiving a UDP frame through the UDP socket based on the determined operating mode being a client mode, means for creating an ECU socket by identifying the vehicle internal communication protocol corresponding to the identified ECU type, means for converting the received UDP frame into the identified vehicle internal communication protocol frame, and means for transmitting the converted vehicle internal communication protocol frame to the second device by embedding it in an IP packet through the created ECU socket.

[0017] In an exemplary embodiment, the third device may further include means for receiving an ECU frame through the ECU socket based on the fact that the determined operating mode is a server mode, means for converting the received ECU frame into a UDP frame, and means for transmitting the converted UDP frame to the first device by placing it in the IP packet through the UDP socket.

[0018] In an exemplary embodiment, the operation mode may be determined based on at least one of the source address and destination address of the received IP packet.

[0019] As an example, the ECU type can be identified based on the ID field value of the ECU frame included in the received IP packet.

[0020] As an example of an embodiment, the first device and the second device can be connected to the second device through a direct Ethernet cable.

[0021] In an exemplary embodiment, the first device and the second device are connected to the second device via an internet network, and the second device can be implemented as a cloud server.

[0022] A method in a device for transmitting and receiving IP packets between a server device and a client device via Ethernet according to another aspect of the present disclosure comprises the steps of receiving the IP packet via the Ethernet, determining an operating mode based on address information included in the received IP packet, identifying an Electronic Control Unit (ECU) type through data interpretation included in the received IP packet, performing a communication protocol conversion between the first device and the second device based on the determined operating mode and the identified ECU type, and transmitting the IP packet converted to the communication protocol, wherein the operating mode includes a client mode and a server mode, and when the determined operating mode is the client mode, a UDP frame included in the received IP packet is converted into a vehicle internal communication protocol frame corresponding to the identified ECU type, and when the determined operating mode is the server mode, a vehicle internal communication protocol frame corresponding to the identified ECU type included in the received IP packet can be converted into the UDP frame.

[0023] The effects obtainable from various embodiments are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description below.

[0024] The present invention has the advantage of providing a virtual ECU diagnostic method using a communication protocol bridge, and a device and system for the same.

[0025] In addition, the present invention has the advantage of providing a virtual ECU diagnostic method using a communication protocol bridge capable of adaptively automatically converting the communication protocol between a server and a client according to the communication protocol type of the ECU to be diagnosed for SIL testing, as well as a device and system for the same.

[0026] In addition, the present invention has the advantage of providing a software-based communication protocol bridge that enables SIL testing for various ECUs through Ethernet communication alone, without using a separate hardware converter for communication protocol conversion or a dedicated cable corresponding to the communication protocol.

[0027] In addition, the present invention has the advantage of providing a cloud server equipped with a communication protocol bridge function that enables software diagnosis through linkage with a virtual ECU in a cloud environment.

[0028] The drawings attached to this specification are intended to provide an understanding of the present invention, to illustrate various embodiments of the invention, and to explain the principles of the invention together with the description in the specification.

[0029] Figure 1 is a diagram illustrating a SIL test environment for a virtual vehicle ECU according to the prior art.

[0030] FIG. 2 is a diagram illustrating a SIL test environment for a virtual vehicle ECU based on a direct Ethernet connection according to an embodiment of the present invention.

[0031] FIG. 3 is a diagram illustrating a cloud-based virtual vehicle ECU SIL test environment according to an embodiment of the present invention.

[0032] FIG. 4 is a block diagram illustrating the structure of a test device or cloud server that provides a CAN-Ethernet bridge function for SIL testing according to an embodiment of the present invention.

[0033] FIG. 5 is a flowchart for explaining the operation in a test device or cloud server that provides a CAN-Ethernet bridge function according to an embodiment of the present invention.

[0034] FIG. 6 is a block diagram illustrating the structure of a test device or cloud server that provides a bridge function for a plurality of vehicle communication protocols for SIL testing according to an embodiment of the present invention.

[0035] FIGS. 7 and 8 are flowcharts for explaining the operation of the test device or cloud server of FIG. 6.

[0036] FIG. 9 shows a vehicle internal communication protocol frame format according to an embodiment of the present invention.

[0037] FIG. 10 illustrates a computing device according to an embodiment of the present invention.

[0038] A first device equipped with software for a virtual ECU (Electronic Control Unit) and generating an IP packet containing an ECU frame corresponding to a vehicle internal communication protocol supported by the virtual ECU;

[0039] A second device equipped with server software that generates the above IP packet containing a UDP (User Datagram Protocol) frame; and

[0040] A third device connected to the first device and the second device via Ethernet, and which performs a communication protocol conversion between the first device and the second device using installed communication protocol conversion software when the IP packet is received via the Ethernet.

[0041] A virtual ECU verification system including

[0042] Hereinafter, a communication protocol bridge-based virtual ECU diagnostic method and an apparatus and system for the same according to the present disclosure will be described in detail with reference to FIGS. 2 to 10.

[0043] FIG. 2 is a diagram illustrating a SIL test environment for a virtual electronic control unit (vECU) based on a direct Ethernet connection according to an embodiment of the present invention.

[0044] Referring to FIG. 2, the SIL test system (200) for a virtual ECU may be configured to include a first test device (210) operating in server mode, a second test device (220) operating in client mode, and a third test device (230) that performs a communication protocol bridge function between the first test device (210) and the second test device (220).

[0045] As shown in FIG. 2, the third test device (230) can be connected to the first test device (210) and the second test device (220) via a direct Ethernet cable.

[0046] The first test device (210) may be equipped with server software that supports UDP (User Datagram Protocol) communication, and the second test device (220) may be equipped with virtual ECU software that supports CAN communication protocol.

[0047] The third test device (230) may be equipped with CAN-Ethernet bridge software.

[0048] According to the embodiment, the third test device (230) can automatically convert a CAN frame received from the second test device (220) via Ethernet communication in client mode into a UDP frame, and then transmit the converted UDP frame to the first test device (210) via Ethernet communication.

[0049] According to the embodiment, the third test device (230) can automatically convert a UDP frame received from the first test device (210) via Ethernet communication in server mode into a CAN frame, and then transmit the converted CAN frame to the second test device (220) via Ethernet communication.

[0050] In the example of normal implementation, the packet conversion method in client mode and server mode will become clearer through the description of the drawings to be described later.

[0051] As described in Figure 2 above, the present invention has the advantage of providing a SIL test environment for virtual ECU software that supports the CAN communication protocol by providing a CAN-Ethernet bridge function through Ethernet communication only, without using a separate physical (or hardware) converter for communication protocol conversion and a dedicated cable corresponding to the communication protocol.

[0052] The first to third test devices (210 to 230) according to the embodiment may each be a PC, but this is merely one embodiment, and at least one of the first to third test devices (210 to 230) according to other embodiments may be implemented in the form of a software-embedded test board.

[0053] Unlike IP communication, where data is exchanged based on node addresses, the CAN communication protocol assigns an identifier (ID) according to the priority of the message and uses this ID to distinguish messages. In other words, if any node A on the CAN bus transmits a message, the remaining nodes, excluding A, determine whether the message transmitted by A is necessary for them based on the ID included in the CAN signal; if it is necessary, they accept it, and if not, they ignore the signal.

[0054] FIG. 3 is a diagram illustrating a cloud-based virtual vehicle ECU SIL test environment according to an embodiment of the present invention.

[0055] Referring to FIG. 3, the SIL test system (300) for a virtual vehicle ECU may be configured to include a first test device (310) operating in server mode, a second test device (320) operating in client mode, and a cloud server (330) that performs a communication protocol bridge function between the first test device (310) and the second test device (320).

[0056] As illustrated in FIG. 3, the cloud server (330) can be connected to the first test device (310) and the second test device (320) via the internet network (340).

[0057] The first test device (310) may be equipped with server software that supports UDP (User Data Protocol), and the second test device (320) may be equipped with virtual ECU software that supports CAN communication protocol.

[0058] The cloud server (330) can be equipped with CAN-Ethernet bridge software.

[0059] According to the embodiment, the cloud server (330) can convert a CAN frame received from the second test device (220) via Ethernet communication in client mode into a UDP frame, and then transmit the converted UDP frame to the first test device (310) via Ethernet communication.

[0060] According to the embodiment, the cloud server (330) can convert a UDP frame received from the first test device (310) into a CAN frame via Ethernet communication in server mode, and then transmit the converted CAN frame to the second test device (320) via Ethernet communication.

[0061] In the example of normal implementation, the packet conversion method in client mode and server mode will become clearer through the description of the drawings to be described later.

[0062] As described in Figure 3 above, the present invention has the advantage of providing a SIL test environment for virtual ECU software that supports the CAN communication protocol by providing a CAN-Ethernet bridge function through the internet in a cloud environment without using a separate physical (or hardware) converter for communication protocol conversion and a dedicated cable corresponding to the communication protocol.

[0063] The first and second test devices (310 to 330) according to the embodiment may each be a PC or a laptop, but this is merely one embodiment, and at least one of the first and second test devices (310 to 320) according to other embodiments may be implemented in the form of a software-embedded test board.

[0064] FIG. 4 is a block diagram illustrating the structure of a test device or cloud server that provides a CAN-Ethernet bridge function for SIL testing according to an embodiment of the present invention.

[0065] Referring to FIG. 4, the third test device (230) or cloud server (330) may be configured to include a packet receiving unit (410), an operation mode identification unit (420), a socket control unit (430), a packet generating unit (440), and a packet transmitting unit (450).

[0066] The packet receiving unit (410) can receive IP packets via Ethernet communication.

[0067] The operation mode identification unit (420) can determine whether the IP packet was received from a client device (or transmitted to a server device) or received from a server device (or transmitted to a client device) based on the source address (or destination address) of the received IP packet.

[0068] The operation mode identification unit (420) can determine the operation mode to be client mode when an IP packet is received from a client device (or transmitted to a server device), and determine the operation mode to be server mode when an IP packet is received from a server device (or transmitted to a client device). Here, the payload of the IP packet received in client mode may include a CAN frame, and the payload of the IP packet received in server mode may include a UDP frame.

[0069] The socket control unit (430) may be configured to include a CAN socket unit (431) that creates and releases a socket for CAN communication and a UDP socket unit (432) that creates and releases a socket for UDP communication.

[0070] The CAN socket section (431) can create a CAN socket for transmitting CAN frames and bind the CAN interface, and when the application ends, it can close the created CAN socket and release the binding.

[0071] The UDP socket unit (432) can create a UDP socket for transmitting UDP frames, bind a UDP interface, and close the created UDP socket and release the binding when the application terminates.

[0072] The packet generation unit (441) may be configured to include a verification unit (441) and a conversion unit (442).

[0073] The verification unit (441) can determine whether the IP packet is a valid packet based on the size (or length) of the CAN frame or UDP frame included in the payload of the received IP packet. If the result of the determination is that it is not valid, the verification unit (441) can control the output of a predetermined error message. According to the embodiment, the verification unit (441) can output a predetermined error message if the size of the CAN frame or UDP frame is less than 0.

[0074] The conversion unit (442) can convert the format of a packet according to the operation mode identified by the operation mode identification unit (210) if the verification result of the verification unit (441) is that the packet is valid. For example, the conversion unit (442) can convert a CAN frame into a UDP frame when the operation mode is client mode, and convert a UDP frame into a CAN frame when the operation mode is server mode. Here, the format conversion may include conversion of header information and data. Here, the header may include an identifier (ID) field, a data length field, etc.

[0075] When packet conversion is completed, the packet transmission unit (450) can transmit the converted packet through a socket created corresponding to the converted packet. For example, when the packet transmission unit (450) is in client mode, it can transmit the converted UDP frame to the server device by putting it in an IP packet through a UDP socket, and when the server mode, it can transmit the CAN frame to the client device by putting it in an IP packet through a CAN socket.

[0076] FIG. 5 is a flowchart for explaining the operation in a test device or cloud server that provides a CAN-Ethernet bridge function according to an embodiment of the present invention.

[0077] Below, we will explain an example where a cloud server performs the CAN-Ethernet bridge function.

[0078] Referring to FIG. 5, when a CAN-Ethernet bridge application is executed, the cloud server (330) can initialize parameter values ​​to be used in the CAN-Ethernet bridge application (S510).

[0079] The cloud server (330) can create a socket for CAN communication and bind it to a CAN interface (S520). Here, binding means the process of connecting a specific socket to a specific network to enable data transmission and reception on that network.

[0080] When IP packet data is received and input via Ethernet communication, the cloud server (330) can determine the operating mode by identifying whether the destination of the IP packet is a client device or a server device based on the received IP packet data (S530).

[0081] Here, if the destination address of the IP packet is a client device, the operation mode is determined to be client mode, and if it is a server device, the operation mode is determined to be server mode; however, this is merely one example, and the operation mode may be determined through the source address or other data interpretation of the IP packet.

[0082] The cloud server (330) creates a UDP socket and performs the specified IP address and port settings, and in client mode, receives a UDP frame (or UDP data) included in the received IP packet through the UDP socket, and in server mode, receives a CAN frame (or CAN data) included in the received IP packet through the CAN socket (S540 to S550).

[0083] The cloud server (330) checks whether the data size of the received frame is valid, and if it is valid, adaptively performs frame conversion according to the operation mode and transmits the converted frame through a socket corresponding to the type of the frame after conversion (S560 to S570). For example, the cloud server (330) may determine that the frame is valid if the data size of the received frame is greater than 0, and determine that it is invalid otherwise. If the operation mode is client mode, the cloud server (330) converts the UDP frame into a CAN frame and transmits the converted CAN frame through a CAN socket, and if the operation mode is server mode, it converts the CAN frame into a UDP frame and transmits the converted UDP frame through a UDP socket. If the data size of the received frame is invalid, the cloud server (330) may terminate the process.

[0084] As an example, in client mode, frame conversion can be performed by determining the CAN ID and CAN data portion of a CAN frame through data interpretation of a received UDP frame, and then calculating a Data Length Code (DLC) value corresponding to the determined CAN data portion. Subsequently, a CAN frame can be generated based on the CAN ID, DLC, and CAN data.

[0085] As an example, in server mode, frame conversion can be performed by copying the values ​​of the CAN ID field, DLC field, and data field of the received CAN frame into the data field of the UDP frame to generate a UDP frame.

[0086] In step 570 above, the cloud server (330) can check whether the transmission is successful, and if the application terminates after the transmission is successful, it can close all created sockets and terminate the process (S580 to S590).

[0087] If transmission fails in step 580 above, the process may be terminated after outputting a predetermined transmission failure message.

[0088] FIG. 6 is a block diagram illustrating the structure of the third test device or cloud server of FIG. 2 to 4, which provides a bridge function for a plurality of vehicle communication protocols for SIL testing according to an embodiment of the present invention.

[0089] In the above-described embodiment, a CAN-Ethernet bridge function for SIL testing of an ECU supporting a CAN communication protocol was described as an example, but this is merely one embodiment, and a third test device (230) or cloud server (330) according to another embodiment may be implemented to adaptively provide a bridge function for multiple vehicle communication protocols.

[0090] Referring to FIG. 6, the third test device (230) or cloud server (330) may be configured to include a packet receiving unit (610), an operation mode identification unit (620), an ECU communication protocol identification unit (630), a socket control unit (640), a packet generating unit (650), and a packet transmitting unit (660).

[0091] The packet receiving unit (610) can receive IP packets via Ethernet communication.

[0092] The operation mode identification unit (620) can determine whether the IP packet was received from a client device (or transmitted to a client device) or received from a server device (or transmitted to a server device) based on the source (or destination) address of the received IP packet.

[0093] The operation mode identification unit (420) can determine the operation mode to be client mode when an IP packet is received from a client device (or transmitted to a server device), and determine the operation mode to be server mode when an IP packet is received from a server device (or transmitted to a client device). Here, the payload of the IP packet received in client mode may include a frame generated by the virtual ECU, and the payload of the IP packet received in server mode may include a UDP frame generated by the server.

[0094] The ECU communication protocol identification unit (630) can identify the relevant ECU type through data interpretation of the received IP packet and identify the vehicle internal communication protocol corresponding to the identified ECU type. Here, the vehicle internal communication protocol may include the CAN communication protocol, the LIN (Local Interconnect Network) communication protocol, and the FlexRay communication protocol, but is not limited thereto, and more or fewer vehicle internal communication protocols may be defined depending on the design of a person skilled in the art and the options and specifications of the target vehicle.

[0095] The socket control unit (640) may be configured to include a CAN socket unit (641) for creating and releasing sockets for CAN communication, a LIN socket unit (642) for creating and releasing sockets for LIN communication, a FlexRay socket unit (643) for creating and releasing sockets for FlexRay communication, and a UDP socket unit (644) for creating and releasing sockets for UDP communication.

[0096] The CAN socket section (641) can create a CAN socket for transmitting CAN frames and bind a CAN interface, and when the application ends, it can close the created CAN socket and release the binding.

[0097] The LIN socket section (642) can create a LIN socket for transmitting LIN frames and bind the LIN interface, and when the application ends, it can close the created LIN socket and release the binding.

[0098] The FlexRay socket section (643) can create a FlexRay socket for transmitting FlexRay frames, bind a FlexRay interface, and close the created FlexRay socket and release the binding when the application ends.

[0099] The UDP socket section (644) creates a UDP socket for transmitting UDP frames and binds the UDP interface, and when the application terminates, it can close the created UDP socket and release the binding.

[0100] The packet generation unit (650) may be configured to include a verification unit (651) and a conversion unit (652).

[0101] The verification unit (651) can determine whether the IP packet is a valid packet based on the size (or length) of the ECU frame or UDP frame included in the payload of the received IP packet. If the result of the determination is that it is not valid, the verification unit (651) can control the output of a predetermined error message. According to the embodiment, if the size of the ECU frame or UDP frame is less than 0, the verification unit (651) can determine that the IP packet is invalid and output a predetermined error message.

[0102] The conversion unit (652) can convert the frame format included in the packet according to the operation mode and ECU communication protocol type identified by the operation mode identification unit (620) when the verification result of the verification unit (651) is that the packet is valid. For example, the conversion unit (652) can convert a CAN frame into a UDP frame when the operation mode is client mode and the identified ECU communication protocol type is CAN, and can convert a UDP frame into a CAN frame when the identified operation mode is server mode and the identified communication protocol type is CAN. For another example, the conversion unit (652) can convert a LIN frame into a UDP frame when the operation mode is client mode and the identified ECU communication protocol type is LIN, and can convert a UDP frame into a LIN frame when the identified operation mode is server mode and the identified communication protocol type is LIN. As another example, the conversion unit (652) can convert a FlexRay frame into a UDP frame when the operation mode is client mode and the identified ECU communication protocol type is FlexRay, and convert a UDP frame into a FlexRay frame when the identified operation mode is server mode and the identified communication protocol type is FlexRay. Here, the format conversion may include conversion of the header field and / or data (or payload) of the frame. Here, the header field may include an identifier (ID) field, a data length field, etc., but is not limited thereto.

[0103] When frame conversion is completed, the packet transmission unit (660) can transmit the converted frame through a socket created corresponding to the converted frame. For example, if the packet transmission unit (660) is in client mode and the supported communication protocol of the corresponding ECU is CAN, the converted UDP frame can be transmitted to a server device by being loaded into an IP packet through a UDP socket. For another example, if the packet transmission unit (660) is in server mode and the communication protocol corresponding to the corresponding ECU is LIN, the LIN frame can be transmitted to a client device by being loaded into an IP packet through a LIN socket.

[0104] FIGS. 7 and 8 are flowcharts for explaining the operation of the third test device or cloud server of FIG. 6.

[0105] The following describes the method performed by a cloud server.

[0106] Referring to FIG. 7, the cloud server (330) can receive IP packets through the internet network (340) (S710).

[0107] The cloud server (330) can determine the operating mode by interpreting the data of the received IP packet (S720).

[0108] If the determined operation mode is client mode, the cloud server (330) can identify the ECU type associated with the received IP packet by interpreting the data of the received IP packet and identify the communication protocol corresponding to the identified ECU type (S730).

[0109] As a result of identification, if the communication protocol corresponding to the ECU is CAN, as illustrated in drawing number S740, the cloud server (330) can create UDP and CAN sockets and bind them to their respective corresponding network interfaces, and determine whether the IP packet is valid by checking the data size of the UDP frame received through the created UDP socket. If the IP packet is valid, the cloud server (330) can convert the UDP frame into a CAN frame and then transmit the converted CAN frame through the CAN socket.

[0110] If, as a result of the identification in step 730 above, the communication protocol corresponding to the ECU is LIN, the cloud server (330), as illustrated in drawing number S750, creates UDP and LIN sockets and binds them to their respective corresponding network interfaces, and can determine whether the corresponding IP packet is valid by checking the data size of the UDP frame received through the created UDP socket. If the IP packet is valid, the cloud server (330) can convert the UDP frame into a LIN frame and then transmit the converted LIN frame through the LIN socket. Here, if the IP packet is invalid, the process can be terminated after outputting a predetermined error message.

[0111] If, as a result of the identification in step 730 above, the communication protocol corresponding to the ECU is FlexRay, the cloud server (330), as illustrated in drawing number S760, creates UDP and FlexRay sockets and binds them to their respective corresponding network interfaces, and can determine whether the IP packet is valid by checking the data size of the UDP frame received through the created UDP socket. If the IP packet is valid, the cloud server (330) can convert the UDP frame into a FlexRay frame and then transmit the converted FlexRay frame through the FlexRay socket.

[0112] Below, the operation of the cloud server (330) when the operation mode determined in step 720 above is server mode will be explained with reference to FIG. 8.

[0113] The cloud server (330) can identify the ECU type associated with the received IP packet through data interpretation of the received IP packet and identify the communication protocol corresponding to the identified ECU type (S810).

[0114] As a result of identification, if the communication protocol corresponding to the ECU is CAN, as illustrated in drawing number S820, the cloud server (330) can create UDP and CAN sockets and bind them to their respective corresponding network interfaces, and determine whether the IP packet is valid by checking the data size of the CAN frame received through the created CAN socket. If the IP packet is valid, the cloud server (330) can convert the CAN frame into a UDP frame and then transmit the converted UDP frame through the UDP socket.

[0115] If, as a result of the identification in step 810 above, the communication protocol corresponding to the ECU is LIN, the cloud server (330), as illustrated in drawing number S830, creates UDP and LIN sockets and binds them to their respective corresponding network interfaces, and can determine whether the corresponding IP packet is valid by checking the data size of the CAN frame received through the created CAN socket. If the IP packet is valid, the cloud server (330) can convert the CAN frame into a UDP frame and then transmit the converted UDP frame through the UDP socket. Here, if the IP packet is invalid, the process can be terminated after outputting a predetermined error message.

[0116] If, as a result of the identification in step 730 above, the communication protocol corresponding to the ECU is FlexRay, the cloud server (330), as illustrated in drawing number S840, creates UDP and FlexRay sockets and binds them to their respective corresponding network interfaces, and can determine whether the corresponding IP packet is valid by checking the data size of the FlexRay frame received through the created FlexRay socket. If the IP packet is valid, the cloud server (330) can convert the FlexRay frame into a UDP frame and then transmit the converted UDP frame through the UDP socket.

[0117] As described in Figures 6 to 8 above, the present invention has the advantage of enabling adaptive online software diagnosis for various types of ECUs through a single verification platform by providing a communication protocol bridge through a cloud environment that can adaptively convert the communication protocol between a server and a client according to the communication protocol type of the ECU to be diagnosed for SIL testing.

[0118] FIG. 9 shows the frame format of an in-vehicle communication protocol according to an embodiment of the present invention.

[0119] Referring to FIG. 9, drawing number 910 is a CAN communication protocol frame format, drawing number 920 is a LIN communication protocol frame format, and drawing number 930 is a FlexRay communication protocol frame format.

[0120] All in-vehicle communication protocols include an ID field (911, 921, 931) to uniquely identify the frame.

[0121] A third test device (230) or cloud server (330) according to the present invention can extract an ID value of an ECU frame included in the payload of an IP packet received via Ethernet, and identify which vehicle internal communication protocol the ECU frame belongs to based on the extracted ID value.

[0122] FIG. 10 illustrates a computing device according to an embodiment of the present invention.

[0123] Referring to FIG. 10, a computing device (1000) may be configured to include at least one of a processor (1020), memory (1030), a user interface input device (1040), a user interface output device (1050), storage (1060), and a network interface (1070) connected via a bus (1010). The network interface (1070) according to the embodiment may include an Ethernet communication interface.

[0124] The processor (1020) may be a semiconductor device that executes processing on instructions stored in a central processing unit (CPU) or memory (1030) and / or storage (1060). The memory (1030) and storage (1060) may include various types of volatile or non-volatile storage media. For example, the memory (1030) may include ROM (Read Only Memory, 1031) and RAM (Random Access Memory, 1032).

[0125] Accordingly, steps of the method (or procedure) or algorithm described in relation to the embodiments disclosed in this specification may be directly implemented in hardware, software modules, or a combination of both, executed by the processor (1020). The software modules may reside in storage media such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs (i.e., memory (1030) and / or storage (1060)).

[0126] An exemplary storage medium is coupled to a processor (1020), and the processor (1020) can read information from the storage medium and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor (1020). The processor and the storage medium may reside within an application-specific integrated circuit (ASIC). The ASIC may reside in a test device—e.g., a PC or laptop—or a cloud server that provides software bridging functions for at least one in-vehicle communication protocol. Alternatively, the processor (1020) and the storage medium may reside in a cloud server or as individual components on a PC (or test board).

[0127] The present invention described above can be implemented as computer-readable code on a medium on which a program is recorded. A computer-readable medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include HDD (Hard Disk Drive), SSD (Solid State Disk), SSD (Silicon Disk Drive), ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc., and also include implementation in the form of a carrier wave (e.g., transmission over the Internet).

[0128] The present invention has the advantage of being able to provide a cost-effective SIL test environment for virtual ECU software verification.

Claims

1. A first device equipped with software for a virtual ECU (Electronic Control Unit) that generates an IP packet containing an ECU frame corresponding to a vehicle internal communication protocol supported by the virtual ECU; A second device equipped with server software that generates the above IP packet containing a UDP (User Datagram Protocol) frame; and A third device connected to the first device and the second device via Ethernet, and which performs a communication protocol conversion between the first device and the second device using installed communication protocol conversion software when the IP packet is received via the Ethernet. A virtual ECU verification system including 2. In Paragraph 1, The above vehicle internal communication protocol is a virtual ECU verification system comprising at least one of a CAN (Controller Area Network) communication protocol, a LIN (Local Interconnect Network) communication protocol, and a FlexRay communication protocol.

3. In Paragraph 2, A virtual ECU verification system in which the third device performs determination of an operating mode and identification of a related ECU type through data interpretation of the received IP packet, and performs communication protocol conversion based on the determined operating mode and the identified ECU type.

4. In Paragraph 3, The above third device Means for creating a UDP socket; Means for receiving the UDP frame through the UDP socket based on the fact that the above-determined operation mode is client mode; Means for generating an ECU socket by identifying the vehicle internal communication protocol corresponding to the identified ECU type; Means for converting the received UDP frame into the identified vehicle internal communication protocol frame; and Means for transmitting the above-described converted vehicle internal communication protocol frame to the second device by loading it onto the IP packet through the generated ECU socket. A virtual ECU verification system including 5. In Paragraph 4, The above third device Means for receiving an ECU frame through the ECU socket based on the fact that the above-determined operation mode is a server mode; Means for converting the received ECU frame into the UDP frame; and Means for transmitting the above converted UDP frame to the first device by embedding it in the IP packet through the UDP socket. A virtual ECU verification system that further includes 6. In Paragraph 3, The above-described operation mode is a virtual ECU verification system determined based on at least one of the source address and destination address of the received IP packet.

7. In Paragraph 3, The above ECU type is a virtual ECU verification system identified based on the ID field value of the ECU frame included in the received IP packet.

8. In Paragraph 1, A virtual ECU verification system connected to the second device via a direct Ethernet cable with the first device and the second device.

9. In Paragraph 1, A virtual ECU verification system characterized in that the first device and the second device are connected to the second device via an internet network, and the second device is a cloud server.

10. A method in a device for transmitting and receiving IP packets between a server device and a client device via Ethernet, A step of receiving the IP packet through the Ethernet; A step of determining an operation mode based on address information included in the received IP packet; A step of identifying the type of ECU (Electronic Control Unit) through the interpretation of data included in the received IP packet; A step of performing a communication protocol conversion between the first device and the second device based on the above-determined operating mode and the above-identified ECU type; and Step of transmitting an IP packet converted to the above communication protocol A method comprising, wherein the operation mode includes a client mode and a server mode, wherein if the determined operation mode is the client mode, a UDP frame included in the received IP packet is converted into a vehicle internal communication protocol frame corresponding to the identified ECU type, and if the determined operation mode is the server mode, a vehicle internal communication protocol frame corresponding to the identified ECU type included in the received IP packet is converted into the UDP frame.

Images