WO2022056894A1

WO2022056894A1 - Vehicle communication method and vehicle communication device

Info

Publication number: WO2022056894A1
Application number: PCT/CN2020/116393
Authority: WO
Inventors: 李�杰
Original assignee: 华为技术有限公司
Priority date: 2020-09-21
Filing date: 2020-09-21
Publication date: 2022-03-24
Also published as: CN112585931A

Abstract

The present application provides a vehicle communication method and a vehicle communication device, relating to the field of vehicle communication. The method comprises: receiving a first packet, the first packet comprising a check field and a unique identifier, and the unique identifier comprising a frame identifier (ID) and an Internet Protocol (IP) address; checking the first packet according to the check field of the first packet; and storing, according to the frame ID, the first packet that has passed the checking into a cache space corresponding to the frame ID. The method is applicable to vehicles such as networked vehicles, intelligent vehicles and autonomous vehicles, and achieves packet identification by configuring a unique identifier for each packet, thereby ensuring synchronous packet transmission and achieving packet discrimination. Moreover, the accuracy requirement on vehicle-mounted devices is not strict, and time alignment is not required at all, allowing the method to be applied to existing vehicle-mounted devices in vehicles. In addition, each frame ID is provided with an independent cache space, thereby facilitating and accelerating packet storage and reading.

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 communication device.

Background technique

With the continuous development of automotive technology, the demand for communication between in-vehicle devices is getting higher and higher. In order to meet the communication requirements, it is usually necessary to adopt a redundant connection method for the in-vehicle equipment to perform redundant backup of the access link. In this redundant connection mode, higher requirements are put forward for the processing methods during packet transmission and reception, for example, how to synchronize packets, how to identify packets, and so on. For example, an in-vehicle device first sends two frames of messages with the same content to the network for transmission, and the two frames of messages finally arrive at the designated network port of the target device (for example, another in-vehicle device or a host computer device, etc.). and the designated port, but during this period, the in-vehicle device needs to establish an effective mechanism and logic to ensure that two frames of the same content can be sent synchronously, and the target device needs to complete the discrimination of the above two frames in the same period. . In order to realize the above process, it is usually necessary to develop a complete set of protocol mechanisms to ensure the reliability of its transmission and reception, as well as the judging of application logic, and finally realize the real-time transmission and redundancy arbitration of packets at the Ethernet network layer.

Common Industrial Protocol (CIP) is a communication protocol applied in industrial automation, but because this connection-based communication usually needs to establish a communication path, and is usually a point-to-point communication method, it will take up a lot of connection resources. And the transmission capacity is also very limited, so it cannot be widely used in the field of vehicles. In order to achieve good communication between in-vehicle devices, automotive Ethernet emerges as the times require. For example, a common scalable service-oriented middleware over internet protocol (SOME/IP) (that is, above the IP protocol layer) is used. A service-oriented scalable middleware), although SOME/IP has better performance than CIP, the protocol depth of SOME/IP is too deep and has greater independence, especially for application layer complexity In addition, the current SOME/IP still cannot meet the requirements of the above-mentioned redundancy mechanism, that is, cannot meet the requirements of the above-mentioned redundancy mechanism for packet synchronization and screening.

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 above-mentioned Ethernet in the vehicle field is realized based on time synchronization, it is too complicated and cumbersome.

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

SUMMARY OF THE INVENTION

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

A first aspect provides a method for vehicle communication, the method comprising: receiving a first message, where the first message includes a check field and a unique identifier, where the unique identifier includes a frame identification ID and an Internet Protocol IP address; The first message is checked according to the check field of the first message; if the first message passes the check, the first message is stored in the buffer space corresponding to the frame ID according to the frame ID.

In the technical solution of the present application, the identification of the message is realized by setting a unique identifier for the message, thereby ensuring the synchronous sending of the message and realizing the discrimination of the message. Compared with the communication method based on time synchronization, the technical solution of the present application does not require time synchronization between the receiving end and the transmitting end, and at the same time avoids message discrimination errors caused by different time precisions and time errors of different devices. The accuracy requirements of the equipment are not too strict, and the alignment time is not required at all, so it is suitable for on-board equipment in existing vehicles. In addition, setting an independent buffer space for each frame ID is a very suitable solution for vehicle communication scenarios, which makes the storage and reading of messages more convenient and faster.

With reference to the first aspect, in some implementations of the first aspect, optionally, if the first packet fails the check, the first packet is discarded.

Optionally, in the above process of checking the message, storing the message or discarding the message, it is possible to check whether the message is correct according to the check field of the received message (for example, the first message). When there is an error in the packet, the packet can be further processed, and the packet can be discarded. That is to say, when the message is correct, the check result is considered to be "passed", and the message is further processed (for example, stored in the buffer space corresponding to the frame ID); when the message is wrong, the check result is considered to be "failed" ”, the packet is discarded. This is because, in order to ensure that the data carried by the received message is correct, a check field is often set, and the check field has a corresponding relationship with the content carried. Therefore, when there is an error in the received message, The check field calculated according to the carried data will be inconsistent with the check field carried when the message is sent, it can be considered that the message has errors, and the message can be discarded.

When storing a message, take receiving a message from two data transmission channels as an example. For example, the first message received from network port 0 and network port 1 can be sent to two independent buffer areas of the application program. A separate buffer space will be created under the corresponding network port for each frame ID. After receiving the packets, the packets are sent to the corresponding buffer area for storage according to the frame ID. Each frame ID is only allocated a buffer space of the corresponding size, and the packets received in each buffer space will be overwritten and stored. That is, the latest received message will overwrite the last message in the buffer.

Optionally, the sent packets may also be counted, that is, the packets of each frame may be numbered, or it may be understood as setting the time sequence identifier of the packet frames. That is to say, the first packet is identified with the time sequence when it is sent.

Optionally, a frame sequence count (sequence counter) can be defined, and the frame sequence count can be used as the sequence identifier of the message. It can be accumulated at one end of the sending message, and the frame sequence counter will increase by 1 every time a frame is sent.

It should be noted that, in this embodiment of the present application, the frame sequence count is used to indicate the sequence of sending packets, which can be understood as the time sequence (sequence) of sending packets. For example, a frame sequence count of 5 in a message means that the message is sent for the 5th time. If the frame sequence count of another message is 7, it means that the message is sent for the 7th time. The message is sent after the message with the frame sequence count of 5 is sent. It can be considered that the message with the frame sequence count of 7 is sent later than the message with the frame sequence count of 5. It should be understood that the above is only an example for illustrating the meaning of the frame sequence count, and there is no limitation.

It should also be noted that, in this application, the sending order of the packets can be understood as the sequence of sending the packets, not the actual sending time of the packets. In other words, in the existing communication, the time stamp is used as the order of the sending time of the message, which is the order of the actual sending time, but in this application, it is only the order of the sending of the message, which does not correspond to the actual time. , which can be thought of as an ordering of each sent message. It is precisely because the freshness of the packets is distinguished by the sending order without corresponding to the actual time, so that the solution of the present application does not need to strictly require the time synchronization of all 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 the updated (late time) message can be selected. The message selection rule is very suitable for this aspect of vehicle communication. Special application scenarios, and this method is not suitable for common communication (such as communication between mobile phones and other terminals), because the amount of data involved in common communication scenarios is very large, if the counting method is used, it is easy to appear, the frame sequence count The maximum value has been reached, but there is still no way to store the data, resulting in data loss and other problems. Moreover, in this application, it is necessary to configure an independent buffer space for each frame ID, which is also unsatisfactory in common communication scenarios. Because of the above reasons, in common communication scenarios, the time synchronization method is currently used, and the counting method cannot be used. If the communication method based on time synchronization is applied to the communication in the vehicle field, it will be very complicated compared to the solution of the present application, which is not as concise and easy to implement as the solution of the present application.

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

In combination with the first aspect, in some implementations of the first aspect, the above-mentioned unique identifier further includes a frame sequence count, and a read request can be obtained, and the read request includes the frame ID of the message to be read; At least one first message is read from the buffer space corresponding to the frame ID of the message, and the value of the frame sequence count of the at least one first message is used to indicate the order in which it is sent; The packet with the largest frame sequence count value and the second packet is returned.

Optionally, according to the above-mentioned frame sequence count of the stored message, a suitable message can be selected from the at least one first message (that is, the message stored in the above-mentioned received first message) as the first message. Two messages, the second message can be understood as a message read in response to the read request, or can be understood as a message returned to the initiator of the read request.

That is to say, when the application program reads the specified frame ID message through the interface function, the program obtains the message from different network ports in the corresponding frame ID buffer area. And according to the set arbitration logic, redundant message arbitration is performed, and the message that wins the arbitration is returned to the user application layer through the interface function. When the message is read, the buffer will be protected, and the buffer will be locked and mutually exclusive. When there is a write request during the reading process, the request will be suspended. When the data copy is completed, it will be released immediately, and new received message.

Optionally, in order to prevent the received message and the read message from affecting each other, the message may be temporarily stored during the process of reading the message without responding to the read request during the process of receiving the message.

With reference to the first aspect, in some implementations of the first aspect, an unselected packet in the at least one first packet may also be discarded. That is to say, when reading a message, discard the unselected message, which can free up buffer space and reduce storage overhead.

As can be seen from the above, the frame ID of each frame of message is the same, and the frame sequence count is also the same. However, before each frame of message is sent from the network ports of multiple data transmission channels, the MAC address and IP address will be loaded, so the MAC address and IP address of the message sent from multiple network ports are different, so the message The frame ID and IP address can form the unique identifier of the packet. And the frame sequence count can also be used as part of the unique identifier. Therefore, for the receiving end, the received first packet may have the same frame ID but different IP addresses.

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

That is to say, the first message is sent by using the vehicle communication device with multiple data transmission channels provided by the embodiment of the present application.

Optionally, the above-mentioned messages, such as the first message, the second message, the stored message, etc., may have various message structures (formats). For example, there may be no encryption-related fields in plaintext transmission, and encryption-related fields may be included in ciphertext transmission.

With reference to the first aspect, in some implementations of the first aspect, the first message may include: an IP header, a user datagram protocol UDP header, a protocol data unit PDU header, and a data area.

Optionally, the IP address of the above-mentioned unique identifier may be loaded in the IP header, and other elements of the unique identifier (eg, frame ID, frame sequence count) may be loaded in the PDU header.

With reference to the first aspect, in some implementations of the first aspect, the first packet may further include a secure data transfer protocol area.

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 for vehicle communication is provided. The method includes: data loading a first message to be sent, where the first message to be sent includes a frame identification ID; and transmitting the first message to be sent to a plurality of In the data transmission channel, the Internet Protocol IP addresses of multiple data transmission channels are different from each other; load the IP addresses of multiple data transmission channels for the first message to be sent, and obtain multiple second messages to be sent; within the same sending period , and send the plurality of second messages to be sent.

In the technical solution of the present application, the identification of the message is realized by setting a unique identifier for the message, thereby ensuring the synchronous sending of the message and realizing the discrimination of the message. The unique identifier may include, for example, the above-mentioned frame ID and IP address. Compared with the communication method based on time synchronization, the technical solution of the present application does not require time synchronization between the receiving end and the transmitting end, and at the same time avoids message discrimination errors caused by different time precisions and time errors of different devices. The accuracy requirements of the equipment are not too strict, and the alignment time is not required at all, so it is suitable for on-board equipment in existing vehicles. In addition, setting an independent buffer space for each frame ID is a very suitable solution for vehicle communication scenarios, which makes the storage and reading of messages more convenient and faster.

It should be noted that, sending a message in the same sending period can be understood as sending a message at the same time. The data and frame IDs loaded in these second messages to be sent are the same, but the IP addresses are different.

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

Optionally, after the first message to be sent is transmitted to different data transmission channels, the IP addresses of the data transmission channel may be loaded into the first message to be sent, thereby obtaining the second message to be sent. That is to say, 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 the second message in the first aspect refers to the 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 in the second aspect The message to be sent is a message obtained by further processing on the basis of the first message to be sent by the vehicle communication device at the sending end before sending the message.

Optionally, the frame sequence count may also be loaded for the first message to be sent, so that the second message to be sent includes the frame sequence count. It can be understood that the sent packets are counted, that is, the packets of each frame are numbered, or it can be understood that the time sequence identifier of the packet frame is set. That is to say, the first packet is identified with the time sequence when it is sent.

Optionally, a frame sequence count can be defined, and the frame sequence count can be used as the sequence identification code of the packet. It can be accumulated at one end of the sending message, and the frame sequence counter will increase by 1 every time a frame is sent.

It should be noted that, in this embodiment of the present application, the frame sequence count is used to indicate the sequence of sending packets, which can be understood as the time sequence (sequence) of sending packets. For example, a frame sequence count of 5 in a message means that the message is sent for the 5th time. If the frame sequence count of another message is 7, it means that the message is sent for the 7th time. The message is sent after the message with the frame sequence count of 5 is sent. It can be considered that the message with the frame sequence count of 7 is sent later than the message with the frame sequence count of 5. It should be understood that the above is only an example to illustrate the meaning of the frame sequence count, and there is no limitation.

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 the sending order of the second message to be sent.

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

Optionally, every time the second to-be-sent message is sent, the frame sequence count value is incremented by 1, and when the frame sequence count value is accumulated to be greater than or equal to a preset threshold, the frame sequence count value is reset to zero.

Optionally, the above-mentioned messages, such as the first message to be sent and the second message to be sent, may have various message structures (formats). For example, there may be no encryption-related fields in plaintext transmission, and encryption-related fields may be included in ciphertext transmission.

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

In combination with the second aspect, in some implementations of the second aspect, the first message to be sent and the second message to be sent both include: an IP header, a user datagram protocol UDP header, a protocol data unit PDU header and a data area , 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 the 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 area.

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, comprising a unit for executing the method in any possible implementation manner of the first aspect or the second aspect.

In a fourth aspect, an apparatus for vehicle communication is provided, including a processor. The processor is coupled to the memory and can be used to execute instructions or data in the memory, so as to implement the method in any possible implementation manner of the first aspect or the second aspect. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface.

In a fifth aspect, a computer program product is provided, the computer program product comprising: a computer program (also referred to as code, or instructions), when the computer program is executed, causes the computer to execute the first aspect or the first aspect above. The method in any possible implementation manner of the second aspect.

In a sixth aspect, a computer-readable medium is provided, the computer-readable medium stores a computer program (also referred to as code, or instruction), when it runs on a computer, causing the computer to execute the above-mentioned first aspect or the first aspect. The method in any possible implementation manner of the second aspect.

Description of drawings

FIG. 1 is a functional block diagram of a vehicle to which the embodiments of the present application are applied.

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

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

FIG. 4 is a schematic diagram of redundant communication of multiple data transmission channels of a vehicle communication device according to an embodiment of the present application.

FIG. 5 is a schematic diagram of a processing flow of receiving redundant packets according to an embodiment of the present application.

FIG. 6 is a schematic diagram of a processing flow of receiving redundant packets according to an embodiment of the present application.

FIG. 7 is a schematic diagram of a process flow of sending redundant packets 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 a format of another 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 the connection of the vehicle communication device according to the embodiment of the present application in the same network.

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

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

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

FIG. 15 is a schematic diagram of a process of receiving 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 schematic diagram of a hardware structure 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 schematic diagram of a hardware structure 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 embodiments of the present application can be applied to various types of vehicles. These methods and/or devices can be applied to both manual driving, assisted driving, and automatic driving. The technical solutions of the embodiments of the present application will be introduced below with reference to the accompanying drawings.

FIG. 1 is a functional block diagram of a vehicle to which the embodiments of the present application are applied. Therein, the vehicle 100 may be a human-driven vehicle, or the vehicle 100 may be configured in a fully or partially autonomous driving mode.

In one example, the vehicle 100 may control the ego vehicle while in an autonomous driving mode, and may determine the current state of the vehicle and its surrounding environment through human manipulation, determine the possible behavior of at least one other vehicle in the surrounding environment, and A confidence level corresponding to the likelihood that other vehicles will perform the possible behavior is determined, and the vehicle 100 is controlled based on the determined information. When the vehicle 100 is in an autonomous driving mode, the vehicle 100 may be placed to operate without human interaction.

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

Alternatively, the vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple elements. Additionally, each of the subsystems 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, travel system 110 may include engine 111, transmission 112, energy source 113, and wheels 114/tires. The engine 111 may be an internal combustion engine, an electric motor, an air compression engine or other types of engine combinations; for example, a hybrid engine composed of a gasoline engine and an electric motor, or a hybrid engine composed of an internal combustion engine and an air compression engine. Engine 111 may convert 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 electricity. The energy source 113 may also provide energy to other systems of the vehicle 100 .

Illustratively, transmission 112 may include a gearbox, a differential, and a driveshaft; wherein transmission 112 may transmit mechanical power from engine 111 to wheels 114 .

In one embodiment, the transmission 112 may also include other devices, such as clutches. Among other things, the drive shafts may include one or more axles that may be coupled to one or more of the wheels 114 .

Illustratively, 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 (eg, a global positioning system (GPS), BeiDou system, or other positioning system), an inertial measurement unit (IMU) 122, a radar 123, a laser Distance meter 124 , camera 125 and vehicle speed sensor 126 . The sensing system 120 may also include sensors that monitor the internal systems of the vehicle 100 (eg, an in-vehicle air quality monitor, a fuel gauge, an oil temperature gauge, etc.). Sensor data from one or more of these sensors can be used to detect objects and their corresponding characteristics (position, shape, orientation, velocity, etc.). This detection and identification is a critical function for the safe operation of the autonomous vehicle 100 .

Among others, the positioning system 121 may be used 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, IMU 122 may be a combination of an accelerometer and a gyroscope.

Illustratively, 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 be used to sense the speed and/or heading of objects.

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, the laser rangefinder 124 may include one or more laser sources, laser scanners, and one or more detectors, among other system components.

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

Illustratively, the vehicle speed sensor 126 may be used to measure the speed of the vehicle 100 . For example, real-time speed measurement of the vehicle can be performed. The measured vehicle speed may be communicated to the control system 130 to effect control of the vehicle.

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

For example, the steering system 131 may operate to adjust the heading of the vehicle 100 . For example, in one embodiment it may be 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 .

Illustratively, the braking unit 133 may be used to control the deceleration of the vehicle 100 ; the braking unit 133 may use friction to slow the wheels 114 . In other embodiments, the braking unit 133 may convert the kinetic energy of the wheels 114 into electrical current. The braking unit 133 may also take other forms to slow the wheels 114 to control the speed of the vehicle 100 .

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

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

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

In one example, control system 130 may additionally or alternatively include components in addition to those shown and described. Alternatively, some of the components shown above may be reduced.

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

In some embodiments, peripherals 140 may provide a means for vehicle 100 to interact with user interface 170 . For example, the onboard computer 142 may provide information to the user of the vehicle 100 . The user interface 116 can also operate the onboard computer 142 to receive user input; the onboard computer 142 can be operated through a touch screen. In other cases, peripheral device 140 may provide a means for vehicle 100 to communicate with other devices located within the vehicle. For example, microphone 143 may receive audio (eg, voice commands or other audio input) from a user of vehicle 100 . Similarly, speakers 144 may output audio to a user of 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 communications; eg, code division multiple access (CDMA)), EVDO, global system for mobile communications (GSM)/general packet radio service (general packet radio service, GPRS), or 4G cellular communications, such as long term evolution (LTE); or, 5G cellular communications. The wireless communication system 141 may communicate with a wireless local area network (WLAN) using wireless Internet access (WiFi).

In some embodiments, the wireless communication system 141 may communicate directly with the device using an infrared link, Bluetooth, or ZigBee; other wireless protocols, such as various vehicle communication systems, for example, the wireless communication system 141 may include an or A number of dedicated short range communications (DSRC) devices, which may include public and/or private data communications between vehicles and/or roadside stations.

It should be noted that the communication solutions provided in the embodiments of the present application are mainly applicable to scenarios in which on-board devices communicate via Ethernet, which may be communication between different on-board devices of the same vehicle, or on-board devices of different vehicles. communication between. In this embodiment of the present application, the vehicle communication device may be any device in the above wireless communication system 141 , or may be a communication device integrated in any vehicle-mounted device, for example, may be a communication device integrated in the braking unit 133 , no longer list them one by one.

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

Illustratively, some or all of the functions of the vehicle 100 may be controlled by a computer system 150 , wherein the computer system 150 may include at least one processor 151 that executes execution in a non-transitory computer-readable medium stored in, for example, memory 152 . Instruction 153. Computer system 150 may also be multiple computing devices that control individual components or subsystems of vehicle 100 in a distributed fashion.

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 the computer in the same block, one of ordinary skill in the art will understand that the processor, computer, or memory may actually include storage that may or may not be Multiple processors, computers or memories within the same physical enclosure. For example, the memory may be a hard drive or other storage medium located within an enclosure other than a computer. Thus, reference to a processor or computer will be understood to include reference to a collection of processors or computers or memories that 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 and deceleration components may each have their own processor that only performs computations related to component-specific functions .

In various aspects described herein, a 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 performed on a processor disposed within the vehicle while others are performed by a remote processor, including taking steps necessary to perform a single maneuver.

In some embodiments, memory 152 may contain instructions 153 (eg, program logic) that may be used by processor 151 to perform various functions of vehicle 100 , including those described above. Memory 152 may also include additional instructions, such as including sending data to, receiving data from, interacting with, and/or performing data processing on one or more of travel system 110 , sensing system 120 , control system 130 , and peripherals 140 control commands.

Illustratively, in addition to instructions 153, memory 152 may store data such as road maps, route information, vehicle location, direction, speed, 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 or receive information from a user of vehicle 100 . Optionally, user interface 170 may include one or more input/output devices within the set of peripheral devices 140 , eg, wireless communication system 141 , onboard computer 142 , microphone 143 , and speaker 144 .

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

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

Optionally, the above component is just an example. In practical applications, components in each of the above modules may be added or deleted according to actual needs, and FIG. 1 should not be construed as a limitation on the embodiments of the present application.

Alternatively, the vehicle 100 may be a self-driving car traveling on a road and may recognize objects in its surroundings to determine an adjustment to the current speed. The objects may be other vehicles, traffic control devices, or other types of objects. In some examples, each identified object may be considered independently, and based on the object's respective characteristics, such as its current speed, acceleration, distance from the vehicle, etc., may be used to determine the speed at which the autonomous vehicle is to adjust.

Alternatively, the vehicle 100 or a computing device associated with the vehicle 100 (eg, computer system 150, computer vision system 134, memory 152 of FIG. rain, ice on the road, etc.) to predict the behavior of the identified object.

Optionally, each of the identified objects is dependent on the behavior of the other, so it is also possible to predict the behavior of a single identified object by considering all of the identified objects together. The vehicle 100 can adjust its speed based on the predicted behavior of the identified object. In other words, the self-driving car can determine that the vehicle will need to adjust (eg, 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 being traveled, the curvature of the road, the proximity of static and dynamic objects, and the like.

In addition to providing instructions to adjust the speed of the self-driving car, the computing device may also provide instructions to modify the steering angle of the vehicle 100 so that the self-driving car follows a given trajectory and/or maintains contact with objects in the vicinity of the self-driving car (eg, , cars in adjacent lanes on the road) safe lateral and longitudinal distances.

The above-mentioned vehicle 100 can be a car, a truck, a motorcycle, a bus, a boat, an airplane, a helicopter, a lawn mower, a recreational vehicle, a playground vehicle, construction equipment, a tram, a golf cart, a train, a cart, etc. The application examples are not particularly limited.

In a possible implementation manner, the vehicle 100 shown in FIG. 1 may be an automatic driving vehicle, and the automatic driving system will be described in detail below.

The automatic driving 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 with a system bus 205 . The processor 203 may be one or more processors, wherein each processor may include one or more processor cores. A display adapter 207 (video adapter), which can drive a display 209, is coupled to the system bus 205. The system bus 205 may be coupled to an input output (I/O) bus 213 through a bus bridge 211, and an I/O interface 215 may be coupled to the I/O bus. I/O interface 215 communicates with various I/O devices, such as input device 217 (eg, keyboard, mouse, touch screen, etc.), media tray 221 (media tray), (eg, CD-ROM, multimedia interface, etc.) . The transceiver 223 can send and/or receive radio communication signals, and the camera 255 can capture landscape and dynamic digital video images. The interface connected to the I/O interface 215 may be the USB port 225 .

The processor 203 may be any conventional processor, such as a reduced instruction set computing (reduced instruction set computer, RISC) processor, a complex instruction set computing (complex instruction set computer, CISC) processor or a combination of the above.

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 the above-mentioned conventional processors.

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

Computer system 201 may communicate with software deployment server 249 through network interface 229 . 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 network 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 solutions provided in the embodiments of the present application are mainly applicable to scenarios in which on-board devices communicate via Ethernet, which may be communication between different on-board devices of the same vehicle, or on-board devices of different vehicles. communication between. In this embodiment of the present application, the vehicle communication device may be a communication device independent of the in-vehicle device, or may be a communication device integrated in any in-vehicle device.

As shown in FIG. 2 , the hard disk drive interface is coupled with the system bus 205 , the hardware drive interface 231 can be connected with the hard disk drive 233 , and the system memory 235 is coupled with the system bus 205 . Data running in system memory 235 may include operating system 237 and application programs 243 . The operating system 237 may include a parser (shell) 239 and a kernel (kernel) 241 . 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 can manage the interaction between the user and the operating system, for example, waiting for user input, interpreting user input to the operating system, and processing various operating systems output result. Kernel 241 may consist of those parts of the operating system that manage memory, files, peripherals, and system resources. Interacting directly with hardware, the operating system kernel usually runs processes and provides inter-process communication, providing CPU time slice management, interrupts, memory management, IO management, and more. Application 243 includes programs that control the autonomous driving of the car, for example, programs that manage the interaction of the autonomous car with obstacles on the road, programs that control the route or speed of the autonomous car, and programs that control the interaction of the autonomous car with other autonomous vehicles on the road. . Application 243 also exists on the system of software deployment server 249 . In one embodiment, the computer system 201 may download the application program from the software deployment server 249 when the autonomous driving related program 247 needs to be executed.

For example, the application program 243 may also be a program for the autonomous vehicle to interact with the road lane lines, that is, a program that can track the lane lines in real time.

For example, the application program 243 may also be a program for controlling the self-driving vehicle to perform automatic parking.

Illustratively, sensors 253 may be associated with computer system 201 , and sensors 253 may be used to detect the environment surrounding computer 201 .

For example, the sensor 253 can detect the lane on the road, such as the lane line, and can track the change of the lane line within a certain range in front of the vehicle in real time when the vehicle is moving (eg, while driving). For another example, the sensor 253 can detect animals, cars, obstacles and pedestrian crossings, etc., and further sensors can also detect the environment around objects such as the above-mentioned animals, cars, obstacles and pedestrian crossings, such as: the environment around animals, for example, the environment around animals Other animals, weather conditions, ambient light levels, etc.

Alternatively, if the computer 201 is located in an autonomous vehicle, the sensors may be cameras, infrared sensors, chemical detectors, microphones, and the like.

Exemplarily, in the scenario of lane line tracking, the sensor 253 can be used to detect the lane line in front of the vehicle, so that the vehicle can perceive the change of the lane during traveling, so as to plan and adjust the driving of the vehicle in real time accordingly.

Exemplarily, in the scenario of automatic parking, the sensor 253 can be used to detect the size or position of the storage space and surrounding obstacles around the vehicle, so that the vehicle can perceive the distance between the storage space and surrounding obstacles, and when parking Collision detection is performed to prevent vehicles from colliding with obstacles.

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

FIG. 3 is a schematic diagram of an application of a cloud-side command to an 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 server 320 on the cloud side for further processing. Networks and intermediate nodes may include various configurations and protocols, including the Internet, the World Wide Web, Intranets, Virtual Private Networks, Wide Area Networks, Local Area Networks, private networks using one or more of the company's proprietary communication protocols, Ethernet, WiFi and HTTP, and various combinations of the foregoing; such communications may be by any device capable of transferring data to and from other computers, such as modems and wireless interfaces.

In one example, server 320 may include a server having multiple computers, such as a load balancing server farm, that exchange information with different nodes of the network for the purpose of receiving, processing, and transmitting data from computer system 312 . The server may be configured similarly 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 about road conditions around the vehicle. For example, server 320 may receive, detect, store, update, and transmit information related to vehicle road conditions.

For example, the relevant information of the road conditions around the vehicle includes other vehicle information and obstacle information around the vehicle.

Some existing vehicle communication methods either require complex point-to-point connections with too limited transmission capability (eg CIP), or involve complex communication protocols (eg SOME/IP), and none of them can meet the requirements of redundant communication. That is to say, for redundant communication, the prior art cannot well realize packet synchronization, and cannot discriminate redundant packets. Although the existing communication method based on time synchronization in the communication field can be used to realize real-time transmission, this method is too complicated and cumbersome, and the screening of redundant messages is still difficult to meet the special requirements of vehicle communication.

In view of the above technical problems, the embodiments of the present application provide a solution for vehicle redundant communication, which can realize real-time transmission of redundant data of vehicles and is easy to implement. Mainly by setting up redundant communication devices of multiple network ports to realize redundant sending and receiving of messages, and by setting unique identifiers and/or setting message numbers for messages to realize message identification, thus ensuring message integrity. Synchronous transmission and identification of packets. Compared with the communication method based on time synchronization, the technical solution of the present application does not require time synchronization between the receiving device and the sending device, and at the same time avoids packet discrimination errors caused by different time precisions and time errors of different devices. The accuracy requirements of the on-board equipment are not too strict, and the alignment time is not required at all, so it is suitable for on-board equipment in existing vehicles.

FIG. 4 is a schematic diagram of redundant communication of multiple data transmission channels of a vehicle communication device according to an embodiment of the present application. As shown in FIG. 4 , when the vehicle communication device is connected to the network for communication, the dual-channel Ethernet interface is used to send and receive data, and the data transmission redundancy is realized on the link. Each Ethernet channel has an independent media access control (MAC) address, a port physical layer (PHY) chip, and an independent Ethernet interface (ethernet interface, ETH).

The vehicle communication device is connected with a microcontroller unit (MCU) of the vehicle-mounted device, so that the communication between the vehicle-mounted devices can be realized. It should be noted that the communication may be performed between different in-vehicle devices of the same vehicle, or the communication may be performed between in-vehicle devices of different vehicles.

Optionally, the in-vehicle device can be understood as an in-vehicle terminal device, and in this embodiment of the present application, it mainly refers to an in-vehicle device that has a communication function and can perform certain functions. For example, each device in the sensing system 120 shown in FIG. The various subsystems in the control system 130 and the devices in the various subsystems, the various devices in the peripheral devices 140, the computer system 150, and the like. However, it should be understood that FIG. 1 is only an example, and the in-vehicle device may also include various types of units that can be used to control the vehicle, any device in the system, for example, a vehicle interface control unit (VIU), a vehicle identification unit ( vehicle integration unit (VIU), vehicle dynamics control (vehicle dynamics control) equipment, electronic control unit (ECU), electronic power steering (EPS), electronically controlled brake system (electronically controlled brake system) , EBS), anti-lock brake control system (antilock brake system, ABS) and so on.

It should also be noted that the vehicle communication device may be a device independent of the in-vehicle device, or may be a device integrated inside the in-vehicle device (that is, a part of the in-vehicle device). For example, the vehicle communication device may be a device in the wireless communication system 141 shown in FIG. 1 , or, for example, the vehicle communication device may be integrated into any of the above-mentioned in-vehicle devices.

As shown in Figure 4, the MCU of the in-vehicle device can send data (messages) through MAC0, PHY0 and network port 0 in the vehicle communication device in sequence, and can also receive data (messages) through network ports 0, PHY0 and MAC0 in sequence. The MCU of the in-vehicle device also sends data (messages) through MAC1, PHY1 and network port 1 in the vehicle communication device in sequence, and can also receive data (messages) through network port 1, PHY1 and MAC1 in sequence.

That is, the vehicle communication device shown in FIG. 4 includes two data transmission channels, wherein one data transmission channel includes the above-mentioned MAC0, PHY0 and network port 0, and the other data transmission channel includes the above-mentioned MAC1, PHY1 and network port 1.

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

Optionally, a frame identification (identity, ID) can be defined for each frame of message, that is, each frame of message has a unique frame ID, and then the two data transmission channels shown in FIG. A message with the same frame ID is sent to the target device/device (the device/device that received the message).

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

Optionally, in this embodiment of the present application, data loading may be in the order of an internet protocol (internet protocol, IP) header, a user datagram protocol (user datagram protocol, UDP) header, and a protocol data unit (protocol data unit, PDU) to load. The PDU data is loaded by the protocol stack or the application program, and is mainly responsible for the frame sequence count and frame ID transmission data loading.

Optionally, when the PDU message is ready, it can be passed to the sending layer, and then sent out simultaneously through two data channels. When the PDU is passed to the UDP and IP layers for transmission, the IP header and the UDP header are loaded by the protocol stack. In this way, when the message is sent to the network, a uniquely identified message is composed of the IP header and the frame ID.

Optionally, in order to isolate the data link, the two network ports of the vehicle communication device may be allocated in different network segments. Optionally, the destination addresses of network port 0 and network port 1 may also be in different network segments.

When the packet is delivered to the receiver through a network device such as a switch. The receiver can monitor and receive the message according to the set port.

Optionally, the in-vehicle communication device may send messages according to a fixed period. That is to say, at the same time, there will be two messages sent to the network by the vehicle communication device of the sending end through the two network ports at the same time. The two frame messages are loaded with the same PDU content, frame sequence count and frame ID, and the same UDP header. However, the IP headers of the two frames are different. Since the two frames are sent from different network ports, they are loaded with different source IP addresses and MAC addresses. Since the set destination addresses are also different, the destination IP address and destination MAC address of the IP header are also different. .

When the vehicle communication device shown in FIG. 4 receives a message, or it can be understood that when the vehicle communication device shown in FIG. 4 is the vehicle communication device of the receiving end, the message can be received from the network port 0 and the network port 1 respectively, and the The packet is selected according to the frame ID and frame sequence count of the received packet, and the specific processing process of the received packet will be introduced in FIG. 5 .

FIG. 5 is a schematic diagram of a processing flow of receiving redundant packets according to an embodiment of the present application. The steps shown in FIG. 5 are described below.

510. Receive a message.

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

Optionally, packets may be received (eg, receiving the first packet) from network ports of multiple (eg, two) data transmission channels, and the receiving processes of the multiple 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. When there are two data transmission channels, the same data transmission channel structure shown in FIG. 4 may be used.

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

Optionally, the unique identifier may further include a frame sequence count, where the frame sequence count is used to indicate the sending and sending order of the received packets (eg, the first packet) when they are sent.

It should also be noted that, in this application, the sending order of the packets can be understood as the sequence of sending the packets, not the actual sending time of the packets. In other words, in the existing communication, the time stamp is used as the order of the sending time of the message, which is the order of the actual sending time, but in this application, it is only the order of the sending of the message, which does not correspond to the actual time. , which can be thought of as an ordering of each sent message. It is precisely because the freshness of the packets is distinguished by the sending order without corresponding to the actual time, so that the solution of the present application does not need to strictly require the time synchronization of all devices.

520. Check the message, when the check result is "pass", go to step 540; when the check result is "fail", go to step 530.

Optionally, it is possible to check whether the message is correct according to the check field of the received message (for example, the first message), and further process the message when the message is correct, and when there is an error in the message, Packets can be discarded. That is to say, when the message is correct, the check result is considered to be "passed", and the message is further processed (for example, go to step 540); when the message is wrong, the check result is considered to be "failed", and the message The message is discarded (step 530 is executed). This is because, in order to ensure that the data carried by the received message is correct, a check field is often set, and the check field has a corresponding relationship with the content carried. Therefore, when there is an error in the received message, The check field calculated according to the carried data will be inconsistent with the check field carried when the message is sent, it can be considered that the message has errors, and the message can be discarded.

530. Discard the packet.

Optionally, the received packets (for example, the first packet) that do not pass the verification (check) 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. Store the message.

Optionally, after the received message passes the inspection, the message may be stored. The following is an example of the scenario shown in FIG. 4 .

For example, the first packet received from network port 0 and network port 1 can be sent to two independent buffer areas of the application program, and the application program will create a separate buffer space for each frame ID under the corresponding network port. . After receiving the packets, the packets are sent to the corresponding buffer area for storage according to the frame ID. Each frame ID is only allocated a buffer space of the corresponding size, and the packets received in each buffer space will be overwritten and stored. That is, the latest received message will overwrite the last message in the buffer.

550. Read the message.

Optionally, when a message needs to be read, the message stored in the buffer area of the corresponding frame ID can be read according to the buffer area (storage area) of the slave message.

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

Optionally, after obtaining the read request, a corresponding buffer space can be found according to the frame ID of the to-be-read message specified in the read request, and then the message stored in the buffer space is read.

Optionally, at least one stored message in the buffer space corresponding to the frame ID may be read, and the at least one stored message includes the above-mentioned first message. It should be noted that, during the execution of steps 510 and 520, the first packet that passes the inspection will be stored, so the packets stored in the buffer space of each frame ID here include the above-mentioned packets that have passed the inspection. Therefore, it can also be understood that at least one first packet is stored in the buffer space of each frame ID. However, it should be understood that there may also be no message in the buffer space, which is equivalent to a read failure, or an indication that there is no message is returned.

560. Select a message, and perform step 530 when the message is not selected, and perform step 510 when the message is selected.

Optionally, according to the above-mentioned frame sequence count of the stored message, a suitable message can be selected from the at least one stored message as the second message, and the second message can be understood as the read request in response to the read request. The extracted message, or it can be understood as the message returned to the initiator of the read request.

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

Optionally, the value of the frame sequence count of the message can be set to take a value from 0 to the maximum value. When the count reaches the maximum value, it continues to count from 0. Therefore, when the maximum value and 0 exist at the same time, it is considered that 0 is the larger count.

It should be noted that each step shown in FIG. 5 does not need to be completely executed, for example, only steps 510 to 540 may be executed, that is, an independent buffer space is set for each frame of message, and the message is stored. Steps 550 and 560 are executed only when the message needs to be read (when a read request is received). Or it can be understood that step 550 and step 560 are the process of reading the message, not the process of receiving the message, and steps 510 to 540 are the process of receiving the message. It can also be understood that steps 510 to 540 are executed every time a message needs to be received, and steps 550 and 560 are executed every time a message needs to be read.

Optionally, an unselected packet in the at least one first packet may also be discarded. That is to say, when reading a message, discard the unselected message, which can free up buffer space and reduce storage overhead.

Optionally, in order to prevent the received message and the read message from affecting each other, it is possible to not respond to the read request during the process of receiving the message, and to suspend the storage of the message during the process of reading the message, which can be understood as: Steps 540 and 550 may not be performed simultaneously.

It can be seen from the above that the messages sent and received by multiple data transmission channels are independent of each other. In the following, with reference to FIG. 6 , two data transmission channels are used as an example for introduction.

FIG. 6 is a schematic diagram of a processing flow of receiving redundant packets according to an embodiment of the present application. Each step shown in FIG. 6 will be introduced below.

It should be noted that Figure 5 can be regarded as a general description of the processing flow, while Figure 6 is equivalent to the processing flow when two network ports receive packets respectively. It can be seen from Figure 6 that the two The processing of the message is independent. Only when the message is selected according to the frame sequence, the two channels can share the frame sequence, so as to select the message from the received message. It should also be understood that since the two data channels are independent in the processing of the packets, there is no restriction on the sequence.

511. The network port 0 receives the packet.

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

512. The network port 1 receives the packet.

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

521. Check the message.

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

522. Check the message.

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

531. Discard the packet.

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

532. Discard the packet.

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

541. Store the message.

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

542. Store the message.

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

551. Read the message.

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

552. Read the message.

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

561. Select packets, and discard unselected packets.

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

562. Select packets, and discard unselected packets.

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

It should be noted that the two data transmission channels are independent of each other when performing the above steps, and the frame sequence count can be shared only when a packet is selected (ie, step 561 and step 562).

FIG. 7 is a schematic diagram of a process flow of sending redundant packets according to an embodiment of the present application. Each step of FIG. 7 will be introduced below.

701. Perform data loading on a first message to be sent, where the first message to be sent includes a frame ID.

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

Optionally, the data to be sent may be loaded in the first message to be sent, and the frame ID may be loaded in the header of the first message to be sent.

It should be noted that the specific location where the data, frame ID, frame sequence count, etc. are loaded in the message will be described in detail below, and will not be expanded here.

702. Deliver the first message to be sent to multiple data transmission channels, where IP addresses of the multiple data transmission channels are different from each other.

703. Load the IP addresses of the above-mentioned multiple data transmission channels into the first packet to be sent, to obtain multiple second packets to be sent.

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

Optionally, the frame sequence count may also be loaded for the first message to be sent, so that the second message to be sent includes the frame sequence count. For the meaning, purpose, setting method, etc. of the frame sequence count, please refer to the relevant introduction above, and for the sake of brevity, it will not be repeated. It should also be understood that the loading of the frame sequence count can be performed at any time before, during, or after step 701 and step 703, as long as it is performed before step 704 is performed, and there is no other limitation.

704. In the same sending period, send multiple second messages to be sent.

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 a message in the same sending period can be understood as sending a message at the same time. The data and frame IDs loaded in the second message to be sent 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 Figure 8, the length of one frame of 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 (data) area, a secure data transmission protocol area, and a key area.

The standard IP header includes 20 bytes, and the standard UDP header includes 8 bytes. As shown in FIG. 8 , the IP header and the UDP header have a total of 28 bytes.

The PDU header includes 32 bytes. In the embodiment of this application, two quantities of message sequence count and frame ID are added to the PDU header. For other PDU components, the same settings as the existing PDU header can be used. For example, the data type, data length, frame check sequence, etc. can be set in the PDU. The specific content will be introduced in FIG. 13 and will not be expanded here.

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

Optionally, the frame ID may together with the source IP form a unique identifier within the PDU.

Optionally, the message sequence count is to count the sent messages, and the message sequence count starts from 0. Every time a PDU message is sent, the message count is accumulated by 1, and when the count reaches the maximum value, it starts from 0 again. Start.

Optionally, an independent packet sequence count can be set for each frame ID.

Optionally, the header of the PDU packet includes a check field, for example, a frame check sequence (frame check sequence, FCS).

The digital signature area includes a header and a key area. The header of the digital signature area is located after the PDU header, and the key area is located at the end of the message frame. The byte lengths of the header and the key area are not fixed. situation settings.

Optionally, the digital signature area can be used to transmit encrypted public keys. Encryption algorithms of different security levels can be arbitrarily selected to encrypt packets. For example, RSA security encryption algorithm, HAL security encryption algorithm, and custom verification encryption algorithm.

The data area refers to an area for transferring data. The packet length (the sum of the byte length of the data and the byte lengths of the above-mentioned parts) does not exceed the requirements of network transmission. For example, the byte length of the packet can be set to be less than or equal to 1500.

Optionally, the length of the data area of each message can be customized according to the actual number of bytes used. The message length is loaded in the message length field of the PDU header. for receipt confirmation. The data area can customize the type of semaphore according to the type of transmission data, such as defining signals by bit offset, or defining different signals by byte offset.

It should be noted that, in the data area, ciphertext transmission or plaintext transmission can be selected according to the needs of data transmission.

The safe data transmit protocol area is used to store verification information for safe transmission. The secure transmission data area supports different secure data transmission protocols, for example, the SDTV2 protocol can be used. The secure data transfer protocol area may include 16 bytes.

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

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

Optionally, the message frame shown in FIG. 9 may include: an IP header, a UDP header, a PDU header, a data area, and a secure data transmission protocol area. FIG. 9 can be regarded as a message form that only encrypts the message but does not verify the secure transmission, or can be understood as a way of cipher text 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 Figure 10, the length of a frame is less than or equal to 1500 bytes.

Optionally, the message frame shown in FIG. 10 may include: an IP header, a UDP header, a PDU header, a digital signature area header, a data area, and a key area.

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

FIG. 11 is a schematic diagram of the connection of the vehicle communication device according to the embodiment of the present application in the same network. As shown in FIG. 11 , both the device #1 and the device #2 are in-vehicle devices, both of which include a vehicle communication device, but it should be understood that the two may also be independent vehicle communication devices. The two are connected in two ways through multiple switches.

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

It should be noted that, as shown in FIG. 11 , it is in the same network, so the above two channels refer to two channels in the same network, not two networks. The most intuitive difference is that the two switches shown in Figure 11 are connected, for example, switch #1 is connected to switch #N+1, which can prevent communication loss caused by switch failure or link failure.

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

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

Optionally, network A includes multiple switches, which may be numbered by switches Ai, where i is a positive integer.

Optionally, network B includes multiple switches, which may be numbered by switches Bj, where j is a positive integer.

It should be noted that FIG. 12 shows different networks, so the above-mentioned network A and network B are different networks. The most intuitive difference is that the switches of network A and network B shown in Figure 12 are isolated, for example, switch A1 is not connected to any switch in network B.

It should also be 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 network, and the like.

In the scenario shown in FIG. 12 , one network port of device #1, device #2, and device #3 is connected to network A, and the other network port is connected to network B. The device #1, the device #2, and the device #3 can simultaneously send data to the two networks through the two network ports according to the message format defined in the embodiment of the present application. The two network ports of another device are also connected to the network, and the packet reception and arbitration can be completed. No matter which network port packets arrive first, the transmission of the current cycle can be completed, making full use of the data link characteristics in the redundant network, and improving the transmission timeliness and reliability of data in the entire network.

The following describes the process of receiving and sending a message with an example.

The first is to set the network topology and data flow. The IPs of the two network ports of the in-vehicle device are allocated to different network segments, and both network ports are connected to the switch network (including the network shown in Figure 11 and the network shown in Figure 12).

Assume that the IP of network port 1 of device #1 is configured as 10.0.0.10/21, the IP of network port 0 of device #1 is configured as 10.0.8.10/21, and the IP of network port 1 of device #2 is configured as 10.0 .0.20/21, configure the IP of network port 0 of device #2 as 10.0.8.20/21.

When the in-vehicle device sends a message, the in-vehicle device can send the same PDU message from network port 1 and network port 0 at the same time in the same communication cycle. The frame ID of this PDU 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, destination port and message length. The source port may be different by implementation, but the destination port value is the same. The data length is also the same. Before the PDU message is sent from network port 1 and network port 0, the IP header of the network port is loaded by the protocol stack of the network port according to the IP information of the network port. Therefore, the contents of the IP header of the PDU message sent by the two network ports are different. .

When the in-vehicle device receives a message from network port 1 and network port 0, the data transmission channel where network port 1 and network port 0 are located can independently process the received message. As a result of the check, it is decided to discard the packet or store the packet.

FIG. 13 is a schematic diagram of a PDU packet format according to an embodiment of the present application. As shown in Figure 13, the PDU message frame includes: a frame header and a data area, wherein the frame header includes 32 bytes, and the data area may include data less than or equal to 1440 bytes.

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

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

The frame sequence count starts to accumulate from 0. Every time the vehicle communication device at the sending end sends a frame, the frame sequence count increases by 1. When the maximum value is reached, it returns to zero (that is, it returns to zero when it is greater than or equal to the preset threshold), and then starts from zero again. Start counting.

Optionally, the preset threshold (maximum value) can 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 the updated (late time) message can be selected. The message selection rule is very suitable for this aspect of vehicle communication. Special application scenarios, and this method is not suitable for common communication (such as communication between terminals such as mobile phones), because the amount of data involved in common communication scenarios is very large, if the counting method is used, it is easy to appear, and the frame sequence has When the maximum value is reached, there is still a situation where the data cannot be stored, resulting in data loss and other problems. Moreover, in this application, it is necessary to configure an independent buffer space for each frame ID, which is also unsatisfactory in common communication scenarios. Because of the above reasons, in common communication scenarios, the time synchronization method is currently used, and the counting method cannot be used. If the communication method based on time synchronization is applied to the communication in the vehicle field, it will be very complicated compared to the solution of the present application, which is not as concise and easy to implement as the solution of the present application.

Optionally, the vehicle communication device at the receiving end may arbitrate the freshness of the message according to the frame sequence count, and the larger the frame sequence count value, the fresher the data. When the data frame sequence counts received by the two independent network ports of the vehicle communication device at the receiving end are inconsistent, the packet with a larger frame sequence count value is selected for analysis, and the packet with a smaller frame sequence count value can be discarded. Assuming that the frame sequence count values of the two network ports are the same, you can set it to select the packets of the specified default network port for parsing. For example, you can specify to select the packets of network port 0 when the values are the same, or you can specify to select the packets of network port 1 when the values are the same, or you can specify that when the values are the same, you can select the network port 0 and the network port 1. The packets of the network port that arrive early, or you can specify to select the packets of the network port that arrives later among network port 0 and network port 1 when the values are the same, and so on, and will not be listed one by one.

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

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

The data type refers to the PDU communication data type, which is usually defined as process data and message data.

The data length can be understood as the length of the data frame, which refers to the length of the data field of the actual PDU message, excluding the 20-byte header.

The frame check sequence refers to the protocol sequence used to check the PDU header. Optionally, a cyclic redundancy check (cyclic redundancy check, CRC) check may be performed using a general-purpose FCS.

The data size of the data area can be 0 to 1440 bytes, that is to say, the data size does not exceed the total byte length limit of the PDU message, and the limit of the total byte length of the message needs to be deducted from the header of the message. length. Optionally, the signal table mapping may be defined by the appendix neutron subprotocol.

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

FIG. 14 is a schematic diagram of a flowchart of sending a redundant packet according to an embodiment of the present application. Each step of FIG. 14 is described below.

1401. Publish a message.

It can be understood that when a message needs to be sent, the message is published. When the vehicle communication device of the in-vehicle equipment needs to send the specified PDU message, the data area of the PDU is loaded in the application program. Taking the PDU 101 as an example, for the PDU 101, the data comes from the MCU of the in-vehicle equipment. After these data are loaded in the data area, the message can be transmitted to different data transmission channels respectively, and the data transmission channel performs subsequent operations such as loading frame ID, loading frame sequence count, and sending message.

Optionally, after the data area is loaded, the information of the frame header of the message can be loaded continuously, and the FCS can be calculated according to the current frame header information, so as to complete the data loading, and then the packaged message can be transmitted to different networks. The protocol stack of the transport channel. Add the IP header and MAC address information of the respective network ports into the protocol stack.

Optionally, a timer can be used to send outgoing packets and wait for the timer to be triggered. When the timer is triggered, the packets are sent from different network ports of different data transmission channels at the same time, and the frame sequence count value is accumulated by 1. . Regardless of whether the transmission fails or not, the frame sequence count is accumulated after the execution of the transmission behavior and is not affected by the success or failure of the transmission. That is to say, the loop counting operations in steps 1411 and 1421 are performed after each sending behavior is performed.

1411. The network port 0 cycle counts.

Optionally, network port 0 may use a counter to cyclically count the number of times the packet is sent.

1421. The network port 1 cycle counts.

It should be noted that steps 1411-1415 are operations performed by the data transmission channel where network port 0 is located, and steps 1421-1424 are operations performed by the data transmission channel where network port 1 is located. 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 (greater than or equal to the maximum value), step 1412 or step 1421 is executed to clear the counter (that is, the value of the frame sequence count is reset to zero), and the steps are executed regardless of whether the transmission fails or not. Step 1413 or step 1423, update the PDU message.

The value of the frame sequence count is generated by the transmit counter, which is continuously accumulated during power-on.

Optionally, in order to avoid arbitration conflict of sending packets in the network, it can be set that the frame sequence count does not support external software modification. When powered on, the sending counter is set to 0, that is, the initial value of the frame sequence count is 0. After each message is sent, the counter is incremented by 1, and the frame sequence count value is incremented by 1 until the frame sequence count value is accumulated to be greater than or equal to the preset value. When the threshold is set, the counter is cleared, the value of the frame sequence count is reset to zero, and the count starts from 0 again.

Optionally, according to the algorithm of the secure data transmission protocol, after the data transmission field is calculated locally through the SID, it can be loaded in the data area.

After the above fields are loaded in the digital signature area, the encryption of the message data area is completed and transmitted to the sending layer. Sent by the protocol stack sending area.

After the packets are all installed, step 1415 and step 1422 are executed to send the packets from network port 0 and network port 1 respectively. If the time interval or the number of times of sending failure exceeds the preset value, step 1403 may be executed to cancel the publishing of the message.

It should be noted that the PDU ID, frame sequence count, IP and MAC constitute the displacement identifier of this frame message in the network. In the same transmission cycle, there are two frames of the message with the same PDU ID and frame sequence count. In the same sending cycle, two packets with the same PDU ID have different IP headers and MAC addresses, so the identifiers of the two identical packets are unique.

It should be understood that FIG. 14 is an example of the process of sending redundant packets, and the specific process can refer to the related introduction in FIG. 7 , so for brevity, details are not repeated here.

FIG. 15 is a schematic diagram of a process of receiving a redundant packet according to an embodiment of the present application. Each step of FIG. 15 is described below.

1501. PDU subscription.

It should be noted that PDU subscription can be understood as one of the triggering conditions for receiving a message, and can also be understood as information for starting a process of receiving a message.

1502. Mode selection, when RT mode is selected, step 1504 is performed, and when SDT or security mode is selected, step 1503 is performed.

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

1503. Decrypt the packet.

It should be noted that step 1503 needs to be performed only for encrypted packets.

1504. Parse the received message.

It can be understood that the content of the received message is read out, so as to use the check field of the received message to check whether there is an error in the message.

1505. Check the packet.

Optionally, this step 1505 may be performed using the method provided in step 520 in FIG. 5 .

1506. Read and select the message.

Optionally, step 1506 may be performed using the methods of steps 550 and 560 in FIG. 5 .

It should be understood that FIG. 15 is an example of the process of receiving redundant packets and reading in packets, and the specific process can refer to the related introduction in FIG. 5 or FIG.

The vehicle communication method of the embodiment of the present application is described above, and the vehicle communication device of the embodiment of the present application is described below. It should be understood that the vehicular communication device introduced hereinafter can execute each process of the vehicular communication method of the embodiments of the present application, and repeated descriptions will be appropriately omitted when introducing the embodiments of the device below.

FIG. 16 is a schematic diagram of a vehicle communication device according to an embodiment of the present application. The device 2000 includes a receiving unit 2001 and a processing unit 2002 . The device 2000 can be used to execute each step performed by the vehicle communication device at the receiving end in the vehicle communication method of the embodiment of the present application.

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

The above-mentioned apparatus 2000 may be the vehicle communication apparatus shown in FIG. 4 .

FIG. 17 is a schematic diagram of a hardware structure 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 connected to each other through the bus 3004 for communication.

The apparatus 3000 may be used to execute each step performed by the vehicle communication device at the receiving end in the above vehicle communication method.

Optionally, the memory 3001 may be a read only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 3001 may store a program. When the program stored in the memory 3001 is executed by the processor 3002, the processor 3002 and the communication interface 3003 are used to execute each step of the vehicle communication method of the embodiment of the present application.

Optionally, the memory 3001 may have the function of the memory 152 shown in FIG. 1 , the function of the system memory 235 shown in FIG. 2 , or the function of the memory 340 shown in FIG. 4 to realize the above function of storing programs. Optionally, the processor 3002 may adopt a general-purpose CPU, a microprocessor, an ASIC, a graphics processing unit (graphic processing unit, GPU), or one or more integrated circuits, for executing related programs, so as to implement the functions of the embodiments of the present application. The functions required to be performed by the units in the vehicle communication device, or to perform each step of the vehicle communication method of the embodiments of the present application.

Optionally, the processor 3002 may have the function of the processor 151 shown in FIG. 1 , or the function of the processor 203 shown in FIG. 2 , or the function of the processor 330 shown in FIG. 3 , so as to realize the above-mentioned function of executing related programs .

Optionally, the processor 3002 may also be an integrated circuit chip with signal processing capability. In the implementation process, each step of the vehicle communication method in the embodiment of the present application may be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software.

Optionally, the above-mentioned processor 3002 may also be a general-purpose processor, a digital signal processor (digital signal processing, DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (field programmable gate array, FPGA) or other Programming logic devices, discrete gate or transistor logic devices, discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of this application can be implemented or executed. 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 conjunction with the embodiments of the present application may be directly embodied as executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other storage media mature in the art. The storage medium is located in the memory, and the processor reads the information in the memory and, in combination with its hardware, completes the functions required to be performed by the units included in the vehicle communication device of the embodiment of the present application, or executes each step of the vehicle communication method of the embodiment of the present application .

Optionally, the communication interface 3003 may use a transceiver device such as, but not limited to, a transceiver to implement communication between the device and other devices or a communication network.

The bus 3004 may include pathways for transferring information between various components of the device (eg, memory, processor, communication interface).

FIG. 18 is a schematic diagram of a vehicle communication device according to an embodiment of the present application. The device 4000 includes a sending unit 4001 and a processing unit 4002 . The device 4000 can be used to execute each step performed by the vehicle communication device at the transmitting end in the vehicle communication method of the embodiment of the present application.

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

The above-mentioned apparatus 4000 may be the vehicle communication apparatus shown in FIG. 4 .

FIG. 19 is a schematic diagram of a hardware structure 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 through the bus 5004 for communication.

The apparatus 5000 can be used to execute each step performed by the vehicle communication apparatus at the transmitting end in the above vehicle communication method.

Alternatively, the memory 5001 may be a ROM, a static storage device, a dynamic storage device or a RAM. The memory 5001 may store a program. When the program stored in the memory 5001 is executed by the processor 5002, the processor 5002 and the communication interface 5003 are used to execute each step of the vehicle communication method of the embodiment of the present application.

Optionally, the memory 5001 may have the function of the memory 152 shown in FIG. 1 , the function of the system memory 235 shown in FIG. 2 , or the function of the memory 340 shown in FIG. 4 to realize the above function of storing programs. Optionally, the processor 5002 may adopt a general-purpose CPU, a microprocessor, an ASIC, a GPU, or one or more integrated circuits, for executing a related program, so as to realize the required execution of the unit in the vehicle communication device of the embodiment of the present application function, or execute each step of the vehicle communication method of the embodiments of the present application.

Optionally, the processor 5002 may have the function of the processor 151 shown in FIG. 1 , the function of the processor 203 shown in FIG. 2 , or the function of the processor 330 shown in FIG. 3 , so as to realize the above-mentioned function of executing related programs .

Optionally, the processor 5002 may also be an integrated circuit chip with signal processing capability. In the implementation process, each step of the vehicle communication method in the embodiment of the present application may be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software.

Optionally, the above-mentioned processor 5002 may also be a general-purpose processor, DSP, ASIC, FPGA or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of this application can be implemented or executed. 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 conjunction with the embodiments of the present application may be directly embodied as executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other storage media mature in the art. The storage medium is located in the memory, and the processor reads the information in the memory and, in combination with its hardware, completes the functions required to be performed by the units included in the vehicle communication device of the embodiment of the present application, or executes each step of the vehicle communication method of the embodiment of the present application .

Optionally, the communication interface 5003 may use a transceiver device such as, but not limited to, a transceiver to implement communication between the device and other devices or a communication network.

The bus 5004 may include pathways for communicating information between various components of the device (eg, memory, processor, communication interface).

The embodiments of the present application further provide a computer program product including instructions, and when the instructions are executed by a computer, the instructions cause the computer to implement the methods in the foregoing method embodiments.

For the explanation and beneficial effects of the relevant content in any of the vehicle communication devices provided above, reference may be made to the corresponding method embodiments provided above, which will not be repeated here.

Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the technical field to which this application belongs. The terms used in this application in the specification of this application are for the purpose of describing specific embodiments only, and are not intended to limit the application.

The embodiments of the present application do not specifically limit the specific structure of the execution body of the methods provided by the embodiments of the present application, as long as the program in which the codes of the methods provided by the embodiments of the present application are recorded can be executed to execute the methods according to the embodiments of the present application. Just communicate.

Various aspects or features of the present application may be implemented as methods, apparatus, or articles of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used in this application may 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 (eg, hard disks, floppy disks, or magnetic tapes, etc.), optical disks (eg, compact discs (CDs), digital versatile discs (DVDs), etc. ), smart cards and flash memory devices (eg, erasable programmable read-only memory (EPROM), cards, stick or key drives, etc.).

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

It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, the memory (storage module) can be integrated in the processor.

It should also be noted that the memory described in this application is intended to include, but not be limited to, these and any other suitable types of memory.

Those of ordinary skill in the art can realize that the units and steps of each example described in conjunction with the embodiments disclosed in this application can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods to implement the described functions for each particular application, but such implementations should not be considered outside the scope of protection of this application.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, for the specific working process of the above-described devices and units, reference may be made to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, which may be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.

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

The functions, if implemented in the form of software functional units and sold or used as independent products, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a computer software product, and the computer software product is stored in a storage In the medium, the computer software product includes several instructions, the instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium may include, but is not limited to, various media that can store program codes, such as a U disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

The above are only specific implementations of the present application, but the protection scope of the present application is not limited to this. should be covered within the scope of protection of this application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

A method for vehicle communication, comprising:

Receive a first message, the first message includes a check field and a unique identifier, and the unique identifier includes a frame identification ID and an Internet Protocol IP address;

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

If the first packet passes the inspection, the first packet is stored in the buffer space corresponding to the frame ID according to the frame ID.
The method according to claim 1, wherein if the first packet fails the check, the first packet is discarded.
The method of claim 1 or 2, wherein the unique identifier further comprises a frame sequence count, the method further comprising:

Obtain a read request, where the read request includes the frame ID of the message to be read;

At least one first packet is read from the buffer space corresponding to the frame ID of the to-be-read packet, and the value of the frame sequence count of the at least one first packet is used to represent the at least one first packet the order in which the messages were sent;

From the at least one first message, the message with the largest value of the frame sequence count is selected as the second message, and the second message is returned.
The method of claim 3, wherein the method further comprises:

A first packet that is not selected among the at least one first packet is discarded.
The method according to any one of claims 1 to 4, wherein the first message comprises: an IP header, a user datagram protocol UDP header, a protocol data unit PDU header and a data area, and the unique identifier The IP address of the identifier is carried in the IP header, and the other elements of the unique identifier are carried in the PDU header.
The method of claim 5, wherein the first message further comprises: a secure data transfer protocol area.
The method according to claim 5 or 6, wherein the first message further comprises: a digital signature area header and a key area.
A method for vehicle communication, comprising:

performing data loading on the first message to be sent, where the first message to be sent includes a frame identification ID;

delivering the first message to be sent to multiple data transmission channels, where the Internet Protocol IP addresses of the multiple 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;

In the same sending period, the plurality of second messages to be sent are sent.
The method of claim 8, wherein the method further comprises:

A frame sequence count is loaded for the plurality of second messages to be sent, where the frame sequence count is used to indicate a sending order of the second messages to be sent.
The method according to claim 9, wherein the initial value of the frame sequence count is 0, and the frame sequence count is less than or equal to a preset threshold, the method further comprises:

Each time the second to-be-sent message is sent, the frame sequence count value is incremented by 1, and when the frame sequence count value is accumulated to be greater than or equal to the preset threshold, the frame sequence count value is incremented by 1. value to zero.
The method according to any one of claims 8 to 10, wherein the first message to be sent and the second message to be sent both include: an IP header, a User Datagram Protocol (UDP) header, a protocol Data unit PDU header and data area, 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 first message. 2. In the IP header of the message to be sent.
The method of claim 11, wherein the frame sequence count is loaded in a PDU header of the second message to be sent.
The method according to claim 11 or 12, wherein the second message to be sent further comprises: a secure data transmission protocol area.
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.
A device for vehicle communication, comprising:

a receiving unit, configured to receive a first message, where the first message includes a check field and a unique identifier, and the unique identifier includes a frame identification ID and an Internet Protocol IP address;

a processing unit, configured to check the first message according to the check field of the first message;

If the first packet passes the inspection, the processing unit is further configured to, according to the frame ID, store the first packet in the buffer space corresponding to the frame ID.
The apparatus according to claim 15, wherein if the first packet fails the check, the processing unit is further configured to discard the first packet.
The apparatus according to claim 15 or 16, wherein the unique identifier further includes a frame sequence count, and the receiving unit is further configured to obtain a read request, wherein the read request includes a message to be read The frame ID of;

The processing unit is further configured to read at least one first packet from the buffer space corresponding to the frame ID of the to-be-read packet, and the value of the frame sequence count of the at least one first packet is used for Indicates the order in which the at least one first packet is sent;

The processing unit is further configured to select, from the at least one first packet, a corresponding packet with the largest value of the frame sequence count as a second packet and return the second packet.
The apparatus of claim 17, wherein the processing unit is further configured to discard an unselected first packet in the at least one first packet.
The device according to any one of claims 15 to 18, wherein the first message comprises: an IP header, a User Datagram Protocol UDP header, a Protocol Data Unit PDU header and a data area, and the unique identifier The IP address of the identifier is carried in the IP header, and the other elements of the unique identifier are carried in the PDU header.
The apparatus of claim 19, wherein the first message further comprises: a secure data transfer protocol area.
The apparatus according to claim 19 or 20, wherein the first message further comprises: a digital signature area header and a key area.
A device for vehicle communication, comprising:

a processing unit, configured to perform data loading on a first message to be sent, where the first message to be sent includes a frame identification ID;

The processing unit is further configured to deliver the first message to be sent to a plurality of data transmission channels, and the 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 plurality of data transmission channels for the first message to be sent, to obtain a plurality of second messages to be sent;

A sending unit, configured to send the plurality of second messages to be sent within the same sending period.
The apparatus according to claim 22, wherein the processing unit is further configured to load a frame sequence count for the plurality of second messages to be sent, where the frame sequence count is used to indicate the second message to be sent The order in which packets are sent.
The device according to claim 23, wherein the initial value of the frame sequence count is 0, and the frame sequence count is less than or equal to a preset threshold, and the processing unit is further configured to:

Whenever the sending unit sends the second message to be sent once, the processing unit adds 1 to the value of the frame sequence count, and when the frame sequence count value is added to a value greater than or equal to the preset value When the threshold is reached, the processing unit resets the value of the frame sequence count to zero.
The device according to any one of claims 22 to 24, wherein the first message to be sent and the second message to be sent both include: an IP header, a User Datagram Protocol (UDP) header, a protocol Data unit PDU header and data area, 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 first message. 2. In the IP header of the message to be sent.
26. The apparatus of claim 25, wherein the frame sequence count is carried in a PDU header of the second message to be sent.
The apparatus according to claim 25 or 26, wherein the second message to be sent further comprises: a secure data transmission protocol area.
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.
A device for vehicle communication, comprising:

A processor for executing computer instructions stored in the memory to cause the apparatus to perform: the method of any one of claims 1 to 7.
A device for vehicle communication, comprising:

A processor for executing computer instructions stored in the memory to cause the apparatus to perform: the method of any one of claims 8 to 14.
A computer storage medium, characterized in that a computer program is stored thereon, and when the computer program is executed by a computer, the method according to any one of claims 1 to 7 is implemented.
A computer storage medium, characterized in that a computer program is stored thereon, and when the computer program is executed by a computer, the method according to any one of claims 8 to 14 is implemented.