Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > 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 

The first block, labelled 3_266, is specified in the lower-level VoiceOutput subdiagram. 3_306 is the start of the DTMF handling: wait for DTMF input, timing out after 5 seconds (this period is taken from the Timeout relationship). If we time out with no input, jump to 3_354, say the voice output specified in the Timeout relationship's reused VoiceOutput subdiagram, and jump back to the start of the first block.

The meat of the DTMF handling is a series of Test-If-Jump blocks, which compare the DTMF tones received with the characters specified in the ConditionalFlow relationships, jumping to the appropriate VoiceOutput block if there is a match. If no match is found, we fall through to the "Invalid input!" section at the end of the 3_306 block, which is generated similarly to the Timeout section.

Moving on to the VoiceOutput section of the generator, listing 3 shows the output for figure 6. The first block shows the code for the flow up to the GotoPoint, which is label 3_844. The code after 3_844 is essentially the sample code from listing 1: the generator fulfils its requirements.

Listing 3: Generator output for Mode menu.

The VoiceOutput generation was handled by a generator in the VoiceOutput modelling language. As the basic sequential flow control was the same for all object types, that was handled with one generic _followFlow generator. This followed the relationship to the next object and called the generator for that object type. The name of the subgenerator to be called is formed on the fly from the name of the type, allowing a new type to be added to the modelling language simply by specifying one small subgenerator for it. Listing 4 shows the generator definition.

A From role, Flow or False relationship, and To role are followed to the next object: (A|B) specifies either type A or type B, and () specifies any type. The name of the generator to call is formed from the output between the subreport and run keywords, that is, _do followed by the name of the object's type, for example, _doIf.

Listing 4: "_followFrom" generator definition.

The generator begins from the Start object and calls _followFlow from it. Each object type's generator handles its own line or lines of output and then calls _followFlow again, making a simple recursion step through the model. The generator for the Stop object does not recurse, and thus the generation finishes there.

The _doIf generator handles the FALSE path as normal sequential flow with the _followFlow generator. The TRUE path, however, is handled by outputting an assembly language test statement followed by a conditional jump to the label specified by the GotoPoint, without any recursion to follow the code on from the label. This avoids the problem of an infinite cycle or duplicate code.

Text and SystemCall objects may contain several TextFragment or Command objects, leading to several lines of output, for example, the first five lines of listing 3. These are handled simply by iterating over the contained objects as shown in listing 5. The listing also shows the final _followFlow call.

Listing 5: "_doText" generator definition for Text object type.

Main results
The presentation by Domatic's experts to their management revealed that the proof of concept was partially successful. The modelling language and generators were seen to have accomplished the objectives set for DSM:
 • The models visualized application structures well
 • The modelling language and generators forced developers to do things right
 • Applications which previously took a day could be made in an hour or two
 • Better reuse possibilities within and across products
 • The models provided consistent documentation
 • Test plans could be integrated with models

However, Domatic's needs were not just for this single domain, but for applying DSM in a range of domains. The time constraint of effectively three hours meant that only simple cases had been handled in this domain, leaving uncertainty over whether DSM or the tool could cope in other domains.

It is also likely that time constraints forced the consultant more into doing things himself, rather than having the time to explain everything and let Domatic's experts try their hand at doing things themselves. Developers are loath to tell management something can be done unless they are certain of their own ability to do it. Domatic's experts thus also raised a number of concerns that the proof of concept had not been able to answer:
 • Coding such simple applications was not challenging for average developers
 • Uncertainty about 100% code generation
 • Uncertainty about backward compatibility with existing code
 • Are code generator facilities flexible enough?

 First Page Previous Page 1 • 2 • 3 • 4 Next Page Last Page

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


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