Associated Vendors: Ingel S.r.l., Cupersafety S.r.l., Steel Minds S.r.l.

Ingel srl is an innovative technology company founded in 1989 to provide systems and products with high technological content. The open-minded company is proposed on a large international scene as reliable partner for innovative projects and products. Ingel develops products and services in the field of networking, burning control, lighting, monitoring systems and the production of electronic boards in all its phases, from design to prototyping and engineering. The main sectors are: integrated systems for home automation, energy efficiency, networking, devices for the management and control of the flame, burning control, lighting, monitoring systems for the detection of parameters, electronics in general, production, assembly, designing, prototyping and engineering electronic boards.

Cupersafety srl was established in 2007 as an ICT technological start-up, thanks to Regional co-financing for SMEs to support investments in technological innovation. The company is now a point of reference in the electronic field for safety and home automation for residential areas (audio/ video surveillance systems and home automation systems). Particular importance has got the Department of design, hardware/ firmware/software development of innovative wireless home automation systems. The ability to design has shown how some hostile points for home automation mass distribution can be easily climbed over using wireless communication protocols, and low cost wireless components. In support of this intense activity, CUPERSAFETY has set up a Technical R&D Department composed of researchers, mostly electrical engineers with specific skills in hw, fw and sw design.

Steel Minds S.r.l. is a new Apulian company that offers specialized services in two main work areas. The most innovative one is dedicated to the virtual productions and entertainment: 3D Animation, Augmented Reality, Smart Technologies, Motion Capture, Gaming, Visual Effects, Interaction Design, and Real Time Applications. The second one, more "traditional", is based on providing IT solutions and services: Software Design, Software Development, Application Innovation, Middleware Services, IT Strategy, IT Outsourcing, Application Lifecycle Management, and Technical Support. The above-mentioned skills and competencies make Steel Minds S.r.l. a benchmark for any modern and efficient application context.

Motivation for Partnership

Ingel is synonymous with technology. The company provides its clients knowledge and techniques in electronics that blend in highly qualified services, products and systems. To have domotic innovative solutions have been realized regional and national projects, in partnership with other enterprises and research center. One of the interesting characteristic of the architecture identified is the predisposition to adapt to different ambient thanks to the wireless technologies implemented. This can give cheaper solutions at important needs also of the vulnerable people. To extend the target market and to improve the system for Ingel becomes strategic the partnership with Make it ReAAL.

With the partnership with Make it ReAAL, Cupersafety wants to set up a new step to proceed with its strategic course, started several years ago. The goal for Cupersafety is to supply innovative systems into the AAL. Regional and National projects have been realized to identify new ICT and Ambient Intelligence Technologies as  useful solutions to extend the period of time in which subjects not-completely-autonomous can manage to live independently in an home environment. In this point of view Cupersafety is going to improve and extend its actual domotic wireless system to European horizons adapting it to Universal platform. This means more competitiveness and bigger target market.

About Steel Minds: The motivation for this partnership request is to gain new market perspectives creating a product that is easily extendible, modular and which, following a standard, interacts with other similar AAL applications.

Since we planned to extend frequently product functionalities, modularity and possibility to add new services and nodes easily is a key value of this project.

UniversAALization Plan

Domestic Ambient Access Control System

Description

The system is the result of a project which has been realized by the involvement of different enterprises, in particular Ingel srl, Cupersafety srl and Steel Minds srl, leading to a joint solution characterized by a wireless architecture.

The system has been designed in a modular manner, able to adapt it to different applications. In this context, we describe a wireless home automation system characterized by a network of several peripheral nodes (sensors/actuators distributed in the home environment) linked to a central node with the function of network coordinator. The network interoperability in wireless mode is possible using a ZigBee protoco.

The interface, between users and the above mentioned network, is a simple and intuitive coordinator software that allows to manage the home control system by mobile devices like a tablet, a smartphone or a PC.

The nodes are able to:

a) communicate by zigbee interfaces with existing lighting devices for lights control

b) communicate by zigbee interfaces with existing automatism to control windows, doors, jamming, etc ...

c) communicate by zigbee interfaces with presence sensors and other different sensors.

The system may include:

  • Lights control
  • Open close control
  • Electrovalve control
  • Sound alert acutator as reminder of alarm
  • Flooding Sensor
  • Gas leak Sensor
  • Presence Sensor

The home automation functionality suggested are:

  • To turn on/off the lights and dimming;
  • To open/close windows, doors, gates etc.;
  • To block gas system and waterworks in case of failures closing electrovalves
  • To manage eletrical loads at the house, choosing the socket and the linked active contact to leave off;
  • To monitor the home enviorment using motion, anti-flooding and smoke sensors;
  • To be interfaced with devices such as a panic button;
  • Sensind automatic sms or acustic signals to alarm in case of a danger for persons or for the house.

The zigbee central node collects the data (status of the lights, the door, the sensor..) which can be used to manage and control all systems by a mobile device.

Depending on the choice of installed devices, this system can provide both a service for home security dedicated to subjects with mild cognitive neurodegenerative deficits and an easy home control through a smartphone app for subject with mobility impairments.A Mobile Application that interfaces with the coordinator for these information and commands may control all these nodes.

Based on this architecture system, each company has defined its product for specific application, by way of example but not of limitation:

  • Ingel srl has elaborated a product able to satisfy the “Safety-At-Home” functionality. With flooding Sensor and gas leak Sensor it’s possible to open windows or door.

  • Cupersafety srl has elaborate a product able to satisfy the “Easy Home Control” functionality. With presence sensor or push bottom it’s possible to switch on/off or dimming light, or to open windows/door;

  • SteelMinds srl has elaborate a product able to satisfy the “Safety-At-Home functionality. With flooding Sensor and gas leak Sensor it’s possible to close electrovalve actuator connected to the gas or water source.

Product architecture AS IS:

In this scenario, there are two important drawbacks:

  • The system doesn’t execute business logic on his own but all sensors must be controlled by mobile user interface

  • It supports a limited number (defined during system configuration) and types of nodes.

  • It is a closed system, not expandable through a standard system, but with ad hoc software components or with the use of custom protocols

The aim is to create a system that reacts and execute “actuations” based on sensors information (as well as user commands) and to have the possibility to extend platform functionalities with more devices and platforms using a standard and to add a higher level logic to the system.

In order to achieve this goal, the universAAL platform will be integrated into the Home Server, with a middleware that interacts with the coordinator eventually expanding its APIs (Adapter component). All the messages from and to the coordinator will pass through the platform, they will logged properly and a business logic could be applied which manage particular situations without human intervention.

In addition to the existing system, external sensors or actuators will be added to the platform. These devices will not be linked with the coordinator, but directly to the platform uAAL through the Local Device Discovery and Integration (LDDI), providing a plug and play functionality to the system.


Some additional and external devices could be:

  • Motion sensors, anti-flooding, smoke to monitoring presence and critical event;

  • Presence sensor to achieve a major control of the subject

  • Light sensor to allow the home remote control in order to manage the illumination

  • Actuator to turning on and off lights and dimming;

  • Actuator to opening windows, doors, gates, shutters, etc.;

A presence detector is an example of sensor to add externally. This will be linked to further functionality to the platform: for example turning on lights when the subject enters into a room.


Situation TO BE:

In the following section, the uAAL platform component will be detailed showing two major flows. The first one (blue arrows) will describe the behavior of the platform in case of sensor messages, the second one (red arrows) in case of smartphone app commands.

The blue arrow represents the information flow generated by a sensor message (from the Coordinator subnet or an external device). In the graph the adapter (in case of Coordinator) or driver (in case of an external sensor) receives the message. It will be forwarded to the relative Context Publisher which translates its information to the relative ontology and publishes it into the Context Bus as a Context Event. Then the Context History Entrepot (CHE) receives the data from the Context Bus, now the Reasoner Application applies the business logic: it queries the CHE and eventually publish Context Events or service requests for Coordinator or actuators respectively.

Smartphone Commands

The red arrow represents an actuation message, created by the internal component of the Coordinator dedicated to the inter-platform communication when it receives a command from the smartphone. The message pass through the Context Bus into the CHE for log reasons and the re-enters into the Coordinator Bundle, sent to the Coordinator and then executed.

The Reasoner

The Reasoner could cyclically query the CHE in order to aggregate a major group of events into other with higher abstract level. For example with the new external sensors (presence sensor) a Reasoner abstraction may be: “if in the past 10 minutes the presence sensor hasn’t detected movements into a room then the room is empty”. Therefore, it can send a turn off message to all the lights of that room. Another abstraction may be: “if all the presence sensors in the house didn’t detected anyone in the past half-hour there’s no one into the house or the residents are gone to bed.” In this case, the Reasoner can send a Context Event in order to block the gas until the presence detection of the residents.

With this configuration, the system will have a standard method to manage the information flow. In case of new product integration need, if it has a similar architecture, the union of the systems is possible just with the addition of some middleware components and an ontology generalization. The main pro to this approach is the standard method (universalization) used to integrate the components instead to invent new protocols and ad hoc glue software to make all the components work together (with the consequent bugs and technology limits).


Using the universAAL Middleware API for Coordinator Module

General approach

☒ Using universAAL runtime with the Java-OSGi API of the middleware

Using other runtime with the Java Remote-API of the middleware

Using of the middleware buses

Context bus (for publishing events and / or subscribing to events)

Service bus (for calling and / or providing services)

Additional middleware features planned to be used

Configurability API (mainly management of config parameters and config home directories for storing files and resources)

Logging mechanisms

Using the universAAL Middleware API for External Modules

General approach

Using universAAL runtime with the Java-OSGi API of the middleware

Using other runtime with the Java Remote-API of the middleware

Usage of the middleware buses

☒ Context bus (for publishing events and / or subscribing to events)

Service bus (for calling and / or providing services)

Additional middleware features planned to be used

Configurability API (mainly management of config parameters and config home directories for storing files and resources)

Logging mechanisms

Using universAAL “Manager” components (platform services)

☒ Context History Entrepôt services (querying data gathered in the home)

☒ Situation Reasoner services (the SR can store SPARQL CONSTRUCT-queries as rules to automatically generate new context events whenever certain conditions hold; this can be used to recognize situations; e.g., if you want that a context event is published whenever the user is sleeping, a solution could be to tell the SR to publish this event whenever in the night the user is in the sleeping room in the bed and the lights are off)

☒ The Drools Engine (a second reasoning engine using the JBoss rules)