A vehicle AUTOSAR communication system based on service-oriented

Abstract

This invention provides a service-oriented vehicle AUTOSAR communication system, comprising: a server cluster with an ECU as the main server and a control manager for controlling and managing other service ECUs; the server cluster and clients connected via a gateway; clients submit requests to the server, and upon receiving the client's request, the server cluster distributes it to sub-processes or sub-threads within the service-providing ECUs for task processing; the control manager distributes the client's request to the corresponding sub-process or sub-thread based on a first request distribution number generated from the client's request in the main process and several first response distribution numbers associated with the sub-processes or sub-threads. By rationally and evenly distributing client requests to the sub-processes or sub-threads in the server cluster according to the first request distribution number and the first request allocation number, the system ensures balanced load distribution of client requests across the server cluster's ECUs, enabling normal operation.

Description

Technical Field

[0001] This invention relates to the field of vehicle-mounted AUTOSAR communication, and more specifically to a service-oriented vehicle AUTOSAR communication system. Background Technology

[0002] The AUTOSAR Adaptive Platform (AP) is a new automotive electronic system architecture standard based on Service-Oriented Architecture (SOA), providing solutions for high-performance ECU development. SOA combines the functions performed by one or more ECUs in a vehicle, abstracting them into services and providing them to users through service interfaces, thus decoupling services and applications and shielding hardware differences. With the development of intelligent connected vehicles, the efficiency and performance requirements of automotive services are increasing. Improving server processing power from the perspective of a single ECU, whether by increasing ECU processing power or adding memory, cannot meet the ever-growing demands for high traffic, high concurrency, high performance, and high availability. Therefore, current high-traffic, high-concurrency request services are used in the internet and cloud computing industries, based on web communication. However, in vehicles, the communication mechanism is based on in-vehicle Ethernet protocols such as TSN and SOME / IP. Existing high-concurrency scaling technologies based on web communication are not suitable for the communication of AUTOSAR's in-vehicle networks. In addition, in-vehicle network communication requires high reliability. When an important client request from inside the vehicle is interrupted, the processing session before the interruption needs to be preserved and data processing needs to continue after the reconnection and request service. Existing technologies cannot meet these special requirements. Summary of the Invention

[0003] To address one of the shortcomings of existing technologies, this invention provides a service-oriented vehicle AUTOSAR communication system, comprising at least:

[0004] The server cluster consists of ECUs that provide services through the in-vehicle network. One of the service ECUs is selected as the master server and a control manager is set up to control and manage the other service ECUs.

[0005] The client must at least consist of an ECU (Engineer Control Unit) for obtaining services;

[0006] The server cluster and the client are connected through a gateway;

[0007] The client sends a request to the server. After receiving the request from the client, the server cluster distributes it to the subprocesses or threads in the ECU that provide the service for task processing.

[0008] The control manager listens for requests from clients in the main process to obtain at least the distribution parameters. Based on the first request distribution number corresponding to the client's request and several first response distribution numbers generated by the response parameters corresponding to the child process or child thread, the control manager distributes the client's request to the child process or child thread corresponding to the matching first response distribution number for processing.

[0009] A service-oriented vehicle AUTOSAR communication system, optionally, further includes the following steps for obtaining the first request distribution count: the control manager listens for requests from clients in the main process, obtains the client's distribution parameters based on the listening, and performs calculations to obtain the first request distribution count, where each first request distribution count corresponds to a client's request.

[0010] First response distribution count acquisition includes:

[0011] The control manager will calculate the response parameters of the created child processes or child threads to obtain several first response distribution numbers and distribute them according to the first response distribution numbers; each child process or child thread corresponds to at least one first response distribution number.

[0012] A service-oriented vehicle AUTOSAR communication system, further optionally, in which subprocesses or subthreads are created by the main process, and the control manager virtually maps the first response distribution numbers corresponding to all existing subprocesses or subthreads to the closed curve boundaries connected end to end according to their numerical values.

[0013] On the boundary of the closed curve, find the child thread or child process that corresponds to the first request distribution number that is close to the first response distribution number of the client's request, and distribute the client's request to the found child thread or child process.

[0014] In a service-oriented vehicle AUTOSAR communication system, optionally, the method by which the control manager distributes client requests to subprocesses or subthreads can also be:

[0015] The control manager creates a hash ring, with a range of 0~ 0 and Connected end to end;

[0016] All child processes or child threads in the server cluster are numbered and mapped to several virtual nodes. The corresponding hash values ​​are obtained using a consistent hashing algorithm and mapped onto a hash ring.

[0017] When a client makes a request, the consistent hashing algorithm generates a hash value for the client request based on the distribution parameters and selects the hash value of the nearest virtual service node from the hash ring;

[0018] The corresponding child process / thread is found using the hash value of the virtual service node, and then the corresponding child process / thread is bound to the client service before the child process or thread performs business processing.

[0019] A service-oriented vehicle AUTOSAR communication system, further optionally, includes at least two or more of the following client distribution parameters: client IP address, MAC address, port number, and client ID;

[0020] The response parameters for a child process or child thread must include at least two of the following: the server's IP address, MAC address, port number, child process ID or child thread ID, and virtual node number.

[0021] A service-oriented vehicle AUTOSAR communication system, optionally further, calculates and obtains the one-to-one correspondence between the input and output of the algorithm used to obtain the first requested distribution number based on the client's distribution parameters, with each input corresponding to one output and each output corresponding to one input;

[0022] The algorithm used to obtain the first response distribution number by calculating the response parameters corresponding to the subprocess or subthread has a one-to-one correspondence between input and output, with each input corresponding to one output and each output corresponding to one input.

[0023] A service-oriented vehicle AUTOSAR communication system, further optionally, wherein the client and subprocesses or subthreads in the server cluster communicate using a SOME / IP-based communication protocol;

[0024] Each child process or thread handles only one client request at a time; after processing a client request, the child process or thread does not release itself, but continues to acquire the next client request to be processed and continue processing it.

[0025] A service-oriented vehicle AUTOSAR communication system, further optionally, when a subprocess or subthread is assigned to requests from multiple clients, each thread in each process or thread pool listens to the assigned socket in a preset manner to see if there is an I / O operation that can be performed. Each subprocess or subthread maintains its own loop and independently listens to different events.

[0026] A service-oriented vehicle AUTOSAR communication system, further optionally, involves a control manager using a message queue to distribute sockets to sub-threads or sub-processes; when a sub-process or sub-thread writes data to the message queue, and detects that there is data to read in the message queue, it analyzes whether it is a new client requesting a connection; if so, it registers the read / write event on the new socket to the event table of its own I / O event model.

[0027] A service-oriented vehicle AUTOSAR communication system, further optionally, includes a first mapping table in the control manager for recording control parameters corresponding to each subprocess or subthread;

[0028] The control manager has a second mapping table for recording server operating parameters;

[0029] Based on the parameters recorded in the first and second mapping tables, the control manager constantly monitors client requests and the processing of client requests by the server's child processes or threads in the server cluster, thereby achieving load balancing.

[0030] A service-oriented vehicle AUTOSAR communication system, further optionally, the first mapping table includes at least two of the following: subprocess or subthread number, IP address, subprocess or subthread port number, process ID, virtual node number, first response distribution number, and first request distribution number;

[0031] The second mapping table includes at least two of the following: server number managed by the control manager, server IP, number of currently working subprocesses or subthreads, maximum supported number of processing threads, current computing power usage of the server, and maximum processing load threshold.

[0032] A service-oriented vehicle AUTOSAR communication system, further optionally, when a client's request is disconnected, the server where the sub-thread or sub-process handling the client's request resides stores the client's computational state in a buffer within a preset waiting time.

[0033] When a disconnected client requests a connection again, the control manager obtains the first request distribution number based on the disconnected client's distribution parameters, and then finds a sub-thread or sub-process on the closed curve boundary that is close to the first response distribution number based on the first request distribution number and assigns it to the client. The sub-thread or sub-process then reads the buffer to store the client's state and continues to process the data.

[0034] A service-oriented vehicle AUTOSAR communication system may further optionally compare the number of the sub-thread or sub-process corresponding to the first response distribution number obtained from the first request distribution number of the disconnected client with the number of the sub-process or sub-thread corresponding to the first response distribution number in the first mapping table. If they are different, the disconnected client request is distributed to the sub-process or sub-thread corresponding to the first response distribution number recorded in the first mapping table.

[0035] A service-oriented vehicle AUTOSAR communication system, further optionally, when the control manager detects a failure in a certain subprocess or subthread or a server in the service cluster, the control manager automatically deletes the first response distribution number corresponding to all subprocesses or subthreads in the failed subprocess or subthread or the server in the failed service cluster on the closed curve boundary.

[0036] Then, subsequent client requests are processed by the normally operating subprocess or subthread, or the subprocess or subthread in the normally operating server, corresponding to the first response distribution number obtained after obtaining the first request distribution number.

[0037] A service-oriented vehicle AUTOSAR communication system, further optionally, when a new server is added to the service cluster, the controller manager assigns a number to the main process or child process created by the main process in the new service, and calculates a number of first response distribution numbers based on the first response parameters corresponding to the child process or child thread. Then, the first response distribution numbers are mapped to closed curve boundaries to complete the distribution of child processes or child threads in the new server.

[0038] A service-oriented vehicle AUTOSAR communication system, further optionally, has a control manager with a security protection policy. If a request from a server in the service cluster, a subprocess or subthread in the server, or a client does not meet the security protection policy, the corresponding first response distribution number is removed at the closed curve boundary.

[0039] Or reject the client's request.

[0040] A service-oriented vehicle AUTOSAR communication system, further optionally, when the control manager learns from a second mapping table that there is a service ECU in the server cluster whose load exceeds the maximum processing load threshold, it stops distributing client requests to the service ECU whose load exceeds the maximum processing load threshold.

[0041] When the control manager calculates the first request distribution number based on the new client request and finds the child process or child thread corresponding to the first request response number that is closest to the first request distribution number in the service ECU whose load exceeds the maximum processing load threshold, the control manager removes the first response distribution number corresponding to all child processes or child threads in the service ECU that exceeds the maximum processing load threshold on the closed curve boundary.

[0042] A service-oriented vehicle AUTOSAR communication system, further optionally, when the control manager finds a subprocess or subthread corresponding to the first request response number that is closest to the first request distribution number but does not meet the requirements, it searches again for a subprocess or subthread corresponding to the second first request response number that is closest to the first request distribution number. If the service ECU where the subprocess or subthread is located meets the requirements, the new client request is distributed to the second subprocess or subthread corresponding to the first request response number that is closest to the first request distribution number.

[0043] Beneficial effects:

[0044] This embodiment employs a control manager to map subprocesses or threads into several virtual nodes based on the client's distribution parameters. It obtains the first response distribution parameters based on the subprocess or thread's response parameters. By mapping the first response distribution parameters into a closed curve, in subsequent allocation processes, based on the first request distribution number and the number of first request distributions close to the first request distribution number, it can reasonably and evenly distribute client requests to subprocesses or threads in the server cluster.

[0045] When a request from the same client is disconnected and reconnected, the session persistence function ensures that requests from the same client are routed to the same subprocess or thread to improve access quality. When the server or ECU crashes, only clients connected to that server or ECU are affected. The use of G functions with unique inputs and outputs allows disconnected clients to reconnect to the subprocess or thread they were in before the disconnection, preventing a large number of clients from being affected.

[0046] When a service or ECU on the server side fails, the traditional approach is that the system will not automatically block the service or ECU because it is difficult to quickly detect the faulty subprocess, subthread or server.

[0047] However, this embodiment sets a corresponding first response distribution number, obtains the first response distribution number that has failed from the first mapping table, and quickly masks it in the closed curve. By evenly distributing the client requests of the failed subprocess or subthread, it ensures that the system will not be paralyzed due to overload. Attached Figure Description

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

[0049] Figure 1 This is a schematic diagram of a service-oriented vehicle AUTOSAR communication architecture in one embodiment of the present invention.

[0050] Figure 2 This is a flowchart illustrating the process of a control manager listening to and distributing client requests in one embodiment of the present invention.

[0051] Figure 3 This is a schematic diagram of the closed curve boundary to which a subprocess or subthread maps the first response distribution number in one embodiment of the present invention.

[0052] Figure 4 This is a distribution diagram of hash rings mapping subprocesses or subthreads to virtual nodes in one embodiment of the present invention.

[0053] Figure 5 This is a distribution diagram of hash rings mapping subprocesses or subthreads to virtual nodes in one embodiment of the present invention.

[0054] Figure 6 This is a schematic representation of the first mapping in the control manager in one embodiment of the present invention.

[0055] Figure 7 This is a schematic representation of the second mapping in the control manager in one embodiment of the present invention. Detailed Implementation

[0056] 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.

[0057] 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.

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

[0059] 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.

[0060] It should be understood that the term "vehicle" or "of vehicles" 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.

[0061] This invention provides a service-oriented vehicle AUTOSAR communication system, such as... Figure 1 and Figure 7 As shown, see Figure 1 Specifically, it includes at least:

[0062] The server cluster consists of ECUs that provide services through the in-vehicle network. One of the service ECUs is selected as the master server and a control manager is set up to control and manage the other service ECUs.

[0063] The client must at least consist of an ECU (Engineer Control Unit) for obtaining services;

[0064] The server cluster and the client are connected through a gateway;

[0065] The client sends a request to the server. After receiving the request from the client, the server cluster distributes it to the subprocesses or threads in the ECU that provide the service for task processing.

[0066] See Figure 2 The flowchart shows the process of the control manager listening to and distributing client requests.

[0067] The control manager listens for requests from clients in the main process to obtain at least the distribution parameters. Based on the first request distribution number corresponding to the client's request and several first response distribution numbers generated by the response parameters corresponding to the child process or child thread, the control manager distributes the client's request to the child process or child thread corresponding to the matching first response distribution number for processing.

[0068] The first request distribution number and the first response distribution number are matched on a closed curve. The first response distribution number with the smallest difference between the two in the clockwise or counterclockwise direction is the matched number.

[0069] Alternatively, the first response distribution number with the smallest difference between the two can be considered a match, regardless of direction.

[0070] Specifically, in this embodiment, it is necessary to roughly balance the number of client requests being processed by each sub-thread or sub-process or the number of client requests being processed by each server to prevent a sub-process, sub-thread, or server from crashing due to overload. This embodiment designs a first request distribution number and generates a uniformly distributed first response distribution number. The client's request is distributed to the sub-thread or sub-process for processing by the first response distribution number that matches the first request distribution number.

[0071] The first request distribution count acquisition includes: the control manager listens for requests from clients in the main process, obtains the client's distribution parameters based on the listening, and performs calculations to obtain the first request distribution count. Each first request distribution count corresponds to a client's request.

[0072] First response distribution count acquisition includes:

[0073] The control manager will calculate the response parameters of the created child processes or child threads to obtain several first response distribution numbers and distribute them according to the first response distribution numbers; each child process or child thread corresponds to at least one first response distribution number.

[0074] The child process or child thread is created by the main process. The control manager virtually maps the first response distribution numbers corresponding to all existing child processes or child threads to the closed curve boundary connected end to end according to the numerical value.

[0075] On the boundary of the closed curve, find the child thread or child process that corresponds to the first request distribution number that is close to the first response distribution number of the client's request, and distribute the client's request to the found child thread or child process.

[0076] See details Figure 3 A schematic diagram showing the closed curve boundary to which the first response distribution number is mapped by a child process or child thread. From Figure 3Within the closed boundary of the rectangle, there are many first response dispatch numbers corresponding to child processes or child threads. Each first response dispatch number corresponds to a child process or child thread, which is usually the virtual node number of the corresponding first mapping table.

[0077] For example, if there is a child thread with process ID 00001, in order to achieve balanced distribution, several node IDs are created. Through response parameters (setting multiple node IDs), a child thread can be mapped to several first response distribution numbers. Each response distribution number has a corresponding response parameter. In other words, for the first response distribution numbers of the same child thread or child process, only the node ID is different in the corresponding response parameters.

[0078] Figure 3 In the process, the first request distribution number is point B. Following the counterclockwise direction, the first response distribution number that is closest to the first request distribution number is also point B. The sub-thread or sub-process corresponding to point B is responsible for handling the client's task.

[0079] Specifically, in the existing E / E architecture, there are many ECUs in the vehicle. Each ECU needs to obtain multiple services according to its function. For example, camera data and LiDAR data need to be adapted to different occasions, so they need to be processed in different ways.

[0080] In vehicle body control, the main unit needs to control the doors, windows, seats, automatic adjustment of rearview mirrors, air conditioning, etc., and the completion of these actions requires the client and server to work together to complete the protocol.

[0081] In this embodiment, an object-oriented communication method is adopted, which abstracts the requirements into client requests and the action processing into services, and realizes the client requests and the services provided by the server based on SOME / IP communication.

[0082] However, since intelligent vehicles have a large number of ECUs, a traditional single server cannot meet the demand. This embodiment uses a server cluster to provide services.

[0083] The server cluster in this invention consists of multiple ECUs in the vehicle that provide services. Each ECU can be equipped with a process pool or a thread pool, and multiple sub-threads or sub-processes are set in the process pool and thread pool to provide services through the sub-threads or sub-processes.

[0084] It should be noted that the ECU providing the service in this embodiment is also referred to as a server;

[0085] In existing servers, the main process monitors client requests. Only after a client request is sent does the main process create a new child process or thread to provide services and process tasks for the client. Once the task is completed, the main process destroys the child process. While this approach saves resources, it is extremely time-consuming. The creation of child processes by the main process, the preparation of subsequent processing by the child process, and their subsequent destruction all contribute to increased resource consumption and time, making it unsuitable for large-scale client requests and real-time requirements.

[0086] To address this issue, the above solution has been improved in this implementation.

[0087] After the vehicle network is initialized, in this embodiment, the main process creates a child process or child thread on a server in the server cluster.

[0088] Specifically, the amount of data in a child process or child thread can be customized according to requirements or the current server capacity, that is, it can be created all at once, rather than being created when there is a client demand.

[0089] For example, if there are 10 servers, the main process creates a preset number of child processes or child threads on each of the 10 servers.

[0090] In order to distribute client requests to the corresponding child processes or threads without causing too many or too few tasks to be processed on any one server, load balancing is required. This embodiment provides the following technical solution:

[0091] Specifically, see Figure 3 The control manager assigns numbers to child processes or child threads, calculates the first response distribution number based on the response parameters corresponding to the child process or child thread, and then maps the first response distribution number of each child process or child thread onto the closed curve boundary.

[0092] It should be noted that the server described in this embodiment is also called an ECU, which can only provide functions that are inconsistent, and the client is also understood as an ECU;

[0093] To achieve a balanced distribution, ensuring that each child process or thread has roughly the same probability of being assigned a response, the same child process or thread is mapped to multiple first response distributions. For example, if there are 4 child processes or threads, and each is mapped to 1000 first response distributions, then 4000 response distributions are generated and distributed to the closed curve boundary according to the size of the first response distribution.

[0094] The positions where the first response distribution number exists on the closed curve boundary are marked. By marking these positions, we can know the actual existence of the corresponding child process or child thread. Values ​​that are not marked on the curve boundary do not correspond to any child process or child thread, and their values ​​cannot be used as the basis for allocation.

[0095] Specifically, in this embodiment, the first response distribution number is obtained by calculating the response parameters corresponding to the subprocess or subthread. The response parameters of each subprocess or subthread are unique after the vehicle system is started and initialized. By setting the corresponding random function, consistency function, and uniform distribution function to calculate the response parameters, a first response distribution number with random distribution, consistent distribution, or uniform distribution is generated. Several first response distribution numbers are allocated to the closed curve boundary connected end to end, and each first response distribution number corresponds to a subprocess or subthread.

[0096] It should also be noted that not all boundary values ​​of closed curves connected end to end have corresponding child processes or child threads. Only the points where the value of the closed curve is equal to the first fraction have corresponding child processes or child threads.

[0097] Specifically, the steps for dispatching a client's request to a child process or child thread are as follows:

[0098] The control manager assigns a number to each child process or child thread and calculates the first response distribution number based on the response parameters corresponding to the child process or child thread.

[0099] Find the first response distribution number that is close to the first request distribution number on the boundary of the closed curve, and obtain the corresponding sub-thread or sub-process based on the first response distribution number;

[0100] The client's request is assigned to the corresponding sub-thread or sub-process for processing.

[0101] Specifically, the client's dispatch parameters, or the response parameters corresponding to the subprocess or subthread are as follows:

[0102] The client's distribution parameters must include at least two or more of the following: the client's IP address, MAC address, port number, and client ID.

[0103] The response parameters for a child process or child thread must include at least two of the following: the server's IP address, MAC address, port number, and child process ID or child thread ID.

[0104] For example, the function to run the client-side parameter distribution is G, and the client-side distribution parameters are IPAddr, ClientID, and PortNum.

[0105] FirstDistributeNum=G(IPAddr,PidNum,PortNum)

[0106] Where IPAddr, ClientID, and PortNum are the IP address, client ID, and port number, respectively.

[0107] FirstDistributeNum is the number of requests to be distributed in the first request.

[0108] For example, the function used to calculate the response parameters corresponding to child processes or child threads is also G.

[0109] The response parameters are IPAddr, MACaddr, PortNum, PidNum, and NodeNum.

[0110] First ResponseNum=G(IPAddr,MACaddr,PortNum, PidNum,NodeNum)

[0111] Wherein, IPAddr, MACaddr, PortNum, PidNum, and NodeNum are the IP address, physical address, port number, child process ID or child thread ID, and virtual node number of the child process or child thread, respectively.

[0112] That is, for a child thread or child process, IPAddr, MACaddr, PortNum, and PidNum are fixed after system initialization, and are variable virtual node numbers. Different first response dispatch numbers can be generated based on different successor node numbers.

[0113] For example: a subprocess or subthread generates 1000 first response dispatches, using different virtual node numbers, which can range from 0 to 999, and then calculates based on the generated responses to produce 1000 first response dispatches;

[0114] First ResponseNum is the number of first responses dispatched;

[0115] When allocating client requests, the system searches for a First ResponseNum that is close to FirstDistributeNum and has a virtual node on the boundary value of the closed curve. The child thread or child process corresponding to this First ResponseNum is then used to handle the client's request.

[0116] For example: Assume a scenario where FirstDistributeNum = 100. If the First ResponseNums close to 100 for virtual machine nodes are 98 and 103 respectively, then the sub-thread or sub-process with First ResponseNum = 98 will handle the client request for FirstDistributeNum = 100.

[0117] Specifically, in this embodiment, it is necessary to ensure the uniqueness of the input and output of function G.

[0118] The input and output of the algorithm used to calculate based on the distribution parameters of the client and obtain the first request distribution number correspond one by one. Each input corresponds to one output, and each output corresponds to one input.

[0119] Or the input and output of the algorithm used to calculate the first response distribution number based on the response parameters corresponding to the sub-process or sub-thread correspond one by one. Each input corresponds to one output, and each output corresponds to one input.

[0120] See Figure 4 and Figure 5 Specifically, the method by which the control manager distributes the client's requests to sub-processes or sub-threads can also be:

[0121] The control manager creates a hash ring. The range of the hash ring is 0 to of, 0 and are connected end to end.

[0122] All sub-processes or sub-threads in the server group are numbered and mapped to a number of virtual nodes. The corresponding hash values are obtained using the consistent hashing algorithm and mapped to the hash ring.

[0123] When a client requests, the consistent hashing algorithm generates a hash value for the client request according to the distribution parameters and selects the virtual service node hash value closest on the hash ring.

[0124] Use the virtual service node hash value to find the corresponding sub-process / sub-thread. After binding the corresponding sub-process / sub-thread to the client for service, the sub-process or sub-thread performs business processing.

[0125] Figure 4 In represents virtual service node 1, and so on. Among them, 100 < n < m, and n < m ≤ -1, V is virtual, s is service; Key is the hash value of the client generated by the consistent hashing algorithm; Key falls between and then The corresponding child process / thread is bound to the service to process the task.

[0126] Specifically, the client communicates with the subprocesses or threads in the server cluster using a SOME / IP-based communication protocol;

[0127] Each child process or thread handles only one client request at a time; after processing a client request, the child process or thread does not release itself, but continues to acquire the next client request to be processed and continue processing it.

[0128] When a child process or thread is assigned to requests from multiple clients, each thread in each process or thread pool listens to the assigned sockets using a preset method to see if there are any I / O operations that can be performed. Each child process or thread maintains its own loop and independently listens to different events.

[0129] The control manager uses a message queue to distribute sockets to child threads or child processes; when a child process or child thread writes data to the message queue, and detects that there is data to read in the message queue, it analyzes whether it is a new client requesting a connection. If so, it registers the read / write event on the new socket to its own I / O event model's event table.

[0130] To manage servers or their child processes and threads within a server cluster, this embodiment sets up a first mapping table and a second mapping table in the control manager. Specifically:

[0131] The control manager has a first mapping table used to record the control parameters corresponding to each subprocess or subthread;

[0132] The control manager has a second mapping table for recording server operating parameters;

[0133] Based on the parameters recorded in the first and second mapping tables, the control manager constantly monitors client requests and the processing of client requests by the server's child processes or threads in the server cluster, thereby achieving load balancing.

[0134] See Figure 6 The first mapping table includes at least two of the following: child process or child thread number, IP address, port number of child process or child thread, child process ID or child thread ID, virtual node number, number of first response dispatches, and number of first request dispatches.

[0135] See Figure 7 The second mapping table must include at least two of the following: the server number managed by the control manager, the server IP, the number of currently working child processes or child threads, the maximum number of supported processing threads, the server's current computing power usage, and the maximum processing load threshold.

[0136] When a client's request is disconnected, the server containing the sub-thread or sub-process that handled the client's request stores the client's computation state in a buffer for a preset waiting time.

[0137] When a disconnected client requests a connection again, the control manager obtains the first request distribution number based on the disconnected client's distribution parameters, and then finds a sub-thread or sub-process on the closed curve boundary that is close to the first response distribution number based on the first request distribution number and assigns it to the client. The sub-thread or sub-process then reads the buffer to store the client's state and continues to process the data.

[0138] The number of the child thread or child process corresponding to the first response distribution number obtained from the first request distribution number of the disconnected client is compared with the number of the child process or child thread corresponding to the first response distribution number in the first mapping table. If they are different, the disconnected client request is distributed to the child process or child thread corresponding to the first response distribution number recorded in the first mapping table.

[0139] When the control manager detects a failure in a subprocess, subthread, or server in the service cluster, the control manager automatically deletes the first response distribution count corresponding to the failed subprocess or subthread, or the first response distribution count corresponding to all subprocesses or subthreads in the failed server of the service cluster, on the closed curve boundary.

[0140] Then, subsequent client requests are processed by the normally operating subprocess or subthread, or the subprocess or subthread in the normally operating server, corresponding to the first response distribution number obtained after obtaining the first request distribution number.

[0141] Specifically, the technical solution provided in this embodiment can balance the sub-threads or sub-processes of newly added or deleted servers, and can ensure that disconnected client requests can connect to the sub-threads, sub-processes or servers before the disconnection.

[0142] When a new server is added to the server cluster, the controller manager assigns a number to the main process or child process created by the main process in the new service. It then calculates a number of first response distributions based on the response parameters of the child process or child thread. Finally, it maps the first response distribution of each child process or child thread onto a closed curve boundary to complete the distribution of child processes or child threads in the new server.

[0143] The control manager has a security protection policy. If a server in the service cluster, a subprocess or thread in the server, or a client request does not meet the security protection policy, the corresponding first response distribution number will be removed at the closed curve boundary.

[0144] Or reject the client's request.

[0145] When a server in an existing server cluster is overloaded or fails, the usual approach is to distribute the services provided by the overloaded server to child processes or child processes of adjacent servers. However, this approach can easily lead to system paralysis. The current health code system uses this method because the services provided by the failed server are transferred to adjacent servers, but the system does not consider the maximum load capacity of adjacent servers, causing them to become overloaded and fail, and so on, leading to a sequential failure of adjacent servers. Therefore, to solve this problem, this embodiment adopts the following solution:

[0146] When the control manager learns from the second mapping table that there is a service ECU in the server cluster whose load exceeds the maximum processing load threshold, it stops distributing client requests to the service ECU whose load exceeds the maximum processing load threshold.

[0147] When the control manager calculates the first request distribution number based on the new client request and finds the child process or child thread corresponding to the first request response number that is closest to the first request distribution number in the service ECU whose load exceeds the maximum processing load threshold, the control manager removes the first response distribution number corresponding to all child processes or child threads in the service ECU that exceeds the maximum processing load threshold on the closed curve boundary.

[0148] When the control manager finds that the child process or child thread that is closest to the first request response number does not meet the requirements, it searches for the second child process or child thread that is closest to the first request response number. If the service ECU where the child process or child thread is located meets the requirements, the new client request is distributed to the second child process or child thread that is closest to the first request response number.

[0149] The above description represents only 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 service-oriented vehicle AUTOSAR communication system, characterized in that, include: The server cluster consists of ECUs that provide services through the in-vehicle network. One of the service ECUs is selected as the master server and a control manager is set up to control and manage the other service ECUs. The client must at least consist of an ECU (Engineer Control Unit) for obtaining services; The server cluster and the client are connected through a gateway; The client sends a request to the server. After receiving the request from the client, the server cluster distributes it to the subprocesses or threads in the ECU that provide the service for task processing. The control manager listens for requests from clients in the main process to obtain at least the distribution parameters. Based on the first request distribution number corresponding to the client's request and several first response distribution numbers generated by the response parameters corresponding to the child process or child thread, the control manager distributes the client's request to the child process or child thread corresponding to the matching first response distribution number for processing. The control manager has a first mapping table used to record the control parameters corresponding to each subprocess or subthread; The control manager has a second mapping table for recording server operating parameters; The control manager monitors client requests and the processing of client requests by the server's child processes or threads in the server cluster based on the parameters recorded in the first and second mapping tables, thereby achieving load balancing. The first request distribution count acquisition includes: the control manager listens for requests from clients in the main process, obtains the client's distribution parameters based on the listening, and performs calculations to obtain the first request distribution count. Each first request distribution count corresponds to one client's request. First response distribution count acquisition includes: The control manager calculates the response parameters of the created child processes or child threads to obtain a number of first response dispatches; each child process or child thread corresponds to at least one first response dispatch. The child process or child thread is created by the main process. The control manager virtually maps the first response distribution numbers corresponding to all existing child processes or child threads to the closed curve boundary connected end to end according to the numerical value. On the boundary of the closed curve, find the child thread or child process that corresponds to the first request distribution number that is close to the first response distribution number of the client's request, and distribute the client's request to the found child thread or child process.

2. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, The control manager can also distribute client requests to child processes or child threads in the following ways: The control manager creates a hash ring, with a range of 0~ 0 and Connected end to end; All child processes or child threads in the server cluster are numbered and mapped to several virtual nodes. The corresponding hash values ​​are obtained using a consistent hashing algorithm and mapped onto a hash ring. When a client makes a request, the consistent hashing algorithm generates a hash value for the client request based on the distribution parameters and selects the hash value of the nearest virtual service node from the hash ring; The corresponding child process / thread is found using the hash value of the virtual service node, and then the corresponding child process / thread is bound to the client service before the child process or thread performs business processing.

3. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, The client's distribution parameters must include at least two or more of the following: the client's IP address, MAC address, port number, and client ID. The response parameters for a child process or child thread must include at least two of the following: the server's IP address, MAC address, port number, child process ID or child thread ID, and virtual node number.

4. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, The algorithm calculates and obtains the first request distribution number based on the client's distribution parameters. The input and output of the algorithm are in one-to-one correspondence, with each input corresponding to one output and each output corresponding to one input. Alternatively, the first response distribution number can be obtained by calculating the response parameters corresponding to the subprocess or subthread. The input and output of the algorithm used are in one-to-one correspondence, with each input corresponding to one output and each output corresponding to one input.

5. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, The client communicates with the subprocesses or threads in the server cluster using a SOME / IP-based communication protocol. Each child process or thread handles only one client request at a time; after processing a client request, the child process or thread does not release itself, but continues to acquire the next client request to be processed and continue processing it.

6. The service-oriented vehicle AUTOSAR communication system as described in claim 5, characterized in that, When a child process or thread is assigned to requests from multiple clients, each thread in each process or thread pool listens to the assigned sockets using a preset method to see if there are any I / O operations that can be performed. Each child process or thread maintains its own loop and independently listens to different events.

7. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, The control manager uses a message queue to distribute sockets to child threads or child processes; when a child process or child thread writes data to the message queue, and detects that there is data to read in the message queue, it analyzes whether it is a new client requesting a connection. If so, it registers the read / write event on the new socket to its own I / O event model's event table.

8. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, The first mapping table includes at least two of the following: child process or child thread number, IP address, port number of child process or child thread, process ID, virtual node number, first response distribution number, and first request distribution number; The second mapping table includes at least two of the following: server number managed by the control manager, server IP, number of currently working subprocesses or subthreads, maximum supported number of processing threads, current computing power usage of the server, and maximum processing load threshold.

9. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, When a client's request is disconnected, the server containing the sub-thread or sub-process that handled the client's request stores the client's computation state in a buffer for a preset waiting time. When a disconnected client requests a connection again, the control manager obtains the first request distribution number based on the disconnected client's distribution parameters, and then finds a sub-thread or sub-process on the closed curve boundary that is close to the first response distribution number based on the first request distribution number and assigns it to the client. The sub-thread or sub-process then reads the buffer to store the client's state and continues to process the data.

10. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, The number of the child thread or child process corresponding to the first response distribution number obtained from the first request distribution number of the disconnected client is compared with the number of the child process or child thread corresponding to the first response distribution number in the first mapping table. If they are different, the disconnected client request is distributed to the child process or child thread corresponding to the first response distribution number recorded in the first mapping table.

11. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, When the control manager detects a failure in a subprocess, subthread, or server in a service cluster, the control manager automatically deletes the first response distribution count corresponding to all subprocesses or subthreads in the failed subprocess, subthread, or server in the failed service cluster from the closed curve boundary. Then, subsequent client requests are processed by the normally operating subprocess or subthread, or the subprocess or subthread in the normally operating server, corresponding to the first response distribution number obtained after obtaining the first request distribution number.

12. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, When a new server is added to the service cluster, the controller manager assigns a number to the main process or child process created by the main process in the new service, and calculates a number of first response distribution numbers based on the first response parameters corresponding to the child process or child thread. Then, it maps the first response distribution numbers to the closed curve boundary to complete the distribution of child processes or child threads in the new server.

13. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, The control manager has a security protection policy. If a server in the service cluster, a subprocess or thread in the server, or a client request does not meet the security protection policy, the corresponding first response distribution number will be removed at the closed curve boundary. Or reject the client's request.

14. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, When the control manager learns from the second mapping table that there is a service ECU in the server cluster whose load exceeds the maximum processing load threshold, it stops distributing client requests to the service ECU whose load exceeds the maximum processing load threshold. When the control manager calculates the first request distribution number based on the new client request and finds the child process or child thread corresponding to the first request response number that is closest to the first request distribution number in the service ECU whose load exceeds the maximum processing load threshold, the control manager removes the first response distribution number corresponding to all child processes or child threads in the service ECU that exceeds the maximum processing load threshold on the closed curve boundary.

15. The service-oriented vehicle AUTOSAR communication system as described in claim 1, characterized in that, When the control manager finds that the child process or child thread that is closest to the first request response number does not meet the requirements, it searches for the second child process or child thread that is closest to the first request response number. If the service ECU where the child process or child thread is located meets the requirements, the new client request is distributed to the second child process or child thread that is closest to the first request response number.

Images