Antoine Savelkoul

I have a so many ideas I would like to write about, but it is difficult to find the time to really do my ideas justice. Therefore, I decided to focus myself more on development then writing.
Shortly after my previous blog post I made a start with my first prototype for the home automation DSL for which I decided to use MetaEdit+. I do have to confess that this was the first time I really made use of MetaEdit+. However I do not regret spending my time on getting used with it. In other words, I am impressed by how quick I got my self familiarized with the tooling (only a matter of hours). The concept MetaEdit+ uses to store models is in line with what I expect from a language workbench. Objects, properties and relations are well separated and offer the flexibility needed during the design process of a language. You can modify the language without the need to regenerate a document model or the visual representation of it.
 

However, from the usability perspective I still see room for improvements. MetaEdit+ is definitely one of the more intuitive and flexible domain modeling tools. Nevertheless, the user still has to get used to concepts as languages, visualizations and models. From a technical perspective I really prefer this clear distinguish, but for domain experts who would like to create models without being forced to use a language pre-defined by others it might be interesting to make this as transparent as possible. 

After seeing and working with tools like the Microsoft DSL Tools, Microsoft SQL Modeling, MetaCase MetaEdit+, MetaEnvironment (CWI) and Intentional Software, the conclusion is that they all have some overlap in concepts, but are unique in their own way. Some tools are more focused on academic people with knowledge about formal languages, others on developers creating frameworks. But in all the tools I am missing something and that is the focus on domain experts and collaboration between people with different kind of expertise. 

For the most part language workbenches seem to follow a process, where as the first step a language has to be designed, then a visual representation and then the models. Before a domain expert is able to define its models someone with knowledge of designing languages should be involved. In some cases, languages and visual representations even have to be compiled and distributed by installation packages before they can be used. This might be no issue when these tools are used in combination with existing software frameworks. A very good example of a successful DSL is the ACA.NET Service Factory from Avanade, build using the DSL Tools from Microsoft. ACA.NET Service Factory is build for a technical domain, meant to be used by developers and to be used at multiple projects to pay back the investment. The DSLs in this case are quite stable, so not using dynamic modeling tools is not a big issue. 

The less flexible a DSL tooling will be, the more time it will take to develop a specific version of a DSL. In my opinion, this will become an issue on projects where custom build DSLs are a key element of the requirements engineering and development process and constantly subject of changes. But how can we make DSM more interesting for to be used in crucial parts of projects where the domain is not clear yet?
In practice, domain experts within companies already created their own languages. They use applications like Excel to write down business roles. One example I have are the medical acceptance procedure from my Masters thesis. The medical advisor used Excell sheets. These sheets had columns to refer to other questions depending on the answers given and columns with values for calculating risks. The sheets however could not be used as input for generating code. 

I am working on a concept that will follow different process of designing languages then currently used when working with other language workbenches. In my concept models are used as a starting point rather than a language design. The first prototype I am creating will definitely support tables, graphs and forms but might also include for example flows and trees in future versions. The first step by the user will be to choose a visualization form it thinks will be suitable to express its thoughts, for example a table. The user then puts the data into the table. When it adds columns, it is has to name them. By doing this, the user is creating a language.
The previous months I have worked on a prototype. The results so far are, despite of a lot of concessions I had to made, very promising. Building a graph tool using WPF (Windows Presentation Foundation) is one of the biggest challenges I am currently focusing on, but will result in a interactive experience for the end user. In the coming months I intend to post about my experiences with WPF and post more details about the design of my prototype.

If you follow blogs of other Oslo enthusiastic, you couldn’t have missed it. Oslo , the codename for Microsoft’s new modeling platform, has been renamed to SQL Server Modeling.  Confirms this that the focus will shift to SQL Server instead of creating a modeling platform for DSLs and storing models?
This development is however something that comes as a disappointment to me. I was hoping for improvements to Oslo which should raise the speed of creating and deploying DSLs. Something I am missing is the possibility to modify language definitions without the need to redeploy your schemes and without losing your models. This is something essential when dealing with changes in DSLs, especially during prototyping. But if Microsoft is really moving their focus to SQL, it will not surprising me if these features will never be developed.

Some other news that is also interesting, but might also be confusing, is the use of SQL Server Modeling Services as underlying application model for Microsoft’s cloud, Azure.
Using DSLs to model applications running within a cloud is something that is in line with my vision for years. If you really want to stimulate people to connect their online services running within a cloud, you should make it easy for them by raising the abstraction level of application development. I believe that DSLs will be the way to make this possible, but I also see that the language workbenches currently available would have to undergo a necessary transformation. I therefore really wonder how this will fit within the direction Microsoft is taking with the SQL Server Modeling Services.

However, I’m still interested in using the SQL Server Modeling Services (Hmm, the name ‘ Oslo ‘ still sounds a lot better) as platform for sharing models. For DSL prototyping however, I will use other tools. Hopefully Microsoft will at the end choose to change the name of there moddeling platform to something like the “Azure Modeling Services” .
To see what other people are writing about the rename:

• Gerben van Loon – “Oslo” renames to SQL Server Modeling”
• Keith Short – Codename “Oslo” Repository Becomes SQL Server Modeling Service
• Aali Alikoski – Oslo -> SQL Server Modeling

To read more about the name change, see this post and other blog posts of Douglas Purdy.

Thursday I went – together with my brother (Martin) – to an event on Home Automation (Beurs Domotica & Slim Wonen). On this event a number of installers and manufacturers of home automation equipment were represented. We used this opportunity to do some market research.
Most significant to realize, and what we knew before going to the event, is that the companies at the event focus mostly on the higher segment of the home automation market. Examples are Philips with their Pronto, Siemens with KNX hardware and a lot of manufactures of touch screen units.
Software solutions
We were mainly interested in manufacturers of software solutions. We talked to some of them which gave us a good indication of where the home automation market stands today. Some of the most remarkable things were the user interfaces. Some of them were so messy that we didn’t understand where all the buttons were meant for. Others were kept as generic as possible which made it difficult to distinguish features by importance and type. There were some more impressive ones, but they need to be configured by the installer. We think a lot of improvements are possible here.
Another significant thing is the support of systems of external parties. KNX is by far the most supported standard enabling manufacturer independent extendibility. Some companies will also support the X.10 which is popular in the lower segment of the market. Extensions to other systems like a/v equipment however are something that seems to have a lower priority. One system we saw had an integrated web radio, but this was limited to one party. If they supported DLNA, lots of other a/v applications would be possible as well.
The lower segment 

Within the lower segment of the market we find manufacturers like KlikAan-KlikUit and Marmitek (X.10). They also offer software, but these are very limited in functionality and often support only their own systems or single protocol. Their equipment however is affordable for a much larger audience. An example of not manufacturer specific software is HomeSeer, which offers extensibility through APIs. An advantage of the HomeSeer software is that is has a large community of enthusiastic peopele developing add-ins for even the more affordable equipment. However, the average computer user would not have enough experience with finding and configuring these extensions. So, where the price is the barrier to a large audience within the higher segment of the market, the complexity is the barrier for the lower.
Significant players in the future
I believe that sooner or later home automation will become as common as the telephone and internet access. A growing market that is related to home automation is that of the Smart Metering. Within the near future utility companies will roll out many electricity, water and gas meters that send ‘usage information’ to a central system. Each meter will have its own data connection. This data connection will however have a lot more potential. This is something companies like Microsoft and Google also realize. These data connections might become a new gate for them to deliver information based services. Smart meters might also contain communication interfaces to home automation systems, so this might also be an opportunity to them to get access to this part of your house to without the need of a home server or internet connection. And so there are many other examples of existing multinationals that might extend their market this way.
Conclusion
Home automation is a living and growing market with enough space for innovations. Complete solutions can been found within the higher market segment. To make these complete solutions accessible to the lower segment of the market, home automation systems will have to become less complex and the need of custom development and configuration needs to be taken away. At this moment a lot of innovations comes from small start-ups, but it would not be inconceivable that large companies like Microsoft and Google will enter the market soon.

In my previous blog posts and papers I referred to my master’s project. During this project I designed and build a prototype of a DSL for medical statements. My DSL is now used within Avanade Netherlands as a case study for other interns. Michael Wolbert and Bryan Sumter developed my DSL further by making a version of the DSL for Microsoft Oslo, which will be presented at the Microsoft PDC next week. Gerben van Loon wrote a blog post: “Questionnaire DSL with Microsoft “Oslo” overview” about it showing some of it’s details that might be interesting to have a look at.
The master’s thesis of my which is the root of this project will be hopefully made public soon.

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:

TV Serial Control   

Request:

Response:

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.

From the embedded prototyping systems I considered, the Arduino is one of the cheapest and the most popular ones. The combination with the ethernet shield will make it the perfect addition for my home automation project. This weekend I received the one that I have ordered online.
  

The ATmega328 microcontroller used by the Arduino includes a serial connection, PWM outputs, I2C bus, analog inputs and more. This will make it ideal for connecting my LCD TV, RGB Led lighting, climate sensors and other equipment to the network. Running simple macros on the controller will in some cases take away the need of a home server being on 24/7. It seems that I’m not far away from generating my first code for embedded devices.

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.

The hardware that I have selected offers the functionality that I will need for this project. Unfortunately, this is not the case for all the software that was provided with the selected hardware. PlugWise is the only one providing software with webinterfaces and some kind of webservices. The other software is simply not focused on extensions to other type of systems.

The table will give an overview of the solutions chosen for the first prototypes of my home automation system.

The solutions that I haven chosen will raise the abstraction level and will make it easier to integrate them. In a next phase of my project, when the first DSL will be defined, I will give a more detailed look at the APIs.

In a series of blog posts about the domain of my home automation DSL I’d like to start by giving a first and high level description of the problem domain. I’m going to do this by explaining the current situation of my own home automation system.

Since, I have the intention to create a home automation system that will be suitable for a broad audience, the first step was to select – as much as possible – ready-to-use hardware available at DIY-shops, large retailers and the internet. The more expensive hardware has been selected for its multi-purpose.

Hardware includes:

·         A self configured Windows Home server running on an Intel Atom CPU. A Windows Home Server can be configured for a price as low as € 350,- when using for example an Asus EEE-Box.

·         Wireless switch units from KlikAan-KlikUit. (An introduction set with three receivers will cost less than € 20,-.)

·         RFXCOM transmitter. This will make it possible to control the wireless switch units from KlikAan-KlikUit and a lot of other manufacturers. The transmitter can be connected to a PC and costs around € 80,-.

·         LG 32 LH3000 LCD-TV, cost me less then € 450,-. It’s serial port makes it possible to control the TV by software at a PC or embedded system.

·         Network media players by Philips supporting UPnP. These days prices of media players that can be connected to the TV and support UPnP start at around € 100,- (e.g. the Asus O!Play). Some high-end TVs already have these players on board.

·         Wireless energy meters from PlugWise. With +/- € 35,- each, they are a little bit pricy, but they are very reliable.

·         Other equipment like USB Device servers and USB to serial converters used to connect equipment to the home network.

·         A HTC-Touch Diamond II mobile phone which has very interesting specs like a high resolution touch screen and WIFI.

All by all still a big investment, but to begin with home automation, you do not have to buy it all at once.

The image below shows how everything is connected.

The different hardware will have its own way to communicate. There are several Standards and protocols involved like ZigBee, RS232 and UPnP. Manufacturers however also use their own protocols based on for example HTTP.

In the next blog post I will explain how devices will interact with each other via software. Other posts that will follow will be about scoping of the domain and sub domains, other already available DSLs and choice of modelling software.

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.