CN115114137A

CN115114137A - Software diagnosis system

Info

Publication number: CN115114137A
Application number: CN202110287680.XA
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 software diagnostic system, this diagnostic system includes: at least one occurrence domain, which is used for recording the event triggered by the software activity and carrying out primary 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 software diagnosis system.

Description

Software diagnosis system

Technical Field

The application relates to the technical field of computer application, in particular to a software diagnosis system.

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. In the complete acquisition mode, a lot of computing resources are often needed, and the data volume is large. In the off-line analysis mode, only complete data can be relied on, the diagnosis can have outdated problems, and data can not be acquired as required for real-time diagnosis.

Disclosure of Invention

The present application provides a software diagnostic system.

The technical scheme provided by the application is as follows: there is provided a software diagnostic system including:

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

the generation domain includes:

an event processing source for recording and processing event sources of the 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 first-line catcher is connected with the event processing source and the first-line diagnoser and is used for realizing the information interface between the event processing source and the first-line diagnoser and performing information filtering on the recording information block or the event information block and/or the diagnosis report.

Different from the prior art, the beneficial effects of this application lie in: the present application provides a diagnostic system comprising: 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 the recording information block or the 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 software diagnosis system.

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 software diagnostic system provided herein;

FIG. 2 is a schematic block diagram of another embodiment of a 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 structural diagram of another embodiment of the software diagnostic system provided by the present application;

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 in the present application;

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 derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

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

The 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 the software activity.

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 occurrence domain 11 of the present application is classified according to the type of the collected information, such as a call tracking class, a ProcFS information collection class, and a NetStat statistics 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. The context here, on the other hand, provides the occurrence service module 115 with a timer for periodically checking commands sent downstream.

When the first-line capturer 113 and the first-line diagnoser 114 process information, a report of the processed 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 keeps the time sequence of the information and the report and pushes the information and the report to the downstream of the 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-Tier Catcher (FTC) 113 is connected to the event processing source 111 and the First-Tier diagnostor 114, and is configured to interface the event processing source 111 with the First-Tier 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 the information, and the first line catcher 113 serves as a filter before the first line diagnoser 114 generates 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 to the first line diagnoser 114 is the information filtered from the first line capturer 113, the output of the first line diagnoser 114 can be a report, which continues back to the field of occurrence 11 and flows downstream, or the diagnostic actions proprietary to the first line diagnoser 114, i.e., micro, required actions, can 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 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 the recording information block or the event information block and sending the recording information block or the event information block to the event processing source; a first-line diagnoser 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 software diagnosis system.

On the basis of the above software diagnostic system embodiment, 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 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 occurrence 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 domain 22 may implement the cascade of processing domains 22 through the cascade of aggregation 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 the 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 present disclosure 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-line diagnotor 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 upstream information and the reports in the two-wire diagnostic algorithm block 223 is ensured and pushed downstream.

Wherein, the Second line diagnostor (STD) 222 is connected to the set repeater 221 and the Second line diagnostic algorithm module 223, and is used for implementing information docking between the set repeater 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 events received by the set forwarder 221 and generate diagnostic reports based on the diagnostic results.

Specifically, the two-wire diagnostic algorithm module 223 is used as a diagnostic algorithm implementation part of the processing domain 22, and the two-wire diagnostic algorithm module 223 can perform complex diagnostic algorithm design and implementation according to information transmitted by the two-wire diagnotor 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 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 software diagnostic system provided in the present application. Summarizing the cascading logic rules of 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 an occurrence 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 a 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 unidirectional half-duplex mode, only the DMz actively sends a command to the DMx, and the DMx feeds back a result of command execution to the DMz, so that the DMx cannot send the command 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 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.

Wherein, 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 a command 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 in the event processing source is realized.

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 occurrence domain and is 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 the algorithm caused by the inconsistency of the 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 information generated in the information block generator needs to be able to be transmitted to the event processing source for processing, and the method of the application adopts a method of providing a timer by the event processing source, and the information block generator starts one or a plurality of timers according to the needs.

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 handler is directly called to process the newly generated information. 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.

In the ProcessInfo _ F method of the event processing source, firstly, the information to be processed is cached, then the ProcessInfo _ F method of the line catcher is called, and the ProcessInfo _ F method can sequentially call the ProcessInfo _ F method of the line diagnotor. 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.

During the ProcessInfo _ F method of the line grabber and the line diagnoser, a diagnostic Report may be generated, i.e., iADS _ Report _ T, and during 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 reports generated by the line grabber and 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 and the PostInfo _ F method and the PostReport _ F method of the occurrence service 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 _ memnfo and FTAction _ MemLeak in DMO _ USpace _ ProcFS call the Start method, and then switch to Running state, that is, it automatically starts system level MemLeak diagnostic behavior.

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

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

The tool iaads _ Utility sends a "DiagMemLeak" diagnostic action to DMP _ USpace, and manually initiates a MemLeak diagnostic action for all domains governed by this DMP.

1) DMP _ USspace first sends RUN command to GEN _ PID _ status of DMO _ USspace _ ProcFS and STATION _ MemLeak of DMP _ USspace _ ProcFS, and STATION _ MemLeak looks for which PID may be MemLeak according to the recorded 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 diagnosis system requires complete data acquisition and simple processing. The requirement is simple to process, the generation domain can not be cascaded with the upstream, the generation domain can only be used as a terminal point on a cascade line, and only data is generated and is pushed to the downstream after preliminary diagnosis. 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 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 can also be connected with the processing domain, so as to realize the cascade connection of the processing domain. Specifically, the processing domain includes a set forwarder, a two-wire diagnostics algorithm module, and a processing services module.

The set-to-repeater (ICR) is responsible for receiving information or records released upstream, and can call the two-wire diagnotor to process or generate a diagnostic report to be released 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 a 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. In use, reference may be made to the following coding: 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 under the corresponding processing domain node checks whether there is data coming from the established connection, and if so, 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 address information loaded by the two-line diagnosis device based on the doorplate information so as to perform 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 upstream generation domains or cascaded processing domains. 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 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 GPU is used for converting and driving display information required by a computer system, providing a line scanning signal for a display and controlling the display of the display correctly, is an important element for connecting the display and a personal computer mainboard, and is also one of important devices for man-machine conversation. The display card is an important component in the computer host, takes on the task 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 also 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, such as 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 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. A software diagnostic system, characterized in that the software diagnostic system comprises:

the generation domain includes:

2. The software diagnostic system of claim 1, wherein the generation domain further comprises:

and the occurrence service module is connected with the event processing source and is used for providing the information block and/or the diagnosis report of the event processing source to the downstream.

3. The software diagnostic system as defined in claim 1, further comprising:

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.

4. The software diagnostic system of claim 3, wherein the software diagnostic system comprises the information database, a primary processing domain, a secondary processing domain, and the occurrence domain;

the primary processing domain is connected with the information database and is cascaded with the secondary processing domain; the secondary processing domain is connected with at least one generating domain.

5. The software diagnostic system of claim 3, wherein 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 diagnostic reports based on the diagnostic results;

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.

6. The software diagnostic system of claim 5, wherein the processing domain further comprises:

and the processing service module is connected with the set repeater and is used for storing the event or diagnosis report of the set repeater in the information database or forwarding the command of the set repeater to a downstream processing domain.

7. The software diagnostic system of claim 6,

the two-line diagnostic algorithm module comprises a dynamic two-line diagnostic algorithm module and a static two-line diagnostic algorithm module;

the processing service module is used for receiving a command for loading the dynamic two-wire diagnostic algorithm module, wherein the command comprises doorplate information and address information of the dynamic two-wire diagnostic algorithm module; the set forwarder is used for copying the received data through the processing thread by a message mechanism when the starting thread of the processing service module checks that the connection established with the generation domain or other processing domains has the received data;

the set forwarder is further configured to check whether a message for copying data exists, and if so, the second-line diagnotor is called 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.

8. The software diagnostic system of claim 7,

the set repeater is further configured to load a dynamic link library of the dynamic two-line diagnostic algorithm module corresponding to the address information, call a preset interface to obtain a starting method of the dynamic two-line diagnostic algorithm module, and call the starting method to start the dynamic two-line diagnostic algorithm module.

9. The software diagnostic system of claim 1,

the occurrence domain is used for sequentially starting the event processing source, the first-line catcher, the first-line diagnotor and the information block generator according to a preset sequence so as to finish the starting of the occurrence domain;

wherein, the information block generator adopts the information timer provided by the event processing source when starting.

10. The software diagnostic system of claim 9,

the generation domain is further configured to wake up the event processing source when the information timer of the information block generator expires, generate an information block of a preset standard data type through the information block generator, and invoke the event processing source to process the information block.