Subscription function recovery method, device and equipment, and computer medium

By generating and sending a second subscription request in the client, the connection interruption problem caused by the client based on the SOME/IP protocol due to receiving the subscription failure message is solved, and the reliability of vehicle data exchange is improved.

CN119946121APending Publication Date: 2025-05-06NEUSOFT REACH AUTOMOBILE TECH (SHENYANG) CO LTD
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202411888478.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-19
Publication Date
2025-05-06

AI Technical Summary

Technical Problem

In a vehicle, a client based on the SOME/IP protocol may occasionally receive event subscription failure messages sent by other ECUs, causing the client to be unable to receive event messages, affecting the reliability of vehicle data exchange.

Method used

When the client receives a subscription failure notification for the first subscription request for the target service feedback by the server, the event subscription function of the target service in the SOME/IP library is called, and a second subscription request is generated and sent to restore the connection and interaction with the server.

Benefits of technology

By automatically resending subscription requests, the client can restore connection and interaction with the server, improving the reliability of vehicle data exchange.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119946121A_ABST
    Figure CN119946121A_ABST
Patent Text Reader

Abstract

The invention discloses a subscription function recovery method, apparatus and device, and a computer medium, the method is suitable for a client in a first ECU, the first ECU is provided with the client, an SOME / IP library, and a first SOME / IP daemon process of the client, and the method comprises: when a subscription failure notification of a first subscription request for a target service fed back by a server is received, sending the first subscription request to the server; calling an event subscription function of the target service in the SOME / IP library, and generating a second subscription request for the target service; and sending the second subscription request to the server to subscribe the target service, thereby playing a role in improving the reliability of vehicle data exchange.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application belongs to the field of vehicle communication technology, and in particular, relates to a subscription function recovery method, device, equipment, and computer medium. Background Art

[0002] AUTOSAR AP (Adaptive Platform) middleware is widely used in vehicle-mounted ECU devices. The CM (Communication Management) module of AUTOSAR AP is used for communication between programs, so the CM module is widely used in AUTOSAR AP applications.

[0003] The communication protocols managed by the CM module include: SOME / IP protocol (Scalable service-oriented Middleware over IP), DDS protocol (Data Distribution Service), SHM protocol (shared memory communication), etc.

[0004] The SOME / IP protocol is an in-vehicle network communication protocol that is widely used for its efficient and flexible service communication. Currently, vehicles usually communicate between multiple ECUs, and the communication protocols within each ECU usually come from different middleware manufacturers, which affects the efficiency and reliability of data exchange. Event communication is the most widely used in SOME / IP, but in mass production experience, clients based on the SOME / IP protocol may occasionally receive event subscription failure messages mistakenly sent by other ECUs, which will cause the client to no longer receive event messages, affecting the reliability of vehicle data exchange. Summary of the invention

[0005] The embodiment of the present application provides an implementation solution different from the prior art to solve the technical problem of low reliability of vehicle data exchange.

[0006] In a first aspect, the present application provides a subscription function recovery method, which is applicable to a client in a first ECU, wherein the first ECU is provided with the client, a SOME / IP library, and a first SOME / IP daemon of the client, comprising: when a subscription failure notification of a first subscription request for a target service is received from a server, an event subscription function of the target service in the SOME / IP library is called to generate a second subscription request for the target service; and the second subscription request is sent to the server to subscribe to the target service.

[0007] In a second aspect, the present application provides a subscription function recovery method, which is applicable to a server in a second ECU, wherein the second ECU is provided with the server, a SOME / IP library, and a second SOME / IP daemon of the server, comprising: receiving a second subscription request for a target service sent by a client; based on the second subscription request, feeding back a subscription result of the second subscription request to the client; wherein the second subscription request is generated by calling an event subscription function of the target service in the SOME / IP library when the client receives a subscription failure notification of a first subscription request for the target service fed back by the server.

[0008] In a third aspect, the present application provides a subscription function recovery device, applicable to a client in a first ECU, wherein the first ECU is provided with the client, a SOME / IP library, and a first SOME / IP daemon process of the client, including:

[0009] A calling unit, configured to call an event subscription function of the target service in the SOME / IP library to generate a second subscription request for the target service when receiving a subscription failure notification of a first subscription request for the target service fed back by the server;

[0010] A sending unit is used to send the second subscription request to the server to subscribe to the target service.

[0011] In a fourth aspect, the present application provides an electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the first aspect, the second aspect, each possible implementation of the first aspect, and any method in each possible implementation of the second aspect by executing the executable instructions.

[0012] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the first aspect, the second aspect, each possible implementation method of the first aspect, and any method in each possible implementation method of the second aspect are implemented.

[0013] In a sixth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the first aspect, the second aspect, each possible implementation method of the first aspect, and any method described in each possible implementation method of the second aspect.

[0014] The subscription function recovery method provided by the present application is applicable to a client in a first ECU, wherein the client, the SOME / IP library, and the first SOME / IP daemon of the client are provided in the first ECU, and includes: when receiving a subscription failure notification of a first subscription request for a target service fed back by a server, calling an event subscription function of the target service in the SOME / IP library to generate a second subscription request for the target service; and sending the second subscription request to the server to subscribe to the target service. After the client receives a notification of event subscription failure, it can automatically resend the subscription request for the event, restore the connection and interaction with the server, and improve the reliability of vehicle data exchange. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0016] Figure 1 A structural diagram of a subscription function recovery system provided in an embodiment of the present application;

[0017] Figure 2a A flowchart of a subscription function recovery method provided in an embodiment of the present application;

[0018] Figure 2b A schematic diagram of the interaction between a client and a server provided in an embodiment of the present application;

[0019] Figure 3 A schematic diagram of the structure of a subscription function recovery device provided in an embodiment of the present application;

[0020] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, but cannot be understood as limiting the present application.

[0022] The terms "first" and "second" etc. in the specification, claims and drawings of the embodiments of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein, for example. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, the process, method, system, product or equipment comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0023] First, some terms in the embodiments of the present application are explained below to facilitate understanding by those skilled in the art.

[0024] AUTOSAR AP, the Adaptive Platform of Automotive Open System Architecture Application Programming Interface, is a software platform launched by AUTOSAR (Automotive Open System Architecture) that meets the needs of high performance and high flexibility.

[0025] AUTOSAR AP (Adaptive Platform) middleware is widely used in vehicle-mounted ECU devices. The AUTOSAR AP CM (Communication Management) module is used for communication between programs, so the CM module is widely used in AUTOSAR AP applications.

[0026] ECU (Electronic Control Unit) is the abbreviation of electronic control unit, also known as "driving computer", "on-board computer", etc. In terms of use, it is a microcomputer controller dedicated to automobiles. Like ordinary computers, it is composed of a microprocessor (CPU), memory (ROM, RAM), input / output interface (I / O), analog-to-digital converter (A / D), and large-scale integrated circuits such as shaping and driving.

[0027] The communication protocols managed by the CM module include: SOME / IP protocol (Scalable service-oriented Middleware over IP), DDS protocol (Data Distribution Service), SHM protocol (shared memory communication), etc.

[0028] ACK, the full name of which is Acknowledgment, is usually translated into Chinese as "confirmation response" or "response signal". It is a signal widely used in communication protocols. Its main function is to confirm to the sender of the message that the message has been successfully received. ACK signals play a key role in many communication technologies and protocols, such as TCP / IP protocol, wireless communication systems, and some specific application layer protocols.

[0029] NACK, the full name of which is Negative Acknowledgment, is translated into Chinese as "negative acknowledgment" or "non-confirmation acknowledgment". It is a signal in a communication protocol that is used to inform the sender of a message that the message it sent was not successfully received or there is an error. In contrast to ACK (confirmation acknowledgment), the NACK signal indicates that the receiver cannot confirm the correct receipt of the data.

[0030] A callback function is a term often used in programming, which refers to a function that is passed as a parameter to another function (usually called a "higher-level function" or "callee"). This mechanism allows the higher-level function to call the callback function at the appropriate time to implement a specific function or behavior. The specific implementation and purpose of the callback function depends on the context in which it is passed and called.

[0031] The SOME / IP (Scalable service-oriented MiddlewarE over IP) library is a collection of related functions, classes, and interfaces that support the implementation of the SOME / IP protocol. SOME / IP is an IP-based scalable middleware used for service communication in automotive electronic systems, supporting service discovery (SOME / IP-SD) and providing a service-oriented communication model.

[0032] The Offer function in SOME / IP (Scalable service-Oriented MiddlewarE over IP) usually refers to the process in which the server broadcasts or multicasts the services it provides to other nodes on the network (including clients) during the service discovery (SD) process. This process is implemented by sending OfferService messages so that clients can discover and connect to these services.

[0033] Subscription messaging is an information delivery mechanism in which the recipient of information (subscriber) expresses interest in a certain type of information in advance. When new information is generated and meets their interests, the system automatically sends this information to the subscriber. This mechanism is widely used in scenarios such as information distribution, event notification, and status update.

[0034] The SOME / IP protocol is an in-vehicle network communication protocol that is widely used for its efficient and flexible service communication. Currently, vehicles usually communicate between multiple ECUs, and the communication protocols within each ECU usually come from different middleware manufacturers, which affects the efficiency and reliability of data exchange. Event communication is the most widely used in SOME / IP, but in mass production experience, clients based on the SOME / IP protocol may occasionally receive event subscription failure messages mistakenly sent by other ECUs, which will cause the client to no longer receive event messages, affecting the reliability of vehicle data exchange.

[0035] In summary, in the vehicle mass production stage, adding an automatic subscription recovery function in the CM module when receiving an event subscription failure message has become a technical problem that needs to be solved urgently.

[0036] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0037] Figure 1 A structural diagram of a subscription function recovery system is provided for an exemplary embodiment of the present application, the system comprising: a first ECU and a second ECU, wherein the first ECU is provided with the client, the SOME / IP library, and the first SOME / IP daemon of the client; and the second ECU is provided with the server, the SOME / IP library, and the second SOME / IP daemon of the server.

[0038] In vehicle networks, the specific implementation and application scenarios of clients and servers in vehicle networks are unique. In vehicle networks, the client refers to the device or system that initiates a request or requires data. It can be the vehicle's ECU (electronic control unit), in-vehicle infotainment system, advanced driver assistance system (ADAS), or any other component that needs to interact with other devices or systems.

[0039] The main responsibilities of the client include: Initiating requests: The client sends requests to the server as needed. The requests may involve operations such as data acquisition, status query, and command execution. Receiving responses: The client receives the server's response to its request and processes or displays the data. Processing interactions: The client is responsible for handling the interaction logic with the server, including error handling, retry mechanisms, etc.

[0040] In the vehicle, the client may exist in many forms, such as a module that communicates with other ECUs via the CAN (Controller Area Network) bus, or an infotainment system that interacts with other systems via Ethernet / vehicle Ethernet.

[0041] The server refers to the device or system that provides data or services. In the vehicle network, the server is the ECU or other system component responsible for collecting, processing and storing data. They can respond to the client's request and provide the required data or service.

[0042] The main responsibilities of the server include: Providing services: The server provides corresponding data or services according to the client's request. These data or services may involve vehicle status, sensor data, control commands, etc. Processing requests: The server receives and processes requests from the client, which may involve operations such as data retrieval, calculation processing, and status update. Maintaining status: The server may need to maintain certain status information in order to respond to the client's request and provide accurate data or services.

[0043] In the vehicle, the server can be an ECU responsible for monitoring the vehicle status (such as an engine control unit, ABS control unit, etc.), or it can be a domain controller responsible for processing specific tasks (such as an autonomous driving domain controller, infotainment domain controller, etc.).

[0044] In vehicle networks, the interaction between clients and servers usually follows certain communication protocols and specifications. These protocols and specifications may vary depending on vehicle manufacturers and models, but they usually include provisions for message formats, communication methods, error handling, etc.

[0045] The execution principles and interaction processes of the various components in the embodiment of the system, such as the client and the server, can be found in the description of the following method embodiments.

[0046] Figure 2a A flowchart of a subscription function recovery method provided by an exemplary embodiment of the present application is provided. The method is applicable to a client in a first ECU. The first ECU is provided with the client, a SOME / IP library, and a first SOME / IP daemon of the client. The method includes at least the following steps S201-S202:

[0047] S201, when receiving a subscription failure notification of a first subscription request for a target service fed back by a server, calling an event subscription function of the target service in the SOME / IP library to generate a second subscription request for the target service;

[0048] In the related technology, when the client receives a subscription failure notification from the server for the first subscription request for the target service, the client will no longer receive messages related to the target service and stop interacting with the server regarding the target service. Through the aforementioned S201, the client can restore the client subscription function for the target service and continue to interact with the server regarding the target service.

[0049] Optionally, the target service may be a service or an event in a service.

[0050] In some optional embodiments of the present application, the services in the present application may include vehicle driving information services, intelligent driving information services, etc. Among them, the vehicle driving information services may include vehicle speed notification events, acceleration notification events, etc. Intelligent driving information services may include: lane departure notification events, anti-lock braking system start notification events, etc.

[0051] S202: Send the second subscription request to the server to subscribe to the target service.

[0052] In the solution of the present application, when the client receives a subscription failure notification for a first subscription request for a target service, the client can automatically send a second subscription request for the target service to the server again to restore communication with the server.

[0053] In some optional embodiments of the present application, the method further includes:

[0054] Register a target function related to the subscription of the target service in the SOME / IP library, wherein the target function includes: a receive message callback function for receiving messages related to the target service, and a subscription status change callback function of the target service, wherein the subscription status change callback function is used to notify the client through the SOME / IP library when the first SOME / IP daemon detects that the subscription status of the target service has changed.

[0055] When the subscription status of the target service changes from subscription success to subscription failure, or from subscription failure to subscription success, the subscription status of the target service is considered to have changed.

[0056] The step of registering the target function related to the subscription of the target service in the SOME / IP library is performed before the aforementioned step S201.

[0057] In some optional embodiments of the present application, the method further includes:

[0058] Upon receiving service notification information sent by the server, the step of registering a target function related to the subscription of the target service in the SOME / IP library is triggered, wherein the service notification information is used to notify the client of at least one service that the server can provide.

[0059] Optionally, after the server goes online, the server calls the offer function in the SOME / IP library in the second ECU to generate an offer message, and sends the offer message to the first SOME / IP daemon of the client through the network through the second SOME / IP daemon, and then the first SOME / IP daemon sends the offer message to the client. The offer message includes the aforementioned service notification information.

[0060] Optionally, the aforementioned target service may be one of the aforementioned at least one service.

[0061] Optionally, the target service may be an event in one of the at least one service mentioned above.

[0062] In some optional embodiments of the present application, the method further includes the following steps S01-S02:

[0063] S01. Sending the first subscription request to the server;

[0064] S02. Receive a subscription result from the server for the first subscription request, where the subscription result includes a subscription failure notification or a subscription success notification.

[0065] Specifically, the client needs to send the first subscription request to the server through the first SOME / IP daemon.

[0066] If the server provides the subscription service corresponding to the first subscription request, it will call the subscription feedback function in the SOME / IP library and reply ACK (event subscription success message) to the client.

[0067] If the server does not provide the subscription service corresponding to the first subscription request, it will call the subscription feedback function in the SOME / IP library and reply NACK (event subscription failure message) to the client.

[0068] Optionally, the server may also call the subscription feedback function in the SOME / IP library due to other reasons and reply NACK (event subscription failure message) to the client.

[0069] Among them, other reasons may be that the first ECU and the second ECU are not compatible.

[0070] Optionally, the second SOME / IP daemon process on the server side periodically sends offer messages to the first SOME / IP daemon process on the client side through the network. The first SOME / IP daemon process on the client side also automatically sends subscription requests for different services to the second SOME / IP daemon process.

[0071] In some optional embodiments of the present application, the method also includes: counting the number of subscription failure notifications received for the target service, and if the number is less than a preset threshold, triggering the execution of the event subscription function of calling the target service in the SOME / IP library to generate a second subscription request for the target service.

[0072] Specifically, after generating the second subscription request for the target service, it is also necessary to control the number of subscription failure notifications received for the target service to increase by 1.

[0073] In some optional embodiments of the present application, the method also includes: if the number of times is not less than the preset threshold, canceling the registration of the target function related to the subscription to the target service in the SOME / IP library, and calling the cancel event subscription function to cancel the subscription to the target service in the server.

[0074] Further, see Figure 2b As shown, Figure 2b A schematic diagram of the interaction between the client and the server provided for this application. Figure 2b 1: Offer() in the figure refers to the server calling the Offer function in the SOME / IP library. 1.1: Offer(), 1.1.1.1: Offer(), and 1.1.1.1.1: Offer() refer to the Offer messages of the nodes shown in the figure respectively. Figure 2bThe event receiving message callback function in the figure refers to the aforementioned receiving message callback function for receiving messages related to the target service; 4: Event subscription () refers to the client calling the event subscription function of the target service in the SOME / IP library; 4.1: Event subscription (), 4.1.1.1: Event subscription (), 4.1.1.1.1: Event subscription () refer to the first subscription request of each node in the figure. 5: Event subscription success ACK () refers to the server calling the function in the SOME / IP library for feedback of subscription success notification information, 5.1: Event subscription success ACK (), 5.1.1.1: Event subscription success ACK (), 5.1.1.1.1: Event subscription success ACK () refer to the subscription success notification of each node in the figure. The "loop [Guard]" in the figure refers to the aforementioned second SOME / IP daemon on the server side periodically sending offer messages to the first SOME / IP daemon on the client side through the network. The first SOME / IP daemon on the client side will also automatically send subscription requests for different services to the second SOME / IP daemon on the client side. 9: Event subscription failure NACK(), 9.1: Event subscription failure NACK(), 9.1.1: Event subscription failure NACK() refer to the aforementioned subscription failure notification. 9.1.1.4: Cancel event subscription() refers to calling the cancel event subscription function in the SOME / IP library, and 9.1.1.4.1: Cancel event subscription() refers to the notification of canceling event subscription. 9.1.1.5: Event subscription() refers to the client calling the event subscription function of the target service in the SOME / IP library to generate a second subscription request for the target service; 9.1.1.5.1: Event subscription() and 9.1.1.5.1.1: Event subscription() refer to the second subscription request for each node in the diagram. For other contents in the diagram, please refer to the aforementioned content and will not be repeated here.

[0075] The aforementioned method can be specifically implemented through the CM module in the client. The present application can add an automatic subscription function in the CM module to achieve the purpose of automatically issuing a subscription when receiving an abnormal event subscription failure message without causing loss of event data, thereby improving the reliability of vehicle data exchange.

[0076] The subscription function recovery method provided by the present application is applicable to a client in a first ECU, wherein the client, the SOME / IP library, and the first SOME / IP daemon process of the client are provided in the first ECU, and includes: when receiving a subscription failure notification of a first subscription request for a target service fed back by a server, calling an event subscription function of the target service in the SOME / IP library to generate a second subscription request for the target service; and sending the second subscription request to the server to subscribe to the target service. After the client receives the notification of event subscription failure, the subscription request can be automatically resent to restore the connection and interaction with the server, thereby improving the reliability of vehicle data exchange.

[0077] The client in the first ECU may be software or hardware, and this application does not limit this.

[0078] The present application also provides a subscription function recovery method, which is applicable to a server in a second ECU, wherein the second ECU is provided with the server, a SOME / IP library, and a second SOME / IP daemon process of the server, including:

[0079] receiving a second subscription request for the target service sent by the client;

[0080] Feedback a subscription result of the second subscription request to the client based on the second subscription request;

[0081] The second subscription request is generated by calling the event subscription function of the target service in the SOME / IP library when the client receives a subscription failure notification of the first subscription request for the target service fed back by the server.

[0082] The details related to this embodiment can be found in the above content and will not be repeated here.

[0083] Figure 3 A schematic diagram of a subscription function recovery device provided for an exemplary embodiment of the present application; wherein the device is applicable to a client in a first ECU, wherein the first ECU is provided with the client, a SOME / IP library, and a first SOME / IP daemon of the client, including:

[0084] The calling unit 31 is used to call the event subscription function of the target service in the SOME / IP library to generate a second subscription request for the target service when receiving a subscription failure notification of the first subscription request for the target service fed back by the server;

[0085] The sending unit 32 is used to send the second subscription request to the server to subscribe to the target service.

[0086] In some optional embodiments of the present application, the aforementioned device is also used for:

[0087] Register a target function related to the subscription of the target service in the SOME / IP library, wherein the target function includes: a receive message callback function for receiving messages related to the target service, and a subscription status change callback function of the target service, wherein the subscription status change callback function is used to notify the client through the SOME / IP library when the first SOME / IP daemon detects that the subscription status of the target service has changed.

[0088] In some optional embodiments of the present application, the aforementioned device is also used for:

[0089] When receiving the service notification information sent by the server, the step of registering the target function related to the subscription of the target service in the SOME / IP library is triggered, and the service notification information is used to notify the client of at least one service that the server can provide.

[0090] In some optional embodiments of the present application, the aforementioned device is also used for:

[0091] Sending the first subscription request to the server;

[0092] Receive a subscription result from the server for the first subscription request, where the subscription result includes a subscription failure notification or a subscription success notification.

[0093] In some optional embodiments of the present application, the aforementioned device is also used for:

[0094] The number of subscription failure notifications received for the target service is counted, and if the number is less than a preset threshold, the step of calling the event subscription function of the target service in the SOME / IP library and generating a second subscription request for the target service is triggered.

[0095] In some optional embodiments of the present application, the aforementioned device is also used for:

[0096] If the number is not less than the preset threshold, the registration of the target function related to the subscription of the target service in the SOME / IP library is cancelled, and the event subscription cancellation function is called to cancel the subscription to the target service in the server.

[0097] The present application also provides a subscription function recovery device, which is applicable to a server in a second ECU, wherein the second ECU is provided with the server, a SOME / IP library, and a second SOME / IP daemon process of the server, including:

[0098] A receiving unit, configured to receive a second subscription request for a target service sent by a client;

[0099] a feedback unit, configured to feed back a subscription result of the second subscription request to the client based on the second subscription request;

[0100] The second subscription request is generated by calling the event subscription function of the target service in the SOME / IP library when the client receives a subscription failure notification of the first subscription request for the target service fed back by the server.

[0101] It should be understood that the device embodiment and the method embodiment may correspond to each other, and similar descriptions may refer to the method embodiment. To avoid repetition, no further description is given here. Specifically, the device may perform the above method embodiment, and the above and other operations and / or functions of each module in the device are the corresponding processes in each method in the above method embodiment, respectively, and no further description is given here for the sake of brevity.

[0102] The above describes the device of the embodiment of the present application from the perspective of the functional module in conjunction with the accompanying drawings. It should be understood that the functional module can be implemented in hardware form, can be implemented by instructions in software form, and can also be implemented by a combination of hardware and software modules. Specifically, the steps of the method embodiment in the embodiment of the present application can be completed by the hardware integrated logic circuit and / or software form instructions in the processor, and the steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or a combination of hardware and software modules in the decoding processor to perform. Optionally, the software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory, and completes the steps in the above method embodiment in conjunction with its hardware.

[0103] Figure 4 is a schematic block diagram of an electronic device provided in an embodiment of the present application, and the electronic device may include:

[0104] The memory 301 and the processor 302, the memory 301 is used to store the computer program and transmit the program code to the processor 302. In other words, the processor 302 can call and run the computer program from the memory 301 to implement the method in the embodiment of the present application.

[0105] For example, the processor 302 may be configured to execute the above method embodiments according to instructions in the computer program.

[0106] In some embodiments of the present application, the processor 302 may include but is not limited to:

[0107] General-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc.

[0108] In some embodiments of the present application, the memory 301 includes but is not limited to:

[0109] Volatile memory and / or non-volatile memory. Among them, the non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus random access memory (DR RAM).

[0110] In some embodiments of the present application, the computer program may be divided into one or more modules, which are stored in the memory 301 and executed by the processor 302 to complete the method provided by the present application. The one or more modules may be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.

[0111] like Figure 4 As shown, the electronic device may also include:

[0112] The transceiver 303 may be connected to the processor 302 or the memory 301 .

[0113] The processor 302 may control the transceiver 303 to communicate with other devices, specifically, to send information or data to other devices, or to receive information or data sent by other devices. The transceiver 303 may include a transmitter and a receiver. The transceiver 303 may further include an antenna, and the number of antennas may be one or more.

[0114] It should be understood that the various components in the electronic device are connected via a bus system, wherein the bus system includes not only a data bus but also a power bus, a control bus and a status signal bus.

[0115] The present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a computer, the computer can perform the method of the above method embodiment. In other words, the present application embodiment also provides a computer program product containing instructions, and when the instructions are executed by a computer, the computer can perform the method of the above method embodiment.

[0116] When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a solid state drive (solid state disk, SSD)), etc.

[0117] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0118] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the module is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0119] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. For example, each functional module in each embodiment of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0120] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A subscription function recovery method, characterized in that: Applicable to a client in a first ECU, wherein the first ECU is provided with the client, a SOME / IP library, and a first SOME / IP daemon of the client, including: When receiving a subscription failure notification of a first subscription request for a target service fed back by the server, calling an event subscription function of the target service in the SOME / IP library to generate a second subscription request for the target service; The second subscription request is sent to the server to subscribe to the target service.

2. The method according to claim 1, characterized in that The method further comprises: Register a target function related to the subscription of the target service in the SOME / IP library, wherein the target function includes: a receive message callback function for receiving messages related to the target service, and a subscription status change callback function of the target service, wherein the subscription status change callback function is used to notify the client through the SOME / IP library when the first SOME / IP daemon detects that the subscription status of the target service has changed.

3. The method according to claim 2, characterized in that The method further comprises: Upon receiving service notification information sent by the server, the step of registering a target function related to the subscription of the target service in the SOME / IP library is triggered, wherein the service notification information is used to notify the client of at least one service that the server can provide.

4. The method according to claim 1, characterized in that: The method further comprises: Sending the first subscription request to the server; Receive a subscription result from the server for the first subscription request, where the subscription result includes a subscription failure notification or a subscription success notification.

5. The method according to claim 1, characterized in that: The method further comprises: The number of subscription failure notifications received for the target service is counted, and if the number is less than a preset threshold, the step of calling the event subscription function of the target service in the SOME / IP library and generating a second subscription request for the target service is triggered.

6. The method according to claim 5, characterized in that The method further comprises: If the number is not less than the preset threshold, the registration of the target function related to the subscription of the target service in the SOME / IP library is cancelled, and the event subscription cancellation function is called to cancel the subscription to the target service in the server.

7. A subscription function recovery method, characterized in that: Applicable to a server in a second ECU, wherein the second ECU is provided with the server, a SOME / IP library, and a second SOME / IP daemon of the server, including: receiving a second subscription request for the target service sent by the client; Feedback a subscription result of the second subscription request to the client based on the second subscription request; The second subscription request is generated by calling the event subscription function of the target service in the SOME / IP library when the client receives a subscription failure notification of the first subscription request for the target service fed back by the server.

8. A subscription function recovery device, characterized in that: Applicable to a client in a first ECU, wherein the first ECU is provided with the client, a SOME / IP library, and a first SOME / IP daemon of the client, including: A calling unit, configured to call an event subscription function of the target service in the SOME / IP library to generate a second subscription request for the target service when receiving a subscription failure notification of a first subscription request for the target service fed back by the server; A sending unit is used to send the second subscription request to the server to subscribe to the target service.

9. An electronic device, characterized in that: include: processor; as well as A memory, configured to store executable instructions of the processor; The processor is configured to perform the method of any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Citation Information

Cited By

  • Notification processing method and device, storage medium and program product

    CN120639837A