CN112685008A

CN112685008A - Service failure control method adopting service-oriented architecture based on AUTOSAR

Info

Publication number: CN112685008A
Application number: CN202011372393.0A
Authority: CN
Inventors: 肖文平; 何敖东
Original assignee: Shanghai Hinge Electronic Technologies Co Ltd
Current assignee: Shanghai Hinge Electronic Technologies Co Ltd
Priority date: 2020-11-30
Filing date: 2020-11-30
Publication date: 2021-04-20

Abstract

The invention provides a service failure control method adopting a service-oriented architecture based on AUTOSAR, which comprises the following steps: the server required by the client comprises a main server and at least one slave server, the slave server can at least provide the service with the same function as the main server, and when the main server fails, the client corresponding to the main server transfers the request to the slave server; each request and response from a server or client is time stamped with a synchronization. Through the service failure control mechanism provided by the invention, the system can monitor in time and seamlessly start the backup service to continuously execute the task after the service fails, the safety and the reliability of the service-oriented architecture are improved, and a powerful guarantee is provided for the automatic driving and unmanned driving technologies.

Description

Service failure control method adopting service-oriented architecture based on AUTOSAR

Technical Field

The invention relates to the field of automobiles, in particular to a service failure control method adopting a service-oriented architecture based on AUTOSAR.

Background

With the continuous development of computing systems, sensor technologies such as cameras and laser radars, machine learning and deep neural networks, it is feasible to install various driving assistance and automatic driving functions in modern automobiles. These functions greatly increase the amount and complexity of the computing resources used in the automobile. Furthermore, automobiles are essential for safety. Stringent safety requirements only further exacerbate the complexity of automotive systems. At present, in order to meet the requirements of high bandwidth and real-time transmission, communication buses for automatic driving and assistant driving have been transferred from traditional CAN buses, Flex buses and the like to vehicle-mounted ethernet buses, because of the numerous ECUs involved in automatic driving, assistant driving and the like, the data processing capacity is large, and in order to improve the efficiency, a network architecture based on AUTOSAR is introduced into an automobile, which adopts service-oriented services, and in the process of adopting service-oriented services, it connects different functional units (called services) of an application program through well-defined interfaces and contracts among the services. The interface is defined in a neutral manner, independent of the hardware platform, operating system, and programming language in which the service is implemented. This allows services built into a wide variety of systems to interact in a uniform and versatile manner. The system comprises a service-oriented architecture, a network and a server, wherein the service-oriented architecture can be used for carrying out distributed deployment, combination and use on loosely-coupled coarse-grained application components through the network according to requirements. However, the service-oriented client provides the requirements and the server provides the services, the client and the server are mutually independent, once the services fail, the client does not know the services, so that the client cannot obtain the required services in time when calling the services provided by the server next time, the function of the system fails, and the phenomenon is not allowed when the automobile is in a driving process. Therefore, there is a need to provide a highly reliable solution to disable the server and still enable the client to obtain its required services to improve the security of the car.

Disclosure of Invention

The invention provides a service failure control method adopting a service-oriented architecture based on AUTOSAR, which comprises the following steps: the server required by the client comprises a main server and at least one slave server, the slave server can at least provide the service with the same function as the main server, and when the main server fails, the client corresponding to the main server transfers the request to the slave server; each request and response from a server or client is time stamped with a synchronization.

A service failure control method based on AUTOSAR adopts a service-oriented architecture, further, a client sets a fusion strategy and sends out a request through a request interface, the client implements the fusion strategy and returns a result according to the response of a server, and each request and response from the server or the client carry a synchronized timestamp.

A service failure control method adopting a service-oriented architecture based on AUTOSAR (automotive open system architecture), further, a client starts service discovery through a service discovery interface, is connected to all corresponding main servers and slave servers and maintains the state;

the service discovery interface allows a client to initiate a service discovery call to connect to a particular service ID, the client using the specified service ID to establish a connection with all its corresponding master and slave servers and maintain state.

A service failure control method based on AUTOSAR and adopting a service-oriented architecture, further, if repeated service for requested service ID exists, a fusion interface allows a client to self-define a fusion strategy, and according to the requirement of the fusion strategy, the client uses a unique identifier and a time stamp primitive to identify the repeated service;

the request interface allows the client to issue a single request call, with the request being relayed to all of the master and slave servers maintained by the client.

A service failure control method based on AUTOSAR and adopting service-oriented architecture further comprises the steps that each client at least has a backup client with the same function, if the client and the backup client request the same service, a server provides a self-defined selection strategy through a selection interface, and the server uses a unique identifier and a time stamp primitive to identify repeated requests;

and the server implements the selection strategy according to the selection strategy when receiving the request from the client, and returns the output to all the clients and the backup client.

A service failure control method based on AUTOSAR adopts a service-oriented architecture, further, a slave server and a main server do not run synchronously, the slave server monitors the main service, and when the main service is found to be failed, the slave service replaces the main service to provide service for a corresponding client.

A service failure control method adopting a service-oriented architecture based on AUTOSAR (automotive open system architecture), further, when connection is not established between a client and a server, a main server fails, and the server is restarted immediately; the restarting of the server comprises: the health management module established in the AUTOSAR is provided with a watchdog module to monitor the server, and once the server process fails to start, a watchdog counter expires, the health management module is triggered to call the execution management module to restart the server process.

A service failure control method based on AUTOSAR adopts a service-oriented architecture, and further, when a server is connected with a client, if at least one slave server is successfully connected with a master server and the client for an asynchronous master server and a non-synchronous slave server, when the master server fails, the slave server processes the failure of the master server or the client processes the failure of the master server or the master service processes the failure of the master server.

A service failure control method based on AUTOSAR adopts a service-oriented architecture, further, when a main server carries out a main stage and immediately fails after a service providing information is sent to a client, a secondary server does not receive a notification message from the main server after waiting for the life time of the service providing information, confirms that the main server fails and replaces the main service to provide the service for the client by the secondary server, and simultaneously sends the notification message to inform the client to provide the service;

each service providing message is provided with a time-to-live, which is defined as the time length of existence of the service providing message.

A service failure control method based on AUTOSAR adopts a service-oriented architecture, further, when a main server carries out a main stage and finds that a service providing function is failed after a service providing message is sent to a client, the main server sends a service stopping message to a slave server and the client, and the slave server replaces the main server and sends a notification message to inform the client to provide the service after receiving the message of the main service stopping service.

A service failure control method based on AUTOSAR adopts a service-oriented architecture, further, when a main server carries out a main stage and a client sends a service request to the main server and a slave server, after the main server receives the back request, the main server immediately fails after sending response information to the slave server and the client, the client starts a timer, the timer is set as processing duration associated with each request, when the processing duration is exceeded and the response of the main server is not received, the client considers that the server fails, and notifies the slave server to replace the main server to provide service.

A service failure control method adopting a service-oriented architecture based on AUTOSAR comprises the following steps: the method for the client to start the task logic to call the remote service comprises the following steps: the method comprises the steps that a client starts a task logic generation method calling request, simultaneously generates an identifier with a time label tc, sends the identifier to a client method processing module, adds deadline { tc, Dc } through the client method processing module, and sends the deadline { tc, Dc } to a server;

the server calls internal logic to generate service data corresponding to the method request, adds a Cf ═ tc, Dc, L, E time stamp corresponding to the method request, generates a time label of { ts, Cf } at the same time, adds the time stamp { ts, Ds, Cf } through the service method processing module, sends the time label to the client method processing module, judges the time label, and sends the service data to the client.

A service failure control method based on AUTOSAR adopts a service-oriented architecture, and further a client method processing module judges whether a preset cut-off time Dc is exceeded or not before a call request is sent, if the preset cut-off time Dc is not exceeded, sending is carried out, otherwise, sending is not carried out.

A service failure control method based on AUTOSAR adopts a service-oriented architecture, further, a server analyzes the associated parameters and the time stamps { tc, Dc } of a method call request message through a service method processing module, increases { tc, Dc, L, E } in the time stamps, and if the time stamps { tc, Dc, L, E } are in a preset time threshold range, the associated parameters of the method call request are sent to the server to call internal logic to realize service data corresponding to the method call request and add Cf time stamps corresponding to the service request;

l is the longest allowed network delay and E is the maximum clock offset error for different platforms.

A service failure control method based on AUTOSAR (automotive open system architecture) adopting a service-oriented architecture is further characterized in that a client method processing module judges whether received service data is in a preset time threshold value allowed range according to a { ts, Ds, L, E, Cf } label, if so, judges whether a corresponding time label corresponds to a time label when a method calling request is carried out, and if so, sends the service data to a client; the time tag is determined by analyzing { tc, Dc } from Cf, and determining whether { tc, Dc } matches with { tc, Dc } tag requested by the transmission method, if yes, the time tag corresponds to the { tc, Dc } tag, and if not, the time tag is discarded.

Has the advantages that:

through the service failure control mechanism provided by the invention, the system can monitor in time and seamlessly start the backup service to continuously execute the task after the service fails, the safety and the reliability of the service-oriented architecture are improved, and a powerful guarantee is provided for the automatic driving and unmanned driving technologies.

In addition, a following mechanism of synchronization and correction of the time labels is provided, so that the client and the server can judge whether the current data is required by the client and the server according to the time labels, wrong operation decision caused by the fact that service data is lost and covered due to complex task scheduling in the chain service is avoided, and safety accidents or system errors caused by logic errors are avoided.

Drawings

The following drawings are only schematic illustrations and explanations of the present invention, and do not limit the scope of the present invention.

Fig. 1 is a schematic diagram of an architecture of an automotive-based adaptive platform according to an embodiment of the present invention.

Fig. 2 is a schematic diagram of a vehicle-mounted network architecture including an automotive architecture ECU and a conventional ECU according to an embodiment of the present invention.

Fig. 3 is a flowchart illustrating a processing procedure of a plan after a server in a network node fails according to an embodiment of the present invention.

Fig. 4 is a flowchart illustrating a method for a client sending a call request to a server and acquiring a service in a network node according to an embodiment of the present invention.

Detailed Description

For a more complete understanding of the features, objects, and advantages of the present invention, reference is now made to the following description taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout. For the sake of simplicity, the drawings are schematic representations of relevant parts of the invention and are not intended to represent actual structures as products. In addition, for simplicity and clarity of understanding, only one of the components having the same structure or function is schematically illustrated or labeled in some of the drawings.

As for the control system, the functional module, application program (APP), is well known to those skilled in the art, and may take any suitable form, either hardware or software, and may be a plurality of functional modules arranged discretely, or a plurality of functional units integrated into one piece of hardware. In its simplest form, the control system may be a controller, such as a combinational logic controller, a micro-programmed controller, or the like, so long as the operations described herein are enabled. Of course, the control system may also be integrated as a different module into one physical device without departing from the basic principle and scope of the invention.

The term "connected" in the present invention may include direct connection, indirect connection, communication connection, and electrical connection, unless otherwise specified.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, values, steps, operations, elements, and/or components, but do not preclude 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 associated listed items

It should be understood that the term "vehicle" or "vehicular" or other similar terms as used herein generally includes motor vehicles such as passenger automobiles including Sport Utility Vehicles (SUVs), buses, trucks, various commercial vehicles, watercraft including a variety of boats, ships, aircraft, and the like, and includes hybrid vehicles, electric vehicles, plug-in hybrid electric vehicles, hydrogen-powered vehicles, and other alternative fuel vehicles (e.g., fuels derived from non-petroleum sources). As referred to herein, a hybrid vehicle is a vehicle having two or more power sources, such as both gasoline-powered and electric-powered vehicles.

Further, the controller of the present disclosure may be embodied as a non-transitory computer readable medium on a computer readable medium containing executable program instructions executed by a processor, controller, or the like. Examples of computer readable media include, but are not limited to, ROM, RAM, Compact Disc (CD) -ROM, magnetic tape, floppy disk, flash drive, smart card, and optical data storage device. The computer readable recording medium CAN also be distributed over network coupled computer systems so that the computer readable medium is stored and executed in a distributed fashion, such as over a telematics server or a Controller Area Network (CAN) or a vehicle mounted ethernet.

Fig. 1 is a schematic diagram of an architecture based on an AUTOSAR adaptive platform, which includes a hardware layer, an AUTOSAR layer, a middleware based on SOME/IP, and an application layer, where the AUTOSAR layer includes a state management module, an execution management module, a health management module, a watchdog, a communication management module, an operating system, and the like, and the adaptive application is on the adaptive platform and is suitable for the AUTOSAR running of the adaptive application. The adaptive platform consists of application program interfaces provided by functional clusters, which belong to the adaptive platform foundation or adaptive platform services. The adaptive platform base provides the core functions of the adaptive platform services, while the adaptive platform provides the support services. Any application program can also provide services for other application programs, the operating system is responsible for the runtime resource management (including time) of all application programs on the adaptive platform, and the execution management is responsible for the system to execute the aspects of process starting, relationship, restarting and the like, such as: platform initialization and application startup/shutdown, communication management responsible for all aspects of communication between applications in a distributed real-time embedded environment, communication management using the SOME/IP protocol stack to manage communication between applications.

Specifically, the present embodiment provides a service failure control method for an automotive open system architecture, including: a plurality of servers and a plurality of clients, the servers and clients running on the AUTOSAR platform. A server acts as a service when it provides a service and as a client when it needs to obtain a service. Similarly, when the client acquires the service, the client serves as the client, and when the client provides the service to the outside, the client serves as the server. It should be noted that, the server and the client are distinguished according to whether to obtain a service or call a service, and both the server and the client are application programs, which may be located in the same ECU based on the adaptive AUTOSAR architecture or in ECUs based on the AUTOSAR architecture, respectively, see fig. 2, and fig. 2 is a schematic diagram of a vehicle-mounted network architecture including the ECUs based on the AUTOSAR architecture and a conventional ECU, and includes: the system comprises an AUTOSAR architecture ECU1, an AUTOSAR architecture ECU2, a traditional ECU1, a traditional ECU2 and a service conversion ECU, wherein the AUTOSAR architecture ECU1, the AUTOSAR architecture ECU2 and the service conversion ECU are connected with a TSN gateway through an on-board Ethernet bus, and the traditional ECU1 and the traditional ECU2 are connected with the service conversion ECU through one of a CAN bus, a LIN bus and a MOST bus. The AUTOSAR architecture ECU1 provides a plurality of servers each providing a service, such as server 1, server 2, server 3, wherein server 1 may be set as a master service and server 2 and server 3 as slave servers.

Client 1 is a master client and client 2 is a slave client. The service conversion ECU is provided with a service conversion module, the service conversion module runs on an AUTOSAR framework and an application layer, and is responsible for converting a signal which is sent by a traditional ECU and has service provision function into service based on an SOME/IP protocol and an SOME/IP-SD protocol, and encapsulating the service in a server for being called by a corresponding client.

After the client side is connected with the server, the client side subscribes the service provided by the server, the server required by the client side comprises a main server and at least one slave server, the slave server can at least provide the service with the same function as the main server, and when the main server fails, the client side corresponding to the main server transfers the request to the slave server;

in order to enable the client and the server to smoothly communicate, a request interface, a fusion interface and a service discovery interface are arranged at the client;

the service discovery interface is used to allow a client to initiate a service discovery call to connect to a specific service ID, the client using the specified service ID to establish a connection with all its corresponding master and slave servers and maintain state.

The convergence interface allows the client to customize the convergence policy, and if there is a duplicate service for the requested service ID, the client identifies the duplicate service using a unique identifier and a timestamp primitive as required by the convergence policy.

The fusion strategy definition judges whether the service IDs are the same according to the service IDs received from the main server and the plurality of auxiliary servers, and if the service IDs are the same, the main server is selected for service; if not, selecting a server with a high-priority service ID for service according to the requirement; and if the current server fails, selecting the server with the shortest transmission delay or the server with the shortest propagation path from the current slave servers to provide services.

The client sets a fusion strategy, sends out a request through a request interface, implements the fusion strategy and returns a result according to the response of the server, and each request and response from the server or the client are provided with synchronized timestamps.

Because the client and the server may exist in different ECUs, the time stamp is meaningful only because the time of the client and the time of the server need to be synchronously corrected, otherwise, errors occur in the time of the client and the time of the server due to transmission delay and transmission priority, and serious influence is caused on driving safety of automatic driving and unmanned driving.

Each client has at least backup clients with the same function, if the client and the backup client request the same service, the server provides a custom selection strategy through a selection interface, and the server uses a unique identifier and a time stamp primitive to identify repeated requests;

Specifically, the server provides the service due to the client calling. Under different conditions, the client is also a server of other clients, and if the client fails, system failure may be caused, so in this implementation, the client also sets a backup client.

And a selection interface is arranged at the server side, allows the server to select the service with the same request from the client side and the backup client side, and selects one client side to provide the service according to the requirement. Preferably, the primary client is selected to be served, and when the primary client fails, the backup client is selected to be served.

The slave server and the main server do not run synchronously, the slave server monitors the main service, and when the main service is found to be invalid, the slave service replaces the main service to provide service for the corresponding client.

The slave service monitors the master service by subscribing to the master service notification message through service discovery;

the slave service replica does not participate in service discovery, and service only occurs when the master service fails.

The client provides service messages to exchange health status with the backup client.

Specifically, since it takes time and often happens to establish communication connection between the car networks, the car network is operated during the starting process of the car, and the car network is not operated after the car is shut down.

In particular, the implementation divides the communication mode between the client and the server by stages to describe SOME important system control parameters, in the SOME-IP/SD, the service sends out a providing message to provide the service in the network, and the client sends out a searching message to locate the service in the network. The SOME-IP/SD is conventionally divided into an initial waiting phase, a repeating phase, and a main phase, and the present embodiment is divided into a connection establishment phase and a non-connection establishment phase for reliability and security. Referring specifically to fig. 3, fig. 3 is a flowchart of a processing procedure of a plan after a server in a network node fails.

Specifically, when the automobile is powered on through the ACC, the ECU of the node in the vehicle-mounted network starts initialization;

when the connection between the client and the server is not established, the main server fails, and in order to meet the requirement of system operation, the server needs to be restarted immediately within a preset reply time threshold;

however, because the connection between the client and the server is not established, the backup server and the client cannot know the server after the server fails, and in order to solve the problem, the specific process of restarting the server adopted in the implementation includes: the health management module established in the AUTOSAR is provided with a watchdog module to monitor the server, and once the process is failed to start, a watchdog counter expires to trigger the health management module to call an execution module to restart the server process.

But under some special conditions, the task still fails after multiple restarts, so the setup allows different operations to be performed depending on the number of times the watchdog timer expires.

When a connection is established between a client and a server, if the server fails, there are two possible outcomes depending on whether the failure is handled or not. If a process is able to handle a failure, a backup mechanism may be raised, but if the failure cannot be handled, the backup mechanism cannot be raised. For example, when power is removed after a service failure, the backup mechanism cannot be triggered.

The failure of the embodiment is directed at that the master server and the slave server are not synchronized, and the slave server replaces the master server when the master server fails, continues to provide service for the client, and provides reliability and safety.

When the server is connected with the client, if at least one of the asynchronous main server and the asynchronous auxiliary server is successfully connected with the main server and the asynchronous auxiliary server, the auxiliary server processes the failure of the main server or the client processes the failure of the main server or the main server processes the failure of the main server.

When the main server carries out the main stage and immediately fails after the service for providing the message is sent to the client, the slave server does not receive the notification message from the main server after waiting for the life time of the service providing message, confirms that the main server fails and replaces the main service to provide the service for the client, and simultaneously sends the notification message to inform the client to provide the service.

The main stage is set as follows: at this stage, the client remains in the silent state and the service continues to send provisioning messages to indicate its availability for the period of control parameter settings.

When the main server carries out the main stage and finds that the function of providing the service is invalid after the service for providing the message is sent to the client, the main server sends a message for stopping the service to the slave server and the client, and the slave server replaces the main server and sends a notification message to inform the client to provide the service after receiving the message for stopping the service from the main server.

When the main server carries out a main stage and the client side sends service requests to the main server and the slave servers, after the main server receives the back requests, the main server immediately fails after sending response information to the slave servers and the client sides, each client side starts a timer, the timer is set to be processing time length relevant to each request, when the processing time length is exceeded and the response of the main server is not received, the client side considers that the server fails, and informs the slave servers to replace the main server to provide services.

In the adaptive AUTOSAR platform, a service is used as a basic unit, the execution of an action is often required to be completed together by a plurality of services, the services are from different ECUs, if a client 1 calls a service 1, the service 1 calls a service 2, the service 2 calls a service 3, the service 3 calls a service 4, the service 1 and the service 2 and the service 3 and the service 4 respectively process different ECUs, because the related processes are complex, in a transmission protocol adopting a TSN, a priority process exists, data generated by the previous service is stored in a cache required to be called by the next service, the next service judges whether data exists in the cache before the operation is executed, and if the data does not exist, the next service does not execute the operation. Therefore, it is possible that the data generated by the previous service is already overwritten before the next service acquires the cached data, so that the next service acquires the current cached data to perform the operation, and then an error result is generated. In order to solve the reliability of the client and the server, the embodiment provides a solution:

with particular reference to fig. 4: more task processing logic is encapsulated into the server or client,

according to the requirement, the client starts a task logic generation method to call the remote service, the client generates an identifier with a time label tc and sends the identifier to an output port of the client method processing module through an input port of the client, and the output port is provided with a cut-off time Dc;

if the preset cut-off time Dc is not exceeded, the client method processing module sends a timestamp marked by tc and Dc to the SOME/IP module through a bypass, and meanwhile, a method call for requesting service is generated according to the client method processing module and sent to the service agent module;

the service agent module judges whether the request is legal, if so, the data associated with the incoming event is forwarded as a method parameter, and meanwhile, the service agent module generates a network message requesting for additionally adding a timestamp corresponding to the current method parameter when the SOME/IP module packages the method parameter;

the method comprises the steps that a SOME/IP module obtains method parameters, the SOME/IP module searches whether timestamp parameters corresponding to the method parameters exist or not, if the timestamp parameters { tc, Dc } exist, the timestamp parameters { tc, Dc } are additionally added into the method parameters, and the method parameters are sent to a TSN gateway transfer server through a vehicle-mounted Ethernet bus by an SOME/IP protocol;

when the server receives the message of method call, the SOME/IP module analyzes the message of method call and sends the { tc, Dc } timestamp message to the server method processing module through the bypass, and then sends the corresponding method call request to the service framework module; when a service framework module receives a message of method calling, analyzes and then sends a correlation parameter of a method calling request to a service method processing module, the correlation parameter of the method calling request triggers service method module interruption, then a check is carried out to receive a timestamp { tc, Dc }, when the timestamp { tc, Dc } is received, a timestamp with { tc, Dc, L, E } is generated, L is the allowable longest network delay, and E is the maximum clock offset error of different platforms;

the service method module analyzes the method calling request and judges whether the calling of the client is in a preset time threshold value allowable range or not according to the time tag of { tc, Dc, L, E } and a preset time threshold value, if so, the service method module sends the method calling request to the server to call internal logic to realize service data corresponding to the method request and adds a Cf ═ { tc, Dc, L, E } timestamp corresponding to the service request;

the server generates a time stamp with a label { ts, Cf } to an input port, and sends the time stamp to an output port of the service method processing module through the input port, the output port is provided with a cut-off time Ds, and if the preset cut-off time Ds is not exceeded, the client method processing module sends the time stamp marked by the { ts, Ds, Cf } through a bypass and returns data related to the event to the service framework module;

wherein ts > (tc + Dc + L + E);

the service framework calls the SOME/IP module to create a response message, and the SOME/IP acquires { ts, Ds, Cf } from the timestamp bypass, attaches the response message to the response message, and then sends the response message to the client through the vehicle-mounted Ethernet bus;

the client acquires (ts, Ds, Cf) from the message through the SOME/IP module, sends the message to the client method processing module through the bypass, and forwards the response message to the service agent module; triggering the interrupt of a client method processing module by the arrival of a response message, acquiring { ts, Ds, Cf } from a timestamp bypass by the client method processing module, adding time delay and clock offset into a time label { ts, Ds, L, E, Cf }, judging whether the received service data is in a preset time threshold allowed range or not by the client method processing module according to the { ts, Ds, L, E, Cf } label, judging whether a corresponding label corresponds to the label when the method is requested or not if the received service data is in the preset time threshold allowed range, and sending the service data to the client if the corresponding label is in the preset time threshold allowed range; and judging whether the tc, Dc are consistent with the label requested by the sending method or not according to the tc, Dc analyzed from the Cf, if so, the corresponding label is corresponding, and if not, the label is discarded.

What has been described above is only a preferred embodiment of the present invention, and the present invention is not limited to the above examples. It is clear to those skilled in the art that the form in this embodiment is not limited thereto, and the adjustable manner is not limited thereto. It is to be understood that other modifications and variations, which may be directly derived or suggested to one skilled in the art without departing from the basic concept of the invention, are to be considered as included within the scope of the invention.

Claims

1. A service failure control method adopting a service-oriented architecture based on AUTOSAR is characterized by comprising the following steps: the server required by the client comprises a main server and at least one slave server, the slave server can at least provide the service with the same function as the main server, and when the main server fails, the client corresponding to the main server transfers the request to the slave server; each request and response from a server or client is time stamped with a synchronization.

2. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 1, characterized in that the client sets a fusion policy and sends out a request through the request interface, and based on the response of the server, the client implements the fusion policy and returns the result, and each request and response from the server or client carries a synchronized timestamp.

3. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 1, characterized in that the client starts service discovery through a service discovery interface, connects to all the master servers and slave servers corresponding to the client and maintains the status;

4. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 2, characterized in that, if there is a duplicate service for the requested service ID, the convergence interface allows the client to customize the convergence policy, and the client uses a unique identifier and a time stamp primitive to identify the duplicate service according to the requirements of the convergence policy;

5. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 1, wherein each client has at least a backup client with the same function, if the client and the backup client request the same service, the server provides a custom selection policy through a selection interface, and the server uses a unique identifier and a time stamp primitive to identify the repeated request;

6. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 1, wherein the slave server and the master server do not run synchronously, the slave server monitors the master service, and when the master service is found to be failed, the slave service replaces the master service to provide service for the corresponding client.

7. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 1, wherein when the connection between the client and the server is not established, the main server fails, and the server is restarted immediately; the restarting of the server comprises: the health management module established in the AUTOSAR is provided with a watchdog module to monitor the server, and once the server process fails to start, a watchdog counter expires, the health management module is triggered to call the execution management module to restart the server process.

8. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 1, wherein when the server establishes connection with the client, for the asynchronous master server and slave server, if at least one slave server successfully establishes connection with the master server and the client, when the master server fails, the slave server processes the failure of the master server or the client processes the failure of the master server or the master service processes the failure of itself.

9. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 8, wherein when the master server performs the master phase and fails immediately after having sent the service providing message to the client, the slave server waits for the lifetime of the service providing message and does not receive the notification message from the master server, confirms that the master server fails and replaces the master service to provide the service to the client, and sends the notification message to notify the client of the service provision;

10. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 8, wherein when the master server performs the master phase and finds that the service providing function is failed after the message providing service has been sent to the client, the master server sends a service stopping message to the slave server and the client, and the slave server receives the message from the master service stopping service and replaces the master server to send a notification message to inform the client of the service providing function.

11. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 8, wherein when the master server performs the master phase and the client sends a service request to the master server and the slave server, the master server immediately fails after receiving the post-request and sending a response message to the slave server and the client, the client starts a timer set to a processing time duration associated with each request, and when the processing time duration exceeds and the response of the master server is not received, the client considers that the server has failed and notifies the slave server to replace the master server to provide the service.

12. The AUTOSAR-based service failure control method adopting a service-oriented architecture as claimed in claim 1, wherein the client-side initiated task logic generation method invoking the remote service comprises: the method comprises the steps that a client starts a task logic generation method calling request, simultaneously generates an identifier with a time label tc, sends the identifier to a client method processing module, adds deadline { tc, Dc } through the client method processing module, and sends the deadline { tc, Dc } to a server;

the server calls internal logic to generate service data corresponding to the method request, adds a Cf ═ tc, Dc, L, E time stamp corresponding to the method request, generates a time label of { ts, Cf } at the same time, adds the time stamp { ts + Ds, Cf } to the service method processing module, sends the time label to the client method processing module, judges the time label, and sends the service data to the client.

13. A service failure control method adopting a service-oriented architecture based on AUTOSAR is characterized in that a client starts a task logic generation method to call remote service, and comprises the following steps: the method comprises the steps that a client starts a task logic generation method calling request, simultaneously generates an identifier with a time label tc, sends the identifier to a client method processing module, adds deadline { tc, Dc } through the client method processing module, and sends the deadline { tc, Dc } to a server;

14. The method according to claim 13, wherein the client method processing module determines whether a preset deadline Dc is exceeded before sending the invocation request, and sends the invocation request if the preset deadline Dc is not exceeded, or does not send the invocation request otherwise.

15. The method according to claim 13, wherein the server parses the associated parameter and the timestamp { tc, Dc } of the method invocation request message through the service method processing module, and adds { tc, Dc, L, E } to the timestamp, and if the timestamp { tc, Dc, L, E } is within a preset time threshold range, then sends the associated parameter of the method invocation request to the server to invoke the internal logic to implement the service data corresponding to the method invocation request and add the Cf timestamp corresponding to the service request;

16. The AUTOSAR-based service failure control method adopting service-oriented architecture as claimed in claim 13, wherein the client method processing module determines whether the received service data is within a preset time threshold allowable range according to the { ts, Ds, L, E, Cf } tag, and if so, determines whether the corresponding time tag corresponds to the time tag at the time of the method invocation request, and if so, sends the service data to the client; the time tag is determined by analyzing { tc, Dc } from Cf, and determining whether { tc, Dc } matches with { tc, Dc } tag requested by the transmission method, if yes, the time tag corresponds to the { tc, Dc } tag, and if not, the time tag is discarded.