Différences

Ci-dessous, les différences entre deux révisions de la page.

--- projets:ocs:20142015:gr8 [2015/01/08 18:01] – [Hardware Specifications and Distribution of the connected Object] palma
+++ projets:ocs:20142015:gr8 [2015/02/18 09:40] (Version actuelle) – [Software Specifications and Distribution of the connected Object] palma
@@ Ligne 24: / Ligne 24: @@
 ==== Scenarios of the Project ====
- === 1. Awaking up ===
+The //object// exposes a very simple interface allowing to switch on/off a lamp and a buzzer. The interface allows also getting the state of each of them.
+Some usage scenarios are depicted here below:
+ === 1. AlarmLight application ===
+The primary purpose of the //object// is to wake-up user at the right time! So, on top of this simple interface is built an application (using WComp for fast prototyping) permitting the following scenarios:
-) Bob fell asleep late yesterday evening and he's got an appointment quite early this morning. However he didnt take care of his alarm clock : the //object// is connected to his calendar and knows at what time Bob need to be waken up.
+) Bob fell asleep late yesterday evening and he's got an appointment quite early this morning. However he didn't take care of his alarm clock : the application, from Bob's calendar web service (Google agenda, but it could be any other similar web service), knows at what time Bob need to be waken up.
-) Since the //object// is "smart", it can deduce from the meeting location and Bob's position, the distance he will have to travel to reach the appointment. Then, the //object// connects to the real time trafic information and dynamicaly adapt the hour at which Bob need to be waken up.
+) Also, the application is connected to a live traffic web service. From Bob's position and the meeting location (metadata added by Bob in his agenda) it will get the expected travel time needed by Bob to reach his appointment. The application dynamically adapts the hour at which Bob need to be waken up (the lamp and the buzzer have to be switched on).
-) When it's time to wake-up, the //object// switch on an embedded lamp in order to wake up Bob. If Bob doesn't deactivate the //object// by touching it then a sound is emitted till Bob stop it.
+) When it's time to wake-up, the lamp and a buzzer are switched on in order to wake up Bob. Once waked-up, Bob deactivate the light and the buzzer sound emission by touching the object.
 ) Of course, Bob can still switch on the lamp embedded in the //object// as soon as he want by touching it (and by touching it again to switch it off).
-=== 2. Security (not implemented) ===
+=== 2. The object as a service in an orchestration ===
-Bob, being asleep, needs to be waken up in case of threat, fire or gas emission occurrence.
+The //object// proposes services that are used in our application but it can also be interesting to make the services available for some other applications. For instance, we could imagine some smoke or temperature sensors located somewhere in Bob's house. We can imagine an application which connect the sensors output to the //object// buzzer and/or lamp through a threshold and switch it on when sensors reaches some unexpected values...
-The //object// can detect gas and smoke and wake up Bob immediately by switching on the lamp and emitting a continuous sound.
-=== 3. The object as a service in an orchestration ===
+Actually there are plenty of applications that can use our simple buzzer and light and divert from the primary //object// usage.
-The //object// proposes services useful for the users but it is also interesting to make it available in order to compose more complex behaviors. For instance, the object will have access to the user agenda or real time road traffic. Such information, available from the //object// could be used for the composition of a complex application. Also, the //object// could be used as a sensor emitting an event at the wake-up time (or when the light is on) that could be used to fire-up an event as input to an other service.
 ==== Connected Object Description (Nice students proposal) ====
@@ Ligne 120: / Ligne 123: @@
 ==== Software Specifications and Distribution of the connected Object ====
+== Overview ==
-// BE CAREFUL : minimal logic must be embedded in the object. The main purpose of the object is to provide access to the its actuators and sensors//
+{{http://image.noelshack.com/fichiers/2015/08/1424249546-16374577289-5827311736-o.png?600x150}}
 == Software Specifications of the connected Object ==
@@ Ligne 127: / Ligne 131: @@
 ** Web Service for Device Specifications **
-// add the description of the Web Service for Device interface of the connected Object //
+ The main purpose of the object is to give acces to its services through UPnP protocol. In our case, the UPnP services are :
+	- Turning on and off the light.
+	- Turning on and off the alarm.
+	- The current State of the light.
+	- The current State of the alarm.
+ In addition of the above, the object owns a physical interface which consists of a touch sensor. This embedded actuator provide the following features:
+	- If the alarm is turned off, each pressure alternately switch on and off the light with each pressure.
+	- If the alarm and light are on, the next pressure turns off the alarm without switching off the light.
+	- If the alarm is on and the light is off, the next pressure turns off the alarm and switch on the light.
 ** Application Protocol over Bluetooth link of the object  **
@@ Ligne 147: / Ligne 161: @@
     * Binary distribution of the developed software for the object and how to install (ex. DLL of new beans and wcc of the WComp the assembly) :
     * Sources distribution of the developed software  and how to build the binary distribution (ex. sources of new beans for WComp):
-// including the list and the  links for all prerequired software //
-  * Mobile Phone Software
-    * The kind of  smart phone that you chose (Reference, Android ? IoS ? Windows Phone X.X ?)
-    * Binary distribution of the developed software for the phone and how to install  :
-    * Sources distribution of the developed software  and how to build the binary distribution :
 // including the list and the  links for all prerequired software //
-==== Software Specifications and Distribution of the high level service for the user ====
+wcc of the embedded software:
-// BE CAREFUL : Here is the main purpose of your project. //
+ [[https://drive.google.com/open?id=0ByF5Pdi4nQlASDNuVUhGU3k3OUU&authuser=0]]
-// BE CAREFUL : The connected object is only a part of the composition/orchestration between other services to build a high level service //
+Beans to install in Bean/ directory in the embedded device
-// BE CAREFUL : Don't forget that the added value and intelligence of the high level service are based on the use of multiple web services like meteo / agenda ... //
+ [[https://drive.google.com/open?id=0ByF5Pdi4nQlAVEVBMEFfS1VRYlU&authuser=0]]
-// BE CAREFUL : The use of a user  terminal and any other Man Machine interface in order to use directly the object is not the purpose of this module //
+Sources of the embedded Beans:
+ [[https://drive.google.com/open?id=0ByF5Pdi4nQlASzdfd1RCcWJaLU0&authuser=0]]
-== Software Specifications of the High Level Service for the user ==
-// add the description of Specifications of the High Level Service for the user //
+  * Mobile Phone Software
+    * The kind of  smart phone that you chose (Reference, Android ? IoS ? Windows Phone X.X ?)
+    * Binary distribution of the developed software for the phone and how to install  :
+    * Sources distribution of the developed software  and how to build the binary distribution :
+// including the list and the  links for all prerequired software //
+==== Software Specifications and Distribution of the high level service for the user ====
-// including the lsit of the Web Services you use to design new High Level functionalities for the user //
-// Example: use of Meteo Web Service to manage the watering of a plant equiped with a connected object //
+== Software Specifications of the High Level Service for the user ==
+The high level service orchestrates the three following WebServices :
+	* Calendar WebService, in our case, Google Calendar. This service is used to know the time of the first user appointement in the morning.
+	* LiveMap WebService,
 == Software Distribution of the High Level Service for the user ==
@@ Ligne 182: / Ligne 197: @@
     * Binary distribution of the developed software for the object and how to install (ex. DLL of new beans and wcc of the WComp the assembly) :
     * Sources distribution of the developed software  and how to build the binary distribution (ex. sources of new beans in WComp):
+wcc of the orchestration software :
+https://drive.google.com/open?id=0ByF5Pdi4nQlAYVExbEZ6RFNUek0&authuser=0
+bridge application for the Google Calendar WebService:
+https://drive.google.com/file/d/0ByF5Pdi4nQlAb2QwUUM1QTFnQ0k/view?usp=sharing
+Beans to add in Bean/ directory:
+https://drive.google.com/file/d/0ByF5Pdi4nQlAcDdjOXZzakVLQnM/view?usp=sharing
+Sources of the Beans :
+https://drive.google.com/file/d/0ByF5Pdi4nQlAYVBGOGNvU0ppMnM/view?usp=sharing