CN112585931A

CN112585931A - Vehicle communication method and communication device

Info

Publication number: CN112585931A
Application number: CN202080004605.1A
Authority: CN
Inventors: 李�杰
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-09-21
Filing date: 2020-09-21
Publication date: 2021-03-30
Also published as: WO2022056894A1

Abstract

The application provides a vehicle communication method and a communication device, and relates to the field of vehicle communication. The method comprises the following steps: receiving a first message, wherein the first message comprises a check field and a unique identifier, and the unique identifier comprises a frame Identification (ID) and an Internet Protocol (IP) address; checking the first message according to the check field of the first message; and storing the first message passing the inspection into a buffer space corresponding to the frame ID according to the frame ID. The method is applied to vehicles such as networked automobiles, intelligent automobiles, automatic driving automobiles and the like, and realizes the identification of the messages by setting the unique identifier for the messages, thereby ensuring the synchronous transmission of the messages and realizing the discrimination of the messages. And the precision requirement on the vehicle-mounted equipment is not too strict, and the alignment time is not required at all, so that the method is suitable for the vehicle-mounted equipment in the existing vehicle. In addition, an independent buffer space is set for each frame ID, so that the storage and reading of the message are more convenient and faster.

Description

Vehicle communication method and communication device

Technical Field

The present application relates to the field of vehicle communication, and in particular, to a vehicle communication method and a communication device.

Background

With the continuous development of automobile technology, the demand for communication between vehicle-mounted devices is higher and higher. In order to meet the communication requirement, a redundant connection mode is generally required to be adopted for the vehicle-mounted equipment, and redundant backup is carried out on an access link. In such a redundant connection, higher requirements are placed on the processing modes during the sending and receiving of the messages, such as how to synchronize the messages, how to discriminate the messages, and the like. For example, a certain vehicle-mounted device first sends two frames of messages with the same content to a network for transmission, and the two frames of messages finally reach a designated network port and a designated port of a target device (for example, another vehicle-mounted device or an upper computer device, etc.), but during this period, the vehicle-mounted device needs to establish an effective mechanism and logic to ensure that the two frames of messages with the same content can be synchronously sent, and the target device needs to complete the screening of the two frames of messages in the same period. In order to implement the above process, a complete set of protocol mechanisms is usually required to be formulated to ensure the reliability of sending and receiving, and the judgability of application logic, so as to finally implement the real-time transmission and redundancy arbitration of the message in the ethernet network layer.

Common Industrial Protocol (CIP) is a communication protocol applied to industrial automation, but since such connection-based communication generally requires establishing a communication path and is generally a point-to-point communication mode, many connection resources are occupied, and transmission capability is very limited, it cannot be widely applied in the vehicle field. In order to realize good communication between vehicle-mounted devices, an automotive ethernet network is developed, for example, a common extensible service-oriented protocol stack (SOME/IP) (i.e., a service-oriented scalable middleware located above an IP protocol layer) is adopted, although SOME/IP has better performance than CIP, the SOME/IP has a protocol depth too deep and has greater independence, and particularly has higher complexity for an application layer.

However, if the existing communication mechanism in the communication field is directly applied to the communication in the vehicle field, that is, the real-time transmission of the ethernet in the vehicle field is realized based on time synchronization, the communication mechanism is complicated.

Therefore, how to better realize the real-time transmission of the redundant data of the vehicle-mounted equipment is a technical problem to be solved urgently.

Disclosure of Invention

The application provides a vehicle communication method and a communication device, which can better realize real-time transmission of redundant data of vehicle-mounted equipment.

In a first aspect, a method of vehicle communication is provided, the method comprising: receiving a first message, wherein the first message comprises a check field and a unique identifier, and the unique identifier comprises a frame Identification (ID) and an Internet Protocol (IP) address; checking the first message according to the check field of the first message; and if the first message passes the check, storing the first message into a cache space corresponding to the frame ID according to the frame ID.

In the technical scheme of the application, the identification of the message is realized by setting the unique identifier for the message, so that the synchronous sending of the message is ensured and the discrimination of the message is realized. Compared with a communication mode based on time synchronization, the time synchronization of the receiving end and the sending end is not required, meanwhile, message discrimination errors caused by different time precision and time errors of different devices are avoided, namely, the precision requirement of the vehicle-mounted device is not too strict, the time alignment is not required completely, and therefore the vehicle-mounted device is suitable for the vehicle-mounted device in the existing vehicle. In addition, an independent buffer space is set for each frame ID, so that the method is a scheme very suitable for a vehicle communication scene, and the storage and reading of the message are more convenient and faster.

With reference to the first aspect, in some implementation manners of the first aspect, optionally, if the first packet does not pass the check, the first packet is discarded.

Optionally, in the process of checking the message, storing the message, or discarding the message, whether the message is correct may be checked according to a check field of the received message (e.g., the first message), and when the message is correct, the message may be further processed, and when the message has an error, the message may be discarded. That is, when the packet is correct, the check result is considered as "pass", and the packet is further processed (for example, stored in the buffer space corresponding to the frame ID); and when the message is wrong, the checking result is considered to be 'failed', and the message is discarded. This is because, in order to ensure that the data carried by the received packet is correct, a check field is often set, and the check field has a corresponding relationship with the carried content, so when the received packet has an error, the check field calculated according to the carried data will not be consistent with the check field carried when the packet is sent, and the packet can be discarded if the packet has an error.

When storing the message, taking the message received from two data transmission channels as an example, for example, the first message received from port 0 and port 1 may be transmitted to two independent buffer areas of the application program, and the application program may respectively create an independent buffer space for each frame ID under the corresponding port. And after receiving the messages, delivering the messages to the corresponding buffer intervals for storage according to the frame IDs. Each frame ID is allocated only one buffer space with a corresponding size, and the message received in each buffer space is stored in an overlapping manner. That is, the latest received message will cover the last message in the buffer.

Optionally, the sent messages may also be counted, that is, each frame of the messages is numbered, or it may be understood as setting the time sequence identifier of the message frame. That is, the first message is identified with the time sequence of transmission.

Alternatively, a sequence counter (sequence counter) may be defined, which serves as a sequence identifier of the message. The accumulation may be performed at the end where the message is sent, and the frame sequence counter accumulates 1 every time a frame of the message is sent.

It should be noted that, in the embodiment of the present application, the frame sequence count is used to indicate the sequence of sending the messages, and may be understood as the time order (sequence) of sending the messages. For example, if a frame sequence count of a certain message is 5 corresponds to the message being transmitted at the 5 th time, and if a frame sequence count of another message is 7 corresponds to the message being transmitted at the 7 th time, it can be known that the message is transmitted after the message having the frame sequence count of 5 is transmitted, and it can be considered that the transmission time of the message having the frame sequence count of 7 is later than that of the message having the frame sequence count of 5. It should be understood that the above is only one example for illustrating the meaning of the frame sequence count, and there is no limitation.

It should be further noted that, in the present application, the sending order of the messages may be understood as the sequence of sending the messages, and is not the actual sending time of the messages. In other words, in the existing communication, the timestamp is used as the sending time sequence of the message, which is the sequence of the actual sending time, but in the present application, only the sequence of the message sending sequence does not correspond to the actual time, and it can be regarded as the sequencing of each sent message. Just by distinguishing the freshness of the messages through the sending sequence and not corresponding to the actual time, the scheme of the application does not need to strictly require the time synchronization of all the devices. It should be noted that, in the embodiment of the present application, the frame sequence count is mainly used to assist in reading the message, so that an updated (later) message can be selected, the message selection rule is very suitable for this special application scenario of vehicle communication, but this method is not suitable for common communication (for example, communication between terminals such as mobile phones) because the amount of data involved in a common communication scenario is very large, and if the counting manner is adopted, the frame sequence count has reached the maximum value, but there is a case where data has no way to be stored, which causes problems such as data loss. In addition, in the present application, an independent buffer space needs to be configured for each frame ID, which is also not satisfied by common communication scenarios. For the above reasons, the time synchronization method is currently adopted in common communication scenarios, but the counting method cannot be adopted. If the communication mode based on time synchronization is applied to the communication in the vehicle field, compared with the scheme of the application, the method is very complicated, and the scheme without the application is concise and easy to realize.

Optionally, the stored packet may also be read, for example, the packet may be read from the buffer space of the corresponding frame ID when a read request sent by the application program is received.

With reference to the first aspect, in some implementations of the first aspect, the unique identifier further includes a frame sequence count, and may obtain a read request, where the read request includes a frame ID of a packet to be read; reading at least one first message from a cache space corresponding to a frame ID of a message to be read, wherein a value of a frame sequence count of the at least one first message is used for representing a transmitted sequence of the at least one first message; and selecting the message with the maximum corresponding frame sequence count value from at least one stored message and returning the second message.

Alternatively, an appropriate message may be selected from the at least one first message (i.e. the message stored in the received first message) as a second message according to the frame sequence count of the stored message, and the second message may be understood as a message read in response to the read request or may be understood as a message returned to the initiator of the read request.

That is, when the application program reads the specified frame ID packet through the interface function, the program obtains packets from different ports in the corresponding frame ID buffer. And carrying out redundant message arbitration according to the set arbitration logic, arbitrating winning messages, and returning the winning messages to the user application layer through an interface function. The buffer area is protected during reading the message, the buffer area is subjected to locking and mutual exclusion processing, when a writing request exists in the reading process, the request is suspended, and when the data copy is completed, the data copy is immediately released, and the newly received message is written.

Optionally, in order to prevent the received packet and the read packet from affecting each other, the read request may not be responded during the process of receiving the packet, and the storage of the packet may be suspended during the process of reading the packet.

With reference to the first aspect, in some implementation manners of the first aspect, unselected packets in the at least one first packet may be discarded. That is to say, when reading the message, the message which is not selected is discarded, so that the buffer space can be released, and the storage overhead is reduced.

As can be seen from the above, the frame ID is the same for each frame of the message, and the frame sequence count is the same. However, before each frame of message is sent out from the network ports of multiple data transmission channels, the MAC address and the IP address are loaded, so the MAC address and the IP address of the message sent out from multiple network ports are different, and therefore the frame ID and the IP address of the message can form a unique identifier of the message. And the frame sequence count may also be part of the unique identifier. Therefore, for the receiving end, the situation that the frame IDs are the same but the IP addresses are different may occur in the received first message.

With reference to the first aspect, in certain implementations of the first aspect, the first message is sent by the vehicle communication device from one of the network ports of the multiple data transmission channels, and the IP addresses of the multiple data transmission channels are different from each other.

That is, the first message is transmitted by using the vehicle communication device having a plurality of data transmission channels provided in the embodiment of the present application.

Alternatively, the messages described above, such as the first message, the second message, the stored message, and so on, may exist in a variety of message structures (formats). For example, there may be no encryption related fields when plaintext is transmitted and encryption related fields may be included when ciphertext is transmitted.

With reference to the first aspect, in some implementation manners of the first aspect, the first packet may include: an IP header, a user datagram protocol, UDP, protocol data unit, PDU, header, and a data field.

Alternatively, the IP address of the unique identifier may be loaded in the IP header and other elements of the unique identifier (e.g., frame ID, frame sequence count) may be loaded in the PDU header.

With reference to the first aspect, in some implementation manners of the first aspect, the first packet may further include a secure data transmission protocol region.

With reference to the first aspect, in some implementations of the first aspect, the first message may further include a digital signature area header and a key area.

In a second aspect, a method of vehicle communication is provided, the method comprising: carrying out data loading on a first message to be sent, wherein the first message to be sent comprises a frame Identification (ID); transmitting the first message to be transmitted to a plurality of data transmission channels, wherein the Internet protocol IP addresses of the plurality of data transmission channels are different from each other; loading IP addresses of a plurality of data transmission channels for a first message to be sent to obtain a plurality of second messages to be sent; and transmitting the plurality of second messages to be transmitted in the same transmission period.

In the technical scheme of the application, the identification of the message is realized by setting the unique identifier for the message, so that the synchronous sending of the message is ensured and the discrimination of the message is realized. The unique identifier may include, for example, the frame ID and IP address described above. Compared with a communication mode based on time synchronization, the time synchronization of the receiving end and the sending end is not required, meanwhile, message discrimination errors caused by different time precision and time errors of different devices are avoided, namely, the precision requirement of the vehicle-mounted device is not too strict, the time alignment is not required completely, and therefore the vehicle-mounted device is suitable for the vehicle-mounted device in the existing vehicle. In addition, an independent buffer space is set for each frame ID, so that the method is a scheme very suitable for a vehicle communication scene, and the storage and reading of the message are more convenient and faster.

It should be noted that sending messages in the same sending period may be understood as sending messages simultaneously. The data and frame ID loaded in these second messages to be transmitted are the same, but the IP addresses are different.

It should be noted that, in the first aspect, the first message refers to a message received by the vehicle communication device at the receiving end, and in the second aspect, the first message to be sent is a message generated by the vehicle communication device at the sending end before sending the message.

Optionally, after the first message to be sent is transmitted to different data transmission channels, the IP addresses of the data transmission channels may be loaded into the first message to be sent, so as to obtain a second message to be sent. That is, the second message to be sent is obtained by loading the IP address on the basis of the first message to be sent.

It should be noted that, in the first aspect, the second message refers to a message read from the buffer space of the frame ID when the vehicle communication device at the receiving end reads the message, and in the second aspect, the second message to be sent is a message obtained by further processing the first message to be sent by the vehicle communication device at the transmitting end before sending the message.

Optionally, the frame sequence count may also be loaded for the first message to be transmitted, so that the second message to be transmitted includes the frame sequence count. It may be understood that the transmitted messages are counted, that is, each frame of the messages is numbered, or that a time sequence identifier of the message frame is set. That is, the first message is identified with the time sequence of transmission.

Alternatively, a frame sequence count may be defined as the sequence identifier of the message. The accumulation may be performed at the end where the message is sent, and the frame sequence counter accumulates 1 every time a frame of the message is sent.

With reference to the second aspect, in some implementations of the second aspect, a frame sequence count may also be loaded for the second message to be sent, where the frame sequence count is used to indicate a sending order of the second message to be sent.

With reference to the second aspect, in certain implementations of the second aspect, the frame sequence count initial value may be set to 0, and the frame sequence count is less than or equal to a preset threshold.

Alternatively, the value of the frame sequence count may be incremented by 1 every time a second message to be sent is sent, and the value of the frame sequence count is zeroed when the value of the frame sequence count is incremented to be greater than or equal to the preset threshold.

Optionally, the messages, such as the first message to be sent and the second message to be sent, may have multiple message structures (formats). For example, there may be no encryption related fields when plaintext is transmitted and encryption related fields may be included when ciphertext is transmitted.

As can be seen from the above, the frame ID is the same for each frame of the message, and the frame sequence count is the same. However, before each frame of message is sent out from the network ports of multiple data transmission channels, the MAC address and the IP address are loaded, so the MAC address and the IP address of the message sent out from multiple network ports are different, and therefore the frame ID and the IP address of the message can form a unique identifier of the message. And the frame sequence count may also be part of the unique identifier.

With reference to the second aspect, in some implementation manners of the second aspect, the first message to be sent and the second message to be sent both include: the frame ID is loaded in the PDU header of the first message to be sent and the PDU header of the second message to be sent, and the IP address is loaded in the IP header of the second message to be sent.

With reference to the second aspect, in some implementations of the second aspect, the IP address is loaded in a PDU header of the second message to be sent.

With reference to the second aspect, in some implementations of the second aspect, the second message to be sent further includes a secure data transmission protocol region.

With reference to the second aspect, in some implementations of the second aspect, the second message to be sent further includes a digital signature area header and a key area.

In a third aspect, an apparatus for vehicle communication is provided that includes means for performing the method of any one of the possible implementations of the first aspect or the second aspect.

In a fourth aspect, an apparatus for vehicle communication is provided that includes a processor. The processor is coupled to the memory and is operable to execute instructions or data in the memory to implement the method of any of the possible implementations of the first aspect or the second aspect. Optionally, the communication device further comprises a memory. Optionally, the communication device further comprises a communication interface, the processor being coupled to the communication interface.

In a fifth aspect, there is provided a computer program product comprising: a computer program (also referred to as code, or instructions), which when executed, causes a computer to perform the method of any of the possible implementations of the first or second aspect.

A sixth aspect provides a computer-readable medium storing a computer program (which may also be referred to as code or instructions) which, when run on a computer, causes the computer to perform the method of any one of the possible implementations of the first or second aspect.

Drawings

Fig. 1 is a functional block diagram of a vehicle to which an embodiment of the present application is applied.

Fig. 2 is a schematic diagram of an automatic driving system to which an embodiment of the present application is applicable.

Fig. 3 is an application schematic diagram of a cloud-side command autonomous driving vehicle according to an embodiment of the present application.

Fig. 4 is a schematic diagram of multiple data transmission channel redundant communication of the vehicular communication apparatus according to the embodiment of the present application.

Fig. 5 is a schematic diagram of a processing flow for receiving a redundant packet according to an embodiment of the present application.

Fig. 6 is a schematic diagram of a processing flow for receiving a redundant packet according to an embodiment of the present application.

Fig. 7 is a schematic diagram of a processing flow for sending a redundant packet according to an embodiment of the present application.

Fig. 8 is a schematic diagram of a format of a message frame according to an embodiment of the present application.

Fig. 9 is a schematic diagram of another format of a message frame according to an embodiment of the present application.

Fig. 10 is a schematic diagram of a format of another message frame according to an embodiment of the present application.

Fig. 11 is a schematic diagram of connection of the vehicle communication device in the embodiment of the present application to the same network.

Fig. 12 is a schematic diagram of connection of the vehicle communication device in the embodiment of the present application to different networks.

Fig. 13 is a schematic diagram of a PDU message format according to an embodiment of the present application.

Fig. 14 is a schematic diagram of a sending flow of a redundant packet according to an embodiment of the present application.

Fig. 15 is a schematic diagram of a receiving flow of a redundant packet according to an embodiment of the present application.

Fig. 16 is a schematic block diagram of a vehicle communication device according to an embodiment of the present application.

Fig. 17 is a hardware configuration diagram of a vehicle communication device according to an embodiment of the present application.

Fig. 18 is a schematic diagram of a vehicle communication device according to an embodiment of the present application.

Fig. 19 is a hardware configuration diagram of a vehicle communication device according to an embodiment of the present application.

Detailed Description

The vehicle communication method and/or the vehicle communication device provided by the embodiment of the application can be applied to various vehicles. The methods and/or devices can be applied to manual driving, auxiliary driving and automatic driving. The technical solution of the embodiment of the present application is described below with reference to the accompanying drawings.

Fig. 1 is a functional block diagram of a vehicle to which an embodiment of the present application is applied. Where the vehicle 100 may be a human-driven vehicle, or the vehicle 100 may be configured to be in a fully or partially autonomous driving mode.

In one example, the vehicle 100 may control the own vehicle while in the autonomous driving mode, and may determine a current state of the vehicle and its surroundings by human operation, determine a possible behavior of at least one other vehicle in the surroundings, and determine a confidence level corresponding to a likelihood that the other vehicle performs the possible behavior, controlling the vehicle 100 based on the determined information. While the vehicle 100 is in the autonomous driving mode, the vehicle 100 may be placed into operation without human interaction.

Various subsystems may be included in vehicle 100, such as, for example, a travel system 110, a sensing system 120, a control system 130, one or more peripheral devices 140, as well as a power supply 160, a computer system 150, and a user interface 170.

Alternatively, vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple elements. In addition, each of the sub-systems and elements of the vehicle 100 may be interconnected by wire or wirelessly.

For example, the travel system 110 may include components for providing powered motion to the vehicle 100. In one embodiment, the travel system 110 may include an engine 111, a transmission 112, an energy source 113, and wheels 114/tires. Wherein the engine 111 may be an internal combustion engine, an electric motor, an air compression engine, or other type of engine combination; for example, a hybrid engine composed of a gasoline engine and an electric motor, and a hybrid engine composed of an internal combustion engine and an air compression engine. The engine 111 may convert the energy source 113 into mechanical energy.

Illustratively, the energy source 113 may include gasoline, diesel, other petroleum-based fuels, propane, other compressed gas-based fuels, ethanol, solar panels, batteries, and other sources of electrical power. The energy source 113 may also provide energy to other systems of the vehicle 100.

For example, the transmission 112 may include a gearbox, a differential, and a drive shaft; wherein the transmission 112 may transmit mechanical power from the engine 111 to the wheels 114.

In one embodiment, the transmission 112 may also include other devices, such as a clutch. Wherein the drive shaft may comprise one or more shafts that may be coupled to one or more wheels 114.

For example, the sensing system 120 may include several sensors that sense information about the environment surrounding the vehicle 100.

For example, the sensing system 120 may include a positioning system 121 (e.g., a Global Positioning System (GPS), a beidou system, or other positioning system), an Inertial Measurement Unit (IMU) 122, a radar 123, a laser range finder 124, a camera 125, and a vehicle speed sensor 126. The sensing system 120 may also include sensors of internal systems of the monitored vehicle 100 (e.g., an in-vehicle air quality monitor, a fuel gauge, an oil temperature gauge, etc.). Sensor data from one or more of these sensors may be used to detect the object and its corresponding characteristics (position, shape, orientation, velocity, etc.). Such detection and identification is a critical function of the safe operation of the autonomous vehicle 100.

The positioning system 121 may be used, among other things, to estimate the geographic location of the vehicle 100. The IMU 122 may be used to sense position and orientation changes of the vehicle 100 based on inertial acceleration. In one embodiment, the IMU 122 may be a combination of an accelerometer and a gyroscope.

For example, the radar 123 may utilize radio signals to sense objects within the surrounding environment of the vehicle 100. In some embodiments, in addition to sensing objects, radar 123 may also be used to sense the speed and/or heading of an object.

For example, the laser rangefinder 124 may utilize laser light to sense objects in the environment in which the vehicle 100 is located. In some embodiments, laser rangefinder 124 may include one or more laser sources, laser scanners, and one or more detectors, among other system components.

Illustratively, the camera 125 may be used to capture multiple images of the surrounding environment of the vehicle 100. For example, the camera 125 may be a still camera or a video camera.

Illustratively, a vehicle speed sensor 126 may be used to measure the speed of the vehicle 100. For example, the vehicle may be tested for speed in real time. The measured vehicle speed may be communicated to the control system 130 to effect control of the vehicle.

As shown in FIG. 1, a control system 130 is provided for controlling the operation of the vehicle 100 and its components. Control system 130 may include various elements, such as may include a steering system 131, a throttle 132, a braking unit 133, a computer vision system 134, a route control system 135, and an obstacle avoidance system 136.

For example, the steering system 131 may be operable to adjust the heading of the vehicle 100. For example, in one embodiment, a steering wheel system. The throttle 132 may be used to control the operating speed of the engine 111 and thus the speed of the vehicle 100.

For example, the brake unit 133 may be used to control the vehicle 100 to decelerate; the brake unit 133 may use friction to slow the wheel 114. In other embodiments, the brake unit 133 may convert the kinetic energy of the wheel 114 into an electrical current. The brake unit 133 may take other forms to slow the rotational speed of the wheels 114 to control the speed of the vehicle 100.

As shown in FIG. 1, the computer vision system 134 may be operable to process and analyze images captured by the camera 125 in order to identify objects and/or features in the environment surrounding the vehicle 100. Such objects and/or features may include traffic signals, road boundaries, and obstacles. The computer vision system 134 may use object recognition algorithms, motion from motion (SFM) algorithms, video tracking, and other computer vision techniques. In some embodiments, the computer vision system 134 may be used to map an environment, track objects, estimate the speed of objects, and so forth.

For example, route control system 135 may be used to determine a travel route for vehicle 100. In some embodiments, route control system 135 may combine data from sensors, GPS, and one or more predetermined maps to determine a travel route for vehicle 100.

As shown in fig. 1, obstacle avoidance system 136 may be used to identify, evaluate, and avoid or otherwise negotiate potential obstacles in the environment of vehicle 100.

In one example, the control system 130 may additionally or alternatively include components other than those shown and described. Or may reduce some of the components shown above.

As shown in fig. 1, vehicle 100 may interact with external sensors, other vehicles, other computer systems, or users through peripherals 140; the peripheral devices 140 may include a wireless communication system 141, an in-vehicle computer 142, a microphone 143, and/or a speaker 144, among others.

In some embodiments, the peripheral device 140 may provide a means for the vehicle 100 to interact with the user interface 170. For example, the in-vehicle computer 142 may provide information to a user of the vehicle 100. The user interface 116 may also operate the in-vehicle computer 142 to receive user input; the in-vehicle computer 142 may be operated through a touch screen. In other cases, the peripheral device 140 may provide a means for the vehicle 100 to communicate with other devices located within the vehicle. For example, the microphone 143 may receive audio (e.g., voice commands or other audio input) from a user of the vehicle 100. Similarly, the speaker 144 may output audio to a user of the vehicle 100.

As depicted in fig. 1, wireless communication system 141 may wirelessly communicate with one or more devices, either directly or via a communication network. For example, wireless communication system 141 may use 3G cellular communication; for example, Code Division Multiple Access (CDMA), EVD0, global system for mobile communications (GSM)/General Packet Radio Service (GPRS), or 4G cellular communications, such as Long Term Evolution (LTE); or, 5G cellular communication. The wireless communication system 141 may communicate with a Wireless Local Area Network (WLAN) using wireless fidelity (WiFi).

In some embodiments, the wireless communication system 141 may communicate directly with devices using an infrared link, bluetooth, or ZigBee protocols (ZigBee); other wireless protocols, such as various vehicle communication systems, for example, wireless communication system 141 may include one or more Dedicated Short Range Communications (DSRC) devices that may include public and/or private data communications between vehicles and/or roadside stations.

It should be noted that the communication scheme provided in the embodiment of the present application is mainly applicable to a scenario in which vehicle-mounted devices communicate with each other through an ethernet, and may be communication between different vehicle-mounted devices of the same vehicle, or communication between vehicle-mounted devices of different vehicles. In the embodiment of the present application, the vehicle communication device may be any device in the wireless communication system 141, or may be a communication device integrated in any vehicle-mounted device, for example, a communication device integrated in the brake unit 133, which is not listed.

As shown in fig. 1, a power supply 160 may provide power to various components of the vehicle 100. In one embodiment, power source 160 may be a rechargeable lithium ion battery or a lead acid battery. One or more battery packs of such batteries may be configured as a power source to provide power to various components of the vehicle 100. In some embodiments, the power source 160 and the energy source 113 may be implemented together, such as in some all-electric vehicles.

Illustratively, some or all of the functionality of the vehicle 100 may be controlled by a computer system 150, wherein the computer system 150 may include at least one processor 151, the processor 151 executing instructions 153 stored in a non-transitory computer readable medium, such as a memory 152. The computer system 150 may also be a plurality of computing devices that control individual components or subsystems of the vehicle 100 in a distributed manner.

For example, processor 151 may be any conventional processor, such as a commercially available Central Processing Unit (CPU).

Alternatively, the processor may be a dedicated device such as an Application Specific Integrated Circuit (ASIC) or other hardware-based processor. Although fig. 1 functionally illustrates a processor, memory, and other elements of a computer in the same block, those skilled in the art will appreciate that the processor, computer, or memory may actually comprise multiple processors, computers, or memories that may or may not be stored within the same physical housing. For example, the memory may be a hard drive or other storage medium located in a different enclosure than the computer. Thus, references to a processor or computer are to be understood as including references to a collection of processors or computers or memories which may or may not operate in parallel. Rather than using a single processor to perform the steps described herein, some components, such as the steering component and the retarding component, may each have their own processor that performs only computations related to the component-specific functions.

In various aspects described herein, the processor may be located remotely from the vehicle and in wireless communication with the vehicle. In other aspects, some of the processes described herein are executed on a processor disposed within the vehicle and others are executed by a remote processor, including taking the steps necessary to perform a single maneuver.

In some embodiments, the memory 152 may contain instructions 153 (e.g., program logic), which instructions 153 may be used by the processor 151 to perform various functions of the vehicle 100, including those described above. The memory 152 may also include additional instructions, such as instructions to send data to, receive data from, interact with, and/or control one or more of the travel system 110, the sensing system 120, the control system 130, and the peripheral devices 140.

Illustratively, in addition to instructions 153, memory 152 may also store data such as road maps, route information, location, direction, speed of the vehicle, and other such vehicle data, among other information. Such information may be used by the vehicle 100 and the computer system 150 during operation of the vehicle 100 in autonomous, semi-autonomous, and/or manual modes.

As shown in fig. 1, user interface 170 may be used to provide information to and receive information from a user of vehicle 100. Optionally, the user interface 170 may include one or more input/output devices within the collection of peripheral devices 140, such as a wireless communication system 141, an in-vehicle computer 142, a microphone 143, and a speaker 144.

In embodiments of the present application, the computer system 150 may control the functions of the vehicle 100 based on inputs received from various subsystems (e.g., the travel system 110, the sensing system 120, and the control system 130) and from the user interface 170. For example, the computer system 150 may utilize inputs from the control system 130 in order to control the brake unit 133 to avoid obstacles detected by the sensing system 120 and the obstacle avoidance system 136. In some embodiments, the computer system 150 is operable to provide control over many aspects of the vehicle 100 and its subsystems.

Alternatively, one or more of these components described above may be mounted or associated separately from the vehicle 100. For example, the memory 152 may exist partially or completely separate from the vehicle 100. The above components may be communicatively coupled together in a wired and/or wireless manner.

Optionally, the above components are only an example, in an actual application, components in the above modules may be added or deleted according to an actual need, and fig. 1 should not be construed as limiting the embodiment of the present application.

Alternatively, the vehicle 100 may be an autonomous automobile traveling on a road, and objects within its surrounding environment may be identified to determine an adjustment to the current speed. The object may be another vehicle, a traffic control device, or another type of object. In some examples, each identified object may be considered independently, and based on the respective characteristics of the object, such as its current speed, acceleration, separation from the vehicle, etc., may be used to determine the speed at which the autonomous vehicle is to be adjusted.

Optionally, the vehicle 100 or a computing device associated with the vehicle 100 (e.g., the computer system 150, the computer vision system 134, the memory 152 of fig. 1) may predict behavior of the identified objects based on characteristics of the identified objects and the state of the surrounding environment (e.g., traffic, rain, ice on the road, etc.).

Optionally, each identified object depends on the behavior of each other, and therefore, it is also possible to predict the behavior of a single identified object taking all identified objects together into account. The vehicle 100 is able to adjust its speed based on the predicted behaviour of said identified object. In other words, the autonomous vehicle is able to determine that the vehicle will need to adjust (e.g., accelerate, decelerate, or stop) to a steady state based on the predicted behavior of the object. In this process, other factors may also be considered to determine the speed of the vehicle 100, such as the lateral position of the vehicle 100 in the road on which it is traveling, the curvature of the road, the proximity of static and dynamic objects, and so forth.

In addition to providing instructions to adjust the speed of the autonomous vehicle, the computing device may also provide instructions to modify the steering angle of the vehicle 100 to cause the autonomous vehicle to follow a given trajectory and/or to maintain a safe lateral and longitudinal distance from objects in the vicinity of the autonomous vehicle (e.g., cars in adjacent lanes on the road).

The vehicle 100 may be a car, a truck, a motorcycle, a bus, a boat, an airplane, a helicopter, a lawn mower, an amusement car, a playground vehicle, construction equipment, a trolley, a golf cart, a train, a trolley, etc., and the embodiment of the present invention is not particularly limited.

In one possible implementation, the vehicle 100 shown in fig. 1 may be an autonomous vehicle, and the autonomous system is described in detail below.

The autopilot system shown in fig. 2 includes a computer system 201, wherein the computer system 201 includes a processor 203, and the processor 203 is coupled to a system bus 205. Processor 203 may be one or more processors, where each processor may include one or more processor cores. A display adapter 207(video adapter), which may drive a display 209, the display 209 coupled with the system bus 205. System bus 205 may be coupled to an input/output (I/O) bus 213 through a bus bridge 211, and I/O interface 215 may be coupled to the I/O bus. The I/O interface 215 communicates with various I/O devices, such as an input device 217 (e.g., keyboard, mouse, touch screen, etc.), a media tray 221 (e.g., CD-ROM, multimedia interface, etc.). Transceiver 223 may send and/or receive radio communication signals and camera 255 may capture digital video images of the scene and motion. Among the interfaces connected to the I/O interface 215 may be USB ports 225.

The processor 203 may be any conventional processor, such as a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, or a combination thereof.

Alternatively, the processor 203 may be a dedicated device such as an Application Specific Integrated Circuit (ASIC); the processor 203 may be a neural network processor or a combination of a neural network processor and a conventional processor as described above.

Alternatively, in some embodiments, the computer system 201 may be located remotely from the autonomous vehicle and may communicate wirelessly with the autonomous vehicle. In other aspects, some processes described herein are executed on a processor disposed within an autonomous vehicle, others being executed by a remote processor, including taking the actions necessary to perform a single maneuver.

Computer system 201 may communicate with software deploying server 249 via network interface 229. The network interface 229 may be a hardware network interface, such as a network card. The network 227 may be an external network, such as the internet, or an internal network, such as an ethernet or a Virtual Private Network (VPN). Optionally, the network 227 may also be a wireless network, such as a WiFi network, a cellular network, and the like.

It should be noted that the communication scheme provided in the embodiment of the present application is mainly applicable to a scenario in which vehicle-mounted devices communicate with each other through an ethernet, and may be communication between different vehicle-mounted devices of the same vehicle, or communication between vehicle-mounted devices of different vehicles. In the embodiment of the present application, the vehicle communication device may be a communication device independent of the vehicle-mounted apparatus, or may be a communication device integrated in any vehicle-mounted apparatus.

As shown in FIG. 2, a hard drive interface is coupled to system bus 205, and a hard drive interface 231 may be coupled to hard drive 233, and a system memory 235 is coupled to system bus 205. The data running in system memory 235 may include an operating system 237 and application programs 243. The operating system 237 may include a parser (shell)239 and a kernel (kernel)241, among other things. The shell 239 is an interface between the user and the kernel of the operating system. The shell can be the outermost layer of the operating system; the shell may manage the interaction between the user and the operating system, such as waiting for user input, interpreting the user input to the operating system, and processing the output results of the various operating systems. Kernel 241 may be comprised of those portions of an operating system that are used to manage memory, files, peripherals, and system resources. Interacting directly with the hardware, the operating system kernel typically runs processes and provides inter-process communication, CPU slot management, interrupts, memory management, IO management, and the like. Applications 243 include programs related to controlling the automatic driving of a vehicle, such as programs that manage the interaction of an automatically driven vehicle with obstacles on the road, programs that control the route or speed of an automatically driven vehicle, and programs that control the interaction of an automatically driven vehicle with other automatically driven vehicles on the road. Application programs 243 also exist on the system of software deploying server 249. In one embodiment, the computer system 201 may download an application from the software deployment server 249 when the autopilot-related program 247 needs to be executed.

For example, the application 243 may also be a program that automatically drives cars and interacts with the lane lines on the road, i.e., a program that can track the lane lines in real time.

For example, the application 243 may be a program for controlling an autonomous vehicle to perform automatic parking.

Illustratively, a sensor 253 can be associated with the computer system 201, and the sensor 253 can be used to detect the environment surrounding the computer 201.

For example, the sensor 253 can detect lanes on the road, such as lane lines, and can track lane line changes within a certain range in front of the vehicle in real time during the movement (e.g., driving) of the vehicle. For another example, the sensor 253 may detect an animal, a car, an obstacle, a crosswalk, and the like, and further, the sensor may detect an environment around the animal, the car, the obstacle, the crosswalk, and the like, such as: the environment surrounding the animal, e.g., other animals present around the animal, weather conditions, brightness of the surrounding environment, etc.

Alternatively, if the computer 201 is located on an autonomous automobile, the sensor may be a camera, infrared sensor, chemical detector, microphone, or the like.

For example, in a lane line tracking scenario, the sensor 253 may be used to detect a lane line in front of the vehicle, thereby enabling the vehicle to sense lane changes during travel to plan and adjust the vehicle's travel in real time accordingly.

For example, in an automatic parking scenario, the sensor 253 may be used to detect the size or position of a garage and surrounding obstacles around the vehicle, so that the vehicle can sense the distance between the garage and the surrounding obstacles, perform collision detection when parking, and prevent the vehicle from colliding with the obstacles.

In one example, the computer system 150 shown in FIG. 1 may also receive information from, or transfer information to, other computer systems. Alternatively, sensor data collected from the sensing system 120 of the vehicle 100 may be transferred to another computer for processing of the data, as described below with respect to FIG. 3.

Fig. 3 is an application schematic diagram of a cloud-side command autonomous driving vehicle according to an embodiment of the present application. As shown in fig. 3, data from computer system 312 may be transmitted via a network to a server 320 on the cloud side for further processing. The network and intermediate nodes may include various configurations and protocols, including the internet, world wide web, intranets, virtual private networks, wide area networks, local area networks, private networks using proprietary communication protocols of one or more companies, ethernet, WiFi, and HTTP, as well as various combinations of the foregoing; such communications may be by any device capable of communicating data to and from other computers, such as modems and wireless interfaces.

In one example, server 320 may comprise a server having multiple computers, such as a load balancing server farm, that exchange information with different nodes of a network for the purpose of receiving, processing, and transmitting data from computer system 312. The server may be configured similar to computer system 312, with processor 330, memory 340, instructions 350, and data 360.

Illustratively, the data 360 of the server 320 may include information regarding the road conditions surrounding the vehicle. For example, the server 320 may receive, detect, store, update, and transmit information related to vehicle road conditions.

For example, the information on the condition of the road around the vehicle includes information on other vehicles around the vehicle and obstacle information.

SOME existing vehicle communication methods either require complicated point-to-point wiring and have too limited transmission capacity (e.g., CIP), or require complicated communication protocols (e.g., SOME/IP) and cannot meet the requirement of redundant communication. That is, for redundant communication, the prior art cannot well implement message synchronization and cannot discriminate redundant messages. Although the real-time transmission can be realized by adopting a communication mode based on time synchronization in the existing communication field, the mode is complicated, and the discrimination of redundant messages is still difficult to adapt to the special requirements of vehicle communication.

In view of the above technical problems, embodiments of the present application provide a scheme for vehicle redundant communication, which can implement real-time transmission of vehicle redundant data and is easy to implement. The redundant sending and receiving of the message are realized mainly by arranging the multi-network-port redundant communication device, and the identification of the message is realized by setting a unique identifier and/or a message number for the message, so that the synchronous sending of the message is ensured and the discrimination of the message is realized. Compared with a communication mode based on time synchronization, the technical scheme of the application does not require the time synchronization of the receiving equipment and the sending equipment, and avoids message discrimination errors caused by different time precisions, time errors and the like of different equipment, namely, the precision requirement of the vehicle-mounted equipment is not too strict, and the time alignment is not required at all, so that the method is suitable for the vehicle-mounted equipment in the existing vehicle.

Fig. 4 is a schematic diagram of multiple data transmission channel redundant communication of the vehicular communication apparatus according to the embodiment of the present application. As shown in fig. 4, when the vehicle communication device is accessed to a network for communication, a two-way ethernet interface is used to transmit and receive data, and transmission data redundancy is realized on a link. Each ethernet has an independent Media Access Control (MAC) address, a physical layer (PHY) chip, and an independent ethernet interface (ETH).

The vehicle communication device is connected with a Micro Controller Unit (MCU) of the vehicle-mounted apparatuses so that communication between the vehicle-mounted apparatuses can be realized. The communication may be performed between different in-vehicle devices of the same vehicle, or between in-vehicle devices of different vehicles.

Alternatively, the vehicle-mounted device may be understood as a vehicle-mounted terminal device, and in the embodiment of the present application, mainly refers to a vehicle-mounted device having a communication function and capable of performing a certain function, for example, each device in the sensing system 120, each subsystem in the control system 130 and devices in each subsystem, each device in the peripheral device 140, the computer system 150, and the like shown in fig. 1. It should be understood that fig. 1 is only an example, and the vehicle-mounted device may further include any of various units and systems that may be used for controlling a vehicle, such as a vehicle interface control unit (vu), a vehicle identification unit (vu), a vehicle dynamic control (vehicle dynamic control) device, an Electronic Control Unit (ECU), an electronic steering control system (EPS), an electronic brake control system (EBS), an Antilock Brake System (ABS), and so on.

It should be noted that the vehicle communication device may be a device independent from the vehicle-mounted device, or may be a device integrated inside (i.e., part of) the vehicle-mounted device. The vehicle communication device may be, for example, a device in the wireless communication system 141 shown in fig. 1, and may be, for example, integrated in any of the above-described in-vehicle apparatuses.

As shown in fig. 4, the MCU of the in-vehicle device may transmit data (messages) sequentially through the MAC0, the PHY0, and the portal 0 in the vehicle communication apparatus, and may receive data (messages) sequentially through the portal 0, the PHY0, and the MAC 0. The MCU of the in-vehicle device may transmit data (packet) via the MAC1, PHY1, and port 1 in the vehicle communication apparatus in this order, and may receive data (packet) via the port 1, PHY1, and MAC1 in this order.

That is, the vehicle communication device shown in fig. 4 includes two data transmission channels, one of which includes the MAC0, the PHY0, and the portal 0, and the other of which includes the MAC1, the PHY1, and the portal 1.

Optionally, the two data transmission channels can independently process the transceiving data or combine the transceiving data.

Alternatively, a frame Identification (ID) may be defined for each frame of the packet, that is, each frame of the packet has a unique frame ID, and then the packet with the same frame ID may be transmitted to the target device/apparatus (device/apparatus receiving the packet) by using the two data transmission channels shown in fig. 4.

Optionally, the sent messages may also be counted, that is, each frame of the messages is numbered, or it may be understood as setting the time sequence identifier of the message frame.

Optionally, in this embodiment of the present application, the data loading may be performed in an order of an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, and a Protocol Data Unit (PDU). The PDU data is loaded by the protocol stack or application, and is primarily responsible for the frame sequence count and the loading of the frame ID already transmitted data.

Alternatively, when the PDU message is ready, it can be passed to the sending layer and then sent out through two data channels simultaneously. When a PDU is delivered to the UDP and IP layers for transmission, the IP header and UDP header are loaded by the protocol stack. Thus, when the message is sent to the network, the IP header and the frame ID form a message with unique identification.

Alternatively, for the isolation of the data link, the two network ports of the vehicle communication device can be allocated in different network segments. Alternatively, the destination addresses of portal 0 and portal 1 may be in different network segments.

When the message is delivered to the receiving end through network equipment such as a switch and the like. The receiving end can monitor and receive the message according to the set port.

Alternatively, the in-vehicle communication device may transmit the message at a fixed cycle. That is, two messages are simultaneously sent to the network by the vehicle communication device at the sending end through the two network ports at the same time. The two-frame message is loaded with the same PDU content, frame sequence count and frame ID, and the UDP header is the same. But the IP headers of the two frame messages are different. Since the two frames of messages are sent from different network ports, different source IP addresses and MAC addresses are loaded, and since the set destination addresses are also different, the destination IP address and the destination MAC address of the IP header are also different.

When the vehicular communication apparatus shown in fig. 4 receives a message, or it can be understood that when the vehicular communication apparatus shown in fig. 4 is a receiving-side vehicular communication apparatus, the messages may be received from the network port 0 and the network port 1, respectively, and the message may be selected according to the frame ID and the frame sequence count of the received message, and a specific process for receiving the message will be described in fig. 5.

Fig. 5 is a schematic diagram of a processing flow for receiving a redundant packet according to an embodiment of the present application. The individual steps shown in fig. 5 are described below.

510. And receiving the message.

Optionally, the received packet may include a check field and a unique identifier, wherein the unique identifier may include a frame identification ID and an IP address.

Alternatively, a message (e.g., a first message) may be received from a portal of a plurality (e.g., two) of data transmission channels, and the receiving processes of the plurality of data transmission channels are independent of each other.

It should be noted that each data transmission channel may include its own MAC, PHY, and network port, and when there are two data transmission channels, the same data transmission channel structure as shown in fig. 4 may be adopted.

It can be seen that there is no limit to the number of messages received in step 510.

Optionally, the unique identifier may also include a frame sequence count for indicating a transmission order of received messages (e.g., the first message) as they are transmitted.

It should be further noted that, in the present application, the sending order of the messages may be understood as the sequence of sending the messages, and is not the actual sending time of the messages. In other words, in the existing communication, the timestamp is used as the sending time sequence of the message, which is the sequence of the actual sending time, but in the present application, only the sequence of the message sending sequence does not correspond to the actual time, and it can be regarded as the sequencing of each sent message. Just by distinguishing the freshness of the messages through the sending sequence and not corresponding to the actual time, the scheme of the application does not need to strictly require the time synchronization of all the devices.

520. Checking the message, and when the checking result is 'pass', switching to execute the step 540; when the check result is "failed", step 530 is performed.

Optionally, whether the message is correct or not may be checked according to a check field of the received message (e.g., the first message), and when the message is correct, the message may be further processed, and when there is an error in the message, the message may be discarded. That is, when the message is correct, the check result is considered as "pass", and the message is further processed (for example, the process is switched to step 540); when the message is wrong, the check result is considered as "failed", and the message is discarded (step 530 is executed). This is because, in order to ensure that the data carried by the received packet is correct, a check field is often set, and the check field has a corresponding relationship with the carried content, so when the received packet has an error, the check field calculated according to the carried data will not be consistent with the check field carried when the packet is sent, and the packet can be discarded if the packet has an error.

530. And discarding the message.

Alternatively, the message that fails the verification (check) in the received message (e.g., the first message) may be discarded.

It should be noted that step 530 may not be executed, that is, the discarding of the packet may or may not be considered.

540. And storing the message.

Optionally, when the received message passes the check, the message may be stored. The scenario illustrated in fig. 4 is illustrated as follows.

For example, the first packet received from portal 0 and portal 1 may be transmitted to two separate buffers of the application program, and the application program may create a separate buffer space for each frame ID under the corresponding portal. And after receiving the messages, delivering the messages to the corresponding buffer intervals for storage according to the frame IDs. Each frame ID is allocated only one buffer space with a corresponding size, and the message received in each buffer space is stored in an overlapping manner. That is, the latest received message will cover the last message in the buffer.

550. And reading the message.

Alternatively, when the message needs to be read, the message stored in the buffer of the corresponding frame ID may be read according to the buffer (storage) of the message.

Alternatively, steps 550 and 560 may be performed after the read request is acquired. The read request may include a frame ID of the message to be read.

Optionally, after the read request is obtained, the corresponding buffer space may be found according to the frame ID of the to-be-read packet specified in the read request, and then the packet stored in the buffer space is read from the buffer space.

Optionally, at least one stored packet in the buffer space corresponding to the frame ID may be read, where the at least one stored packet includes the first packet. It should be noted that, during the execution of steps 510 and 520, the first packet passing the inspection is stored, so that the packet stored in the buffer space of each frame ID includes the first packet passing the inspection, and therefore it can also be understood that at least one first packet is stored in the buffer space of each frame ID. It should be understood that there may be no message in the cache space, which may be equivalent to a read failure, or an indication of no message being returned.

560. A message is selected, step 530 is performed when the message is not selected, and step 510 is performed when the message is selected.

Alternatively, an appropriate message may be selected from the at least one stored message as a second message according to the above frame sequence count of the stored message, and the second message may be understood as a message read in response to the read request or may be understood as a message returned to the initiator of the read request.

Alternatively, a message with a larger frame sequence count may be selected according to the frame sequence count of the message, for example, a message with a largest frame sequence count value in the buffer space may be selected as the second message.

Alternatively, it may be set that the value of the frame sequence count of the message may take a value from 0 to a maximum value, and the count is continued from 0 when the count reaches the maximum value, and therefore, when there are both the maximum value and 0, 0 is considered to be a larger count.

It should be noted that, the steps shown in fig. 5 do not need to be completely executed, and for example, only step 510 to step 540 may be executed, that is, an independent buffer space is set for each frame of packet, and the packet is stored. Steps 550 and 560 are performed when a message read is required (when a read request is received). Alternatively, it is understood that step 550 and step 560 are processes of reading a message, not a process of receiving a message, and that steps 510 to 540 are processes of receiving a message. It will also be appreciated that steps 510 through 540 are performed each time a message needs to be received, and steps 550 and 560 are performed each time a message needs to be read.

Optionally, the unselected packet of the at least one first packet may be discarded. That is to say, when reading the message, the message which is not selected is discarded, so that the buffer space can be released, and the storage overhead is reduced.

Alternatively, in order to prevent the received message and the read message from affecting each other, the read request may not be responded during the process of receiving the message, and the message may be suspended from being stored during the process of reading the message, which may be understood as that step 540 and step 550 are not executed at the same time.

As can be seen from the above, the sending and receiving messages of the multiple data transmission channels are independent from each other, and the following description will take two data transmission channels as an example in conjunction with fig. 6.

Fig. 6 is a schematic diagram of a processing flow for receiving a redundant packet according to an embodiment of the present application. The individual steps shown in fig. 6 are described below.

It should be noted that fig. 5 can be regarded as a general description of a processing flow, while fig. 6 is equivalent to a processing flow when two network ports respectively receive a message, and it can be seen from fig. 6 that the processing procedures of two paths of messages are independent, and only when a message is selected according to a frame sequence, two paths of messages can share the frame sequence, so that a message is selected from the received messages. It should also be understood that there is no restriction on the order of the two data channels since they are independent of the message processing.

511. The network port 0 receives the message.

Alternatively, step 511 may be performed using the method provided in step 510.

512. The network port 1 receives the message.

Alternatively, step 512 may be performed using the method provided in step 510.

521. The message is checked.

Alternatively, step 521 may be performed using the method provided in step 520.

522. The message is checked.

Alternatively, step 522 may be performed using the method provided in step 520.

531. And discarding the message.

Optionally, step 531 may be performed using the method provided in step 530.

532. And discarding the message.

Optionally, step 532 may be performed using the method provided in step 530.

541. And storing the message.

Alternatively, step 541 may be performed using the method provided in step 540.

542. And storing the message.

Optionally, step 542 may be performed using the method provided in step 540.

551. And reading the message.

Alternatively, step 551 may be performed using the method provided in step 550.

552. And reading the message.

Alternatively, step 552 may be performed using the method provided in step 550.

561. And selecting messages and discarding the messages which are not selected.

Alternatively, step 561 may be performed using the method provided in step 560.

562. And selecting messages and discarding the messages which are not selected.

Alternatively, step 562 may be performed using the method provided in step 560.

It should be noted that the two data transmission channels are independent from each other in performing the above steps, and the frame sequence count can be shared only when the message is selected (i.e., step 561 and step 562).

Fig. 7 is a schematic diagram of a processing flow for sending a redundant packet according to an embodiment of the present application. The individual steps of fig. 7 are described below.

701. And carrying out data loading on a first message to be sent, wherein the first message to be sent comprises a frame ID.

It should be noted that the first message (shown in fig. 5 and 6) refers to a message received by the vehicle communication device at the receiving end, and the first message to be sent is a message generated by the vehicle communication device at the sending end before sending the message in step 701.

Alternatively, data to be transmitted may be loaded in the first message to be transmitted, and a frame ID may be loaded in the header thereof.

It should be noted that details of where data, frame ID, frame sequence count, and the like are loaded in the message will be described below, and will not be expanded here.

702. And transmitting the first message to be transmitted to a plurality of data transmission channels, wherein the IP addresses of the data transmission channels are different from each other.

703. And loading the IP addresses of the plurality of data transmission channels for the first message to be sent to obtain a plurality of second messages to be sent.

It should be noted that the second message (shown in fig. 5 and fig. 6) refers to a message read from the buffer space of the frame ID when the vehicle communication device at the receiving end reads the message, and the second message to be sent is obtained by further processing the first message to be sent by the vehicle communication device at the sending end before sending the message in step 703.

Optionally, the frame sequence count may also be loaded for the first message to be transmitted, so that the second message to be transmitted includes the frame sequence count. The meaning, use, setting method, etc. of the frame sequence count may refer to the related description above and will not be repeated for brevity. It is also understood that the loading of the frame sequence count may occur at any time before, during, or after step 701 and step 703, as long as it is performed before step 704 is performed, and that no other restrictions exist.

704. And transmitting a plurality of second messages to be transmitted in the same transmission period.

Optionally, when sending the second message to be sent, the second message to be sent may be sent from the network port of each data transmission channel of the multiple data transmission channels.

It should be noted that sending messages in the same sending period may be understood as sending messages simultaneously. The data and frame ID loaded in the second message to be transmitted are the same, but the IP addresses are different.

Fig. 8 is a schematic diagram of a format of a message frame according to an embodiment of the present application. As shown in fig. 8, the length of a frame message is less than or equal to 1500 bytes.

Optionally, the message frame may include: an IP header (header), a UDP header, a PDU header, a digital signature area (signature optional) header, a data area, a secure data transfer protocol area, and a key area.

The standard IP header includes 20 bytes and the standard UDP header includes 8 bytes, and as shown in fig. 8, the IP header and the UDP header total 28 bytes.

The PDU header includes 32 bytes, in this embodiment, two quantities, namely, a packet sequence count and a frame ID, are added to the PDU header, and the same setting as that of the existing PDU header may be adopted for other PDU components, for example, the data type, the data length, the frame check sequence, and the like may be set in the PDU, and the specific contents will be described in fig. 13 and will not be expanded here.

Optionally, the frame ID is a unique identifier of the PDU user data structure, unique in the protocol stack.

Alternatively, the frame ID may form a unique identifier within the PDU along with the source IP.

Optionally, the packet sequence count is to count the transmitted packets, and count the packet sequence count from 0, and every time a PDU packet is transmitted, the packet count is accumulated by 1, and when the count reaches the maximum value, the packet sequence count starts from 0 again.

Alternatively, a separate packet sequence count may be set for each frame ID.

Optionally, the PDU packet header includes a check field, for example, a Frame Check Sequence (FCS) may be included.

The digital signature area comprises a header and a key area, wherein the header of the digital signature area is positioned behind the PDU header, the key area is positioned at the end of the message frame, the lengths of the header and the key area are not fixed, and the digital signature area can be set according to actual conditions.

Alternatively, the digital signature region may be used to transmit an encrypted public key. The encryption algorithms with different security levels can be selected arbitrarily to encrypt the message. Such as RSA secure encryption algorithms, HAL secure encryption algorithms, and may custom check encryption algorithms.

The data (data) area refers to an area for transmitting data. The length of the message (the sum of the byte length of the data and the byte lengths of the above parts) does not exceed the requirement of network transmission, and for example, the byte length of the message may be set to be less than or equal to 1500.

Optionally, the data area of each packet may be customized in length according to the number of bytes actually used. The message length is loaded in the message length field of the PDU header. In order to make a receipt acknowledgement. The data area can customize the type of the semaphore according to the type of the transmission data, for example, defining the signal by bit offset or defining different signals by byte offset.

It should be noted that the data area may select ciphertext transmission or plaintext transmission according to the requirement of transmitting data.

The secure data transmission protocol (safe data transmission protocol) area is used for storing verification information of secure transmission. The secure transmission data area supports different secure data transmission protocols, for example, the SDTV2 protocol may be used. The secure data transfer protocol region may include 16 bytes.

It should be noted that fig. 8 is only an example of a message frame format, and other message frame formats may be adopted, for example, the message frame format shown in fig. 9 or fig. 10 may be adopted.

Fig. 9 is a schematic diagram of another format of a message frame according to an embodiment of the present application. As shown in fig. 9, the length of a frame message is less than or equal to 1500 bytes.

Optionally, the message frame shown in fig. 9 may include: IP header, UDP header, PDU header, data field, secure data transfer protocol field. Fig. 9 may be considered a message form that encrypts only messages but does not verify secure transmissions, or may be understood as a way of ciphertext transmission.

Fig. 10 is a schematic diagram of a format of another message frame according to an embodiment of the present application. As shown in fig. 10, the length of a frame message is less than or equal to 1500 bytes.

Optionally, the message frame shown in fig. 10 may include: IP header, UDP header, PDU header, digital signature field header, data field, key field.

It should be noted that fig. 9 and fig. 10 are only examples of two other message formats, and other situations may also exist, for example, there may be no secure data transmission protocol and no digital signature authentication requirement. That is, the message may also include only: an IP header, a UDP header, a PDU header, and a data field, which may have a data length of 0-1440 bytes.

Fig. 11 is a schematic diagram of connection of the vehicle communication device in the embodiment of the present application to the same network. As shown in fig. 11, the apparatus #1 and the apparatus #2 are both in-vehicle apparatuses, both of which include vehicle communication means, but it should be understood that they may be separate vehicle communication means. The two are connected in two paths through a plurality of exchangers.

Optionally, the first path between the device #1 and the device #2 includes N switches, where N is a positive integer, and the second path between the device #1 and the device #2 includes M switches, where M is a positive integer. In order to distinguish the switches in the two paths, the N switches in the first path are numbered from 1 to N, and the switches in the second path are numbered from N +1 to N + M.

It should be noted that, since fig. 11 shows that the two networks are in the same network, the two networks refer to two networks in the same network, and not to two networks. The most intuitive difference is that there is a connection between the two switches shown in fig. 11, for example, switch #1 is connected to switch # N +1, which can prevent the communication loss caused by the switch failure or the link failure.

Alternatively, the device #1 and the device #2 have two ports, respectively, and the two ports have different IP addresses and are separated during transmission.

Fig. 12 is a schematic diagram of connection of the vehicle communication device in the embodiment of the present application to different networks. As shown in fig. 12, the apparatus #1, the apparatus #2, and the apparatus #3 are all in-vehicle apparatuses, and all three include vehicle communication devices, but it should be understood that the three may be independent vehicle communication devices. Device #1, device #2, and device #3 are respectively connected to two networks, network a and network B.

Optionally, the network a includes a plurality of switches, which may be numbered by switches Ai, where i is a positive integer.

Optionally, the network B includes a plurality of switches, and may be numbered by a switch Bj, where j is a positive integer.

It should be noted that fig. 12 shows different networks, and therefore, the network a and the network B are different networks. The most intuitive difference is that the switches of network a and network B shown in fig. 12 are isolated, e.g., switch a1 is not connected to any switch in network B.

It should be further noted that fig. 12 is only an example, but there is no limitation on the number of devices, the number of networks, the number of switches in the networks, and the like.

In the scenario shown in fig. 12, one network port of the device #1, the device #2, and the device #3 is accessed into the network a, and the other network port is accessed into the network B. The device #1, the device #2, and the device #3 may simultaneously transmit data from the two network ports to the two networks in the same packet format defined in the embodiment of the present application. Two network ports of another device are also accessed into the network, thus completing the receiving and arbitration of the message. The message of any network port can be transmitted in a cost cycle when arriving preferentially, the characteristics of the data link in the redundant network are fully utilized, and the transmission timeliness and reliability of the data in the whole network are improved.

The following illustrates the process of receiving and sending messages.

The first is the setting of the network topology and the data flow. The IP of the two network ports of the vehicle-mounted device are respectively allocated in different network segments, and both the two network ports are accessed into the switch network (including the network shown in fig. 11 and the network shown in fig. 12).

Assume that the IP of portal 1 of device #1 is configured to be 10.0.0.10/21, the IP of portal 0 of device #1 is configured to be 10.0.8.10/21, the IP of portal 1 of device #2 is configured to be 10.0.0.20/21, and the IP of portal 0 of device #2 is configured to be 10.0.8.20/21.

When the vehicle-mounted equipment sends the message, the vehicle-mounted equipment can simultaneously send the same PDU message from the network port 1 and the network port 0 in the same communication period. The frame ID of the PDU packet is the same as the frame sequence count. The UDP header of the PDU message is loaded by the system to record the source port, the destination port and the message length. Different source ports may be different by implementation, but the destination port values are the same. The data length is also the same. Before the PDU message is sent out from the network port 1 and the network port 0, the IP header is loaded by the protocol stack of the network port according to the IP information of the network port, so that the contents of the IP headers of the PDU message sent out by the two network ports are different.

When the vehicle-mounted device receives the messages from the network port 1 and the network port 0, the data transmission channels where the network port 1 and the network port 0 are located may independently process the received messages, for example, the messages may be independently checked, and the messages may be discarded or stored according to the checking result.

Fig. 13 is a schematic diagram of a PDU message format according to an embodiment of the present application. As shown in fig. 13, the PDU message frame includes: a frame header comprising 32 bytes and a data area, which may comprise less than or equal to 1440 bytes of data.

The frame header includes a frame sequence count (sequence counter), a frame ID, a protocol version (protocol version), a data type (data type), a data length (data length), a reserved field (reserve), a reserved field 01, a reserved field 02, a reserved field 03, a data area (data), and a frame check sequence.

The frame sequence count is counted and updated by the vehicle communication device at the transmitting end, and the vehicle communication device at the receiving end can mainly read the message by using the frame sequence count.

The frame sequence count is accumulated from 0, and when the vehicle communication device at the sending end sends a message for each frame, the frame sequence count is accumulated by 1, and when the frame sequence count reaches the maximum value, the frame sequence count is reset to zero (namely, when the frame sequence count is larger than or equal to a preset threshold value), and the frame sequence count is reset from zero.

Alternatively, the preset threshold (maximum value) may be set to 0xFFFF FFFF.

It should be noted that, in the embodiment of the present application, the frame sequence count is mainly used to assist in reading the message, so that an updated (later) message can be selected, the message selection rule is very suitable for this special application scenario of vehicle communication, but this method is not suitable for common communication (for example, communication between terminals such as mobile phones) because the amount of data involved in a common communication scenario is very large, and if the counting manner is adopted, the frame sequence has reached the maximum value, but there is a case where data has no way to be stored, which causes problems such as data loss. In addition, in the present application, an independent buffer space needs to be configured for each frame ID, which is also not satisfied by common communication scenarios. For the above reasons, the time synchronization method is currently adopted in common communication scenarios, but the counting method cannot be adopted. If the communication mode based on time synchronization is applied to the communication in the vehicle field, compared with the scheme of the application, the method is very complicated, and the scheme without the application is concise and easy to realize.

Alternatively, the vehicle communication device at the receiving end may arbitrate message freshness according to frame sequence count, and the larger the frame sequence count value, the fresher the data. When the data frame sequence counts received by two independent network ports of the vehicle communication device at the receiving end are inconsistent, the message with the larger frame sequence count value is selected for analysis, and the message with the smaller frame sequence count value can be discarded. If the frame sequence count values of the two network ports are the same, the message of the specified default network port can be selected for analysis. For example, a message that selects port 0 when the values are the same, a message that selects port 1 when the values are the same, a message that selects a port that arrives earlier in port 0 and port 1 when the values are the same, a message that selects a port that arrives later in port 0 and port 1 when the values are the same, or the like may be specified, and they are not listed one by one.

Optionally, the unique identifier of the packet may be set to include a frame ID and a source IP of the packet. As can be seen from the above, the frame ID of each frame packet is the same as the frame sequence count. However, before each frame of message is sent out from the network ports of multiple data transmission channels, the MAC address and the IP address are loaded, so the MAC address and the IP address of the message sent out from multiple network ports are different, and therefore the frame ID and the IP address of the message can form a unique identifier of the message. And the frame sequence count may also be part of the unique identifier.

The protocol version is mainly used to define PDU version information to determine its compatibility.

The data type refers to a PDU communication data type, and is generally defined as process data and message data.

The data length is understood as the data frame length, which refers to the data field length of the actual PDU message and does not include a 20-byte header.

The frame check sequence refers to a protocol sequence for checking a PDU header. Optionally, a Cyclic Redundancy Check (CRC) check may be performed using the generic FCS.

The data size of the data area may be 0-1440 bytes, that is, the data size is only required to be less than the total byte length limit of the PDU message, and the length of the header of the message needs to be deducted from the total byte length limit of the PDU message. Alternatively, the signal table mapping may be defined by a sub-protocol in the appendix.

Alternatively, if a secure data transmission protocol and secure encryption are used, the data area may include the above-described secure transmission check area, digital signature area, and key area.

Fig. 14 is a schematic diagram of a sending flow of a redundant packet according to an embodiment of the present application. The steps of fig. 14 are described below.

1401. And issuing the message.

It can be understood that when a message needs to be sent, the message is issued. When the vehicle communication device of the vehicle-mounted device needs to transmit a specified PDU message, the data area of the PDU is loaded in the application program. Taking PDU 101 as an example, for PDU 101, data comes from the MCU of the vehicle-mounted device. After the data are loaded in the data area, the messages can be respectively transmitted to different data transmission channels, and the data transmission channels execute the subsequent operations of loading frame ID, loading frame sequence counting, message sending and the like.

Alternatively, after the data area is loaded, the information of the frame header of the packet may be continuously loaded, and the FCS may be calculated according to the information of the current frame header, so as to complete data loading, and then the packet may be transmitted to the protocol stacks of different network transmission channels. And adding IP header and MAC address information of each network port into a protocol stack.

Alternatively, a timer may be used to send the start message, and wait for the triggering of the timer, after the triggering of the timer, the message is sent out from different network ports of different data transmission channels at the same time, and the frame sequence count value is incremented by 1. The frame sequence count is accumulated after the transmission action is executed regardless of the transmission failure or not, and is not affected by the transmission success or not. That is, the loop count operations of step 1411 and step 1421 are performed after each execution of the transmit action.

1411. Portal 0 cycle count.

Alternatively, portal 0 may use a counter to cycle through the number of times a message is sent.

1421. Portal 1 cycle count.

It should be noted that steps 1411-1415 are operations performed by the data transmission channel where the port 0 is located, and steps 1421-1424 are operations performed by the data transmission channel where the port 1 is located, and the operations of the two data transmission channels are independent of each other.

When the value of the frame sequence count reaches the maximum value (is greater than or equal to the maximum value), step 1412 or step 1421 is executed, the counter is cleared (i.e., the value of the frame sequence count is reset to zero), and step 1413 or step 1423 is executed to update the PDU message regardless of transmission failure.

The value of the frame sequence count is generated by a transmission counter and is continuously accumulated during power-up.

Alternatively, the frame sequence count may be set to be non-software-modifiable externally in order to avoid arbitration collisions in the network for sending messages. When the power is on, the sending counter is set to be 0, namely the initial value of the frame sequence count is 0, then every time the message is sent, the counter is added with 1, the value of the frame sequence count is accumulated with 1, until the value of the frame sequence count is accumulated to be larger than or equal to the preset threshold value, the counter is cleared, the value of the frame sequence count returns to zero, and the counting is started from 0 again.

Alternatively, the data transfer field may be loaded in the data area after being calculated by the SID locally according to an algorithm of the secure data transfer protocol.

And after the digital signature area finishes loading the fields, the message data area encryption is finished and the message data area encryption is transmitted to a sending layer. And sending the data by a protocol stack sending area.

After all the messages are loaded, step 1415 and step 1422 are executed, and the messages are sent out from port 0 and port 1, respectively. If the time interval or the number of failed transmissions exceeds the predetermined value, step 1403 may be executed to cancel the distribution of the message.

When it needs to be noted, the PDU ID, the frame sequence count, the IP and the MAC form a displacement identifier of the frame message in the network. In the same sending period, the message with the same PDU ID and frame sequence count has two frames. In the same sending period, the IP headers and the MAC addresses of two messages with the same PDU ID are different, so that the identifiers of the two messages with the same ID have uniqueness.

It should be understood that fig. 14 is an example of a flow for sending a redundant packet, and a specific process may refer to the related description of fig. 7, and therefore, for brevity, will not be described again.

Fig. 15 is a schematic diagram of a receiving flow of a redundant packet according to an embodiment of the present application. The steps of fig. 15 are described below.

1501. And subscribing the PDU.

It should be noted that the PDU subscription may be understood as one of the trigger conditions for receiving the packet, and may also be understood as information for starting a packet receiving process.

1502. The mode selection, when RT mode is selected, performs step 1504, and when SDT or secure mode is selected, performs step 1503.

It should be noted that the RT mode is understood as the plaintext transmission described above, that is, the message is not encrypted, and the decryption operation is not required. SDT and security mode may be understood as ciphertext transmission as described above, that is, a message is encrypted, and at this time, the message needs to be decrypted first.

1503. And decrypting the message.

It should be noted that only the encrypted message needs to perform the step 1503.

1504. And analyzing the received message.

It can be understood that the content of the received message is read out, so as to check whether the message has an error by using the check field of the received message.

1505. The message is checked.

Alternatively, step 1505 may be performed using the method provided in step 520 of FIG. 5.

1506. Reading and selecting messages.

Alternatively, step 1506 may be performed using the method of steps 550 and 560 in fig. 5.

It should be understood that fig. 15 is an example of a flow of receiving a redundant packet and reading in a packet, and a specific process may refer to related descriptions in fig. 5 or fig. 6, and therefore, for brevity, will not be described again.

The vehicle communication method according to the embodiment of the present application is described above, and the vehicle communication device according to the embodiment of the present application is described below. It is to be understood that the vehicular communication apparatus described hereinafter is capable of executing the respective processes of the vehicular communication method of the embodiment of the present application, and the repetitive description will be appropriately omitted when describing the embodiment of the apparatus.

Fig. 16 is a schematic diagram of a vehicle communication apparatus according to an embodiment of the present application, and the apparatus 2000 includes a receiving unit 2001 and a processing unit 2002. The apparatus 2000 may be configured to perform each step performed by the vehicle communication apparatus on the receiving side in the vehicle communication method according to the embodiment of the present application.

For example, the receiving unit 2001 may be configured to perform step 510, step 550 in the method shown in fig. 5, and the processing unit 2002 may be configured to perform step 520 to step 540, step 560 in the method shown in fig. 5. For another example, the receiving unit 2001 may be used to perform steps 511, 512 and steps 551, 552 in the method shown in fig. 6, and the processing unit 2002 may be used to perform steps 521, 522, 531, 532, 541, 542 and steps 561, 562 in the method shown in fig. 6. For another example, the receiving unit 2001 may be configured to execute step 1501 in the method illustrated in fig. 15, and the processing unit 2002 may be configured to execute step 1502 to step 1506 in the method illustrated in fig. 15.

The device 2000 may be a vehicle communication device as shown in fig. 4.

Fig. 17 is a hardware configuration diagram of a vehicle communication device according to an embodiment of the present application. The apparatus 3000 includes a memory 3001, a processor 3002, a communication interface 3003, and a bus 3004. The memory 3001, the processor 3002, and the communication interface 3003 are communicatively connected to each other via a bus 3004.

The device 3000 may be used to perform the various steps performed by the vehicle communication device at the receiving end in the above vehicle communication method.

Alternatively, the memory 3001 may be a Read Only Memory (ROM), a static memory device, a dynamic memory device, or a Random Access Memory (RAM). The memory 3001 may store a program, and the processor 3002 and the communication interface 3003 are used to perform the respective steps of the vehicle communication method of the embodiment of the present application when the program stored in the memory 3001 is executed by the processor 3002.

Alternatively, the storage 3001 may have the function of the storage 152 shown in fig. 1 or the function of the system memory 235 shown in fig. 2, or the function of the storage 340 shown in fig. 4, so as to realize the above-described function of storing programs. Alternatively, the processor 3002 may employ a general-purpose CPU, a microprocessor, an ASIC, a Graphics Processing Unit (GPU) or one or more integrated circuits, and is configured to execute a relevant program to implement the functions required to be performed by the units in the vehicle communication device according to the embodiment of the present application, or to execute the steps of the vehicle communication method according to the embodiment of the present application.

Alternatively, the processor 3002 may have the functions of the processor 151 shown in fig. 1 or the functions of the processor 203 shown in fig. 2, or the functions of the processor 330 shown in fig. 3, so as to implement the above-described functions of executing the related programs.

Alternatively, the processor 3002 may be an integrated circuit chip having signal processing capability. In implementation, the steps of the vehicle communication method according to the embodiment of the present application may be implemented by integrated logic circuits of hardware in a processor or instructions in the form of software.

Alternatively, the processor 3002 may be a general-purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, or discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in the memory, and the processor reads information in the memory, and in conjunction with hardware thereof, performs functions required to be performed by the units included in the vehicle communication apparatus of the embodiment of the present application, or performs the respective steps of the vehicle communication method of the embodiment of the present application.

Alternatively, communication interface 3003 may enable communication between the apparatus and other devices or communication networks using transceiver means such as, but not limited to, a transceiver.

Bus 3004 may include a pathway to transfer information between various components of the device (e.g., memory, processor, communication interface).

Fig. 18 is a schematic diagram of a vehicle communication device according to an embodiment of the present application, and the device 4000 includes a transmitting unit 4001 and a processing unit 4002. The apparatus 4000 may be configured to perform each step performed by the vehicle communication apparatus at the transmitting end in the vehicle communication method according to the embodiment of the present application.

For example, the sending unit 4001 may be configured to perform step 704 in the method shown in fig. 7, and the processing unit 4002 may be configured to perform steps 701 to 703 in the method shown in fig. 7. For another example, the sending unit 4001 may be configured to perform step 1414 and step 1424 in the method shown in fig. 14, and the processing unit 4002 may be configured to perform other steps in the method shown in fig. 14.

The above-described device 4000 may be a vehicle communication device shown in fig. 4.

Fig. 19 is a hardware configuration diagram of a vehicle communication device according to an embodiment of the present application. The apparatus 5000 includes a memory 5001, a processor 5002, a communication interface 5003, and a bus 5004. The memory 5001, the processor 5002 and the communication interface 5003 are connected to each other via a bus 5004.

The apparatus 5000 may be configured to perform each step performed by the vehicle communication apparatus at the transmitting end in the above vehicle communication method.

Alternatively, memory 5001 may be ROM, static storage, dynamic storage, or RAM. The memory 5001 may store programs that, when executed by the processor 5002, the processor 5002 and the communication interface 5003 are used to perform the various steps of the vehicle communication method of the embodiments of the present application.

Alternatively, the storage 5001 may have the functions of the storage 152 shown in fig. 1 or the functions of the system memory 235 shown in fig. 2, or the functions of the storage 340 shown in fig. 4, so as to realize the functions of storing programs described above. Alternatively, the processor 5002 may employ a general-purpose CPU, a microprocessor, an ASIC, a GPU or one or more integrated circuits for executing related programs to implement the functions required to be performed by the units in the vehicle communication device of the embodiment of the present application or to execute the steps of the vehicle communication method of the embodiment of the present application.

Alternatively, the processor 5002 may have the functions of the processor 151 shown in fig. 1 or the functions of the processor 203 shown in fig. 2, or the functions of the processor 330 shown in fig. 3, so as to implement the above-described functions of executing the related programs.

Alternatively, the processor 5002 may also be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the vehicle communication method according to the embodiment of the present application may be implemented by integrated logic circuits of hardware in a processor or instructions in the form of software.

Alternatively, the processor 5002 may also be a general purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in the memory, and the processor reads information in the memory, and in conjunction with hardware thereof, performs functions required to be performed by the units included in the vehicle communication apparatus of the embodiment of the present application, or performs the respective steps of the vehicle communication method of the embodiment of the present application.

Alternatively, the communication interface 5003 may enable communication between the apparatus and other devices or communication networks using transceiver means such as, but not limited to, a transceiver.

Bus 5004 can include a pathway to transfer information between various components of the device (e.g., memory, processor, communication interfaces).

Embodiments of the present application also provide a computer program product containing instructions, which when executed by a computer, cause the computer to implement the method in the above method embodiments.

For the explanation and beneficial effects of the related content in any vehicle communication device, reference may be made to the corresponding method embodiments provided above, and details are not repeated here.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the description of the present application in the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

The embodiment of the present application does not particularly limit a specific structure of an execution subject of the method provided by the embodiment of the present application, as long as communication can be performed by the method provided by the embodiment of the present application by running a program in which codes of the method provided by the embodiment of the present application are recorded.

Various aspects or features of the disclosure may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disk, floppy disk, or magnetic tape), optical disks (e.g., Compact Disk (CD), Digital Versatile Disk (DVD), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROM), card, stick, or key drive, etc.).

Various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, but is not limited to: wireless channels and various other media capable of storing, containing, and/or carrying instruction(s) and/or data.

It should be noted that when the processor is a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, the memory (memory module) may be integrated into the processor.

It should also be noted that the memories described herein are intended to comprise, without being limited to, these and any other suitable types of memories.

Those of ordinary skill in the art will appreciate that the various illustrative elements and steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. Furthermore, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application, or portions thereof, may be embodied in the form of a computer software product stored in a storage medium, the computer software product including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to perform all or part of the steps of the methods described in the embodiments of the present application. The foregoing storage media may include, but are not limited to: various media capable of storing program codes, such as a U disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of vehicle communication, comprising:

receiving a first message, wherein the first message comprises a check field and a unique identifier, and the unique identifier comprises a frame Identification (ID) and an Internet Protocol (IP) address;

checking the first message according to the check field of the first message;

and if the first message passes the check, storing the first message into a cache space corresponding to the frame ID according to the frame ID.

2. The method of claim 1, wherein the first packet is discarded if the first packet fails the check.

3. The method of claim 1 or 2, wherein the unique identifier further comprises a frame sequence count, the method further comprising:

acquiring a reading request, wherein the reading request comprises a frame ID of a message to be read;

reading at least one first message from a cache space corresponding to a frame ID of the message to be read, wherein a value of a frame sequence count of the at least one first message is used for representing a transmitted sequence of the at least one first message;

and selecting the message with the maximum frame sequence count value from the at least one first message as a second message and returning the second message.

4. The method of claim 3, wherein the method further comprises:

and discarding the first message which is not selected in the at least one first message.

5. The method according to any of claims 1 to 4, wherein the first packet comprises: an IP header, a User Datagram Protocol (UDP) header, a Protocol Data Unit (PDU) header, and a data field, the IP address of the unique identifier being loaded in the IP header, and other elements of the unique identifier being loaded in the PDU header.

6. The method of claim 5, wherein the first message further comprises: a secure data transfer protocol area.

7. The method of claim 5 or 6, wherein the first message further comprises: a digital signature area header and a key area.

8. A method of vehicle communication, comprising:

carrying out data loading on a first message to be sent, wherein the first message to be sent comprises a frame Identification (ID);

transmitting the first message to be sent to a plurality of data transmission channels, wherein the internet protocol IP addresses of the plurality of data transmission channels are different from each other;

loading the IP addresses of the plurality of data transmission channels for the first message to be sent to obtain a plurality of second messages to be sent;

and transmitting the plurality of second messages to be transmitted in the same transmission period.

9. The method of claim 8, wherein the method further comprises:

and loading a frame sequence count for the plurality of second messages to be sent, wherein the frame sequence count is used for representing the sending sequence of the second messages to be sent.

10. The method of claim 9, wherein the frame sequence count initial value is 0 and the frame sequence count is less than or equal to a preset threshold, the method further comprising:

and accumulating the value of the frame sequence count by 1 every time the second message to be sent is sent, and when the value of the frame sequence count is accumulated to be greater than or equal to the preset threshold value, returning the value of the frame sequence count to zero.

11. The method according to any of claims 8 to 10, wherein the first message to be transmitted and the second message to be transmitted each comprise: the frame ID is loaded in the PDU header of the first message to be transmitted and the PDU header of the second message to be transmitted, and the IP address is loaded in the IP header of the second message to be transmitted.

12. The method of claim 11, wherein the frame sequence count is loaded in a PDU header of the second message to be sent.

13. The method according to claim 11 or 12, wherein the second message to be sent further comprises: a secure data transfer protocol area.

14. The method according to any one of claims 11 to 13, wherein the second message to be sent further comprises: a digital signature area header and a key area.

15. An apparatus for vehicle communication, comprising:

the device comprises a receiving unit, a sending unit and a receiving unit, wherein the receiving unit is used for receiving a first message, the first message comprises a check field and a unique identifier, and the unique identifier comprises a frame Identification (ID) and an Internet Protocol (IP) address;

the processing unit is used for checking the first message according to the check field of the first message;

if the first packet passes the check, the processing unit is further configured to store the first packet in a cache space corresponding to the frame ID according to the frame ID.

16. The apparatus of claim 15, wherein the processing unit is further configured to discard the first packet if the first packet fails the check.

17. The apparatus according to claim 15 or 16, wherein the unique identifier further comprises a frame sequence count, and the receiving unit is further configured to obtain a read request, where the read request comprises a frame ID of a message to be read;

the processing unit is further configured to read at least one first packet from a cache space corresponding to a frame ID of the packet to be read, where a value of a frame sequence count of the at least one first packet is used to indicate a transmitted order of the at least one first packet;

the processing unit is further configured to select, from the at least one first packet, a packet whose corresponding frame sequence count value is the largest as a second packet and return the second packet.

18. The apparatus of claim 17, wherein the processing unit is further configured to discard non-selected ones of the at least one first packet.

19. The apparatus according to any one of claims 15 to 18, wherein the first packet comprises: an IP header, a User Datagram Protocol (UDP) header, a Protocol Data Unit (PDU) header, and a data field, the IP address of the unique identifier being loaded in the IP header, and other elements of the unique identifier being loaded in the PDU header.

20. The apparatus of claim 19, wherein the first message further comprises: a secure data transfer protocol area.

21. The apparatus of claim 19 or 20, wherein the first packet further comprises: a digital signature area header and a key area.

22. An apparatus for vehicle communication, comprising:

the processing unit is used for carrying out data loading on a first message to be sent, and the first message to be sent comprises a frame identification ID;

the processing unit is further configured to transmit the first to-be-transmitted message to a plurality of data transmission channels, where internet protocol IP addresses of the plurality of data transmission channels are different from each other;

the processing unit is further configured to load the IP addresses of the multiple data transmission channels for the first to-be-transmitted message to obtain multiple second to-be-transmitted messages;

and the sending unit is used for sending the plurality of second messages to be sent in the same sending period.

23. The apparatus of claim 22, wherein the processing unit is further configured to load a frame sequence count for the second plurality of messages to be sent, the frame sequence count indicating an order in which the second messages to be sent are sent.

24. The apparatus of claim 23, wherein the frame sequence count initial value is 0, and wherein the frame sequence count is less than or equal to a preset threshold, the processing unit further configured to:

and each time the sending unit sends the second message to be sent once, the processing unit accumulates the value of the frame sequence count by 1, and when the value of the frame sequence count is accumulated to be greater than or equal to the preset threshold value, the processing unit returns the value of the frame sequence count to zero.

25. The apparatus according to any of claims 22 to 24, wherein the first message to be transmitted and the second message to be transmitted each comprise: the frame ID is loaded in the PDU header of the first message to be transmitted and the PDU header of the second message to be transmitted, and the IP address is loaded in the IP header of the second message to be transmitted.

26. The apparatus of claim 25, wherein the frame sequence count is loaded in a PDU header of the second message to be sent.

27. The apparatus according to claim 25 or 26, wherein the second message to be sent further comprises: a secure data transfer protocol area.

28. The apparatus according to any one of claims 25 to 27, wherein the second message to be sent further comprises: a digital signature area header and a key area.

29. An apparatus for vehicle communication, comprising:

a processor to execute computer instructions stored in the memory to cause the apparatus to perform: the method of any one of claims 1 to 7.

30. An apparatus for vehicle communication, comprising:

a processor to execute computer instructions stored in the memory to cause the apparatus to perform: the method of any one of claims 8 to 14.

31. A computer storage medium, characterized in that a computer program is stored thereon, which computer program, when executed by a computer, causes the method according to any of claims 1 to 7 to be carried out.

32. A computer storage medium, characterized in that a computer program is stored thereon, which computer program, when being executed by a computer, causes the method according to any of the claims 8 to 14 to be carried out.