CN115114134A

CN115114134A - Software diagnosis system loading method and system, equipment and storage medium thereof

Info

Publication number: CN115114134A
Application number: CN202110286410.7A
Authority: CN
Inventors: 兰海
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2021-03-17
Filing date: 2021-03-17
Publication date: 2022-09-27

Abstract

The application discloses a software diagnosis system loading method, a system, equipment and a storage medium thereof, wherein the software diagnosis system loading method comprises the following steps: acquiring a command for loading the dynamic two-line diagnostic algorithm module, which is received by the processing service module, wherein the command comprises doorplate information and address information of the dynamic two-line diagnostic algorithm module; checking whether the connection established with the occurrence domain or other processing domains has received data through a starting thread of the processing service module; if yes, copying the received data through a processing thread through a message mechanism; calling a set forwarder to check whether a message for copying data exists; if yes, calling a dynamic two-line diagnosis algorithm module corresponding to the address information loaded by the two-line diagnosis device based on the doorplate information so as to perform secondary diagnosis on the data. By the method, the dynamic loading of the two-line diagnostic algorithm module is supported, the two-line diagnostic algorithm module is used as required, and the use problem of the environment with hard memory is solved.

Description

Software diagnosis system loading method and system, equipment and storage medium thereof

Technical Field

The present application relates to the field of computer application technologies, and in particular, to a software diagnostic system loading method, a software diagnostic system loading system, a software diagnostic system loading device, and a storage medium.

Background

When the program code of the software is completed, the software must be diagnosed, which is to test whether the execution result of the program meets the requirements of the original design. At this time, the software designer must determine whether the input and output data of each individual function mode meets the original requirements, and in addition, the overall performance of the system is tested, and even if the functions are satisfactory, if the execution speed is very slow, the software cannot meet the needs of the user.

Currently, for a diagnostic system of software activity, a typical separation structure of "acquisition" and "analysis" is adopted, that is, independent acquisition and independent analysis are adopted, and acquisition adopts a "complete" mode and analysis adopts an "offline" mode. The existing processing domains responsible for "analysis" have the following problems: in the embedded device, for some environments with a relatively tight memory, if the processing domain is started, all static STAs are loaded, which may cause a process starting failure and a function abnormality.

Disclosure of Invention

The application provides a software diagnosis system loading method, a system, equipment and a storage medium thereof.

The technical scheme provided by the application is as follows: the software diagnosis system loading method is applied to a processing domain in a system software diagnosis system, and the processing domain comprises a set transponder, a two-line diagnosis algorithm module, a two-line diagnotor and a processing service module, wherein the set transponder is respectively connected with the two-line diagnotor and the processing service module, the two-line diagnosis algorithm module is connected with the two-line diagnotor, and the two-line diagnosis algorithm module comprises a dynamic two-line diagnosis algorithm module and a static two-line diagnosis algorithm module;

the software diagnosis system loading method comprises the following steps:

acquiring a command for loading the dynamic two-wire diagnostic algorithm module, which is received by the processing service module, wherein the command comprises doorplate information and address information of the dynamic two-wire diagnostic algorithm module;

checking whether the connection established with the occurrence domain or other processing domains has received data through a starting thread of the processing service module;

if yes, copying the received data through a processing thread through a message mechanism;

calling the set forwarder to check whether the message of the copied data exists;

if so, calling the second-line diagnotor to load a dynamic second-line diagnostic algorithm module corresponding to the address information based on the doorplate information so as to perform secondary diagnosis on the data.

Another technical solution provided by the present application is: providing a system software diagnostic system, the system software diagnostic system comprising:

at least one occurrence field for recording events triggered by the software activities and performing a diagnosis on the events;

an information database;

and the processing domain is connected with the occurrence domain and the information database and is used for carrying out secondary diagnosis on the event of the occurrence domain and storing the event and a secondary diagnosis result in the information database.

Another technical solution provided by the present application is: there is provided a terminal device comprising a processor and a memory, the memory having stored therein a computer program, the processor being configured to execute the computer program to implement the steps of the software diagnostic system loading method described above.

The application adopts another technical scheme that: there is provided a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program realizes the steps of the software diagnostic system loading method when executed.

Different from the prior art, the beneficial effects of this application lie in: the processing domain acquires a command for loading the dynamic two-line diagnostic algorithm module, which is received by the processing service module, wherein the command comprises doorplate information and address information of the dynamic two-line diagnostic algorithm module; checking whether the connection established with the occurrence domain or other processing domains has received data through a starting thread of the processing service module; if yes, copying the received data through a processing thread through a message mechanism; calling a set forwarder to check whether a message for copying data exists; if yes, calling a dynamic two-line diagnosis algorithm module corresponding to the address information loaded by the two-line diagnosis device based on the doorplate information so as to perform secondary diagnosis on the data. By the method, the dynamic loading of the two-line diagnostic algorithm module is supported, the two-line diagnostic algorithm module is used as required, and the use problem of the environment with hard memory is solved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a schematic block diagram of an embodiment of a system software diagnostic system provided herein;

FIG. 2 is a schematic block diagram of another embodiment of a system software diagnostic system provided herein;

FIG. 3 is a schematic block diagram of an embodiment of a processing domain provided in the present application;

FIG. 4 is a schematic block diagram of another embodiment of a system software diagnostic system provided herein;

FIG. 5 is a schematic diagram of the connection of a generation domain and a processing domain provided herein;

FIG. 6 is a flowchart illustrating an embodiment of a software diagnostic system booting method provided herein;

FIG. 7 is a logical system diagram of domain launching as provided herein;

FIG. 8 is a logical system diagram of the service module initiation provided herein;

FIG. 9 is a diagram of a logical system for the initiation of a chunk generator as provided herein;

FIG. 10 is a schematic flow chart diagram illustrating another embodiment of a software diagnostic system startup method provided herein;

FIG. 11 is a system diagram illustrating an embodiment of a memory leak provided herein;

FIG. 12 is a flowchart illustrating an embodiment of a software diagnostic system loading method provided herein;

FIG. 13 is a schematic diagram of another embodiment of a processing domain provided herein;

FIG. 14 is a logical system diagram of the operation of the processing domains provided herein;

FIG. 15 is a logical system diagram of the processing domain startup provided herein;

fig. 16 is a schematic structural diagram of an embodiment of a terminal device provided in the present application;

FIG. 17 is a schematic structural diagram of an embodiment of a computer-readable storage medium provided in the present application.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be obtained by a person skilled in the art without making any creative effort based on the embodiments in the present invention, belong to the protection scope of the present invention.

Referring to fig. 1, fig. 1 is a schematic structural diagram of an embodiment of a system software diagnostic system provided in the present application.

The system software diagnosis system 100 of the embodiment of the present disclosure includes at least one occurrence Domain 11(DMO ═ Domain interrupt), where the occurrence Domain 11 may exist in the form of an independent process, that is, the whole terminal device only needs one occurrence Domain 11 to complete the diagnosis of software activities.

In particular, the occurrence field 11 serves as a place where an event or record occurs and is captured first, the occurrence field 11 may be a place where an event or record first triggers an action, and the triggering of all actions within the occurrence field 11 may take the form of a function call. Thus, the occurrence domain 11 can take the shortest path, the fastest, most efficient processing means to complete the diagnosis of software activity.

The generation domain 11 of the present application is classified according to the type of the collected information, such as a call trace class, a ProcFS information collection class, and a NetStat statistic class. The staff can design a plurality of varieties according to different requirements, and is suitable for the generation domain 11 generated by different information acquisition.

The existence of the occurrence domain 11 can be realized by taking a process as a unit and generating one or more occurrence domain 11 instances in each process according to requirements, wherein the same occurrence domain 11 can only have one instance in a certain process. For example, the diagnosis of function call tracing needs to collect information about the entry and exit of each function, so each process needs to call an instance of the trace-class occurrence domain 11, that is, the same-type occurrence domain 11 has multiple instances in multiple processes.

In addition, the occurrence domain 11 can also exist in an independent process form, for example, the occurrence domain 11 collects kernel events, the whole software system only needs one instance, and when the occurrence domain 11 is required to collect events, only the instance of the process in which the occurrence domain 11 is located needs to be found.

The generation domain 11 of the embodiment of the present disclosure is suitable for independent collection and aggregation of multiple instances of the same type in multiple processes, and is also suitable for collection as required by the whole system, and collection and sharing of information in independent processes.

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 diagnotor 114, a first-line capturer 113, and an occurrence service module 115.

Among them, an Event processing Source (ARES) 111, an Event Source for recording and processing software activities. The event processing source 111 is the core of the occurrence domain 11, provides the runtime context of the occurrence domain 11, and only provides a unique context, ensuring that the single thread mode is adopted for design and implementation in the occurrence domain 11.

The context here on the one hand serves as a timer for the information block generator 112, periodically calling a timer function for the information block generator 112. Specifically, the information collected and generated by the information block generator 112 first occurs to the event processing source 111, is transmitted by the event processing source 111 to the line catcher 113 for processing, and finally is individually given to the line diagnoser 114 by the line catcher 113 for diagnostic processing. On the other hand, the context herein provides a timer for the occurrence service module 115 to periodically check for commands sent downstream.

In addition, when the first-line capturer 113 and the first-line diagnoser 114 process information, a report of processing information is generated, the report is generated in the middle of processing, the report is cached at the event processing source 111, and the event processing source 111 finally maintains the time sequence of the information and the report and pushes the information and the report to the downstream of subscription through the occurrence service module 115.

The information block Generator (GEN) 112 is connected to the event processing source 111, and is configured to generate the record information block or the event information block and send the record information block or the event information block to the event processing source.

The information block generator 112 may collect and generate non-standardized information, and format the information into an internal unified data format. The information block generator 112 relies on the timer provided by the event processing source 111 as context.

The First-line Catcher (FTC) 113 is connected to the event processing source 111 and the First-line diagnostor 114, and is configured to interface the event processing source 111 with the First-line diagnostor 114 and filter the recorded information block or the event information block and/or the diagnostic report.

The first line catcher 113 can realize the information interface 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 serves as a filter before the first line diagnoser 114 processes information, and the first line catcher 113 serves as a filter before the first line diagnoser 114 generates a report and outputs the report.

Wherein, a First-line diagnotor (FTA) 114 is used for diagnosing the recording information block or the event information block and generating a diagnosis report based on the diagnosis result.

The first line diagnostics 114 is where the diagnostic algorithms in the generation domain 11 are implemented, and the first line diagnostics 114 is specifically designed to implement only simple but urgent diagnostic algorithms. The input of the first-line diagnoser 114 comes from the information filtered by the first-line capturer 113, the output of the first-line diagnoser 114 may be a report, which is continuously returned to the generation field 11 and passed downstream, or a diagnostic action proprietary to the first-line diagnoser 114, i.e. a micro, necessary action may be taken.

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 configured to provide the information block and/or the diagnosis report of the event processing source to the downstream.

In an embodiment of the present disclosure, a system software diagnostic system includes: at least one occurrence domain, which is used for recording the event triggered by the software activity and carrying out diagnosis on the event; the occurrence domain includes: an event processing source for recording and processing event sources of software activities; the information block generator is connected with the event processing source and used for generating a recording information block or an event information block and sending the recording information block or the event information block to the event processing source; a first-line diagnotor for diagnosing the log information block or the event information block and generating a diagnosis report based on the diagnosis result; and the front-line catcher is connected with the event processing source and the front-line diagnotor and is used for realizing the information interface between the event processing source and the front-line diagnotor and carrying out information filtering on the recording information block or the event information block and/or the diagnostic report. By the method, dynamic acquisition and real-time diagnosis can be realized by providing the system software diagnosis system.

On the basis of the above embodiment of the system software diagnostic system, the present application further provides another software diagnostic system, specifically referring to fig. 2, and fig. 2 is a schematic structural diagram of another embodiment of the software diagnostic system provided by the present application.

The system software diagnostic system 200 of the embodiment of the present disclosure includes an occurrence domain 21, a processing domain 22, and an information database 23. Wherein, at least one processing domain 22 is connected with the occurrence domain 21 and the information database 23, and is used for performing secondary diagnosis on the event of the occurrence domain 21 and storing the event and the secondary diagnosis result in the information database 23.

Specifically, the processing domain 22 serves as a place for collecting, forwarding, performing secondary diagnosis, and secondary action of event information or log information. Processing event information or log information in the field 22, which has been delayed compared to the occurrence field 21, is not suitable for taking intervention actions requiring real-time performance; however, the processing domain 22 has moved out of the context of the generation domain 21, and more complex diagnostic processing can be performed in the processing domain 22. Event information or record information in the processing domain 22 is collected to generate Set [ InfoEvt, InfoRec ], which are suitable for batch operation and improve the efficiency of forwarding and processing. The processing domains 22 may implement a cascade of processing domains 22 through a cascade of set forwarders.

It should be noted that at most 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; the processing domains 22 can be cascaded, and at most one processing domain 22 can be connected out of one processing domain 22. In addition, in some special cases, the occurrence field 21 may exist alone.

With reference to fig. 3, fig. 3 is a schematic structural diagram of an embodiment of a processing domain provided in the present application. As shown in fig. 3, the processing domain 22 of the disclosed embodiment specifically includes a set forwarder 221, a two-wire diagnoser 222, a two-wire diagnostic algorithm module 223, and a processing service module 224.

Among them, an aggregation forwarder (ICR) 221 is configured to receive an event from the upstream occurrence domain 21 or a Command from the downstream processing domain 22. The functions of the aggregation forwarder 221 of the disclosed embodiment include, but are not limited to:

(1) as the core of the processing domain 22, the basic processing domain 22 only needs to be provided with one runtime context by the set forwarder 221.

(2) The generation domain 21 or the processing domain 22 connected to the upstream may be connected to a plurality of upstream.

(3) Information from upstream is received and forwarded to the two-wire diagnostics 222 for local diagnostic algorithms.

(4) Commands from downstream are received and a decision is made to forward to some object locally or to an upstream DMx.

(5) The chronological order between the information upstream and the report in the two-line diagnostic algorithm module 223 is ensured and pushed downstream.

Wherein, the Second-line Diagnostician (STD) 222 connects the set forwarder 221 and the Second-line diagnostic algorithm module 223, and is used for implementing information docking between the set forwarder 221 and the Second-line diagnostic algorithm module 223, and integrating the diagnostic reports of all the Second-line diagnostic algorithm modules 223 to perform comprehensive diagnosis.

Specifically, the two-wire diagnotor 222, as a site for information aggregation and filtering before the two-wire diagnostic algorithm module 223 in the processing domain 22, can implement a comprehensive diagnostic algorithm with respect to the incoming information and the report generated by the two-wire diagnostic algorithm module 223.

Wherein, a two-line diagnostic Algorithm module (STA: Second-Tier Algorithm)223 is used to diagnose the events received by the set repeater 221 and generate a diagnostic report based on the diagnostic result.

Specifically, the two-wire diagnostic algorithm module 223 is used as a diagnostic algorithm implementation site of the processing domain 22, and the two-wire diagnostic algorithm module 223 can perform complex diagnostic algorithm design and implementation according to the information transmitted by the two-wire diagnoser 222. The diagnostic structure of the two-line diagnostic algorithm module 223 may be transmitted to the two-line diagnotor 222 in the form of a report, and the two-line diagnotor 222 synthesizes all the reports of the two-line diagnostic algorithm module 223 to perform a comprehensive diagnosis.

The processing service module 224 is connected to the aggregation forwarder 221, and is configured to store the event or diagnosis report of the aggregation forwarder 221 in the information database 23, or forward the command of the aggregation forwarder 221 to the downstream processing domain 22.

The cascade logic of the system software diagnostic system 200 is further described below with reference to fig. 4, and fig. 4 is a schematic structural diagram of another embodiment of the system software diagnostic system provided in the present application. Summarizing the cascading logic rules of the system software diagnostic system 200 are detailed below:

(1) a generation domain 21 can only tap out at most one processing domain 22.

(2) In special cases, the occurrence field 21 may exist alone.

(3) One processing domain 22 may access multiple generation domains 21.

(4) The processing domains 22 may be cascaded.

(5) A processing domain 22 can only be tapped off at most one processing domain 22.

Specifically, the generation domain 21 and the processing domain 22, and the processing domain 22 are connected by using a Service module, i.e., a Service. The Service upstream is Publisher, SrvPub for short, and the Service downstream is Subscriber, SrvSub for short.

Referring to fig. 5, fig. 5 is a schematic diagram illustrating a connection between a generation domain 21 and a processing domain 22.

As shown in fig. 5, each SrvPub can only receive one SrvSub at most, and SrvSub can subscribe only when SrvPub is idle, that is, the existing subscription cannot be preempted.

Specifically, DMz connects to the publisher by calling the Connect method of SrvSub, initiating the subscription. If SrvPub already has SrvSub in place, then this subscription fails (Busy). When the SrvPub is connected, the SrvPub is required to be provided to start issuing matched protocol parameters. DMz subscribes to the successful release of DMx, and generates a "release subscription session (SrvPub-SrvSub-Dialog)" which contains an "information block channel (InfoChannel)" and a "command channel (CommandChannel)".

The InfoChannel is in a unidirectional simplex mode, only DMx actively pushes the information block to DMz, and DMz cannot push the information block to DMx through the channel. The CommandChannel is in a one-way half-duplex mode, only the DMz actively sends commands to the DMx, and the DMx feeds back the result of command execution to the DMz, so that the DMx cannot send the commands to the DMz through the channel.

Referring to fig. 6 and fig. 7, fig. 6 is a schematic flowchart of an embodiment of a software diagnostic system boot method provided in the present application, and fig. 7 is a logic system diagram of domain boot provided in the present application. The software diagnostic system starting method of the embodiment of the disclosure is applied to the occurrence domain in the system software diagnostic system of the embodiment, and the specific structure of the occurrence domain is not described herein again.

As shown in fig. 6, the software diagnostic system starting method according to the embodiment of the present disclosure specifically includes the following steps:

step S11: and starting the event processing source, the first-line catcher and the first-line diagnostor in sequence according to a preset sequence.

As shown in FIG. 7, each occurrence domain has a unique starting method, and the first step of starting is to complete the starting work of the occurrence domain itself

Specifically, the starting method of the occurrence domain calls the starting methods of the objects in the occurrence domain, such as the event processing source (ARES), the information block Generator (GEN), the first line capturer (FTC), the first line diagnoser (FTA), the occurrence Service module (Service), and the like, one by one and in sequence, and strictly follows the starting sequence of fig. 7, so that no data generation and processing exception caused by the sequence exists in the starting process.

It should be noted that fig. 7 only illustrates the starting sequence of a certain occurrence domain, and in an actual system, there may be multiple occurrence domains, which are isolated from each other, but each of which maintains the same starting content and sequence.

Specifically, each occurrence domain has only one event processing source, and after the occurrence domain completes its own startup work, the occurrence domain 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 a core object in the occurrence domain, and therefore, the key mechanism and function of the occurrence domain are actually realized by the event processing source.

Each event processing source only has one line catcher object, and the starting method of the line catcher is called after the event processing source completes the starting work of the event processing source. The line trap completes its own startup first, and the line trap and line diagnotor are optional, and the reason for this is that there is a locally fast diagnostic action or algorithm within the domain. Each line trap has a set of line diagnostics, and the start-up method of the line diagnostics is called one by one according to the predetermined sequence of the line diagnostics in the line trap.

It should be noted that there is only one occurrence service module in each event processing source, and the occurrence service module is used as an optional item in the event processing source and needs to be started only when cascade connection and command control are needed.

Specifically, please refer to fig. 8, fig. 8 is a logic system diagram of the service module initiation. As shown in fig. 8, after calling the start method of the occurrence service module, the event processing source also starts a timer in the range of the event processing source, which is named CmdTimer.

The CmdTimer is specially used for receiving commands from the occurrence service module, and shares one root Timer with other information generators of the event processing source, so that only one Timer runtime context is realized in the event processing source.

The CmdTimer timer of the event processing source expires, calling the RecvCmd _ F method of the occurrence service module, receiving the command that has come in queue. The event processing source analyzes the doorplate information in the newly received command, finds out the doorplate information with the purpose of an occurrence service module, a first-line catcher/first-line diagnostor, an information block generator or the event processing source, returns the result of executing the command to the occurrence service module, and finally sends the result to the sender of the corresponding command.

Step S12: the information block generator is started to complete the start of the occurrence field.

Wherein, each event processing source has a group of information block generator objects, and the starting method is called one by one. Because the information block generator is a real information input source in the generation domain and is used as a necessary option in the event processing source, the information block generator must be started at the end, so that other objects are ensured to be ready to process the standard information generated by the information block generator, and the misjudgment of an algorithm caused by inconsistent information in the starting process is avoided.

Specifically, referring to fig. 9, fig. 9 is a logic system diagram of the start of the information block generator provided in the present application. As shown in fig. 9, the information block generator calls the StartTimer method of the event processing source, and indirectly calls the timer determined when the event processing source is started.

The method of the event processing source providing the timer is adopted, and the information block generator starts one or more timers according to the requirement.

By adopting the method, the timers of the whole occurrence domain are the same, and the StartTimer method provided by the event processing source is provided for the information block generator to be used, so that all the timers to be started by the information block generator in the occurrence domain are managed by the event processing source. The event processing source ensures that the whole occurrence domain has only one context which runs simultaneously, so that the non-concurrent running environment of the occurrence domain is realized, the design and implementation complexity of the occurrence domain is reduced, and the requirements of conciseness, high efficiency and stability of the occurrence domain are met.

In addition, after the initiation of the occurrence domain is completed, how the occurrence domain completes the diagnosis of the software activity is described below, specifically referring to fig. 10, fig. 10 is a flowchart illustrating another embodiment of the initiation method of the software diagnosis system provided by the present application.

As shown in fig. 10, the software diagnostic system starting method according to the embodiment of the present disclosure specifically includes the following steps:

step S21: when the message timer of the message block generator expires, the event processing source is awakened.

Wherein, when the timer registered by the information block generator in the domain expires, the event processing source is awakened. The timer is managed by the event processing source, and the StartTimer of the information block generator for calling the event processing source is also merged into the timer, so that the event processing source can be ensured to have unique management on the timer in the occurrence domain.

Step S22: the information block of the preset standard data type is generated by an information block generator.

Wherein, the event processing source calls the Timer _ F method of the information block generator. The information block generator generates the standard data type (iasd _ Info _ T) of the diagnostic system in the Timer _ F method if any information is generated. Then, the processInfo _ F method of the event processing source is directly called, and the newly generated information is processed. The iasd _ Info _ T is a standard normalized data structure of the diagnostic system of the present application, and it is necessary to normalize the various information, which is entered into the diagnostic system, into a standard data structure.

Step S23: and calling the event processing source to process the information block.

The method comprises the steps of caching information to be processed in a ProcessInfo _ F method of an event processing source, calling a ProcessInfo _ F method of a line catcher, and calling a ProcessInfo _ F method of a line diagnotor in sequence. The method is an object operation method, the calling party calls according to the method name of the object, the efficiency of function calling can reach the highest, the method that the information block generator indirectly calls the first-line diagnotor through the event processing source can be achieved, and the effect of rapid diagnosis is achieved.

In the course of the ProcessInfo _ F method of the line catcher and the line diagnoser, a diagnostic Report, i.e., iADS _ Report _ T, may be generated, and in the course of processing, the PostReport _ F method of the event processing source may be directly or indirectly called. The PostReport _ F method of the event processing source temporarily caches the reports generated by the line grabber and the line diagnoser. 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.

And the event processing source calls the cached information and the report respectively according to the order to a PostInfo _ F method and a PostReport _ F method of the service generation module and pushes the information and the report to the downstream.

For example, as shown in the system diagram of memory leak shown in fig. 11, GEN _ meminfo and FTAction _ MemLeak in DMO _ USpace _ ProcFS switch to Running state after calling the Start method, that is, it automatically starts system level MemLeak diagnostic behavior.

GEN _ meminfo takes the meminfo file under the PROC file system mount directory as the information source, and periodically (for example, 60 seconds) reads the information in it (for example, "MemTotal" and "MemFree") that can be used by FTAction _ MemLeak to diagnose system-level memory leaks.

Other DMOs and DMPs in the iasd system, any GEN or ACTION associated with MemLeak, which have or have not called the Start method, will not switch to Running state, and need to show sending RUN command, and part of the state _ MemLeak also needs to send LOAD command first and then RUN command.

The tool iADS _ Utility sends a diagnosis behavior of 'DiagMemLeak' item to the DMP _ USpace, and manually starts the MemLeak diagnosis behaviors of all domains governed by the DMP.

1) DMP _ USspace first sends RUN command to GEN _ PID _ status of DMO _ USspace _ ProcFS and to STATION _ MemLeak of DMP _ USspace _ ProcFS, and STATION _ MemLeak looks for which PID may be in MemLeak according to the record information of GEN _ meminfo and GEN _ PID _ status.

If DMP _ USpace _ ProcFS:: STATION _ MemLeak can preliminarily determine which PID is in MemLeak, then it sends a Report to DMP _ USpace:: STATION _ MemLeak, reporting that the PID is a suspected process of MemLeak.

The generation domain of the software diagnosis system requires complete data acquisition and simple processing. The requirement processing is simple, the generation domain can not be cascaded with the upstream, the generation domain can only be used as the terminal point on the cascade line, and only data is generated for preliminary diagnosis and then is pushed to the downstream. If cascade connection of a plurality of diagnosis nodes is needed, complex diagnosis is needed, and the processing domain designed by the application is needed to realize the complex diagnosis.

The processing domain may be cascaded with an upstream generation domain or another processing domain, and may interface with another processing domain or operation and maintenance software downstream. The mutual forwarding of upstream and downstream data or the diagnosis of upstream push information and the corresponding processing of downstream issuing commands are realized.

With specific reference to fig. 12 and fig. 13, fig. 12 is a schematic flowchart of an embodiment of a software diagnostic system loading method provided by the present application, and fig. 13 is a schematic structural diagram of another embodiment of a processing domain provided by the present application. The software diagnosis system loading method of the embodiment of the disclosure is applied to the processing domain in the system software diagnosis system of the embodiment.

As shown in fig. 13, the processing domain of the embodiment of the present disclosure is a place where event or record information set is secondarily diagnosed or forwarded, and the processing domain may perform complex processing actions. The upstream of the processing domain can be connected with the generation domain and the processing domain, so as to realize the cascade connection of the processing domains. Specifically, the processing domain includes a set forwarder, a two-wire diagnostics algorithm module, and a processing services module.

The set-repeater (ICR) is responsible for receiving information or records issued upstream, and can call a two-line diagnotor to process or generate a diagnostic report and issue the diagnostic report to downstream; information from upstream may also be forwarded or recorded to downstream. Meanwhile, the corresponding node can be found through the routing information in the control command issued by the downstream, and the corresponding processing action is executed.

The Second-line Diagnostician (STD) defaults to Log (Log) capability and calls the Second-line Diagnostician module, and the Second-line Diagnostician provides a registration mechanism to support the dynamic registration of the Second-line Diagnostician module. The two-wire diagnotor also has the ability to generate a "Report," where a Report refers to a diagnostic Report for a certain period of time, for certain selected events, or for recorded information for the processing domain.

A two-wire diagnostic Algorithm module (STA) is capable of performing complex diagnostic processes. The two-wire diagnostic algorithm module can be specified during static compiling and can also be registered during dynamic running, namely the two-wire diagnostic algorithm module realizes an iADS _ STA _ Execummand, iADS _ STA _ ProcessInfoSet, iADS _ STA _ Start, iADS _ STA _ Stop and iADS _ STA _ DoorplatTenfoGet interface and compiles the interface into so files, and when the system runs, the two-wire diagnostic device responds to commands issued downstream when needed, dynamically loads the commands, and the interface realizes the starting and running of the dynamic two-wire diagnostic algorithm module after the address is read.

The processing domains are connected with each other externally by adopting a processing service module, wherein the upstream of the processing service module is Publisher, SrvPub for short, and the downstream of the processing service module is Subscriber, SrvSub for short.

In the embedded device, for some environments with a relatively tight memory, if the processing domain is started, all static two-wire diagnostic algorithm modules are loaded, which may cause a process starting failure and a function abnormality. In order to solve the problem, the application designs a scheme for dynamically loading a two-wire diagnostic algorithm module. Based on the structure of the processing domain and the logic system diagram of fig. 14, the software diagnosis system loading method provided by the embodiment of the present disclosure specifically includes the following steps:

step S31: and acquiring a command for loading the dynamic two-line diagnostic algorithm module, which is received by the processing service module, wherein the command comprises doorplate information and address information of the dynamic two-line diagnostic algorithm module.

As shown in fig. 14, the downstream SvrSub issues a command for specifying the processing domain to load the dynamic link two-wire diagnostic algorithm model to the SrvPub of the corresponding processing domain node, where the command carries the doorplate information and the address information of the dynamic two-wire diagnostic algorithm module.

Specifically, as the processing domains can realize cascade connection, a set transponder, a two-line diagnotor, a two-line diagnostic algorithm module, a SrvPub module and a SrvSub module are divided in one processing domain. The control command is issued and finally needs to be executed by a specific module, and the command message needs to carry doorplate information, so that the set repeater finds the specific module to process. The doorplate comprises the following three types of information: functional domain information, entity information, and process thread information.

The function domain information mainly indicates whether the domain is a generation domain or a processing domain, or a specific implementation category in the generation domain or the processing domain. In use, reference may be made to the following coding: the memory occurrence field code is 1, the CPU occurrence field code is 2, and the thread occurrence field code is 3. The memory processing domain code is 0x81, the CPU processing domain code is 0x82, and the thread processing domain code is 0x 83.

Entity information, which mainly distinguishes different modules in the same domain. The following codes can be referred to in use: ICR encoding is 1, STD encoding is 2, SrvPub encoding is 3.

The process thread information, the same functional domain, may be deployed in different processes a and B, and a certain command may only need to be processed by the process a, and the process ID of the process a is filled in through the process thread information. It can be guaranteed that the a process is executing instead of the B process.

Step S32: the connection established with the origin domain or other processing domain is checked by the start-up thread of the processing service module for the presence of received data.

The SrvPub-initiated thread cycle corresponding to the processing domain node checks whether there is data coming from the established connection, and if there is data, the process goes to step S33.

Step S33: the received data is copied by the processing thread through the messaging mechanism.

Step S34: the call set forwarder checks if there is a message to copy the data.

Wherein, the receiving thread cycle of the set repeater calls OpRecvCmd _ F (received data method) of the set repeater to check whether a message for copying data exists, if yes, the OpRecvCmd _ F is called to take OpExecCmd _ F (execution command method) as an entry parameter, and the OpExecCmd _ F is called to process data after the data is copied.

The OpExeccmd _ F is sent to the two-line diagnotor through the doorplate check, and the Execcmd _ F processing of the two-line diagnotor is called, and the processing steps are as follows:

(1) the dlopen function load command carries the so file of the two-wire diagnostic algorithm module under the path information.

(2) And calling the dlsym interface to acquire and save the Start method represented by the iADS _ STA _ Start.

(3) And calling the dlsym interface to acquire a Stop method represented by the iADS _ STA _ Stop and store the Stop method.

(4) The dlsym interface is called to acquire and save an executcmd _ F method for executing a downstream command, which is indicated by iasd _ STA _ executcommand.

(5) And calling the dlsym interface to acquire and store a ProcessInfoSet method for processing the upstream push information indicated by the iADS _ STA _ ProcessInfoSet.

(6) And calling the dlsym interface to acquire the address of the iADS _ STA _ DoorplatInfoGet interface and calling so as to store the doorplate information of the dynamic two-line diagnostic algorithm module, and when a command issued downstream is processed subsequently, the addressing can be successful.

(7) After the starting method is called to start the two-line diagnostic algorithm module, the dynamic two-line diagnostic algorithm module can be normally used. The upstream information calls ProcessInfoSet method processing, and the downstream command calls Execcmd _ F method processing.

Step S35: and calling a dynamic two-line diagnosis algorithm module corresponding to the loading address information of the two-line diagnotor based on the doorplate information so as to carry out secondary diagnosis on the data.

Before loading the dynamic two-line diagnostic algorithm module, the processing domain needs to be started, and for specific logic of starting the processing domain, referring to fig. 15, fig. 15 is a logic system diagram of processing domain start provided by the present application.

As shown in fig. 15, each processing domain has a unique start method, there is only one aggregation forwarder in the processing domain, and the start method of the aggregation forwarder is called to complete the start of the whole processing domain.

Specifically, there may be multiple SvrSub objects in each set forwarder responsible for communicating with an upstream generation domain or cascaded processing domain. When starting, traversing the control block of each SvrSub object, taking the control block as an entry parameter, calling the starting method of the SvrSub, and triggering the SvrSub object to initiate connection to the corresponding upstream SvrPub by using different protocols according to the protocol type configured by the entry parameter. And storing corresponding protocol message receiving, sending and processing methods to the control blocks of each SvrSub object according to the configured corresponding protocol type.

Each set forwarder only has one SvrPub object which is responsible for receiving and sending data after receiving a downstream connection request. When starting, calling the starting method of the SvrPub, starting a thread, monitoring a connection event, and notifying a processing thread through a message mechanism (such as semaphore synchronization) if data is received after connection is established.

Each set transponder only has one two-line diagnotor, and the starting interface of the two-line diagnotor is started and called to realize the starting of the diagnosis logic.

Each set of repeaters may have a plurality of two-wire diagnostic algorithm modules therein, and the startup method of the statically linked two-wire diagnostic algorithm modules is called one by one to start. The two-wire diagnostic algorithm module is activated in response to a command trigger at run time.

The set forwarder operates requiring an independent thread context. When the processing domain is started, the control block information of the processing domain is used as the starting method of the input reference calling set forwarder to be started. The set forwarder stores the control block information of the different processing domains into a list, then starts a processing thread, periodically traverses the linked list nodes, acquires the control block information of each processing domain, and calls a processing method of the control block to process data.

Finally, the processing domain is successfully started after the starting method of the set forwarder is called.

It will be understood by those skilled in the art that in the method of the present invention, the order of writing the steps does not imply a strict order of execution and any limitations on the implementation, and the specific order of execution of the steps should be determined by their function and possible inherent logic.

In order to implement the control method of the system software diagnostic system of the above embodiment, including a software diagnostic system starting method and a software diagnostic system loading method, the present application provides a terminal device, and specifically refer to fig. 16, where fig. 16 is a schematic structural diagram of an embodiment of the terminal device provided in the present application.

As shown in fig. 16, the terminal device 500 of the present embodiment includes a processor 51, a memory 52, an input-output device 53, and a bus 54.

The processor 51, the memory 52, and the input/output device 53 are respectively connected to the bus 54, the memory 52 stores a computer program, and the processor 51 is configured to execute the computer program to implement the software diagnostic system starting method and/or the software diagnostic system loading method according to the above embodiments.

In the present embodiment, the processor 51 may also be referred to as a CPU (Central Processing Unit). The processor 51 may be an integrated circuit chip having 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 device, discrete gate or transistor logic, discrete hardware components. The processor 51 may also be a GPU (Graphics Processing Unit), which is also called a display core, a visual processor, and a display chip, and is a microprocessor specially used for image operation on a personal computer, a workstation, a game machine, and some mobile devices (such as a tablet computer, a smart phone, etc.). The purpose of the GPU is to convert and drive display information required by a computer system, provide a line scanning signal to a display, control the correct display of the display, and be an important element for connecting the display and a personal computer motherboard, and also be one of important devices for "man-machine conversation". The display card is an important component in the computer host, takes charge of outputting display graphics, and is very important for people engaged in professional graphic design. A general purpose processor may be a microprocessor or the processor 51 may be any conventional processor or the like.

The present application further provides a computer-readable storage medium, as shown in fig. 17, the computer-readable storage medium 600 is used for storing a computer program 61, and when being executed by a processor, the computer program 61 is used for implementing the method as described in the embodiments of the software diagnostic system startup method and/or the software diagnostic system loading method of the present application.

The methods involved in the embodiments of the software diagnostic system starting method and/or the software diagnostic system loading method of the present application, when implemented, exist in the form of software functional units and are sold or used as independent products, and may be stored in a device, for example, a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

The above description is only an embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes performed by the present specification and drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims

1. The software diagnosis system loading method is applied to a processing domain in a system software diagnosis system, and the processing domain comprises a set transponder, a two-line diagnosis algorithm module, a two-line diagnotor and a processing service module, wherein the set transponder is respectively connected with the two-line diagnotor and the processing service module, the two-line diagnosis algorithm module is connected with the two-line diagnotor, and the two-line diagnosis algorithm module comprises a dynamic two-line diagnosis algorithm module and a static two-line diagnosis algorithm module;

the software diagnosis system loading method comprises the following steps:

acquiring a command which is received by the processing service module and used for loading the dynamic two-line diagnostic algorithm module, wherein the command comprises doorplate information and address information of the dynamic two-line diagnostic algorithm module;

calling the set forwarder to check whether the message for copying the data exists;

2. The software diagnostic system loading method of claim 1,

the step of calling the second-line diagnotor to load the dynamic second-line diagnostic algorithm module corresponding to the address information based on the doorplate information includes:

loading a dynamic link library of a dynamic two-line diagnostic algorithm module corresponding to the address information;

calling a preset interface to obtain a starting method of the dynamic two-line diagnostic algorithm module;

and calling the starting method to start the dynamic two-wire diagnostic algorithm module.

3. The software diagnostic system loading method of claim 2,

the software diagnosis system loading method further comprises the following steps:

calling the preset interface to acquire the address of a dynamic two-line diagnostic algorithm module doorplate information acquisition interface and calling the interface to store the doorplate information of the dynamic two-line diagnostic algorithm module;

and addressing the dynamic two-line diagnostic algorithm module based on the doorplate information stored by the doorplate information acquisition interface of the dynamic two-line diagnostic algorithm module, so as to call the dynamic two-line diagnostic algorithm module to perform secondary diagnosis on the data.

4. The software diagnostic system loading method of claim 1,

the doorplate information comprises functional domain information, entity information and process thread information.

5. The software diagnostic system loading method of claim 1,

the processing service module comprises a sending processing service module and a receiving processing service module, and the set repeater is connected with the sending processing service module and the receiving processing service modules;

the sending processing service module is used for receiving and sending data after receiving a connection request of a downstream processing domain, and the receiving processing service module is used for communicating with an upstream generation domain or a cascade processing domain.

6. The software diagnostic system loading method of claim 5,

traversing the control block of each receiving and processing service module, taking the control block as a reference, and calling a starting method of the receiving and processing service module;

triggering the receiving processing service module to initiate connection to a corresponding upstream generation domain or a cascade processing domain based on the protocol type of the access configuration;

and storing a corresponding protocol message processing method to the control block of each receiving and processing service module based on the protocol type of the access configuration.

7. A system software diagnostic system, the system software diagnostic system comprising:

an information database;

8. The system software diagnostic system of claim 7,

the processing domain comprises:

an aggregation forwarder for receiving an event from an upstream occurrence domain or a command from a downstream processing domain;

a two-wire diagnostic algorithm module for diagnosing events received by the collective transponder and generating a diagnostic report based on the diagnostic result;

and the second-line diagnotor is connected with the set transponder and the second-line diagnostic algorithm module and is used for realizing the information butt joint of the set transponder and the second-line diagnostic algorithm module, and synthesizing the diagnostic reports of all the second-line diagnostic algorithm modules to carry out comprehensive diagnosis.

9. A terminal device, characterized in that the terminal device comprises a processor and a memory; the memory stores a computer program, and the processor is used for executing the computer program to realize the steps of the software diagnosis system loading method according to any one of claims 1-6.

10. A computer-readable storage medium, wherein a computer program is stored, which when executed performs the steps of the software diagnostic system loading method of any one of claims 1 to 6.