Entity Context Metamodel

The goal of the Entity Context Metamodel (ECMM) is the description of the context that an entity is able to perceive from the environment.

The entity Context Metamodel is part of the intra- entity view of the Information Layer models.

Entities have their “own view” of the context, the information that comes from the environment modifies this view which is “absorbed” by the Entity Core model to be processed.

The perception of the environment from the entity point of view is divided into different layers that represent context characteristics. Thus, each layer represent an aspect of the entity context. As an analogy, we can state that an entity is like the Earth, it has layers that wrap the core. On Figure 18 we show an schematic description of it.

Entity Context schematic description
Figure 18: Entity Context schematic description

The following list describes the each layer:

  • The Context-aware Entity Layer is the external representation of the entity to the eyes of the environment. It sets the limits between those things that are part of the environment and those that are part of the entity. And it acts as an interface between the entity and the environment that surrounds it providing information to the environment and consuming information from it.
  • The Sensor Layer is just below the context-aware entity layer. It interprets information flows from the environment that modifies the entity context and core states.
  • The Social Layer is in charge of processing the information related to the social context of the entity. It is close related to the Social metamodel and social expressions
  • The Task Layer is in charge of processing information related to the task context of the entity. It is close related to the Task metamodel and task expressions.
  • The Space Layer is responsible for processing information related to the space context of the entity. It is close related to the Space metamodel (SpMM) and space expressions.
  • The Logic Layer processes information related to the data exchanged through the information flows. This layer is close related to the Task Metamodel, logic expressions and Data Expressions.

All these layers cover the core that processes the information gathered from the environment to act accordingly.

The Figure 19 represents the interaction between an entity (context and core) and the environment. Each entity has a role according to the influence of them in the environment and how they are affected by it. On the left, Entity 1 it plays the role of a sensor because it captures environment changes through the description of relevant situations (Situation A, Situation B, Situation C, Situation D etc.).

Entity environment concept
Figure 19: Entity environment concept

Situations were described in terms of conditions (C1, C2, C3, C4, etc.). Thus, when these conditions are satisfied, the state of the context changes to adjust its perception of the environment and eventually triggers an event of the core of the entity. This event generates an information flow (represented by the Information Flow arrow) that is consumed by Entity 2 which follows the same procedure as Entity 1.

Although the Entity 2 “perceives” the incoming information flow from Entity 1, it is not considered a sensor because it gets information from another entity instead of the getting the information directly from the environment.
It is considered an actuator because it affects the environment as result of the event triggering.

The key parameters used to describe these concepts are:

  • The entity context
  • The context situation
  • The context condition
  • The data definition

The Entity Context

The entity context represents the context of an entity. It provides a layer that is used as an interface between the environment and the entity core. It intercepts incoming information flows and interprets them before passing them to context situations.

The Context Situation

A Context Situation represents a particular state of the context that is relevant to the entity when performing a task. After an Information Flow reaches the Entity Context, it is matched to a Context Situation to adjust the the context state accordingly. This matchig is defined in terms of Context Condition regarding the Context State. Once the context state was updated, the information flow is forwarded to the Entity Core to modify Entity’s internal state. As result of the Entity internal state modification, an ongoing information flow may be generated to act on the environment (if the entity also plays the role of actuator).

The Context State

The context state of an Entity is defined in the Context Memory.
As in human beings, the Context Memory stores information and patterns.
Patterns defined in terms of regular expressions representing the relevant characteristics of the context in which the entity should react to get a “view” of the entity surrounding environment.

A memory usually defines two operations: update and match. While the update operation “writes” or “stores” information on the memory, the match operation “queries” the memory to obtain information. Both, the update and match operations receive an expression as parameter. This expression provides the update operation the data to be stored or written, and to the match operation the information is used as a condition to be satisfied by the memory.

To represent the entity context state, five types of memories were defined:

The Holder Memory

The Holder Memory (HM) provides designers with the ability to store and match one piece of information.

For instance, suppose that you have a Holder Memory (aHM) and we store the Data A expression in aHM. If you match aHM to the Data A Memory Condition, the result is TRUE. However, if later on, you update the aHM with the Data B expression and match it o the Data A Memory Condition, the result is FALSE. Note that, if you match the aHM to the (Data A + Data B) Memory Condition, the result is TRUE.

Consequently, the Holder Memory just stores the last expression.

The Stack Memory

The Stack Memory stores and matches information according to data change history.

For Instance: Suppose that you have a Stack Memory (aSM) and you store information (Data A) using the update operation. Then you store the (Data B) information in aSM. The result is Data B ,Data A . Therefore, although aSM matches the Data A ,∗, Data B ,Data A expression, it does not match the Data A expression.

The Time Memory

The Time Memory provides designers with a time tracker memory which defines two states: on / off. This state changes using the update operation.
When the timer is swiched on through the update operation, it takes a time constraint in miliseconds. After this period, the state of the timer changes to off. The match operation checks if the state of the memory is on or off.

The Logic and Dictionary Memories

These memories work in tandem because the update operation is performed on the Dictionary Memory and the match operation is performed on the Logic Memory.

The Dictionary Memory is employed as an associative memory that relates keys to values. Thus, the update operation on the Dictionary Memory takes two parameters: the key and the value.

The Logic Memory stores a logic expression that is satisfied, or not, according to a Dictionary Memory. Therefore, expression variables in a Logic Memory are replaced by the values stored in a Dictorany Memory.

For instance: Suppose that you have a Dictionary Memory (aDM) and you store the 234 value under the “aValue” key and the 34 value under the “aValue2” key.

The logic expression aValue > 200 is satisfied and the aValue2 < 200 is not satisfied.

Note that Dictionary Memory does not support history like the Stack Memory because if you store the 500 value under the “aValue” key you overwrite the value on the key. It is neither a Holder Memory because the value on “aValue2” is unaltered.

The Context Condition

The Context Condition represents a particular condition on the context state regarding to a context feature. So, we have defined two types of conditions:

  • Sensing Conditions are in charge of detecting incoming/ongoing information flows from/to other entities. They are close related to information flows defined in the Information Flow model.
  • Memory Conditions are responsible for defining conditions regarding the entity context state which is defined by a set of Memories. Thus, context conditions execute the match operation on context memories to check if they are satisfied or not.
The Context Action

Context Actions define how to react according to the Context State of an entity. This reaction is performed when a situation arises (all Context Conditions defining a Context Situation are satisfied by the entity Context State). Therefore, Context Actions are in charge of executing the update operation on Context Memories.

The Data Definition

The Information Flow model defines the relationship among entities through Information Flows. These Information Flows exchange information among these entities. The data definition for this model is based on the DataDefinition hierarchy defined in the information flow model. The main difference lies on the fact that while in the information flow model definition reaches the the variable or a terminal level in this model the information reaches the terminal level in all cases.

The Entity Context metamodel is defined in Figure 20.

Entity Context Metamodel
Figure 20: Entity Context Metamodel

The Figure 21 shows the Entity Context Model of a Sensor Pooling sample. It defines two entities, the DataProvider (the Sensor) and the DataConsumer (the Application). While the DataProvider provides information through an incoming information flow (getData) expressed in terms of data definitions that is referenced by a data variable belonging to the DataType type; the Data Consumer entity gets this data through this information flow that is called when the onPool situation matches the timer condition. The Timer condition is expressed in terms of a Timer memory that is set to on for a period of 5000 ms.

The pooling pattern
Figure 21: The pooling pattern

You can reference this work as:
Ricardo Tesoriero, José A. Gallud, María D. Lozano and Víctor M. R. Penichet. CAUCE: Model-driven Development of Context-aware Applications for Ubiquitous Computing Environments
Journal of Universal Computer Science,  Vol. 16,  No. 15, pp. 2111-2138. 2010. Link: http://www.jucs.org/jucs_16_15/cauce_model_driven_development