A communication method for an in-vehicle network and an in-vehicle network

Abstract

This invention provides a communication method and an in-vehicle network, comprising at least: a client publishing request information and subscribing to requests returned by a server; the server subscribing to requests published by the client and publishing response information; data publishing and subscription are conducted through request topics and response topics; the client processes response information including information matching the request ID; if the received response information has a processing sequence, the response information containing the processing sequence is inserted into the corresponding buffer queue in the timing buffer according to a linked list storage method; if the received response information does not have a processing sequence, it is directly unpacked to obtain payload information for task execution. Through the implementation of the above technical solution, this invention can avoid errors caused by logical mismatches between client request information and response information, thereby ensuring that the program obtains correct results.

Description

Technical Field

[0001] This invention relates to the field of intelligent vehicle communication, and in particular to a communication method for an in-vehicle network and an in-vehicle network. Background Technology

[0002] In recent years, technological advancements have propelled the automotive industry forward, pushing it towards assisted driving, autonomous driving, and driverless operation. This has made cars increasingly complex, as users demand more functions and higher quality. These new functions often require numerous control units (ECUs) and software control, constantly pushing the limits of existing architectures and design methods. In modern vehicles, each ECU has a large number of critical timing functions distributed and running simultaneously, communicating and accessing information within the in-vehicle network. Numerous ECUs need to interact and provide services, requiring sensors such as in-vehicle Ethernet cameras, in-vehicle Ethernet LiDAR, millimeter-wave radar, GPS, and inertial navigation. Advanced driver assistance systems require multi-sensor fusion for path planning and decision-making. Furthermore, the in-vehicle network generates a large amount of data, and some critical information, such as braking signals and steering information, cannot be delayed. Ensuring the smooth exchange of this information within the in-vehicle network has become a pressing technical challenge for intelligent vehicle in-vehicle network communication. Summary of the Invention

[0003] To address one of the shortcomings of existing technologies, the inventors provide a communication method for an in-vehicle network, comprising at least:

[0004] The client creates a data writer for request information to publish the request information, and creates a data reader for response information to subscribe to the requests returned by the server;

[0005] The server creates a data reader for request information to subscribe to requests published by the client, and creates a data writer for response information to publish response information;

[0006] Data publishing and subscription are conducted through request and response topics. The client processes response information that includes a matching request ID. Request and response information includes at least header and payload data.

[0007] If the received response information has a processing timeline, the response information containing the processing timeline is inserted into the corresponding buffer queue in the timeline buffer area in a linked list manner; if the received response information does not have a processing timeline, it is directly unpacked to obtain the payload information and execute the task.

[0008] In one embodiment, optionally, when there are multiple request messages including processing times that need to be sent through a request topic, a time-series buffer is synchronously created to store the response information corresponding to each time sequence;

[0009] If the first node of the time-series buffer is not empty, the client obtains the response information from the first node of the time-series buffer space, processes it, deletes the first node, and sets the next node as the first node.

[0010] In one embodiment, more preferably, the client keeps monitoring the first node of the created time-series buffer and destroys the processing time-series buffer after all data in the time-series buffer has been processed.

[0011] In one embodiment, more preferably, the request information uses a request topic for the client to initiate a request to the server, and the request information includes a request header and request payload data;

[0012] Alternatively, the response message uses a response topic, which is used by the server to return a response to the client. The response message contains the response header and response payload data.

[0013] In one embodiment, more preferably, the request header includes at least one of the following: a client-globally unique identifier, a processing sequence identifier, a bound server name, a service name and function to be invoked, and a request sequence number;

[0014] The request payload includes at least the parameter information required for the function call used to implement the request function;

[0015] Alternatively, the response header may include at least one of the following: a globally unique identifier of the client that initiated the request, a sequence number of the request corresponding to the response, a processing sequence identifier of the request, a globally unique identifier of the server, and a response sequence of the server.

[0016] The response payload includes at least the information returned after the function call.

[0017] In one embodiment, more preferably, when the server of the current node creates response information, it broadcasts the globally unique identifier contained in the response header in the response information to the nodes in the vehicle network. If no feedback is received from the nodes in the vehicle network after a preset waiting time, the globally unique identifier is fixed to the globally unique identifier in the response header of the corresponding response information.

[0018] If a feedback message is received within a preset time period, a new unique identifier is generated and broadcast across the entire network, repeating this process until a fixed globally unique identifier is obtained.

[0019] In one embodiment, more preferably, when other nodes in the vehicle network obtain the information sent by the server of the current node, they parse out the globally unique identifier and compare it with the system in which they are located. If they are different, the identifier is discarded; if they are the same, a feedback message is sent to the current node.

[0020] In one embodiment, more preferably, when the server in the vehicle network goes offline, the server will broadcast to the network nodes to notify them to delete its associated information.

[0021] In one embodiment, more preferably, the client performs service discovery on the requested topic and the server, and the client's publisher calls the data writer to send request information for the requested topic;

[0022] The server performs service discovery with the client on the response topic, and the server's subscribers call the data reader to read the request information from the client.

[0023] In one embodiment, more preferably, the client creates a client process and specifies the parameters used for the requested topic, the parameters of which include at least one of the following: domain ID, topic name, type name, and QoS policy;

[0024] When creating a server process, the server specifies the parameters to be used in the response topic. The parameters to be used in the response topic include at least one of the following: domain ID, topic name, type name, and QoS policy. The server process consists of a server object and a service object. The service object is set in the server object, and the service list, a data member of the server object, is registered in the server object.

[0025] In one embodiment, more preferably, the server determines whether the request needs to be processed by judging the bound server name in the request header of the request data, and calls the function according to the service name and function information to be called;

[0026] The client matches the response information to the request by judging the globally unique identifier of the client that initiated the request, the sequence number information of the request corresponding to the response, or the processing sequence in the response header of the response data.

[0027] In one embodiment, more preferably, the server creates a main thread and a first thread. After receiving a request, the first thread puts the request information into the message queue of the service corresponding to the request, puts the service called by the request into the request service queue, and then notifies the main thread that a request has arrived.

[0028] After receiving the notification, the main thread retrieves the service at the head of the request service queue and calls the service's first preset function to process the request.

[0029] The request processing adopts a first-in-first-out scheduling strategy. Each time the first preset function is called, only one request is processed. After completion, the service at the head of the queue will be removed from the queue.

[0030] In one embodiment, more preferably, the server creates a master thread and a second thread, and each service establishes a service thread at startup to handle service-related requests;

[0031] The main thread enters a sleep state after startup to maintain the running state of the process; the second thread, upon receiving a request, puts the request into the message queue of the service corresponding to the request and wakes up the service thread corresponding to the request.

[0032] The service thread calls the second preset function to process the request. If there are no other pending requests in the service's message queue after the request is processed, the service thread enters a sleep state.

[0033] An in-vehicle network includes: at least one area gateway, a domain controller, and an ECU, wherein the domain controller is connected to the area gateway via an in-vehicle Ethernet, and the domain controller is connected to the ECU via an in-vehicle Ethernet or CAN.

[0034] The domain controller, gateway, or ECU is equipped with a client and a server, and the client and server use the above-mentioned vehicle network communication method.

[0035] Beneficial effects:

[0036] The technical solution provided by this invention employs a client-server communication method. Through request subjects and response topics, the client and server become relatively independent. The client only needs to call the required service and is unconcerned about the server's location. The server only provides the service and doesn't need to know who is making the call. For complex or multi-task scenarios, by analyzing the complex tasks and designing processing timing, timing buffers, and storage methods, errors caused by logical mismatches between client request and response information can be avoided. Furthermore, for servers from different manufacturers, under different topics, the same globally unique identifier may be generated. The applicant obtains a globally unique identifier and broadcasts it to each node in the vehicle network. This broadcast notifies all nodes, allowing them to compare the server's globally unique identifier. If a similar identifier is found, the globally unique identifier is changed. Attached Figure Description

[0037] The following figures are for illustrative purposes only and do not limit the scope of the invention.

[0038] Figure 1 This is a schematic diagram of the communication between the client and the server at a node in a vehicle network according to an embodiment of the present invention.

[0039] Figure 2 This is a schematic diagram illustrating the process of storing response information in a timing buffer in one embodiment of the present invention. Detailed Implementation

[0040] To provide a clearer understanding of the technical features, objectives, and effects of this invention, specific embodiments are now described with reference to the accompanying drawings, in which the same reference numerals denote the same parts. For the sake of simplicity, the parts related to this invention are shown schematically in each drawing and do not represent their actual structure as a product. Furthermore, for the sake of clarity and ease of understanding, in some drawings, components with the same structure or function are shown only schematically, or only one is labeled.

[0041] Regarding control systems, as is well known to those skilled in the art, functional modules and application programs (APPs) can take any suitable form, whether hardware or software, and can be multiple discrete functional modules or multiple functional units integrated onto a single hardware device. In its simplest form, the control system can be a controller, such as a combinational logic controller or a microprogrammed controller, as long as it can implement the operations described in this application. Of course, the control system can also be integrated as different modules onto a single physical device, without departing from the basic principles and scope of protection of this invention.

[0042] In this invention, "connection" can include direct connection, indirect connection, communication connection, and electrical connection, unless otherwise specified.

[0043] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly specifies otherwise. It will also be understood that, when used in the specification, the terms “comprising” and / or “including” mean the presence of the stated features, values, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, values, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any and all combinations of one or more of the listed related items.

[0044] It should be understood that the term "vehicle" or "of a vehicle" or other similar terms as used herein generally includes motor vehicles, such as passenger cars including sport utility vehicles (SUVs), buses, trucks, various commercial vehicles, boats including various vessels, aircraft, etc., and includes hybrid vehicles, electric vehicles, plug-in hybrid electric vehicles, hydrogen-powered vehicles, and other vehicles powered by alternative fuels (e.g., fuels derived from non-petroleum energy sources). As mentioned herein, a hybrid vehicle is a vehicle with two or more power sources, such as both gasoline and electric power.

[0045] Furthermore, the controller disclosed herein can be embodied as a non-transient computer-readable medium on a computer-readable medium containing executable program instructions that are executed by a processor, controller, or the like. Examples of computer-readable media include, but are not limited to, ROM, RAM, optical disc (CD)-ROM, magnetic tape, floppy disk, flash memory drive, smart card, and optical data storage device. Computer-readable recording media can also be distributed across a network-coupled computer system, such that the computer-readable media are stored and executed in a distributed manner, for example, via a telematics server or a controller area network (CAN).

[0046] This invention provides a communication method for an in-vehicle network, used for communication between numerous ECUs. The communication architecture of the in-vehicle network adopts an object-oriented service for communication. Specifically, different ECUs communicate with each other via the network. In particular, each ECU can be configured with multiple clients and servers. The client and server are relative. When an APP in an ECU needs to call other APPs, the current ECU is the client; when the APP of the current ECU provides services to other ECUs, the current ECU is the server.

[0047] In addition, to separate services from requirements, a client and a server can be used in the same ECU. In this way, the client and the server are relatively independent within the same ECU, each implementing different functions, which is convenient for developers and designers and reduces interdependence.

[0048] Therefore, it should be noted that the client and server in this embodiment are relative concepts, not absolute concepts, depending on the functions provided by the current ECU.

[0049] Specifically, see Figure 1 The client creates a data writer for request information to publish the request information, and creates a data reader for response information to subscribe to the requests returned by the server;

[0050] The server creates a data reader for request information to subscribe to requests published by the client, and creates a data writer for response information to publish response information;

[0051] Data publishing and subscription are conducted through request and response topics. The client processes response information that includes a matching request ID. Request and response information includes at least header and payload data.

[0052] If the received response information has a processing sequence, then the response information containing the processing sequence is inserted into the corresponding buffer queue in the timing buffer area in a linked list storage manner;

[0053] If the received response information does not have a processing sequence, it is directly unpacked to obtain the payload information and execute the task.

[0054] During in-vehicle network communication, a large amount of information is generated. To improve execution efficiency, this invention breaks down complex tasks into multiple services. For example, when a client executes a function, such as turning the steering wheel during autonomous driving, a complex function requires acquiring perception data, performing path planning based on the perception data and the vehicle's current position, and then calculating parameters such as the steering angle and current speed. Therefore, complex tasks are decomposed into a series of services, which are then called by the server. These services are executed synchronously on different servers or on the same server with multi-threaded operation. However, this also presents a problem: some functions are logically related to the decomposed services. If this relationship is not distinguished, errors will occur. In existing object-oriented service architectures, the client and server are relatively independent. The client cannot identify whether the response information after requesting a service has a logical relationship; the client only verifies whether the received information meets the request requirements and processes it if it does. Clearly, existing technologies cannot solve the technical problems of this application.

[0055] The applicant has solved the above problems by designing a timing processing mechanism and a timing buffer, using linked lists to store information, and employing corresponding operational methods.

[0056] Specifically, when there are multiple request messages including processing time sequences that need to be sent through a request topic, a time sequence buffer is created synchronously to store the response information corresponding to each time sequence;

[0057] If the first node of the time-series buffer is not empty, the client obtains the response information from the first node of the time-series buffer space, processes it, deletes the first node, and sets the next node as the first node.

[0058] Specifically, this embodiment chooses to use a linked list for storage. By designing a series of random sequences, for example: assuming that the execution of the program is divided into four or more services, there are four processing sequences to identify the current order of obtaining services;

[0059] If the function executed by the client includes request information calls with multiple preset processing sequences, a timing buffer is allocated in the system memory before executing the request information call. The timing buffer is set with multiple storage units, and each storage unit is used to store the response information returned by the request information.

[0060] For example: see Figure 2 The function can be broken down into four services. When the client calls it, it uses four request messages to call the corresponding services, service 1 to service 4 respectively.

[0061] The processing timing includes: 0x01A, 0x01B, 0x01C, and 0x01D. In the timing buffer, there are four units that store the four processing timings and response return information respectively. In this embodiment, a class loadInfo can be designed for storage. In order to save space, after receiving the response data, storage space is allocated for it before storage, and the storage space is released when it is used up.

[0062] Data is stored using a linked list. Each node in the linked list stores response data corresponding to a processing time sequence, and each node in the linked list corresponds to a storage unit.

[0063] The client will receive response information, including processing timing, and store it in the storage unit corresponding to the timing buffer.

[0064] If the first node of the time-series buffer is not empty, the client obtains the response information from the first node of the time-series buffer space, processes it, deletes the first node, and sets the next node as the first node. This process is repeated until the first node is empty.

[0065] Specifically, the client keeps monitoring the first node of the created time-series buffer and destroys the processing time-series buffer after all data in the time-series buffer has been processed.

[0066] Specifically, in another embodiment of the present invention, different topics are set for matching in order to distinguish between request information and response information;

[0067] The request message uses a request subject and is used by the client to initiate a request to the server. The request message contains request headers and request payload data.

[0068] Alternatively, the response message uses a response topic, which is used by the server to return a response to the client. The response message contains the response header and response payload data.

[0069] The request header includes at least one of the following: a globally unique client identifier, a processing sequence identifier, a bound server name, a service name and function to be invoked, and a request sequence number;

[0070] Specifically, the processing sequence identifier only applies to request information containing processing sequence. Not all client request calls contain processing sequence. Therefore, for request calls without processing sequence, this example sets the processing sequence identifier to a fixed code, such as setting all the bits occupied by the processing sequence identifier to 0.

[0071] The request payload includes at least the parameter information required for the function call used to implement the request function;

[0072] Alternatively, the response header may include at least one of the following: a globally unique identifier of the client that initiated the request, a sequence number of the request corresponding to the response, a processing sequence identifier of the request, a globally unique identifier of the server, and a response sequence of the server.

[0073] The response payload includes at least the information returned after the function call.

[0074] By adding a globally unique identifier for the client and a processing sequence identifier for the request to the response information, it is ensured that the response information required by the client matches the request information. Otherwise, in an object-oriented service architecture, since the client and server are relatively independent, there may be a situation where the response information does not match the request information.

[0075] Specifically, since many ECUs come from different manufacturers, although their communication follows certain standards, differences can arise during application development. For example, when responding to topics, the same globally unique server identifier might be generated, but the client is unaware of this. Therefore, to solve this problem, this invention designs the following solution:

[0076] When the server of the current node creates a response message, it broadcasts the globally unique identifier contained in the response header of the response message to all nodes in the vehicle network. If no feedback is received from the nodes in the vehicle network after a preset waiting time, the globally unique identifier is fixed to the globally unique identifier in the response header of the corresponding response message.

[0077] If a feedback message is received within a preset time period, a new unique identifier is generated and broadcast across the entire network, repeating this process until a fixed globally unique identifier is obtained.

[0078] When other nodes in the vehicle network obtain the information sent by the server of the current node, they parse out the globally unique identifier and compare it with the system in which they are located. If they are different, they discard the information; if they are the same, they send a feedback message to the current node.

[0079] When a server in the vehicle network goes offline, it will broadcast to all network nodes, notifying them to delete its associated information.

[0080] Specifically, the client performs service discovery on the requested topic and the server, and the client's publisher calls the data writer to send the request information for the requested topic;

[0081] The server performs service discovery with the client on the response topic, and the server's subscribers call the data reader to read the request information from the client.

[0082] Specifically, to address the situation where dozens or even hundreds of ECUs may communicate in an in-vehicle network, but these ECUs have different security levels and generate different data types, if the CSMA / CD communication mechanism is used according to the existing Ethernet transmission rules during data transmission, critical signals may not be transmitted in a timely manner, causing severe delays and potentially leading to serious safety incidents. Therefore, the applicant has designed corresponding parameters for both the request and response topics.

[0083] The client creates a client process and specifies the parameters to be used for the requested topic. The parameters to be used for the requested topic must include at least one of the following: domain ID, topic name, type name, and QoS policy.

[0084] When creating a server process, the server specifies the parameters to be used in the response topic. The parameters to be used in the response topic include at least one of the following: domain ID, topic name, type name, and QoS policy. The server process consists of a server object and a service object. The service object is set in the server object, and the service list, a data member of the server object, is registered in the server object.

[0085] The server determines whether to process the request by checking the bound server name in the request header of the request data, and calls the function according to the service name and function information.

[0086] The client matches the response information to the request by judging the globally unique identifier of the client that initiated the request, the sequence number information of the request corresponding to the response, or the processing sequence in the response header of the response data.

[0087] Specifically, a server may receive multiple requests from different clients. When multiple services need to be processed, but the server only creates one service processing process, the handling method is as follows:

[0088] The server creates a main thread and a first thread. After receiving a request, the first thread puts the request information into the message queue of the service corresponding to the request, puts the service to be called into the request service queue, and then notifies the main thread that a request has arrived.

[0089] After receiving the notification, the main thread retrieves the service at the head of the request service queue and calls the first preset function of the service to process the request.

[0090] The request processing adopts a first-in-first-out scheduling strategy. Each time the first preset function is called, only one request is processed. After completion, the service at the head of the queue will be removed from the queue.

[0091] The first preset function is a function that implements the requested information. By calling the execution of the first preset function, a certain function can be achieved, such as acquiring image data, LiDAR data, and identifying or tracking targets in the image data.

[0092] Clearly, the above method cannot handle a large number of service requests. To address this technical issue, we propose the following technical solution for handling a large volume of service requests and reducing latency:

[0093] The server creates a main thread and a second thread. Each service creates a service thread when it starts up to handle service-related requests.

[0094] The main thread enters a sleep state after startup to maintain the running state of the process; the second thread, upon receiving a request, puts the request into the message queue of the service corresponding to the request and wakes up the service thread corresponding to the request.

[0095] The service thread calls the second preset function to process the request. If there are no other pending requests in the service's message queue after the request is processed, the service thread enters a sleep state.

[0096] Specifically, the above-mentioned technical solution applied for is mainly aimed at the communication of the vehicle network, and can be implemented with the following architecture: at least one area gateway, one domain controller, and one ECU, wherein the domain controller is connected to the area gateway through vehicle Ethernet, and the domain controller is connected to the ECU through vehicle Ethernet or CAN.

[0097] The domain controller, gateway, or ECU is equipped with a client and a server, and the client and server are implemented using the above-described vehicle network communication method.

[0098] The above technical solutions can be implemented by improving the middleware of the data distribution service or by implementing them on the autosar system platform.

[0099] The above descriptions are merely preferred embodiments of the present invention, and the present invention is not limited to the above embodiments. Those skilled in the art will understand that the forms in these embodiments are not limited thereto, nor are the adjustments possible. It is understood that other improvements and variations directly derived or conceived by those skilled in the art without departing from the basic concept of the present invention should be considered to be included within the scope of protection of the present invention.

Claims

1. A communication method for a vehicle-mounted network, characterized in that, At least including: The client creates a data writer for request information to publish the request information, and creates a data reader for response information to subscribe to the requests returned by the server; The server creates a data reader for request information to subscribe to requests published by the client, and creates a data writer for response information to publish response information; Data publishing and subscription are conducted through request and response topics. The client processes response information that includes a matching request ID. Request and response information includes at least header and payload data. When there are multiple request messages including processing times that need to be sent through a request topic, a time-series buffer is created synchronously to store the response information corresponding to each time sequence; If the received response information has a processing sequence, the response information containing the processing sequence is inserted into the corresponding buffer queue in the timing buffer area according to the linked list storage method; if the received response information does not have a processing sequence, it is directly unpacked to obtain the payload information and execute the task. If the first node of the time-series buffer is not empty, the client obtains the response information from the first node of the time-series buffer, processes it, deletes the first node, and sets the next node as the first node.

2. The communication method for a vehicle-mounted network as described in claim 1, characterized in that, The client keeps monitoring the first node of the created time-series buffer and destroys the processing time-series buffer after all data in the time-series buffer has been processed.

3. The communication method for a vehicle-mounted network as described in claim 1, characterized in that, The request message uses a request subject and is used by the client to initiate a request to the server. The request message includes a request header and request payload data. Alternatively, the response message uses a response topic, which is used by the server to return a response to the client. The response message contains the response header and response payload data.

4. The communication method for a vehicle network as described in claim 3, characterized in that, The request header includes at least one of the following: a globally unique client identifier, a processing sequence identifier, a bound server name, a service name and function to be invoked, and a request sequence number; The request payload includes at least the parameter information required for the function call used to implement the request function; Alternatively, the response header may include at least one of the following: a globally unique identifier of the client that initiated the request, a sequence number of the request corresponding to the response, a processing sequence identifier of the request, a globally unique identifier of the server, and a response sequence of the server. The response payload includes at least the information returned after the function call.

5. The communication method for a vehicle-mounted network as described in claim 1, characterized in that, When the server of the current node creates a response message, it broadcasts the globally unique identifier contained in the response header of the response message to all nodes in the vehicle network. If no feedback is received from the nodes in the vehicle network after a preset waiting time, the globally unique identifier is fixed to the globally unique identifier in the response header of the corresponding response message. If a feedback message is received within a preset time period, a new unique identifier is generated and broadcast across the entire network, repeating this process until a fixed globally unique identifier is obtained.

6. The communication method for a vehicle-mounted network as described in claim 5, characterized in that, When other nodes in the vehicle network obtain the information sent by the server of the current node, they parse out the globally unique identifier and compare it with the system in which they are located. If they are different, they discard the information; if they are the same, they send a feedback message to the current node.

7. The communication method for a vehicle-mounted network as described in claim 1, characterized in that, When a server in the vehicle network goes offline, it will broadcast to all network nodes, notifying them to delete its associated information.

8. The communication method for a vehicle network as described in claim 1, characterized in that, The client performs service discovery on the requested topic and the server. The client's publisher calls the data writer to send the request information for the requested topic. The server performs service discovery with the client on the response topic, and the server's subscribers call the data reader to read the request information from the client.

9. The communication method for a vehicle-mounted network as described in claim 1, characterized in that, The client creates a client process and specifies the parameters to be used for the requested topic. The parameters to be used for the requested topic must include at least one of the following: domain ID, topic name, type name, and QoS policy. When creating a server process, the server specifies the parameters to be used in the response topic. The parameters to be used in the response topic include at least one of the following: domain ID, topic name, type name, and QoS policy. The server process consists of a server object and a service object. The service object is set in the server object, and the service list, a data member of the server object, is registered in the server object.

10. A communication method for a vehicle-mounted network as described in claim 1, characterized in that, The server determines whether to process the request by checking the bound server name in the request header, and then calls the function based on the service name and function information. The client matches the response information to the request by judging the globally unique identifier of the client that initiated the request, the sequence number information of the request corresponding to the response, or the processing sequence in the response header of the response data.

11. The communication method for a vehicle-mounted network as described in claim 1, characterized in that, The server creates a main thread and a first thread. After receiving a request, the first thread puts the request information into the message queue of the service corresponding to the request, puts the service to be called into the request service queue, and then notifies the main thread that a request has arrived. After receiving the notification, the main thread retrieves the service at the head of the request service queue and calls the first preset function of the service to process the request. The request processing adopts a first-in-first-out scheduling strategy. Each time the first preset function is called, only one request is processed. After completion, the service at the head of the queue will be removed from the queue.

12. The communication method for a vehicle-mounted network as described in claim 1, characterized in that, The server creates a main thread and a second thread. Each service creates a service thread when it starts up to handle service-related requests. The main thread enters a sleep state after startup to maintain the running state of the process; After receiving the request, the second thread puts the request into the message queue of the service corresponding to the request and wakes up the service thread corresponding to the request. The service thread calls the second preset function to process the request. If there are no other pending requests in the service's message queue after the request is processed, the service thread enters a sleep state.

13. An EE electrical system for a vehicle network, characterized in that, include: At least one area gateway, one domain controller, and one ECU, wherein the domain controller is connected to the area gateway via an in-vehicle Ethernet, and the domain controller is connected to the ECU via an in-vehicle Ethernet or CAN. The domain controller, gateway, or ECU is equipped with a client and a server, and the client and server use the vehicle network communication method as described in any one of claims 1 to 12.

Images