Content uploaded by Natasha Jarus
Author content
All content in this area was uploaded by Natasha Jarus on Feb 20, 2019
Content may be subject to copyright.
Formalizing Cyber–Physical System Model
Transformation via Abstract Interpretation
Natasha Jarus, Sahra Sedigh Sarvestani, and Ali Hurson
Department of Electrical and Computer Engineering
Missouri University of Science and Technology
Rolla, USA 65409
Email: {jarus, sedighs, hurson}@mst.edu
Abstract—Model transformation tools assist system designers
by reducing the labor–intensive task of creating and updating
models of various aspects of systems, ensuring that modeling
assumptions remain consistent across every model of a system,
and identifying constraints on system design imposed by these
modeling assumptions. We have proposed a model transformation
approach based on abstract interpretation, a static program
analysis technique. Abstract interpretation allows us to define
transformations that are provably correct and specific. This
work develops the foundations of this approach to model
transformation. We define model transformation in terms of
abstract interpretation and prove the soundness of our approach.
Furthermore, we develop formalisms useful for encoding model
properties. This work provides a methodology for relating models
of different aspects of a system and for applying modeling
techniques from one system domain, such as smart power grids,
to other domains, such as water distribution networks.
Index Terms—Modeling, Model transformation, Formal meth-
ods, Abstract interpretation
I. INTRODUCTION
The multitude of functional and non–functional require-
ments for critical infrastructure cyber–physical systems (CPSs)
present many challenges to system designers. A smart grid
must be able to supply all its customers; it must be fault–
tolerant in the face of component failure; it must be secure
against physical and cyber attacks; and it must achieve all
these goals with efficient infrastructure. To meet all these
requirements, designers must integrate physical components,
cyber control software and hardware, and processes for human
operators into a complete system. This is a truly daunting
task, but one that can be facilitated by model-based design
and evaluation.
A vast body of literature has been published on various
modeling formalisms that capture system performance, de-
pendability, safety, and security. No single modeling formalism
can encompass all aspects of system performance and de-
pendability, necessitating the labor–intensive and error–prone
process of creating multiple system models and propagating
changes across all of these models. Furthermore, designers
must be careful that these models remain consistent with each
other, i.e., that the assumptions made about the system by one
model are not contradicted by those of any other model. For
instance, a dependability model for a smart grid where two
power lines are assumed to be connected in parallel is not
compatible with a power flow analysis where the lines are
placed in series.
One way to alleviate these challenges is through model
transformation, which enables automated or semi-automated
transformations between modeling formalisms. These trans-
formations can ensure that modeling assumptions are consis-
tent across every model of a system by verifying that any
model can be transformed into any other. This approach can
also identify constraints on system design imposed by these
assumptions. Such a model transformation approach should
meet two design constraints. First, it should be applicable to a
broad range of systems and a variety of modeling formalisms
in order to be useful to designers of complex systems. Second,
it should be sound—it should be possible to prove that the
result of a transformation is correct and consistent with the
initial models.
In our earlier work [1], we proposed a model transformation
approach based on abstract interpretation, a static program
analysis technique. Models are seen as abstractions of the
semantics of a system—its structure and behavior. Through
this lens, provably correct model transformation becomes the
problem of defining sound mappings from system semantics
to model semantics and vice versa. By composing these
mappings, we can develop sound transformations between
modeling formalisms.
The research contribution of this work is twofold. We
propose:
1) a formalization of system and model semantics, leading
to a formalization of sound model transformation, and
2) a mathematical structure useful in the development of
structures that capture system semantics.
Our first contribution formalizes the research approach we
outlined in [1] and incorporates several improvements from
feedback we have received since publication of that work. The
second contribution lays the groundwork for integrating real–
world modeling formalisms into this model transformation
approach.
The structure of this paper is as follows: in Section II, we
briefly summarize related model transformation and formal-
ization techniques. Section III presents our formalization of
system and model semantics and describes how we use this
formalization to create a method for model transformation.
Section IV presents tag–option lattices, a structure that we find
to be useful when formalizing the semantics of systems. Sec-
tion V summarizes our work and discusses future directions
for our research.
II. RE LATE D WOR K
In the literature, model transformation refers to two different
but related concerns. One concern is integrating models of
different parts of the system into a complete system model; this
is more specifically called heterogeneous model composition.
The other concern is transforming one type of model for a
system to a different model of the same system or a related
system.
Model transformation research specific to CPSs primarily
focuses on building hierarchical models [2]–[5]. Hierarchical
models allow different model types to be combined together to
model complex systems. Each component can be modeled in a
convenient formalism; the hierarchical model is then simulated
by simulating each sub-model in tandem.
The Ptolemy modeling software [6] performs hierarchical
modeling and model composition [7], [8]. As such, Ptolemy
makes it easy to build and link small models. Hierarchical
models can consist of heterogeneous sub–models, allowing
different parts of the system to be expressed using different
types of models [8]–[11]. Model composition is achieved
in part by defining ontologies of system properties, e.g.,
units of model inputs and outputs. Based on these ontolo-
gies, Ptolemy can perform conversions of values transmitted
between sub–models and check for incompatibilities which
indicate modeling errors. Ptolemy also enables heterogeneous
model evaluation: it provides choices for both the modeling
language and the solution or simulation technique used to
evaluate the model [12]. However, Ptolemy does not offer
methods for transforming one system–level model to another.
In addition, it is focused on models of system function and
lacks facilities for modeling non-functional attributes.
OsMoSys [13] and SIMTHESys [14] are modeling systems
motivated by model–driven engineering. Their approach to
model transformation is based on techniques from software
engineering. Graph–based models, such as Petri Nets and
Fault Trees, are described using an object–oriented notation.
Every model has associated interfaces which allow models
of different types to be composed and evaluated. OsMoSys
features compositional models and interfaces with external
tools to evaluate them [15]. SIMTHESys provides a language
in which users can describe new modeling formalisms for use
with OsMoSys. Both are capable of modeling both functional
and non-functional aspects of a system [16]. However, neither
are focused on the problem of model transformation.
M¨
obius [17] is another modeling tool that supports hier-
archical modeling. It supports several modeling formalisms,
including block diagrams and Petri nets, and additional for-
malisms including stochastic timed systems can be included
via external modeling tools [18], [19]. While this feature offers
considerable flexibility in modeling, M¨
obius is constructed
around a modeling workflow that builds and evaluates hierar-
chical models and has little support for model transformation.
Its model composition method is based on object–oriented
design principles and is applicable to many state–based model
formalisms.
AToM3[20] is capable of both model transformation and
model composition. It uses metamodels to describe specific
modeling languages, then defines transformations between
metamodels to transform models [21]. Models are graph-
based and transformations take the form of graph rewriting
rules [22]. However, there is no hierarchy of models, so
introducing a new model requires writing transformation rules
from the new model to each model that AToM3implements.
CHESS [23] provides a modeling language for describing
systems and includes several model transformation methods
specific to creating dependability models. CHESS is based
on the Unified Modeling Language (UML); transformations
are based on graph rewriting rules. CONCERTO [24] ex-
tends CHESS by introducing modeling techniques for non-
functional system attributes such as dependability [25]. How-
ever, CONCERTO is focused on multicore processing sys-
tems [26], [27] and lacks the features necessary for modeling
complex physical components.
Rosetta [28] is focused on functional multi–formalism mod-
eling [29]. It takes an algebraic approach to relating models:
each formalism is described as a coalgebra—a mathematical
system useful for describing arbitrary transitions among arbi-
trary states [30], [31]. The coalgebras corresponding to each
formalism are placed in a lattice, which provides a structure
for determining how to transform one model into another.
Model transformations can be used to relate different models
of the same system; for example, it is possible to combine a
functional system model with a model of that system’s power
consumption. However, Rosetta lacks many features required
for CPS modeling, especially support for hybrid discrete–
continuous formalisms.
Each of these model transformation tools offers a partial
solution to the model transformation problem; however, none
of them present a solution that is generally applicable. Some
frameworks place constraints on the behavior of transforma-
tion functions (e.g., class inheritance transformation). Others
apply only to specific formalisms. Furthermore, only Rosetta
offers an approach that can be proven to be correct. The work
presented in this paper aims to address these shortcomings
by providing a model transformation approach that relates
a wide variety of modeling formalisms in a provably sound
fashion, and yields results that are sufficiently specific to be
meaningful.
III. ABS TR ACT IN TE RP RE TATIO N OF MO DE LS
The foundation of our approach is abstract interpreta-
tion [32], [33], a formalism for developing sound semantic
abstractions. In this work, system semantics are represented in
terms of properties that hold for the system. Such properties
might include information about components, their reliabili-
ties, and how they are interconnected. Models are abstractions
of system semantics—they concern certain properties of the
system, but not others. Thus, generating a model from a
system’s properties, then deriving properties of that system
from the generated model, may result in some of the initial
properties not being present in the derived properties. This is
a necessary effect of abstraction—we cannot derive properties
from a model if the model does not capture those properties. To
define mappings from system properties to models and vice
versa, both domains need to allow for this potential loss of
precision.
A. Properties
We first define how system semantics are represented.
Lattices (see [34]) offer a useful formalism for describing the
nature of approximation. We define a complete Properties
lattice ordered by specificity: for p1, p2∈Properties, p1v
p2means that the constraints in p1and p2are not contradictory
and that p1places the same or more constraints on a system
than p2does. For example, p2could constrain the reliability
of a component to fall in the range (0,1], whereas p1could
require that component to have a reliability of 0.95.
The meet (denoted as u) of two elements of Properties
places the constraints of both elements on a system; the join
(denoted as t) implies satisfaction of the constraints of either
element. Suppose p1requires a component’s reliability to fall
in [0.8,1.0] and p2constrains it within [0.75,0.9]. Then p1up2
will require it to be in [0.8,0.9] and p1tp2within [0.75,1.0].
F
and Fextend this concept to subsets of Properties.
For certain p1, p2∈Properties are contradictory, p1up2
will result in a constraint that is impossible to satisfy. If p1
requires a component to have a reliability in [0.5,0.7] and p2
requires it in [0.9,1], then it is impossible for any component
to meet both constraints. In this paper, we require that every
element of Properties to be satisfiable except for ⊥, the
“impossible” constraint. Therefore, for this example, p1up2=
⊥. Note that ∀p∈Properties,⊥ v p.
To summarize, each element of the Properties lattice
describes one or more systems. In the general case, pdescribes
a set of systems, all of which meet the constraints in p. If every
constraint in p∈Properties has exactly one possible choice,
pwill describe a single system.
B. Models
We now consider how modeling formalisms can be repre-
sented in this lattice framework. As a given element of the
Properties lattice may not define a single system, we must
account for the possibility that the lattice may not specify the
system well enough for a single model to be abstracted from
it. If p∈Properties does not constrain the reliability of a
component to a single value, a single reliability model cannot
be abstracted from p. Instead, we abstract a set of models, one
for each possible assignment of the component’s reliability,
subject to the constraints of p.
Therefore, in the same way that the Properties lattice
is defined, we also define the domain of each modeling
formalism to account for the nature of potentially imprecise
system specifications. To ensure that this approach is broadly
applicable, we define this domain using structure external to
the modeling formalism itself. Thus we do not have to require,
say, that a reliability model formalism be able to express the
concept of a component having a range of possible reliabilities.
We use a powerset lattice to provide this extra structure.
For a given model formalism, the set Model contains all
possible models expressible in that formalism. The powerset
lattice P(Model)then forms a lattice ordered by specificity:
for M1, M2⊆Model,M1⊆M2indicates that M1contains
fewer possible models describing a system, and thus places
more constraints on the system, than M2does. Likewise, M1∩
M2produces a set of models that fit the constraints associated
with M1and with M2;M1∪M2produces a set of models
where constraints from either may hold.
Singleton sets (i.e., sets of the form {m},m∈Model)
correspond to fully-specified models, and ∅=⊥corresponds
to an “impossible” system—one with contradictory modeling
requirements.
To make the notation clearer and more consistent, we will
define Model =P(Model), as the powerset lattice of the
original set of models, Model . For the powerset lattice
Model, we will use the rounded operators (⊆,T,S) to prevent
confusion with the square operators of the lattice Properties,
and of lattices in the abstract.
C. Correctness
In this work, we represent the set of systems by S. We think
of these systems abstractly; thus, we do not concern ourselves
with the representation of Sor its elements. When we speak
of a system s∈ S, we understand sto be the system to be
modeled.
Any system s∈ S is described by a number of elements of
Properties. To formalize this notion, we use a correctness
relation to relate a system to properties (and later, models)
that describe it. We suppose a relation RP:S → Properties
where s RPpif and only if pdescribes the system s. We must
assume the existence of RP, since the properties of the system
being designed are determined by the designer. However,
abstract interpretation allows us to induce correctness rela-
tionships between systems and models based on RP—in other
words, abstract interpretation enables sound transformations
between system properties and system models.
Definition 3.1: Acorrectness relation RL:S → Lrelates
systems to elements of a lattice L. Two attributes hold for RL:
(i) If s RLl1and l1vl2, then s RLl2.
(ii) If ∀l∈L0⊆L, s RLl, then s RL
F
L0.
In terms of Properties and its correctness relation RP,
Property (i) states that we can relax correct constraints without
violating their correctness. The reverse does not hold, oth-
erwise, the inconsistent constraint ⊥would describe every
system. The formalization of relaxation of constraints as
described by Property (i) allows us to generalize constraints
and therefore plays a crucial role in modeling abstraction.
Property (ii) requires that for any set of constraints L0there
exist a “best” constraint that correctly describes any system
described by every constraint in L0. We can apply this property
to the constraints derived from several models to narrow down
our description of a given system’s properties. In this sense,
it allows us to derive a specific result from a number of more
general results. Note that the converse of (ii) follows from (i),
so (ii) could also be written as a biconditional.
D. Abstraction and Concretization
Given a correctness relation RPfor Properties, we desire
to define a mapping between Properties and a modeling
formalism Model that induces a correctness relation RM:
S → Model. Furthermore, this mapping must allow for the
modeling domain to abstract system constraints. For instance,
a topology model should be able to discard constraints on
component reliability.
The formalism of choice for this task is a Galois connection:
Definition 3.2: AGalois Connection (P, α, γ, M)between
two complete lattices Pand Mconsists of a pair of monotone
functions α:P→Mand γ:M→Pfor which the following
relationships hold:
(γ◦α)(p)wp(1)
(α◦γ)(m)vm(2)
We refer to Pas the concrete domain,Mas the abstract
domain,αas the abstraction operator, and γas the concretiza-
tion operator.
In terms of models and properties, αabstracts a model, m,
from a set of constraints on a system, p, and γderives, or
concretizes, system constraints from a model of that system.
Relationship (1) states that abstracting the model mfrom
constraints p, then concretizing constraints from that model,
results in constraints that are at most more general than
those of p. In other words, abstraction may relax constraints
irrelevant to the model formalism, but it cannot produce a
model that implies constraints that contradict p. Relationship
(2) requires that Properties be able to completely capture the
constraints imposed by each model formalism, meaning that
if constraints are concretized from a model, m, of a system,
any other model abstracted from these constraints will be as
least as specific as the original model, m. Concretization may
introduce additional constraints, but in practice, the vof (2)
will often be strict equality in practice.
Next, we show that each Galois connection induces a
correctness relation RMon the abstract domain.
Theorem 3.1: Given a Galois connection (P, α, γ, M)and a
correctness relation RP:S → P, the relation RM:S → M
defined by s RMm⇐⇒ s RPγ(m)is a correctness relation.
Proof: We must show that properties (i) and (ii) from
Definition 3.1 hold for RM. Take s∈ S and m1, m2∈M.
s RMm1∧m1vm2
⇐⇒ s RPγ(m1)∧m1vm2(Defn. of RM)
⇐⇒ s RPγ(m1)∧γ(m1)vγ(m2) (γmonotone)
=⇒s RPγ(m2) (Prop. (i) for RP)
⇐⇒ s RMm2(Defn. of RM)
The proof of (ii) uses the fact that γis completely mul-
tiplicative, that is,
F
{γ(m)|m∈M0}=γ(
F
M0). Take
s∈ S and M0⊆M.
∀m∈M0s RMm
⇐⇒ ∀m∈M0, s RPγ(m) (Defn. of RM)
=⇒s RP
G
{γ(m)|m∈M0}(Prop. (ii) for RP)
⇐⇒ s RPγ
G
M0(Multiplicativity of γ)
⇐⇒ s RM
G
M0(Defn. of RM)
Put in terms of models and system properties, if we define
a Galois connection between Properties and the lattice
for a given modeling formalism Model, then every correct
collection of system constraints abstracts to a correct model
and every correct model concretizes to a correct collection of
system constraints. Therefore, we have developed a provably
sound definition of the nature of model abstraction.
E. Model Transformation
Given this formalization of system and model seman-
tics, we can now formalize the problem of model trans-
formation. Suppose we have a properties domain and two
modeling formalisms with associated Galois connections to
the properties domain (Properties, αM1, γM1,Model1) and
(Properties, αM2, γM2,Model2). Furthermore, we have a
correctness relation RPwhich induces correctness relations
RM1and RM2.
Definition 3.3: Amodel transformation from Model1to
Model2is a semantically sound mapping τM2
M1:Model1→
Model2. That is, if m1∈Model1is correct, then τM2
M1(m1)
is also correct.
We can define τM2
M1by first concretizing constraints from
m1∈Model1, then abstracting an element of Model2from
it.
Theorem 3.2: The mapping τM2
M1(m1) = (αM2◦γM1)(m1)
is sound.
Proof: Take s∈ S and m1∈Model1.
s RM1m1
⇐⇒ s RPγM1(m1)Defn. of RM1
=⇒s RP(γM2◦αM2◦γM1)(m1)Eqn. (1), Prop. (i)
⇐⇒ s RM2(αM2◦γM1)(m1)Defn. of RM2
To sum up the transformation process: begin with a model
m1∈Model1. Concretize properties of the system from
{m1}, then apply τM2
M1to produce a set of models M0
2⊆
Model2. Finally, select a model from M0
2by introducing
information about the system not present in m1.
Figure 1 illustrates the domains, mappings, and relationships
present in this formalization of model transformation.
sss
.
.
..
.
..
.
.
RM1=⇒RP=⇒RM2
.
.
..
.
..
.
.
Model1Properties Model2
γM1αM2
τM2
M1
Fig. 1. Sound model transformation.
F. Selection and Specificity
Recall that the elements of Model are sets of models. To
concretize properties of a single model m∈Model, we
first map it to {m} ∈ Model, then apply γ. Conversely, for
a set of models Mproduced from an abstraction operation,
each model in that set equally captures the system constraints
from which Mwas abstracted. If M=∅, then the chosen
modeling formalism cannot reason about the given system
constraints. If M={m}, then the abstraction process has
produced a single model describing the system. Otherwise,
the system constraints lack some information about the system
that is relevant to this modeling formalism. In this case, the
user must introduce new information about the system by
selecting one model from this set. For example, one may
have to provide information about component reliability when
selecting a reliability model.
We represent this selection process as a function σ:
Model →Model; the definition of σdepends entirely upon
the exact system being modeled. While the known system
constraints may not be precise enough to indicate exactly
which model in the set is correct, they still indicate that the
correct model is in the given set of models. Therefore we
can constrain σto not produce a model which we know is
incorrect even when we do not have enough information about
the system to produce a single model.
Definition 3.4: The function σ:Model →Model is a
selection operator if the following conditions hold:
(i) σ(m)∈m
(ii) If s RMm, then s RM{σ(m)}
Given a selection operator, we can incorporate the newly
introduced information back into the system properties do-
main, allowing future transformations to include these con-
straints and therefore produce more specific results. Take
p∈Properties such that s RPp. Derive the exact model
of formalism Model by letting m:= (σ◦α)(p). By def-
inition of σwe know s RM{m}, so s RPγ({m}). Finally,
we can construct a more specific element p0∈Properties
by p0:= puγ({m}). The correctness of p0follows from
property (ii) for RP, and by definition of u,p0vp.
Figure 2 depicts the relationship between these given func-
tions and domains.
Model Properties
Model
α
γ
σm7→ {m}
Fig. 2. Mappings between Model,Model, and Properties
IV. TAG-OPT IO NS LATT IC E
In our formalization of systems and models, we assume a
properties domain that is a lattice of constraints on a system;
its elements are ordered by specificity. A common pattern
arises when defining this domain: a lattice that assigns a set of
potential values to each element of a set of names or tags. Two
examples are assigning possible reliabilities to components
and defining whether a state is considered functional or failed.
We will refer to this type of lattice as a Tag–Options Lattice;
it is comprised of a tag lattice and a family of options lattices.
For instance, one may use a tag lattice where each element
is a set of components known to be part of a system; each
element of the corresponding options lattice is a function that
assigns possible reliabilities to each component.
A. Tag Lattice
Let T:= {t1, t2,· · · } be a set of tags.
Definition 4.1: The tag lattice T:= P(T)∂is the dual of the
powerset lattice of T, where v:=⊇,
F
:= S, and F:= T.
In this lattice, >=∅corresponds to a system where no tags
are known to apply—for example, a system with no known
components. Thus, every system is described by >. Lattice
elements are ordered by specificity; if T1, T2∈Tand T1vT2,
then T1contains more information than T2about tags that
apply to a system.
B. Options Lattice Family
Let O={o1, o2,· · · } denote the set of options—potential
values—for each tag.
Definition 4.2: For each set of tags T0∈Twe can define
a corresponding options lattice OT0. The elements of OT0are
functions f:T0→ P(O)that assign a set of possible options
to each tag. For any f, g ∈OT0,fvgif and only if f(t)⊆
g(t)for all t∈T0.
We can alternatively view the elements as sets of tuples
(t, o)where t∈T0and o∈ P(O). Each set contains exactly
one tuple per tag.
For any set of elements of an options lattice, O0⊆OT0, we
define
i) FO0=λt. S{f(t)|f∈O0}, and
ii)
F
O0=λt. T{f(t)|f∈O0}.
We refer to the family of options lattices associated with tag
set Tby O(T).
t17→ O
t17→ {x}t17→ {y}
t17→ ∅
Fig. 3. Hasse diagram for O{t1}
For example, if T0:= {t1, t2}and O:= {x, y}, then
f:= {(t1,∅),(t2,{x, y})}and g:= {(t1,{x}),(t2,{y})}are
elements of OT0. Furthermore,
ftg={(t1,{x}),(t2,{x, y})}
fug={(t1,∅),(t2,{y})}
Theorem 4.1: OT0is a complete lattice.
Proof: The proof that vis a partial order on OT0follows
directly from ⊆being a partial order on f(t), f ∈OT0for
all t∈T0. Likewise, the proof that
F
and Fare complete
follows from the completeness Tand S.
From these definitions it follows that >(t) = Oand ⊥(t) =
∅for all t∈T0. We can always imagine a system where any
of the given options holds for each tag; a system where no
tag corresponds to any of the options is a system about which
our abstractions cannot reason.
Hasse diagrams for O{t1}and O{t1,t2}are shown in Figure 3
and Figure 4, respectively.
Thus far, we have defined a lattice of system tags Tand a
family of options lattices O(T) := {OT0|T0∈T}consisting
of mappings of tags to options. What remains is to combine
these lattices into a single tag–options lattice.
C. Options Lattice Homomorphisms
Before we can develop a tag–options lattice, we must define
how elements of different options lattices are related. The
tool of choice is a lattice homomorphism: a mapping between
lattices that preserves meets and joins.
Definition 4.3: For all sets of tags A,B∈Twe define a
function φB
A:OA→OBby
φB
A(f) := λt. (f(t)if t∈A∩B
Oif t∈B−A
Or, from a sets-of-tuples perspective,
φB
A(f) = {(t, o)∈f|t∈A∩B}∪{(t, O)|t∈B−A}
φallows us to convert a function with one domain to a
related function with a different domain: if f:A→ P(O),
then φB
A(f) : B→ P(O).
Theorem 4.2: φB
Ais a lattice homomorphism. That is, for
all O0⊆OA,
i)
F
φB
A(f)|f∈O0=φB
A(
F
O0)and
ii) FφB
A(f)|f∈O0=φB
A(FO0).
Proof: To show
F
φB
A(f)|f∈O0=φB
A(
F
O0),
suppose A,B⊆Tand O0⊆OAand take arbitrary t∈B.
t17→ O
t27→ O
t17→ {x}
t27→ O
t17→ O
t27→ {x}
t17→ {y}
t27→ O
t17→ O
t27→ {y}
t17→ {x}
t27→ {x}
t17→ {x}
t27→ {y}
t17→ {y}
t27→ {x}
t17→ {y}
t27→ {y}
t17→ {x}
t27→ ∅
t17→ ∅
t27→ {x}
t17→ {y}
t27→ ∅
t17→ ∅
t27→ {y}
t17→ ∅
t27→ O
t17→ O
t27→ ∅
t17→ ∅
t27→ ∅
Fig. 4. Hasse diagram for O{t1,t2}
Case 1:t∈A.
φB
A
G
O0(t)
=
G
O0(t) (Defn. of φB
A)
=\{f(t)|f∈O0}(Defn. of
G
for A)
=\φB
A(f)(t)|f∈O0(Defn. of φB
A)
=
G
φB
A(f)|f∈O0(t) (Defn. of
G
for B)
Case 2: t /∈A.
φB
A
G
O0(t)
=O(Defn. of φB
A)
=\{O|f∈O0}(Set Properties)
=\φB
A(f)(t)|f∈O0(Defn. of φB
A)
=
G
φB
A(f)|f∈O0(t) (Defn. of
G
for B)
The proof that FφB
A(f)|f∈O0=φB
A(FO0)is anal-
ogous.
We now prove a corollary necessary to show the complete-
ness of the tag–option lattice:
Theorem 4.3: If A,B,C∈Tsuch that AvBvCand
f∈OAand g∈OCsuch that φC
A(f)vg, then φB
A(f)v
φB
C(g).
Proof: Take arbitrary t∈B.
Case 1:t∈C. Then f(t)⊆g(t),φB
A(f)(t) = f(t), and
φB
C(g)(t) = g(t). Therefore φB
A(f)(t)⊆φB
C(f)(t).
Case 2:t6∈ C. Then φB
C(g)(t) = Oand φB
A(f)(t)⊆O.
D. Tag-Options Lattice
So far, we have developed a lattice that relates sets of tags
that apply to a given system and a family of lattices that relate
option values given a set of tags. Now we combine these into
a lattice that can relate option values between sets of tags.
Definition 4.4: Atag–options lattice Λ(T,O(T)) is a lattice
of tuples (T0, f )where T0is an element of Tand fis an ele-
ment of OT0. Given elements (A, f)and (B, g )∈Λ(T,O(T)),
(A, f )v(B, g)if and only if AvBand φB
A(f)vg.
(Note that if (A, f )v(B, g),AtB=B, so φAtB
A=φB
A
and φAtB
B=λx.x.)
For any subset Λ⊆Λ(T,O(T)), let V:= {T0|(T0, f)∈
Λ}. Then we can define
i) FΛ:= FV,FnφFV
T0(f)|(T0, f )∈Λo, and
ii)
F
Λ:=
F
V,
F
nφ
F
V
T0(f)|(T0, f )∈Λo.
In this lattice, ⊥= (⊥T,⊥OT)is the system where no
options are valid for any tag. >= (>T,>O∅)corresponds
to the system where no tags are known to apply.
For example, suppose we have a set of tags T={t1, t2, t3}
and take elements T1,T2∈Twhere T1={t1, t2}, and
T2={t2, t3}. Let the options set be O={x, y}.
Let f:T1→ P(O)be an element of OT1where f=
{(t1,∅),(t2,O)}. Let g:T2→ P(O)be an element of OT2
where g={(t2,{x}),(t3,{y})}. Then (T1, f )and (T2, g)are
elements of Λ(T,O(T)).
Furthermore, we can compute the meet of (T1, f )and
(T2, g)as follows:
(T1, f )u(T2, g)
=(T1uT2, φT1uT2
T1(f)uφT1uT2
T2(g))
=(T1∪T2,{(t1,∅),(t2,O),(t3,O)}
u {(t1,O),(t2,{x}),(t3,{y})})
=(T,{(t1,∅ ∩ O),(t2,O∩ {x}),(t3,O∩ {y})})
=(T,{(t1,∅),(t2,{x}),(t3,{y})}).
Theorem 4.4: Λ(T,O(T)) is a complete lattice.
Proof: That vis a partial order follows from the partial
orders defined on Tand the lattices of O(T).
To show that
F
is a well–defined meet operator, take an
arbitrary subset Λ⊆Λ(T,O(T)), and let V:= {T|(T, f)∈
Λ}.
Take arbitrary (T0, f 0)∈Λ(T,O(T)) such that ∀l∈
Λ,(T0, f 0)vl. Thus, T0v
F
V. Furthermore,
∀l∈Λ,(T0, f 0)vl
=⇒ ∀(T, f)∈Λ, T 0vT∧φT
T0(f0)vf(Defn. of v)
=⇒ ∀(T, f)∈Λ, φ
F
V
T0(f0)vφ
F
V
T(f) (Thm. 4.3)
=⇒φ
F
V
T0(f0)v
G
nφ
F
V
T(f)|(T, f)∈Λo
(Defn. of
F
for O
F
V)
Therefore (T0, f 0)v
F
Λ. The proof that Fis a well–defined
join operator is analogous.
For an example of how a tag–options lattice might be
used to construct a concrete properties domain, consider the
task of assigning reliabilities to components. In this case,
we define a set of component names Components :=
{c1, c2,· · · } to use as tags. The elements of the tag lattice
Components := P(Components)∂consist of sets of
component names. If an element of Components applies to
a given system, then we know that the system consists of at
least those components. The set of options is Probability =
{x∈R|0< x ≤1}. Finally, the tag–options lat-
tice Λ(Components,Probability(Components)) con-
sists of pairs (C, p)where Cis a set of components
known to comprise a given system and p(c)assigns a
range of possible reliabilities to each c∈C. Thus
Λ(Components,Probability(Components)) is a lattice
of constraints on component reliability ordered by specificity.
It can be used as part of a definition of a properties domain
in conjunction with other lattices that capture other relevant
system properties.
V. CONCLUSION AND FUTURE WORK
In this paper, we have demonstrated a formalization of
model and system semantics. Models abstract system seman-
tics; therefore, we can derive, or concretize, constraints on a
system from models of it. Conversely, given constraints on a
system, we can abstract a set of models that are consistent
with those constraints.
To formalize the soundness of this approach, we apply
abstract interpretation, which defines a correctness relation
between systems and constraints. If our abstraction and con-
cretization mappings between a given modeling formalism and
system constraints form a Galois connection between the two
domains, we can show that these mappings and the correctness
relation for system constraints induce a correctness relation
between systems and the models of the modeling formalism.
Through this lens, the process of model transformation be-
comes the process of concretizing system properties from one
model, then abstracting a second model from these properties.
We show that this process is sound; that is, if the initial model
is correct, then the final model will also be correct.
Future work will take several directions. We are currently
working on relating models of different aspects of a system—
in this case, reliability and topology. This work will demon-
strate both how topology affects system reliability by intro-
ducing dependencies between components and how reliability,
via the same dependencies and the constraints on system
functionality, constrains the choice of topologies for which
that definition of reliability holds.
We plan to further extend the work of this paper to other
model types and other choices of system properties. Expanding
the possible transformations will allow us to relate modeling
techniques from various system domains; for example, we may
apply a water distribution network analysis technique to a
power grid, or incorporate both cyber and physical models
into a cyber–physical model.
Another avenue of research is to expand the formalization
of models and systems to other metamodeling tasks. A salient
challenge in the design of complex systems is that of het-
erogeneous model composition: combining component models
that use various modeling formalisms into a single model
of a complete system. The abstraction and concretization
functions defined in this work provide a basis for developing
these connections. It may even be possible to perform this
composition at a higher level, enabling the creation of hybrid
modeling formalisms and associated solution and evaluation
techniques.
Finally, the task of developing this approach into a tool
for system designers will certainly present its own challenge.
Such a tool must be interactive and scalable to complex, real–
world systems, all without requiring the user to have a deep
understanding of the underlying theory.
REFERENCES
[1] N. Jarus, S. Sedigh Sarvestani, and A. R. Hurson, “Models, metamodels,
and model transformation for cyber–physical systems,” in 7th Interna-
tional Green and Sustainable Computing Conference, pp. 1–8, Nov.
2016.
[2] P. Derler, E. A. Lee, and A. L. Sangiovanni-Vincentelli, “Addressing
modeling challenges in cyber–physical systems,” tech. rep., Mar. 2011.
[3] T. H. Feng and E. A. Lee, “Scalable models using model transforma-
tion,” tech. rep., July 2008.
[4] K. Wan, D. Hughes, K. L. Man, and T. Krilavicius, “Composition
challenges and approaches for cyber–physical systems,” in 2010 IEEE
International Conference on Networked Embedded Systems for Enter-
prise Applications (NESEA), pp. 1–7, Nov. 2010.
[5] A. Bhave, B. Krogh, D. Garlan, and B. Schmerl, “Multi–domain
modeling of CPS using architectural views,” 2010.
[6] C. Ptolemaeus, ed., System design, modeling, and simulation: using
Ptolemy II. Berkeley, Calif: UC Berkeley EECS Dept, 1. ed., version
1.02 ed., 2014.
[7] Y. Xiong, E. Lee, X. Liu, Y. Zhao, and L. Zhong, “The design and ap-
plication of structured types in Ptolemy II,” in 2005 IEEE International
Conference on Granular Computing, vol. 2, pp. 683–688 Vol. 2, July
2005.
[8] B. Lickly, C. Shelton, E. Latronico, and E. A. Lee, “A practical ontology
framework for static model analysis,” in Proceedings of the Ninth ACM
International Conference on Embedded Software, EMSOFT ’11, (New
York, NY, USA), pp. 23–32, ACM, 2011.
[9] H. Feng, Model transformation with hierarchical discrete-event control.
PhD thesis, Citeseer, 2009.
[10] C. Brooks, T. H. Feng, E. A. Lee, and R. van Hanxleden, “Multimod-
eling: A preliminary case study,” tech. rep., Jan. 2008.
[11] S. Tripakis, C. Stergiou, C. Shaver, and E. A. Lee, “A modular formal
semantics for Ptolemy,” Mathematical Structures in Computer Science,
vol. 23, pp. 834–881, Aug. 2013.
[12] A. Goderis, C. Brooks, I. Altintas, E. A. Lee, and C. Goble, “Het-
erogeneous composition of models of computation,” Future Generation
Computer Systems, vol. 25, pp. 552–560, May 2009.
[15] G. Franceschinis, M. Gribaudo, M. Iacono, N. Mazzocca, and V. Vit-
torini, “Towards an object based multi-formalism multi-solution mod-
eling approach,” Proceedings of the Second Workshop on Modelling of
Objects, Components and Agents Aarhus (MOCA02), Denmark, vol. 26,
no. 27, pp. 47–65, 2002.
[13] V. Vittorini, M. Iacono, N. Mazzocca, and G. Franceschinis, “The
OsMoSys approach to multi-formalism modeling of systems,” Software
and Systems Modeling, vol. 3, pp. 68–81, Nov. 2003.
[14] E. Barbierato, M. Gribaudo, and M. Iacono, “SIMTHESysER: a tool
generator for the performance evaluation of multiformalism models,”
tech. rep., Universit´
ı degli Studi di Napoli, Belvedere Reale di San
Leucio 81100 Caserta, Italy, 2012.
[16] M. Iacono, M. Gribaudo, and E. Barbierato, “Exploiting multiformalism
models for testing and performance evaluation in SIMTHESys,” ACM,
2011.
[17] G. Clark, T. Courtney, D. Daly, D. Deavours, S. Derisavi, J. Doyle,
W. Sanders, and P. Webster, “The M ¨
obius modeling tool,” in 9th
International Workshop on Petri Nets and Performance Models, pp. 241–
250, 2001.
[18] S. Gaonkar, K. Keefe, R. Lamprecht, E. Rozier, P. Kemper, and
W. H. Sanders, “Performance and dependability modeling with M¨
obius,”
SIGMETRICS Performance Evaluation Review, vol. 36, pp. 16–21, Mar.
2009.
[19] C. Buchanan and K. Keefe, “Simulation debugging and visualization
in the M¨
obius Modeling Framework,” in Quantitative Evaluation of
Systems (G. Norman and W. Sanders, eds.), no. 8657 in Lecture Notes
in Computer Science, pp. 226–240, Springer International Publishing,
Sept. 2014.
[20] J. De Lara and H. Vangheluwe, “AToM3: A tool for multi-formalism
and meta-modelling,” in FASE, vol. 2, pp. 174–188, Springer, 2002.
[21] T. H. Feng, M. Zia, and H. Vangheluwe, “Multi–formalism modelling
and model transformation for the design of reactive systems,” in
Proceedings of the 2007 Summer Computer Simulation Conference,
SCSC ’07, (San Diego, CA, USA), pp. 505–512, Society for Computer
Simulation International, 2007.
[22] J. De Lara, H. Vangheluwe, and M. Moreno, “Using meta-modelling and
graph grammars to create modelling environments,” Electronic Notes in
Theoretical Computer Science, vol. 72, no. 3, 2002.
[23] “CHESS Project Website - CHESS.” http://www.chess-project.org/.
[24] “CONCERTO Project.” http://www.concerto-project.org/.
[25] L. Montecchi, P. Lollini, and A. Bondavalli, “A reusable modular
toolchain for automated dependability evaluation,” in Proceedings of the
7th International Conference on Performance Evaluation Methodologies
and Tools, pp. 298–303, ICST (Institute for Computer Sciences, Social-
Informatics and Telecommunications Engineering), 2013.
[26] V. Bonfiglio, L. Montecchi, F. Rossi, P. Lollini, A. Pataricza, and
A. Bondavalli, “Executable models to Support Automated Software
FMEA,” pp. 189–196, IEEE, Jan. 2015.
[27] A. de Matos Pedro, D. Pereira, L. M. Pinho, and J. S. Pinto, “Towards a
runtime verification framework for the ada programming language,” in
Reliable Software Technologies–Ada-Europe 2014, pp. 58–73, Springer,
2014.
[28] C. Kong and P. Alexander, “The Rosetta meta-model framework,” in
10th IEEE International Conference and Workshop on the Engineering
of Computer-Based Systems, pp. 133–140, Apr. 2003.
[29] J. Streb and P. Alexander, “Using a lattice of coalgebras for heteroge-
neous model composition,” in Proceedings of the MoDELS Workshop
on Multi-Paradigm Modeling, pp. 27–38, 2006.
[30] N. Frisby, M. Peck, M. Snyder, and P. Alexander, “Model composition
in rosetta,” in 2011 18th IEEE International Conference and Workshops
on Engineering of Computer Based Systems (ECBS), pp. 140–148, Apr.
2011.
[31] P. Alexander, “Rosetta: Standardization at the system level,” Computer,
vol. 42, pp. 108–110, Jan. 2009.
[32] P. Cousot and R. Cousot, “Abstract interpretation: a unified lattice model
for static analysis of programs by construction or approximation of
fixpoints,” in 4th ACM SIGACT-SIGPLAN Symposium on Principles of
Programming Languages, pp. 238–252, ACM, 1977.
[33] F. Nielson, H. R. Nielson, and C. Hankin, Principles of Program
Analysis. Berlin, Heidelberg: Springer Berlin Heidelberg, 1999.
[34] B. A. Davey and H. A. Priestley, Introduction to Lattices and Order.
Cambridge University Press, 2 ed., 2002.
