Antoine Savelkoul : Model Driven Software Development, Home Automation

First designs for the home automation DSLs

Antoine — Thu, 05 Nov 2009 18:12:00 GMT

When writing this post I realized how many design choices I have already made while designing the first prototype. Too much to blog about, so I will only discuss a few design choices I have made. Firstly, I would like to start with describing the domain of the first DSLs.

The first DSLs will be used to define the capabilities of devices that will be controlled by the home automation system. Examples of devices are light switches, dimmers, energy meters and the TV. It should not only be understandable by the designers of the devices, but also by its users. A high level description of the basic functionalities of a television might look like:

The television has a power button that can be used to turn the television on and of. Furthermore, the volume can be set to a variable level or muted on and off without losing the previous sound level. The user can switch between the sources "HDMI", "VGA", "Composite in" and the build in tuner. The tuner has some pre-sets the user can choose from.

A visualization might result in an image like below:

From this drawing we nearly have a language, we only need to formalize it. A pseudo description of the language might look like:

A device type has a name
A device type has zero or more device functions
A device function has a name
A device function should be one of the following types:

On / off
Variable
Fixed choice
Dynamic choice

A fixed choice should have one or more pre defined options
A variable should have a minimum and maximum level

A second DSL is used to describe how the devices will talk with the home automation system. My first observation was that, each device will receive commands through a transmitter unit or another connection. For example the light switches will receive signals from a transmitter and the television via a serial connection. But by defining it this way, each device implementation will depend on a specific transmitter or connection while, for example with the wireless light switches I have used, the user has the choice to use an original manufacturer's transmitter or one of RFXCOM. So, the original design was not completely in line with my goal to have a manufacturer independent solution.

However, I came up with the idea to include communication protocols so that a manufacturer independent solution is possible. These communication protocols can be best compared with web services. The DSL for the communication protocol will have some resemblance with for example the Web Service Software Factory.

Some simplified examples of two communication protocols within my home automation system:

Wireless light switches

Request:

Parameter	Type	Is address	Description
Home code	A .. P	Yes	Home code set on the device
Device code	1 .. 16	Yes	Device group and number
Value	on/off	No	On/off or dimming

TV Serial Control

Request:

Parameter	Type	Is address	Description
Set ID	1 .. 99	Yes	ID of the television
Command 1	j,k,m,x	No	First part of command code
Command 2	a .. z	No	second part of command code
Data	0-255	No	Value (on/of, level etc.)

Response:

Parameter	Type	Is address	Description
Command 2	a .. z	No	Second part of the command received
Set ID	1-99	Yes	ID of the television
Act code	OK, NC	No	Indicates if the command has been received and executed successfully
Data	0-255	No	New value

Parameters can have a "Is address" flag. This flag will be used to add configuration parameters when adding devices to the home automation system.

The last DSL I would like to discuss is the DSL used to assign the protocols to the devices. Within the image below we see how, by using the protocols, compatibility between devices can be modelled without creating direct dependencies.

One interesting scenario for this DSL is that it should be easy to work with multiple people on. There will be several ways on how the model will be created. People can assign self defined or existing protocols to devices they have defined, but might not interested in all the transmitters that are available or all devices that can be controlled by a specific transmitter. On the other hand, protocols might be designed to control specific type of devices. For the end user there is no difference between a light switch controlled using a wireless protocol or using Power Line Communication. So, how the model above will be created and visualized is still something to think about.

Some things that are not yet covered by the DSLs described in this blog post are:

The translation of commands (protocol) to device functions
The translation of commands to, for example, to a textual representation used for communication over a serial link

These will also be covered by the first DSL prototypes I am designing. As soon as I have built these prototypes I will make some parts of my project available for download.

For who is interested in other home automation DSLs too I can recommend the following interesting papers and blog posts of other people (thanks to Steven Kelly for providing some of the references):

Online draft from Martin Fowler’s next book. His DSL is based on a state machine.
Steven Kelly discussing the DSL of Martin Fowler
The Making Of User-Interface Designer, A Proprietary DSM Tool and The Practice of Deploying DSM Report from a Japanese Appliance Maker Trenches by Laurent Safa.
Chapter 7 of the Domain-Specific Modeling book from Steven Kelly and Juha-Pekka Tolvanen. See also the example on dsmforum.org.
OSLO is running my house by Kris Horrocks.
HAAIS DSL. You need a ACM account to download (unfortunately I don’t have such an account) and HAAIS DSL Presentation (free download). The domain of the DSL on page 25 has an overlap with the domain I described in this blog post.

Automated home: Applying Interaction Design on DSLs

Antoine — Sat, 03 Oct 2009 16:17:00 GMT

In my previous posts I have given an impression of the current situation (how the hardware is connected, which software I use). It is very tempting to dig into hardware and software details now, but during previous experiences with designing DSLs I learned that this will be the wrong way.

During my Master’s thesis a few years ago I did an investigation at one of Netherlands major insurance companies. During this investigation, I designed a number of DSLs for the domain of medical statements. I did this in cooperation with domain experts. The methods I used were very promising.

One of the methods I was inspired by is Interaction Design. A lot of papers and articles about designing DSLs will start with an analysis of the ~~problem~~ solution domain by discussing complete hardware designs and software architectures (including some of my own). However, I decided to have a look at the how medical statements were defined by medical advisors, evaluated by legal advisors and implemented by software developers. This resulted in a totally different design as I primarily had in mind. I also believe that the methods I used will create more efficient DSLs that will really decrease the time needed per project phase because it covers the most relevant business logic while representing the language of the business. Thereby, the created models can even be used to validate requirements with domain experts saving valuable time on writing documentation.

For my home automation system, I will apply these successful methods as well. With the only exception, that the group of volunteers who can act as domain experts will be smaller this time. The next step will be to form a list of personas that will have an important part in the process of designing and using this system.
The personas are:

Residents of the automated home (e.g. a family with kids or elderly people)
Owner or maintainer of the home automation system (normally the person in house who also configures the thermostat and television set)
The installer of the home automation system (might be a small company or the owner self)
Equipment manufacturers who want to make their equipment compatible with my home automation system
Hobbyists who want to create their own hardware for the system
Hobbyists who want to add existing (not by the manufacturer supported) hardware to the system
Manufacturers, retailers and hobbyists who want to design their own user interfaces for the system

In short (when writing an article about my project, I will give more details);

The average residents just like to have an overview of the system, e.g. knowing where which equipment is located. They will not design their own system but at most define some simple macros.
The installer of the system wants to be able to configure the system, e.g. how everything will be connected. They will also need the possibility to make some adjustments to the user interface and define some more complex macros.
Equipment manufacturers and hobbyists who want to make their hardware compatible with the system need to create a software add-in. They need to be able to define what the capabilities of the hardware are, how they can be configured and implement the communication protocols. In the case of hardware that still has to be developed, the communication protocols might be even in scope for the design.
Finally, some manufacturers, retailers and hobbyists might give their own touch and feel to the system by designing their own user interfaces.

These are a number of personas I have identified so far. For the first phase of my project I would like to limit my scope to the device side because without having them connected, other parts like customizable user interfaces will be useless. In one of my next blog posts I will show an initial design of my first DSL.

Recommendation for reading:

Alan Cooper. The Inmates Are Running the Asylum.

Still busy with DSLs

Antoine — Thu, 10 Sep 2009 17:22:00 GMT

After moving to the apartment of my girlfriend and my and doing some jobs to make it our place, I recently took a week off to work on some of my ideas. One of the projects I started is a DSL for home automation and smart metering. The goal of the DSL will be to simplify the way of building add-ins to support several types of devices like wireless switch units, energy meters and a/v equipment. This while maintaining a manufacturer independent architecture of the home automation system. Thus far the results are promising. Within the next months, I hope to explain a little bit more of the approach I´m taking in my home automation.