Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Designing home automation network with DSM (Part 2)

Posted: 13 Feb 2015     Print Version  Bookmark and Share

Keywords:modelling languages  home automation system  Domatic  DSM  microprocessor 

As explained in Part 1 of this series, for each home automation system type you have created there would normally be one set of diagrams specifying how the user could control it over the phone. At the top level would be a VoiceMenu diagram, and each VoiceOutput object in that could be exploded to its own VoiceOutput diagram.

An example model
In our example application in figure 5, the telecom module responds to the call with the main menu: an initial welcome message and list of the options. To keep things simple, here there are only two options: pressing 1 takes the user to the mode menu and pressing 2 to the version info.

The version info is simple: it reads out the version info and waits for the user to press 1 to return to the main menu. The InvalidInput and Timeout relationships are even simpler: each simply says "Invalid input!" or "Timeout!" and returns to the previous menu as shown.

The mode menu is more complex: it reads out the current mode and a list of all modes, telling the user which key to press for each. The DTMF_Input for the mode menu allows the user to press a key corresponding to a mode. As there are five modes, the key must be from 1 to 5 (setting the mode to 0 does nothing). If legal input is received, the "Set mode" object's subdiagram uses a SystemCall to change the system mode to match the key which was pressed.

Figure 5: Sample VoiceMenu model.

The details of the mode menu are described in the VoiceOutput subdiagram in figure 6. After initially stating the current mode and telling the user to select another mode, the application initializes a counter variable, register A, to zero. After the GotoPoint, A is incremented and we move to the bottom row of the diagram, heading left. The number of modes, five, and their names are built into the system, so the system can say the name of the first mode and "press 1." In the If object we check that A has not yet reached the value of the last mode, five, and if so we jump to repeat for the next mode from the GotoPoint. After the fifth mode has been read and the test in If fails, we exit via Stop back to the VoiceMenu diagram, where we wait for the user to press a key corresponding to a mode.

Figure 6: Sample VoiceOutput model for mode menu.

Home automation language use scenarios
As we mentioned above, the two modelling languages aimed to provide a natural way to describe and specify the desired behaviour of the voice menu, and of the voice elements and system calls that made up each segment of speech. The VoiceMenu language was specific to the domain of voice menus, which was a common basis shared by Domatic's developers, clients, and clients' end-users. It could thus easily be used as a medium of conversation between all these stakeholders, and allowed specification of systems at a high level of abstraction.

A likely use scenario would have been for a Domatic employee to work with a client to design the voice menu, directly using the VoiceMenu modelling language in the DSM tool. If example texts were specified in the top-level elements, a slight modification of the generator would allow working prototypes to be built and tested immediately.

1 • 2 • 3 • 4 Next Page Last Page



Comment on "Designing home automation network wi..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top