# Simulation Methodology-Based Context-Aware Architecture Design for Behavior Monitoring of Systems

## Abstract

**:**

## 1. Introduction

_{BM-DEVS}, which defines how simulation models should be implemented so that models can express the desired behavior to be monitored and perform the monitoring task. In Section 4, an example of execution on a simple model is presented. In this section, the desired monitoring trajectory is presented by a set of temporal logic rules and the step-by-step reasoning process for tracing the trajectory is shown. In Section 5, a context-aware architecture as an application of BM-DEVS models, discussions on the modeling efficiency of the proposed approach for monitoring, and an overview of the discrete event view of time flow in the temporal logic are described. Additionally, a comparison between the proposed approach and other common approaches to context-awareness is given. The final section concludes with a summary of the motivations and contributions of the proposed methodology, as well as future research directions.

## 2. Background

#### 2.1. DEVS Formalism

_{int}, δ

_{ext}, λ, t

_{a}),

_{int}is an internal transition function dictating state transitions due to internal events, δ

_{ext}is an external transition function dictating state transitions due to external events, λ is an output function generating external events at the output, and t

_{a}is a time advance function [10,11].

_{d}| d∈D}, EIC, EOC, IC, Select),

_{d}is a component basic model, EIC is the set of external input coupling connecting external inputs to component model inputs, EOC is the set of external output coupling connecting external outputs to component model outputs, IC is the set of internal coupling connecting component outputs to component inputs, and Select is a tie-breaking function [10,11].

#### 2.2. TL (Temporal Logic)

**∪**for continuation until some future moment, and W for continuation unless some future moment [8].

## 3. BM-DEVS Formalism

_{BM-DEVS}rules or TL

_{BM-DEVS}, within a multi-component model, which consists of multiple component models.

#### 3.1. BM-DEVS Structure

_{BM-DEVS}= (N, P, B, Z

_{f},

_{p}),

_{d}where P

_{d}is a set of sequential phases of component models, and d∈ D, where D is a set of component names. The phase is the symbolic name for representing the state of a model.

_{BM-DEVS}rules describing the trajectories for monitoring. A TL

_{BM-DEVS}rule is a TL implication formula whose arguments are BM-DEVS models.

_{f,p}is a set defined by Z

_{f,p}= {(f

_{b}, p) | f

_{b}∈F

_{b}, b∈B, p∈P} ⊆ (∪

_{b}

_{∈B}F

_{b}) × P. That is, Z is a translator function that maps Z

_{f,p}: F

_{b}→ P, where f

_{b}is one of the final states (F

_{b}) of the Büchi automata, b∈B. When the desired behavior is detected within N

_{BM-DEVS}, a certain phase p∈ P is set by Z

_{f,p}. Execution of Z

_{f,p}is equivalent to firing of a rule causing a phase transition of a coupled model of N

_{BM-DEVS}.

#### 3.2. Evaluation of TL_{BM-DEVS} Rules

_{BM-DEVS}rule is similar to a temporal logic implication formula whose arguments are BM-DEVS models. The condition of a TL

_{BM-DEVS}rule is evaluated to be true when an inference engine finds that the trajectory (behavior) of the component models match the trajectory description in the conditions of the rule. One of the differences in TL

_{BM-DEVS}from other TL is that since the time-space in BM-DEVS models is continuous as in classic DEVS models, the time-space in TL

_{BM-DEVS}rules is also continuous, rather than discrete. We will elaborate on this issue in the discussion section.

_{BM-DEVS}rule based on the time-dependent behavior of the component models, rather than just based on the static point values. Such an inference engine is called an IE

_{BM-DEVS}(Inference Engine—BM-DEVS). The IE

_{BM-DEVS}is different from a conventional inference engine in that the rules being evaluated in the IE

_{BM-DEVS}are TL

_{BM-DEVS}type rules rather than the conventional point value-dependent type rules. A comparison of the condition evaluations in the two different types of rules is given in Figure 1.

_{BM-DEVS}rule. The IE

_{BM-DEVS}evaluates the trajectory over a time period between t

_{0}and t

_{1}to determine if the behavior described in the conditions of the rule has occurred. If it has, the simulator may fire the rule after a conflict resolution and set the model to state s0. So, to evaluate the trajectory, tracking of the trajectory from t

_{0}until t

_{1}is needed. Whereas, the evaluation process of a conventional non-TL

_{BM-DEVS}rule just checks if the point values described in the conditions of the rule are true at t

_{1}(Figure 1b).

#### 3.2.1. Description of Phase Values in a Coupled Model and the Done-Messages in an IE_{BM-DEVS}

_{BM-DEVS}rules assigned to a parent model or coupled model. All the done-messages from the component models’ simulators are delivered with the component models’ initial phase values to the parent simulator just once if the done-messages are the one-time initial done-messages. In the case of non-initial messages, the done(p, t) message with the smallest t value (indicating the most imminent next event time) is delivered to the parent abstract simulator, as in the classic DEVS simulator [12].

_{BM-DEVS}part of the abstract simulator. This results in no execution of the IE

_{BM-DEVS}and no advancement of the moment value of this phase in the parent simulator receiving the done(nil, t) message. If the phase p is non-nil, then the parent simulator receiving the done(p, t) message invokes execution of the IE

_{BM-DEVS}part as well as the rest of the conventional part of the BM-DEVS abstract simulator, and the moment advances by one, i.e., the current-moment becomes the current-moment + ○ of the phase. Note that the moment value expressed by ○ is required by the IE

_{BM-DEVS}only for the evaluation of TL

_{BM-DEVS}rules, not for the conventional simulator. Note that the moment value represents the elapsed time within a phase, so that whenever there is a phase change, the moment value resets to 0.

_{BM-DEVS}rule indicates that one of the goals of the TL

_{BM-DEVS}rules has been realized. As a result, the moment is reset to 0 in a new phase, indicating that a new goal is to be pursued. After this phase change, the new phase value is reported upward to the parent simulator of the sender coupled model in a done(p, t) message, as explained previously. Upon receipt of this done(p, t) message, the parent or receiver simulator seeks the possibility of changing its phase too. This decision depends on the rules assigned to the receiver. On the other hand, if there is no phase change in the sender, the done message done(nil, t) is sent to the parent. In this case, there is no possibility of changing the phase of the parent receiving this message since the phase change did not occur in the sender or component model, which also means that no goal has been achieved at the sender component model. As a result, no goal can be achieved at the receiver parent model.

_{BM-DEVS}part of the BM-DEVS abstract simulator and cause a moment to advance [12].

#### 3.2.2. Algorithm for the Inference Engine Part of the BM-DEVS Abstract Simulator

_{BM-DEVS}, part of the BM-DEVS abstract simulator that performs TL

_{BM-DEVS}rule evaluation. The rest of the abstract simulator is for executing the instructions in the models to carry out the simulation process [10,11].

Algorithm 1. Algorithmic description for IEBM-DEVS | |

1 | repeat//start the abstract simulator with temporal evaluation on the TL_{BM-DEVS} rules |

2 | if receive done-message(p_{d}, t) then |

2 | //done-message is issued by a component model that has just gone through a phase change |

4 | //p_{d} is a phase value of the component model d, t is the current simulation time |

5 | if p _{d} ≠ nilthen//IE_{BM-DEVS} is invoked |

6 | cm = cm + ○//advance the cm (current moment) by one, initially cm = 0, ○ is the next moment |

7 | update {p//update the phase values of all the component models_{d}} |

8 | if AB = ’() then |

9 | determine AB from B based on {p_{d}} and p (or CM.p) |

10 | //CM.p is the phase of this model CM |

11 | //AB (set of active rules: a set of rules whose conditions are true up |

12 | to the current time point.). B a set of all the rules of this model. AB is a subset of B. |

13 | //true condition: the trajectory patterns in the condition of the rules |

14 | match that of the component models and this model |

15 | else |

16 | update every ab.s where ab∈AB |

17 | //make state transitions on every ab∈AB with ab::δ and {p_{d}} and p |

18 | //ab::δ is a state transition function of ab |

19 | end if |

20 | if any ab.f has reached then//ab.f is a final state of ab |

21 | p = Z//start a new phase p of this CM,_{f,p} |

22 | //Z is a translation function that maps a final state of rule ab to a CM’s phase_{f,p} |

23 | set AB = ’( ) |

24 | cm = 0 |

25 | end if |

26 | end if //end of if p_{d} ≠ nil |

27 | { |

28 | … |

29 | //Same as the execution of a classic DEVS abstract simulator part w/o the |

30 | IE_{BM-DEVS} involved. |

31 | //Executed for both done(p, t) and done(nil, t) cases. The classic DEVS |

32 | abstract simulator does not distinguish between these two done messages. |

33 | … |

34 | } |

35 | if p changed then |

36 | return done(p, t)//return the phase of this CM to the higher level abstract |

37 | simulator, which makes the parent of this CM advance |

38 | the current moment ○ by one |

39 | else |

40 | return done(nil, t) |

41 | end if |

42 | end if//end of if receive done-message(p, t) |

43 | until the end of the simulation//end repeat |

## 4. Simple Modeling and Simulation Example of the BM-DEVS

_{BM-DEVS}part of the BM-DEVS abstract simulator performs in the example in Section 4.2.

#### 4.1. BM-DEVS Model Specification Example

_{BM-DEVS}rules as shown below.

**Rule****1.**- MP.passive :: ○(P1.active ∧ P2.passive) ⇒ MP.active

**Rule****2.**- MP.active :: ○MP.active ⇒ MP.passive

_{BM-DEVS}= (N, P, B, Z

_{f},

_{p})

_{BM-DEVS}Rule 1and Rule 2, respectively;

_{f,p}= {(b1.s1, MP.active), (b2.s1, MP.passive)}.

_{BM-DEVS}Rules 1 and 2 are shown in Figure 4 is a pictorial representation of Büchi automata [12,15] b1 and b2, respectively. The state transition diagrams below show how the transitions are made. Initially, all the automata are at state i, which indicates that they are de-activated. Once activated, these automata enter state s0 from i. The double circle in the figure represents the final state, indicating that the trajectory expressed in the conditions of a rule has been generated; as a result, a phase change at the current model occurs.

_{BM-DEVS}Rules r1 and r2 shown in Figure 4 are represented by the Büchi automaton [12] b1 and b2, respectively, as shown below.

_{f,p}translates s1 into passive or MP.passive.

#### 4.2. BM-DEVS Abstract Simulator Example

_{BM-DEVS}, of the BM-DEVS abstract simulator is executed to monitor the trajectories of component models P1 and P2, which are arguments of the TL

_{BM-DEVS}rules stored in the coupled model MP. The simulator is being executed while the MP transits from passive to active and returns to passive. Since these transitions occur according to the trajectories of P1 and P2, the transitions of the trajectory of the MP are the result of monitoring the MP on the component models.

_{0}to t

_{1}, or from 0MP.passive to ○MP.passive. At ○MP.passive, the MP model transits to the “active” phase since the trajectory expressed in the condition formula of Rule 1, MP.passive :: ○(P1.active ∧ P2.passive), is detected, as shown in the timing diagram. Thus, the time point changes to 0MP.active, which is identical to ○MP.passive at that time point.

_{0}. Note that in step2, b

_{1}(Büchi automaton, representing Rule 1) becomes active, indicating that the simulator begins monitoring to detect the desired trajectory expressed in the conditions of Rule 1. In step3, when done(p1.active) is received, the simulator is able to detect the desired trajectory, and as a result of the detection, b1 transits from b1.s0 to b1.s1, where b1.s1 is the final state of b1, which is equivalent to MP.active. This equivalence is found by the translator function Z that translates a Büchi automaton state to an MP phase. Due to the phase change to “active”, the new time point begins with 0, or the time point resets to 0. At this moment, all the active automata in B are deactivated and re-evaluated. As a result, b

_{2}transits to b

_{2}.s0 from b

_{2}.i, indicating that b

_{2}became active; thus, the monitoring on b

_{2}begins, as shown in step3.

_{1}to t

_{2}, or from 0MP.active to ○MP.active. At ○MP.active, the MP model transits to the “passive” phase since the trajectory expressed in the condition formula of Rule 2, MP.active :: ○MP.active, is detected, as shown in the timing diagram. Thus, the time point changes to 0MP.passive, which is identical to ○MP.active at that time point. The detection of the trajectory and transition just described corresponds to executions of the abstract simulator from step 3 to step 4.

Execution steps in the abstract simulator C:MP of BM-DEVS | |

1 | [Step 1] |

2 | Initial values of C:MP—the values before the one-time initial done-messages are |

3 | received//C:MP is the abstract simulator for the MP model |

4 | {p//initial phase values of the component models_{d}} = ’( ) |

5 | p = passive//phase of the MP, passive initially otherwise specified |

6 | B = {b1.i, b2.i}//set B shows all the members of B with the current state values |

7 | AB = ’()//initially none of the automata (rules) of δ activate for b∈B, i.e., b1 and b2 |

8 | B’ = {b1.i, b2.i}//set B after execution of δ |

9 | Z//the final state of b1.s1 is identical_{f,p} = {(b1.s1, MP.active), (b2.s1, MP.passive)} |

10 | to the MP’s active state |

11 | [Step 2] |

12 | At time 0MP.passive—at initialization time, when initial messages |

13 | done(p1.passive, t) and done(p2.passive, t) are received |

14 | {p_{d}} = {p1.passive, p2.passive} |

15 | p = passive |

16 | B = {b1.i, b2.i}//set B shows all the members of B with the current state value |

17 | AB = {b1.s0} |

18 | B’ = {b1.s0, b2.i}//after execution of δ |

19 | Z/no change of the MP’s phase because b1.s0 is not a final state_{f,p} (b1.s0) => ’()/ |

20 | [Step 3] |

21 | At time ○MP.passive—when done(p1.active, t) is received |

22 | {p_{d}} = {p1.active, p2.passive} |

23 | p = passive |

24 | B = {b1.s0, b2.i} |

25 | AB = {b1.s1}//b1 reached at the accepting state or final state |

26 | B’ = {b1.s1, b2.i} |

27 | Z_{f,p} (b1.s1) => active |

28 | //after executing Z and clearing AB and selecting AB from B |

29 | //at time 0MP.active same as ○MP.passive |

30 | {p_{d}} = {p1.active, p2.passive} |

31 | p = active |

32 | B = {b1.i, b2.i} |

33 | AB = {b2.s0} |

34 | B’ = {b1.i, b2.s0} |

35 | [Step 4] |

36 | At time ○MP.active—when done(p2.active, t) is received |

37 | {p_{d}} = {p1.active, p2.active} |

38 | p = active |

39 | B = {b1.i, b2.s0} |

40 | AB = {b2.s1} |

41 | B’ = {b1.i, b2.s1} |

42 | Z_{f,p} (b2.s1) => passive |

43 | //after executing Z and clearing AB and selecting AB from B |

44 | {p_{d}} = {p1.active, p2.active} |

45 | P = passive |

46 | B = {b1.i, b2.i} |

47 | AB = ‘() |

48 | B’ = {b1.i, b2.i} |

49 | Steps continue until the end of the simulation. |

#### 4.3. Context-Aware Architecture Implementation as a BM-DEVS Application

**…**, object_n are BM-DEVS models through which monitoring of the real-world system is possible.

## 5. Discussion on BM-DEVS

_{f,p}are added to classic DEVS, and the abstract simulator is modified to allow the execution of these new elements. Additionally, the proposed inference engine IE

_{BM-DEVS}is added to the abstract simulator. Regarding the temporal logic, the major modification is to allow DEVS models to be the arguments in a TL rule, which in turn results in changing the view of the flow of time from discrete time-space to continuous time-space, since DEVS is defined based on continuous time-space. Naturally, the inference engine that executes the rules is modified to accommodate these changes, as explained in Section 3.2.

#### 5.1. Efficiency of BM-DEVS for Behavior Monitoring

#### 5.2. Determination of the Moment Value and Its Duration

#### 5.3. Comparison with Other Context-Awareness Approaches

_{BM-DEVS}, which is a temporal logic whose arguments are BM-DEVS simulation models, as shown in Figure 3. Note that the state trajectory of this type can represent any behavioral pattern irrespective of its purpose.

_{BM-DEVS}) naturally become the simulation models, which also results in the need for designing a temporal inference engine (IE

_{BM-DEVS}) capable of tracing the state transitions of the models for a certain interval of time, as shown in Figure 1. The inference engine reasons are based on a set of model states that correspond to either an initial state, an intermediate inferred state, or a goal state.

#### 5.4. Verification of the Validity of BM-DEVS

## 6. Conclusions and Future Work

_{BM-DEVS}, which is a temporal logic whose arguments are BM-DEVS simulation models, as shown in Figure 3. Note that the state trajectory of this type can represent any behavioral pattern irrespective of its purpose as long as the pattern can be generated within the models. To monitor the state trajectories of interest among a virtually unlimited number of possible trajectory patterns dispersed in the simulation model, a methodology that defines the components and their roles for monitoring the task is essential, as proposed in this research. According to the proposed methodology, since the state transitions of the models have to be traced, the arguments of the temporal logic (TL

_{BM-DEVS}) naturally become the simulation models. The simulation models as arguments of the rule, in turn, result in the need for designing a temporal inference engine (IE

_{BM-DEVS}) capable of tracing the state transitions of the simulation models for a certain interval of time, as shown in Figure 1.

_{BM-DEVS}.

_{BM-DEVS}rules and monitor trajectories expressed by the rules. The rules are executed by the proposed inference engine IE

_{BM-DEVS}and the algorithm for the inference engine is shown in Section 3.2.2. Note that the behavioral knowledge is stored via variables in this research. Further, since these variables are among the most basic factors constituting a problem solver, how the variables are defined affects all the subsequent designs, such as compound data structures, various levels of functions, and problem-solving algorithms, all of which determine whether problems can be expressed accurately and solved correctly.

_{BM-DEVS}rule to monitor the trajectories of the component models. However, in the future, temporal logic will be applied to the action of the rule as well. In this case, the action to be executed is expressed by the temporal logic formula, i.e., the action expressed in a TL

_{BM-DEVS}rule becomes a goal to be achieved. RG-DEVS (goal ReGression DEVS) [21] can be extended to implement the simulation model to achieve the goal expressed in a TL

_{BM-DEVS}rule, and the model thus implemented becomes the controller software module for a real-world system under control.

## Funding

## Conflicts of Interest

## References

- Jamil, M.S.; Jamil, M.A.; Mazhar, A.; Ikram, A. Ahmed, Smart environment monitoring system by employing wireless sensor networks on vehicles for pollution free smart cities. Procedia Eng.
**2015**, 107, 480–484. [Google Scholar] [CrossRef] [Green Version] - Rashid, B.; Rehmani, M.H. Applications of wireless sensor networks for urban areas: A survey. J. Netw. Comput. Appl.
**2016**, 60, 192–219. [Google Scholar] [CrossRef] - Vahdat-Nejad, H.; Ramazani, A.; Mohammadi, T.; Mansoor, W. A survey on context-aware vehicular network applications. Elsevier Veh. Commun.
**2016**, 3, 43–57. [Google Scholar] [CrossRef] - Baldauf, M. A survey on context-aware systems. Int. J. Ad Hoc Ubiquitous Comput.
**2007**, 2, 263–277. [Google Scholar] [CrossRef] [Green Version] - Fang, Q.; Xu, C.; Hossain, M.S.; Muhammad, G. STCAPLRS A spatial-temporal context-aware personalized location recommendation system. ACM Trans. Intell. Syst. Technol.
**2016**, 7, 59. [Google Scholar] [CrossRef] - Liu, Z.L.; Liu, Q.; Xu, W.; Liu, Z.; Zhou, Z.; Chen, J. Deep learning-based human motion prediction considering context awareness for human-robot collaboration in manufacturing. Procedia CIRP
**2019**, 83, 272–278. [Google Scholar] [CrossRef] - Klimek, R. Behavior recognition and analysis in smart environments for context-aware applications. In Proceedings of the IEEE International Conference on Systems, Man, and Cyberrnetics, Hong Kong, China, 9–12 October 2015. [Google Scholar]
- Hoyos, J.R.; García-Molina, J.; Botía, J.A. A domain-specific language for context modeling in context-aware systems. J. Syst. Softw.
**2013**, 86, 2890–2905. [Google Scholar] - Nam, S.M.; Cho, T.H. Context-aware architecture for probabilistic voting-based filtering scheme in sensor networks. IEEE Trans. Mob. Comput.
**2017**, 16, 2751–2763. [Google Scholar] [CrossRef] - Zeigler, B.P. Object-Oriented Simulation with Hierarchical, Modular Models: Intelligent Agents and Endomorphic Systems; Academic Press: San Diego, CA, USA, 1990; pp. 41–143. [Google Scholar]
- Zeigler, B.P.; Preahofer, H.; Kim, T.G. Theory of Modeling and Simulation; Academic Press: San Diego, CA, USA, 2000; pp. 75–123. [Google Scholar]
- Fisher, M. An Introduction to Practical Formal Methods Using Temporal Logic; John Wiley & Sons: Hoboken, NJ, USA, 2011; pp. 12–48. [Google Scholar]
- Manna, Z.; Pnueli, A. The Temporal Logic of Reactive and Concurrent Systems: Specification; Springer Science & Business Media: Berlin, Germany, 2012. [Google Scholar]
- Sickert, S.; Esparza, J.; Jaax, S.; Křetínský, J. Limit-deterministic büchi automata for linear temporal logic. In Proceedings of the International Conference on Computer Aided Verification, Toronto, ON, Canada, 17–23 July 2016. [Google Scholar] [CrossRef]
- Büchi, J.R. The Collected Works of J. Richard Büchi; Springer Science & Business Media: Berlin, Germany, 2012. [Google Scholar]
- Sezer, O.B.; Dogdu, E.; Ozbayoglu, A.M. Context-aware computing, learning, and big data in internet of things: A survey. IEEE Internet Things J.
**2018**, 5, 1–28. [Google Scholar] [CrossRef] - Mueller, M.; Smith, N.; Ghanem, B. Context-aware correlation filter tracking. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, Honolulu, HI, USA, 21–26 July 2017. [Google Scholar]
- Liu, N.N.; He, L.; Zhao, M. Social temporal collaborative ranking for context aware movie recommendation. ACM Trans. Intell. Syst. Technol.
**2013**, 4, 15. [Google Scholar] [CrossRef] - Cho, T.H. Embedding intelligent planning capability to DEVS models by goal regression method. Simulation
**2002**, 78, 716–730. [Google Scholar] [CrossRef] - Rakib, A.; Haque, H.M.U.; Faruqui, R.U. A temporal description logic for resource-bounded rule-based context-aware agents. In Proceedings of the International Conference on Context-Aware Systems and Applications, Phu Quoc Island, Vietnam, 25–26 November 2013. [Google Scholar]
- Elfar, M.; Wang, W.; Pajic, M. Context-aware temporal logic for probabilistic systems. arXiv
**2007**, arXiv:2007.0579. [Google Scholar]

**Figure 3.**The trajectory pattern of the Multi-Processor (MP) to be monitored (This pattern is the result of the P1 and P2 trajectories).

**Figure 4.**Pictorial representation of TL

_{BM-DEVS}rule 1 and rule 2 shown as Büchi automata b1 and b2, respectively.

© 2020 by the author. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Cho, T.H.
Simulation Methodology-Based Context-Aware Architecture Design for Behavior Monitoring of Systems. *Symmetry* **2020**, *12*, 1568.
https://doi.org/10.3390/sym12091568

**AMA Style**

Cho TH.
Simulation Methodology-Based Context-Aware Architecture Design for Behavior Monitoring of Systems. *Symmetry*. 2020; 12(9):1568.
https://doi.org/10.3390/sym12091568

**Chicago/Turabian Style**

Cho, Tae Ho.
2020. "Simulation Methodology-Based Context-Aware Architecture Design for Behavior Monitoring of Systems" *Symmetry* 12, no. 9: 1568.
https://doi.org/10.3390/sym12091568