Case Study - Siemens


Siemens proposed a Smart Home Case Study.

Smart Home Concept

In the homes of European citizens you typically find a wide range of electrical and electronic devices: 
  • home equipment: lights, thermostats, electrical blinds, fire and glass break sensors, etc,
  • white goods: washing machines, dryers and dishwashers, etc,
  • entertainment equipment: TVs, radios and devices to play music or movies, etc,
  • communication devices: (smart) phones and PCs or others

Goals

The goal of projects in the Smart Home domain is to network the available devices and enable the inhabitants to monitor and control their status through some kind of GUI. A rudimental solution allows controlling devices from certain technical areas inside the house and executes home centric applications. A more ambitious solution integrates more kinds of devices and includes an external platform to enable remote access and services from other providers. Tasks such as billing, logging and platform management are involved in this case.

In any case, the challenge for a provider of a Smart Home product family is to support the variety in the domain, e.g. the distribution and wiring of devices in a home. Moreover the stakeholders for specifying and installing a Smart Home are typically no software experts, therefore specifying the properties of a concrete Smart Home has to be intuitive for stakeholders like building architects. 


Concept

Specifying a concrete Samrt Home should be possible in a specific graphical or textual language that is intuitive to use for a building architect. Icons and terms in this language should be expressive to prevent errors in describing the home. The architect is typically not familiar with the IT-domain. The automation software should be generated.

It should be possible to easily equip a freely designed home with all sensors and actuators ordered by a customer.

The kinds of devices that should be supported are at least:  
  • Lights, light switches 
  • Window openers, window sensors, blinds, glass break sensors
  • Radiators and thermostats
  • Door sensors and door openers
  • Cameras
  • Motion and light detectors
  • Presence sensors
  • Fire and smoke detectors, sprinkler system
  • Alarm devices
  • Home entertainment systems, e.g. TV, Audio
  • Communication systems, e.g. phones, PCs or other internet enabled devices
  • White goods like washing machines 

The Smart Home description language should make it easy to specify which devices should be situated in which rooms and should also allow connecting sensors and actuators as necessary, e.g. mapping a light switch to a light or a blind to a window.

It should be easy to integrate devices from different vendors by simply adding the software that is shipped with the device. Device vendors are typically the choice of the home owner.


The most important functional requirements for a smart home platform are: 
  • Monitor and change the status of devices (for the end user) 
  • Monitor the changes made manually (for the end user)
  • Installation of new devices (for the end user or an operator)
  • Installation of new kinds of devices (for an operator)
  • Personalization
  • Authorization
  • Authentication

The following non-functional requirements are dominating: 
  • Stability/Reliability: If safety or security relevant services such as fire alarm, babysitter functions or emergency help for elderly people are provided, the stability and reliability of the system are very important.
  • Short feedback times to GUI: For the acceptance of the system an instant reaction of the system to user input is indispensable.
  • Scalability: A smart home platform should be usable for small homes with few technical devices and for large homes with many devices and a high diversity of devices.
  • Security: The smart home platform may contain security relevant information; e.g. information if a person is at home, if children are alone at home or where alarm devices are located. Also personal information such as documents or pictures may be contained. Therefore unauthorized access to this information has to be barred.
  • Variability: For different users and different situations different views on the devices are necessary.
  • Extensibility: The inclusion of new services and extension of currently available services should be easy. 

The domain consists of the following key entities: 
  • House
  • Floors
  • Rooms
  • Controlled Devices
  • Smart Home Service Platform
  • Remote Control GUI Devices (inside house)

Implications on the Implementation of the Product Family

Providing a solution for a Smart Home product family requires to support an enormous amount of variability in the software base assets. AOSD and MDD help us to solve the challenges imposed by the above described requirements. In particular the demonstrator investigates the following concepts for solving typical product line engineering challenges: 
  • Model to model transformations (Problem Space to Solution Space)
  • The problem space specificataion of a Smart Home consists of devices and their relations to achieve intelligent compound behaviour. In the solution space (also called software domain) those entities are implemented in software components.
    Example: For a thermostat device and a radiator device in the problem space model, the solution space model will consist of
    · A radiator driver component for each radiator
    · A thermostat component or each thermostat
    · And a service component per floor that coordinates and manages thermostats and radiators using some kind of control algorithm
  • AO to simplify tracing granularity
    Aspects should reduce the granularity of assets such that traceability of requirements to code on a per-file-level becomes possible.
    Example: In SecureHome, we will weave monitoring functionality into component implementations. Monitoring functionality is modularized in an aspect.
  • Architecture Level AO
    AO is not just useful on the level of the implementation language, it can also be used on the level of architectural building blocks, i.e. components (see invasive vs. non-invasive AO languages). For OSGi, we will have to provide a means to deploy interceptors. AO component middleware like CAM/DAOP supports this concept already.
    Example: An encryption interceptor encrypts communication among components.
  • Model weaving (AO modeling)
    Model weaving is used to implement variability on the modeling and the meta modeling level.
    Examples: Depending on the Edition (Economy, Secure, Luxury, …) the domain meta model must be changed. Advanced editions offer more kinds of devices and therefore also more advanced compound functionality.
  • Combining AO and Generators
    Aspects on templates and transformations are used to adapt model transformation and code generation.
    Examples:
    · In order to generate code for different target platforms, we will use AO techniques for templates to adapt the code generation
    · If we change the domain meta model (because of various editions), and if we keep the solution space meta model similar, we need to adapt the problem space to solution space transformation
  • Combining feature models and DSLs for
    · Varying models (DSL sentences)
    · Varying the DSL itself (meta models, syntax, editors)
    · Weaving transformations and transformation steps
  • Unanticipated Changes & AO
    Using AO languages one can hook into generated (or manually written library) code at places where the product line architects did not identify a hook.
  • Traceability starting from Requirements
    Representing requirements as models and establish traceability links to models created in subsequent phases.

Aditional material


The SmartHome Videos section presents a colection of videos that presents detailed information about Smart Home.

Implementation of the Smart Home Case Study
The implementation of the Smart Home Case Study is now available for download on the follow link:

        http://www4.informatik.uni-erlangen.de/~elsner/SmartHomeWorkspace-2008-12-02-D5.3.zip

You will find the description of its concepts as well as detailed installation instructions in the AMPLE Deliverable 5.3. Avaiable in Documents Section (  http://ample.holos.pt/pageview.aspx?pageid=70&langid=1).

For visualization of the trace data you will additionally need the Ample Tracing Framework 0.2.1 (2008-11-27) or newer (available in the BSCW for AMPLE members).
Developed by Holos
Contact holos@holos.pt