Situation Manager Component (SMC)

While receiving a list of valid situations from the other components TMC, LMC, AMC, etc.), the SMC (see Figure 41) constructs one final list containing the situations (received from the other components) according to their occurrences and their projections. In this way, this component delivers two final lists of situations as a final output of the EM. These situations could be either situations that will be starting or situations that are no longer valid and need to end.

In order to identify the starting situations, the SMC calculates for each received situation the number of projections and axes represented in that projection and compares them with the input of the other components (TMC, TLC, etc.). If the number of incoming instances of a situation (verified by the primitives) matches one of the projections, it is considered as a possible situation to start (to start a situation, it should verify at least all the primitives of one projection). For example, if a situation S0 happens when the first projection is verified (user is home at 5 pm), the SMC should receive 2 instances of S0 coming from TMC and LMC.

For ending situations, the SMC uses the opposite mechanism: if at least, one occurrence is not sent to the SMC, it considers that situation as a stopping situation (to break the situation, it is enough that one primitive verification fails). Using the same example of S0, if the user leaves the house and the SMC receives only one instance (coming from TMC), it means that the projection of S0 is no longer verified then it should be stopped.

Then, the SMC verifies the exceptions related to situations about to start. If they violate any of the exceptions they are retracted from the starting list. For ending situations, the exceptions can expand the lifespan of a situation as long as that exception is valid.

This component has also a list of Active Situations, which represents situations that are already running (still verify the primitives of their projections). A possible starting situation will not necessarily be an active one, as it might be filtered later by one of the next modules (CE, AO, or ACL). For ending situations, however, they must be already active in order to be stopped.

Finally, the final lists of situations are transferred to the Condition Evaluation (CE) module.

Figure 41 - The Situation Manager Component

In this example, we consider the previously described House Alarm Situation (see Figure 34). We describe below a number of various situations that could happen to the user daily.

In Table 11, we present an example of a user having the situations described above. In this example, the user has three devices where LLA is installed. We follow him/her on three steps where the user changes time, location and activity over the day. We consider that the IC only extracts data those three times. Initially, we propose that S0 (House Alarm Situation in Figure 34) is an active situation, the time is 6 am; the day is Monday and he/she is at home.

In table 11:

 T: Time;  L: Location;  A: Activity;  Sits: Situations;

Table 11: Situation analysis by the Event Manager's components

Device 1 (Smart-Watch) Device 2 (Tablet) Device 3 (Smart-Phone)

Input Input Input Event Manager

T L A T L A T L A DC TMC LMC AMC TLMC TAMC LAMC SMC

S t e p 1

Data 07:00 home free 08:00 home free 07:00 home free  07:00 home free 07:00, home 07:00, free home, free Valid. Sits S1, S2 S0, S1, S2, S9 S8 -- -- --  Activ. Sits S0 Start. Sits S1, S2 End. Sits S0 S t e p 2

Data 10:00 Office work 10:00 home work 10:00 Office work  10:00 Office work 10:00, Office 10:00, work Office, work Valid. Sits S4 S4, S6 -- S3 -- --  Activ. Sits S1, S2 Start. Sits S4 End. Sits S1, S2 S t e p 3

Data 18:00 MCenter free 18:00 home free 18:00 Mcent free  18:00 MCent free 18:00, MCent 18:00, free MCent, free Valid. Sits S7 S7 S8 -- -- --  Activ.Sit S4 Start.Sit S7 End. Sits S4

84

In Step 1, the data extracted from all the devices is the same (07:00, Home, Free). The DC distributes the data to the rest of components (running on the Smart-Phone). We considered that S0 (House Alarm Situation) was already active. After all, components send the valid situations to the SMC, it calculates the starting and ending situations. It decides to stop S0, because one of its primitives (Before(6,20)) is no longer verified, and to start S1 (Sleep/Wakeup) and S2 (Breakfast Situation) because all the primitives in their respective projection are verified.

In Step 2, the user left home but left his/her tablet there. Therefore, the data extracted from that tablet will not be sent to the EM. The data considered comes from the Smart-Phone and Smart-Watch (10:00, Office, Work). The DC distributes the data to the rest of components. After all, components send the valid situations to the SMC, it calculates the starting and ending

situations. It decides to stop S1 and S2 (already active), because their primitives are no longer

verified, and to start S4 (First work shift situation) because all the primitives in its projection P1 are verified.

In Step 2, the data considered still comes from the Smart-Phone and Smart-Watch (18:00, MCenter, Free). The DC distributes the data to the rest of components. After all, components send the valid situations to the SMC, it calculates the starting and ending situations. It decides to stop S4 (already active) and to start S7 (Massage session situation).

This example presents the workflow of the cross-device detection mechanism. The output (Staring situations, Ending situations) of this mechanism is sent to the rest of the architecture (CE, AO, ACL) in order to finish the rest of the process.

3. Conclusions

To summarize, our proposal provides a mechanism able to detect, formalize and understand the user context. The EM provides a set of components working simultaneously and independently in order to detect events and understand situations regardless of the source. However, detecting situations is not our main goal. In related works, most application use rule- based languages to detect events and to understand the context, others use information collected from sensors in order to formalize a context from that raw data.

Our approach differs in the way we address context detection as we aim our model to be centered on the user daily needs in a connected environment. This means that our mechanism can handle both basic and complex representations of everyday situations. It considers high-

85

level context understandable by the user and that does not need necessarily the presence of, a sensor network or a huge set of complex rules.

Our approach provides a light, dynamic and open to growth contextual model. The second phase of responding to the contextual change is handling this change on the service layer of the application. Therefore, the next chapter presents the situation control and handling strategy which is integrated into LLA and dedicated to offering an improved user experience.

86