Multi-network communication system

Abstract

A multi-network communication system is provided, including: a first sub-network, within which there is at least one local service, and each of the at least one local services is mapped to a corresponding internal VLAN and sends and receives first data packets to or from the outside of the communication system via the corresponding internal VLAN and a first virtual network port pair between the first sub-network and the second sub-network; and a second sub-network, communicatively coupled to the first sub-network, and the second sub-network is configured to directly forward the first data packets from or to the outside.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technologies, and in particular, to a multi-network communication system including multiple sub-networks. Background Art

[0002] With the development of artificial intelligence and chip technologies, more and more functional modules are integrated into vehicles, such as autonomous driving, audio and video entertainment, and vehicle intelligence. This has led to an increasing number of controllers in vehicles, such as ECUs (Electronic Control Units). These systems require a large amount of data to be exchanged between ECUs or between ECUs and the cloud.

[0003] Traditional in-vehicle communication solutions include LIN (Local Interconnect Network), MOST (Media Oriented System Transport), CAN (Controller Area Network), and FlexRay, etc. With the increasing requirements for data transmission volume and transmission rate, these communication solutions are difficult to meet the needs of high bandwidth and low latency. In particular, in-vehicle systems have very high requirements for the response speed of sensors and control systems, and need to ensure a transmission delay at the millisecond level (or less).

[0004] To address this need, in-vehicle Ethernet has been developed. Based on the civilian Ethernet protocol, in-vehicle Ethernet has changed the electrical characteristics of physical ports and specifically customized some new standards in combination with in-vehicle network requirements. Currently, in-vehicle Ethernet uses DoIP (Diagnostic communication over Internet Protocol), SOME / IP (Scalable service-Oriented Middleware over IP), and Ethernet AVB (Ethernet Audio / Video Bridging) as its own protocol stack for in-vehicle Ethernet to meet special requirements in the in-vehicle environment, such as the requirements of in-vehicle devices for electrical characteristics (EMI (electromagnetic interference) / RF (radiation)), the requirements of in-vehicle devices for applications such as high bandwidth, low latency, and audio and video synchronization, and the requirements of in-vehicle systems for network management.

[0005] However, with more and more modules using Ethernet as the carrier, the hardware and software requirements of different systems and different manufacturers have led to a great occupation of in-vehicle Ethernet resources. Building a safe and reliable automotive Ethernet network topology centered on the intelligent cockpit has become an urgent problem to be solved for high-performance and high-reliability vehicles. Summary of the Invention

[0006] One aspect of the present disclosure provides a multi-network communication system, including: a first sub-network, which contains at least one local service, and each of the at least one local service is mapped to a corresponding internal VLAN and transmits and receives a first data packet to or from the outside of the communication system via the corresponding internal VLAN and a first virtual network port pair between the first sub-network and the second sub-network; and a second sub-network, communicatively coupled to the first sub-network, and the second sub-network is configured to directly forward the first data packet from or to the outside.

[0007] In an optional embodiment, the internal communication between the first sub-network and the second sub-network can be performed through a dedicated virtual network port pair different from the first virtual network port pair.

[0008] In an optional embodiment, inside the second sub-network, the first data packet can be directly forwarded between the bridge operating at the data link layer and the outside.

[0009] In an optional embodiment, the first sub-network can have a unique external IP address.

[0010] In an optional embodiment, the first sub-network can contain a first mapping table for mapping at least a part of the five-tuple information in the first data packet from the outside to the private IP address of the local service for receiving the first data packet.

[0011] In an optional embodiment, the first sub-network can further contain a second mapping table for mapping the private IP address to the corresponding internal VLAN.

[0012] In an optional embodiment, the internal VLAN for receiving the first data packet can be the same as the internal VLAN for sending the first data packet.

[0013] In an optional embodiment, each of the at least one local service can listen for data on the corresponding internal VLAN.

[0014] In an optional embodiment, the first sub-network can communicate with the second sub-network through a virtual network port, and the second sub-network communicates with the outside through a physical network card.

[0015] In an optional embodiment, the second sub-network can provide security services. Description of the Drawings

[0016] Figure 1 Shows an example application of Ethernet in a vehicle system.

[0017] Figure 2 Shows an example architecture of in-vehicle Ethernet as an example of a multi-network communication system.

[0018] Figure 3 Shows the address allocation method of a conventional multi-IP network.

[0019] Figure 4 Shows the address allocation method of single-IP multi-VLAN according to an embodiment of the present disclosure.

[0020] Figure 5 Shows a schematic diagram of the communication architecture of the cockpit system 100 applying the single-IP multi-VLAN address allocation according to an embodiment of the present disclosure.

[0021] Figure 6 Shows a schematic diagram of the OSI reference model.

[0022] Figure 7 Shows a schematic diagram of the communication decoupling of the cockpit system 100 according to an embodiment of the present disclosure.

[0023] Figure 8 Shows a schematic diagram of the communication scheme of the cockpit system 100 applying policy routing according to an embodiment of the present disclosure.

[0024] Figure 9 Shows that in accordance with an embodiment of the present disclosure Figure 8 A flowchart of an example process 900 of message transmission executed in the shown cockpit system 100. Detailed Description of the Invention

[0025] In the following description, numerous specific details are set forth. However, it should be understood that embodiments of the present invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description.

[0026] References in the specification to "one embodiment", "an embodiment", "example embodiment", etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is considered within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0027] For the purposes of the present disclosure, the phrase "A and / or B" means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0028] Embodiments of the present disclosure are described below with an automotive vehicle as a platform. However, it should be understood that the communication architecture and technology of the present disclosure can also be applied to other platforms involving communication between multiple domains (sometimes also referred to as sub-networks below) and / or ECUs, such as other types of motor vehicles (e.g., motorcycles, buses, tractors, tractor-trailer vehicles, or construction equipment), rail transit vehicles (e.g., trains or trams), ships (e.g., boats or ships), aircraft (e.g., airplanes or helicopters), or spacecraft (e.g., satellites), etc.

[0029] Figure 1 An example application of Ethernet in an in-vehicle system is shown. Currently, more and more in-vehicle systems use Ethernet as a carrier, such as Figure 1 the V2X (Vehicle to Everything) shown, communication system, audio system, camera system, entertainment system, DMS (Driver Monitoring System). According to various requirements put forward by different vehicle manufacturers or customers, these systems / ECUs are integrated into the vehicle body in independent domains (sometimes also referred to as sub-networks below). Each domain may contain one or more applications. Depending at least in part on the number of applications, each system may occupy a certain number of IP addresses. However, with the increase in the number of these domains and applications, challenges are posed to the resource scheduling and network topology security of Ethernet.

[0030] One of the purposes of the present disclosure is to provide a multi-network communication system that can improve the occupancy of network resources by each sub-network. Each sub-network can come from different manufacturers, use different standards and protocols, and provide different services. These sub-networks can be commonly connected to the in-vehicle Ethernet for communication within the sub-network, between sub-networks, and / or between each sub-network and the outside. The form of providing services to the outside can be, for example, receiving a request message from another network, device, or cloud, and after the local service within the sub-network processes the request message, replying with a response message to the other network, device, or cloud.

[0031] Depending on the arrangement of the network ports, the response message can be directly sent to the outside or sent to the outside via another sub-network. For example, a sub-network without a physical network card can pass the message to a sub-network with a physical network card through a virtual network port and then send it to the outside. The physical network card can be set in a sub-network with higher requirements for network transmission real-time performance and security.

[0032] Figure 2 Shows an example architecture of in-vehicle Ethernet as an example of a multi-network communication system. Figure 2 Among them, an implementation of the multi-network communication system can be the cockpit system 100, which includes two sub-networks (domains), namely QNX 101 and Android 102.

[0033] QNX 101 and Android 102 are commonly used operating systems in in-vehicle applications. QNX 101 adopts a non-open-source microkernel architecture, has high functionality and security, and can be used to provide instrument and power systems as well as various security services, such as Figure 2 The ADCU (Automated Driving Control Unit) service, HOD (Hands Off Detection) service, HUD (Head-up Display) service, DoIP diagnostic service, etc. shown in.

[0034] Android 102 has an open source and good development environment, has accumulated a large number of application ecosystems in the mobile terminal, and has advantages in the in-vehicle entertainment field. Therefore, there are usually a large number of local services in the sub-network of Android 102. The local services in Android 102 are modifiable and extensible, so the network resources occupied by its local services also change. In contrast, the local services in QNX 101 can be fixed, and the network resources occupied by them are also relatively fixed.

[0035] The local services in QNX 101 and Android 102 can come from different developers and have different communication requirements, such as communication protocols, source ports, destination ports, etc. The local services of different developers may use the same communication protocol and / or port, or may be different.

[0036] For example, the local HUD service (not shown) of QNX 101 can transmit data to the external HUD module 121 through CAN, the local HOD service (not shown) can transmit data to the external HOD module 122 through the LIN protocol, and the local ADCU service (not shown) can transmit data to the external ADCU module 123 through in-vehicle Ethernet. QNX 101 can also transmit data to external devices through the gateway 130, such as Figure 2 The PC diagnostic instrument shown to perform DoIP diagnosis. For example, the manufacturer can obtain the running data of the vehicle from QNX 101 through DoIP diagnosis.

[0037] The TBOX (Telematics - BOX) module 140 can provide interaction with the mobile terminal. For example, the local references within the cockpit system 100 can interact with the mobile terminal, the remote cloud, or the server through the TBOX module 140. As an example, a user can send a request to obtain vehicle information through a mobile application. The request reaches the cockpit system 100 via the TBOX module 140. The local service within the cockpit system 100 provides a response to the request. The response can be replied to the mobile terminal through the TBOX module 140.

[0038] The increase in local services within QNX 101 and Android 102 results in QNX 101 and Android 102 occupying more IP addresses. Figure 3 Illustrates the address allocation method of the conventional multi - IP network. As Figure 3 shown, the TBOX service, DVR (Digital Video Recorder) service, DoIP service, and SOME / IP service in the in - vehicle environment are respectively assigned an IP address (Address 1 - Address 4). The dashed box 201 represents a sub - network containing these services. Therefore, Figure 3 in it, the sub - network 201 needs to be assigned four external IP addresses.

[0039] Figure 4 Illustrates the address allocation method of single - IP multi - VLAN according to an embodiment of the present disclosure. As Figure 4 shown, the TBOX service, DVR service, DoIP service, and SOME / IP service within the sub - network 201A are respectively mapped to corresponding VLAN (Virtual Local Area Network) channels and communicate with the outside through the corresponding VLAN channels. Different from Figure 3 the sub - network 201 that occupies four external IP addresses shown, the sub - network 201A of this embodiment only occupies a unique external IP address. The internal local services (TBOX service, DVR service, DoIP service, and SOME / IP service) can be assigned private IP addresses and mapped to the unique external IP address through the corresponding VLANs (VLAN 2 - VLAN 5). The private IP addresses can be pre - determined by the manufacturer and are not publicly disclosed. The conversion from private IP addresses to external IP addresses can be achieved through the existing NAT (Network Address Translation) technology. By adopting this conversion from a single IP address to multiple private IP addresses, the occupation of the external IP address resources of the in - vehicle Ethernet where the sub - network 201A is located is reduced.

[0040] Figure 5Schematic diagram showing the communication architecture of the cockpit system 100 applying single-IP multi-VLAN address allocation according to an embodiment of the present disclosure. In this embodiment, the cockpit system 100 can be connected to the external ADCU module 123 through an optional external switch 120 and can be further connected to the TBOX module 140 via an optional gateway 130.

[0041] Android 102 has an external IP address "198.18.34.15" and sets four private IP addresses "10.1.2.6", "10.1.3.6", "10.1.4.6", and "10.1.5.6" internally for local services. The correspondence between the private IP addresses and the local services can be set and changed as needed. Depending on the number of local services, a part of the private IP addresses can be not enabled or enabled after the local services are changed. In this embodiment, the four private IP addresses "10.1.2.6", "10.1.3.6", "10.1.4.6", and "10.1.5.6" respectively correspond to four VLAN channels, namely VLAN2 to VLAN4. Each VLAN channel can have a different priority. A private IP address corresponding to a VLAN channel with a higher priority can be allocated to a local service with a higher priority. The private IP addresses "10.1.2.6", "10.1.3.6", "10.1.4.6", and "10.1.5.6" and the external IP address "198.18.34.15" can be mutually converted through NAT. For example, a mapping table of the private IP addresses and the external IP address can be set.

[0042] For example, when an external request is transmitted to Android 102, the destination address in its message is the external IP address "198.18.34.15" of Android 102. The routing module within Android 102 can determine the destination of the message based on the five-tuple information in the message, such as a local service assigned the private IP address "10.1.2.6". The five-tuple information is used to determine the source and destination of the message, including the source address, destination address, communication protocol, source port, and destination port. The routing module can thus use NAT to replace the destination address in the received message with this private IP address "10.1.2.6" and transmit it through VLAN 2 pre-assigned to this private IP address to the corresponding local service for processing. After the local service finishes processing, it needs to transmit the response information to the outside through VLAN 2. At this time, the source address in the message of the response information is the private IP address "10.1.2.6". The network filtering module can use NAT to convert this private IP address "10.1.2.6" to the external IP address "198.18.34.15" of Android 102 as the source address of the reply message and send it to the outside. In this way, for the outside, Android 102 always uses only one external IP address "198.18.34.15", saving the network resources of the Ethernet.

[0043] It should be noted that in this embodiment, Android 102 itself does not have a physical network port and cannot directly transfer data with the outside. The physical network port is set in QNX 101, namely emac, to ensure the real-time performance and system security of the QNX network. Therefore, the data transfer between Android 102 and the outside needs to be achieved through the emac of QNX 101. In addition, communication can also occur between Android 102 and QNX 101, and communication may also occur between QNX 101 and the outside. To improve the stability and security of the network topology, the present disclosure decouples the communication between Android 102 and the outside, the inter-domain communication between Android 102 and QNX 101, and the communication between QNX 101 and the outside. To achieve the decoupling of communication, different layers within QNX 101 are used in this embodiment to perform these three types of communication.

[0044] Figure 6A schematic diagram showing the OSI reference model. The OSI (Open System Interconnection Reference Model) model divides the computer network architecture into seven layers as shown in the figure: the physical layer, the data link layer, the network layer, the transport layer, the session layer, the presentation layer, and the application layer. The application layer provides ports for application software to set up communication with another application software. The presentation layer is used to convert data into a format that is compatible with the receiver's system format and suitable for transmission. The session layer is used to set up and maintain a communication connection between two computers in a computer network during data transmission. The transport layer is used to add a transport header (TH) to the data to form a data packet. The transport header contains sending information such as the protocol used, such as the Transmission Control Protocol (TCP), etc. The network layer determines the path selection and forwarding of data, and adds a network header (NH) to the data packet to form a packet. The network header contains network data, such as the Internet Protocol (IP), etc. The data link layer is used for network addressing, error detection, and error correction. The physical layer transmits data frames on a local area network and is responsible for managing the interconnection between computer communication devices and network media, including pins, voltages, cable specifications, hubs, repeaters, network cards, host adapters, etc.

[0045] In the past, the transmission of messages started from the first layer (physical layer) and went up layer by layer. Messages of an application (such as a DoIP service) usually affected more than four layers, that is, the first layer to the fourth (fifth, sixth, or seventh) layer.

[0046] Figure 7 A schematic diagram showing the communication decoupling of the cockpit system 100 according to an embodiment of the present disclosure. In this embodiment, a message from Android 102 passes through the bridge 1014 ( Figure 5 the bridge in) of QNX 101 and is then directly sent to the outside through the physical network card 1013. Since the bridge 1014 and the network card 1013 work at the second layer, that is, the data link layer, by directly forwarding the message from Android 102 using the bridge 1014 and the network card 1013, the message from Android 102 only affects the layers below the second layer of QNX 101 and does not affect the messages above the second layer.

[0047] Inter-domain communication between Android 102 and QNX 101 is carried out through dedicated virtualization ports vif0 and vp0. Communication between Android 102 and the outside world is carried out through virtualization ports vif1 and vp1 other than the dedicated virtualization ports vif0 and vp0. That is to say, the virtualization ports vif0 and vp0 only transmit data packets for inter-domain communication between Android 102 and QNX 101. In this way, the inter-domain communication between Android 102 and QNX 101 can be decoupled from the communication between Android 102 and the outside world.

[0048] Communication between QNX 101 and the outside world is carried out at Figure 6 the fourth layer shown, that is, the transport layer and above. Therefore, the communication between QNX 101 and the outside world can be decoupled from the communication between Android 102 and the outside world which only goes up to the second layer. Thus, the decoupling among the communication between QNX 101 and the outside world, the communication between Android 102 and the outside world, and the inter-domain communication between Android 102 and QNX 101 is realized, improving the security and stability of the network topology.

[0049] The above describes the cockpit system 100 that applies the address allocation of single IP multiple VLANs. However, it should be noted that although the address allocation of single IP multiple VLANs can reduce the occupation of external IP addresses, the problem of VLAN tags for data packets needs to be solved. Specifically, in Figure 3 the implementation of the multi-IP network address allocation shown, the packets for a certain local service can be directly addressed through the IP address assigned to this service. For example, an external device or the cloud can directly send packets to the IP address assigned to this local service, and after the local service processes the request from this external device or the cloud, it can directly reply to the packet to the source address included in the received packet.

[0050] However, in Figure 4 and Figure 5 the implementation of the single IP multiple VLAN address allocation shown, multiple local services share one external IP address. The packets from an external device or the cloud only contain this unique external IP address as the destination address. After the transceiver module of the sub-network receives this packet, it determines which local service this packet should be sent to according to the five-tuple information (source IP address, destination IP address, protocol, source port, destination port) included in this received packet, and then converts the external IP address of this sub-network included in the packet into the private IP address of the corresponding local service through the NAT module and sends it to the local service through the corresponding VLAN channel. However, in the past, after the local service processed the received packet, it replied to the packet through the traditional routing table. This would cause the replied packet not to reach the network port of the sub-network through the correct VLAN channel, for exampleFigure 7 The virtual network port 1022 of Android 102 as shown. In other words, the packets received by the local service and the replied packets are not transmitted through the same VLAN channel. As a result, the packets replied by the local service will be discarded.

[0051] To solve this problem, based on the single IP multi-VLAN address allocation, the present disclosure adds policy routing to implement the matching of VLAN tags of the replied packets, so that the same local service can receive and send packets (data packets) via the same VLAN channel. Figure 8 A schematic diagram showing a communication scheme of the cockpit system 100 to which policy routing is applied according to an embodiment of the present disclosure. Figure 9 Shown according to an embodiment of the present disclosure in Figure 8 A flowchart of an example process 900 of packet transmission executed in the shown cockpit system 100.

[0052] Figure 8 The example of Figure 7 corresponds to, with only the outside of the cockpit system 100 shown on the left. QNX 101 communicates with the outside through the physical network card 1013. Android 102 communicates with the virtual network port 1012 on the QNX 101 side through its own virtual network port 1022, and further communicates with the outside via the network card 1013 on the QNX 101 side.

[0053] Multiple virtual network interface pairs can be set between the virtual network port 1022 on the Android 102 side and the virtual network port 1012 on the QNX 101 side, such as the vif0-vp0 port pair and the vif1-vp1 port pair described above with reference to Figure 5 and Figure 7 The vif0-vp0 port pair can be dedicated to the inter-domain communication between Android 102 and the QNX 101 side. Other port pairs such as the vif1-vp1 port pair can be used by Android 102 to transfer communication data with the outside of the cockpit system 100.

[0054] The network card 1013 of QNX 101 is coupled to the virtual network port 1012 through the bridge 1014, so as to enable the forwarding of packets below the second layer (i.e., the data link layer). The local application 1011 of QNX 101 is also coupled to the network card 1013 through the bridge 1014. The local application 1011 can transmit data with the outside above the fourth layer (transport layer).

[0055] On the Android 102 side, a DNAT (Destination Network Address Translation) module 1023 and an SNAT (Source Network Address Translation) module 1026 are set up to perform address translation for received packets and reply packets. The DNAT module 1023 converts the destination address in the received packet, that is, the external IP address of Android 102 (for example Figure 8 the "198.18.34.15" shown in Figure 8 as the "DNAT dst ip") to an internal private IP address as the converted destination address. The conversion of the destination address can be based on at least a part of the five-tuple information of the received packet. The five-tuple information includes the source address ("src ip"), destination address ("dst ip"), protocol ("protocol"), source port, and destination port. Figure 8 The source port is omitted in

[0056] and only the source address, destination address, protocol, and destination port ("port") are shown. Figure 8 In the example shown in Figure 8 , the upper mapping table (the first mapping table) has two entries. For a packet from the external TBOX module 140 with Android 102 as the destination, its source address is "198.18.34.7", the destination address is the external IP address "198.18.34.15" of Android 102, the communication protocol is TCP, and the destination port is 2022. Based on this five-tuple information, the private IP address "10.1.3.6" of the corresponding local service can be found in the mapping table. Similarly, for a packet from the external ADCU module 123 with Android 102 as the destination, its source address is "198.18.34.6", the destination address is the external IP address "198.18.34.15" of Android 102, the communication protocol is UDP, and the destination port is 2345. Based on this five-tuple information, the private IP address "10.1.4.6" of the corresponding local service can be found in the mapping table.

[0057] Since external data sources may come from products or applications of different manufacturers, and the protocols, ports, and source addresses they use may be the same, generating a mapping table based on five-tuple information can more accurately locate the correct private IP address. However, it should be understood that in the case where it can be ensured that the correct private IP address can be located based on a part of the elements in the five-tuple (for example, the external data source comes from the same manufacturer), the mapping table can be made only based on that part of the elements.

[0058] After the DNAT module 1023 converts the destination address in the received packet into the private IP address corresponding to the local service, the routing decision module 1024 determines the corresponding internal VLAN channel according to the determined private IP address, and sends it to the local interface 1021 through the corresponding internal VLAN channel for processing by the corresponding local service 211.

[0059] After the local service 211 finishes processing the received packet, it needs to send a reply message. As described above, the packet of the reply message needs to pass through the same internal VLAN channel as the received packet so as not to be discarded. The routing decision module 1025 can determine the corresponding internal VLAN channel according to the private IP address of the local service 211 that provides the reply message, and send the reply packet to the SNAT module 1026 through the corresponding internal VLAN channel.

[0060] In the routing decision module 1024 and the routing decision module 1025, a mapping table (second mapping table) of the private IP address of the local service and the internal VLAN channel can be pre-stored.

[0061] After the SNAT module 1026 receives the reply packet through the corresponding VLAN channel, it replaces the private IP address in the packet with the external IP address of the subnet where it is located, that is, the external IP address of Android 102 as the source address, and then sends it to QNX 101 through the virtual network port 1022. QNX 101 sends the reply packet from Android 102 to the destination address in the packet, thus completing this service.

[0062] According to this embodiment, for the outside, Android 102 only has a single unique external IP address "198.18.34.15". In other words, the destination address in the request packet from the outside and the source address in the reply packet from Android 102 are both the external IP address "198.18.34.15" of Android 102.

[0063] The following combines Figure 9 , taking Figure 8 the cockpit system 100 shown as the server providing network services and the TBOX module 140 as the client of the TCP network request as an example to illustrate the packet processing process of this embodiment.

[0064] First, make the following assumptions about the internal private IP address and external IP address of the cockpit system 100, the IP addresses of the ADCU module 123 and the TBOX module 140, and the allocation of the ports (Port) and protocols (Protocol) for requests and listening:

[0065] Table 1

[0066]

[0067] In the above table, "Internal VLAN 3 of the Cockpit System" represents the local service within the cockpit system that is assigned the VLAN 3 channel, and its private IP address is "10.1.3.6". The port Port represents the destination port. The following describes the packet processing procedure based on the above assumptions.

[0068] First, in block 901, the TBOX module 140 acting as the client sends a request packet to the cockpit system 100. The network card 1013 on the QNX101 side receives this request packet.

[0069] In block 902, the network card 1013 forwards the received packet to the virtual network port 1012 through the bridge 1014. The network card 1013 can determine whether the destination of the packet is the local service 1011 on the QNX 101 side or Android 102 based on the destination address in the packet.

[0070] In block 903, the virtual network port 1012 on the QNX 101 side and the virtual network port 1022 on the Android 102 side can transfer the packet via the specified virtual network port pair. In this embodiment, since the packet comes from outside the cockpit system 100, the packet can be transferred through the vif1-vp1 port described above instead of the vif0-vp0 port dedicated to the inter-domain communication between QNX 101 and Android 102.

[0071] In block 904, the DNAT module 1023 on the Android 102 side checks the information in the packet. The following mapping table can be stored in the DNAT module 1023.

[0072] Table 2 (The First Mapping Table)

[0073]

[0074] The mapping table in the DNAT module 1023 can map at least a part of the five-tuple information (source IP, destination IP, protocol, source port, destination port) of the received packet to the private IP address of the corresponding local service 211 within Android 102. According to Table 2, for a packet from the source IP address "198.18.34.7" (TBOX module 123), destination IP address "198.18.34.15", communication protocol TCP, and destination port 2022, the destination IP address "198.18.34.15" can be converted to the private IP address "10.1.3.6" of the TBOX service in the corresponding local service. For a packet from the source IP address "198.18.34.6" (ADCU module 140), destination IP address "198.18.34.15", communication protocol UDP, and destination port 2345, the destination IP address "198.18.34.15" can be converted to the private IP address "10.1.4.6" of the ADCU service in the corresponding local service 211.

[0075] In block 905, the DNAT module 1023 determines whether the information in the packet matches an entry in Table 2. If no entry is hit ("No" in block 905), further routing determination, forwarding, or discarding processing can be performed.

[0076] If a corresponding entry is found in the first mapping table ("Yes" in block 905), it proceeds to block 906 for destination address conversion.

[0077] In block 907, the routing decision module 1024 makes a routing determination. The routing determination can be based on a mapping table (also known as the second mapping table) that maps private IP addresses to internal VLANs as shown below.

[0078] Table 3

[0079] Destination IP Receiving Channel 10.1.3.6 VLAN3 10.1.4.6 VLAN4

[0080] In block 908, the received packet is sent via the corresponding VLAN channel to the local service indicated by the destination address after DNAT conversion.

[0081] In block 909, each of the local services 211 listens for packets on their respective corresponding VLAN channels. For example, the ADCU service with the private IP address "10.1.3.6" can listen for data on VLAN 3, and the TBOX service with the private IP address "10.1.4.6" can listen for data on VLAN 4. Packets transmitted through the corresponding VLAN channels are listened for and received by the corresponding local service 211.

[0082] In block 910, after the local service 211 processes the received message and generates a reply message, the reply message is sent to the routing decision module 1025.

[0083] In block 911, the routing decision module 1025 examines the message and its stored policy routing table, and in block 912 determines through which VLAN channel the reply message should be sent. The policy routing table indicates the mapping relationship between the private IP address (i.e., the source IP address) of the local service 211 providing the service and the VLAN channel used to send the reply message.

[0084] Table 4

[0085] Source IP Destination IP Sending Channel 10.1.3.6 198.18.34.7 (TBOX) VLAN3 10.1.4.6 198.18.34.6 (ADCU) VLAN4

[0086] By setting the routing decision module 1025, the correct VLAN channel can be used, that is, the same VLAN channel as the VLAN channel used to receive the request message, to send the reply message. For example, for a request message with a destination address of "10.1.3.6", VLAN 3 is the corresponding receiving channel. After the local service processes this message, the reply should be sent through the same VLAN 3. In this case, for the reply message, its source address is "10.1.3.6" and the channel used for sending is VLAN 3. If it is sent through an incorrect VLAN channel, such as using the previous main routing table, the replied message will be discarded because the VLAN channel of the reply path is inconsistent with the VLAN channel of the receiving path. By setting the routing decision modules 1024 and 1025 of this embodiment, this problem can be avoided, so that different local services can send and receive messages through the correct VLAN channels under single-IP multi-VLAN routing.

[0087] After determining the VLAN channel for sending the reply message in block 913, the routing decision module 1025 sends the reply message to the SNAT module 1026 via the determined VLAN channel in block 914.

[0088] The SNAT module 1026 examines the message in block 914. The SNAT module 1026 is used to convert the source address (corresponding to the private IP address of the local service) in the reply message into the external IP address of the subnet (Android102). An example of the mapping table in the SNAT module 1026 is shown below.

[0089] Table 5

[0090] Condition Executed SNAT Action Source IP 10.1.3.6 10.1.3.6->198.18.34.15 10.1.4.6 10.1.4.6->198.18.34.15

[0091] In box 915, the SNAT module 1026 determines whether the source IP address of the received reply packet is hit. If not, the packet is discarded. If hit (Yes in box 915), then in box 916, the source IP address is translated and then sent to the virtual network port 1022.

[0092] Similar to the process of receiving packets, the virtual network port 1022 on the Android 102 side sends the reply packet to the virtual network port 1012 on the QNX 101 side through the same virtual network port pair (such as vif1-vp1) used when receiving packets.

[0093] The virtual network port 1012 then forwards the reply packet to the network card 1013 through the bridge 1014 in box 918. This forwarding only affects the layers below the second layer (data link layer) of QNX 101, thus decoupling the communication between the local service 1011 of QNX 101 and the external communication above the fourth layer.

[0094] Finally, in box 919, the network card 1013 sends the reply packet to the destination according to the destination IP address in the reply packet.

[0095] The above describes the process in which the local application 211 within Android 102 receives a request from outside the cockpit system 100 and replies with a packet. For the inter-domain communication between Android 102 and QNX 101, such as the case where the local service 1011 on the QNX 101 side requests a service from the local service 211 on the Android 102 side, the communication process on the Android 102 side is generally similar to that described above with reference to Figure 8 and Figure 9 The difference is that the source IP address of the sent packet and the destination IP address of the reply packet are the external IP addresses of QNX 101, and Android 102 and QNX 101 transfer data via a dedicated virtual network port pair to decouple the communication between Android 102 and the outside of the cockpit system 100. In this case, the request packet for Android 102 is sent by the local service 1011 on the QNX 101 side and reaches the virtual network port 1012 through the bridge 1014. After the reply packet from Android 102 is received by the virtual network port 1012, it reaches the local service 1011 on the QNX 101 side through the bridge 1014.

[0096] In the case of external communication between QNX 101 and the cockpit system 100, the local service 1011 on the QNX 101 side transmits data to the outside via the bridge 1014 and the network card 1013. In this case, the transmitted data is carried out above the fourth layer (transport layer) of the OSI reference model to decouple the communication with Android 102 and the outside of the cockpit system 100.

[0097] In this embodiment, an arrangement of single-IP multi-VLAN address allocation is described on the Android 102 side. However, an arrangement of single-IP multi-VLAN address allocation can also be set on the QNX 101 side on this basis to further reduce the occupancy of network resources by QNX 101, especially when the number of local services 1011 of QNX 101 is large.

[0098] In addition, the above describes an example implementation of a multi-network communication system using QNX and Android as two operating systems. However, it should be understood that the technology of the present disclosure is also applicable to multi-network communication systems including other types of sub-networks.

[0099] At least a part of the embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention can be implemented as a computer program or program code executed on a programmable system, which includes at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0100] The program code can be applied to the input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0101] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium that represent various logics in a processor. When read by the machine, the representative instructions cause the machine to fabricate the logics for performing the technologies described herein. Such representations, referred to as "IP cores", can be stored on a tangible machine-readable medium and can be supplied to various customers or production facilities to be loaded into the manufacturing machines that actually fabricate the logics or processors.

[0102] The preferred embodiments of the present invention have been described in detail above. However, it should be understood that the present invention can adopt various embodiments and variations without departing from its broad spirit and scope. Those of ordinary skill in the art can make many modifications and changes based on the concept of the present invention without creative labor. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experiments on the basis of the prior art shall fall within the protection scope determined by the claims of the present invention.

Claims

1. A multi-network communication system, comprising: A first sub-network, within which there is at least one local service, and each of the at least one local service is mapped to a corresponding internal VLAN and sends and receives first data packets to or from the outside of the communication system via the corresponding internal VLAN and a first virtual network port pair between the first sub-network and a second sub-network; And The second sub-network, communicatively coupled to the first sub-network, internal communication between the first sub-network and the second sub-network is carried out through a dedicated virtual network port pair different from the first virtual network port pair, communication between the second sub-network and the outside is carried out at the transport layer and above, and the second sub-network is configured to directly forward the first data packets from or to the outside via a bridge operating at the data link layer.

2. The multi-network communication system according to claim 1, wherein The first sub-network has a unique external IP address.

3. The multi-network communication system according to claim 1, characterized in that, The first sub-network includes a first mapping table for mapping at least a part of the five-tuple information in the first data packets from the outside to the private IP address of the local service for receiving the first data packets.

4. The multi-network communication system according to claim 3, wherein The first sub-network further includes a second mapping table for mapping the private IP address to the corresponding internal VLAN.

5. The multi-network communication system according to claim 1, characterized in that, The internal VLAN for receiving the first data packets is the same as the internal VLAN for sending the first data packets.

6. The multi-network communication system according to claim 1, characterized in that, Each of the at least one local service listens for data on the corresponding internal VLAN.

7. The multi-network communication system according to claim 1, wherein The first sub-network communicates with the second sub-network through a virtual network port, and The second sub-network communicates with the outside through a physical network card.

8. The multi-network communication system according to claim 1, wherein The second sub-network provides security services.

Images