KR20150050990A - Method for packaging controller area networks packet and apparatuses using the same - Google Patents

Abstract

A vehicle-communication system includes an electronic control device which outputs a controller area network (CAN) packet, and a gateway which receives the CAN packet and packages the entire received CAN packet in the data field of an Ethernet packet.

Description

METHOD FOR PACKAGING CONTROLLER AREA NETWORKS PACKET AND APPARATUSES USING THE SAME [0002]

An embodiment according to the concept of the present invention relates to a method of packaging CAN packet (CAN packet), in particular packaging the entire CAN packet in a data field of an Ethernet packet And a device using the same.

Various subsystems ranging from subsystems related to convenience, safety and multimedia to powertrains for power transmission are controlled through a number of electronic control units.

Various control network technologies such as CAN communication, LIN (local interconnect network) communication, K-line communication, and FlexRay communication are used to control the plurality of electronic control devices.

CAN communication is the most widely used communication method as a standard interface standard of a vehicle LAN. The transmission speed of CAN communication uses a single channel at maximum 1Mbps. CAN communication is mainly used to control powertrain systems such as an engine or an automatic transmission, or to control a body system such as an automobile door or an air conditioner. In addition to automobiles, CAN communication is used in a variety of industrial fields such as factory automation, ships, medical equipment, and industrial equipment.

LIN communication is a low-cost serial bus communication protocol and is mainly applied to a subsystem for providing convenience functions inside a vehicle. The transmission speed of LIN communication is up to 20kbps.

FlexRay communication is used when higher communication reliability is required than CAN communication or LIN communication, or when faster message transmission speed is required. Therefore, FlexRay communication can be applied not only to subsystems implemented using CAN communication or LIN communication, but also to improved power train systems. FlexRay communication can provide high speed communication environment of up to 20Mbps using two 10Mbps communication channels.

However, as the number of electronic control devices required for automobiles and the amount of control signals increase, communication complexity inside the vehicle is rapidly increasing. Therefore, there is a demand for an in-vehicle communication system that can cope with an increasing communication complexity (i.e., communication bandwidth).

SUMMARY OF THE INVENTION It is a technical object of the present invention to provide a method of packaging an entire CAN packet into a data field of an Ethernet packet and devices using the same.

A method of packaging a CAN packet according to an exemplary embodiment of the present invention includes the steps of: receiving a CAN packet (control area network (CAN) packet) sent from a gateway by a gateway; To a data field of an Ethernet packet.

According to an embodiment, after the step of packaging, the gateway may further comprise generating a remainder of the Ethernet packet except for the data field.

According to the embodiment, the entire CAN packet includes a start of frame (SOF), an identifier, a remote transmission request (RTR), an identifier extension (IDE), a reserved bit R0, a data length code (DLC) Data fields, cyclic redundancy check (CRC), acknowledge (ACK), end of frame (EOF), and inter frame space (IFS).

An in-vehicle communication system according to an embodiment of the present invention includes an electronic control device for outputting a CAN packet, and an electronic control device for receiving the CAN packet and transmitting all of the received CAN packet as an Ethernet packet And may include a gateway for packaging the data in a data field.

According to an embodiment, the gateway may package the entire CAN packet into the data field of the Ethernet packet, and then generate the remainder of the Ethernet packet, except for the data field.

According to an embodiment, the entire CAN packet includes a start of frame (SOF), an identifier, a remote transmission request (RTR), an identifier extension (IDE), a reserved bit R0, a data length code (DLC) A data field, a cyclic redundancy check (CRC), an acknowledge (ACK), an end of frame (EOF), and an inter frame space (IFS).

The method and apparatus according to the embodiment of the present invention have an effect of transmitting the CAN packet through the Ethernet communication network without complicated conversion process by packaging the entire CAN packet into the data field of the Ethernet packet.

In addition, the method and apparatus according to the embodiment of the present invention can effectively utilize an Ethernet-based central network having a wide bandwidth.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In order to more fully understand the drawings recited in the detailed description of the present invention, a detailed description of each drawing is provided.
1 is a block diagram of an in-vehicle communication system according to an embodiment of the present invention.
2 is a diagram for explaining a process of packaging a CAN packet into an Ethernet packet.
3 is a diagram for explaining a process of unpackaging a CAN packet packaged in an Ethernet packet.
4 is a diagram for explaining a process of packaging an LIN packet into an Ethernet packet.
5 is a diagram for explaining a process of unpacking an LIN packet packaged in an Ethernet packet.
6 is a diagram for explaining a process of packaging a K-LINE packet into an Ethernet packet.
7 is a diagram for explaining a process of unpacking a K-LINE packet packaged in an Ethernet packet.
8 is a diagram for explaining a process of packaging a FlexRay packet into an Ethernet packet.
9 is a diagram for explaining a process of unpackaging a FlexRay packet packaged in an Ethernet packet.
10 is a block diagram according to one embodiment of the gateway shown in FIG.
11 is a block diagram according to another embodiment of the gateway shown in Fig.
12 is a flowchart of a method of packaging another protocol packet into an Ethernet protocol packet according to an embodiment of the present invention.
13 is a flowchart of a method of unpackaging Ethernet protocol packets packed with other protocol packets according to an embodiment of the present invention.
FIG. 14 is a flowchart of a method for rearranging the transmission order of Ethernet protocol packets packed with other protocol packets according to an embodiment of the present invention.

It is to be understood that the specific structural or functional description of embodiments of the present invention disclosed herein is for illustrative purposes only and is not intended to limit the scope of the inventive concept But may be embodied in many different forms and is not limited to the embodiments set forth herein.

The embodiments according to the concept of the present invention can make various changes and can take various forms, so that the embodiments are illustrated in the drawings and described in detail herein. It should be understood, however, that it is not intended to limit the embodiments according to the concepts of the present invention to the particular forms disclosed, but includes all modifications, equivalents, or alternatives falling within the spirit and scope of the invention.

The terms first, second, etc. may be used to describe various elements, but the elements should not be limited by the terms. The terms may be named for the purpose of distinguishing one element from another, for example, without departing from the scope of the right according to the concept of the present invention, the first element may be referred to as a second element, The component may also be referred to as a first component.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between. Other expressions that describe the relationship between components, such as "between" and "between" or "neighboring to" and "directly adjacent to" should be interpreted as well.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, the terms "comprises" or "having" and the like are used to specify that there are features, numbers, steps, operations, elements, parts or combinations thereof described herein, But do not preclude the presence or addition of one or more other features, integers, steps, operations, components, parts, or combinations thereof.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the meaning of the context in the relevant art and, unless explicitly defined herein, are to be interpreted as ideal or overly formal Do not.

As used herein, a module may refer to a functional or structural combination of hardware to perform the method according to an embodiment of the present invention or software that can drive the hardware.

Accordingly, the module may mean a logical unit or a set of hardware resources capable of executing the program code and the program code, and does not necessarily mean a physically connected code or a kind of hardware.

In this specification, a packet can be broadly defined as a bundle of data that is handled as one unit by the transmitting side and the receiving side in data transmission, and may mean a concept including a frame. have.

1 is a block diagram of an in-vehicle communication system according to an embodiment of the present invention.

1, an in-vehicle communication system 10 includes electronic gateways 100, 200 and 300 and electronic control devices (not shown) connected to a plurality of gateways 100, 200 and 300, respectively electronic control units 110, 210, and 310, respectively.

The in-vehicle communication system 10 may have an ethernet-based central network. That is, the gateways 100, 200, and 300 constituting the central network of the in-vehicle communication system 10 can communicate with each other using Ethernet communication.

Speed communication system can be realized by allowing the central network of the in-vehicle communication system 10 to use the Ethernet communication in that the Ethernet communication can have a bandwidth of 100 Mbps to 1000 Mbps.

1, the case where the gateways 100, 200, and 300 of the in-vehicle communication system 10 constitute a bus-type network has been described, but the present invention is not limited thereto.

In accordance with the embodiment, the gateways 100, 200, and 300 of the in-vehicle communication system 10 may comprise various types of networks in the form of a ring, a star, or a tree .

Each of the gateways 100, 200, and 300 may relay the communication between the electronic control devices 110, 210, and 310 based on the Ethernet communication.

That is, each of the gateways 100, 200, and 300 may transmit packets of other protocols other than Ethernet transmitted from the electronic control devices 110, 210, and 310, such as CAN packet, LIN packet, K- Packets and so on. Each of the gateways 100, 200, and 300 may package packets of another received protocol into an Ethernet packet. The gateways 100, 200, and 300 can exchange Ethernet packets with the packets of the other protocol packaged using Ethernet communication.

In addition, each of the gateways 100, 200, and 300 may un-package the packet of the other protocol packaged in the received Ethernet packet. Packets of the other protocol that are unpackaged may be transmitted to each of the electronic control devices 110, 210, and 310 that communicate with each of the gateways 100, 200, and 300.

The gateways 100, 200, and 300 may communicate with each other in a server-client manner. In other words, the gateway (for example, 100) may transmit Ethernet packets packed with packets of other protocols to other gateways 200 and 300, and packets of other protocols may be packaged into Ethernet packets to other gateways 200 and 300 As shown in FIG.

The structure, packaging operation, and un-packaging operation of each of the gateways 100, 200, and 300 will be described in detail with reference to FIGS. 2 to 13. FIG.

Each of the electronic control units 110, 210, and 310 may be used to control various sub-systems ranging from a subsystem for convenience, safety, multimedia, to a power train for power transmission within the vehicle Device. ≪ / RTI >

Each of the electronic control devices 110, 210, and 310 is connected to each of the gateways 100, 200, and 300 via another protocol other than Ethernet, such as CAN communication, LIN communication, K- Packets can be exchanged.

2 is a diagram for explaining a process of packaging a CAN packet into an Ethernet packet.

1 and 2, the CAN packet P-CAN includes a start of frame (SOF), an identifier, a remote transmission request (RTR), an identifier extension (IDE), a reserved bit R0, a DLC data lenghth code, data 1, cyclic redundancy check (CRC), acknowledgment (ACK), EOF, and inter frame space (IFS).

Although the CAN packet (P-CAN) in FIG. 2 shows a CAN 2.0A version format according to the ISO standard (ISO11898) as one embodiment of the CAN packet, the technical scope of the present invention is not limited to the CAN packet ) Should not be construed as limited.

The SOF indicates the start of the message, and the identifier may include priority information of the message.

RTR is a remote transmission request bit. When the value is '0', it indicates that the CAN packet (P-CAN) is a packet for data transmission and when it is '1', it indicates that the CAN packet (P-CAN) is a packet for remote transmission request.

The IDE distinguishes between the standard identifier and the extension identifier, and the DLC indicates the number of bytes of the data (Data1) portion. The CRC is a bit for detecting an error with a 16-bit checksum, and the ACK is a bit for indicating that the CAN packet (P-CAN) has been correctly received.

EOF represents the end of the CAN packet (P-CAN), and IFS is the area containing the amount of time required by the controller.

The Ethernet packet P-ETH1 includes a preamble, a start frame delimiter (SFD), a destination address (SA), a source address (SA), a type, a data field Data1 ', a cyclic redundancy check (CRC) . ≪ / RTI >

The preamble is a part for bit synchronization, and the SFD is a function for indicating the start of a frame. DA represents a MAC address (media access control address) of a destination to receive the Ethernet packet (P-ETH1), and SA represents a MAC address of a destination to which the Ethernet packet (P-ETH1) is transmitted.

The type indicates the type of the Ethernet packet P-ETH1, the data field Data1 'contains the data to be transmitted, and the CRC is used to detect an error in the Ethernet packet P-ETH1.

Each of the gateways 100, 200, and 300 can package a packet of another protocol, for example, a CAN packet (P-CAN) other than Ethernet, into the data field Data1 'of the Ethernet packet P-ETH1. That is, the entire packaged CAN packet (P-CAN) (SOF, Identifier, RTR, IDE, Reserved bit (R0), DLC, Data (Data1), CRC, ACK, EOF and IFS) Is included in the data field Data1 'of the P-ETH1.

Each of the gateways 100, 200, and 300 according to the embodiment is configured such that after packaging, the remainder (preamble, SFD, DA, SA) except for the data field Data1 'of the Ethernet packet P- , Type, and CRC). In some cases, unnecessary parts can be processed by default.

Accordingly, each of the gateways 100, 200, and 300 can transmit the CAN packet (P-CAN) through the Ethernet communication network by converting the CAN packet (P-CAN) into the Ethernet packet (P-ETH1) .

Referring to FIG. 1, an Ethernet packet (P-ETH1) in which the entire CAN packet (P-CAN) is packaged can be transmitted and received between the gateways 100, 200, and 300.

3 is a diagram for explaining a process of unpackaging a CAN packet packaged in an Ethernet packet.

1 to 3, each of the gateways 100, 200, and 300 includes a CAN packet (P-CAN) included in a data field Data1 'of an Ethernet packet (P-ETH1) ) To the electronic control devices 110, 210, and 310, respectively.

The un-packaging process of FIG. 3 may be performed through a reverse process of the packaging process described in FIG.

4 is a diagram for explaining a process of packaging an LIN packet into an Ethernet packet.

4, the LIN packet P-LIN includes a synchronization break (Synch break), a synchronization byte (Synch byte), an identifier, data (Data2), and a checksum ).

A sync break can be used as a start signal for a new packet, and a sync byte can appear as a specific bit pattern for synchronization.

An identifier is composed of a message ID assigned to each type according to the purpose of a message to be transmitted and received.

Data (Data2) contains data to be transmitted, and a checksum is used to detect an error in the LIN packet (P-LIN).

Each of the gateways 100, 200, and 300 may package a packet of another protocol other than Ethernet, for example, the entire LIN packet P-LIN, into the data field Data2 'of the Ethernet packet P-ETH2. That is, the entire packaged LIN packet (P-LIN) (Synch break, Synch byte, Identifier, Data2, and checksum) In the data field Data2 '.

Each of the gateways 100, 200, and 300 according to the embodiment includes the remaining parts (preamble, SFD, DA, SA) except for the data field Data2 'of the Ethernet packet P- , Type, and CRC). In some cases, unnecessary parts can be processed by default.

Thus, each of the gateways 100, 200, and 300 can transmit the LIN packet (P-LIN) through the Ethernet communication network without packaging by packaging the LIN packet P-LIN into the Ethernet packet P-ETH2 .

The structure of the Ethernet packet P-ETH2 is substantially the same as the Ethernet packet P-ETH1 of Fig. 1 except that the LIN packet P-LIN is packed in the data field Data2 '.

5 is a diagram for explaining a process of unpacking an LIN packet packaged in an Ethernet packet.

Referring to FIGS. 1, 4 and 5, each of the gateways 100, 200 and 300 includes a LIN packet included in a data field Data 2 'of an Ethernet packet P-ETH2 received via an Ethernet communication network, (P-LIN) to the electronic control devices 110, 210, and 310, respectively.

The un-packaging process of FIG. 5 may be performed through a reverse process of the packaging process described in FIG.

6 is a diagram for explaining a process of packaging a K-LINE packet into an Ethernet packet.

Referring to FIGS. 1 and 6, a K-LINE packet P-KL includes a format, a target, a source, a length, a service ID, , And a checksum.

Format is a part for defining output content and character format, and Target and Source are optional parts for multi-node connection. The Length indicates the size of the data Data3.

The format (Format) to the length belong to the header, and the service ID (Service ID) and the data (Data3) belong to the data byte. The checksum is a bit for detecting an error.

Each of the gateways 100, 200 and 300 can package a packet of another protocol such as K-LINE packet (P-KL) other than Ethernet into the data field Data 3 'of the Ethernet packet P-ETH3 . That is, all of the packaged K-LINE packet (P-KL) (Format, Target, Source, Length, Service ID, Data 3, Checksum) is included in the data field Data 3 'of the Ethernet packet P-ETH3.

Each of the gateways 100, 200, and 300 according to the embodiment is configured such that after packaging, the remaining parts (preamble, SFD, DA, SA) except the data field Data 3 'of the Ethernet packet P- , Type, and CRC). In some cases, unnecessary parts can be processed by default.

Accordingly, each of the gateways 100, 200, and 300 packages the K-LINE packet (P-KL) into the Ethernet packet (P-ETH3) Lt; / RTI >

The structure of the Ethernet packet P-ETH3 is substantially the same as the Ethernet packet P-ETH1 of FIG. 1 except that the K-LINE packet P-KL is packaged in the data field Data 3 '.

7 is a diagram for explaining a process of unpacking a K-LINE packet packaged in an Ethernet packet.

1, 6, and 7, each of the gateways 100, 200, and 300 includes a K-field included in a data field Data 3 'of an Ethernet packet P-ETH3 received via an Ethernet communication network, LINE packet (P-KL) to the electronic control devices 110, 210, and 310, respectively.

The un-packaging process of FIG. 7 may be performed through a reverse process of the packaging process illustrated in FIG.

8 is a diagram for explaining a process of packaging a FlexRay packet into an Ethernet packet.

1 and 8, a FlexRay packet P-FR includes a reserved bit (1), a data preamble indicator (2), a null frame indicator (3) A sync frame indicator 4 and a start frame indicator 5, a frame ID, a data length, a header CRC, a cycle count Cycle count, Data (Data 4), and CRC.

The reserved bit (1) indicates whether data is transmitted or received, and the data preamble indicator (2) indicates a connection status with the network. The null frame indicator 3 indicates the validity of the data, and the sync frame indicator 4 indicates whether to store the synchronized FlexRay packet P-FR in the node. The start frame indicator 5 indicates whether the FlexRay packet P-FR is a start frame.

The frame ID can be used to identify the FlexRay packet (P-FR) and prioritize the event trigger frame.

The data length indicates the length of the data Data 4, and the header CRC can be used to detect an error during transmission. The cycle count is a counter value that is incremented each time the communication cycle starts.

A start frame indicator 5, a frame ID (Frame ID), a data length (Data Length), a header The CRC (Header CRC), and the cycle count are included in the header.

The data Data 4 includes data to be transmitted. The CRC is used to detect errors.

Each of the gateways 100, 200 and 300 may package a packet of another protocol other than Ethernet, for example, the entire FlexRay packet P-FR into the data field Data 4 'of the Ethernet packet P-ETH4. That is, the entire packaged FlexRay packet P-FR (reserved bit 1, data preamble indicator 2, null frame indicator 3, sync frame indicator 4 and start frame indicator 5) ID (Frame ID), Data length, Header CRC, Cycle count, Data 4 and CRC are transmitted to the data field Data 4 'of the Ethernet packet P- .

Each of the gateways 100, 200, and 300 according to the embodiment includes the remaining parts (preamble, SFD, DA, SA) except for the data field Data 4 'of the Ethernet packet P- , Type, and CRC). In some cases, unnecessary parts can be processed by default.

Accordingly, each of the gateways 100, 200, and 300 can transmit the FlexRay packet (P-FR) through the Ethernet communication network without the conversion process by packaging the FlexRay packet P-FR into the Ethernet packet P-ETH4 .

The structure of the Ethernet packet P-ETH4 is substantially the same as the Ethernet packet P-ETH1 of Fig. 1 except that the FlexRay packet P-FR is packaged in the data field Data4 '.

9 is a diagram for explaining a process of unpackaging a FlexRay packet packaged in an Ethernet packet.

1, 8, and 9, each of the gateways 100, 200, and 300 includes a FlexRay packet (not shown) included in a data field Data 4 'of an Ethernet packet P- (P-FR) to the electronic control devices 110, 210, and 310, respectively.

The un-packaging process of FIG. 9 can be performed through a reverse process of the packaging process described in FIG.

10 is a block diagram according to one embodiment of the gateway shown in FIG.

1 and 10, a gateway 100A according to an embodiment of the gateway 100 shown in FIG. 1 may include a receiving circuit 120A and a transmission circuit 130A. have.

The receiving circuit 120A may include a first packet type determination module 122 and a packaging module 124. [

The first packet type determination module 122 receives packets of various protocols (e.g., CAN packet, LIN packet, K-LINE packet, or FlexRay packet) transmitted from each of the electronic control devices 110, The type of the packet can be determined. The first packet type determination module 122 may transmit the packets of various protocols transmitted from each of the electronic control units 110 to the packaging module 124 together with data on the type of the determined packet.

The packaging module 124 may package packets of various protocols (e.g., CAN packet, LIN packet, K-LINE packet, or FlexRay packet) into the data field of the Ethernet packet based on the data on the type of packet. In this case, the packaging module 124 may adjust the space allocated to the data field of the Ethernet packet for packaging according to the type of the packet. Depending on the embodiment, the packaging module 124 may package the data regarding the packet type together in the data field of the Ethernet packet.

The packaging module 124 may transmit Ethernet packets, which are packaged with packets of various protocols (e.g., CAN packet, LIN packet, K-LINE packet, or FlexRay packet) to another gateway 200.

According to an embodiment, the receiving circuit 120A may not include the first packet type determination module 122. [ In this case, the packaging module 124 may package packets of various protocols (for example, CAN packet, LIN packet, K-LINE packet, or FlexRay packet) in the data field of the Ethernet packet regardless of the packet type.

The transmission circuit 130A may include a second packet type determination module 132 and an un-packaging module 134. [

The second packet type determination module 132 determines the type of packet of another protocol packaged in the Ethernet packet transmitted from another gateway 200 (for example, a CAN packet, a LIN packet, a K-LINE packet, or a FlexRay packet) . The second packet type determination module 132 transmits the packet of the other protocol (for example, the CAN packet, the LIN packet, the K-LINE packet, or the FlexRay packet) together with the data about the type of the determined other protocol packet to the un- 134).

Unpackaging module 134 unpacks packets (e.g., CAN packet, LIN packet, K-LINE packet, or FlexRay packet) of the other protocol packaged in the Ethernet packet based on the data about the type of the other protocol packet - Can be packaged. In this case, the un-packaging module 124 can determine the portion to be un-packaged in the data field of the Ethernet packet according to the type of the packet.

According to an embodiment, the transmitting circuit 130A may not include the second packet type determination module 132. [ In this case, the un-packaging module 134 can unpackage various protocol packets (e.g., CAN packet, LIN packet, K-LINE packet, or FlexRay packet) packaged in the data field of the Ethernet packet regardless of the packet type can do.

Each of the other gateways 200 and 300 may have the same structure as the gateway 100A.

11 is a block diagram according to another embodiment of the gateway shown in Fig.

1, 10, and 11, the gateway 100B according to another embodiment of the gateway 100 shown in FIG. 1 may include a receiving circuit 120B and a transmitting circuit 130B.

The receiving circuit 120B may include a packaging module 124 and an order rearrangement module 126. The structure and operation of the packaging module 124 shown in Fig. 11 is substantially the same as the structure and operation of the packaging module 124 shown in Fig.

The reordering module 126 reorders the packets of the other protocol (for example, CAN packet, LIN packet, K-LINE packet, or FlexRay packet) packaged in the data field of the Ethernet packet by the packaging module 124, Data regarding the transmission priority can be extracted from a part of the packet of the protocol (for example, the identifier of the CAN packet in Fig. 1).

In a state where packets of another protocol (e.g., a CAN packet, a LIN packet, a K-LINE packet, or a FlexRay packet) are packaged in a data field of an Ethernet packet based on the extracted data, Packets can be rearranged according to transmission priority.

Depending on the embodiment, the reordering module 126 may be implemented with a first in first out (FIFO) buffer.

In accordance with another embodiment, the reordering module 126 may be implemented within the transmit circuitry 130B or external to the gateway 100B.

The un-packaging module 134 included in the transmission circuit 130B performs substantially the same function as the un-packaging module 134 of FIG.

Each of the other gateways 200 and 300 may have the same structure as the gateway 100B.

12 is a flowchart of a method of packaging another protocol packet into an Ethernet protocol packet according to an embodiment of the present invention.

1 to 12, a gateway (e.g., 100) may receive other protocol packets (e.g., CAN packets, LIN packets, K-LINE packets, or FlexRay packets) from each of the electronic control devices 110 (S10).

The gateway (e.g., 100) may package the entirety of the other protocol packets received in the data field of the Ethernet packet (S12).

A gateway (e. G., 100) may transmit the entire Ethernet packet of the other protocol packet to other gateways (e. G., 200 and 300).

13 is a flowchart of a method of unpackaging Ethernet protocol packets packed with other protocol packets according to an embodiment of the present invention.

A gateway (e.g., 100) may receive an Ethernet packet from another gateway (e.g., 200) in which all other protocol packets are packaged, and unpackage the received Ethernet packet to obtain the entire other protocol packet (S20).

The gateway (e.g., 100) may transmit the entirety of the other protocol packets obtained through un-packaging to the electronic control devices (e.g., 110) (S22).

FIG. 14 is a flowchart of a method for rearranging the transmission order of Ethernet protocol packets packed with other protocol packets according to an embodiment of the present invention.

(E.g., a CAN packet, a LIN packet, a K-LINE packet, or a FlexRay packet) from each of the electronic control devices 110, the gateway (e.g., 100) (S30).

The gateway (e.g., 100) may package the entirety of the other protocol packets received in the data field of the Ethernet packet (S32).

A gateway (e.g., 100) may transmit a packet (e.g., a packet) of another protocol in a state where a packet of another protocol (e.g., a CAN packet, a LIN packet, a K-LINE packet, or a FlexRay packet) Data relating to the transmission priority can be extracted from the CAN packet identifier in FIG. 1 (S34).

The gateway (e.g., 100) may rearrange the transmission order of the Ethernet packets based on the extracted data (S36).

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. Accordingly, the true scope of the present invention should be determined by the technical idea of the appended claims.

10: In-Vehicle Communication System
100, 200, 300: gateway,
110, 210 and 310: Electronic control units (ECUs)

Claims (6)

The method comprising: receiving a CAN packet (control area network (CAN) packet) from a gateway; And
Wherein the gateway comprises packaging all of the received CAN packets in a data field of an Ethernet packet. The method of claim 1, wherein after the packaging step,
Further comprising the step of the gateway generating a remainder of the Ethernet packet except for the data field. 3. The method of claim 2,
An identifier (ID), an identifier extension (ID), a reserved bit (R0), a data length code (DLC), data, a CRC (cyclic redundancy check) A method of packaging a CAN packet comprising acknowledgment (ACK), end of frame (EOF), and inter frame space (IFS). An electronic control device for outputting a CAN packet (control area network (CAN) packet); And
And a gateway for receiving the CAN packet and packaging the entire CAN packet received in a data field of an Ethernet packet. 5. The gateway according to claim 4,
After packaging the entirety of the CAN packet in the data field of the Ethernet packet, generates the remaining portion of the Ethernet packet except for the data field. 6. The method of claim 5,
An identifier (ID), an identifier extension (ID), a reserved bit (R0), a data length code (DLC), data, a CRC (cyclic redundancy check) (ACK), an end of frame (EOF), and an inter frame space (IFS).

Images