CATS est une plate-forme à services orientée transport et ciblant les environnements mobiles. Elle permet de prendre en compte le contexte d'exécution et d'adapter en fonction l'architecture de l'application afin de permettre à l'utilisateur de bénéficier du maximum de services utiles à un moment donné. Par exemple un véhicule peut vouloir utiliser un service de réservation de place de parking à partir du moment ou un nombre assez important de voisins autour de lui l'utilise également. Ou encore un véhicule arrivant dans un parking souterrain souhaiterait pouvoir télécharger les services et ressources lui permettant de se localiser et d'évoluer dans cet environnement. CATS facilite la mise en oeuvre d'une telle solution. Le framework s'appuie sur OSGi et iPOJO pour le téléchargement, la connexion et l'assemblage des services.
Exploring the Future Potential of AI-Enabled Smartphone Processors
CATS: A Context-Aware Transportation Services Framework for Mobile Environments
1. + LAMIH
L A B O R AT O I R E
D’ A UTOMATIQUE
DE MECANIQUE ET
D’ I NFORMATIQUE
INDUSTRIELLES
ET HUMAINES
Dana Popovici (PhD student), Mikael Desertot (co-adviser), Sylvain Lecomte (adviser)
2. 2
+
Plan
! Introduction
! Circumstances of our work
! Domain & goal
! The proposed framework – for transportation applications
! Context of execution – what is context?
! Architecture – on top of OSGi
! VESPA – example of a transportation application
! Conclusion & perspectives
3. 3
+
Circumstances of our work
! Nowadays: important technological advancements
! PDA; Smartphones (with GPS, Wi-Fi, …)
! Information & services available everywhere
! Existing applications that make use of such technology
! Location based services (using GPS): itinerary; POI; traffic information; …
! Cooperation applications between users: guided museum visits; file sharing; …
! Limits of the applications
! isolated applications – no cooperation between applications
! lack of flexibility – example: GPS navigation in a tunnel
! diversity of architectures
! lack of an unified framework to model and manage applications
4. 4
+ Domain
! Transportation applications for mobile devices (Smartphone, tablet, …)
! Assist users traveling from one place to another
! GPS navigation + accidents notification + POI + parking + …
React to context changes
!
What is interestingto installhighway?
! Easy on the and use What about in a city?
Highway City
accident
!
ke !
Bra
Shop City POI
nt
ide Gas
acc red !
o
ign
Shop
Gas
4 5
5. 5
+ Constraints & challenges
! Constraints
! Limited device resources
! small screen; little memory; …
! Need for communication – infrastructure access
is not ensured
! in-car devices (no GSM); area without 3G coverage
! The user can't manage the device at all time
! especially drivers
! Challenges
! Users are highly mobile & distributed
! both the user and her/his neighbors move
! The context evolves
! city/highway; indoor/outdoor; new neighbor; GPS
signal lost;…
6. 6
+
Scenario of use
! A driver using an application on
the mobile phone
! navigation + parking place service
(with simple broadcast protocol)
! the underground parking uses a
dedicated parking place service
! the server & a user have the service
! Problems
1. how to download a service?
2. how to choose which one?
3. how to connect it to the
existing application?
! Currently: not possible
7. + Context-Aware Transportation Services 7
(CATS) Framework
! A framework on mobile devices (Smartphone, in-car device,…) for
transportation specific applications:
1. Context-Aware: applications react to context changes by reconfiguring or
replacing services
2. Transportation: specific context elements
3. Services: modular applications built of services
4. Framework: simultaneous management of the applications
Framework
Application 2
Context
Application 1 manager
Service Bb
Service Da
Trader
Service Aa Service Ca
Execution
Service Ba Service Ea manager
8. 8
+
CATS Framework
1. Taking into account the context
2. Modular architecture
3. Service research and installation
Framework
Application 2
Context
Application 1 manager
Service Da
Trader
Service Aa Service Ca
Execution
Service Ba Service Ea manager
9. 9
+
The context
! Context is all information that can be used to characterize the
situation of an entity [Dey and Abowd, 1999]
! a system is context-aware if it uses context to provide relevant services &
information with respect to the user's task
! Who uses context and which elements?
! all mobile applications that are in frequently changing environments
! elements: sensor data (temperature, sound, …); personal context (user's
schedule, preferences, …); services available in proximity; etc.
! impossible to model all the context !!
10. 10
+
Context in transportation
! Our applications assist users on the move
! Goal: don't stop working & adapt to the context
! How do we adapt?
! replace services (they don't work / they're not suited)
! download & install new services
! What are the domain characteristics?
! high mobility of the users
pedestrians, passengers (bus, train, …), drivers (city, highway)
! unstable communication network
infrastructure connection loss, changing neighbors
! need to function in ad-hoc
(example: notification of an accident or emergency breaking)
11. 11
+
Context elements
! The device – services may be specific for a device or need certain
resources (important at download!)
! The execution framework – services have dependencies which must be
resolved (important at download!)
! The environment – changes constantly and influences the performance of
the services; it determines the reconfiguration or replacement of services
! The user – can influence the behavior of some services
Context
DeviceCtx ExecutionCtx EnvironmentCtx UserCtx
Software Hardware Services Data Position Network Use External Time Profile Prefers
12. 12
+
Approach
! A context element can determine the stopping of a service
! an equivalent service must be found, independent of that element
! example: positioning with GPS / Wi-Fi
! Some services are context-dependent
! they need to know the value of an element to configure parameters – example:
traffic event notification on the highway / in the city
! equivalent services based on the context
! Context monitoring with a publish & subscribe mechanism for the
context elements
13. 13
+
CATS Framework
1. Taking into account the context
! Context Manager – takes snapshots of the context elements
2. Modular architecture
3. Service research and installation
Framework
Application 2
Context
Application 1 manager
Service Da
Trader
Service Aa Service Ca
Execution
Service Ba Service Ea manager
14. 14
+
CATS Framework
1. Taking into account the context
2. Modular architecture – service based
! OSGi framework
3. Service research and installation
Framework
Application 2
Context
Application 1 manager
Service Da
Trader
Service Aa Service Ca
Execution
Service Ba Service Ea manager
15. 15
+
Execution Manager
! Needed for extra functionality on top of OSGi
! Manages services with respect to the context
! stops services which are no longer conform with the conditions
! starts an equivalent service which is suited
! handles the situation when no equivalent is present on the device
! launches a search for the service on neighboring devices
16. 16
+
CATS Framework
1. Taking into account the context
2. Modular architecture
3. Service research and installation
! service description; discovery
Framework
Application 2
Context
Application 1 manager
Service Da
Trader
Service Aa Service Ca
Execution
Service Ba Service Ea manager
17. 17
+ Service discovery
(in the transportation domain)
! Infrastructure access is not always available – search near by
! ideally: have a maximum of services on the device (when possible)
! Constraints:
! download before the devices are too far apart – choose "best" device
! services should be of small size
too fast ok
too far
service?
18. 18
+
The Trader
! Goal: retrieve as fast as possible a suitable service
! Criteria:
! service functionality – does it do what we want?
! context dependency – is it suited for the current context of the device?
! relative movement of the devices – is there enough time to download?
! Functioning of the Trader [work in progress]
! the device sends a request for a service to neighboring devices
! the neighbors having an implementation of the service answer
! the device chooses the "best" service
! the device downloads & installs the service
19. 19
+
So… the CATS framework
! is based on OSGi – allows to install & deploy services on the fly
! has bundles to manage the framework and the applications
! Context Manager; Execution Manager; Trader
! uses equivalent services based on context situations and
encourages a maximum of local services
! 3G/Internet is not always available
! Which applications run on CATS ?
20. + VESPA 20
! uses V2V communication to share information about events on the road
! information dissemination => dissemination protocol
! estimation of event relevancy => based on GPS coordinates
! user notification => information display on screen
21. + VESPA on CATS 21
! Several map services (for event notification):
! no map – display distance & direction to the event
! google – needs 3G or Internet
! local – simplified map to download (example: user made map of a village)
! Several parking place protocols:
! dissemination – risk of competition
! reservation protocol – increased number of messages
Framework
Application 2
Context
VESPA manager
Service Da
Trader
EP Positioning
Execution
Dissemination Service Ea manager
23. 23
+
Conclusion
! Despite the large amount of research in the domain of mobile
applications, few works consider the creation of a dynamic
framework with services installed on the fly
! Our goal is to propose a framework suitable for the transportation
domain, hosting flexible applications
! easy context adaptation through services exchange
! continuous functioning in all environments, with minimal user intervention
! The OSGi framework enables us to achieve these goals
24. 24
+
Work in progress & future work
! The evaluations were done on devices with very limited mobility
! the influence of mobility must be evaluated further
! The distributed trader is not finalized
! a query language must be developed, to allow a fine description of the
needed service based on context elements
! Improvement of the service reconfiguration for a better adaptation
to the context changes
25. + LAMIH
L A B O R AT O I R E
D’ A UTOMATIQUE
DE MECANIQUE ET
D’ I NFORMATIQUE
INDUSTRIELLES
ET HUMAINES
Merci pour votre attention!
Dana Popovici (doctorante), Mikael Desertot (encadrant), Sylvain Lecomte (directeur de thèse)