A software diagnostic system loading method and its system, device and storage medium

Abstract

The present application discloses a software diagnostic system loading method and its system, device, and storage medium. The software diagnostic system loading method includes: obtaining a command for loading a dynamic second-line diagnostic algorithm module received by a processing service module, wherein the command includes house number information and address information of the dynamic second-line diagnostic algorithm module; checking whether there is received data in the connection established with the occurrence domain or other processing domain through the startup thread of the processing service module; if so, copying the received data through the processing thread through the message mechanism; calling the collection forwarder to check whether there is a message to copy the data; if so, calling the dynamic second-line diagnostic algorithm module corresponding to the address information of the second-line diagnostic device based on the house number information to perform a secondary diagnosis on the data. Through the above method, the present application supports dynamic loading of the second-line diagnostic algorithm module, which can be used on demand to solve the usage problem in an environment with tight memory.

Description

Technical Field

[0001] The present application relates to the field of computer application technology, and in particular to a software diagnostic system loading method and its system, device, and storage medium. Background Art

[0002] When the software program code is completed, the software must be diagnosed, which is to test whether the results of the program execution meet the original design requirements. At this time, the software designer must determine whether the input and output data of each individual functional mode meet the original requirements. In addition, the overall performance of the system must also be tested. Even if the function meets the requirements, if the execution speed is very slow, the software will not meet the needs of the user.

[0003] The current diagnostic system for software activities adopts a typical separation structure of "collection" and "analysis", that is, independent collection and independent analysis, and the collection adopts the "complete" mode, and the analysis adopts the "offline" mode. The existing processing domain responsible for "analysis" has the following problems: In embedded devices, for some environments with tight memory, if all static STAs are loaded into the processing domain as soon as it is started, it may cause the process startup to fail and function abnormally. Summary of the invention

[0004] The present application provides a software diagnostic system loading method and its system, device, and storage medium.

[0005] A technical solution provided by the present application is: to provide a software diagnosis system loading method, the software diagnosis system loading method is applied to a processing domain in a system software diagnosis system, the processing domain includes a collection forwarder, a second-line diagnosis algorithm module, a second-line diagnostic device and a processing service module, wherein the collection forwarder is connected to the second-line diagnostic device and the processing service module respectively, the second-line diagnosis algorithm module is connected to the second-line diagnostic device, and the second-line diagnosis algorithm module includes a dynamic second-line diagnosis algorithm module and a static second-line diagnosis algorithm module;

[0006] The software diagnostic system loading method comprises:

[0007] Obtaining a command received by the processing service module for loading the dynamic second-line diagnostic algorithm module, wherein the command includes house number information and address information of the dynamic second-line diagnostic algorithm module;

[0008] Checking, through the startup thread of the processing service module, whether there is received data in the connection established with the occurrence domain or other processing domains;

[0009] If so, the received data is copied through the processing thread via the message mechanism;

[0010] Calling the collective forwarder to check whether there is a message of copying data;

[0011] If so, the second-line diagnostic device is called based on the house number information to load the dynamic second-line diagnostic algorithm module corresponding to the address information to perform a secondary diagnosis on the data.

[0012] Another technical solution provided by the present application is to provide a system software diagnostic system, the system software diagnostic system comprising:

[0013] at least one occurrence domain, for recording events triggered by the software activity and performing a diagnosis on the events;

[0014] Information database;

[0015] At least one processing domain is connected to the occurrence domain and the information database, and is used for performing secondary diagnosis on the events of the occurrence domain, and storing the events and secondary diagnosis results in the information database.

[0016] Another technical solution provided by the present application is: to provide a terminal device, the terminal device includes a processor and a memory, the memory stores a computer program, and the processor is used to execute the computer program to implement the steps of the above-mentioned software diagnostic system loading method.

[0017] Another technical solution adopted by the present application is: providing a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed, the steps of the above-mentioned software diagnostic system loading method are implemented.

[0018] Different from the prior art, the beneficial effects of the present application are as follows: the processing domain obtains the command received by the processing service module to load the dynamic second-line diagnostic algorithm module, wherein the command includes the house number information and the address information of the dynamic second-line diagnostic algorithm module; the startup thread of the processing service module checks whether there is received data in the connection established with the occurrence domain or other processing domains; if so, the received data is copied through the processing thread through the message mechanism; the collection forwarder is called to check whether there is a message to copy the data; if so, the dynamic second-line diagnostic algorithm module corresponding to the address information of the second-line diagnostic device is called based on the house number information to perform a secondary diagnosis on the data. Through the above method, the present application supports dynamic loading of the second-line diagnostic algorithm module and uses it on demand, solving the usage problem in an environment with tight memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0020] Figure 1 It is a structural diagram of an embodiment of a system software diagnostic system provided by the present application;

[0021] Figure 2 is a structural diagram of another embodiment of the system software diagnostic system provided by the present application;

[0022] Figure 3 It is a structural diagram of an embodiment of a processing domain provided by the present application;

[0023] Figure 4 It is a structural diagram of another embodiment of the system software diagnostic system provided by the present application;

[0024] Figure 5 It is a connection diagram of the occurrence domain and the processing domain provided by this application;

[0025] Figure 6 It is a flowchart of an embodiment of a method for starting a software diagnostic system provided by the present application;

[0026] Figure 7 It is a logical system diagram of the occurrence domain startup provided by this application;

[0027] Figure 8 It is a logical system diagram of the startup of the service module provided by this application;

[0028] Fig. 9 It is a logical system diagram for starting the information block generator provided by this application;

[0029] Fig.10 It is a flowchart of another embodiment of the method for starting a software diagnostic system provided by the present application;

[0030] Fig.11 It is a system schematic diagram of a memory leak embodiment provided by the present application;

[0031] Fig.12 It is a flowchart of an embodiment of a method for loading a software diagnostic system provided by the present application;

[0032] Fig.13 is a structural schematic diagram of another embodiment of the processing domain provided by the present application;

[0033] Fig.14 It is a logical system diagram of the processing domain work provided by this application;

[0034] Fig.15 It is a logical system diagram of the processing domain startup provided by this application;

[0035] Fig.16 It is a structural diagram of an embodiment of a terminal device provided by the present application;

[0036] Fig.17 It is a structural schematic diagram of an embodiment of a computer-readable storage medium provided by the present application. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0038] See also Figure 1 , Figure 1 It is a structural diagram of an embodiment of a system software diagnostic system provided by the present application.

[0039] The system software diagnosis system 100 of the embodiment of the present disclosure includes at least one occurrence domain 11 (DMO=DomainOccur), wherein the occurrence domain 11 here can exist in the form of an independent process, that is, the entire terminal device only needs one occurrence domain 11 to complete the diagnosis of software activities.

[0040] Specifically, the occurrence domain 11 is the place where the event or record occurs and is first captured. The occurrence domain 11 can be the place where the event or record first triggers the action, and the triggering of all actions in the occurrence domain 11 can be in the form of function calls. Therefore, the occurrence domain 11 can complete the diagnosis of software activities by taking the shortest path, the fastest and the most effective processing means.

[0041] The occurrence domain 11 of the present application is classified according to the type of collected information, such as call tracking, ProcFS information collection, and NetStat statistics, etc. The staff can design multiple varieties of occurrence domains 11 suitable for different information collection and generation according to different needs.

[0042] The existence of the occurrence domain 11 can be based on the process as a unit, and one or more occurrence domain 11 instances can be generated in each process according to the needs, wherein the same occurrence domain 11 can only exist in one instance in a certain process. For example, the diagnosis of function call tracing needs to collect the information of each function entry and exit, so each process needs to call the instance of the tracing class occurrence domain 11, that is, the same type of occurrence domain 11 has multiple instances in multiple processes.

[0043] In addition, the occurrence domain 11 can also exist in the form of an independent process. For example, the occurrence domain 11 for collecting kernel events only needs one instance in the entire software system. When this occurrence domain 11 is needed for collection, it is only necessary to find the instance of the process where the occurrence domain 11 is located.

[0044] The occurrence domain 11 of the embodiment of the present disclosure is applicable to multiple instances of the same type in multiple processes, independent collection and aggregation, and is also applicable to on-demand collection of the entire system, collecting and sharing information in independent processes.

[0045] Specifically, the occurrence domain 11 of the embodiment of the present disclosure further includes an event processing source 111 , an information block generator 112 , a first-line diagnostician 114 , a first-line capturer 113 and an occurrence service module 115 .

[0046] Among them, the event processing source (ARES, Activity Record / Event Source) 111 is used to record and process the event source of software activities. The event processing source 111 is the core of the occurrence domain 11, providing the runtime context of the occurrence domain 11, and only providing a unique context to ensure that the design and implementation of the occurrence domain 11 adopts a single-threaded mode.

[0047] On the one hand, the context here acts as a timer of the information block generator 112, and periodically calls the timer function of the information block generator 112. Specifically, the information collected and generated by the information block generator 112 is first sent to the event processing source 111, which is then transmitted to the first-line capturer 113 for processing, and finally the first-line capturer 113 sends the information to the first-line diagnostic device 114 for diagnosis processing one by one. On the other hand, the context here provides a timer for the generation service module 115, which is used to periodically check the commands sent from the downstream.

[0048] In addition, when the first-line capturer 113 and the first-line diagnostician 114 process information, they will also generate a report on the processed information. The report is generated in the middle of the processing and cached at the event processing source 111. The event processing source 111 ultimately maintains the time sequence of the information and the report, and pushes it to the subscribed downstream through the occurrence service module 115.

[0049] The information block generator (GEN) 112 is connected to the event processing source 111 and is used to generate a record information block or an event information block, and send the record information block or the event information block to the event processing source.

[0050] The information block generator 112 can complete the collection and generation of non-standardized information and format it into an internal unified data format. The information block generator 112 relies on the timer provided by the event processing source 111 as a context.

[0051] Among them, the first-tier catcher (FTC) 113 connects the event processing source 111 and the first-tier diagnostic device 114, and is used to realize the information docking between the event processing source 111 and the first-tier diagnostic device 114, and to filter the record information block or event information block and / or diagnostic report.

[0052] The first-line catcher 113 can realize the information connection between the event processing source 111 and the first-line diagnoser 114, and realize the unified management of the first-line diagnoser 114. The first-line catcher 113 is used as a filter before the first-line diagnoser 114 processes information, and is also used as a filter before the first-line diagnoser 114 generates a report output.

[0053] The first-tier algorithm / action (FTA) 114 is used to diagnose the record information block or the event information block, and to generate a diagnosis report based on the diagnosis result.

[0054] First-line diagnostics 114 is the place where diagnostic algorithms are implemented in the occurrence domain 11. First-line diagnostics 114 is specially designed to implement only simple and urgent diagnostic algorithms. The input of first-line diagnostics 114 comes from the information filtered by the first-line capturer 113. The output of first-line diagnostics 114 can be a report, which is continuously returned to the occurrence domain 11 and flows downstream. It can also take private diagnostic actions of first-line diagnostics 114, that is, micro and necessary actions.

[0055] Among them, the occurrence service module (Service) 115, as a service provided by the entire occurrence domain 11 to the downstream, is connected to the event processing source and is used to provide the information block and / or diagnosis report of the event processing source to the downstream.

[0056] In the disclosed embodiment, the system software diagnosis system includes: at least one occurrence domain, which is used to record events triggered by software activities and diagnose the events once; the occurrence domain includes: an event processing source, which is used to record and process the event source of software activities; an information block generator, connected to the event processing source, which is used to generate a record information block or an event information block, and send the record information block or the event information block to the event processing source; a first-line diagnostic device, which is used to diagnose the record information block or the event information block, and generate a diagnostic report based on the diagnostic result; a first-line capturer, which is connected to the event processing source and the first-line diagnostic device, which is used to realize information docking between the event processing source and the first-line diagnostic device, and to filter the record information block or the event information block and / or the diagnostic report. Through the above method, the present application can realize dynamic collection and real-time diagnosis by providing a system software diagnosis system.

[0057] Based on the above system software diagnostic system embodiment, this application also provides another software diagnostic system. Figure 2 , Figure 2 It is a structural diagram of another embodiment of the software diagnostic system provided by the present application.

[0058] The system software diagnosis system 200 of the embodiment of the present disclosure includes an occurrence domain 21, a processing domain 22 and an information database 23. Among them, at least one processing domain 22 is connected to the occurrence domain 21 and the information database 23, and is used to perform secondary diagnosis on the events of the occurrence domain 21, and store the events and secondary diagnosis results in the information database 23.

[0059] Specifically, the processing domain 22 is used as a place for event information or record information collection, forwarding, secondary diagnosis, and secondary action. Compared with the occurrence domain 21, the event information or record information in the processing domain 22 has already incurred a delay, so it is not suitable for intervention actions that require real-time performance; however, the processing domain 22 has been separated from the context of the occurrence domain 21, and more complex diagnostic processing can be performed in the processing domain 22. The event information or record information in the processing domain 22 is collected to generate Set[InfoEvt, InfoRec], which is suitable for batch operations to improve the efficiency of forwarding and processing. The processing domain 22 can achieve cascading of the processing domain 22 by cascading the collection forwarders.

[0060] It should be noted that one occurrence domain 21 can only be connected to one processing domain 22, and one processing domain 22 can be connected to multiple occurrence domains 21; processing domains 22 can be cascaded, and one processing domain 22 can only be connected to one processing domain 22. In addition, in some special cases, the occurrence domain 21 can also exist alone.

[0061] Please continue to refer to the specific structure of processing domain 22 Figure 3 , Figure 3Schematic diagram of the structure of a processing domain embodiment provided by the present application. Figure 3 As shown, the processing domain 22 of the embodiment of the present disclosure specifically includes a collection forwarder 221 , a second-line diagnostic device 222 , a second-line diagnostic algorithm module 223 and a processing service module 224 .

[0062] The Info-Command-Router (ICR) 221 is used to receive events from the upstream occurrence domain 21 or commands from the downstream processing domain 22. The functions of the Info-Command-Router 221 in the embodiment of the present disclosure include but are not limited to:

[0063] (1) As the core of the processing domain 22, the basic processing domain 22 only needs to be provided with a runtime context by the collection forwarder 221.

[0064] (2) The generation domain 21 or processing domain 22 connected to the upstream can be connected to multiple upstreams.

[0065] (3) Receive information from upstream and forward it to the second-line diagnostic device 222 for local diagnostic algorithm.

[0066] (4) Receive commands from downstream and decide whether to forward them to a local object or to the upstream DMx.

[0067] (5) Ensure the time sequence between the upstream information and the report in the second-line diagnostic algorithm module 223, and push it to the downstream.

[0068] Among them, the second-tier diagnostician (STD: Second-Tier Diagnostician) 222 is connected to the collective forwarder 221 and the second-tier diagnostic algorithm module 223, and is used to realize the information docking between the collective forwarder 221 and the second-tier diagnostic algorithm module 223, and to integrate the diagnostic reports of all second-tier diagnostic algorithm modules 223 to perform comprehensive diagnosis.

[0069] Specifically, the second-line diagnostic device 222 serves as an information collection and filtering unit before the second-line diagnostic algorithm module 223 in the processing domain 22 , and can implement a comprehensive diagnostic algorithm for the incoming information and the report generated by the second-line diagnostic algorithm module 223 .

[0070] The second-tier diagnosis algorithm module (STA: Second-Tier Algorithm) 223 is used to diagnose the events received by the collective forwarder 221 and generate a diagnosis report based on the diagnosis results.

[0071] Specifically, the second-line diagnostic algorithm module 223 is used as the diagnostic algorithm implementation of the processing domain 22. The second-line diagnostic algorithm module 223 can design and implement a complex diagnostic algorithm based on the information transmitted by the second-line diagnostic device 222. The diagnostic structure of the second-line diagnostic algorithm module 223 can be transmitted to the second-line diagnostic device 222 in the form of a report, and the second-line diagnostic device 222 integrates the reports of all the second-line diagnostic algorithm modules 223 to perform a comprehensive diagnosis.

[0072] Among them, the processing service module 224 is connected to the collective forwarder 221, and is used to store the events or diagnostic reports of the collective forwarder 221 in the information database 23, or forward the commands of the collective forwarder 221 to the downstream processing domain 22.

[0073] Combine the following Figure 4 Further describing the cascade logic of the system software diagnostic system 200, Figure 4 200 is a schematic diagram of the structure of another embodiment of the system software diagnosis system provided by the present application. The cascade logic rules of the system software diagnosis system 200 are summarized as follows:

[0074] (1) One generation domain 21 can only connect to one processing domain 22 at most.

[0075] (2) In special cases, the occurrence domain 21 can exist alone.

[0076] (3) A processing domain 22 can access multiple generation domains 21.

[0077] (4) The processing domains 22 can be cascaded.

[0078] (5) A processing domain 22 can only connect to one processing domain 22 at most.

[0079] Specifically, the occurrence domain 21 and the processing domain 22, and the processing domains 22 and 22 are connected by a service module, namely, Service. The upstream of Service is Publisher, referred to as SrvPub, and the downstream of Service is Subscriber, referred to as SrvSub.

[0080] The connection between the occurrence domain 21 and the processing domain 22 can be found in Figure 5 , Figure 5 It is a connection diagram between the occurrence domain and the processing domain provided by this application.

[0081] like Figure 5 As shown, each SrvPub can only receive one SrvSub at most, and SrvSub can subscribe only when SrvPub is idle, that is, it cannot preempt an existing subscription. This application ensures that the cascading function will not become the source of new problems through this connection rule.

[0082] Specifically, DMZ connects to the publisher and starts subscription by calling the Connect method of SrvSub. If SrvPub already has SrvSub in place, the subscription fails (Busy). When connecting to SrvPub, it is necessary to provide the protocol parameters that match the SrvPub publishing start. DMZ subscribes to the DMx publication successfully and generates a "publish-subscribe session (SrvPub-SrvSub-Dialog)", which contains the "information block channel (InfoChannel)" and the "command channel (CommandChannel)".

[0083] Among them, InfoChannel is a unidirectional simplex mode, only DMx actively pushes information blocks to DMz, and DMz cannot push information blocks to DMx through this channel. CommandChannel is a unidirectional half-duplex mode, only DMz actively sends commands to DMx, and DMx feeds back the results of command execution to DMz, and DMx cannot send commands to DMz through this channel.

[0084] Please continue reading Figure 6 and Figure 7 , Figure 6 is a flowchart of an embodiment of a method for starting a software diagnostic system provided by the present application, Figure 7 The software diagnosis system startup method of the embodiment of the present disclosure is applied to the occurrence domain in the system software diagnosis system of the above embodiment, and the specific structure of the occurrence domain is not described here.

[0085] like Figure 6 As shown, the software diagnostic system startup method of the embodiment of the present disclosure specifically includes the following steps:

[0086] Step S11: start the event processing source, the first-line capturer, and the first-line diagnostic device in sequence according to a preset order.

[0087] Among them, Figure 7 As shown, each occurrence domain has a unique startup method. The first step of startup is to complete the startup work of the occurrence domain itself.

[0088] Specifically, the startup method of the occurrence domain will call the startup methods of objects such as the event processing source (ARES), information block generator (GEN), first-line capturer (FTC), first-line diagnostics (FTA), and occurrence service module (Service) in the occurrence domain one by one and in sequence, and strictly follow Figure 7 The startup sequence ensures that there will be no data generation and processing exceptions caused by the sequence during the startup process.

[0089] It should be noted that Figure 7 The figure only shows the startup sequence of a certain occurrence domain. In the actual system, there may be multiple occurrence domains, which are isolated from each other, but each maintains the same startup content and sequence.

[0090] Specifically, there is only one event processing source in each occurrence domain. After the occurrence domain completes its own startup work, it calls the startup method of the event processing source. The event processing source first completes its own startup work. Because the event processing source is the core object in the occurrence domain, the key mechanisms and functions of the occurrence domain are actually implemented by the event processing source.

[0091] There is only one first-line catcher object in each event processing source. After the event processing source completes its own startup work, the startup method of the first-line catcher is called. The first-line catcher first completes its own startup work. The first-line catcher and the first-line diagnostic are optional. The reason for their existence is that there must be local fast diagnostic actions or algorithms in the occurrence domain. Each first-line catcher has a group of first-line diagnostics. According to the pre-order of the first-line diagnostics in the first-line catcher, their startup methods are called one by one.

[0092] It should be noted that there is only one occurrence service module in each event processing source. As an optional option in the event processing source, the occurrence service module needs to be started only when cascading and command control are required.

[0093] Specifically, see Figure 8 , Figure 8 This is a logical system diagram of the service module startup provided by this application. Figure 8 As shown, after the event processing source calls the start method of the service module, it will also start a timer within the scope of the event processing source, named CmdTimer.

[0094] The CmdTimer is specifically used to receive commands from the event service module. The CmdTimer shares a root Timer with other information generators of the event processing source, so that there is only one timer runtime context in the event processing source.

[0095] When the CmdTimer timer of the event processing source expires, the RecvCmd_F method of the generating service module is called to receive the command that has arrived and is in the queue. The event processing source parses the house number information in the newly received command, finds the destination is the generating service module, the first-line catcher / first-line diagnostics, the information block generator or the event processing source itself, and returns the result of the command to the generating service module, and finally sends it to the sender of the corresponding command.

[0096] Step S12: Start the information block generator to complete the startup of the occurrence domain.

[0097] Each event processing source has a set of information block generator objects, and its startup method is called one by one. Because the information block generator is the real information input source in the occurrence domain, as a required option in the event processing source, the startup of the information block generator must be the last to ensure that other objects are ready to process the standard information generated by the information block generator, so as to avoid misjudgment of the algorithm due to inconsistent information during the startup process.

[0098] Specifically, see Fig. 9 , Fig. 9 This is a logical system diagram for starting the information block generator provided by this application. Fig. 9 As shown, the information block generator calls the StartTimer method of the event processing source, indirectly calling the timer determined when the event processing source is started.

[0099] The information generated in the information block generator needs to be able to be passed to the event processing source for processing. This application adopts a method in which the event processing source provides a timer, and the information block generator starts one or more timers as needed.

[0100] By adopting the above method, the timer of the entire occurrence domain can be unified. The StartTimer method provided by the event processing source is provided to the information block generator, so that the timers to be started by all information block generators in the occurrence domain are managed by the event processing source. The event processing source ensures that the entire occurrence domain has only one context running at the same time, so as to realize the non-concurrent operation environment of the occurrence domain, reduce the design and implementation complexity of the occurrence domain, and meet the requirements of simplicity, efficiency and stability of the occurrence domain.

[0101] In addition, after the start of the occurrence domain is completed, the following will continue to introduce how the occurrence domain completes the diagnosis of software activities. For details, please refer to Fig.10 , Fig.10 It is a flowchart of another embodiment of the software diagnostic system startup method provided by the present application.

[0102] like Fig.10 As shown, the software diagnostic system startup method of the embodiment of the present disclosure specifically includes the following steps:

[0103] Step S21: When the information timer of the information block generator expires, the event processing source is awakened.

[0104] When the timer registered by the information block generator in the occurrence domain expires, the event processing source is awakened. The timer here is managed by the event processing source, and the information block generator calls the StartTimer of the event processing source and is also merged into the timer to ensure that the event processing source has unique management of the timer in the occurrence domain.

[0105] Step S22: Generate an information block of a preset standard data type through an information block generator.

[0106] Among them, the event processing source calls the Timer_F method of the information block generator. In the Timer_F method of the information block generator, if there is information generated, the standard data type (iADS_Info_T) of the diagnostic system is generated. Then, the ProcessInfo_F method of the event processing source is directly called to process the newly generated information. Among them, iADS_Info_T here is the standard normalized data structure of the diagnostic system of this application, which solves the problem that the original information at the input end of the information block generator is too diverse. These various information enter the diagnostic system and must be normalized into a standard data structure.

[0107] Step S23: Call the event processing source to process the information block.

[0108] Among them, in the ProcessInfo_F method of the event processing source, the information to be processed is first cached, and then the ProcessInfo_F method of the first-line capturer is called, and the ProcessInfo_F method will call the ProcessInfo_F method of the first-line diagnostics in turn. The above methods are all running methods of the object. The caller calls according to the method name of the object. The efficiency of the function call can be maximized, and the information block generator can indirectly call the method of the first-line diagnostic through the event processing source to achieve the effect of rapid diagnosis.

[0109] In the process of the ProcessInfo_F method of the first-line capturer and the first-line diagnostics, a diagnostic report can be generated, that is, iADS_Report_T can be generated, and in the process, the PostReport_F method of the event processing source can be called directly or indirectly. The PostReport_F method of the event processing source will temporarily cache the reports generated by the first-line capturer and the first-line diagnostics. The return of the PostReport_F method of the event processing source is equivalent to the completion of the current Timer_F processing of the information block generator.

[0110] The event processing source calls the PostInfo_F method and PostReport_F method of the occurrence service module in sequence to push the cached information and reports to the downstream.

[0111] For example, Fig.11 The system diagram of memory leak is shown in Figure 1. GEN_meminfo and FTAction_MemLeak in DMO_USpace_ProcFS switch to the Running state after calling the Start method, which means that it automatically starts the system-level MemLeak diagnostic behavior.

[0112] GEN_meminfo uses the meminfo file in the PROC file system mount directory as the information source, and periodically (for example, 60 seconds) reads the information that FTAction_MemLeak can use to diagnose system-level memory leaks (for example, "MemTotal" and "MemFree").

[0113] For other DMO and DMP in the iADS system, any GEN or ACTION related to MemLeak, whether the Start method has been called or not, will not switch to the Running state. It is necessary to explicitly send the RUN command. Some STAction_MemLeaks also need to send the LOAD command first and then the RUN command.

[0114] The tool iADS_Utility sends the "DiagMemLeak" diagnostic behavior to DMP_USpace to manually start the MemLeak diagnostic behavior for all domains governed by this DMP.

[0115] 1) DMP_USpace will first send a RUN command to GEN_PID_status of DMO_USpace_ProcFS and STAction_MemLeak of DMP_USpace_ProcFS. STAction_MemLeak will find which PID may be MemLeaking based on the record information of GEN_meminfo and GEN_PID_status.

[0116] If DMP_USpace_ProcFS::STAction_MemLeak can preliminarily determine which PID is MemLeaking, it will send a Report to DMP_USpace::STAction_MemLeak to report that this PID is a suspected process of MemLeaking.

[0117] The occurrence domain of the software diagnosis system requires complete data collection and simple processing. To achieve simple processing, the occurrence domain cannot be cascaded with the upstream. The occurrence domain can only serve as the end point on the cascade line, and only generates data for preliminary diagnosis and then pushes it downstream. If multiple diagnostic nodes need to be cascaded and complex diagnosis is required, the processing domain designed in this application is required to achieve it.

[0118] The processing domain can be cascaded with the upstream occurrence domain or another processing domain, and can be connected with another downstream processing domain or operation and maintenance software to achieve mutual forwarding of upstream and downstream data or diagnosis of upstream pushed information and corresponding processing of downstream issued commands.

[0119] Please continue to read Fig.12 and Fig.13 , Fig.12 is a flowchart of an embodiment of a method for loading a software diagnostic system provided by the present application. Fig.13 The software diagnosis system loading method of the disclosed embodiment is applied to the processing domain in the system software diagnosis system of the above embodiment.

[0120] like Fig.13 As shown, the processing domain of the embodiment of the present disclosure is where the event or record information is collected for secondary diagnosis or forwarding, and the processing domain can perform complex processing actions. The upstream of the processing domain can be connected to the occurrence domain, or it can be connected to the processing domain to achieve cascading of processing domains. Specifically, the processing domain includes a collection forwarder, a second-line diagnostic device, a second-line diagnostic algorithm module, and a processing service module.

[0121] The Info-Command-Router (ICR) is responsible for receiving information or records published by the upstream. It can call the second-line diagnostic device to process or generate diagnostic reports and publish them to the downstream. It can also forward information or records from the upstream to the downstream. At the same time, it can also find the corresponding node through the routing information in the control command issued by the downstream and perform the corresponding processing action.

[0122] The second-tier diagnostician (STD) has the "log" capability by default, and also has the ability to call the second-tier diagnostic algorithm module. The second-tier diagnostician also provides a registration mechanism to support the dynamic registration of the second-tier diagnostic algorithm module. The second-tier diagnostician also has the ability to generate a "report", where the report refers to a diagnostic report on a certain period of time, certain selected events or recorded information of the processing domain.

[0123] The second-tier diagnostic algorithm module (STA) can perform complex diagnostic processing. The second-tier diagnostic algorithm module can be specified during static compilation or registered during dynamic runtime, that is, the second-tier diagnostic algorithm module implements the iADS_STA_ExecCommand, iADS_STA_ProcessInfoSet, iADS_STA_Start, iADS_STA_Stop, and iADS_STA_DoorplateInfoGet interfaces, compiled into so files, and when the system is running, the second-tier diagnostic device responds to the commands issued by the downstream when needed, dynamically loads, and reads the interface implementation address to start and run the dynamic second-tier diagnostic algorithm module.

[0124] The processing domain uses the processing service module to connect to the outside world. The upstream of the processing service module is Publisher, referred to as SrvPub, and the downstream of the processing service module is Subscriber, referred to as SrvSub.

[0125] In embedded devices, for some environments with limited memory, once the processing domain is started, all static second-line diagnostic algorithm modules will be loaded into it, which may cause process startup failure and malfunction. In order to solve this problem, this application designs a solution for dynamically loading second-line diagnostic algorithm modules. Based on the structure of the above processing domain and Fig.14 The software diagnostic system loading method provided by the embodiment of the present disclosure specifically includes the following steps:

[0126] Step S31: obtaining a command for loading a dynamic second-line diagnosis algorithm module received by the processing service module, wherein the command includes house number information and address information of the dynamic second-line diagnosis algorithm module.

[0127] Among them, Fig.14 As shown, the downstream SvrSub sends a command for specifying the processing domain to load the dynamic link second-line diagnosis algorithm model to the SrvPub of the corresponding processing domain node. The command carries the house number information and the address information of the dynamic second-line diagnosis algorithm module.

[0128] Specifically, since the processing domain can be cascaded, a processing domain is divided into a collection forwarder, a second-line diagnostic device, a second-line diagnostic algorithm module, a SrvPub module, and a SrvSub module. The control command is ultimately sent to a specific module for execution, so the command message needs to carry the house number information so that the collection forwarder can find the specific module for processing. The house number includes the following three types of information: functional domain information, entity information, and process thread information.

[0129] Functional domain information mainly indicates whether it is an occurrence domain or a processing domain, or a specific implementation category in an occurrence domain or a processing domain. The following codes can be used for reference: the memory occurrence domain is coded as 1, the CPU occurrence domain is coded as 2, and the thread occurrence domain is coded as 3. The memory processing domain is coded as 0x81, the CPU processing domain is coded as 0x82, and the thread processing domain is coded as 0x83.

[0130] Entity information, mainly distinguishes different modules in the same domain. The following codes can be used for reference: ICR is 1, STD is 2, and SrvPub is 3.

[0131] Process thread information: The same functional domain may be deployed in different processes A and B. A certain command may only need to be processed by process A. By filling in the process ID of process A through the process thread information, it can be ensured that the command is executed by process A instead of process B.

[0132] Step S32: Check, through the startup thread of the processing service module, whether there is any received data in the connection established with the occurrence domain or other processing domains.

[0133] The thread started by SrvPub under the corresponding processing domain node periodically checks whether there is data coming from the established connection. If there is data, the process goes to step S33.

[0134] Step S33: Copy the received data through the processing thread via the message mechanism.

[0135] Step S34: Call the collection forwarder to check whether there is any message to copy data.

[0136] Among them, the receiving thread of the collection forwarder periodically calls the OpRecvCmd_F (receive data method) of the collection forwarder to check whether there is a message of copying data. If so, it calls OpRecvCmd_F with OpExecCmd_F (execute command method) as an input parameter, so that it copies the data and then calls OpExecCmd_F to process the data.

[0137] OpExecCmd_F is sent to the second-line diagnostic device through the house number check, and the ExecCmd_F of the second-line diagnostic device is called for processing. The processing steps are as follows:

[0138] (1) The dlopen function loads the so file of the second-line diagnosis algorithm module under the path information carried by the command.

[0139] (2) Call the dlsym interface to obtain the start method represented by iADS_STA_Start and save it.

[0140] (3) Call the dlsym interface to obtain the stop method represented by iADS_STA_Stop and save it.

[0141] (4) Call the dlsym interface to obtain the ExecCmd_F method for executing the downstream command represented by iADS_STA_ExecCommand and save it.

[0142] (5) Call the dlsym interface to obtain the ProcessInfoSet method for processing upstream push information represented by iADS_STA_ProcessInfoSet and save it.

[0143] (6) Call the dlsym interface to obtain the address of the iADS_STA_DoorplateInfoGet interface and call it to save the doorplate information of this dynamic second-line diagnosis algorithm module, so that the addressing can be successful when processing the commands issued by the downstream in the subsequent processing.

[0144] (7) After calling the start method to start the second-line diagnosis algorithm module, the dynamic second-line diagnosis algorithm module can be used normally. The upstream information is processed by calling the ProcessInfoSet method, and the downstream command is processed by calling the ExecCmd_F method.

[0145] Step S35: Based on the house number information, the dynamic second-line diagnosis algorithm module corresponding to the second-line diagnosis device loading address information is called to perform a secondary diagnosis on the data.

[0146] Before loading the dynamic second-line diagnosis algorithm module, you need to start the processing domain first. For the specific logic of starting the processing domain, please refer to Fig.15 , Fig.15 It is a logical system diagram of the processing domain startup provided by this application.

[0147] like Fig.15 As shown, each processing domain has a unique startup method, and there is only one collection forwarder in the processing domain. The startup method of the collection forwarder is called to complete the startup of the entire processing domain.

[0148] Specifically, each collection forwarder can have multiple SvrSub objects, which are responsible for communicating with the upstream occurrence domain or cascade processing domain. At startup, traverse the control blocks of each SvrSub object, use the control block as an input parameter, call the SvrSub startup method, and trigger the SvrSub object to use different protocols to initiate a connection to the corresponding upstream SvrPub according to the protocol type configured in the input parameter. According to the corresponding protocol type configured, save the corresponding protocol message receiving, sending, and processing methods in the control block of each SvrSub object.

[0149] There is only one SvrPub object in each collection forwarder, which is responsible for sending and receiving data after receiving the downstream connection request. When starting, call the start method of SvrPub, start the thread, listen for connection events, and if data is received after the connection is established, notify the processing thread through the message mechanism (such as semaphore synchronization).

[0150] Each collective forwarder has only one second-line diagnostic device, and the startup calls the startup interface of the second-line diagnostic device to realize the startup of the diagnostic logic.

[0151] Each collective forwarder can have multiple second-line diagnostic algorithm modules, and the startup methods of the statically linked second-line diagnostic algorithm modules are called one by one to start. For the startup of the dynamically linked second-line diagnostic algorithm module, it responds to the command trigger during operation.

[0152] The collection forwarder needs an independent thread context to run. When the processing domain starts, it will use its own control block information as an input parameter to call the collection forwarder's startup method to start. The collection forwarder will store the control block information of these different processing domains in a list, and then start a processing thread to periodically traverse the linked list nodes, obtain the control block information of each processing domain, and call the control block's processing method to process the data.

[0153] Finally, the processing domain is successfully started after the collection forwarder's startup method call is completed.

[0154] Those skilled in the art will appreciate that, in the above method of specific implementation, the order in which the steps are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of the steps should be determined by their functions and possible internal logic.

[0155] In order to implement the control method of the system software diagnosis system of the above embodiment, including the software diagnosis system startup method and the software diagnosis system loading method, the present application provides a terminal device, which is specifically referred to as Fig.16 , Fig.16 It is a structural diagram of an embodiment of a terminal device provided in this application.

[0156] like Fig.16 As shown, the terminal device 500 of this embodiment includes a processor 51 , a memory 52 , an input / output device 53 , and a bus 54 .

[0157] The processor 51, memory 52, and input / output device 53 are respectively connected to a bus 54. The memory 52 stores a computer program. The processor 51 is used to execute the computer program to implement the software diagnostic system startup method and / or software diagnostic system loading method of the above-mentioned embodiment.

[0158] In this embodiment, the processor 51 may also be referred to as a CPU (Central Processing Unit). The processor 51 may be an integrated circuit chip with signal processing capabilities. The processor 51 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components. The processor 51 may also be a GPU (Graphics Processing Unit), also known as a display core, a visual processor, or a display chip, which is a microprocessor that is specifically used for image computing on personal computers, workstations, game consoles, and some mobile devices (such as tablet computers, smart phones, etc.). The purpose of the GPU is to convert and drive the display information required by the computer system, and to provide a line scan signal to the display to control the correct display of the display. It is an important component that connects the display and the mainboard of the personal computer, and is also one of the important devices for "human-computer dialogue". As an important component of the computer host, the graphics card is responsible for the task of outputting display graphics, and is very important for people engaged in professional graphic design. The general-purpose processor may be a microprocessor or the processor 51 may also be any conventional processor, etc.

[0159] The present application also provides a computer-readable storage medium, such as Fig.17 As shown, the computer-readable storage medium 600 is used to store a computer program 61. When the computer program 61 is executed by the processor, it is used to implement the method described in the software diagnostic system startup method and / or software diagnostic system loading method embodiments of the present application.

[0160] The methods involved in the embodiments of the software diagnostic system startup method and / or software diagnostic system loading method of the present application, when implemented in the form of a software functional unit and sold or used as an independent product, can be stored in a device, such as a computer-readable storage medium. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a disk or an optical disk.

[0161] The above description is only an implementation mode of the present invention, and does not limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made by using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A software diagnostic system loading method, characterized in that: The software diagnosis system loading method is applied to a processing domain in a system software diagnosis system, the processing domain includes a collection forwarder, a second-line diagnosis algorithm module, a second-line diagnostic device and a processing service module, wherein the collection forwarder is connected to the second-line diagnostic device and the processing service module respectively, the second-line diagnosis algorithm module is connected to the second-line diagnostic device, and the second-line diagnosis algorithm module includes a dynamic second-line diagnosis algorithm module and a static second-line diagnosis algorithm module; The software diagnostic system loading method comprises: Obtaining a command received by the processing service module for loading the dynamic second-line diagnostic algorithm module, wherein the command includes house number information and address information of the dynamic second-line diagnostic algorithm module; Checking, through the startup thread of the processing service module, whether there is received data in the connection established with the occurrence domain or other processing domains; If so, the received data is copied through the processing thread via the message mechanism; Calling the collective forwarder to check whether there is a message of copying data; If yes, then based on the house number information, the second-line diagnostic device is called to load a dynamic second-line diagnostic algorithm module corresponding to the address information to perform a secondary diagnosis on the data; The occurrence domain is used to record events triggered by software activities and to perform a diagnosis on the events; The processing domain is connected to the occurrence domain and the information database, and is used to perform secondary diagnosis on the events of the occurrence domain, and store the events and secondary diagnosis results in the information database; The collective forwarder is used to receive events from the upstream occurrence domain or commands from the downstream processing domain; The second-line diagnostic algorithm module is used to diagnose the events received by the collective forwarder and generate a diagnostic report based on the diagnosis results; The second-line diagnostic device is connected to the collective forwarder and the second-line diagnostic algorithm module, and is used to realize information docking between the collective forwarder and the second-line diagnostic algorithm module, and to integrate the diagnostic reports of all the second-line diagnostic algorithm modules to perform comprehensive diagnosis.

2. The software diagnostic system loading method according to claim 1, characterized in that: The step of calling the second-line diagnostic device to load the dynamic second-line diagnostic algorithm module corresponding to the address information based on the house number information includes: Loading a dynamic link library of a dynamic second-line diagnosis algorithm module corresponding to the address information; Calling a preset interface to obtain a startup method of the dynamic second-line diagnosis algorithm module; The startup method is called to start the dynamic second-line diagnosis algorithm module.

3. The software diagnostic system loading method according to claim 2, characterized in that: The software diagnostic system loading method further includes: Calling the preset interface to obtain the address of the house number information acquisition interface of the dynamic second-line diagnosis algorithm module and calling the interface to save the house number information of the dynamic second-line diagnosis algorithm module; The dynamic second-line diagnosis algorithm module is addressed based on the house number information stored in the house number information acquisition interface of the dynamic second-line diagnosis algorithm module, so as to call the dynamic second-line diagnosis algorithm module to perform secondary diagnosis on the data.

4. The software diagnostic system loading method according to claim 1, characterized in that: The house number information includes functional domain information, entity information and process thread information.

5. The software diagnostic system loading method according to claim 1, characterized in that: The processing service module includes a sending processing service module and a receiving processing service module, and the collective forwarder is connected to a sending processing service module and multiple receiving processing service modules; The sending processing service module is responsible for receiving and sending data after receiving a connection request from a downstream processing domain, and the receiving processing service module is responsible for communicating with an upstream processing domain or a cascade processing domain.

6. The software diagnostic system loading method according to claim 5, characterized in that: The software diagnostic system loading method further includes: Traversing the control blocks of each of the receiving and processing service modules, taking the control blocks as input parameters, and calling the start method of the receiving and processing service module; Based on the protocol type of the input parameter configuration, trigger the receiving processing service module to initiate a connection to the corresponding upstream occurrence domain or cascade processing domain; Based on the protocol type of the input parameter configuration, the corresponding protocol message processing method is saved to the control block of each of the receiving and processing service modules.

7. A system software diagnostic system, characterized in that: The system software diagnostic system comprises: at least one occurrence domain, for recording events triggered by software activities and performing a diagnosis on the events; The occurrence domain is applicable to multiple instances of the same type in multiple processes, independent collection and aggregation, and applicable to on-demand collection of the entire system, collection and sharing of information in independent processes; The occurrence domain includes an event processing source, an information block generator, a first-line diagnostic device, a first-line capture device, and an occurrence service module; Information database; at least one processing domain, connected to the occurrence domain and the information database, for performing secondary diagnosis on the events of the occurrence domain, and storing the events and secondary diagnosis results in the information database; The processing domain includes: A collection forwarder is used to receive events from the upstream occurrence domain or commands from the downstream processing domain; A second-line diagnostic algorithm module, used to diagnose events received by the collective forwarder and generate a diagnostic report based on the diagnostic results; The second-line diagnostic device is connected to the collective forwarder and the second-line diagnostic algorithm module, and is used to realize information docking between the collective forwarder and the second-line diagnostic algorithm module, and to integrate the diagnostic reports of all the second-line diagnostic algorithm modules to perform comprehensive diagnosis.

8. A terminal device, characterized in that: The terminal device includes a processor and a memory; the memory stores a computer program, and the processor is used to execute the computer program to implement the steps of the software diagnostic system loading method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed, the steps of the software diagnostic system loading method according to any one of claims 1 to 6 are implemented.

Images