In the paper the problem of monitoring of a complex technical systems state of is considered. It is noted that such systems include a large number of elements and their structures permanently change. Classi cation of problems of monitoring is given and possible approaches to their decision are considered. For solving these problems it is suggested to use model driven approach. As model of structure of a target system it is o ered to use multilevel relative nite state operational automata and as behavior model it is o ered to use the work ow graphs. The actuality of models is provided by means of analysis of log les. Authors have suggested an algorithm of multilevel relatively nite state operational automata synthesis earlier. For maintenance in actual state of behavior models one can use process mining algorithms. The example of usage of suggested approach is given.
The modern stage of technology development is characterized by the permanent increasing of the complexity of technical systems and by increasing of the number of subsystems, number of hierarchy levels and by the complexity of links between the elements of the system and by the complexity of the systems behavior. The complexity of the systems behavior can be expressed in the expansion of the ? Copyright c 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). set of implemented functions, in the complexity of realized functions and in the ability of systems to adaptation. Advanced systems realize elements of cognitive behavior, including ability to learning and self learning. The problem of monitoring the status of such systems becomes a complex scienti c and technical task. The monitoring system (MS) has to give information about the current state of the target system (TS), consisting of a huge number of elements, the structure of which is permanently changing, with strict restrictions on the bandwidth of communication channels and the number of observation points. Obviously, modern MS must have a level of intelligence, at least no lower than the level of intelligence of TS, i.e. should be adaptive and preferably have cognitive abilities. 2
The problem of monitoring of the objects states was faced by many generations
of researchers and developers, in particular technical systems developers. In the
early stages, this problem was investigated by specialists in the of control
systems, in particular adaptive control systems [
Nowadays there is currently no general theory of MS building. These problems are discussed using di erent architecture viewpoints and di erent perspectives for di erent classes of information systems (IS), although it is becoming increasingly clear that the MS represents a separate class of IS that can be considered as a subclass of information management systems.
Development of modern MS can be based on the following main IT
technologies: 1) theoretical researches in the eld of adaptive control systems [
From a theoretical point of view, the results obtained from studies in the
eld of adaptive management systems construction, in particular [
It should be noted that the above mentioned approaches only address separate aspects of MS development and do not form a holistic approach to development of MS that can be used for monitoring complex technical systems (CTS) with dynamic structure and adaptive behavior. 3
The suggested approach is aimed primarily at solving the problems of e ective management of CTS with dynamic structure and behavior through the implementation of e ective monitoring procedures. This approach can be applied both to the implementation of monitoring procedures of some external TS, and to the implementation of self monitoring procedure of MS. The key ideas of the developed approach is are the follows.
1. A TS is regarded as a partially observable system whose state information is not fully available for a certain moment of time.
2. Available TS state information is stored in the form of models of the TS that includes 3 model groups: models that describe structural dynamics, models that describe TS behavior, and transformation models. The models actuality is supported by means of log les processing.
3. The models are essentially architectural models. Thus, both TS and MS can be considered as agile architecture systems.
4. The proposed approach can be positioned as a multimodel approach in
the sense of [
The 3 main features of the proposed approach distinguish it from the existing approaches: 1) the use of explicit models describing structural dynamics and business processes in the TS; 2) structural dynamics and business processes are considered as a single entity; 3) the use of an architectural approach to the development of the MS, which allows to use suggested approach for solving the task of monitoring the state of multilevel systems with dynamic structure and adaptive behavior, which include many thousands of elements. 4
In general, the MS consists of a TS and a monitoring subsystem. The
monitoring subsystem receives reports about events occurring in the TS. The monitoring
subsystem may provide requests for the state of the TS or its elements. The
monitoring subsystem works with models that are generated from status messages
(logs) and provides information to users according to their roles and requests.
Systems of di erent nature can be conceded as TS, but the subject of this work
is CTS. Within the framework of the developed approach, the structure and
behavior of the TS are subject to the following main restrictions: 1) from the point
of view of the monitoring subsystem, the TS is passive, i.e. it does not react in
any way to attempts to pick up logs, it cannot prevent the attempts of pick up
logs, it does not change its state and behavior because of log pickupping; 2) log
sources are linked to certain subsystems and are not connected with each other
in any way; 3) all logs contain structured data which are represented in XES
(eXtensible Event Stream) format or can be converted to XES format [
Thus, the following types of tasks are not solved within the framework of the suggested approach: 1) in the case when logs from the TS encapsulate unstructured data (texts in natural languages, voice messages); 2) in the case when the TS is an active component, that is, it may prevent the process of log pick up by suppression or distortion of logs, or when the TS changes its structure and/or behavior when it detects an attempt to pick up the logs; 3) if the message semantic is unknown, i.e. when the problem is to understand the languages which is used for communication between TS elements (humans, animals, robots, etc.).
The MS can be considered as a log processing system. On the basis of logs and context information, TS models are built, on the basis of which information is presented to users according to their role and their requests. At the conceptual level MS can be de ned as Sm =fX; Y; M; F g, where X is a set of queries about TS state, Y is a set of reactions to queries, M is a set of models, F is a set of functions that implement mappings X!F Y, or X!F M!F Y. The generalized structure of the MS which includes 3 automata is shown in Figure 1.
MS includes 4 main elements: MS = fR; SDCA; BP DCA; M CAg, where: R - repository, SDCA - structural dynamics control automate, BPDCA - BP dynamics control automate, MCA- monitoring control automate. The repository is designed to store models, logs, scripts, contextual and other information.
Generalized algorithm of MS realized by MCA: Step 1.Start background monitoring processes (polling) Step 2. Waiting requests from other automata or a user
Step 3. If there is a request, from SDCA, then process the request and go to step 2
Step 4. If there is a request from BPDCA, then processing and go to step 2 Step 5. If there is a request from a user, then processing and go to step 2. Generalized algorithm of SDCA operation:
Step 1. Waiting for log from TS hardware or software platform or request from MCA
Step 2. If the log from the TS platform is received, then the log cleaning, processing and go to step 1
Step 3. If a request for MCA is received, processing and go to step 1 Generalized algorithm of BPDCA operation: Step 1. Waiting for log from BP or request from MCA
Step 2. If the log is received, then the log cleaning, processing and transition of item 1.
Step 3. If a request for APC is received, processing and transition of item 1.
In general case MS can be a part of monitoring and management system. The generalized structure of such a system is shown in Figure 2).
System according to Figure 1 includes 4 main elements: TS, MS, control signals generation subsystem and users. Monitoring requests can be generated either by a user (manual control) or by the control signals generator (automatic control or mixed mode). MS receives requests from users or from a control signals generator about TS or its elements status in terms of a domain speci c language. MS transforms requests into log requests script and on the basis models and information from logs generates answers to the requestor.
One can de ne following partial case of the system as shown in Figure 2: 1) the system operates in automatic mode (user is absent); 2) the user can only observe the behavior of the CA; 3) the user controls the system manually.
The MS can also be seen as a stand-alone management system that handles monitoring requests for some external system. 5
The model requirements that to the operation of automata can be formulated by the following way.
General model system requirements. The general requirements for models to be used in CTS MS can be de ned as follows: 1) models must have ability to describe CTS with dynamic structure and adaptive behavior; 2) models must be functionally complete, i.e. they must be able to answer questions from all users within the scope of the tasks; 3) models must be executable, i.e. it must be able to use them in run time and preferably in non-rigid real time mode; 4) models must have implementations of acceptable complexity, even for TS consisting of a large number of elements.
Requirements to structural models. The main requirement for structural models is the ability to describe with their help the dynamic structure of TS in terms of elements, connections and their current, past and future states of structural elements of TS. They must give the possibility to describe the constantly changing multilevel structure of arbitrary complexity, and it must be possible to build them automatically from logs.
Requirements for behavior models. The main requirement for behavior models is the ability to describe with their help BP and determine BP state for current moment of time, for past and future moments of time. They must allow observe BP execution in run time using log information. They also must allow change BP structure when TS structure changes.
Transformation model requirements. These models are used to form representations and they can be conceded as brokers between the model system and users. The main function of this subsystem is to translate queries formulated by interested parties into the language of queries to the corresponding models and, accordingly, to make the inverse transformation. 6
The models used in the frames of model based approach to MS construction are
essentially architectural models. Di erent formalisms such as UML diagrams,
Petri networks, graphs, particularly work ow graphs, ontologies, state machines
can be used as TS models [
The main argument in favor of this approach is the possibility of automatic
synthesis of such automata by logs [
In order to describe dynamic behavior it is necessary to able to describe multilevel managed adaptive processes. One of the key model requirements is the ability to generate automatically process models from logs.
Automata models also can be used for solving this problem. Thus, a hierarchical stochastic automate with a recon gurable structure can be used to describe the monitoring process in its most general form. In fact, it is a set of automata that can be used for simulation.
One can de ne the following main types of TS: 1) simple TS with xed structure; 2) complex TS with xed structure; 3) simple TS with variable structure; 4) complex TS with variable structure; 5) simple cognitive TS; 6) complex cognitive TS. Table 1 shows the types of automata that can be used to model separate TS classes.
The simplest Mealy machine is de ned as A = (X; Y; S; T; S0), where X and Y are nite sets of input and output signals, S is not more than countable set, S0 is initial state), T is table of transitions. Such machines are studied in detail, algorithms of their synthesis are known, but with their help it is possible to describe directly only the simplest MS with a xed structure of small complexity. A hierarchical (multilevel) automate is de ned as an oriented graph H = fV0, Vk, L, Tg having an initial vertex V0, nested vertices Vk, and a plurality of arcs L.
Each can be mapped to either automate A or graph H, and the vertex V0 only to graph H. Hierarchical MS are typically organized as a tree. When the state of the system changes, very often only the separate low level subsystems change their state. Hierarchical automata can in principle be reduced to conventional Mealy machine. The use of hierarchical automata in some cases makes it possible to simplify the procedure of their synthesis. They can also be useful when working with distributed MSs. If the structure of the TS is not constant, then the automate has to be rebuilt. This is not possible in all cases. Variable structure automate can be de ned as an automate whose transition and output functions are explicitly time dependent, Ai+1 = F(Ai, t) or as A = (X(t), Y(t), S(t), T(t), s0).
In the present work, it is assumed that the MS operates with discrete states and works in discrete time. As TS operates in discrete time and works with discrete states, it can be considered that at each time ti the automate is in some particular state si and then it can be de ned as A = (X(si), Y(si), S(si), T(si), s0). If the variable structure automate works for a very long time then the number of states in general becomes in nite. It makes the procedure of synthesis of such automate very di cult. This problem can be solved using 2 approaches: by generating a new automate \on the y" by means of correcting automate structure every time when a new log arrives or by reducing this problem to the special case when the number of states is a countable set. Thus, it would be useful to consider special cases when a new automate is not change its state to a new state, but only the individual elements (attributes) of the description are changed. In this case, the variable-structured automate may be de ned as a set of automata, Ai = Ai-1, i-1, i, where A is a set of operations, realization of which can transform the automat to the desired automate.
Variable structure automata can be considered as a class of automata for which di erent elements can be changed and other elements remain unchanged. The main types of automata with variable structure are presented in Table 2, where 0 corresponds to unchanged elements and 1 corresponds to variable elements. Some combinations have no practical implementations. This applies primarily to cases where states appear and disappear, but the transition table does not change. The situation with the appearance of new input signals without changing the transition table is essentially the appearance of unidenti ed automata and signals. The reasons may be di erent. First, such a signal may occur due to a time delay or failure in the log generation subsystem on the MS side, second, it may be a really new signal for which the automate needs to be recon gured. If the signal disappears, some of the automate states may become unavailable. These cases require separate consideration. Other combinations have real implementations. Changing input signals is a simple operation that can be implemented in terms of operations \Add Signal" and \Remove Signal". Behavior changes (transition tables) can be implemented in terms of operations \Delete Transition" and \Add Transition". Thus, the automate recon guration can be implemented in the form of a scripts including the operations listed above.
The task of synthesis of multilevel automata with variable structure is
discussed in detail in the works of the authors [
A stochastic automate (Moore) can be de ned as A = (X, Y, S, M(x), s0), where X is the nite set of input signals, Y is the nite set of output signals, S is the counting set of states, s0 is the initial state or probability distribution of initial states, M(x) = jjmij (x)jj, q is a function-function distribution.
It is known fact, that by means of increasing automate complexity it is possible to build an equivalent deterministic automate. In this case, the inputs are described by the stochastic matrix family X(t) = jjxt(t)jj.
From the point of view of MS construction probabilistic machines are interesting, rst of all, from the point of view of organization of the training process, by means of probability adjustment. 7
The structural dynamics control subsystem at the logical level can be represented by 2 main subsystems: structural dynamics model (SDM) and SDM control automate (SDMCA) (Figure 3). The physical implementations of the system according to Figure 3 can be very di erent. They can be realized as a distributed system, or as distributed ontologies, SDM and SDMCA can be implemented in the frame of one system or as separate unites.
SDMCA receives information about state of individual TS elements changes, which comes in the form of logs. On the basis of received information model corrections are realized. If it is necessary, then SDMCA sends request for additional information. It can be either simple queries or scripts. The SDMCA may receive requests on the state of the TS elements from the MCA and generate responses to these requests.
The IDA can be de ned as:
Msd = (Gsd; Fsd; Qsd); where Gsd, is a set of sets of graphs, Fsd is a set of graph conversion operators, Qsd is the language of TS state requests. The Gsd graph is a multilevel graph and describes the TS structure at some hierarchy level in terms of the subsystems and the relationships between them:
i Gsd = (Vi; Li); where Vi is the set of vertices belonging to the i-th level and Li is the set of links belonging to the i-th level. Through Vij we will denote the j-th element belonging to the i-th level, Lij - j-th link belonging to the i-th level, Lij . The set of sets Gsd can be divided into 3 subsets: 1) a subset of fully serviceable Gsds con gurations; 2) a subset of partially serviceable Gsdp con gurations; 3) a subset of defective Gsdr con gurations.
Each subset of Gsd includes a countable set of con gurations. Each element of the static model is vertex Vi and the link Lij can have an arbitrary number of attributes. The number and types of attributes depend on the speci cs of the subsystem to which the vertex or link is mapped.
Attribute values can be read at an arbitrary point in time in a log format,
de ned indirectly or with the help of logical inference. The attributes contain
parameters characterizing the technical state in terms of \green-yellow-red, GYR"
[
In particular, the working model describes the TS in concrete moment of time. The reference model can be linked with the interval and the parameters can be colored in the GYR colors. Elements (subsystems) can appear and disappear at an arbitrary moment in time because of di erent reasons i.e. on/o , break- x, user login/exit.
Models of new elements may be known and stored in the repository, but may not be known. Relationships between elements can also have attributes.
More formally, a model describing structural dynamics represented in the form of multilevel relative nite state operational automate can be de ned as follows.
Automate = fSet of Input Messages, Set of Output Messages and Logs, Set of Sets of Automate State, Set of Transition Tablesg, Machine State = fGeneral State, Current TS Structureg, General State = fServiceable, Faulty, Partially Serviceableg, Current structure = fElements, Linksg, Structure element = fAttributes, Linksg, Attribute = fSet of Name-Value pairsg, Links = fSiblings, Parents, Childreng.
The following information comes to automate inputs: 1) requests TS state (current state requests, past state requests, future state requests); 2) requests for recon guration (requests for recon guration in order to improve performance, requests for recon guration in case of TS element occurrence or disappearance.
Logs may by generated in di erent ways: 1) logs generated by built-in monitoring and diagnostics elements of TS subsystems; 2) logs generated upon request from SDCA; 3) logs generated by diagnostic scripts launched by SDCA.
SDCA is a processor (engine) providing access to the model by performing a set of operations. SDCA is responsible for monitoring the TS state and control TS structural dynamics. The SDCA input receives logs, which can be messages (responses to requests) or signals. The SDCA may provide requests for the state of the TS elements and provide control signals for recon guration or parameter adjustment. All end-user requests for TS element status pass through MCA. The SDCA controls the current model using commands of restructuring the current model. The main commands of model management are following: 1) replace the model; 2) to remove vertex; 3) add vertex; 4) to add link; 5) remove link; 6) remove attribute; 7) add attribute; 8) set attribute value.
SDCA inputs may receive requests for current, past and future state of TS or its elements. The main types of requests are of the following type: in what state is the i-th element of the TS, in what state was the i-th element of the TS in t moment of time, which subsystems are in a partially serviceable state, etc.
The automate operation the can be described as follows. The automate changes its state when new log or signal, which encapsulate information about the change in the state of the TS element, appears. Automate has memory for saving information about all previous States and traces. When a request about the state of the TS or TS elements is made by a user, the automate generates the required representation on the basis of the current state vector and/or historical vectors. The machine can query the status of the TS elements. This action does not change the automate state.
It should be noted that in general, the number of states of the automate can be in nitely large, for example, in the case of IoT systems. In this case the automate is to be built in run time mode. In many particular cases, the number of automate states is nite, for example when we deal with recon gurable technical systems.
Step 3. When information about the change in the state of the TS element appears, the following actions are performed:
Step 4.1. If it is possible, the response is generated on the base on the state vector, and is send to the user.
Step 4.2. If it is impossible then special diagnostic script is generated and launched. The response is formed on the base of the script execution results.
Step 5. If at the input we have a request about the reasons for the incorrect operation of BP, then the diagnostic script is generated and launched, the results of script operation are used to form a response.
Dynamic behavioral TS models are models of BP running in the TS. A wide
range of models and languages, such as Petri networks, automata models, work
ow graphs, L, YAWL etc can be used [
Taking into account earlier listed behavior models requirements, a work ow graph model has been selected. Three components of the work ow graph are of interest: the control ow graph, the data (object) ow graph, and the resource graph. The reference model is a work ow graph whose vertices are loaded with information identical to the information present in the logs in the form NameValues form. If possible, GYR intervals can be set. More formally, the pattern of behavior can be described as follows:
Reference Model = fVertex Set, Arc Set, Markup Setg. < V ertex >::=< V ertex name >< P arameter V alue > :
The contents of the Parameter-Values eld can be speci ed in 3 ways: one parameter-one value or one parameter - Interval of values, one parameter of 3 interval (Green, Yellow, Red).
BPDCA operates as follows. Logs are input to BPDCA. At the output we have BP control signals, which perform BP adjustment. It is assumed that the recon guration is realized inside the TS and the TS control unit selects one of the recon guration options from the list of possible ones. The BPDCA may request and receive current state information from the SDCA. The BPDCA informs the SDCA about violations in the BP implementation process and receives information about the TS structure change. In addition, the BPDCA input receives requests about the current status of the BP, to which it responds.
Generalized BPDCA algorithm is as follows.
Step 1. Logs and signals, which are generated by BP, are transmitted to BPCA input
Step 2. Logs are compared to reference logs
Step 2.1. If all values are in the green zone, then continue
Step 2.2. If values are in the red or yellow zone, a message is sent to the SDCA.
Step 2.3. If the TS restructuring signal is received, the possibility of BP restructuring is considered.
If it is possible, then the recon guration is performed and a message is sent
to the MCA. Markups are implemented using standard methods [
It should be noted that, unfortunately, it is impossible to present the reference model in the form of traces, since for a correctly operating process it is sometimes impossible to determine exactly the order of arrival of logs. This can be done, for example, with the help of data ow models.
The presentations formation models (RFM) describe how users interact with the MS using Domain Speci c Languages (DSL). Formally, the RFM can be de ned as Mpf =fT RM; DSLg, where TRM is a set of models built on the Mpf model, and DSL is a set of languages for interaction with MS, focused on di erent categories of users DLS !RQM and M !RS DLS.
RFM can be realized as a set of services for translation requests and responses into the DSL of di erent users. As a model describing the operation of the PFM, it is proposed to use a modi ed data fusion model based on a well-known JDL model [15], which includes 6 Levels.
Level 0. Signal/Feature Assessment. The main task solved at this level is to estimate and predict the values of the individual parameters of TS elements.
Level 1. Entity assessment. The main task solved at this level is to estimate and predict the values of individual parameters and the state of individual entities (objects).
Level 2. Situation Assessment. The main task solved at this level is to assess and predict the state of the structure and parameters of relations between elements of some part of the TS and their impact on the state of the objects themselves.
Level 3. Impact Assessment. The main task solved at this level is assessment and prediction of future states of the TS, its parts and formation of alternative variants of the system response.
Level 4. Process Assessment. The main task at this level is to evaluate and predict the performance characteristics of the TS and compare them with the desired performance indicators.
Level 5. Human-machine interaction (HMI). (Cognition Re nement). Functions related to the improvement of the man machine interface are implemented at this level. This level is responsible for virtualization and collective decisionmaking.
The JDL model assumes a bidirectional process. Bottom-up movement is a
process of information mining from raw data, and then knowledge extraction
from information and decision-making. A reverse motion is a stream of queries
that are formulated by interested persons in terms of the subject area. Note that
functions related to di erent levels can be implemented in an arbitrary order [
In fact, JDL model de nes what is \done" rather than \how is done" i.e. the JDL model is a functional model. It was never seen as a process model or as a technical architecture model. The classic JDL model is a fairly general model that is not directly related to any of the subject domains.
Visual data-fusion model. This model is a further development of JDL model. The authors solved the following tasks: i) minimization the amount of information provided to the user saving the needed level of quality; ii) provide information strictly in accordance with the user request and role; iii) provide information taking into account the current situation. The main distinguishing feature of this model from classical JDL model is that suggested MJDL model is domain oriented model and because of it this model can be populated by concrete services and stakeholders. So suggested MJDL model may be conceded as functionalprocess model.
The generalized structure of the proposed MJDL is shown in Figure 4 The proposed MJDL model as well as the classic JDL model has 6 levels. The main users (stakeholders) include 4 groups: service engineers (responsible for the technical state of the TS infrastructure), operator (monitoring the state of separate TS subsystems, if necessary, they can realize control actions), managers responsible for the technical state of large subsystems or the TS), business analysts and top managers who are primarily interested in the overall state of the TS. These user groups work at di erent levels of the MJDL model. Separate levels of MJDL model realize following functionality.
Level 0. The main task solved at this level is generation requests for logs and processing "raw" logs, processing, evaluation and prediction of values of TS elements individual parameters. It can be said that individual logs are processed at this level. Typical problems solved at this level are the elimination of noise such as random logs, loss of logs, inability to receive the required log, etc.
Level 1. The task of this level is characteristics evaluation of individual elements of TS and prediction the values of individual parameters and the state of individual TS subsystems. At this level functions related to the generation of information about individual objects are implemented. It may be, for example, information about the technical state of individual subsystems of a CTS, the location of the object, the speed of movement and the direction of movement.
Level 2. Evaluation of the overall TS state. The main task solved at this level is to estimate and predict the TS state. This layer implements functions related to generating situation information in a particular context in terms of entities (subsystems), relationships between them and events.
Level 3. Reaction de nition. This level is present if we speak about a monitoring and management system. The main task solved at this level is evaluation and prediction of future states of the TS and its parts in terms of utility/cost, generation of alternative versions of control signals generation. At this level, the situation is assessed, which may include an assessment of the dynamics of the situation, assumptions about possible actions of objects external to the CA, threats and their own vulnerabilities.
Level 4. E ciency assessment. The main challenge at this level is to evaluate and predict the performance characteristics of both the TS and the MS itself and compare them with the desired performance indicators. At this level, the CM itself is monitored, in particular to improve its timing parameters.
Level 5. Human-machine interaction. Functions related to the implementation of HMI procedures are implemented at this level. In addition, this level is responsible for virtualization and collective decision making. Also knowledge management mechanisms are implemented at this level, i.e. such questions are solved: who requests information, who has access to information, for what purpose the information will be used, etc.
The use of the proposed MJDL model allows solve 2 main problems: creation of common terminology, which specialists in di erent elds can use in the design of di erent MS for di erent subject domains. In this context, the task of harmonizing inter-layer interfaces, that is, standardizing the way information is presented, comes to the fore. 10
Depending on what is known about the TS and what needs to be known, 4 global tasks for MS can be identi ed.
Task A. Verifying the relevance of the model using log le information. Corresponds to the case where it is known both the static model of the TS and its dynamic model, i.e. models relating to all levels of interest are known.
Task B. Build a behavior model using a structural model and logs. In this
case, the TS structure is known, but there is no knowledge about BP in TS.
This problem is similar to the classic process mining task [
Task C. Building a structural model by behavior model and logs. BPs running in the TS are known or can be restored by logs. For example, in technical systems, this may be an option where it is necessary to determine the cause of the malfunction from an anomaly in behavior.
Task D. Construction of structural and behavior models using descent approach. In this case there is no complete information on both system structure and BP. There is only a set of logs. 11
Tasks Type A (Model conformance checking). The very fact that the model is irrelevant can be detected either through the appearance of messages (logs) or when internal control circuits are activated. It is assumed that the proper polling procedures are started. For Type A of problem statement there are a number of special cases
Task A1. Verify that the structure model and behavior model are correct. The indication of incorrect models can be: a message from SDCA generated by build in internal control schemes or a reaction to a request to rebuild the BP, a message from BPDCA about appearance of a yellow or red log, The reaction of MS can be a request to SDCA for running monitoring script in order to identify the origin of incorrect operation.
Task A2. Correction of models. The structure model is adjusted when it becomes known about changing TS element state. It can be done on the base of information from the log or by means of launching diagnostic script. Correction of the behavior is performed in the following cases: when a log with information about the restructuring of the TS, when a yellow or red log appears or when a request from the user about restructuring comes, for example, in order to improve the e ciency of the TS.
Task A3. Speci es the point of divergence between reference and real models. This task usually occurs in a MS running in post mortem mode. A typical approach to solving this problem is to view logs from the BP, i.e. from the BPDCA. We can start viewing logs both from the beginning or from the end. One can track the control ow graph, resource graph, and object ow graph for yellow-red logs. It is possible to track logs coming from SDCA for appearance of yellow-red logs. This approach usually allow detect the time and cause of the error.
Task A4. Construction of a picture of the development of an emergency situation. This task usually occurs in post mortem systems. The model of emergency situation development can be represented as a pair of ordered and time-aligned chains of yellow-red logs from the SDCA and BPDCA Using this information one can build causal links between events.
Task A5. Identify risks of emergency situations and present situation development options. Alarm risks are de ned in terms of yellow logs both from SDCA and BPDCA. The forecast is based on the assumption that yellow logs can turn into red log. So one can de ne the structural element responsible for the appearance of the yellow log, if the emergency situation is detected through the log from the BPDCA.
Tasks of type B. Building a behavior model from structure model
and logs. This is a well known process mining task [
Task B1. Build behavior model on the basis of structure model and logs. Control ow graph recovery is a process mining task in classical statement. (Restoring a resource graph and an object ow graph are separate tasks.)
Task B2. Restore the structure of individual BP from logs. This is a special case of classical process mining task when it is necessary to build BP model using logs only from certain BP.
Task B3. It is a task of nding certain patterns of unwanted behavior. The solution of this problem assumes usage of a pattern library. This problem as a rule is a security problem.
Tasks of type C. Building a structural model by behavior and logs.
Since the structural model is a multilevel relative nite state operational
automate, this task is the essence of the task of synthesis of such automate from logs
[
Task C1. Receiving actual information about changing of TS structure.
The main idea of solving this problem is running polling processes and process logs in run time. Also it is necessary to process in run time messages from the TS build-in control systems which are responsible for TS recon guration. In some cases it would be enough only to correct models but in very often it is necessary to rebuild the model from the stretch.
Task C2. Building a structural model from a behavior model. This is the task
of synthesis multilevel relative nite state operational automate from logs. This
task can also be de ned as the task of determining the structure of a black box
in terms of nite state operational automate on the basis of known behavior
in a minimum number of steps. Algorithms of synthesis of such automata are
described in details in publications [
Task C3. Identify a faulty TS element within the minimum time. This task assumes that some TS subsystem is known to be malfunctioning, but the speci c element causing the fault is unknown. It is necessary to generate or select the diagnostic procedure which can nd the faulty element.
Task C4. De ning a TS element which is a "bottleneck".The term "bottleneck" can be de ned in di erent ways. If bottleneck is an unreliable element, it is the task 5. If a bottleneck is de ned in terms of performance or throughput, this task is solved by receiving proper logs from running benchmarks. These can be both logs from structural elements and logs received from BP.
Tasks type D. Building of structural and behavioral models using descent approach. This fairly common task can be solved in di erent ways depending on which logs are available. If logs relating to all levels are available, the multilevel relative nite state operational automate can be build (Task C2) and then a behavior model can be build. If logs related only to certain levels are available, one can use the "step by step descent" method, that is, one can build only of the level of detail of the available logs.
The generalized algorithm is as follows.
Step 1. De ne a behavior model at the top i0 level.
Step 2. Using the black box de nition structure procedure (Task C2), de ne the top i0 layer structure.
Step 3. For each i0 level model element, using generated test scripts build lower level models in the same way.
Thus, the algorithm is reduced to the sequential application of the black box structure determination procedure and the construction of BP by logs. The case where logs themselves are available, but their structure and semantic are unknown, is a separate task, which is not considered in this work. This task type can be de ned as a separate type (Type E). A type E task can be formulated as a task of de ning a log structure by a structural model and a behavior model. 12
The suggested approach was used for development of a number of real IS. One of such systems is a cable television network management system. Modern cable television networks have hundreds of thousands and even millions of subscribers, and the number continues to grow. The system itself is a distributed system that includes data networks, server and subscriber equipment. The typical structure of a cable digital television (CDT) network is shown in Figure 5
In Figure 5, the following designations are used: Server - Data Center; LS { local segments of the network, STB - Set-top-box, which supports basic and extended functionality of user's TV receivers. Modern CDT networks has a number of speci c features. Such features include: large and very large network size, high dynamic environment, heterogeneity of network infrastructure, strict requirements in terms of total cost of ownership, reliability, reaction speed etc.
Failure of even one elements of such a network can lead to avalanche e ects when a local problem causes an avalanche-like increase in tra c between the local server and the STBs due to multiple attempts to receive/transmit data. It is obvious that all possible scenarios of behavior of such systems cannot be described in advance.
Monitoring of STB network interaction errors (so-called "last mile" errors) and receiver errors are particularly important. While monitoring CDT network it is necessary to take into account the following limitations when solving monitoring and control tasks: TV consoles, especially old models, have weak technical capabilities, data collection and transmission networks are characterized by low bandwidth, local servers, as a rule, have low performance. All these constraints de ne the context for MS development. In addition, the context is determined by end-user behavior.
CDT network operators have enough big toolbox for collecting and processing information about subscribers but the operators do not use these tools intensively. The problem is that existing restrictions do not allow realize processing of these information because this will lead to increasing network tra c and decreases the level of user services quality. For example it can increase the response time for user actions. In some cases the volume of data to be transferred can be many times more than real bandwidth of the network. Usage of model approach when models are placed in high performance central server and enough powerful region servers allow solve many mentioned above problems and essentially decrease the tra c inside the management network.
The main idea developed architectural model approach to MS development is that the TS is considered as partially observed IS, information (knowledge) of which for any moment of time is not available in full volume. Available information (knowledge) is stored in a form of dynamic models which include 3 groups of models: the models describing the structural dynamics, models describing behavior and models of transformation of representations.
The relevance of models is maintained by means of processing system events coming in the form of log- Thus, both MS and TS can be considered as agile architecture systems. Suggested approach is based on the algorithms of automatic synthesis of multilevel variable structure automata and process mining algorithms. Suggested approach was used in the process of development of a number of MS for di erent subject domains. Further direction of suggested approach development is solving problem of building MS for cognitive IS. This can be done by moving from hierarchical variable-structure automata to hierarchical probability variable-structure automata. This would allow realize learning procedures.