the de facto standard, in MDE for building domain specific models and associated tools using generative techniques.
• Transformation engines and generators: that analyze certain aspects of models and then synthesize various types of artifacts, such as source code, simulation inputs, or alternative model representations [Sch06]. This ability to create artifacts from models helps ensure the consistency between application implementations and analysis information associated with the requirements captured by models. Moreover, MDE tools can impose domain-specific constraints and perform model checking that can prevent many errors from happening early in the life cycle of software development. In this thesis, we use two kinds of models: architectural models and data models. Architec- tural models to represent what components are present in the current AmI system, and the connectivity between them (sensors, agents, communication channels). While data models manage the attributes offered by each component, within a time dimension. The data models should reflect as well the continuous aspect of the physically sensed attributes. These models need to be adaptable at runtime when the context changes, for this reason, we present the [email protected] paradigm in the next subsection.
3.3
[email protected] for context representation
The [email protected] paradigm promises a new approach to MDE, by fading the boundary between design-time (the typical phase where MDE is employed) and runtime. These [email protected][MBNJ09] are abstract, yet always synchronized, representations of the running system. Any change of the abstraction implies an adaptation of the system at runtime. Conversely, a dynamic adaptation triggered by the runtime is reflected as well in the model. This abstract model, always synchronized with the running system, enables local or remote computations on the system. It can be used to add or remove a component, or to redeploy a distributed application to do load balancing.
The dynamic [email protected] platform follows the idea to keep at runtime (during the execution of a system) a model of the current running system as a reflection layer [DFB+12].
This reflexion model allows not only to introspect (analyze) the current state, but also acts as an intercession layer (ability to modify a system through model modifications). In order to ensure this property, a bidirectional causal link [MBNJ09] has to be built, which impacts the system at each modification applied on the model and vice-versa. Any change in the system appears in the model, and vice versa, any change in the model affects the running system. The synchronization between the real world and its abstraction needs to be fast enough to call the AmI system responsive in near real-time.
A typical usage of [email protected] is to manage the complexity of dynamic adaptation in complex, distributed and heterogeneous systems, by offering a more abstract and safer abstraction layer than reflection on top of the running system [FNM+12b]. In this thesis,
we consider [email protected] as the cornerstone to build applications for AmI, in order to keep the state of AmI system in sync with its abstraction model, in near real-time.
3.3.1 Requirements of [email protected]
The heterogeneity and distribution aspect creates specific requirements for [email protected] to be suitable to use in ambient intelligent systems. We present here these main requirements as listed by Fouquet et al. [FNM+12b]:
• Reduced memory footprints: The memory footprint of a [email protected] engine determines the types of nodes that are able to run this engine. The more demanding is the [email protected] engine in terms of memory, the more difficult it is to deploy it on the small devices (e.g. Android phones, gateways with low power CPUs), and the more centralized the application will be. This would reduce the reliability of the system: if the large devices fail or disconnect, the overall system cannot safely adapt anymore. Moreover, model exchanges for the synchronization of the system in this strategy would dramatically increase network load.
• Thread safety: A [email protected] is generally used in highly concurrent environ- ments. For instance, different probes integrated in a device can update a context model. This model is then used for triggering the adaptation reasoning process. This context model should enable safe and consistent read and write for the reasoners to take accurate decisions. The [email protected] infrastructure must ensure that the multiple threads of the application can access and modify the models without worrying about the concurrent access details. It must implement fast, yet safe, validation or reasoning algorithms on multi-core/thread nodes.
• Efficient model cloning: A device should be able to locally clone its own model for reasoning purposes so that it can reason on a fully independent and safe representation of itself, which can later on be re-synchronized with the current model. This criteria is very important for reasoning on models, where we want to try several variations on the current model (for instance, in an optimization problem execution).
• Lazy loading: it is a design pattern that defer the initialization of a model until the point at which it is needed. Lazy loading can improve the performance and efficiency of AmI systems in many levels, for example: initialization time, memory consumption and network traffic are kept as low as possible, due to the fact that only the useful parts of the model are loaded and only when needed.
3.3.2 Native Independent Versioning
Data composing the reasoning context of intelligent systems can have very different update rates. For instance, a topology related information can be updated every month whereas a sensor related data will be updated every millisecond. The development of such systems, driven by [email protected], implies an efficient strategy to manage these very volatile data together in a context model with static data. Indeed, saving the whole model for each modification offers a very poor performance, whereas creating timestamped elements for each change also leads to large and unmanageable models.
3.3. [email protected] for context representation
relation version v1
model element e1 model element e2
path version v1 path version v2 version v4 navigation context
Figure 3.1: Native versioning for model elements
To tackle these problems, Hartmann et al. [HFN+14a] proposed, a native versioning
concept for each model element. They defined that every model element can exist in a sequence of versions, attached to its unique identifier. They also defined model element relationships as links between unique identifiers, without the version information. They presented as well a navigation concept that always resolves the closest version to the one requested. For instance, if the requested version is v3, the navigation context will resolve the closest one v2 in case v3 does not exist. This is illustrated in figure3.1.
3.3.3 Time management
This model version can be used to simulate time continuity. For instance, at each attribute change, a new version of the attribute is created; and the current time can be used as the version ID. This method enables to model classical discrete time-series using the native independent versioning solution for each granular update. The time-continuity is simulated by the navigation context resolver which takes the closest version of the requested one [HFN+14b]. For example, if the sensor has pushed values at time t and t + 100, any get
request on the attribute between t and t + 100, let’s say at t + 50, will resolve the version stored at time t. However, this creates a discontinuity on the attribute-value dimension. A linear signal for example will be transformed to steps-shaped signal. However, fo physical attributes, we would expect that the value to change smoothly from time t to t + 100. Moreover, based on this discrete representation of versions, this approach still expects the enumeration capabilities of versions and thus is limited to face a high sampling rate from a sensor. For instance, at a high sampling rate of a constant signal, each sample will be saved in a new version, even if the value is still the same. The tree that manages the version resolution will increase in size a lot, affecting the performance of a lookup search. For these reasons, we propose an efficient and continuous model for IoT in chapter 6.
3.3.4 Eclipse Modeling Framework (EMF)
EMF [SBMP08] is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a metamodel specification described in ECORE, EMF provides tools and runtime support to create Domain Specific Languages (DSL) on top of the Eclipse platform. It produces a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Most important, EMF provides the foundation for interoperability with other EMF-based tools and applications.
However, EMF suffers from several limitations that make it not suitable for [email protected]. First, it has a large dependency set. In [FNM+12b], it has been shown that a standalone
JAR executable outside of the Eclipse tool (a Java archive that includes all dependencies) has a size of 15 MB for only 55 KB generated files. The large number and size of dependencies is one of the main limitations of EMF when the model must be embedded at runtime. Second, EMF does not provide thread safe accesses to the models [GvdHT09]. This requirement is important for a [email protected] infrastructure, because supporting dynamic and distributed architectures requires concurrent access to models. A third limitation, is the cloning overhead. As reported in [FNM+12a], EMF has a large memory footprint when
cloning a model, and it is slow. Forth, EMF has a poor performance when loading large models, and finally EMF does not manage time natively. For these limitations, we decided to use Kevoree Modeling Framework (KMF) instead of EMF because it is more suitable for the needs of AmI.
3.3.5 Kevoree Modeling Framework (KMF)
The Kevoree Modeling Framework or KMFi, is an open source alternative to EMF. KMF
was made to support a generic and efficient [email protected] infrastructure compatible with EMF. KMF addresses the limitations of EMF by offering the following features.
• Multi-thread access: In order to allow multi-threading, KMF deploys a protection against concurrent read and write accesses.
• Fast cloning and lazy loading: KMF has internal mechanisms to clone models fast, and in an efficient way (Refer to table3.1for a comparison between KMF and EMF [FNM+12a]). The fast cloning will allow us to execute mutations on models
faster, when performing optimizations. This will be discussed in more details in chapter8.
• Time-aware model: KMF treats time dimension as a crosscutting concern of data modeling. Indeed, model elements can independently evolve in time at different paces, so there is no need to enforce the sampling of all model elements at the same rate. KMF does not store snapshots of the entire model but rather only stores updated
i