Towards Scalable Model Checking of Reflective Systems via Labeled Transition Systems

Reflection is a technique that enables a system to inspect or change its structure and/or behavior at runtime. It is a key enabler of many techniques for developing systems that have to function despite rapidly changing requirements and environments. A crucial issue in developing reflective systems is to ensure the correctness of their behaviors, because object-level behaviors are affected by metalevel behaviors. In this paper, we present an extended labeled transition system (LTS), which we call a metalevel LTS (MLTS), that supports data representation of another LTS for use in modeling a reflective tower. We show that two of the existing state reduction techniques for an LTS (symmetry reduction and divergence-sensitive stutter bisimulation) are also applicable to an MLTS. Then, we introduce two strategies for implementing an MLTS model in Promela, thereby enabling verification with the SPIN model checker. We also present case studies of applying MLTSs to two reflection applications: self-adaptation of a reconnaissance robot system, and dynamic evolution of an Internet-of-things (IoT) system. The case studies demonstrate the applicability of our approach and its scalability improvement through the state reduction techniques.


INTRODUCTION
R EFLECTION (or computational reflection) [1] is a technique that enables a system to inspect or modify its own structure and/or behaviors at runtime; these characteristics are called self-inspection and self-modification, respectively. Reflection was originally incorporated in the LISP language to create additional ways to access information in a program besides language primitives [2]. It has since been applied to other languages [3], [4] and several useful applications have been developed. Reflection is a key enabler of many techniques for developing systems that have to function despite rapidly changing requirements and environments. These techniques include introspection [5], dynamic object creation [4], requirement reflection [6], and self-adaptation [7], [8]. For example, reflection is a key enabler of self-adaptive systems, which can change their own structure or behavior in response to environmental changes at runtime according to their requirements or goals. Such an adaptation can be achieved through inspection and modification on reflection models [8], [9]. To determine its adaptation, a self-adaptive system reasons about and acts upon reflection models that correspond to the software system's architecture models, behavior models, or requirement/goal models [7], [9], [10], [11], [12].
A typical architecture for achieving reflection consists of an object level and a metalevel, as originally introduced by Smith [2]. The metalevel either accesses or manipulates the object level through data that represents the structure or behavior of the object level [3]. A reflective system can consist of two or more layers [10], and each pair of adjacent layers forms a relative relationship between the object level and the metalevel. This architecture is called a reflective tower. Specifically, a reflective tower is a reflective system with a multi-layered reflection mechanism in which each layer controls the next layer through reflection. Such a reflective tower can be modeled hierarchically. This enables the management concerns of a reflective system to be separated [13] or largescale reflective systems to be abstracted [14]. In a reflective tower, self-inspection is achieved by allowing a layer to access to information about the structure and behaviors of a lower layer, while self-modification is achieved by allowing a layer to modify the structure or behaviors of a lower layer.
A crucial issue in developing a reflective system is to ensure the correctness of its behaviors. This issue is important for the following reasons. First, state changes at the object level are not easily anticipated. A change may be triggered not only by local behaviors of the object level but also by access from the metalevel. Second, the local behavior of the object level itself might be changed by an access from the metalevel. In other words, a reflective system's behavior can change dynamically, and its testing is thus arduous.
There has been much research on formal verification to ensure the correctness of reflective systems. Weyns et al. [9] used the Z specification language. Ferrarotti et al. [15] and Schewe et al. [16] proposed extending abstract state machines to model reflection. Those efforts produced only theoretical frameworks. On the other hand, a promising approach to ensuring the correctness of a reflective system is model checking, because it performs verification in a fully automated way and does not require engineers to rationalize complicated reflective systems. Li et al. [17] and Grech et al. [18] proposed static analysis techniques for Java programs, which use the Java reflection API, but such techniques enable model checking only of Java programs. Capra and Camilli [19] used high-level petri nets and applied model checking to ensure the correctness of reflective systems. However, that approach handles only one pair of an object level and metalevel, and it does not support model checking of a reflective tower. Bruni et al. [20] proposed a model checking approach for reflective tower verification based on rewriting logic, which is a formal framework supporting full reflection. In their approach, the object level is represented as an algebraic structure and the metalevel accesses and changes the object-level behaviors through that structure. They used Maude [21], which is an implementation of the rewriting logic, for model checking of a reflective tower. Although rewriting logic is a powerful formal framework for reflective systems, its tool support is limited to only the Maude model checker and its variants.
We believe that a labeled transition system (LTS) is a promising approach to enable scalable model checking, because (1) it concisely represents the behavior of the target system, (2) a large number of techniques exist for reducing the state space of an LTS model, and (3) LTSs are supported by a wide range of model checkers that are used in industry, such as SPIN [22], NuSMV [23], and PAT [24]. However, an LTS does not support reflection. Self-inspection and self-modification require a model to have an internal representation of other models in lower levels, but there is no mechanism to model other LTSs in an LTS.
Hence, in this paper, we propose a formal model based on the generic LTS concept that specifies a reflective tower and supports scalable model checking. The contributions of this paper are as follows.
1) We present a metalevel labeled transition system (MLTS) that supports data representations of other MLTSs and thus enables modeling of a reflective tower. 2) We show that two state reduction techniques for LTSs, namely, symmetry reduction [25] and divergencesensitive stutter bisimulation ( [26], Section 7.8.1), are applicable to MLTSs. 3) We introduce two strategies for implementing an MLTS in Promela, which enables verification by the SPIN model checker. 4) We present two case studies of using an MLTS to model two reflective tower applications: self-adaptation of a reconnaissance robot system [27], and dynamic evolution of an Internet-of-things (IoT) system. 5) We validate the feasibility and scalability of our approach through the case studies. This paper is organized as follows. Section 2 gives background information on LTSs and related concepts. Section 3 describes the first case study of a reconnaissance robot system, which we use as a running example to illustrate our approach. Section 4 details our approach, and Section 5 describes two strategies for implementing an MLTS model in Promela to enable model checking. Section 6 presents the second case study of an IoT-based remote elderly monitoring system, which demonstrates the scalability of our approach. Section 7 discusses the advantages and limitations of our approach. Finally, Section 8 reviews related work, and Section 9 concludes with a summary of the key points and an outline of our future work.

PRELIMINARIES
In this section, we present definitions related to LTSs ( [26], Section 2; [28]) because our approach is based on the standard concept of an LTS. Definition 1. An LTS T is a tuple ðS; A; À!; s 0 ; AP; LÞ, where S is a set of states, A is a set of action labels, À! S Â A Â S is a transition relation, s 0 2 S is the initial state, AP is a set of atomic propositions, and L : S ! 2 AP is a labeling function.
Hereafter, we will write s À! l s 0 if ðs; l; s 0 Þ 2 À!. In the definition of À! jj , the first and second sets comprise the asynchronous transitions of T and T 0 , respectively, and the third set comprises their synchronized transitions.
Linear temporal logic (LTL) is a typical framework to specify the dynamic properties of LTSs. We can determine that an LTS satisfies an LTL formula specifying such a property by checking if each sequence of consecutive transitions of the LTS conforms to the formula.
An LTL formula for an LTS T ¼ ðS; A; À!; s 0 ; AP; LÞ is either p 2 AP ; a formula obtained by combining formulae with a logical connective :; _;^; or ! ; F; ÅF; FUC; or FW C, where F and C are formulae.
We can define a satisfaction relation T; s F among an LTS T , a state s 2 S, and an LTL formula F. Before presenting the definition, we need to define the execution traces represented by a sequence of transitions. Definition 3. An execution trace of an LTS T ¼ ðS; A; À!; s 0 ; AP; LÞ is a finite or infinite sequence t ¼ hs 1 ; s 2 ; . . .i of states of T such that, for any s i ; s iþ1 in the sequence, s i À! l s iþ1 in T for some l 2 A.
Then, the satisfaction relation is defined as follows. We write T F if and only if T; s 0 F. As will be discussed in more detail in Section 4.1, we need to formalize the situation in which the metalevel "simulates" the behaviors of the object level. It is well known that if T 0 simulates T , then T 0 satisfies all of the LTL formulae that are satisfied by T ( [26], Section 7.5).

RUNNING EXAMPLE
In this paper, we will use a reconnaissance robot system [27] as a running example to illustrate our approach. The robot system is assumed to be self-adaptive: it can change its structure and behavior in response to changes in the environment. Because of the limited space here, we will focus on only a few of its functionalities: moving to a designated location, and recovering from failures. In particular, the robot's mission is to move to a designated location, and it is equipped with a functionality to recover from failures.
As illustrated in Fig. 1, the reconnaissance robot is a selfadaptive system with a three-layer architecture [13], which is a typical example of a reflective tower. The behaviors of each layer are explained as follows.
The component layer consists of components that perform the robot's tasks. Initially, the robot can move autonomously by using the "goto task" component. The environment might change at runtime, and those changes might hinder the current component from working as expected. In such a case, the component layer needs to be adapted by modifying the "goto task" component or switching it to an alternative component. For example, suppose that an obstacle appears in front of the robot, leading the "goto task" component to transition to the "Failure" state. In this case, the "goto task" component may need to be switched out for another component, i.e., the "visual following task" component, to follow behind another robot. Fig. 2 shows the alternative behavior specifications available in the component layer: the "goto task" and "visual following task" components. The adaptation of the component layer is controlled by a meta layer, called the change management layer.
The change management layer is responsible for controlling the component layer. This layer consists of a change management component, whose initial behavior is shown on the lefthand side of Fig. 3, "before evolution." Initially, the change management component monitors the component layer and tries to recover when it detects a failure in the goto task component. Note that the "@" symbol denotes the current state of the layer under control. The transition with the guard condition "goto task@Failure" means that the goto task component's state has become "Failure" (as shown on the left side of Fig. 2). The "recovered" transition means that the recovery has succeeded. In this case, the change management component changes the goto task component's state from "Failure" to "Moving" so that it can resume its task. The "recovery failed" transition means that the recovery failed. In this case, the initial behavior of the change management component no longer works and should be evolved. Such an evolution of the change management layer is controlled by another meta layer, called the goal management layer.
The goal management layer is responsible for controlling the change management layer. It evolves the change management layer's behavior to achieve alternative goals. It   consists of a goal management component, whose behavior is shown in Fig. 4. When the change management component's state has become "Recovery failed," the goal management component evolves it by changing its behavior from "before evolution" to "after evolution," as shown on the right side of Fig. 3. After this evolution, the change management component tries to apply another management strategy to the component layer: it triggers the "change components" transition to replace the goto task component with the visual following task component.

MODELING OF REFLECTIVE TOWER BY USING MLTS
In this section, we introduce a metalevel labeled transition system (MLTS), which is an extension to an LTS to support reflection, and we explain how to model a reflective tower with an MLTS. Our approach has three features: In the MLTS, a metalevel model deals with objectlevel models as data, and it can access and change that data to enable self-inspection and modification. A reflective tower can be modeled using an MLTS, which enables hierarchical modeling of reflective systems. Existing state reduction techniques for an LTS can also be applied to MLTSs and reflective towers.

MLTS: Metalevel Labeled Transition System
We extend an LTS to support reflection in two steps. First, we propose an extended labeled transition system (ELTS), which is an LTS extension for handling data. Then, we propose the MLTS, an ELTS extension that enables other ELTSs to be treated as data in order to model a reflective tower. Self-inspection and self-modification are achieved by allowing an MLTS of one layer to access and modify the data representing the MLTSs of lower layers.

ELTS Definition
Here, we define the ELTS and its parallel composition, and we show that an ELTS can be treated as an LTS. where S is a set of states, A is a set of action labels, D is a nonempty set of data handled by E, TS S Â 2 D Â A Â D D Â S is a set of transition specifications, s 0 2 S is the initial state, d 0 2 D is the initial data, AP is a set of atomic propositions, and L : S Â D ! 2 AP is a labeling function.
The rationale for the definition's structure, specifically that of TS, is as follows. As will be explained later, we can regard E as equivalent to an LTS whose state is a pair ðs; dÞ, where s 2 S; d 2 D. Therefore, the transition specifications in TS and the labeling function L depend on both s and d. In more detail, consider a transition specification t ¼ ðs; G; l; e; s 0 Þ 2 TS S Â 2 D Â A Â D D Â S. This implies that G 2 2 D and e 2 D D . Therefore, G is a subset of D, and e : D ! D is a function to update data. Here, t specifies the following transition. If the state is s and the data is d 2 Gð DÞ, then a transition with the label l can be triggered. 1 After the transition is triggered, a data-update function e changes data d to eðdÞ 2 D, and the state changes to s 0 . As for the labeling function, Lðs; dÞ is the set of atomic propositions that are true if the current state is s and the current data is d.
As an example, Fig. 5 shows ELTSs for a simple timer system. 2 ELTS E a has a natural number n representing a counter as D, and which is updated by using the data update function e a . Specifically, E a ¼ fS a ; A a ; D a ; TS a ; s a 0 ; d a 0 ; AP a ; L a g is defined as follows. S a ¼ fWorking1; Stoppedg A a ¼ ftick; stopg D a ¼ N TS a ¼ fðWorking1; fn 2 N jn > 0g; tick; e : n 7 ! n À1; Working1Þ; ðWorking1; f0g; stop; e : n 7 ! n; StoppedÞg s a 0 ¼ Working1 d a 0 ¼ n 0 2 N AP a ¼ fg L a : S a ! 2 AP a is a function whose value is the empty set Next, we define a parallel composition of two ELTSs that involve the same set of data in a "consistent" way.
, and e ¼ e 0 for any ðs 1 ; G; l; e; s 2 Þ 2 TS; ðs 1 ; 0 G; 0 l; 0 e; 0 s 0 2 Þ 2 TS 0 such that l ¼ l 0 . Then, the parallel composition EjjE 0 ¼ ðS jj ; A jj ; D jj ; TS jj ; s jj0 ; d jj0 ; AP jj ; L jj Þ is defined as follows.  1. Thus, G represents this transition's guard condition. 2. Here, we use the simple timer example instead of the running example described in Section 3, because we soon demonstrate how an ELTS handles data shortly. In the running example, the data represents an object level, and we will thus use that example to explain the MLTS in Section 4.1.2. D jj ¼ Dð¼ D 0 Þ TS jj ¼ fððs 1 ; sÞ; G; l; e; ðs 2 ; sÞÞj ðs 1 ; G; l; e; s 2 Þ 2 TS^l 2 ðA n A 0 Þg [fððs; s 0 1 Þ; G; 0 l; 0 e; 0 ðs; s 0 2 ÞÞj ðs 1 ; 0 G; 0 l; 0 e; 0 s 0 2 Þ 2 TS 0^l 2 ðA 0 n AÞg [fððs 1 ; s 0 1 Þ; G \ G; 0 l; e; ðs 2 ; 0 s 0 2 ÞÞj ðs 1 ; G; l; e; s 2 Þ 2 TS^ðs 1 ; 0 G; 0 l; e; 0 s 0 2 Þ 2 TS 0 g Specifically, a state of the parallel composition EjjE 0 is a pair of a state of E and a state of E 0 . In particular, the definition of TS jj may look complicated. It simply means that a transition of the parallel composition EjjE 0 represents either an asynchronous transition of E that does not change the state and the data of E 0 , an asynchronous transition of E 0 , or a synchronous transition that changes the states of both E and E 0 . Although the definition indicates that the synchronous transition changes the data by using the data-update function e of E, we have the same result with e 0 because e ¼ e 0 according to the assumptions in the definition. We say that the ELTSs E and E 0 are composable if they satisfy the assumptions of Definition 6. Note that the second assumption of composability represents the "consistency" of the data-update function, meaning that the synchronous transitions update data in the same way. For example, E a jjE b shown in Fig. 5 Finally, we show that an ELTS can be treated as an LTS by tailoring the data and the data-update function to states and transitions. Intuitively, T ðEÞ's states are represented as superpositions of ELTS states and data, and T ðEÞ's transitions occur between two of these superpositions.
In contrast, an LTS T can be viewed as an ELTS EðT Þ for which its set of data D is fÃg (i.e., a set with only one element "Ã"), TS ¼ fðs; D; l; e; s 0 Þjs À! l s 0^e ðÃÞ ¼ Ãg, the initial state s 0 is the same as in T , the initial data d 0 ¼ Ã, and the value of the labeling function Lððs; ÃÞÞ is the same as LðsÞ for the labeling function L of T . We can see that T ðEðT ÞÞ is an LTS that is equivalent to T , because the ELTS allows only a transition of the form ðs; ÃÞ À! l ðs; 0 ÃÞ, which can be regarded as the transition s À! l s 0 of T .
Next, we show that the LTS creation operation T can be applied to a parallel composition of two ELTSs by using bisimilarity. Note that the relation R from the set S T 1 of the states of LTS T 1 to the set S T 2 of the states of T 2 is a bisimulation between T 1 and T 2 if it is a simulation relation from T 1 to T 2 and its inverse R À1 is a simulation relation from T 2 to T 1 . Two LTSs that have a bisimulation relation are called bisimilar.
Theorem 8. For any two composable ELTSs, E 1 and E 2 , T ðE 1 jjE 2 Þ and T ðE 1 ÞjjT ðE 2 Þ are bisimilar. 3,4 We can prove this by defining the relation R from the set of states of T ðE 1 jjE 2 Þ to the set of states of T ðE 1 Þjj T ðE 2 Þ-that is, from ðS E 1 Â DÞ Â ðS E 2 Â DÞ to ðS E 1 Â S E 2 Þ ÂD-by using fðððs 1 ; dÞ; ðs 2 ; dÞÞ; ððs 1 ; s 2 Þ; dÞÞjs 1 2 S E 1^s 2 2 S E 2^d 2 Dg and examining whether it is a bisimulation relation. This relation means that each state of T ðE 1 ÞjjT ðE 2 Þ whose components have the same data corresponds to the state of T ðE 1 jjE 2 Þ with the same states of E 1 ; E 2 and the same data.

MLTS Definition
Here, we define the MLTS based on the ELTS definition. The data of an MLTS consists of state level information on other ELTSs. D fðE; s; dÞjE 2 E^s is a state of E^d is data of Egg; that is, D is the set of tuples of an ELTS, its current state, and its current data.
Intuitively, an MLTS corresponds to a metalevel behavior, and its set E of ELTSs corresponds to all alternative object-level behaviors that are managed by the metalevel. An MLTS modifies the object level by updating D.
For example, we can model the change management component on the right side of Fig. 3 as an MLTS. Let E and E 0 be the ELTS models of the goto task and the visual following task, respectively. The change management layer is modeled as an MLTS M C ¼ ðS C ; A C ; D C ; TS C ; s C0 ; d C0 ; AP C ; L C Þ with the following constructs. Recall that that the symbol "*" represents the data used to indicate that an LTS is considered to be an ELTS, as explained before. ÃÞ e C ðd C0 Þ ¼ ðE; 0 Following; ÃÞ s C0 ¼ Recovery failed AP C is the empty set L C : S C ! 2 AP C is a function whose value is the empty set. The transition specification ðRecovery failed; fd C0 g; change components; e C ; Working2Þ represents a transition that causes changes in the components in the component layer. In detail, if the current state and the data are "Recovery failed" and d C0 , respectively, this transition can be triggered because d C0 2 fd C0 g. After the triggering of this transition, the state changes to "Working2" and the data changes to e C ðd C0 Þ ¼ ðE; 0 Following; ÃÞ. The change to the data means that E changes to E 0 and the state of E 0 is set to "Failure".

Modeling of MLTS-Based Reflective Tower
A reflective tower can be modeled by using an MLTS. Given an MLTS M on E , any ELTS E 2 E can be an MLTS, because an MLTS is a kind of ELTS. This treatment leads to the following layer structure, which can be considered an MLTSbased reflective tower. 5 Definition 10. For a positive integer n, we define a reflective tower with n layers, or an n-layer reflective tower, as follows.
A 1-layer reflective tower is an ELTS that has only one piece of data, "Ã," and only transition specifications with a guard of fÃg. This means that the ELTS is EðT Þ for some LTS T . An MLTS M is an ðn þ 1Þ-layer reflective tower on E 1 ; E 2 ; . . . ; E n if and only if the following conditions hold.
As a result, a reflective tower has a layer structure. For example, the robot application illustrated in Fig. 1  Moving; ÃÞÞ AP G is the empty set L G : S G ! 2 AP G is a function whose value is the empty set. An MLTS-based reflective tower supports both selfinspection and self-modification. The self-inspection is achieved via data D of an MLTS on each layer. For example, D G in the goal management component's MLTS includes the data representation of the change management component. In D G , M 0 C and M C are MLTSs of the change management components' behaviors illustrated in Fig. 3, where the definition of M C is the one given in Section 4.1.2. Each layer can access information about the structure and behavior of the lower layer through D. The change management component can be regarded as a 2-layer reflective tower M C (or M 0 C ) on E 1 . It manages the two components in the component layer: the goto task and the visual following task, i.e., E and E 0 in Section 4.1.2.
Similarly, the self-modification is achieved through triggered changes to the data by using the data-update function e. For example, TS G , which is the set of transitions of the goal management component, includes the "change" transition from the "Before change" state to the "After change" state attached with the data-update function e G , which will modify the change management layer's behavior from M 0 C (corresponding to the left model in Fig. 3) to M C (the right model in Fig. 3). Note that the data-update function separates the details of lower-layer modifications from the local behaviors in each layer: the local behaviors are represented as states and state transitions, whereas the lower-layer modifications are represented as data and data-update functions. The advantage of this separation-of-concerns will be discussed in Section 7.3.1.

Treating of MLTS-Based Reflective Tower as LTS
As an MLTS is treated as an LTS, an MLTS-based reflective tower is also treated as an LTS. For a 1-layer reflective tower, i.e., an ELTS E, T Ã ðEÞ is T ðEÞ.
i¼1 AP E i . Note that, for each i ¼ 1; 2; . . . ; n, all Es in E i have the same set of atomic propositions AP E i , from the definition of an MLTS; and -L Ã ðs; ðE; s; 0 d 0 ÞÞ ¼ Lðs; ðE; s; 0 d 0 ÞÞ [ L Ã E ðs; 0 d 0 Þ, where L Ã E is the labeling function of T Ã ðEÞ. Intuitively, the local behaviors in each layer and the reflections in an MLTS-based reflective tower are merged into transitions in an LTS T Ã ðMÞ: the second condition in the second bullet point is for reflection, and the third condition is for the local behaviors.
The atomic propositions and labeling functions in each layer are also merged. The fourth and fifth conditions indicate that an atomic proposition holds if it holds in the state of one of the layers. For example, let AP E and L E be the set of atomic propositions and the labeling function shared in the component layer ELTSs E and E 0 ; they are defined as follows.
Here, the atomic proposition "operating" in the component-layer ELTSs holds if and only if the state of the component layer is not "Failure." Then, AP Ã and L Ã of T Ã ðMÞ can be identified as follows: As for L, e.g., Similarly, for the "Failure" state, the value of L Ã is the empty set. Note that, for example, C Þ, and similarly for the other subscripts. In summary, this reflective tower treats "operating" as an atomic proposition and its satisfaction relies on the component layer.
Finally, we define the satisfaction relation between a reflective tower M and an LTL formula using T Ã ðMÞ.
Definition 12. Let M be a reflective tower and F be an LTL formula whose atomic propositions are in AP Ã of T Ã ðMÞ. Then, For example, t uð:operating ! ÅoperatingÞ is an LTL formula that the robot system is required to satisfy.

State-Space Reduction for MLTS
Next, we show that symmetry reduction and DS stutter bisimulation ( [26], Section 7.8.1), which are state reduction techniques for an LTS, are also applicable to an MLTS and a reflective tower.

Symmetry Reduction
Symmetry reduction [25] is a well-known state reduction technique based on a symmetry relationship between states. Symmetry reduction chooses a state from a set of states that can be seen as "symmetric." Here, we explain the meaning of "symmetric" in this context as follows. Suppose that, for an LTS T , if we exchange two states s and s 0 , the resulting LTS is isomorphic to T . Then, we can see s and s 0 as symmetric. Reference [25] and similar works in the literature formalize this idea by using a group G that acts on the set of states. Here, "act" specifically means that we have a function from G Â S to S that maps ðs; sÞ to ss and is compatible with the group structure of G. Then, for some s 2 G, s 0 ¼ ss and s ¼ s À1 ðs 0 Þ.
This symmetry reduction technique defined in [25] was designed for an LTS, whose behaviors are represented only by states and transitions. Here, we show that symmetry reduction can also be applied to MLTS. An MLTS includes both metalevel behaviors represented by states and transitions and object-level behaviors represented by data and data-update functions. Here, we first apply symmetry reduction to an ELTS, and then extend it to an MLTS-based reflective tower.
Symmetry Reduction for ELTS First, we define symmetry reduction for an ELTS in a similar way as in [25]. Note that, if the first condition holds, ðs 1 ; dÞ À! l ðs 2 ; dÞ if and only if ðss 1 ; dÞ À! l ðss 2 ; dÞ because d 2 G. Thus, G can be seen as a symmetry group of T ðEÞ by defining sðs; dÞ as ðss; dÞ. Using a symmetry group, we can formally define the set of states that are symmetric. Then, we can choose one state from each such set and gather the chosen states to create a set with a reduced number of states.
Let G be a group acting on the set S. We say that s and s 0 are in the same orbit if and only if there exists s 2 G such that ss ¼ s 0 . We can prove the validity of symmetry reduction for ELTSs in the same way as in [25]. and a symmetry group G acting on S, let be a representative function corresponding to G. Then, is a bisimulation.
In addition, by the second condition in the definition of symmetry group, the representative function preserves the truth values of atomic propositions for each state. Therefore, also preserves the satisfaction of LTL formulae.
Next, we can give a specific notion of symmetry reduction for parallel composition in the same way as in [29]. Let E 1 ; E 2 ; . . . ; E n be composable ELTSs, where E i ¼ ðS i ; A i ; D i ; TS i ; s i0 ; d i0 ; AP i ; L i Þ, E jj ¼ E 1 jj . . . jjE n ¼ ðS jj ; A jj ; D jj ; TS jj ; s jj0 ; d jj0 ; AP jj ; L jj Þ, and G n is a group of permutations of f1; . . . ; ng. Then, we can regard G n as a symmetry group for E jj by considering each s 2 G n and defining sðs 1 ; . . . ; ; s n Þ ¼ ðs sð1Þ ; . . . ; s sðnÞ Þ if this is also a state of E jj .
Symmetry Reduction for Reflective Tower We can define symmetry reduction for an MLTS-based reflective tower as an extension of the ELTS symmetry reduction above. First, we informally explain the definition as follows.
The basic idea is to combine a symmetry group of the toplayer MLTS M and a symmetry group for each ELTS in the lower layers. By doing so, we can build a symmetry group G Ã for the entire structure of the reflective tower. In detail, each element s Ã of G Ã is a tuple ðs M ; s E ; . . .Þ of the elements of the symmetry groups of M and the ELTSs, such as E, in the lower layers. This s Ã acts on a state of the tower in the following way. Each state of the tower consists of states of M and the lower-layer ELTSs. Here, s M and each s E acts on the states of M and a lower-layer ELTS E, respectively. Formally, a state of the reflective tower is represented as ðs; ðE; s; 0 . . .ÞÞ, where s, and s 0 are a state of M and a state of E, respectively. The action of s Ã turns this state into ðs M s; ðE; s E s; 0 . . .ÞÞ.
However, even if we provide a valid symmetry group for each ELTS, self-modification by reflection may change the lower layer, and the validity may be violated. If an ELTS in a lower layer is changed to another, the corresponding transition induced by the symmetry groups may disappear. Therefore, we need constraints on the elements of a symmetry group in order to preserve transitions.
Definition 16. Let M nþ1 be an ðn þ 1Þ-layer reflective tower on E 1 ; E 2 ; . . . ; E n and G M nþ1 and G M i be symmetry groups of M nþ1 and each E i 2 E i ði ¼ 1; 2; . . . ; nÞ, respectively. Let We define an action of G Ã M nþ1 on the set of states of T Ã ðM nþ1 Þ by induction on n (including 0) as follows.
The definition of the action of G Ã M nþ2 on T Ã ðM nþ2 Þ can be divided into two parts, namely, for M nþ2 and for the lower layers. By the induction hypothesis, is composed by the following two types of components: Among these four conditions, the first two correspond to the definition of a symmetry group of ELTS (Definition 13). The last two conditions are specific to a reflective tower. The third condition ensures that either d 2 G or not; that is, it ensures that the results of self-monitoring are the same for the symmetry states. Finally, the fourth condition ensures that the results of self-modification are the same for transitions starting from symmetry states.
Proof: For a transition of T Ã ðM nþ1 Þ, there are two cases as follows. The first case involve self-modification, and the second involves simulation of the lower layer.
is a transition specification of M nþ1 where G and e are the guard condition and the data update function, respectively, and Because we can show the inverse direction by tracing this reasoning in the opposite direction, this is equivalent to ðs; ðM nþ1 ; s 1 ; 0 d 0 1 ÞÞ À! l ðs; ðM nþ1 ; s 2 ; 0 d 0 2 ÞÞ. This means that the symmetry group condition for transitions holds. Finally, the last condition for this theorem is exactly the condition for the labeling function.
We can define a representative function Ã M nþ1 of G Ã M nþ1 by induction on n (including 0) as follows. Our definition requires representative functions M nþ1 of G M nþ1 and E i of G E i for each E i 2 E i ði ¼ 1; . . . ; nÞ. We build Ã M nþ1 by combining these functions.
We prove this theorem by induction on n (including 0).
If n ¼ 0 and s is a state of M 1 , then s and M 1 ðsÞ are in the same orbit. Therefore, there exists and s Ã M nþ1 be the tuples whose components were described in the previous paragraph. Then, 1 Þ, which means s 1 and s 2 are in the same orbit, and ðs 1 ; 0 d 0 1 Þ and ðs 2 ; 0 d 0 2 Þ are in the same orbit. By the induction hypothesis, In Section 6, we will apply symmetry reduction to an example of a reflective tower.

DS Stutter Bisimulation
Another LTS concept that can be applied to our approach is divergence-sensitive (DS) stutter bisimulation ( [26], Section 7.8.1). First, we define the notion of R-divergence.
In short, a divergent state has an infinite path that starts from it and has states in the same equivalence class. Next, we define DS stutter bisimulation for ELTSs.
. . . ; n À 1, and ðs 2 ; d 2 ÞRðs n ; 0 d 0 n Þ. In addition, this condition holds if we exchange the components of E and E 0 .
When these conditions hold, T ðEÞ and T ðE 0 Þ clearly satisfy the conditions of DS stutter bisimulation as described by Baier and Katoen ([26], Section 7.8.1). Note that a DS stutter bisimulation relation preserves properties expressed in LTL without using the "next" operator; that is, E and E 0 satisfy the same LTL formulae without the "next" operator.
DS stutter bisimulation reduces states according to the stutter bisimilarity defined in the second item of Definition 20. Briefly speaking, two systems are DS stutter bisimilar if (1) their behaviors are the same or (2) a state in one system corresponds to a sequence of transitions in the other as long as the satisfaction of properties is not affected when the state is replaced with the sequence or vice versa. 6. Because the action of G Ã M nþ2 does not change the lower-layer ELTS, we can use the same M nþ1 . DS stutter bisimulation can also be applied to reflective towers by using T Ã instead of T : the definition is obtained by changing the components of T ðEÞ to T Ã ðMÞ in Definition 20.

MODEL CHECKING OF REFLECTIVE TOWER WITH SPIN
In this section, we explain two strategies for implementing an MLTS to represent a reflective tower in Promela. A Promela process consists of variable declarations, value assignments to variables, inter-process communications, and control structures. Typically, a system whose behavior is modeled as a parallel composition of LTSs can be implemented as a set of Promela processes: the LTSs are implemented as Promela processes, and the parallel composition is implemented by using inter-process communications. However, Promela processes and the concurrent executions via the inter-process communications should be statically defined. Accordingly, such an implementation approach cannot handle reflection, because lower-level ELTSs may change dynamically. Note that Promela has limited support for reflection: we can add C code blocks, which can monitor and modify the state space, the current state, and the transition relation. However, it is limited to two-layer reflection, and a customized strategy is necessary to implement a reflective tower in Promela. Hence, we implement a reflective tower as a Promela process that simulates all in-layer behaviors and reflections across layers. We devise two translation strategies.
The first strategy, called the simple strategy, represents the states and transitions in a reflective tower as data (specifically, as arrays of symbols) in Promela. A transition that changes a lower level is represented via changes to the arrays' values. The second strategy, called the ELTS-based strategy, transforms an n-layer reflective tower M on E 1 ; E 2 ; . . . ; E nÀ1 into a simple ELTS E whose states and transitions represent all the states and transitions in M and E 1 ; E 2 ; . . . ; E nÀ1 . All possible changes due to reflection in M are tailored and merged into E. Then, E is implemented in Promela by using the existing LTS implementation technique for Promela.

Simple Strategy
The main idea of this strategy is to represent object-level ELTSs as data arrays so that a metalevel can change them at runtime. For reflection, the simple strategy uses the arrays to represent the states and transitions of all processes in a reflective tower. It is based on a typical LTS implementation strategy in Promela. 7

Implementation Details
The simple strategy introduces the notion of a sequential process, which is an ELTS (or MLTS) expressed only in terms of states and transitions without parallel compositions. An ELTS E can be represented in the form E 1 jjE 2 jj . . . E n , where E i is a sequential process. For a reflective tower, each level can be regarded as a set of sequential processes. For readability, we explain this strategy in a semiformal way here The simple strategy translates a reflective tower into Promela. A reflective tower M on E 1 ; E 2 ; . . . ; E n is regarded as a parallel composition of sequential processes. Hereafter, we suppose that M is represented as M 1 jjM 2 jj . . . jjM k , where the M i ði ¼ 1; . . . ; kÞ are sequential processes. In addition, each lower layer E j is represented as a parallel composition of sequential processes.
The implementation consists of three steps: (1) implement data arrays, (2) initialize the data arrays, and (3) implement transitions with the data arrays.
(1) Implement data arrays First, the sequential processes are encoded as data arrays so that the metalevel can change them. The simple strategy introduces one data array for the sequential processes' states and additional data arrays for the transitions.
The simple strategy determines the states of a reflective tower as the states of sequential processes. We declare an array current to represent the current states of all sequential processes. Here, current[i] represents the current state of a sequential process, which is a sequential process either of M or of E j . State changes in the reflective tower are represented by changing the value of current's element. The number of elements in current is determined by the total number of sequential components. Here, suppose each lower layer consisting of an ELTS E 2 E i is represented as E's sequential processes E j ðj ¼ 1; 2; . . . ; m l Þ. Then, the number of elements in current is n p ¼ k þ S n l¼1 m l . This strategy also encodes the structural aspects of transitions as data arrays. For each state s of a sequential process, we declare two arrays s_targets and s_labels to represent the respective target states and labels of transitions starting from s. Then, s_targets[i] and s_labels [i] respectively represent the target state and the label of the i þ 1th transition starting from s. Transitions may be added or removed by a higher-level MLTS. Thus, developers need to determine the maximum number of transitions starting from s by analyzing its meta-levels to define the size of the arrays. In general, it is not easy to determine this maximum number; however, we do not need the exact number. Rather, it is sufficient to specify a number that is considered large enough according to experience. Let tðsÞ be the maximum number of transitions starting from s, and the number of elements in both s_targets and s_labels is defined as tðsÞ. If tðsÞ ¼ 1, we do not need to use arrays and can simply declare variables s_targets and s_labels instead.
In conventional implementations of similar transition models in Promela, a Promela process declared by the keyword proctype implements each process that is a component of a parallel composition. However, we cannot change the behaviors of the process in this case. Instead, we "encode" each sequential process into the data structures described above and change them from the metalevel.
The reconnaissance robot example has three sequential processes, which model each of the three layers. Therefore, the array current has three elements. We also have two arrays, moving_targets and moving_labels, for the "Moving" state of the goto task. Each has two elements for the two transitions, "move" and "fail." We also have two 7. The strategy was presented in the RERS Challenge 2019 held at TACAS 2019: http://rers-challenge.org/2019/index.php?page¼parallelP variables, recovery_failed_targets and recover-y_failed_labels, for the "Recovery failed" state of the change management layer.
(2) Initialize data arrays The next step is to initialize the arrays defined in step (1). current s _targets and s_labels for each state s We initialize the current array with the following assignment statements.
. . . current[j 0 ] = s 0 j 0 ; . . . Next, we initialize information about transitions. For each state s, we initialize the arrays or the variables s_targets and s_labels with the initial targets and labels of the transitions starting from s.
For the robot example, a reflective tower consists of four sequential process ELTSs: the goto task, visual following task, change management, and goal management components. Thus, we have the following initialization assignments for the state of each sequential process. and moving_label[0] correspond to the "move" transition from and to the "Moving" state of the goto task component illustrated in Fig. 2, and moving_target [1] and moving_label [1] correspond to the "fail" transition from the "Moving" state to the "Failure" state.
(3) Implement transitions The next step is to implement the behavioral aspects of the transitions. For each state s and i ¼ 1; . . . ; tðsÞ, we respectively initialize s_target[i À 1] and s_labels[i À 1] with the target and the label of the ith transition starting from s.
The simple strategy uses Promela's nondeterministic execution mechanism. Our implementation lists up all possible transitions for each state. In the analysis, the Promela model checker nondeterministically chooses one of the possible transitions and triggers it. The nondeterministic executions are expressed in Promela by using the if or do keyword. For example, according to the semantics of Promela, the code if :: (Promela code) . . . :: (Promela code) fi represents the following behavior 8 : The first statement of each code fragment starting from a double-colon, ::, is called a guard and is a Boolean expression. One of the :: fragments whose guard is true is nondeterministically chosen and executed. If there are no such fragments, a deadlock occurs. When if is replaced with do, the choices and executions are repeated until a deadlock occurs or the break instruction is executed.
In the simple strategy, the overall structure in Promela is a do loop whose branches implement the transitions. The strategy first chooses an action label and then determines which sequential process can trigger the transition that synchronizes with it. Therefore, we implement transitions as do branches for each action label l 2 A. The details of the implementation of each transition are as follows.
Step 1 Let E 1 ; . . . ; E n 1 be sequential-process ELTSs that have l as their action label. For each j ¼ 1; . . . ; n 1 , let s j and ðs j ; 0 G j ; l; e j ; s 00 j Þ be a state and a transition specification, respectively, of E j , and let g j be a Boolean expression indicating whether the current data is in G j . Then, we implement one do branch for each combination k 1 ; . . . ; k n 1 where 0 k j < tðs j Þðj ¼ 1; . . . ; n 1 Þ; that is, k j is a nonnegative integer that is less than the maximum number of transitions starting from s j .
Step 2 The following Boolean expression appears as the guard of this do branch.
..&& s n 1 _labels [k n 1 ] == l && g 1 && g n 1 -> A true value for this expression indicates that the current states are the sources of the transitions, the label of the transitions is l, and all guards hold.
Step 3 The statements after the guard represent the dataupdate function e for the data d and the updates of the current states. For each ELTS sequential process in the first level, statements to update d to eðdÞ are created. For each MLTS sequential process in a level higher than the first, let d be ðE; 0 s; d 0 Þ, E 0 ¼ E 0 1 jj . . . jjE 0 n 0 , eðE; 0 s; d 0 Þ ¼ ðE; 00 s; 0 d 00 Þ, and let s 0 ¼ ðs 1 ; . . . ; s n 0 Þ. Then, the following statements are implemented.
Statements that update E 0 to E 00 . We can implement this update by changing the values of (some state)_target and (some state)_labels.
Statements that update the current states of the E 0 j , i.e., current[(index of E 0 j )] = s j ; for each j ¼ 1; . . . ; n 0 . Statements that update d 0 .
Finally, the statements that update the current states of the E j for j ¼ 1; . . . ; n 1 have the form current[(index of E j )] = s 00 j ;. Note that Step (3) implements changes in the lower level through the data representation, specifically, by changing the values of the data arrays. 8. For more details, see http://spinroot.com/spin/Man/if.html.
For the robot example, we can implement the "change components" transition of the change management component, which monitors and modifies the component layer by reflection, as follows. Here, line 1 is a guard condition of the transition. This transition is triggered according to the state not only of the change management component but also of the component layer. The condition in parentheses indicates whether the goto task is operating. Lines 2 and 3 represent self-modification due to the transition: it deactivates the goto task and activates the visual following task by configuring its current state to the " Following" state. Line 4 changes the state of the change management layer to "Working2."

Implementation Correctness
Next, we show the correctness of the above implementation. To validate its correctness as a transition system, the initialization and transitions should be the same as those of the original reflective tower. For the initialization, the Promela code starts with the initial state of the reflective tower model, as explained in Section 5.1.1. As for the transitions, we prove the following theorem that claims the correctness.
Theorem 21. For each state s of a reflective tower M on E 1 ; E 2 ; . . . ; E n , there is a one-to-one correspondence between a transition of T Ã ðMÞ and a do branch starting from a Boolean expression in Promela. In addition, each transition specification and its corresponding branch represent the same behavior.
The proof is in Appendix A, available in the online supplemental material.

Property Specification in LTL
Generally, an LTL formula in Promela consists of temporal operators, Boolean operators, and Boolean expressions. For example, the temporal operators include "always" ("[]") and "eventually" ("<>"), and the Boolean operators include "and" ("&&") and "or" ("||"). Any Boolean expression can be an atomic proposition. In the simple strategy, an atomic proposition claiming that the current state of an ELTS is a specific state s becomes true when the corresponding value of the current array becomes s, and becomes false when it becomes a state other than s.
For  ) indicates that either the state of the goto task component is "Moving" or the state of the visual following task component is "Following." Therefore, this Boolean expression represents the atomic proposition "operating" that was described in Section 4.2.

Counterexample Analysis
We encode a reflective tower with lower-level ELTSs into one Promela process to simulate transitions on different levels and self-modification across the levels. The counterexamples produced by SPIN contains a mixture of local state transitions in each layer and changes due to selfmodification.
To help developers by distinguishing these, we use Promela's logging functionality to embed logs related to a reflective tower in the counterexamples. Specifically, we use two different types of printf instructions and insert them in each code fragment representing a transition, i.e., a branch of a do loop. These logging instructions can produce logs of a local state transition or self-modification in a reflective tower.
> process 0 modified from failure to 0 > process 1 modified from 0 to following > process 2 changed recovery_failed to working2 The first and second logs including "modified" indicate that the component layer, whose state is represented as current[0] and current [1] respectively, was modified due to a self-modification. Intuitively, this self-modification deactivates the goto task component by substituting 0 to current[0] and activate the visual following task component by substituting "following" to current [1]. The third log including "changed" indicates that the change management layer, whose is represented as current [2], was changed by its local transition. This log corresponds to a local state transition in the change management layer, as illustrated in the right model of Fig. 3, rather than self-modification from the left to the right model of Fig. 3, because a "changed" log is for a local state transition. Such logs can help developers to analyze reflective towers.
Embedding the log instructions can be automated. As explained in Section 5.1.1, the simple strategy generates an if block for each transition specification of sequential process ELTS, and the guard of the if block includes an expression about a label of the transition specification. The automation steps are as follows.

1) Identify an ELTS having the transition label used in
the guard. Suppose the index i of the current array corresponds to the ELTS. 2) For all assignment statements of current array in the if block, insert a "changed" log statement if the assignment statement is for current[i], and insert a "modified" log statement otherwise. The former case in the second step indicates that the state change is caused by a local transition in the ELTS, and the latter case indicates that it is caused by self-modification triggered by a transition in its meta-level.

ELTS-Based Strategy
In the second strategy, called the ELTS-based strategy, a reflective tower is translated into a simple ELTS whose behavior is equivalent to the original MLTS. The original reflective tower includes metalevel behavior as states and transitions and lower-level behaviors as data. This strategy encodes the states and transitions in all layers into the states and internal transitions of one simple ELTS. Even if the metalevel evolves the lower levels, the behaviors before and after evolution are encoded in the ELTS, which is translated into a Promela process.

Translate Reflective Tower into ELTS
This strategy transforms a reflective tower M on E 1 ; E 2 ; . . . ; E n into a simple ELTS EðMÞ. The transformation is similar to the construction of T Ã ðMÞ described in Definition 11. 9 For the robot example, the reflective tower model M G of the goal management layer on E 1 and E 2 , including the ELTSs representing the change management and component layers, respectively, is translated into a simple ELTS whose states are tuples of the ELTSs and their states in all layers. For example, suppose that a state of the reflective tower is a combination of states in the three layers: "After change" in the goal management layer, "Recovery failed" in the change management layer, and "Failure" in the component layer. These states are translated into one state in the simple ELTS as a tuple: ("After change," (M C , "Recovery failed"), (E, "Failure")), where M C and E are the models of the change management component before evolution and the goto task component.

Implement ELTS in Promela
Next, the simple ELTS EðMÞ is implemented in Promela. This strategy uses goto statements with a label in Promela to represent a transition specification in an ELTS. It introduces a label S for an ELTS state s and attaches it to an if block in Promela. 10 The implementation is as follows.
1) For each state s of EðMÞ, a label S and an if block beginning with S are created. 2) Let ðs; G; l; e; s 0 Þ be a transition specification of EðMÞ from the state s, and let S 0 be a label for the target state s 0 . A corresponding branch is created in the if block for s. The if block checks if the current state is s and contains a goto statement for each branch to specify possible transitions from the state. The following statements are generated.
S:if ::(branch) goto S' :: (guard) -> (update-statements); goto S" fi If a transition specification has a guard condition d 2 G, it is implemented in the guard of a branch. Similarly, if a transition specification has a data-update function d ¼ eðdÞ, it is implemented in update-statements. An if block can contain two or more branches, in which case one is nondeterministically chosen from the branches held by the guard.
Note that because the simple ELTS EðMÞ is generated from a reflective tower M, a state s in EðMÞ is a tuple ðs nþ1 ; ðE n ; s n ; ðE nÀ1 ; s nÀ1 ; ð. . . ; ðE 1 ; s 1 ÞÞ . . .Þ, where s nþ1 is a state of M, and each s i for i ¼ 1; 2; . . . ; n is a state of E i . A label name is determined by concatenating those names with two underscores "__". For example, for the state ("After change," (M C , "Recovery failed"), (E, "Failure")), a label after_change__cmc2__recovery_failed__gtc __ failure is created, where cmc1, cmc2, gtc, and vtc are the respective names of the change management component before evolution (M 0 c ), the change management component after evolution (M c ), the goto task component (E), and the visual following task component (E 0 ).
For the change management component in the robot example illustrated on the right in Fig. 3, the transition from "Recovery failed" to "Working2" is implemented as follows. 1 after_change__cmc2__recovery_failed__gtc__ failure:if 2 :: goto after_change__cmc2__working2__vtc__ following 3 fi As stated before, the label after_change__cmc2__ recovery_failed__vtc__failure represents a simple ELTS' state corresponding to "After change" in the goal management component, "Recovery failed" in the change management component, and "Failure" in the goto task component. Note that the visual following task is deactivated here, and thus, its name and state are not included in the label. This transition changes the change management component's state and replaces the goto task component with the visual following task. The label after_chan-ge__cmc2__working2__vtc__following represents a state corresponding to "After change" in the goal management component, "Working2" in the change management component, and "Following" in the visual following task component represented by vtc. Note that the goto task 9. Definition 22 in Appendix B, available in the online supplemental material, formally defines the simple ELTS EðMÞ of a reflective tower M.
10. This implementation with if blocks and goto statements was inspired by an implementation technique described on the official SPIN web site: http://spinroot.com/spin/Man/Exercises.html component is deactivated instead of the visual following task component, and thus, its name and state are not included in the label.

Implementation Correctness
Here, we validate the correctness of the ELTS-based strategy by showing that a generated simple ELTS has the same behavior as the original reflective tower and that the corresponding Promela implementation has the same behavior as the simple ELTS.
Regarding the first part, we claim that, for any reflective tower M, EðMÞ behaves in the same way as M. This can be formalized as the claim that T ðEðMÞÞ and T Ã ðMÞ are bisimilar. 11 In the second part for initialization, the Promela code initializes the data correctly and starts its execution from the statement with a goto label corresponding to the initial state of the ELTS. As for the transitions, first, execution of the S: if part means that the current state is s. Then, the nondeterministic choice and execution of an S:if branch corresponds to the nondeterministic choice and triggering of a transition starting from s. The branch shown above may be executed if and only if d 2 G. After it is executed, the data becomes eðdÞ, and the execution jumps to the S 0 :if block, meaning that the state changes to s 0 . This behavior conforms to that of T ðEðMÞÞ as specified in Definition 7. Thus, the implementation correctly simulates T ðEðMÞÞ, and therefore, EðMÞ as well.
We can illustrate the above discussion through the robot example. Suppose that the models of the change management component have already been transformed into ELTSs through the above procedure. For the first part of the discussion, the "change components" transition of the MLTS model of the robot from "Recovery failed" to "Working2," for example, is transformed into the following transition of the generated ELTS: ððAfter change; Recovery failed; FailureÞ; ÃÞ À! recovered ððAfter change; Working2; FollowingÞ; ÃÞ.
As for the second part, the above transition is implemented as follows. 1 after_change__cmc2__recovery_failed__gtc __failure: 2 if 3 :: goto after_change__cmc2__working2__vtc__ following 4 fi Thus, each transition of the MLTS corresponds to a transition of the generated ELTS and an if branch that is executed nondeterministically.

Property Specification in LTL
Unlike the simple strategy, in the ELTS-based strategy, there are no specific expressions representing ELTS states. To specify properties, the ELTS-based strategy introduces additional Boolean variables representing atomic propositions.
For example, consider the property addressed in Section 5.1.3, i.e., that the state of a process E whose number is i will become s an infinite number of times. Here, let p be an atomic proposition related to the property, which becomes true if the state of E is s and becomes false otherwise. Then, the property can be specified as an LTL formula [] <> p.
A corresponding Boolean variable is introduced for each atomic proposition related to a property. For example, the Promela code shown in Fig. 6 is modified to that shown in Fig. 7. The label S indicates that the state of E is s, while the label S 0 indicates otherwise. Then, the ELTS-based strategy introduces a new Boolean variable x and adds statements for updating x to if blocks with corresponding labels. These statements for x are inserted after each label. Then, x becomes 1 if and only if the state of E is s, which means that the value of x is the same as the truth value of p. We can implement the LTL formula shown above as [] <> x in Promela.
The LTL property t uð:operating ! ÅoperatingÞ mentioned in Section 4.2 uses the atomic proposition operating. The ELTS-based strategy introduces a Boolean variable x representing this atomic proposition, which becomes 1 if the state of the goto task component is "Moving" or the state of the visual following task component is "Following," and 0 otherwise. An LTL formula in Promela representing this LTL property is specified by using x as follows:[](!x -> <> x).
The ELTS-based strategy also modifies the Promela code shown in Section 5.2.1 to introduce the Boolean variable in if blocks corresponding to the atomic proposition. For example, suppose that the following the if blocks related to the atomic proposition operating have been obtained. 1 after_change__cmc2__recovery_failed__gtc__ failure:if 2 :: goto after_change__cmc2__working2__vtc__ following 3 fi 4 ...   Here, other Boolean variables y and z are also introduced: they respectively correspond to atomic propositions of the change management layer and the goal management layer. A state of a simplified ELTS obtained by the ELTS-based strategy is formed by merging all layers' states, whereas an atomic proposition used in an LTL property corresponds to a state of one layer. Although y and z are introduced for other properties related to those layers, the details are omitted here because of the space limitation.
Assignment statements for Boolean variables can be automatically inserted into appropriate positions. Suppose an atomic proposition claims that the current state of an ELTS is a specific state s. As explained in Section 5.2.1, a state of a reflective tower is represented as a label of an if block, and a label name is determined by concatenating state names of ELTSs composing a reflective tower. By checking the label name, corresponding atomic propositions and their assignment statements can be identified and attached to the label. For example, the goto label after_-change__cmc2__ recovery_failed__gtc__failure means that the states of the goal management, change management, and goto task components are "After change," "Recovery failed," and "Failure". Therefore, Boolean variables corresponding to atomic propositions related to those states can be automatically attached.
Note that this modification for atomic propositions does not affect the control flow, because it just adds the Boolean variables x, y, and z. In Section 6, we will evaluate performance of the ELTS-based strategy with this overhead by comparing it with that of the simple strategy.

Counterexample Analysis
As in simple strategy, we embed two types of printf statements in each code fragment representing a transition. In the ELTS-based strategy, state changes of ELTSs composing a reflective tower can be identified in goto statements in if blocks corresponding to transition specifications. A label name specified in goto statement is the concatenation of the current state names of the ELTSs. Therefore, by checking the difference between the label of the if block and the label specified in the goto statement, we can determine which and how ELTS states will be changed.
However, the ELTS-based strategy loses the label names after Promela transformation, even though these are necessary to determine whether the state change is caused by a local transition or self-modification. Thus, log statements need to be embedded during the Promela transformation. As explained in Section 5.2.1, the ELTS-based strategy generates an if block for each transition specification of a simple ELTS EðMÞ transformed from a reflective tower. In the EðMÞ transformation, label names of ELTSs composing the reflective tower are preserved, so we can determine from the label which ELTS in the original reflective tower triggers the transition specification.
Embedding the log instructions can be automated. Specifically, in step 2 of the ELTS-based strategy implementation explained in Section 5.2.1, the following steps are executed to embed the log statements.

1) Identify an ELTS in the original reflective tower M
corresponding to a transition label of EðMÞ. Suppose the ELTS is E i and the label is S.

2) For all goto statements in the if block, identify all
ELTSs whose states are changed and the states after the change by analyzing the difference between S and the label specified in the goto statement. 3) For all changed ELTSs, insert a "changed" log statement if it is E i , and insert a "modified" log statement otherwise. For example, as for a transition specification corresponding to the "change components" transition of the change management component, which modifies the component layer, the following Promela code will be generated. 1 after_change__cmc2__recovery_failed__gtc __ failure:if 2 :: 3 printf("process %d modified from %e to %e\n," 0, current[0], 0); 4 printf("process %d modified from %e to %e\n," 1, current [1], following); 5 printf("process %d changed from %e to %e\n," 2, current [2], working2); 6 goto after_change__cmc2__working2__ vtc__following 7 fi As explained in Section 5.2.1, an if block's label indicate that the current states of ELTSs, and a label used in goto statement indicates how these state change. Here, three state changes are identified, and corresponding log statements are inserted. By analyzing the two labels in Line 1 and 6, this transition changes the change management component state locally, and a corresponding "changed" log statement is inserted at Line 5. Similarly, this transition deactivates the goto task component (gtc) and activates the visual following task component (vtc), and corresponding "modified" log statements are inserted at Line 3 and 4. As a result, the following log information similar to that of the simple strategy is generated, which help developers to analyze changes in the reflective tower.
> process 0 modified from failure to 0 > process 1 modified from 0 to following > process 2 changed from recovery_failed to working2

CASE STUDIES
In this paper, we address two research questions related to the feasibility and scalability of our approach: RQ1: Can it model and verify a reflective tower with three or more layers? RQ2: To what extent does it scale?
We conducted two case studies aimed at answering these questions: a reconnaissance robot with a three-layer architecture and an IoT-based remote elderly monitoring system. The first case study was used mainly for examining RQ1. As described in Section 3, the reconnaissance robot is an example of a reflective tower with three layers. We thus checked whether our approach could verify such a reflective system with two or more layers. We have already demonstrated how the simplified reconnaissance robot is represented as an MLTS (Section 4.2) and how the MLTS is implemented in Promela and verified by model checking (Section 5). Accordingly, we have demonstrated that our approach can be used to model and verify a reflective tower.
We do not discuss RQ2 with the robot example here; however, for reference, we measured the following data in verifying the simplified robot example with the deadlock freedom property: (1) the number of states, (2) the amount of consumed memory, and (3) the verification time. Regarding (1), SPIN explored seven states. We performed the verification five times and calculated averages of about 133 MB for (2) and about 0.74 s for (3).
In the following, we examine RQ2 in the context of the second example. The IoT system allowed us to demonstrate the scalability of our approach by changing the number of IoT devices in it. We modeled this example as an MLTS and performed model checking with Promela code implemented according to the implementation strategies described in Section 5. 12

Dynamic Evolution of IoT-Based Remote Elderly
Monitoring System The second case study illustrates the dynamic evolution of an IoT-based remote elderly monitoring system consisting of a number of IoT devices. As well as showing the feasibility of model checking with our approach, this case study enabled us to evaluate its scalability by changing the number of IoT devices. The system monitors the daily activities of an elderly person at home by using embedded IoT devices to directly monitor the person's status. The system consists of IoT devices and a gateway. The gateway orchestrates the IoT devices, which communicate only with the gateway. 13 An IoT device can be either a motion detection sensor (hereafter, referred to as a "sensor") or an IoT-connected electric kettle (hereafter, referred to as a "kettle"). The sensor and kettle can send notifications to the gateway when a person's motion has been detected or the person has used them. A lack of notifications for a certain period would indicate that the person may be experiencing a problem.
For a dynamic evolution scenario, we tried adding a cryptographic functionality to this service. Suppose that the communication between the IoT devices and the gateway is not initially encrypted. Such an operational environment is unsafe because of security risks due to unencrypted wireless communication. Thus, the system needed to be evolved to encrypt its communications by updating the communication components used in the IoT devices and the gateway.
The evolution requirements were as follows. To ensure the service continuity, the devices' communications and other functionalities should not be stopped during evolution. If these functionalities were stopped for a period of time, an emergency situation involving the monitored person might be missed. Therefore, evolution must proceed without stopping the whole monitoring service, and it must proceed correctly; that is, the evolution requirements must be satisfied. Hence, we addressed the following four properties related to the evolution requirements.
Deadlock freedom. If a device is communicating, the communication must be eventually completed. No device may receive encrypted messages before evolution. All communications must eventually be encrypted. The evolution of such an IoT system tends to be complicated, because an evolution process-namely, a sequence of software component updates on not only the server side but also the device side-should be carefully controlled on the basis of the system's states to satisfy its evolution requirements. Weißbach et al. [30] proposed a decentralized coordination approach for dynamic evolution that proceeds as follows.
1) When a gateway receives an instruction to evolve, it first updates its communication component to support encrypted communication. Then, it forwards the evolution instruction to all IoT devices and stops communication with them until their evolutions are completed. 2) When an IoT device receives this instruction, it updates its communication component. Afterward, it sends an "updated" message to the gateway. 3) After receiving an "updated" message from an IoT device, the gateway starts encrypted communication with it. Note that the gateway asynchronously restarts communication with IoT devices whose evolutions are complete: it is thus unnecessary to stop the whole monitoring service until the all devices have been updated. The case study followed this evolution process.
However, it is difficult to determine whether this process satisfies the evolution requirements, because it consists of a sequence of update actions in the gateway and the IoT devices that are executed concurrently and asynchronously. Accordingly, we used model checking to verify that the requirements had been satisfied.

MLTS Modeling
The IoT system is a two-layer reflective tower, with an object level consisting of IoT devices and a gateway and a 12. The Promela code used in both case studies is available at https://github.com/yt3/TSE-codes 13. For simplicity, hereafter, we will refer to the system's IoT devices and the gateway simply as "devices." metalevel consisting of an evolution process that controls the devices on the object level. The evolution process of the whole system can be divided into local evolution processes working on each device (an IoT device or the gateway). We defined an MLTS for the IoT system as follows. The MLTS of the entire system is defined as M 1 jjM 2 jj . . . jjM n on E , where each MLTS M i on E represents a local evolution process on the metalevel controlling a device D i ði ¼ 1; . . . ; nÞ on the object level. Here, n is the total number of devices, including both the IoT devices and the gateway. Then, E is the set of ELTSs representing the object-level devices D 1 . . . D n , which operate asynchronously and cooperatively.
We used the following state-space reduction techniques in order to verify the evolution process with as many devices as possible. 1) We applied symmetry reduction to parallel compositions of components that had the same behavior. On the object level, all the sensors' ELTSs had the same behavior, as did all the kettles' ELTSs. The metalevel had a local evolution process for each sensor, and the corresponding MLTSs thus had the same behavior. This was also the case for the local evolutions processes of the kettles. 2) We also reduced the states of the IoT devices and the gateway after evolution by using a DS stutter bisimulation. For example, a device after evolution would encrypt data before sending a message. The states around the encryption could be reduced to one state, and the resulting model was DS stutter bisimilar to the original. This was because the evolution requirements referred to the state of a message (encrypted or not) when it was received, rather than when it was encrypted. We applied a similar reduction to the states around a decryption. 14

Feasibility of Model Checking
In the first experiment, we tested two different evolution processes: one that allows a change from no encryption to encryption during communication, and one that does not. We expected the results to show that the former was not correct and that the latter was correct.
The model checking with SPIN successfully detected a case in which a deadlock occurred during evolution because of an incorrect process at the metalevel. SPIN generated counterexamples showing that the gateway received an unencrypted message from an IoT device and then received the "updated" message from the IoT device before processing the unencrypted message. In this case, the gateway tried to decrypt the unencrypted message and a failure occurred.
Here, we describe how we analyzed the counterexamples and detected the cause of the failure for each of the two strategies to implement an MLTS in Promela.
First, we obtained the counterexample shown in Fig. 8 from the simple-strategy implementation. In this counterexample, processes 0 to 3 represent the object levels of the gateway and the three IoT devices, and processes 4 to 7 represent their local evolution processes on the metalevel. The current array represents the current states of the processes. Thus, this counterexample indicates that the first IoT device evolved after it sent an unencrypted message, and that the gateway tried to decrypt this message.
Second, the ELTS-based strategy implementation gave the counterexample shown in Fig. 9. In this counterexample, because of the space limitation, we only show the IoT devices' object level and metalevel, and we omit those of the gateway. Processes 0 to 2 represent the object levels of the three IoT devices, and processes 3 to 5 represent their metalevels. The three Boolean variables for atomic propositions (is_before_comm, encrypted, and evolved) are used for verifying LTL properties. This counterexample indicates the same failure as that indicated by the simple-strategy implementation.
So far, we have verified deadlock freedom. We can also verify LTL properties with both strategies. For the example, we can specify the properties of the remote elderly monitor system explained in Section 6.1, we can specify the properties besides deadlock freedom by using the following LTL formulae.
If a device is communicating, the communication is eventually completed: t uðsent ! Å:sentÞ, where "sent" holds if and only if a message is sent and not received. No device receives encrypted messages before evolution: t uð:evolved ! :encryptedÞ, where "evolved" holds if and only if a specified device has evolved and "encrypted" holds if and only if the device has received an encrypted message. All communications are eventually encrypted: t uðsent^evolved ! t u encryptedÞ Here, we describe how to analyze a counterexample from LTL property verification by using the first property  14. For more details, see Appendix C, available in the online supplemental material. mentioned above as an example. First, we obtained the counterexample shown in Fig. 10 from the simple-strategy implementation.
This counterexample indicates that after the first IoT device evolved, it may have become trapped in a self-loop transition at the "After decryption" state and could not complete the ongoing communication. The description "<<<<<START OF CYCLE>>>>>" indicates that the subsequent behavior was an infinite loop.
Moreover, the implementation of the ELTS-based strategy gave the counterexample shown in Fig. 11, which indicates the same situation as in the case of the simple strategy.

Scalability of Model Checking
To examine the scalability of our approach, we increased the number of devices and performed model checking. We conducted experiments based on two scenarios: a system consisting of a gateway and an increasing number of sensors, and a system consisting of a gateway and increasing numbers of kettles and sensors. The first scenario tested scalability in terms of the number of devices having the same behaviors (sensors), whereas the second scenario tested it in terms of the numbers of devices having different behaviors (sensors and kettles). In the remote elderly monitoring system, the difference between a kettle and a sensor is that the user needs to operate the kettle to make it send a signal to the gateway, whereas a sensor periodically sends signals.
To determine the effects of the two state reduction techniques (symmetry reduction and DS stutter bisimulation) described in Section 4.3 and the two implementation strategies described in Section 5, we compared eight Promela models with different combinations of features: With or without symmetry reduction; With or without DS stutter bisimulation; and Simple strategy or ELTS-based strategy.
In these experiments, we used two SPIN optimization options: partial order reduction by not using the -DNORE-DUCE option, and collapse compression by using the -DCOLLAPSE option.
We also compared our approach with the Maude model checking proposed by Tahara and et al. [31] for reference. The purpose of this was to compare the basic performance of our MLTS-based approach and the rewriting-logic-based approach, without the state reduction techniques. We used the model checker included in the original Maude tool version 2.7.1 as provided on the official Maude website. 15 We verified each feature combination five times by using a computer with eight Intel Ò Core TM i7-4770 CPUs (3.40 GHz clock speed, 15.6-GB memory, Ubuntu 18.04 64bit OS). We measured the number of explored states and calculated the average memory consumption and average verification time.
Because the results for all the four properties introduced in Section 6.1 were similar, we only present the results for the third property here (i.e., no device receives encrypted messages before evolution). Note that the graphs for the numbers of states do not include the Maude results, because it is not reasonable to compare those numbers between different model checkers. The symbols in the legends denote the following.
Maude: Implementation in Maude. BL (baseline): Implementation in Promela with the simple strategy and no state reduction techniques. T1, T2, T3: Implementation in Promela with symmetry reduction, DS stutter bisimulation, and the ELTSbased strategy, respectively. The symbol "+" indicates a combination of these techniques: for example, "T1+T2" means a combination of T1 and T2. All: Implementation in Promela with T1, T2, and T3. Figs. 12 and 13 show the results for the first scenario, in which only the number of sensors was changed. First, we compare the results of the two implementation strategies without the state reduction techniques: BL and T3 indicate the simple and ELTS-based strategies, respectively. Here, we also evaluate the impact of the two SPIN optimization options: partial order reduction and collapse compression. Fig. 12 shows no significant difference in the number of devices that could be verified between the two implementation strategies when the state reduction techniques were not used. The optimizations reduce the memory consumptions, and the number of devices that could be verified is thus slightly increased: from eight to nine for both BL and T3. However, the improvement by the optimization options is not significant. There are two possible reasons for these results. One is that partial order reduction can decrease the number of states only for multiple parallel processes, whereas our implementation uses only one process. The other reason is that collapse compression reduces the amount of information of each state and does not change the number of states.  For reference, we also compare our approach with the Maude-based approach. The results show that the baseline and Maude-based approaches did not differ significantly in terms of both the memory consumption and the verification time. The baseline was able to verify up to nine devices, and the Maude-based approach, up to seven devices.
Next, we evaluate the effect of the state reduction techniques, as shown in Fig. 13. Our approach with the state reduction techniques scaled up to verification of a system with 35 devices. Each state reduction technique made verification more efficient, and the use of both improved the efficiency even more. The results for "T1+T2" showed that verification with both techniques worked with up to 20 devices, whereas the baseline worked only up to eight devices. As for the implementation strategies, the ELTSbased implementation strategy (i.e., "T3") outperformed the simple strategy. Without the state reduction techniques, it worked with up to 28 devices. Finally, verification with all of the reduction techniques and the ELTS-based strategy was the most effective approach, as it worked with up to 35 devices. In addition, the results did not vary much when the system consisted entirely of kettles, but the kettles' more complicated behavior did increase the verification cost. Fig. 14 show the results for the second scenario, in which both the number of sensors and the number of kettles were changed. Note that the numbers of each device were kept the same for simplicity. For example, a total of 12 devices means that six kettles and six sensors were used. The results exhibit trends similar to those in Fig. 13, but the state reduction techniques were less effective.  In both scenarios, the total number of devices handled by the verification was improved by applying the state reduction techniques: the number improved from nine to 35 in the first scenario, and from six to 35 in the second scenario.

DISCUSSION
Here, we discuss both the advantages and the limitations of our approach. First, we discuss RQ1 and RQ2. After that, we address a third question, RQ3:"How convenient is the MLTS approach for specifying a reflective tower?" Finally, we describe the threats to validity.

RQ1: What Types of Reflective Systems can it
Verify?
As discussed at the beginning of Section 6, our experiments analyzed two reflective systems, each with two or more layers. We found that our approach could detect faults in a reflective tower by model checking and find defects by analyzing counterexamples. These experiments were performed on only the robot and IoT examples, but we believe that it would be possible to verify other reflective systems.
As for properties, we focused on verifying functional properties that are generally representable by LTL formulae, including reachability, safety, liveness, and scenario conformance. The case studies addressed the deadlock freedom and application-specific properties for dynamic updates.
Note that the DS stutter bisimulation brings a limitation on the properties under verification: it is applicable only for cases in which the properties under verification do not include the "next" operator represented by "X" in Promela, meaning that a property holds at every possible next state. This limitation also applies to MLTSs, because the translation of an MLTS to an LTS preserves the DS stutter bisimulation relation.

RQ2: To What Extent Does it Scale?
Here, we discuss the complexity of our reflective tower model checking and analyze the experimental results on the scalability of our approach.
A reflective tower is inherently complicated and has a large number of states because of its layer structure. Our approach performs model checking on an LTS T Ã ðMÞ obtained by transforming a reflective tower M. It is known that the explicit model checking algorithm for an LTL formula is linear with respect to the size of an LTS (including the states and the transitions) ( [26], Section 5.2.1). As for a reflective tower, the size of T Ã ðMÞ would grow exponentially in the number of layers. Note that the theoretical complexity holds for both translation strategies, because the total numbers of states and transitions in total are the same for both strategies.
Therefore, state space reduction techniques are useful to alleviate state explosion. The experimental results showed that the scalability of our model checking was improved by applying the state reduction techniques, because they reduced the number of states. Although, the complexity increased exponentially with the number of devices in many cases, we were able to verify a system comprising 35 devices by applying two state reduction techniques,  whereas only nine devices could be verified without them. Between these techniques, symmetry reduction was more effective, particularly when it was combined with transformation to ELTSs. This is because symmetry reduction works for not only the metalevel but also the object level, as stated in Section 4.3.1. Therefore, the effect of symmetry reduction reduces the sizes of the state spaces for both levels.
We also compared two implementation strategies. The experimental results showed that the ELTS-based strategy outperformed the simple strategy. The reason is that the simple strategy uses up much more memory to store the array of states and the information about transitions.
For reference, we also compared our approach with another model checking approach that supports reflection. We chose Maude for this purpose because it is representative of a rewriting-logic-based verification framework that can deal with reflection and has available model checkers. The experimental results in Section 6.4 showed that there was no significant difference in scalability between the MLTS-based verification on the SPIN model checker and Maude-based verification on the Maude model checker, without state reduction techniques. We compared these approaches without the state reduction techniques because it is not easy to align those techniques for different modeling approaches, and this issue is outside the scope of this paper. Such a comparison will be one of our future works.

RQ3: How Convenient is Model Checking With
the MLTS Approach?

Modeling of Reflective Tower
We have shown that a reflective tower can be modeled as an MLTS, which can then be translated into an LTS by applying the translation strategy. This leads to questions: Is it possible to model a reflective tower as parallel compositions of conventional LTSs that represent the components of each layer? If so, what are the advantages of our approach over that approach?
Regarding the former question, the answer is that it is possible. Generally, modeling of a reflective tower as an LTS requires engineering tricks, because the states and transitions in an LTS are static, whereas those in a reflective tower are dynamically changed by reflection. Such a dynamic update can be modeled in an LTS by following an implementation technique addressed described in an existing study [32], which merges three different concerns into one LTS model: (1) the states and transitions of an LTS before an update, (2) those of another LTS after the update, and (3) update transitions that map the states of the LTS before the update to those of the LTS after the update. Intuitively, the update transitions connect all alternative behaviors in one layer and are triggered by an upper-level LTS via parallel composition.
However, such an LTS-based approach requires developers to model and maintain a reflective tower with a huge, complicated LTS containing mixed concerns. This weakness becomes especially serious as the number of reflections increases. For example, the IoT-based remote elderly monitoring system takes three steps to update its object-level components: (1) stop sending messages, (2) add encryption and decryption, and (3) start sending messages. Intuitively, the metalevel applies three updates, namely, update1, update2, and update3, as illustrated in Fig. 15. Here, the object level has four alternative behaviors. If the object level is represented as an LTS, it includes those four behaviors and updates the transitions among them (i.e., update1, update2, and update3), as illustrated in Fig. 16. The concerns of each object-level behavior and those of the update transitions are mixed. The complexity will deteriorate if the dynamic evolution procedure becomes complicated or if the system has to support more layers. Mixed concerns will make reflective tower modeling error-prone.
In contrast, our approach separates the mixed concerns by modeling each alternative object-level behavior as E i 2 E and the update transitions as data-update functions e. The concerns of the behaviors in each layer and of the reflection between layers are clearly separated and easy to model and maintain. A data-update function e also models self-inspection and selfmodification. The former is modeled by the fact that the input to e includes the structure and the behaviors of the lower layer modeled by the elements of E, while the change of the input to e to the output of e includes modification of the lower layer.

Model Checking
Once a reflective tower is modeled as an MLTS, a Promela model can be derived according to the implementation strategy. We have introduced two different implementation strategies: the simple strategy and the ELTS-based strategy.
The two implementation strategies have different ways to represent states in Promela. Thus, a counterexample generated by the SPIN model checker has a slightly different form. However, we can obtain almost the same log information about counterexamples with both strategies, as described in Section 5, by embedding appropriate logging statements that have state information. Thus, the same effort is required to analyze the counterexamples and thus understand the reflective tower's behavior.

Threats to Validity
The main threat to internal validity concerns the effectiveness of verifications. The experimental results in Section 6 demonstrated that verification with our approach could scale by applying state reduction techniques. However, the scalability improvement might have been affected by optimization in the SPIN model checker. To distinguish the contributions of our approach from those of the model checker, we performed a verification with the SPIN model checker for a model that was implemented with the simple strategy without state reduction techniques. The contributions of our approach could be found by comparing the results of the baseline and those of the other cases.
As for threats to external validity, we showed the feasibility of our approach through only two case studies. Our approach will need further validation on other reflective tower applications, and this will be one of our future works. However, we demonstrated in this paper that our approach is applicable to the reconnaissance robot example of a reflective tower with three layers, whereas the most of the existing studies have addressed reflective systems with only two layers.

Reflective System Verification
There are several approaches for verifying reflective systems. Li et al. [17] and Grech et al. [18] proposed static analysis techniques for Java programs that enable model checking of programs by using the Java reflection API. These approaches depend on Java and deal only with reflection obtained via the API, whereas our approach is based on the notion of an LTS, which is a general-purpose model of system behaviors.
Weyns et al. [9] used the Z specification language. Although their approach rigorously treats the metalevel and the object level separately, it does not explicitly model the behavior of a system. In contrast, our MLTS can explicitly represent both metalevel and object-level behaviors.
Capra and Camilli [19] used high-level petri nets that represent behaviors explicitly. A metalevel behavior is represented as a type of high-level net called a symmetric net, while an object-level behavior is represented as a simple place/transition net. However, they only addressed two-layer reflective towers. Modeling of more than two layers with this approach would require a more complex petri net structure that can operate symmetric nets as lower-level models. In contrast, our approach models each layer uniformly by using MLTSs, and it can easily model reflective towers with two or more layers.
Borda et al.'s study [33] proposed an adaptive communicating sequential process model, which is an extension of the communicating sequential process model for reflective systems. The main feature of their approach is that it treats the object level as a first-class object. It represents both the object level and the metalevel as concurrent processes, but metalevel processes can replace object-level processes during operation. However, the metalevel cannot the inspect internal states of the object-level processes, and its capability to describe reflection is thus limited. In contrast, in our approach, the metalevel can access the internal states and transitions of object levels through data.
Other recent research has used abstract state machines (ASMs) as models of reflection. An ASM is a type of transition system, similar to our ELTS, that updates data when triggering a transition. The main difference is that an ASM has a more refined structure than an ELTS and can thus model algorithms more precisely. Arcaini et al. [34] proposed self-adaptive ASMs to model two types of entities called managed and managing agents. The managing agents can modify the behavior of the managed ones. They conducted model checking and quantitative evaluation by using tools called ASMETA and NuSMV. However, their model changes the program of a managed agent in its entirety and does not provide fine-grained metalevel control, unlike our approach.
Ferrarotti et al. [15] and Schewe et al. [16] extended ASMs with reflection and used them to model reflective sequential and distributed algorithms, respectively. They modeled dynamic evolution and self-adaptive systems by using such algorithms. Thus, their approaches are apparently the most similar to ours. However, they presented only a theoretical framework, performed no experiments, and provided no quantitative evaluation. In contrast, we used a simpler and more generic extension of an LTS to focus on scalable verification of reflective systems. As a result, our approach can easily model an example like the remote elderly monitoring system that has fine-grained control of the object level at the metalevel.
Modeling and verification of reflective towers with two or more layers have also been investigated. Formal verification based on rewriting logic is a representative approach to enable hierarchical reflection modeling and model checking. Tahara et al. [31] applied Maude to reflective systems, specifically for dynamic evolution, but their work addressed reflective systems with two layers, rather than general reflective towers. Bruni et al. [20] proposed a formal framework based on rewriting logic to specify a reflective tower, and they demonstrated its model checking. As those works indicate, rewriting logic is a powerful formal framework for reflective tower verification. However, the tools that can support such approaches are limited to those that deal with rewriting logic: to the best of our knowledge, they are limited to the Maude model checker and its variants. In contrast, we aim to model and verify a reflective tower based on an LTS, which is supported by many widely used tools, such as SPIN, NuSMV, and PAT.

Formal Models Similar to ELTS/MLTS
The basic idea of our MLTS to extend an LTS to contain and manipulate data that represents lower-level LTSs to support self-inspection and self-modification in a reflective tower.
There are several other formal models that contain and manipulate data. For example, Cheng and Krishnakumar proposed an extended finite state machines (EFSMs) [35], which is an extension of a finite state machine to handle the data operations associated with a transition. Similarly, a program graph ( [26], Section 2.1.2), which aims to provide operational semantics to Promela, handles data in a graph. Those ideas are similar to our ELTS; however, we also proposed the MLTS, which handles other ELTSs as data to model a reflective tower.
Several other formal models support hierarchical structures. For example, statecharts [36] support a hierarchical structure that allows a state to contain substates and transitions between them. Klarl [37] proposed a hierarchical LTS (H-LTS), which is an extension of an LTS to support a hierarchical structure. Those models were designed for analyzing complex systems are not specific to reflective system modeling and verification. In those models, sub-models (e.g., sub-states or sub-LTSs) should be statically defined and tightly coupled with a parent model, and the modification of a sub-model by its parent model is not supported. In contrast, our MLTS supports selfinspection and self-modification by representing object-level models as data. States in the object-level can be used as guard conditions for transitions in the meta-level. Moreover, the dataupdate function can dynamically modify object-level models and the current states of an object-level through these data representations.

State Reduction Techniques
In this paper, we demonstrated that two state reduction techniques for an LTS, namely, symmetry reduction and DS-stutter bisimulation, are applicable to our MLTS. There are many other state-space reduction techniques for LTSs. A recent book [38] surveyed such techniques: partial-order reduction, compositional reasoning, abstraction, and bisimulation. We plan to apply various other techniques for LTSs to make our approach even more scalable.
State reduction techniques for rewriting logic have also been investigated [39], [40], [41], [42]. Those state reduction techniques effectively use the algebraic nature of rewriting logic. Meseguer et al. [39] proposed a state reduction technique called equational abstraction, which applies the concept of abstraction for LTSs to rewriting logic. That approach uses equations to merge multiple states. Because a state of rewriting logic is an equivalence class of terms that are identified by those equations, addition of equations reduces the number of states. Bae and Meseguer [41] applied predicate abstraction, which is a type of abstraction for an LTS, to rewriting logic. That technique identifies a tuple of truth values for each state, where each truth value indicates whether a state satisfies a given predicate. Thus, their technique turns a number of states into one tuple if their truth values coincide. A key issue in predicate abstraction is how to determine if a state satisfies a predicate. That technique uses reasoning on rewriting logic for this purpose. Meseguer [40] defined generalized rewrite theories, where a rewrite theory is an axiomatic system of rewriting logic, and further proposed state reduction techniques for those generalized rewrite theories. One of the state reduction techniques, called subsumption, identifies one term and another term that can be obtained by instantiating variables of the former term, i.e., by replacing the variables with other terms. Escobar et al. [42] presented a state reduction technique for a tool called Maude-NRL Protocol Analyzer. That technique uses characteristics of cryptographic protocols to remove unreachable and redundant states to explore. Although the state reduction techniques for rewriting logic in those works [39], [40], [41], [42] were evaluated with simple examples, to the best of our knowledge, they have not yet been evaluated with reflective systems such as reflective towers. In contrast, our approach focuses on applying the state reduction techniques for LTSs to reflective towers, and we demonstrated its applicability and effectiveness through two reflective tower applications in this paper.

CONCLUSION
We proposed an approach for model checking of reflective towers, which is based on the generic LTS concept. We proposed the use of an MLTS, which is an extension of an LTS, to model reflective towers. We showed that two state reduction techniques for LTSs are also applicable to MLTSs. We also introduced two strategies for implementing an MLTS in Promela. Furthermore, we demonstrated that two example models, of a reconnaissance robot and an IoT-based remote elderly monitoring system, could change their own behaviors by using reflection. Experimental results demonstrated that our approach has the ability to verify a reflective tower and that the state reduction techniques improved the scalability in these cases.
We plan to perform extensive future work on this approach. In particular, we aim to apply it to more than just the two case studies examined here, and we thus plan to conduct more experiments on other applications. In the current implementation, developers have to manually check the counterexamples that are generated when verified properties do not hold and manually find the faults in the encoded LTSs. Accordingly, automated support for finding such faults is required. In this paper, we used SPIN as a representative of widely-used model checkers that support LTSs. Because our approach is based on the notion of an LTS, we plan to apply it to other model checkers such as NuSMV and PAT. Finally, we applied symmetry reduction and DS stutter bisimulation to our MLTS-based approach, and we will apply other state reduction techniques for LTSs, as well.
Yasuyuki Tahara received the BSc and MSc degrees in mathematics from the University of Tokyo, Japan, in 1989 and 1991, respectively, and the PhD degree in information and computer science from Waseda University, Japan, in 2003. He is currently an associate professor with the University of Electro-Communications. He joined Toshiba Corporation in 1991. He was a visiting researcher with City University London, U.K., from 1995 to 1996, and with Imperial College London, U.K., from 1996 to 1997. He left Toshiba Corporation and joined the National Institute of Informatics (NII) in 2003. He left NII and joined the University of Electro-Communications in 2008. His research interests include formal verification of software and requirements engineering. He is a member of the Information Processing Society of Japan (IPSJ) and Japan Society for Software Science and Technology (JSSST).
Akihiko Ohsuga received the PhD degree in computer science from Waseda University, Tokyo, Japan, in 1995. From 1981 to 2007, he was with Toshiba Corporation. He joined the University of Electro-Communications in 2007. He is currently a professor with the Graduate School of Informatics and Engineering and a dean of the Graduate School of Information Systems. He is also a visiting professor with the National Institute of Informatics (NII). His research interests include agent technologies, web intelligence, and software engineering. He is a member of the IEEE Computer Society (IEEE CS), Information Processing Society of Japan (IPSJ), Institute of Electronics, Information and Communication Engineers (IEICE), Japanese Society for Artificial Intelligence (JSAI), Japan Society for Software Science and Technology (JSSST), and Institute of Electrical Engineers of Japan (IEEJ). He has been an IPSJ fellow since 2017. He has served as a chair of the IEEE CS Japan Chapter, a member of the JSAI Board of Directors, and a member of the JSSST Board of Directors. He received IPSJ best paper awards in 1987 and 2017.