A vehicle-mounted communication method and system based on Ethernet communication protocol
By constructing a response queue and adjusting the data processing process, the problem of reduced transmission efficiency caused by large data volumes in vehicle communication was solved, and efficient communication under large data volume conditions was achieved.
Patent Information
- Application Number
- CN202310719214.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-16
- Publication Date
- 2025-12-02
- Estimated Expiration
- 2043-06-16
AI Technical Summary
In vehicle communication, as the amount of data increases, there are more and more cases where the amount of data in a single frame of the SOME/IP protocol exceeds the length specified by the protocol, which leads to an increase in the packet transmission time interval and affects data transmission efficiency.
By constructing a response queue, the data processing process is adjusted according to the data transmission object and the time interval of data segmentation, thereby dynamically adjusting the data processing process to reduce the impact of increased communication data volume on vehicle communication efficiency.
Even when faced with large amounts of data, it can still maintain high communication efficiency. By using multi-threaded processing and reasonable planning of task sequences, it reduces the impact of segmented sending time intervals on communication efficiency and improves overall data transmission efficiency.
Smart Images

Figure CN116800787B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of automotive Ethernet technology, and in particular to an automotive communication method and system based on Ethernet communication protocol. Background Technology
[0002] SOME / IP, as a service-oriented scalable protocol introduced for in-vehicle Ethernet communication, has been widely applied to various functional areas of SOA-based vehicles. Furthermore, SOME / IP communication can choose to use TCP or UDP as the transport layer protocol according to different scenarios and requirements, ensuring that data packet loss is not a problem even when the number of servers and clients increases and the amount of data grows.
[0003] With the development of automotive automation and intelligence, the amount of data in vehicle communication will increase, leading to more and more cases where the data volume of a single frame of SOME / IP protocol exceeds the length specified by the protocol. In order to ensure that data is not lost, packet transmission is used, that is, data is transmitted in segments. However, packet transmission usually adds time intervals, so when there are many data transmission objects, it will lead to a decrease in data transmission efficiency, thereby affecting normal vehicle communication. Summary of the Invention
[0004] The purpose of this application is to provide a method and system based on the Ethernet communication protocol, which can be applied in vehicle instrument communication software. By constructing a response queue according to the data transmission object and the time interval of data segmentation, the data processing process can be dynamically adjusted, thereby reducing the impact of the increase in communication data volume on vehicle communication efficiency.
[0005] In a first aspect, this application provides a vehicle-mounted communication system based on the Ethernet communication protocol, comprising: a communication service module, a data transmission module, a data parsing module, and a data processing module.
[0006] The communication service module is used to identify the data transmission object and provide a data communication interface to transmit protocol frame data;
[0007] The data transmission module is used to construct a response queue based on the data transmission object and the size of the protocol frame data, and to send and receive protocol frame data based on the response queue;
[0008] The data parsing module is used to encode the data to be sent to generate byte order data, and to parse the received protocol frame data to extract message content;
[0009] The data processing module is used to process the message content and feed the processing results back to the data transmission module.
[0010] With the above technical solution, when the data volume is large and it is necessary to send and receive the data in segments, a response queue can be built according to the data transmission object and the time interval of data segment transmission. This allows the waiting time to be used to process other communication processes, thus enabling vehicle communication to still have high communication efficiency when facing large data volumes.
[0011] Optionally, the communication service module includes a service discovery unit, a service provision unit, and a service monitoring unit.
[0012] The service discovery unit is used to obtain services provided by other devices in the vehicular network;
[0013] The service providing unit is used to publish service instances for other vehicle devices in the vehicle network to discover and use, and provides service interfaces.
[0014] The service monitoring unit is used to monitor whether a network connection is established between in-vehicle devices, and to locate service instances and detect whether the service instances are running.
[0015] Optionally, the data transmission module includes a data receiving unit, a data sending unit, and a response control center.
[0016] The data receiving unit is used to receive protocol frame data sent by other devices in the vehicle network, extract messages through the data parsing module, and store the messages into a preset message queue.
[0017] The data sending unit is used to generate data to be sent based on the results fed back by the data processing module.
[0018] The response control center is used to construct a response queue based on the data transmission object and the data protocol frame size, and to send and receive data based on the response queue.
[0019] Optionally, the response control center includes a data segmentation unit, a data reassembly unit, a time monitoring unit, and a response queue generation unit.
[0020] The data segmentation unit is used to segment data according to preset segmentation rules during data transmission;
[0021] The data reassembly unit is used to receive and reassemble the segmented data during data reception;
[0022] The time monitoring unit is used to set time intervals and to send and receive data in segments according to the time intervals.
[0023] The response queue generation unit is used to generate corresponding response queues at the data sending end and the data receiving end, respectively, based on all transmitted data and the set time interval, and to realize data sending and data receiving processing based on the response queues.
[0024] Optionally, the data parsing module includes a serialization processing unit and a deserialization processing unit.
[0025] The serialization processing unit is used to serialize the transmitted data to form byte-order data;
[0026] The deserialization processing unit is used to deserialize the received data to form data in the protocol matrix definition format.
[0027] Optionally, the data processing module includes an active processing unit and a passive processing unit.
[0028] The active processing unit is used to actively provide data feedback based on the subscribed events and transmit the corresponding results to the data transmission module.
[0029] The passive processing unit is used to perform response processing based on the received protocol frame data and transmit the response result to the data transmission module.
[0030] Secondly, this application provides a vehicle communication method based on the Ethernet communication protocol, comprising the following steps:
[0031] It receives protocol frame data transmitted from other in-vehicle devices in real time, and processes the received protocol frame data through the data parsing module to obtain message content and data transmission queue.
[0032] The message content is processed by the data processing module to generate a response result.
[0033] Based on the response result, the data to be sent is generated through the data transmission module;
[0034] The data to be sent is fed back to the data transmission object.
[0035] Optionally, the step of feeding back the data to be sent to the data transmission object includes:
[0036] Determine if the size of the data to be sent has reached a preset threshold.
[0037] If not, the data to be sent is sent directly to the data transmission object;
[0038] If so, the data to be sent is segmented and the corresponding time interval is set;
[0039] Generate a response queue based on the data transmission object and time interval;
[0040] Based on the response queue, the data to be sent is sent to the data transmission object.
[0041] Optionally, the received protocol frame data is processed by a data parsing module to obtain the message content, including:
[0042] Determine whether a message is synchronous or asynchronous based on its content;
[0043] If it is a synchronous message, the preset callback method will be triggered directly;
[0044] If it is an asynchronous message, it will be stored in a preset message queue.
[0045] Thirdly, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above for an in-vehicle communication method based on an Ethernet communication protocol.
[0046] In summary, firstly, data encapsulation is performed on the basis of vsomeip. By modularizing vsomeip, data interaction between in-vehicle devices can be effectively realized, and various synchronous and asynchronous RPC calls or event notifications can be handled stably and efficiently. Secondly, when dealing with large data transmission volumes, the data processing sequence can be dynamically adjusted while transmitting data in segments to improve the overall efficiency of in-vehicle communication. Furthermore, the producer-consumer model is adopted to ensure the isolation between data reception and data processing, preventing frame loss due to excessively long data processing times. Attached Figure Description
[0047] Figure 1 This is a schematic diagram of an in-vehicle communication system based on the Ethernet communication protocol provided in an embodiment of this application;
[0048] Figure 2 This is a schematic diagram of the communication service module provided in an embodiment of this application;
[0049] Figure 3 This is a schematic diagram of the data transmission module provided in an embodiment of this application;
[0050] Figure 4 This is a schematic diagram of the response control center provided in the embodiments of this application;
[0051] Figure 5 This is a flowchart of an in-vehicle communication method based on the Ethernet communication protocol provided in an embodiment of this application;
[0052] Figure 6 This is a flowchart illustrating how data to be sent is fed back to the data transmission object, as provided in an embodiment of this application. Detailed Implementation
[0053] The following is in conjunction with the appendix Figure 1 - Appendix Figure 6 This application will be described in further detail below.
[0054] This application provides an in-vehicle communication system based on the Ethernet communication protocol, see [link to relevant documentation]. Figure 1 It includes: a communication service module 10, a data transmission module 20, a data parsing module 30, and a data processing module 40.
[0055] The communication service module 10 is used to identify the data transmission object and provide a data communication interface to transmit protocol frame data.
[0056] The data transmission module 20 is used to construct a response queue based on the data transmission object and the size of the protocol frame data, and to send and receive protocol frame data based on the response queue.
[0057] The data parsing module 30 is used to encode the data to be sent to generate byte order data, and to parse the received protocol frame data to extract message content.
[0058] The data processing module 40 is used to process the message content and feed the processing results back to the data transmission module.
[0059] The protocol frame data represents the data packets of the SOME / IP protocol, which can be transmitted using both TCP and UDP communication protocols. The SOME / IP protocol data packets mainly consist of two parts: Header and Data. Data represents the data body, i.e., the message content, while the Header contains information such as message ID, service ID, message type, and the ID of the vehicle-mounted device that sent the message.
[0060] Among them, SOME / IP, as a service-oriented scalable protocol introduced for in-vehicle Ethernet communication, has been widely applied to various functional areas of SOA-based vehicles. The SOME / IP protocol manages vehicle information on a service-by-service basis. Services can contain various callable methods and event groups, and information is transmitted and shared through server interfaces, with services allocated on demand.
[0061] SOA stands for Service-Oriented Architecture. In the SOA model, all functionalities are defined as independent services, which are connected through well-defined interfaces and protocols. SOME / IP in the automotive Ethernet protocol architecture is a communication middleware defined based on SOA principles.
[0062] This application employs vsomeip to construct the SOME / IP protocol stack system and applies it within the in-vehicle network architecture to build a middleware communication system based on SOA, enabling data interaction with other devices in the in-vehicle network. This data interaction takes the form of services, achieved by publishing its own services and subscribing to services provided by other devices. In other words, a communication connection must be established before data exchange can occur, much like a mobile phone where communication is only possible when both parties know each other's contact information.
[0063] Therefore, in this embodiment of the application, the data transmission object is first identified by the communication service module 10, and a data communication interface is provided to transmit protocol frame data.
[0064] Specifically, see Figure 2 The communication service module 10 includes a service discovery unit 11, a service provision unit 12, and a service monitoring unit 13.
[0065] The service discovery unit 11 is used to obtain services provided by other devices in the vehicle network.
[0066] Service providing unit 12 is used to publish service instances for other vehicle devices in the vehicle network to discover and use, and provides service interfaces.
[0067] The service monitoring unit 13 is used to monitor whether a network connection is established between vehicle-mounted devices, and to locate service instances and detect whether the service instances are running.
[0068] In this embodiment, when two in-vehicle devices interact with each other, both devices act as both servers and clients, participating in both publishing and subscribing to services. When publishing a service, the device acts as a server, broadcasting the service information so that other in-vehicle devices can subscribe and use it.
[0069] When subscribing to a service, the client acts as a client, subscribing to the corresponding service from the service provider. First, the client searches for available service instances in the vehicular network by sending a service discovery message. Upon receiving the client's service discovery message, the server sends a service response via UDP. After receiving the server's response, the client can subscribe to relevant events by sending an event subscription message.
[0070] After receiving a subscription request from a client, the server checks whether the subscription conditions are met. If the conditions are met, it replies with ACK; otherwise, it replies with NACK. Once the client successfully subscribes to a relevant event, the server publishes the event to the subscribed client according to the event's attributes. ACK and NACK represent feedback information in network communication; ACK indicates positive feedback, while NACK indicates negative feedback.
[0071] In addition to obtaining available service instances through service discovery unit 11, the service provider, while providing services, also provides corresponding service interfaces through service provision unit 12. Service interfaces are mainly divided into three types: Method, Event, and Field.
[0072] The Method is used to implement a remote procedure call that uses a Request-Response mechanism for communication. The client sends a remote procedure call request (Request) to request relevant data or to request the execution of relevant operations. The server receives the Request, performs the corresponding operation based on the content, and then responds to the client's Request via a Response.
[0073] Events are used to control the interaction of event groups in the publish-subscribe mechanism. Unlike methods, they do not respond to each request. Instead, the server actively sends data to the client. When an event sends data depends on the server itself meeting certain conditions.
[0074] The biggest difference between Field and the previous two is that the core of Field is to manipulate specific data, which is generally a variable with specific meaning, while the core of Method and Event is to perform certain actions.
[0075] Each service consists of similar or related functions and has a corresponding implementation interface. For example, the services provided by a vehicle air conditioner include: turning the air conditioner on or off, adjusting the air conditioner's fan speed, displaying the current ambient temperature, and setting the current target temperature. Turning the air conditioner on or off and adjusting the fan speed are equivalent to two callable methods, displaying the current ambient temperature is equivalent to an event, and setting the current target temperature is equivalent to a field that can adjust the data.
[0076] It's worth noting that service subscription actually refers to subscribing to events. Once the subscription is successful, the server will publish the event to the subscribed clients according to the event's attributes. For example, in the air conditioning service mentioned above, it can inform the subscribed clients of the current ambient temperature. After subscribing to this event, the vehicle's air conditioning system, acting as the server, will continuously notify the subscribed clients of the current ambient temperature.
[0077] In addition, before subscribing to a service, it is necessary to ensure that the current vehicle network is in a normal connection state. Therefore, the service monitoring unit 13 will monitor whether a network connection has been established between vehicle devices, locate the service instance, and detect whether the service instance is running. Only when the service instance is detected to be running can it be used by other vehicle devices.
[0078] In this embodiment of the application, after the service is published and subscribed through the service communication module 10, that is, after the communication relationship is established and the data transmission object is confirmed, the data transmission module 20 can receive messages sent by other in-vehicle devices in real time, and send request data to the service provider as needed.
[0079] Specifically, see Figure 3 The data transmission module 20 includes a data receiving unit 21, a data sending unit 22, and a response control center 23.
[0080] The data receiving unit 21 is used to receive protocol frame data sent by other devices in the vehicle network, extract messages through the data parsing module, and store the messages in a preset message queue.
[0081] The data sending unit 22 is used to generate data to be sent based on the results fed back by the data processing module.
[0082] The response control center 23 is used to construct a response queue based on the data transmission object and the data protocol frame size, and to send and receive data based on the response queue.
[0083] The data parsing module 30 parses the protocol frame data to obtain the message content, and then performs corresponding processing based on the message content. Since multiple protocol frame data may be received within the same time period, meaning multiple vehicle-mounted devices have sent messages, it is difficult to process multiple messages simultaneously. Therefore, the obtained message content is stored in a preset message queue, and the data processing module 40 processes the messages in the message queue.
[0084] In addition to receiving messages from other in-vehicle devices through the data receiving unit 201, it also sends messages through the data sending unit 202, that is, using services provided by other in-vehicle devices, or actively responding to messages based on subscribed events.
[0085] In addition, as mentioned above, in-vehicle devices transmit messages via SOME / IP protocol frame data. When using UDP for data transmission, there is a limitation on the length of the message content, i.e., there is an effective payload. When the data volume is large and exceeds the effective payload, the protocol frame data needs to be segmented. That is, the data is sent in segments at the sending end and received in segments at the receiving end. Furthermore, in order to eliminate out-of-order and jitter when sending data packets, a corresponding time interval is set. That is, after each segment of data packet is sent, a certain time interval is set before sending the next segment of data packet.
[0086] When the data volume is too large and there are many segments to be sent, the waiting interval will reduce the efficiency of communication. For example, when an in-vehicle device acts as a server, there are multiple messages in the associated message queue, which means there are multiple tasks to be processed. Usually, after one task is completed, the next task will be popped from the message queue. In this case, there is already a waiting process. If the previous task is a task that sends data in segments, it means that the task is considered complete only after all segments of data have been sent. However, there is a time interval between the sending of segments. Therefore, when there are many tasks that need to be sent in segments, or when the data is divided into many segments, it will affect the efficiency of the entire communication.
[0087] Therefore, in this embodiment of the application, by adding a response control center 23, and combining the message queue and the time interval of segmented transmission, the process of processing each message is adjusted. That is, a response queue is constructed according to the data transmission object and the data protocol frame size, and the data is sent and received according to the response queue.
[0088] Specifically, see Figure 4 The response control center 23 includes a data segmentation unit 231, a data reassembly unit 232, a time monitoring unit 233, and a response queue generation unit 234.
[0089] The data segmentation unit 231 is used to segment the data according to a preset segmentation rule when the data is sent.
[0090] The data reassembly unit 232 is used to receive and reassemble the segmented data during data reception.
[0091] The time monitoring unit 233 is used to set the time interval and to send and receive data in segments according to the time interval.
[0092] The response queue generation unit 234 is used to generate corresponding response queues at the data sending end and the data receiving end, respectively, based on all transmitted data and the set time interval, and to realize data sending and data receiving processing based on the response queues.
[0093] The response queue represents the sequence of tasks processed by the on-board communication device at the data sending and receiving ends in chronological order.
[0094] In this embodiment of the application, when the amount of data to be sent is large, the protocol frame data, namely the SOME / IP packet, will be segmented by the data segmentation unit 231 according to the payload, and a corresponding segmentation identifier will be added. Since the data to be sent is sent in segments, the receiving end will also receive the data in segments by the data reassembly unit 232.
[0095] In order to avoid out-of-order transmission and jitter when sending data packets, the time monitoring unit 233 is used to set the time interval and to send and receive data in segments according to the time interval.
[0096] It is worth noting that because the data is segmented according to the UDP protocol payload, the data byte length of each segment is the same except for the last segment. After the last segment is sent, the entire data to be sent is also sent, and there is no subsequent time interval. Therefore, the time interval set here has only one value, that is, the same time interval is set. Of course, different time intervals can be set according to different data transmission objects.
[0097] Considering that if the time intervals for segmented data transmission occur frequently, it may affect the overall data communication efficiency.
[0098] Therefore, in this embodiment of the application, the response queue generation unit 234 will generate corresponding response queues at the data sending end and the data receiving end respectively, based on all transmitted data and the set time interval, and realize data sending and data receiving processing based on the response queues.
[0099] For example, at the data sending end, multiple objects that need to send data are confirmed according to the message queue. At this time, the sequence of task processes has been determined according to the message queue. Suppose the current task process sequence is [A, B, C, D], where A and B are tasks that need to be sent in segments, represented by [A1, A2, A3] and [B1, B2, B3, B4] respectively according to the number of segments. Suppose the time required to send each segment of data is t1, and the interval time between segment data sending is t2. If t1 and t2 are the same, the time interval between segment sending can also be utilized. Another thread can be set to process task B while processing task A. That is, the response sequence for tasks A and B can be set as [A1, B1, A2, B2, A3, B3, B4].
[0100] If a time interval still exists, proceed downwards in the same way, determine the completion time of the next task, and then consider whether the next task can be completed within the time interval. In principle, each thread task should not be interrupted, that is, it is not allowed to stop when a task is half completed and then start to complete another task. This would cause resource occupation and also affect data transmission. Resources should be released after a task is completed, and then another linear task can be started, and so on, so as to build a response sequence.
[0101] Of course, the above-mentioned t1 and t2 being the same is just an example. In reality, the task sequence should be arranged comprehensively based on the ratio between t1 and t2, as well as the data transmission time under different transmission objects. The goal is to make use of the time interval of segmented transmission and to rationally plan the completion order of tasks through multi-threading, thereby improving the data transmission efficiency of the entire vehicle communication.
[0102] Since data transmission is performed in the form of SOME / IP protocol frames, but actual data interaction is performed in the form of actual message content, the data parsing module 30 is also used to parse the SOME / IP protocol frame data to extract the message content.
[0103] Specifically, the data parsing module 30 includes a serialization processing unit 301 and a deserialization processing unit 302.
[0104] The serialization processing unit 301 is used to serialize the transmitted data to form byte order data.
[0105] The deserialization processing unit 302 is used to deserialize the received data to form data in the protocol matrix definition format.
[0106] Serialization refers to the process of converting a data structure or object into a binary string according to predefined rules; deserialization refers to the process of reconstructing a data structure or object from a binary string according to the same rules.
[0107] In this embodiment, Google's open-source protobuf is used for data serialization and deserialization. Protobuf serializes the data to byte order before sending, and deserializes the received data into the format defined by the protocol matrix. For a specific SOME / IP protocol matrix, only the corresponding proto interface file needs to be defined for convenient data encoding, decoding, and transmission.
[0108] In this embodiment, there are various types of messages, as mentioned above. Each service instance provides multiple message transmission interfaces, corresponding to different message types. Therefore, different processing methods are used for different message types, and the data processing module 40 is used for message classification processing.
[0109] Specifically, the data processing module 40 includes an active processing unit 401 and a passive processing unit 402.
[0110] The active processing unit 401 is used to actively provide data feedback based on the subscribed event and transmit the corresponding results to the data transmission module.
[0111] The passive processing unit 402 is used to perform response processing based on the received protocol frame data and transmit the response result to the data transmission module.
[0112] In this embodiment, message processing employs a producer-consumer model. The acquired message content is stored in a preset message queue, and then message items are repeatedly popped from the queue and processed. This ensures that messages are cached to prevent frame loss even with large bus data volumes, thereby increasing data real-time performance and reliability.
[0113] Because the SOME / IP protocol frame data contains corresponding message types, the Message Type is used to identify the type of message, including requests that expect a reply, requests without a reply, subscribed event messages, and response messages.
[0114] Therefore, when processing messages popped from the message queue, the first step is to determine the message type. If it's a request message, it's processed according to a pre-defined callback method, and whether a corresponding reply message is generated depends on whether a reply is required. If it's a subscribed event message, which is essentially a notification message, no reply is needed. For example, subscribing to an air conditioning service in the above example continuously notifies the current ambient temperature, so this type of message doesn't require a reply. If it's a response message, meaning a request was actively sent expecting a reply, such as a reply message received after successfully subscribing to an event, then naturally, no reply is needed.
[0115] For messages that require a reply or feedback, the passive processing unit 402 generates the corresponding feedback information, which is then sent via the message transmission module 20. For subscribed events, the event's attributes are updated automatically for message transmission. Specifically, the active processing unit 401 generates the corresponding message content based on the subscribed event, and then the message transmission module 20 sends the message.
[0116] This application also provides an in-vehicle communication method based on the Ethernet communication protocol, see [link to relevant documentation]. Figure 5 It includes the following steps:
[0117] S100 receives protocol frame data transmitted from other in-vehicle devices in real time, and processes the received protocol frame data through the data parsing module to obtain message content and data transmission objects.
[0118] S200: The message content is processed by the data processing module to generate a response result.
[0119] S300: Based on the response result, the data to be sent is generated through the data transmission module.
[0120] S400: Feedback the data to be sent to the data transmission object.
[0121] In this embodiment of the application, in the entire vehicle network, each vehicle device communicates with other vehicle devices through the SOME / IP protocol. After publishing its own services for other vehicle devices to use, it needs to obtain the corresponding data requests in real time and process them accordingly.
[0122] Since the data is transmitted in the form of SOME / IP protocol frame data, after receiving the protocol frame data transmitted from other in-vehicle devices, it is necessary to parse it. That is, the data parsing module 30 will parse the protocol frame data to extract the message content, and then process it according to the message content.
[0123] When processing message content, feedback is usually required, and corresponding feedback results are generated. Then, the data transmission module 20 converts the response results into data to be sent, and finally sends the data to be sent to the data transmission object, thus completing one round of communication.
[0124] In addition, since the amount of data to be sent is relatively large, that is, the length of the resulting byte data exceeds the effective payload, it is necessary to send it in segments.
[0125] Therefore, in this embodiment of the application, when feeding back the data to be sent to the data transmission object, the size of the data to be transmitted is also used to determine whether it is necessary to send it in segments. When it is necessary to send it in segments, the efficiency of the entire data communication must also be taken into account, and the time interval of the segments should also be taken into consideration.
[0126] Specifically, see Figure 6 The process of sending the data to be sent back to the data transmission object includes the following steps:
[0127] S410. Determine whether the size of the data to be sent has reached the preset threshold.
[0128] S420. If not, the data to be sent is sent directly to the data transmission object.
[0129] S430. If so, the data to be sent is segmented and the corresponding time interval is set.
[0130] S440. Generate a response queue based on the data transmission object and time interval.
[0131] S450: Based on the response queue, the data to be sent is sent to the data transmission object.
[0132] The preset threshold represents the maximum data length that can be transmitted via UDP, i.e., the payload.
[0133] First, determine whether the data to be sent has reached the preset threshold. If the data to be sent has not reached the preset threshold, the protocol frame data to be sent can be sent directly to the data transmission object.
[0134] If the data to be sent reaches the preset threshold, the data will be segmented according to the length of the data to be sent and the payload. Then, according to the time interval set by the transmission object, that is, after each segment of data is sent, a certain time interval will be set before sending the next segment of data. This will help to prevent data from being out of order when the data transmission object receives the data, and will also provide a certain buffer time for data reassembly.
[0135] After segmenting the data and setting time intervals, all data or tasks that need to be sent are identified based on the current transmission object. Then, a response sequence is constructed by combining the time intervals of the segmented data transmission. Finally, the data to be sent is sent to the data transmission object based on the response sequence.
[0136] Furthermore, since some messages require feedback, it is necessary to first determine the sender of the message, that is, the source of the message. As mentioned above, in addition to message data, the protocol frame data also contains information such as the corresponding service ID, service ID, and client ID. Thus, the protocol frame data can be used to determine where the message was transmitted from, that is, to confirm the data transmission object. Accordingly, if message feedback is required, the feedback message will be sent to the data transmission object.
[0137] In this embodiment, after receiving protocol frame data and processing it through the data parsing module, the message content can be obtained. The message content is then processed accordingly by the data processing module. For messages requiring feedback, a corresponding response feedback result will be generated.
[0138] Based on the response result, the data transmission module generates the data to be sent. This data is naturally protocol frame data. The data to be sent is serialized by the serialization processing unit in the data parsing module to form byte order data. Then, it is encapsulated by combining message attributes and corresponding ID information to obtain protocol frame data. Finally, the protocol frame data is sent through the data transmission module, which means that the feedback information is transmitted to the message source.
[0139] Since dataset interaction, besides event group interaction mechanisms, primarily involves Remote Message Calls (RPC), which can take both synchronous and asynchronous forms, synchronous calls can be simply understood as the caller waiting for the executor's result. For example, in the process of subscribing to an event group, after sending an event subscription message, whether the subscription was successful requires feedback from the provider; that is, waiting for the service provider's response is what constitutes a synchronous call.
[0140] Asynchronous calls, on the other hand, do not require the caller to wait for the execution result from the executor. In this case, the corresponding message can be stored in a pre-defined message queue.
[0141] Therefore, in this embodiment of the application, different processing will be performed for these two different message formats so that the entire communication system can stably and efficiently handle various synchronous and asynchronous RPC calls or event notifications.
[0142] Specifically, after the received protocol frame data is processed by the data parsing module to obtain the message content, the following steps are also included:
[0143] S510: Determine whether a message is synchronous or asynchronous based on its content.
[0144] S520: If it is a synchronous message, the preset callback method will be triggered directly.
[0145] S530: If it is an asynchronous message, the message will be placed in a preset message queue.
[0146] In this embodiment, after parsing the received protocol frame data and obtaining the message content, the message is judged to determine whether it is a synchronous or asynchronous message. Besides considering whether data feedback is needed based on the message type, the corresponding Session ID is also used for judgment. When the Session ID is active, it indicates that the current session is in progress, equivalent to a phone call still being connected, with one party waiting for a response. This situation is equivalent to a synchronous message.
[0147] After determining whether a message is synchronous or asynchronous, appropriate processing is performed. For synchronous messages, a preset callback method is directly triggered for processing to better meet the real-time requirements of synchronous messages. For asynchronous messages, the message is placed into a preset message queue, and then the data processing module processes the messages in the message queue in a loop.
[0148] This application also provides a computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above for an in-vehicle communication method based on an Ethernet communication protocol.
[0149] The embodiments described in this specific implementation are preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the principles of this application should be covered within the scope of protection of this application.
Claims
1. A vehicle-mounted communication system based on the Ethernet communication protocol, characterized in that, include: Communication service module, data transmission module, data parsing module, data processing module. The communication service module is used to identify the data transmission object and provide a data communication interface to transmit protocol frame data; The data transmission module is used to construct a response queue based on the data transmission object and the size of the protocol frame data, and to send and receive protocol frame data based on the response queue; The data parsing module is used to encode the data to be sent to generate byte order data, and to parse the received protocol frame data to extract message content; The data processing module is used to process the message content and feed the processing result back to the data transmission module; The data transmission module includes a data receiving unit, a data sending unit, and a response control center. The data receiving unit is used to receive protocol frame data sent by other devices in the vehicle network, extract messages through the data parsing module, and store the messages into a preset message queue. The data sending unit is used to generate data to be sent based on the results fed back by the data processing module. The response control center is used to construct a response queue based on the data transmission object and the data protocol frame size, and to send and receive data based on the response queue; The response control center includes a data segmentation unit, a data reassembly unit, a time monitoring unit, and a response queue generation unit. The data segmentation unit is used to segment the data according to the payload of the UDP protocol when the data is sent. The data reassembly unit is used to receive and reassemble the segmented data during data reception; The time monitoring unit is used to set time intervals and to send and receive data in segments according to the time intervals; the response queue generation unit is used to generate corresponding response queues at the data sending end and the data receiving end respectively, based on all transmitted data and the set time intervals, and to realize data sending and receiving processing based on the response queues.
2. The vehicle-mounted communication system based on Ethernet communication protocol according to claim 1, characterized in that, The communication service module includes a service discovery unit, a service provision unit, and a service monitoring unit. The service discovery unit is used to obtain services provided by other devices in the vehicular network; The service providing unit is used to publish service instances for other vehicle devices in the vehicle network to discover and use, and provides service interfaces. The service monitoring unit is used to monitor whether a network connection is established between in-vehicle devices, and to locate service instances and detect whether the service instances are running.
3. The vehicle-mounted communication system based on Ethernet communication protocol according to claim 1, characterized in that, The data parsing module includes a serialization processing unit and a deserialization processing unit. The serialization processing unit is used to serialize the transmitted data to form byte-order data; the deserialization processing unit is used to deserialize the received data to form data in the protocol matrix definition format.
4. The vehicle-mounted communication system based on Ethernet communication protocol according to claim 1, characterized in that, The data processing module includes an active processing unit and a passive processing unit. The active processing unit is used to actively provide data feedback based on the subscribed events and transmit the corresponding results to the data transmission module. The passive processing unit is used to perform response processing based on the received protocol frame data and transmit the response result to the data transmission module.
5. A vehicle-mounted communication method based on the Ethernet communication protocol, characterized in that, include: It receives protocol frame data transmitted from other in-vehicle devices in real time, and processes the received protocol frame data through the data parsing module to obtain message content and data transmission objects; The message content is processed by the data processing module to generate a response result. Based on the response result, the data to be sent is generated through the data transmission module; The data to be sent is fed back to the data transmission object; It receives protocol frame data sent from other devices in the vehicle network, extracts messages through the data parsing module, and stores the messages in a preset message queue; Generate data to be sent based on the results fed back from the data processing module; A response queue is constructed based on the data transmission object and the data protocol frame size, and data is sent and received based on the response queue; When sending data, the data is segmented according to the UDP protocol payload; During data reception, the segmented data is received and reassembled. Set a time interval and send and receive data in segments according to the time interval; At both the data sending and receiving ends, corresponding response queues are generated based on all transmitted data and the set time intervals, and data sending and receiving are processed according to the response queues.
6. The vehicle-mounted communication method based on Ethernet communication protocol according to claim 5, characterized in that, The step of feeding back the data to be sent to the data transmission object includes: Determine if the size of the data to be sent has reached a preset threshold. If not, the data to be sent is sent directly to the data transmission object; If so, the data to be sent is segmented and the corresponding time interval is set; Generate a response queue based on the data transmission object and time interval; Based on the response queue, the data to be sent is sent to the data transmission object.
7. The vehicle-mounted communication method based on Ethernet communication protocol according to claim 5, characterized in that, The process of receiving protocol frame data and obtaining message content via a data parsing module includes: Determine whether a message is synchronous or asynchronous based on its content; If it is a synchronous message, the preset callback method will be triggered directly; If it is an asynchronous message, it will be stored in a preset message queue.
8. A computer-readable storage medium storing a computer program capable of being loaded by a processor and executing a vehicle communication method based on an Ethernet communication protocol as described in any one of claims 5 to 7.
Citation Information
Patent Citations
Data transmission method and vehicle-mounted Ethernet transmission system
CN112399381A
Data transmission method and device, electronic equipment and storage medium
CN116132550A