Dealing with the need for Infrastructural Support in Ambient Intelligence

Dealing with the need for Infrastructural Support in Ambient Intelligence2 June 2009 @ School of Computing and Mathematics, University of Ulster, Jordanstown campusDr. Diego Lz-de-Ipiña Glz-de-ArtazaFaculty of Engineering (ESIDE), University of Deusto, Bilbaodipina@eside.deusto.eshttp://www.morelab.deusto.eshttp://www.smartlab.deusto.eshttp://paginaspersonales.deusto.es/dipina

IntroductionWhat is the endemic problem(s) of AmI precluding its wider deployment?Probably many factors but a very remarkable one is the ...“unfortunate” high demand on infrastructural support!!!SensorsActuatorsAutomation buses and protocolsWireless communication linksMiddlewareContext modelling and Reasoning enginesAnd so on and so forth ...

Research MotivationGiven that AmI is not possible without infrastructure ...How do we alleviate this “unfortunate” need?Our approach/research aim:Use and adapt low-cost off-the-shelf hardware infrastructure and combine it with intelligent middleware and interaction techniques to make “any” environment appear “intelligent”This talk describes several iterative research efforts addressing the infrastructure dependency issue

Talk OutlinePart 0: Bird’s-eye view of my research group and laboratory activities (5’)Part 1: Review my previous research work on solutions to address “the need for infrastructure of AmI” (35’)Iteration 1: Build your own sensing and reasoning infrastructureIteration 2: Concentrate on explicit user-environment interactionIteration 3: Leverage from Web 2.0 principles and map them to AmIIteration 4: Dealing with the heterogeneity, dynamic behaviour of existing instrumented environmentsIteration 5: Focus on a more specific application domain: AALPart 2: Review of current research lines & projects (10’)

MoreLab Research Group & SmartLab Research Laboratory @ University of Deusto

University of Deusto, BilbaoPrivate Jesuits' University founded in 1886 in Bilbao, Basque Country, SpainIt offers degrees on:Business & AdministrationLawPsychologyEngineeringSocial Sciences & Linguistics URL: http://www.deusto.es

Our Research Group:Created in 2003, there are 3 lecturers and 12 researchers:URL: http://www.morelab.deusto.esSpecialized on Mobile-Mediated Interaction, Internet of Things, Smart Objects, Semantic Middleware, AAL

Remote Control of Embedded Sensing Devices

Mobile-mediated Human-Environment Interaction

RealWidget: desktop widgets for the real world

RFID Glove (left) and RealWidget (right)

Prototyping an intelligent chair (FlexChair) withan embedded wireless sensor node

AmI-enabling Semantic Middleware

Our Research Lab: SmartLabA research laboratory focused on AmI researchAim: create an intelligent working space with a double purpose:Provide infrastructure to host and attract research projects related to AmIAssess the suitability of AmI as a mechanism to enrich and improve the working daily activities of a group of usersURL: http://www.smartlab.deusto.es

Iteration 1: Build your own essential sensing and reasoning infrastructurePhD Dissertation: Visual Sensing and Middleware Support for Sentient Computing

Iteration 1: Build your own essential sensing and reasoning infrastructureBasque GovernmentEducation DepartmentLaboratory for Communications Engineering (LCE)Cambridge University Engineering DepartmentEngland, UKAT&T LaboratoriesCambridgeGoals:build Sentient Spaces = computerised environments that sense & reactclose gap between user and computer by using contextmake ubiquitous computing reality through Sentient Computingby building your own low cost easily deployable infrastructure to make it feasible!!!Developed during PhD research in University of Cambridgehttp://www.cl.cam.ac.uk/research/dtg/Supervised by Prof. Andy Hopper

Sentient ComputingSentient Computing = computers + sensors + rules:

distributed sensors capture context, e.g. temperature, identity, location, etc

rules model how computers react to the stimuli provided by sensors

3 phases: (1) context capture, (2) context interpretation and (3) action triggering

PhD aim: to make viable widespread adoption of Sentient Computing through:

location sensor deployable everywhere and for everyone

middleware support for easier sentient application development:

rule-based monitoring of contextual events and associated reactions

user-bound service lifecycle control to assist in action triggeringTRIP: a Vision-based Location Sensor“Develop an easily-deployable location sensor technology with minimum hardware requirements and a low price”TRIP (Target Recognition using Image Processing):identifies and locates tagged objects in the field of view of a cameraRequires:off-the-shelf technology: cameras+PC+printerspecially designed 2-D circular markersuse of well-known Image Processing and Computer Vision algorithmsCheap, easily deployable  can tag everything:e.g. people, computers, books, stapler, etcProvides accurate 3-D pose of objects within 3 cm and 2° error

TRIPcode 2-D Markerradius encoding sectors1even-parity sectorssync sector20 *102011221210001TRIPcode of radius 58mm and ID 18,7952-D barcode with ternary codeEasy to identify bull’s-eye:invariant with respect to:RotationPerspectivehigh contrast 2 16 bit code encoding rings:1 sector synchronisation2 for even parity checking4 for bull’s-eye radius encoding39 = 19,683 valid codes

Target Recognition ProcessStage 0: Grab FrameStage 1: BinarizationStage 2: Binary Edge DetectionEllipse params:x (335.432), y (416.361) pixel coords a (8.9977), b (7.47734) pixel coords  (15.91) degreesBull’s-eye radius: 0120 (15 mm)TRIPcode: 002200000 (1,944)Translation Vector (meters): (Tx=0.0329608, Ty=0.043217, Tz=3.06935)Target Plane Orientation angles (degrees):(=-7.9175, =-32.1995, =-8.45592) d2Target: 3.06983 metersStages 4-7: Ellipse Fitting, Ellipse Concentricity Test, Code Deciphering and POSE_FROM_TRIPTAG methodStage 3: Edge Following & Filtering

Geometry POSE_FROM_TRIPTAG method

A Rule Paradigm for Sentient ComputingSentient systems are reactive systems that perform actions in response to contextual events Respond to the stimuli provided by distributed sensors by triggering actions to satisfy the user’s expectations based on their current context, e.g. their identity, location or current activity Issues:Development of even simple sentient application usually involves the correlation of inputs provided from diverse context sources Observation: Modus operandi of sentient applications: Wait until a pre-defined situation (a composite event pattern) is matched to trigger an action

ECA Rule Matching EngineSentient Applications respond to an ECA model:monitor contextual events coming from diverse sourcescorrelate events to determine when a contextual situation occurs:e.g. IF two or more people in meeting room + sound level high THEN meeting onineffective to force every app to handle same behaviour separatelySolution ECA Rule Matching Service:accepts rules specified by the user in the ECA language<rule> ::= {<event-pattern-list> => <action-list> }automatically registers with the necessary event sourcesnotifies clients with aggregated or composite events or executes actions when rules fire:aggregated event= new event summarizing a situationcomposite event= batch of events corresponding to a situation

Building a Sentient Jukebox with ECA Service“If it is Monday, a lab member is logged in and either he is working or it is raining outside, then play some cheerful music to raise the user’s spirits”within 15000 {/* Enforce events occur in 15 secs time span*/query PCMonitor$logged_in(user ?userID, host ?hostID) and test(dayofweek = "Monday") and Location$presence(user ?userID) before /* a presence event must occur before any event on its RHS */ ((PCMonitor$keyboard_activity(host ?hostID, intensity ?i) and test(?i > 0.3)) or (query WeatherMonitor$report(raining ?rainIntensity) and test(?rainIntensity > 0.2)))=>notifyEvent(Jukebox$play_music(?userID, ?hostID, "ROCK"));}

Mapping of Rules to CLIPS(assert (rule (ruleID 0) (ruleRegTime 1005472984621)))(defrule rule0 (PCMonitor$logged_in (user ?userID) (host ?hostID) (timestamp ?time0#)) (test (eq (dayofweek) "Monday")) (Location$presence (user ?userID) (timestamp ?time1#)) (test (> ?time1# 1005472984621)) (test (> ?time1# (- (curtime) 15000))) (or (and (and (PCMonitor$keyboard_activity (host ?hostID) (intensity ?i) (timestamp ?time2#)) (test (> ?time2# 1005472984621)) (test (> ?time2# (- (curtime) 15000))) (test (> ?time2# ?time1#))) (test (> ?i 0.3))) (and (WeatherMonitor$report (raining ?rainIntensity) (timestamp ?time3#)) (test (> ?rainIntensity 0.2))))=> (bind ?currentTime# (curtime)) (bind ?factID0# (assert (Jukebox$play_music# 0 ?currentTime# ?userID ?hostID "ROCK"))) (notify-event ?factID0#))

LocALE FrameworkNeed to provide support for reactive behaviour of sentient systems:e.g. user-bound service activation after aggregated event arrivalLocALE = CORBA-based solution to object lifecycle & location control:hybrid of CORBA’s Object LifeCycle Service and Implementation Repositoryaddresses location-constrained service activation, deactivation and migrationadds mobility, fault-tolerance and load-balancing to objects in a location domaingenerates permanent object references (independent of object network location)undertakes transparent client request redirection upon object’s location changeuseful for third-party object location controllers:e.g. “migrate the TRIP parser to another host when the used host owner logs in”

Location-constrained Object Lifecycle ControlWhy is CORBA location transparency not always desirable?sometimes want to control where objects are first located and then relocatede.g. load-balancing or follow-me applicationsLocALE provides apps with location-constrained object lifecycle-control: apps specify on distributed object creation its initial location:within a host, e.g. hostDN("guinness") any host in an spatial container (room), e.g. roomID("Room_1")in any location domain’s host, e.g. hostDN("ANY") orin one of a given set of hosts, e.g. hostGroup("heineken", "guinness")… and restrictions under which an object can later be moved and/or recovered:LC_CONSTRAINT(RECOVERABLE | MOVABLE) # any host of location domainLC_CONSTRAINT(RECOVERABLE_WITHIN_ROOM | MOVABLE_WITHIN_ROOM)

LCE Active TRIPboardAugments whiteboard with interactive commands issued by placing special ringcodes in view of a camera observing whiteboardActivated by LocALE when person enters room or through web interfaceRegisters rules with the ECA Rule Matching Server:Location$TRIPevent(TRIPcode 52491, cameraID “MeetingRoomCam”) and Location$presence(user ?userID, room “LCE Meeting Room”) => notifyEvent(CaptureSnapshotEvent(“MeetingRoomCam”, ?userID))By means of LocALE, application’s TRIParser component is:created in a load-balanced way by randomly selecting one host in a hostGroupfault-tolerance by recreation of failed recogniser in another host

Follow-Me AudioProvides mobile users with music from the nearest set of speakersMP3 decoder and player follow the user to his new location.Uses TRIP as a real-time location and music selection deviceUses ECA Service to register contextual situations to be monitoredUses LocALE’s migration support

Iteration 2: Concentrate on explicit user-environment interaction: profit from what you already have in your hands!EMI2lets: a Reflective Framework for Enabling AmI

Iteration 2: Concentrate on explicit user-environment interactionLatest mobile devices used mainly for communication, entertainment or as electronic assistantsHowever, their increasing:Computational powerStorageCommunications (Wi-Fi, Bluetooth, GPRS)Multimedia capabilities (Camera, RFID reader)ExtensibilityMakes them ideal to act as intermediaries between us and environment:Aware (Sentient) DevicesPowerful devicesAlways with us anywhere at anytimeOur mobile devices can turn into our personal butlers!!!

MotivationBuild Smart Spacesand transform mobile devices intoUniversal Remote Controllers of Anything Anywhere at AnytimeMobile devices equipped with Bluetooth, cameras, barcode, GPS or RFID are sentient devices http://www.ctmd.deusto.es/mobilesenseA Smart Space is a container, either indoors or outdoors, of Smart ObjectsA Smart Object is an everyday object (e.g. door) or device augmented with some computational service. Definition of suitable AmI architectures may be a good starting point to make AmI reality

EMI2lets Platform IEMI2lets is a middleware to facilitate the development and deployment of mobile context-aware applications for AmI spaces. Software platform to:convert physical environments into AmI spaces augment daily life objects with computational servicestransform mobile devices into Smart Object remote controllers

EMI2lets Platform IIEMI2lets is an AmI-enabling middleware addresses the service discovery and interactionaspects required for active influenceon EMI2Objects Follows a Jini-like mechanism and Smart Client paradigm once a service is discovered, a proxy of it (an EMI2let) is downloaded into the user’s device (EMI2Proxy). An EMI2let is a mobile component transferred from a Smart Object to a nearby handheld device, which offers a graphical interface for the user to interact over that Smart Object

EMI2lets Deployment…EMI2let PlayerEMI2letEMI2letEMI2letEMI2letEMI2letEMI2letEMI2letEMI2letEMI2let runtimeEMI2let runtimeEMI2let back-endEMI2let back-endEMI2let back-endEMI2let back-endEMI2let back-endEMI2let back-endEMI2let Server…EMI2let FrameworkEMI2let DesignerSmart ObjectSmart ObjectEMI2let ServerEMI2let ServerEMI2let transferHandheld device(PDA,mobile phone)…Handheld device(PDA,mobile phone)EMI2let DesignerEMI2let to back-endcommunicationEMI2letEMI2let…EMI2let Player…EMI2let ServerEMI2let transfer……

How does it work?ReproductionDiscoverDownloadInteractUpload to the serverDevelopmentGPRS

EMI2lets Internal ArchitectureEMI2let Abstract Programming Model APIAbstract-to-Concrete MappingEMI2Protocol over Bluetooth RFCOMMSOAP over Wi-Fi, GPRS/UMTS or InternetTRIP-based Service DiscoveryUPnP Service DiscoveryRFID-based Service DiscoveryBluetooth Service Discovery (SDP)Interaction MappingDiscovery MappingPresentation MappingPersistence Mapping…

EMI2 Internals3-tier software architectureEMI2 framework defines 4 programming abstractions:Discovery CommunicationPresentation PersistencyAn EMI2letplug-in= abstraction implementation Common plug-ins: Bluetooth, Wi-Fi, UPnPSpecial purpose: TRIP (Target Recognition using Image Processing)Assembly fusionat runtimeReflection does the magic!!!

EMI2lets ApplicationsWe have created EMI2lets for different application domains:Accessibility: blind (bus stop), deaf (conference)Home/office automation: comfort (lights), entertainment (WMP), surveillance (camera)Industry: robotPublic spaces: restaurant, parking, airport

ConclusionEMI2lets = middleware providing universal active influence to mobile devices over Smart Objects:Transforms mobile devices into universal remote controllers.Enables both local and global access to those Smart Objects (anywhere/anytime).Independent and extensible to the underlying service discovery and interaction, graphical representation and persistence mechanisms. Enables AmI spaces using conventional readily-available hardware and software.Follows a “write once run in any device type” philosophy

Iteration 3: Easing AmI! Leverage from Web 2.0 principles and map them to AmIA Web 2.0 Platform to Enable Context-Aware Mobile Mash-ups

Iteration 3: Easing AmI! Leverage from Web 2.0 principlesIssues impending AmI wide deployment remain:AmI is possible if and only if:Environments are heavily instrumented with sensors and actuators Besides, to develop AmI apps continues being very hard!Still, mobile devices enable interaction anywhere at anytimeUser-controlled (explicit) & system-controlled (implicit)Is AmI possible without heavy and difficult instrumentation (or infrastructure-less)?YES, IT SHOULD if we want to increase AmI adoption!!!

Research AimAimLower the barrier of developing and deploying context-aware applications in uncontrolledglobal environmentsNot only my office, home, but what about my city, other companies, shopping centres, and so onHOW?Converging mobile and ubiquitous computing with Web 2.0 into Mobile Ubiquitous Web 2.0Adding context-aware social annotation to physical objects and locations in order to achieve AmI

What does it do?Annotate every physical object or spatial region with info or services Both indoors and outdoorsFilter annotations associated to surrounding resources based on user context and keyword filteringEnable user interaction with the smart object and spatial regions both in a PUSH and PULL mannerRequirementParticipation in a community of users interested in publishing and consuming context-aware empowered annotations and servicesSentient Graffiti

User’s viewGraffiti annotationDescriptions, keywords, contextual attributesGraffiti discovery and consumptionTRIP, RFID, NFC, GPSSystem’s viewContext-Aware FolksonomyTag/keyword-basedContext-Aware Mash-upGoogleMaps + our server back-endFunctionality

Multi-modal InteractionSentient Graffiti simplifies human-to-environment interaction through four mobile mediated interaction modes:Pointing – the user points his camera phone to a bi-dimensional visual marker and obtains all the graffitis associated with it

Touching – the user touches an RFID tag with a mobile RFID reader bound to a mobile through Bluetooth (or NFC mobile) and obtains the relevant graffitis

Location-aware – mobiles equipped with a GPS in outdoor environments obtain the relevant nearby graffitis in a certain location range

Proximity-aware –the device retrieves all the graffitis published in nearby accessible Bluetooth servers when it is in Bluetooth range 54

Sentient Graffiti &Near-Field-Communication (NFC) is a combination of contact-less identification and interconnection technologies enabling wireless short-range communication between devices and smart objects. Range about 20 cm, 13.56 MHz band Enables 3 types of services:Service initiation and configurationP2P (peer to peer) data sharing and communicationPayment and ticketing Key enabler for the upcoming Internet of ThingsHow does Sentient Graffiti leverage from NFC?Touching interaction through NFCMIDP 2.0 Push Registry and NFC are combined to prevent users from starting mobile client before interacting with RFID augmented objectsProximity-aware interaction through NFCNokia NFC 6131 and Bluetooth SG servers are bound by simply touching an RFID tag with a mobile

Available prototypes:Marker-associated Graffitis: Virtual Notice Board Public/private graffitis, expiration time, remote review, user participationBluetooth-range Graffitis: University Services BoothIndividual, group and private graffitis, tag-based (OPEN_DAY)Location-range Graffitis: Bus AlerterThird-party SG clientesOther possible applications:City Tour: Bilbao_tourism Graffiti DomainConference: AmI-07 feedback, expiration after conferencePublicity: Graffiti expiration after N timesFriend meetingsDisco/stadium/office blogsApplication Types & Examples

Marker-associated Graffitis: Virtual Notice Board

Bluetooth-range Graffitis: University Booth

Location-Range Graffitis: Bus Alerter

Third-Party Mobile Application using Sentient Graffiti HTTP API

ConclusionsSentient Graffiti is a platform which promotes a more extensive adoption of AmI in global environments(cities, cars, hospitals, homes) without imposing deployment and maintenance hassles, offering the following features:Context-aware to filter and select most appropriate smart objects’ content and services for usersEncourages the creation of third party context-aware mash-upsthrough its HTTP APIBased on standard web technologieslowering its adoption barrierEnables multi-modal interaction between users and environment through generic mobile clientFurther work:Evaluate SG in a mobile social software communityAdopt Semantic Web context modeling

Iteration 4: Dealing with the heterogeneity, dynamic behaviour of existing instrumented environments, using available standardsSmartLab: Semantically Dynamic Infrastructure for Intelligent Environments

Iteration 4: Dealing with the heterogeneity, dynamic behaviour of existing instrumented environmentsMiddleware support for intelligent environment provision:Monitoring contextDetermine the user activity and high level contextAdapt the environment to the user

Layer 1: Sensors and Actuators

Device assortment common in intelligent environments:EIB/KNXAsterisk VoIP VideoIP CamerasIndoor Location System (Ubisense)People wandering devices (Gerontek)Custom-built Devices (WSN)ChairDisplay braceletContainerEvery system has its own control interfaceHow do we interconnect all of them?Layer 1: Sensors and Actuators

Layer 2: Service AbstractionEvery device or system provides certain functionalities that we must transform into software services inside OSGi.Each device must provide a control bundle acting as a proxy inside the OSGi platform.All the native services of each device are wrapped in OSGi services.EIB/KNX Bus  BinaryLight, DimmableLight, Alarm, DoorSensorVideoIP HTTP Cameras CameraControllerVoiceIP Asterisk Server  AsteriskControllerGerontek Server  GerontekControllerUbisense COM Server  UbisenseControllerCustom-Built Devices  SmartChair, SmartContainer

Layer 2: Semantically-enhanced OSGi Bundles

Layer 3: Service and Context Management

Layer 3: Service ManagementDiscovery serviceSimple multicast protocol to obtain the bundles automatically.Installer serviceDecides whether the bundle should be installed or not.Local Repository serviceExtends the OBR service to provide a local cache for the discovered bundles.

Layer 3: Context ManagementContext information modelled with an ontologyBase coreTime and space relationsEventsNew services might extend the knowledge baseClasses and instancesBehaviour rulesConverts inferred information into OSGi events to which the different services can register.React accordingly to specific events.

Context ManagementTwo knowledge generation methods in SmartLab:Ontological reasoningMakes use of RDF (rdf:domain), RFS (rdfs:subPropertyOf) and OWL (owl:TransitiveProperty) predicatesAllows to infer implicit knowledgeRule-based reasoningAllows defining relationship among entities in ontologyThree types of inference:Semantic rules – enable making ontological reasoning based on RDF and OWL theoretical modelsKnowledge extraction rules – extract new knowledge from ontology’s implicit oneEvent-inferring rules – generate aggregated events from the context in the knowledge base

Event-inferring Rule Example[EVENT-Meeting:(?meetingArea rdf:type <http://deusto.es/smartlab.owl#MeetingArea>),(?meetingArea <http://deusto.es/smartlab.owl#containsPersonItem> ?p1),(?meetingArea <http://deusto.es/smartlab.owl#containsPersonItem> ?p2), (?p1 <http://deusto.es/smartlab.owl#name> ?name1), (?p2 <http://deusto.es/smartlab.owl#name> ?name2),notEqual(?name1, ?name2),makeTemp(?meetingEvent)->(?meetingEvent rdf:type<http://deusto.es/smartlab.owl#LocableMeetingEvent>),(?meetingEvent <http://deusto.es/smartlab.owl#place> ?meetingArea), (?meetingEvent <http://deusto.es/smartlab.owl#name> ?name1),(?meetingEvent <http://deusto.es/smartlab.owl#name> ?name2) ]

Layer 4: Service programmability, Management and Interaction

Layer 4: Service programmability, Management and InteractionImplicit interactionContext management generates events and some services are invoked automatically.Explicit interactionHTTP interface inside OSGi to invoke any service that exposes remote methodsDashboard-like GUI based on widgets (javascript cross-browser library) that are loaded when the services are active.

ConclusionsSeveral extensions to the OSGi framework to support intelligent and evolvable environment instrumentation have been presented:Devices or environment services expose a special semantic control bundle.OSGi bundles are discovered and act as a proxy providing semantic enhanced services.These services populate the system with new context information in order to infer new knowledge and generate events.Different services can register to receive context events and react to them accordingly.The platform knowledge has been modelled using ontologies and rules that can be extended and updated dynamically.For explicit interaction we have a HTTP interface or a Dashboard GUI based on widgets that can be used to interact with the platform.Semantic reasoning is powerful but costly computationally!!

Iteration 5: Focus on a more specific application domain: AALZAINGUNE: Infrastructural Support for Ambient Assisted Living

Some facts:By 2020, 25% of the EU's population will be over 65Spending on pensions, health and long-term care is expected to increase by 4-8% of GDP in coming decadesTotal expenditures tripling by 2050Older Europeans are important consumers with a wealth over €3000 billionAmbient Assisted Living (AAL) is a European Union initiative to address the needs of the ageing European populationElderly people should be able of living longer in their preferred environments, to enhance the quality of their livesCosts for society and public health systems should be reducedhttp://www.aal-europe.eu/To make AAL reality important to devise new easily-deployable middleware and hardware infrastructureIteration 5: Focus on a more specific application domain: AAL

TecnológicoFundación DeustoTeknologikoa Deustu FundazioaAims to provide the software/hardware infrastructure (platform) required to easily deploy assistive services for elderly people @homehttp://www.tecnologico.deusto.es/projects/zainguneHOW?With an OSGi gateway powered by a rule-based reasoning engine which allows the coordination and cooperation of the home sensing and actuation devicesConsortium composed by:The ZAINGUNE Project

Heterogeneous device support: Agotek’s gerontek, Asterisk IP phones, IP cameras, KNX-EIB devices, ...Model assistive environments as a set of cooperating servicesProgrammability through aSOA-based approach. Apply natural explicit interaction mechanisms:Easy to use gadget-based and secure front-end, phone-mediated interaction, ... ZAINGUNE Goals

ZAINGUNE Multi-layered Architecture

ZAINGUNE Multi-layered ArchitectureThe hardware device layer is composed of the sensors and actuators which populate an environmentThe software platform layer transforms the functionality provided by the devices managed by Layer 1 into software services (bundles) which can be combined to give place to more advanced servicesEvery device within an AAL environment (home, residence, hospital) is encapsulated as a bundle or execution unit within our OSGi environment.

ZainguneController – core component of ZAINGUNE server, manages and controls access to the components (OSGi bundles) supported by ZAINGUNE.

ZainguneServlet – behaves as an Web Service/OSGi gateway exporting the OSGi bundle functionality through Web Services and generates web front-ends (based on JavaScript X library) of every bundleThe applications environment layer includes all the possible application scenarios for the ZAINGUNE infrastructurePublic housing flat for disabled or elderly people, hospitals, residences and so onMulti-layered Architecture

Web gadget-based interaction – an easy to use web gadget-based environment controller divided into the following sections:Help – single button to request helpCommunications – call by photo, email and SMSHome control – control of every device by containerSurveillance – both local and remote IP camera controlPhone touchpad- and voice-based interaction – the integration of Asterisk in ZAINGUNE provides: feedback through phone speakers, house control through keystrokes and voice commands Alert bracelet-based interaction – special purpose device designed for assistance seeking and alert notificationMulti-modal Environment Interaction

Multi-modal Environment Interaction

A custom-built device combining an organic screen (µOLED-96-G1 of 4D Systems) with a WSN mote based on Mica2DOT capable of displaying messages broadcasted by nearby motes.Every inhabitant may carry an alert bracelet for:Assistance seekingAlert notificationA future work option is to add living signal monitoring sensors (e.g. Nonin 4100 Avant Module) to such deviceZAINGUNE Alert Bracelet

The adoption of a rule-based engine in ZAINGUNE offers two main advantages: Decouples environment configuration from programmabilityEnables environment-initiated proactive reactionsEnvironment intelligence is encapsulated as a set of rules which trigger when certain sensorial situations are matchedLHS represents sensing conditions whilst RHS depicts actions to be undertaken when the LHS situations are matchedThis rule-based paradigm is employed to configure the reactive behaviour of a ZAINGUNE-controlled environment: efficient management of energy resourcessecurity at home or danger situation preventionIntelligence through Rule-Based Reasoning

Dealing with the need for Infrastructural Support in Ambient Intelligence

More Related Content

What's hot (20)

Similar to Dealing with the need for Infrastructural Support in Ambient Intelligence (20)

More from Diego López-de-Ipiña González-de-Artaza (20)

Recently uploaded (20)

Dealing with the need for Infrastructural Support in Ambient Intelligence