Towards monitoring systems development on the basis of the multilevel relative finite state operational automata Michael Chervontsev1,2[0000−0003−3897−5068] , Saddam 1[0000−0001−9931−463X] Abbas , Alexander Vodyaho1[0000−0002−1933−0933] , and Natalia Zhukova3,4[0000−0001−5877−4461]? 1 Saint Petersburg Electrotechnical University ”LETI” (ETU) St. Petersburg, 197376, Russia aivodyaho@mail.ru 2 Research and Engineering Center of Saint Petersburg Electro-Technical University, Saint-Petersburg, 197022, Russia chervontsev.mikhail@nicetu.spb.ru 3 Saint-Petersburg Institute for Information and Automation RAS St. Petersburg, 199178, Russia nazhukova@mail.ru 4 Saint Petersburg National Research University of Information Technologies, Mechanics and Optics ITMO University, St. Petersburg, 197101, Russia. Abstract. In the paper the problem of monitoring of a complex techni- cal systems state of is considered. It is noted that such systems include a large number of elements and their structures permanently change. Clas- sification 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 offered to use multilevel relative finite state operational automata and as behavior model it is offered to use the work flow graphs. The actual- ity of models is provided by means of analysis of log files. Authors have suggested an algorithm of multilevel relatively finite 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. Keywords: monitoring systems · automata based approach to monitor- ing systems development 1 Introduction 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 Com- mons License Attribution 4.0 International (CC BY 4.0). 2 Vodyaho et al. 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 monitor- ing the status of such systems becomes a complex scientific 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 struc- ture 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 Known approaches for monitoring problems solving 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 sys- tems, in particular adaptive control systems [1], where it was considered as one of the subtasks of control theory. In later stages, this problem was faced by busi- ness process management system developers [2, 3], where it was no longer tightly linked to the problem of control systems development. Nowadays there is currently no general theory of MS building. These prob- lems are discussed using different architecture viewpoints and different perspec- tives for different 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 tech- nologies: 1) theoretical researches in the field of adaptive control systems [1]; 2) structural system dynamics studies [4]; 3) pragmatic approach to building monitoring systems on the base of ITIL/ITSM approach [5], 4) BPM systems [2]; 5) data fusion system [6]. For the developers of MS, the experience gained in the construction of MS for non-technical objects, in particular natural and biological objects, is of considerable interest. From a theoretical point of view, the results obtained from studies in the field of adaptive management systems construction, in particular [1], as well as studies in the field of structural dynamics of systems [4] are the most useful for the construction of the CM. In addition, the works of the authors [7, 8] on the synthesis of multilevel automata models and the works [9] on the synthesis of multilevel business processes (BP) from the logs can be noted. The pragmatic ITIL/ITSM approach to building MS is very good for enterprise information systems but attempts to apply it to other classes of IS, for example, for the Internet of Things (IoT), as a rule, are not effective. The specifics of building MS for the IoT are discussed [10]. A number of technologies can be useful for the modern MS building: 1) data processing in sensor networks [11]; 2) algorithms of process mining [12]; 3) multivevel automata synthesis [7,8]; 4) work related to the use of software Agile architectures [13]. Monitoring Systems Development 3 It should be noted that the above mentioned approaches only address sepa- rate aspects of MS development and do not form a holistic approach to develop- ment of MS that can be used for monitoring complex technical systems (CTS) with dynamic structure and adaptive behavior. 3 Suggested approach The suggested approach is aimed primarily at solving the problems of effective management of CTS with dynamic structure and behavior through the imple- mentation of effective 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 devel- oped 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 files 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 [4], based on the use of dynamic models, and as a agile architectural approach, based on the use of many architectural points of view and architectural perspectives [13]. 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 MS generalized model In general, the MS consists of a TS and a monitoring subsystem. The monitor- ing 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 mon- itoring subsystem works with models that are generated from status messages (logs) and provides information to users according to their roles and requests. Systems of different nature can be conceded as TS, but the subject of this work is CTS. Within the framework of the developed approach, the structure and be- havior 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 4 Vodyaho et al. 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 [14]; 4) the TS is not a hard real time system; 5) all control actions are formed on the basis of the TS model; 6) all logs must be converted to XES format as part of preprocessing; 7) all noises in logs shall be cleaned at the preprocessing stage. 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 unstruc- tured 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 se- mantic 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 defined as Sm ={X, Y, M, F }, 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 F F F of functions that implement mappings X→ Y, or X→ M→ Y. The generalized structure of the MS which includes 3 automata is shown in Figure 1. Fig. 1. The generalized structure of a MS. Monitoring Systems Development 5 MS includes 4 main elements: MS = {R, SDCA, BP DCA, M CA}, 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). Fig. 2. MS as a part of Management System. 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 6 Vodyaho et al. generator about TS or its elements status in terms of a domain specific language. MS transforms requests into log requests script and on the basis models and information from logs generates answers to the requestor. One can define 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 Requirements to models 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 defined 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 mod- els 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 chang- ing 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 repre- sentations 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 Automata models usage in MS The models used in the frames of model based approach to MS construction are essentially architectural models. Different formalisms such as UML diagrams, Petri networks, graphs, particularly workflow graphs, ontologies, state machines can be used as TS models [12, 13]. Taking into account the requirements to Monitoring Systems Development 7 structural models, the most promising is the use of multilevel relative finite state operational automata as the models. The main argument in favor of this approach is the possibility of automatic synthesis of such automata by logs [6, 7]. Structural models describe TS in terms of subsystems, links between them, in terms of inputs and outputs, and properties (attributes). 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 hierarchi- cal stochastic automate with a reconfigurable 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 define the following main types of TS: 1) simple TS with fixed struc- ture; 2) complex TS with fixed structure; 3) simple TS with variable structure; 4) complex TS with variable structure; 5) simple cognitive TS; 6) complex cogni- tive TS. Table 1 shows the types of automata that can be used to model separate TS classes. The simplest Mealy machine is defined as A = (X, Y, S, T, S0 ), where X and Y are finite 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 fixed structure of small complexity. A hierarchical (multilevel) automate is defined as an oriented graph H = {V0 , Vk , L, T} having an initial vertex V0 , nested vertices Vk , and a plurality of arcs L. Table 1. Types of automata that can be used in MS. TS structure Automata type Necessity of au- tomatic automata synthesis 1 Simple TS with fixed Elementary finite state No structure automate 2 Complex TS with fixed Multilevel finite state au- No structure tomate 3 Simple TS with variable Automate with variable Yes structure structure 4 Complex TS with variable Multilevel automate with Yes structure variable structure 5 Simple cognitive TS Stochastic automate with Yes variable structure 6 Complex cognitive TS Multilevel stochastic Yes automate with variable structure 8 Vodyaho et al. 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 con- ventional 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 Table 2. Types of automata with variable structure Inputs Outputs States Transitions Comments 0 0 0 0 0 Classical automate with fixed structure 1 0 0 0 1 Transition table changes 2 0 0 1 0 - 3 0 0 1 1 Individual states can appear and disappear and the transition table can be changed 4 0 1 0 0 Only the output function changes, the logic of the automate operation remains un- changed 5 0 1 0 1 The function of the outputs and the logic of the operation of the automaton, which is described in terms of the same states, change 6 0 1 1 0 - 7 0 1 1 1 Changes the function of outputs and the logic of the automate operation, which is described in terms of the same states 8 1 0 0 0 Only the output table changes, the logic re- mains the same 9 1 0 0 1 The logic that is described in terms of old states and the output function changes 10 1 0 1 0 - 11 1 0 1 1 Automate inputs and operation logic, which is described in terms of new states change 12 1 1 0 0 - 13 1 1 0 1 The logic of the operation, which is de- scribed in terms of previous states changes 14 1 1 1 0 - 15 1 1 1 1 The automate is completely replaced with a new automate structure automate can be defined 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 ). Monitoring Systems Development 9 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 defined 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 infinite. It makes the procedure of synthesis of such automate very difficult. This problem can be solved using 2 approaches: by generating a new automate “on the fly” 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 defined 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 different 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 ele- ments. Some combinations have no practical implementations. This applies pri- marily 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 unidentified au- tomata and signals. The reasons may be different. 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 re- configured. 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 reconfig- uration 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 dis- cussed in detail in the works of the authors [7, 8]. A stochastic automate (Moore) can be defined as A = (X, Y, S, M(x), s0 ), where X is the finite set of input signals, Y is the finite set of output signals, S is the counting set of states, s0 is the initial state or probability distribution of initial states, M(x) = ||mij (x)||, q is a function-function distribution. It is known fact, that by means of increasing automate complexity it is pos- sible to build an equivalent deterministic automate. In this case, the inputs are described by the stochastic matrix family X(t) = ||xt (t)||. 10 Vodyaho et al. From the point of view of MS construction probabilistic machines are inter- esting, first of all, from the point of view of organization of the training process, by means of probability adjustment. 7 Structural Dynamics Models 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 different. 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. Fig. 3. Logical structure of structural of dynamics management subsystem. SDMCA receives information about state of individual TS elements changes, which comes in the form of logs. On the basis of received information model cor- rections 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 defined 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: Gisd = (Vi , Li ), Monitoring Systems Development 11 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 configurations; 2) a subset of partially serviceable Gsdp configurations; 3) a subset of defective Gsdr configurations. Each subset of Gsd includes a countable set of configurations. 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 specifics 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, defined indirectly or with the help of logical inference. The attributes contain pa- rameters characterizing the technical state in terms of “green-yellow-red, GYR” [4], where “green” means that the element is fully serviceable, “yellow” means that the element is partially serviceable, “red” means that the element is de- fective. The parameter may also be unavailable. In this case, its value can be determined through a logical inference. An arbitrary number of log available points can be associated with each element. Reference and working (current) models are distinguished. These models can have different attributes. 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 different reasons i.e. on/off, break-fix, 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 finite state operational automate can be defined as follows. Automate = {Set of Input Messages, Set of Output Messages and Logs, Set of Sets of Automate State, Set of Transition Tables}, Machine State = {General State, Current TS Structure}, General State = {Serviceable, Faulty, Partially Serviceable}, Current structure = {Elements, Links}, Structure ele- ment = {Attributes, Links}, Attribute = {Set of Name-Value pairs}, Links = {Siblings, Parents, Children}. The following information comes to automate inputs: 1) requests TS state (current state requests, past state requests, future state requests); 2) requests for reconfiguration (requests for reconfiguration in order to improve performance, requests for reconfiguration in case of TS element occurrence or disappearance. Logs may by generated in different ways: 1) logs generated by built-in moni- toring 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 12 Vodyaho et al. (responses to requests) or signals. The SDCA may provide requests for the state of the TS elements and provide control signals for reconfiguration 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 infinitely 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 finite, for example when we deal with reconfigurable technical systems. The generalized SDCA algorithm is as follows. Step 1. Starting the polling process. Step 2. Waiting for input information. Step 3. When information about the change in the state of the TS element appears, the following actions are performed: Step 3.1. Adjust TS model Step 3.2. Reconfigure TS if necessary Step 3.3. Send restructuring information to BPDCA and to interested users. Step 3.4. Adjust and restart the polling process. Step 4. If a request about TS state arrives then: 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. Monitoring Systems Development 13 8 Behavioral TS models 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 flow graphs, L, YAWL etc can be used [2, 12]. Information about BP current state can be obtained by logs, in XES format [14]. Taking into account earlier listed behavior models requirements, a workflow graph model has been selected. Three components of the work flow graph are of interest: the control flow graph, the data (object) flow graph, and the resource graph. The reference model is a work flow graph whose vertices are loaded with information identical to the information present in the logs in the form Name- Values form. If possible, GYR intervals can be set. More formally, the pattern of behavior can be described as follows: Reference Model = {Vertex Set, Arc Set, Markup Set}. < V ertex >::=< V ertex − name >< P arameter − V alue > . The contents of the Parameter-Values field can be specified 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 reconfiguration is realized inside the TS and the TS control unit selects one of the reconfiguration 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 infor- mation 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 reconfiguration is performed and a message is sent to the MCA. Markups are implemented using standard methods [2] for workflow 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 flow models. 14 Vodyaho et al. 9 Representations formation models The presentations formation models (RFM) describe how users interact with the MS using Domain Specific Languages (DSL). Formally, the RFM can be defined as Mpf ={T RM, DSL}, 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 RQ RS different categories of users DLS→ M and M→ DLS. RFM can be realized as a set of services for translation requests and responses into the DSL of different users. As a model describing the operation of the PFM, it is proposed to use a modified 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 enti- ties (objects). Level 2. Situation Assessment. The main task solved at this level is to as- sess 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 Refinement). Func- tions related to the improvement of the man machine interface are implemented at this level. This level is responsible for virtualization and collective decision- making. 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 different levels can be implemented in an arbitrary order [6]. In fact, JDL model defines 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 informa- tion provided to the user saving the needed level of quality; ii) provide informa- tion 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 ori- ented model and because of it this model can be populated by concrete services Monitoring Systems Development 15 and stakeholders. So suggested MJDL model may be conceded as functional- process 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), man- agers 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 different 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 el- ements 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 definition. This level is present if we speak about a moni- toring 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. Efficiency 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 implementa- tion 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 pur- pose 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 different fields can use in the de- 16 Vodyaho et al. Fig. 4. MJDL model. Monitoring Systems Development 17 sign of different MS for different 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 Typical tasks of monitoring. Variants of problem statement Depending on what is known about the TS and what needs to be known, 4 global tasks for MS can be identified. Task A. Verifying the relevance of the model using log file information. Cor- responds 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 [12] when we want to restore the BP structure either from scratch from logs or from a known higher level dynamic model and logs. 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 sys- tems, 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 ap- proach. In this case there is no complete information on both system structure and BP. There is only a set of logs. 11 Generalized algorithms of typical monitoring problems solving 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 18 Vodyaho et al. a request from the user about restructuring comes, for example, in order to improve the efficiency of the TS. Task A3. Specifies 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 flow graph, resource graph, and object flow 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 situ- ation. 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 devel- opment options. Alarm risks are defined 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 define the structural element responsible for the appear- ance 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 [12]. Task B1. Build behavior model on the basis of structure model and logs. Con- trol flow graph recovery is a process mining task in classical statement. (Restor- ing a resource graph and an object flow 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 finding 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 finite state operational auto- mate, this task is the essence of the task of synthesis of such automate from logs [7,8]. 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 reconfiguration. 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 finite state operational automate from logs. This task can also be defined as the task of determining the structure of a black box Monitoring Systems Development 19 in terms of finite 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 [6, 7]. 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 specific element causing the fault is unknown. It is necessary to generate or select the diagnostic procedure which can find the faulty element. Task C4. Defining a TS element which is a ”bottleneck”.The term ”bottle- neck” can be defined in different ways. If bottleneck is an unreliable element, it is the task 5. If a bottleneck is defined 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 different ways depending on which logs are available. If logs relating to all levels are available, the multilevel relative finite 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. Define a behavior model at the top i0 level. Step 2. Using the black box definition structure procedure (Task C2), define 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 defined as a separate type (Type E). A type E task can be formulated as a task of defining a log structure by a structural model and a behavior model. 12 Example of suggested approach usage 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 num- ber of specific features. Such features include: large and very large network size, 20 Vodyaho et al. Fig. 5. The typical structure of CDT network. high dynamic environment, heterogeneity of network infrastructure, strict re- quirements in terms of total cost of ownership, reliability, reaction speed etc. Failure of even one elements of such a network can lead to avalanche effects when a local problem causes an avalanche-like increase in traffic 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 moni- toring 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 define 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 inten- sively. The problem is that existing restrictions do not allow realize processing of these information because this will lead to increasing network traffic and de- creases 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 power- ful region servers allow solve many mentioned above problems and essentially decrease the traffic inside the management network. Monitoring Systems Development 21 13 Conclusions 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 informa- tion (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 auto- matic 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 different subject domains. Further direction of suggested ap- proach development is solving problem of building MS for cognitive IS. This can be done by moving from hierarchical variable-structure automata to hierarchi- cal probability variable-structure automata. This would allow realize learning procedures. References 1. Sragovich V. Mathematical Theory of Adaptive Control World Scientific. Publishing Danvers, NJ, 2006. – 473 . 2. Dumas M., La Rosa M., Mendling J., Reijers H. Fundamentals of Business Process Management Second Edition. Springer-Verlag GmbH Germany, Berlin, 2018, – 527 p. 3. Weske M. Business Process Management. Springer-Verlag Berlin Heidelberg, 2012. – 403 . 4. Osipov V.Yu. Synthesis of effective programs for managing information and com- puting resources. Devices and control systems. 1998, No. 12. S. 24 - 27. 5. ITIL - IT Service Management. — URL: https://www.axelos.com/best-practice- solutions /itil 6. Blasch E., Bosse E., Lambert D. High-Level Information Fusion Management and System Design, Artech House Publishers, Norwood, MA. 2012. – 376 p. 7. Osipov V., Lushnov M., Stankova E., Vodyaho A. Inductive Synthesis of the Mod- els of Biological Systems According to Clinical Trials. // International Conference on Computational Science and Its Applications (ICCSA 2017). Lecture Notes in Computer Science, vol. 10404. Springer, Cham. – Pp 103-115. 8. Osipov V., Vodyaho A., Zhukova N. About one approach to multilevel behavioral program synthesis for television devices // International journal of computers and communications. 2017. Volume 11, P. – 17-25. 9. Munoz-Gama J. Conformance Checking and Diagnosis in Process Mining. Compar- ing Observed and Modeled Processes, Springer International Publishing AG. Berlin Heidelberg, 2016. – 202 p. 10. Huang Jun, Hua Kun (Eds.) Managing the Internet of Things: Architectures, The- ories and Applications. The Institution of Engineering and Technology, 2016. — 226 p. 22 Vodyaho et al. 11. Iyengar S., Brooks R., Distributed Sensor Networks. Taylor Francis, London. 2012- 1140p. 12. Van der Aalst W. Process Mining Data Science in Action. Second Edition. – Hei- delberg. Springer, 2016. – 468 p. 13. Rozanski N., Woods E. Software Systems Architecture. Working with Stakeholders Using Viewpoints and Perspectives. – Upper Saddle River, NJ. Addison-Wesley, 2012. – 715 p. 14. XES Schema Definition. http://www.xes-standard.org/