An interface calling method, a computer readable storage medium and a program product

Abstract

The application discloses an interface calling method, a computer readable storage medium and a program product. The method can include the following steps: a display module sends a function selection message to a diagnosis module; the diagnosis module sends a login request message to the display module; the display module obtains login data, logs in a server through the login data, and sends a login success response message to the diagnosis module if a login success message from the server is received; the diagnosis module sends a data acquisition request message to the display module; the display module obtains request parameters and interface field codes corresponding to a target function; a processing interface corresponding to the interface field codes is called, execution data is acquired from the server based on the request parameters, and a data acquisition response message is sent to the diagnosis module; the diagnosis module acquires the execution data, executes the target function based on the execution data, and obtains an execution result corresponding to the target function. Through the application, the efficiency of online flashing and online diagnosis operation can be improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an interface calling method, a computer-readable storage medium, and a program product. Background Technology

[0002] With the development of communication technology, the functions of smart devices are becoming increasingly complex and diverse. In the field of smart device functionality and maintenance, the need for online flashing and online diagnostics is becoming increasingly urgent. These two operations are crucial for ensuring the normal operation of smart devices, improving user experience, and enabling remote management and maintenance. The efficiency and stability of the backend interface calls directly affect the efficiency and user experience of online flashing and online diagnostics. How to correctly and efficiently call the backend interface during online flashing and online diagnostics is currently a hot research topic. Summary of the Invention

[0003] This application provides an interface calling method, a computer-readable storage medium, and a program product, which can improve the efficiency of online writing and online diagnostic operations.

[0004] Firstly, this application provides an interface calling method applied to an electronic device, the electronic device including a display module and a diagnostic module; the method includes: upon receiving a selection operation input to a function selection interface, the display module determines a target function based on the selection operation and sends a function selection message to the diagnostic module through a message transmission mechanism; the function selection message indicates the target function; the target function includes online flashing or online diagnostics of the electronic device; in response to the function selection message, the diagnostic module sends a login request message to the display module through a message transmission mechanism; the login request message indicates that the display module should log in to the server; in response to the login request message, the display module obtains login data through a data transmission mechanism, logs in to the server using the login data; and upon receiving a login success message from the server... In the event of a login success response message, the diagnostic module sends a login success response message to the diagnostic module via a message transmission mechanism. In response to the login success response message, the diagnostic module sends a data retrieval request message to the display module via the message transmission mechanism. The data retrieval request message instructs the display module to retrieve the execution data corresponding to the target function from the server. In response to the data retrieval request message, the display module retrieves the request parameters and interface field code corresponding to the target function via a data transmission mechanism. It then calls the processing interface corresponding to the interface field code, retrieves the execution data from the server based on the request parameters, and sends a data retrieval response message to the diagnostic module via the message transmission mechanism. In response to the data retrieval response message, the diagnostic module retrieves the execution data via a data transmission mechanism and executes the target function based on the execution data to obtain the execution result corresponding to the target function.

[0005] As can be seen, by separating the display and diagnostic modules and employing a dual-channel communication method combining message and data transmission mechanisms, modular execution of online flashing or online diagnostic functions is achieved. The decoupling design between modules reduces system coupling, allowing the display and diagnostic modules to be developed and upgraded independently, thus improving system maintainability and scalability. Simultaneously, the orderly process of function selection, login verification, data acquisition, and function execution ensures the security and reliability of the online flashing or diagnostic process, avoiding execution errors caused by chaotic data interaction and improving the stability and efficiency of online function execution in electronic devices.

[0006] In one possible implementation, the aforementioned interface field codes include functional interface field codes and auxiliary interface field codes, the aforementioned processing interfaces include functional execution interfaces and auxiliary interaction interfaces, and the processing interface corresponding to the aforementioned calling interface field code obtains execution data from the server based on request parameters and sends a data acquisition response message to the diagnostic module through a message transmission mechanism. This may include: calling the functional execution interface corresponding to the functional interface field code to obtain execution data from the server based on request parameters; calling the auxiliary interaction interface corresponding to the auxiliary interface field code to verify the execution data; and, if the execution data verification is successful, sending a data acquisition response message to the diagnostic module through a message transmission mechanism.

[0007] As can be seen, by subdividing the interface field codes into functional interface field codes and auxiliary interface field codes, and calling the corresponding functional execution interface and auxiliary interaction interface respectively, the separation of data acquisition and data verification is achieved. Each interface has a single responsibility, which facilitates code maintenance and error localization, further improving the stability and reliability of the system.

[0008] In one possible implementation, the above method may further include: the display module, after obtaining the functional interface field code and the auxiliary interface field code through the data transmission mechanism, saving the functional interface field code.

[0009] It is evident that saving the function interface field code facilitates repeated calls in subsequent processes. For example, when performing operations such as uploading execution results, it is not necessary to retrieve it from the server again, which reduces the number of network interactions, lowers communication latency, and improves processing efficiency.

[0010] In one possible implementation, the above method may further include: the diagnostic module sending a result upload message to the display module through a message transmission mechanism; the result upload message instructing the display module to upload the execution result to the server; in response to the result upload message, the display module obtains the execution result through a data transmission mechanism and calls the result upload interface corresponding to the function interface field code to upload the execution result to the server.

[0011] As can be seen, the diagnostic module focuses on function execution without needing to concern itself with the specific implementation details of result uploading, thus maintaining the single responsibility principle of the module; the display module efficiently completes the upload using the saved interface information, avoiding the extra overhead of repeatedly obtaining the interface code; at the same time, it uploads the execution results to the server in a timely manner, facilitating remote monitoring and data recording, providing data support for subsequent data analysis and problem tracing, and perfecting the closed-loop process of online diagnosis and online writing.

[0012] In one possible implementation, the login data includes a login interface field code and login parameters. The login to the server via the login data may include: calling the login interface corresponding to the login interface field code, and logging into the server based on the login parameters.

[0013] As can be seen, using the interface field code to dynamically call the login interface makes the login process highly flexible and configurable. When the server's login interface changes, only the interface field code needs to be updated to adapt, without modifying the underlying code of the display module, which reduces system maintenance costs and improves cross-version compatibility.

[0014] In one possible implementation, the above data transmission mechanism includes one or more of the following: pipe transmission mechanism, data copying message mechanism, and memory sharing mechanism.

[0015] As can be seen, the data transmission mechanism employs one or more technologies such as pipe transmission, data copying messages, and memory sharing, which can be flexibly selected according to the data volume and real-time requirements, thus realizing efficient data exchange between the display module and the diagnostic module.

[0016] In one possible implementation, the display module responds to the login request message by acquiring login data through a data transmission mechanism and then logging into the server using the login data. Upon receiving a login success message from the server, it sends a login success response message to the diagnostic module through a message transmission mechanism. This may include: the display module responding to the login request message by acquiring login status information; the login status information indicating whether the display module has logged into the server; if the login status information indicates that the display module has not logged into the server, it acquires login data through the data transmission mechanism and logs into the server using the login data; and upon receiving a login success message from the server, it sends a login success response message to the diagnostic module through a message transmission mechanism.

[0017] As can be seen, by introducing a login status information check mechanism, the current login status is first obtained and determined when the display module responds to the login request message. Only when it is confirmed that the user is not logged in will the complete login data retrieval and server login process be executed. This login status determination enables on-demand execution of the login process, supporting both the complete process for first-time logins and rapid responses for already logged-in users, thus enhancing the system's flexibility and adaptability to different scenarios.

[0018] In one possible implementation, the above method may further include: when the login status information indicates that the module has logged into the server, sending a login success response message to the diagnostic module through a message transmission mechanism.

[0019] As can be seen, when the login status information indicates that the module has logged into the server, a login success response message is sent directly to the diagnostic module via the message transmission mechanism, eliminating the need to repeatedly retrieve login data and perform server login operations. This significantly reduces unnecessary network interactions and data processing overhead, improving system response speed and resource utilization efficiency.

[0020] In a second aspect, embodiments of this application provide an electronic device, which includes: a memory for storing a program; and a processor for executing the program stored in the memory. When the program is executed by the processor, the processor executes a method as described in any possible implementation of the first aspect.

[0021] Thirdly, embodiments of this application provide a computer storage medium storing a computer program, the computer program including program instructions, and when the program instructions are executed by a processor, the processor performs the method as described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product, which includes: instructions or a computer program; when the instructions or the computer program are executed, the method in the first aspect and any possible implementation thereof is implemented.

[0023] Fifthly, embodiments of this application provide a chip including a processor configured to execute instructions, which, when executed, cause the chip to perform the methods described in the first aspect and any possible implementation thereof. Optionally, the chip further includes an input / output interface configured to receive or transmit signals. Attached Figure Description

[0024] Figure 1A schematic diagram of a system architecture provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 3 A flowchart illustrating an interface invocation method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will now be described with reference to the accompanying drawings.

[0026] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0027] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0028] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0029] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0030] First, some of the terms used in this application will be explained to facilitate understanding by those skilled in the art.

[0031] I. Online flashing Online flashing refers to the process by which electronic devices (such as automotive electronic control units (ECUs), smartphones, IoT terminals, industrial controllers, programmable logic devices, etc.) obtain updated firmware images, system software, applications, configuration files, calibration data, or low-level drivers directly through the network, without relying on traditional dedicated wired programmers, offline programmers, or physical disassembly of equipment, while maintaining a real-time communication connection with a remote server or host computer. This allows for the writing, overwriting, erasing, or updating of data in the device's internal programmable non-volatile memory (such as Flash memory, electrically erasable programmable read-only memory (EEPROM), ferroelectric random access memory (FRAM), etc.).

[0032] This process typically involves establishing communication protocols, verifying the integrity and security of data transmission (such as Cyclic Redundancy Check (CRC) and hash verification), identity authentication and access control, as well as rollback or recovery mechanisms after a failed flash, aiming to achieve iterative upgrades of device functions, performance optimization, vulnerability patching, or configuration changes.

[0033] II. Online Diagnosis Online diagnostics refers to the technical process by which a system or device establishes a continuous network communication connection with a remote diagnostic server, cloud service platform, or expert support center to achieve remote status monitoring, real-time fault detection, in-depth root cause analysis, performance health assessment, and predictive maintenance.

[0034] Online diagnostics breaks through the physical limitations of traditional diagnostic methods. It eliminates the need for diagnostic personnel to carry specialized diagnostic equipment to the site or to disassemble and send the equipment to a repair center. Instead, it allows for the remote initiation, execution, data collection, analysis, and feedback of diagnostic tasks via the network.

[0035] In practical applications of online flashing and online diagnostics, electronic devices often require frequent and complex data interactions between the user interaction module and the underlying diagnostic execution module. In related technologies, the interface call relationships between modules are chaotic, and the communication mechanisms are inconsistent, resulting in high system coupling, poor scalability, low development efficiency, and difficulty in adapting to changing business needs and complex network environments.

[0036] In view of this, this application provides an interface calling method. By designing a separate architecture for the display module and the diagnostic module, and establishing a communication method that combines a unified message transmission mechanism and a data transmission mechanism, orderly collaboration of each link in the online writing and online diagnostic process is realized.

[0037] The following describes a network architecture applicable to the embodiments of this application.

[0038] Please see Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application. Figure 1 As shown, the system architecture includes electronic device 110 and server 120.

[0039] Electronic device 110 may include, but is not limited to: smartphones, tablets, smart wearable devices, smart voice interaction devices, smart home appliances, personal computers, in-vehicle terminals, smart cameras, virtual reality devices (such as augmented reality (AR) devices), etc., and this application does not limit them.

[0040] Server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0041] Electronic device 110 and server 120 can exchange data via a network connection (such as a mobile communication network, wireless LAN, or Ethernet). When electronic device 110 needs to perform online flashing or online diagnostics, it can log in to server 120 and obtain the execution data corresponding to the online flashing or online diagnostic functions. Simultaneously, after electronic device 110 completes online flashing or online diagnostics and obtains the execution results, it can upload the results to server 120 for remote monitoring and data recording.

[0042] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 2 As shown, the electronic device includes a display module 210 and a diagnostic module 220.

[0043] The display module 210 and the diagnostic module 220 can be independent functional units deployed within the same electronic device. They interact with each other through inter-process communication mechanisms, such as a dual-channel communication method combining message transmission and data transmission mechanisms. The separate design of the display module 210 and the diagnostic module 220 decouples the user interaction layer from the business execution layer, allowing them to be developed, deployed, and upgraded independently, significantly improving the modularity and maintainability of the system.

[0044] The display module 210 is responsible for providing a user interface, receiving and responding to user input, and communicating with the remote server 120 via the network. The display module 210 may include a login interface message unit 211, a function execution message unit 212, and an execution result upload message unit 213.

[0045] The login interface message unit 211 is used to obtain login data through a data transmission mechanism after the display module 210 receives a login request message from the diagnostic module 220, and then log in to the server 120 using the login data. The function execution message unit 212 is used to obtain the request parameters and interface field code corresponding to the target function through a data transmission mechanism after the display module 210 receives a data acquisition request message from the diagnostic module 220, and then call the processing interface corresponding to the interface field code to obtain execution data from the server 120 based on the request parameters. The execution result upload message unit 213 is used to obtain the execution result through a data transmission mechanism after the display module 210 receives a result upload message from the diagnostic module 220, and then call the result upload interface corresponding to the previously saved function interface field code to upload the execution result to the server 120.

[0046] The diagnostic module 220 is responsible for receiving control commands from the display module 210, executing specific online flashing or online diagnostic functions, and returning the execution results. As the core of the electronic device's function execution, the diagnostic module 220 runs in an independent process space, isolated from the display module 210, effectively protecting the core algorithms and industry data related to diagnosis.

[0047] The following describes the interface calling method provided in the embodiments of this application.

[0048] Please see Figure 3 , Figure 3 This is a flowchart illustrating an interface invocation method provided in an embodiment of this application. Figure 3 As shown, the method for calling this interface may include, but is not limited to, the following steps: S301, when the display module receives a selection operation input on the function selection interface, it determines the target function based on the selection operation and sends a function selection message to the diagnostic module through a message transmission mechanism. Correspondingly, the diagnostic module receives the function selection message from the display module.

[0049] The display module is responsible for rendering and displaying the function selection interface. This interface serves as the entry point for users to interact with electronic devices and can be presented on the display screen of electronic devices through a graphical user interface (GUI), such as the central control display screen of a vehicle, the interactive interface of the instrument panel, the touch screen of a smart terminal, or a remote control panel.

[0050] The function selection interface includes at least one optional function item, which corresponds to the online service functions that the electronic device can perform, including at least online flashing and online diagnostic functions. The online flashing function item is used to trigger a remote upgrade process for the firmware or software of the electronic device, and the online diagnostic function item is used to trigger a remote detection and fault analysis process for the system status of the electronic device. The function selection interface may also include other auxiliary function items, such as function status query, historical record viewing, or system settings, etc., which are determined according to the actual application scenario, and this application embodiment does not impose any limitations on this.

[0051] Users can perform selection operations on the function selection interface through various input methods. Input methods include, but are not limited to: touch screen tapping or swiping, physical button pressing, knob rotation, voice command input, gesture recognition input, or operation of external input devices (such as mouse, keyboard).

[0052] When a user makes a selection, the input event listener registered by the display module captures the event, obtaining the location coordinates of the operation, the operation type (e.g., single click, double click, long press), and the corresponding UI element identifier. Based on the mapping between the UI element identifier or location coordinates and the function options, the display module parses the selected function and determines the target function to be executed. The target function may include online flashing or online diagnostics of the electronic device.

[0053] After the target function is determined, the display module generates a function selection message, which indicates the target function. This function selection message contains at least function type information to identify the target function, such as a function identifier (ID) or function code.

[0054] The display module can send the function selection message to the diagnostic module via a message transmission mechanism. This mechanism can be a message queue mechanism used in inter-process communication, enabling control signaling interaction between the display and diagnostic modules, and features low latency and high reliability. Correspondingly, the diagnostic module receives the function selection message from the display module, parses the message content to determine the type of target function to be executed.

[0055] S302, in response to the function selection message, the diagnostic module sends a login request message to the display module via a message transmission mechanism. Correspondingly, the display module receives the login request message from the diagnostic module.

[0056] In this embodiment, after receiving the function selection message, the diagnostic module parses and confirms that the target function is online flashing or online diagnostics. Further, the diagnostic module generates a login request message, which instructs the display module to log in to the server.

[0057] The login request message can be encapsulated using a predefined message format, including a request identifier and necessary context information. The diagnostic module sends this login request message to the display module via a message transmission mechanism. The specific implementation of the message transmission mechanism is consistent with the aforementioned step S301, ensuring the uniformity and reliability of control signaling transmission between modules. The diagnostic module can write the login request message to the sending buffer or message channel according to the interface specification of the message transmission mechanism and trigger the system to transmit the message. During message transmission, the diagnostic module can set a timeout threshold for message transmission as needed. If the message fails to be sent successfully within the specified time, the diagnostic module can retry, record the transmission failure log, and decide whether to terminate the process and report the error to the user based on the maximum number of retries.

[0058] Accordingly, the display module receives a login request message from the diagnostic module, parses it, and learns that a server login operation needs to be performed.

[0059] S303, the display module responds to the login request message and obtains login data through the data transmission mechanism.

[0060] In this embodiment, after receiving a login request message, the display module initiates a login data acquisition process. Login data is a set of credential information necessary for the display module to authenticate its identity with the server; its completeness and correctness directly determine the success or failure of subsequent login operations.

[0061] The display module retrieves login data from local storage or configuration files via a data transfer mechanism. This data transfer mechanism differs from the message transfer mechanism, focusing on the transmission of batch data and can employ one or more of the following: pipelining, data copying messaging, or shared memory mechanisms.

[0062] Among them, the pipe transfer mechanism is suitable for sequential reading and writing of streaming data; the data copy message mechanism is suitable for copying data from one process's address space to another; and the memory sharing mechanism allows two processes to directly access the same physical memory, achieving efficient data exchange with zero copying. By selecting an appropriate data transfer mechanism, the display module can efficiently acquire login data, improving the efficiency of online flashing or online diagnostics for electronic devices.

[0063] S304, the display module logs into the server using login data.

[0064] In this embodiment of the application, after obtaining login data, the display module can use this login data to establish a secure connection with the server and perform identity authentication, thereby logging into the server.

[0065] In one possible implementation, login data may include a login interface field code and login parameters. The login interface field code identifies which interface is called to perform the login operation, while the login parameters include authentication information such as username, password, device identifier, token, or encryption certificate.

[0066] After acquiring the login data, the display module parses the login interface field code and locates the corresponding login interface based on the code. It also extracts login parameters, such as username, password, or encrypted credentials. The display module calls the login interface, sending a login request to the server with the login parameters as input. Upon receiving the login request, the server verifies the login parameters, checking the validity of device permissions and user identity. During the login request transmission process, a secure transport layer protocol (such as Transport Layer Security (TLS) / Secure Sockets Layer (SSL)) can be used to encrypt the communication link to prevent the leakage of sensitive information.

[0067] In one possible implementation, after receiving a login request message from the diagnostic module, the display module can first obtain login status information and determine whether the display module is currently logged into the server based on the login status information, in order to avoid resource waste and user experience degradation caused by repeated logins. Login status information includes, but is not limited to: login status identifier, session credentials, credential acquisition time, and credential validity period. Specifically, the login status identifier indicates whether the user is currently logged in, and can take values ​​such as "not logged in," "logging in," "logged in," "login failed," or "session expired." Session credentials, such as access tokens, refresh tokens, session IDs, or cookies, are used to identify the user in subsequent requests. The credential acquisition time is used to calculate the duration the credential has been used. The credential validity period is obtained by parsing the expiration time (expires_in) or expiration timestamp returned by the server and is used to determine whether the credential is still valid.

[0068] If the display module is determined to be already logged into the server, it can skip the step of obtaining login data through the data transmission mechanism and then logging into the server using that data. If the display module is determined not to be logged into the server (including states such as "not logged in," "login failed," "session expired," or invalid credentials), it initiates the complete login process, obtains login data through the data transmission mechanism, and then logs into the server using that data.

[0069] S305, the server sends a login success message to the display module. Correspondingly, the display module receives the login success message from the server.

[0070] In this embodiment, after verifying the login data submitted by the display module and confirming the identity's legitimacy, the server generates a login success message and transmits it back to the display module via the communication network. The login success message may include session credentials, which can be a session ID maintained by the server, and subsequently carried by the electronic device to associate with the session; alternatively, the session credential can be an access token, which the electronic device must subsequently include in the request header for stateless authentication by the server. The login success message may also include session validity, server timestamp, or additional configuration information.

[0071] Correspondingly, the display module receives the login success message from the server through the communication network, parses and saves the session information therein for subsequent interaction with the server.

[0072] S306, the display module sends a login success response message to the diagnostic module via a message transmission mechanism. Correspondingly, the diagnostic module receives the login success response message from the display module.

[0073] In this embodiment, after receiving the login success message from the server, the display module confirms that the login process is complete and generates a login success response message to notify the diagnostic module that the login status is ready. The login success response message can be sent to the diagnostic module via a message transmission mechanism. The message content may include a login success status identifier, and, if necessary, a copy of the session identifier for the diagnostic module's reference. The specific implementation of the message transmission mechanism can be consistent with the aforementioned step S301 to ensure the uniformity and reliability of control signaling transmission between modules.

[0074] Accordingly, upon receiving the login success response message, the diagnostic module knows that the display module has successfully logged into the server and can continue executing the subsequent data acquisition process. This achieves state synchronization between the display module and the diagnostic module, ensuring that the diagnostic module initiates the next operation at the correct time and avoiding errors caused by the diagnostic module blindly requesting data while not logged in.

[0075] S307, in response to the login success message, the diagnostic module sends a data retrieval request message to the display module via a message transmission mechanism. Correspondingly, the display module receives the data retrieval request message from the diagnostic module.

[0076] In this embodiment of the application, after receiving the login success response message, the diagnostic module confirms that the display module has a legitimate identity to communicate with the server, and then starts the data acquisition process.

[0077] The diagnostic module generates a data acquisition request message, which instructs the display module to obtain the execution data required to perform the target function from the server, such as the firmware data package required for online flashing or the diagnostic task instructions required for online diagnostics. The data acquisition request message may contain identification information of the target function, as well as possible additional parameters (such as Vehicle Identification Number (VIN), hardware version number, etc.).

[0078] The diagnostic module sends the data acquisition request message to the display module via a message transmission mechanism. The specific implementation of the message transmission mechanism is consistent with step S301 above, ensuring the uniformity and reliability of control signaling transmission between modules. Correspondingly, the display module receives the data acquisition request message from the diagnostic module, parses it, and determines the specific data type and related parameters that need to be obtained from the server.

[0079] S308, the display module responds to the data acquisition request message and obtains the request parameters and interface field codes corresponding to the target function through the data transmission mechanism.

[0080] In this embodiment, after receiving a data acquisition request message, the display module parses the message content to determine the data type to be acquired. Subsequently, the display module obtains the request parameters and interface field codes required to execute the target function from local configuration, cache, or pre-stored files through a data transmission mechanism.

[0081] The choice of data transmission mechanism can be consistent with that in step S303 to ensure efficient data transmission. Request parameters are the query conditions or input parameters that need to be carried when requesting data from the server, such as firmware version number, diagnostic service identifier, and data range. The interface field code is used to identify which interface is called to obtain execution data.

[0082] S309, the display module calls the processing interface corresponding to the interface field code, and obtains execution data from the server based on the request parameters.

[0083] In this embodiment, after obtaining the request parameters and interface field code, the display module can locate the corresponding processing interface based on the interface field code. The processing interface can be a pre-registered Application Programming Interface (API) function or a network service endpoint. The display module calls the processing interface, taking the request parameters as input, and initiates a data request to the server. After receiving the request, the server filters or generates corresponding execution data based on the request parameters, such as firmware data blocks, diagnostic task scripts, or parameter configuration files, and returns this execution data to the display module.

[0084] During the data request process, the display module can carry the session credentials obtained from S305 to maintain the login status. The display module receives the execution data returned by the server and temporarily stores it in a local buffer.

[0085] In one possible implementation, the interface field code may include a functional interface field code and an auxiliary interface field code, and the processing interface may include a functional execution interface and an auxiliary interaction interface. The functional execution interface is the main interface for data acquisition, and the auxiliary interaction interface is the auxiliary interface for data verification.

[0086] The display module first calls the function execution interface corresponding to the function interface field code to obtain execution data from the server based on the request parameters. Then, it calls the auxiliary interaction interface corresponding to the auxiliary interface field code to verify the execution data, ensuring the integrity and correctness of the data. After successful verification, the display module continues with subsequent processes.

[0087] In one possible implementation, after the display module obtains the functional interface field code and the auxiliary interface field code through the data transmission mechanism, it can further perform a local saving operation on the functional interface field code. This saving operation aims to persistently store the functional interface field code in the non-volatile storage medium of the electronic device, so that it can be reused in subsequent stages of the current function execution process (such as the result upload stage) and other function execution scenarios. This avoids the communication overhead and processing delay caused by repeated acquisition, thereby optimizing system performance and improving user experience.

[0088] S310, the display module sends a data acquisition response message to the diagnostic module via a message transmission mechanism. Correspondingly, the diagnostic module receives the data acquisition response message from the display module.

[0089] In this embodiment of the application, after the display module successfully acquires the execution data and completes the verification, it generates a data acquisition response message to notify the diagnostic module that the data is ready.

[0090] Data acquisition response messages can be sent to the diagnostic module via a message transmission mechanism. The message content may include a status indicator indicating successful data acquisition, and, if necessary, a pointer or descriptive information about the data storage location (such as a handle to shared memory or a file path). The specific implementation of the message transmission mechanism is consistent with the aforementioned step S301, ensuring the uniformity and reliability of control signaling transmission between modules.

[0091] Correspondingly, after receiving the data acquisition response message, the diagnostic module knows that the execution data is available and can begin executing the target function. This achieves data preparation completion status synchronization, ensuring that the diagnostic module only starts function execution after the data is ready, avoiding execution failure due to missing data.

[0092] S311, the diagnostic module responds to the data acquisition response message, acquires the execution data through the data transmission mechanism, and executes the target function based on the execution data to obtain the execution result corresponding to the target function.

[0093] In this embodiment, after receiving the data acquisition response message, the diagnostic module parses the message content to determine the storage location or access method of the execution data. Subsequently, the diagnostic module reads the execution data from shared memory, pipes, or a specified file path through a data transmission mechanism. The choice of data transmission mechanism can be consistent with that in step S303 to ensure efficient data transfer.

[0094] After acquiring the execution data, the diagnostic module can perform corresponding operations based on the type of the target function. When the target function is online flashing, the diagnostic module can parse the firmware data in the execution data, write the firmware data to the specified storage area through the underlying driver interface, and perform operations such as erasure, programming, and verification. When the target function is online diagnostics, the diagnostic module can parse the diagnostic task instructions in the execution data, call the corresponding diagnostic service functions, collect fault codes, read data streams, or perform action tests to generate diagnostic results.

[0095] During execution, the diagnostic module can monitor the execution status in real time and record execution logs. After execution is complete, the diagnostic module obtains the execution result corresponding to the target function. This execution result can be temporarily stored locally for later reporting to the server or displaying to the user.

[0096] For the target function of online flashing, the execution results may include the flashing operation status code (e.g., success, failure, partial success), flashing time, flashing data volume, verification results, error codes and descriptions upon failure, and prompts indicating the need for rollback. For the target function of online diagnostics, the execution results may include the list of fault codes read and their status, the collected data stream values, the execution feedback of the action test, the end status of the diagnostic session, and a summary or complete data of the generated diagnostic report.

[0097] In one possible implementation, after the diagnostic module obtains the execution result corresponding to the target function, the execution result can be reported to the server to achieve remote data synchronization, status recording, and subsequent analysis.

[0098] The diagnostic module can send a result upload message to the display module via a message transmission mechanism. This message instructs the display module to upload the execution result to the server. The specific implementation of the message transmission mechanism is consistent with the aforementioned step S301, ensuring the uniformity and reliability of control signaling transmission between modules.

[0099] The display module responds to the result upload message by obtaining the execution result through the data transmission mechanism. The choice of data transmission mechanism can be consistent with that in step S303 to ensure efficient data transfer. Simultaneously, it calls the result upload interface corresponding to the previously saved function interface field code to upload the execution result to the server.

[0100] As can be seen, the interface calling method provided in this application embodiment achieves clear separation and efficient collaboration between the display module and the diagnostic module, significantly improving the structure and maintainability of the system architecture, while effectively ensuring the security of core data in the diagnostic module, providing strong support for the isolation and protection of industry data.

[0101] This application also provides a computer device; please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application.

[0102] like Figure 4 As shown, the computer device 400 may include one or more processors 410, one or more memories 430, one or more communication interfaces 420, and a bus 440, wherein the processors 410, memories 430, and communication interfaces 420 are connected via the bus 440.

[0103] The memory 430 is used to store a program; the processor 410 is used to execute the program stored in the memory. When the program is executed, the processor 410 executes the method in any of the possible implementations of the interface call method described above.

[0104] It should be understood that, in the embodiments of this application, the memory 430 mentioned above includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CDROM), as well as external memory other than computer memory and processor cache. A portion of the memory 430 may also include non-volatile random access memory.

[0105] The processor 410 described above can be one or more Central Processing Units (CPUs). If the processor 410 is a CPU, it can be a single-core CPU or a multi-core CPU. The processor 410 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0106] The steps performed in the foregoing embodiments can be based on the above. Figure 4The computer device 400 shown is implemented such that the processor 410 can execute any of the optional embodiments of the interface calling method provided in this application. The memory 430 can provide a cache when the processor 410 executes any of the optional embodiments of the interface calling method provided in this application, and can also store the computer programs required by the processor 410 to execute any of the optional embodiments of the interface calling method provided in this application.

[0107] This application also provides a computer storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, enable the processor to implement the above-mentioned functions. Figure 3 The method shown.

[0108] This application also provides a computer program product, which includes: instructions or a computer program; when the instructions or the computer program are executed, the above-mentioned functions can be achieved. Figure 3 The method shown.

[0109] This application also provides a chip, which includes a processor. The processor executes instructions, enabling the chip to achieve the aforementioned... Figure 3 The method shown.

[0110] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by hardware related to computer programs. The computer programs can be stored in computer storage media, and when executed, they can implement the processes of the above method embodiments. The aforementioned computer storage media include various media capable of storing computer program code, such as read-only memory (ROM) or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. An interface invocation method, characterized in that, The method is applied to an electronic device, the electronic device including a display module and a diagnostic module; the method includes: Upon receiving a selection operation input to the function selection interface, the display module determines the target function based on the selection operation and sends a function selection message to the diagnostic module via a message transmission mechanism. The function selection message indicates the target function, which includes performing online flashing or online diagnostics on the electronic device. In response to the function selection message, the diagnostic module sends a login request message to the display module through the message transmission mechanism; the login request message is used to instruct the display module to log in to the server. In response to the login request message, the display module obtains login data through a data transmission mechanism and logs into the server using the login data; and upon receiving a login success message from the server, it sends a login success response message to the diagnostic module through the message transmission mechanism. In response to the login success response message, the diagnostic module sends a data retrieval request message to the display module through the message transmission mechanism; the data retrieval request message is used to instruct the display module to retrieve the execution data corresponding to the target function from the server; In response to the data acquisition request message, the display module acquires the request parameters and interface field code corresponding to the target function through the data transmission mechanism; calls the processing interface corresponding to the interface field code, acquires the execution data from the server based on the request parameters, and sends a data acquisition response message to the diagnostic module through the message transmission mechanism. The diagnostic module responds to the data acquisition response message, acquires the execution data through the data transmission mechanism, and executes the target function based on the execution data to obtain the execution result corresponding to the target function.

2. The method as described in claim 1, characterized in that, The interface field code includes a functional interface field code and an auxiliary interface field code. The processing interface includes a functional execution interface and an auxiliary interaction interface. Calling the processing interface corresponding to the interface field code retrieves the execution data from the server based on the request parameters and sends a data retrieval response message to the diagnostic module through the message transmission mechanism, including: Call the function execution interface corresponding to the function interface field code, and obtain the execution data from the server based on the request parameters; Call the auxiliary interaction interface corresponding to the auxiliary interface field code to verify the execution data; If the execution data verification passes, a data acquisition response message is sent to the diagnostic module through the message transmission mechanism.

3. The method as described in claim 2, characterized in that, The method further includes: When the display module obtains the functional interface field code and the auxiliary interface field code through the data transmission mechanism, it saves the functional interface field code.

4. The method as described in claim 3, characterized in that, The method further includes: The diagnostic module sends a result upload message to the display module through the message transmission mechanism; the result upload message is used to instruct the display module to upload the execution result to the server; In response to the result upload message, the display module obtains the execution result through the data transmission mechanism and calls the result upload interface corresponding to the function interface field code to upload the execution result to the server.

5. The method as described in claim 1, characterized in that, The login data includes a login interface field code and login parameters. Logging into the server using the login data includes: Call the login interface corresponding to the login interface field code, and log in to the server based on the login parameters.

6. The method according to any one of claims 1-5, characterized in that, The data transmission mechanism includes one or more of the following: pipe transmission mechanism, data copy message mechanism, and memory sharing mechanism.

7. The method as described in claim 1, characterized in that, The display module responds to the login request message by acquiring login data through a data transmission mechanism and logging into the server using the login data; and upon receiving a login success message from the server, it sends a login success response message to the diagnostic module through the message transmission mechanism, including: The display module responds to the login request message and obtains login status information; the login status information is used to indicate whether the display module has logged into the server; If the login status information indicates that the display module is not logged into the server, the system obtains login data through a data transmission mechanism and logs into the server using the login data; and upon receiving a login success message from the server, the system sends a login success response message to the diagnostic module through the message transmission mechanism.

8. The method as described in claim 7, characterized in that, The method further includes: When the login status information indicates that the display module has logged into the server, a login success response message is sent to the diagnostic module through the message transmission mechanism.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-8.

10. A computer program product containing instructions, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-8.

Images