Modeling vs. Design vs. Rapid Prototyping

By paul ~ November 21st, 2008. Filed under: Best Practices, Systems Engr..

As I was writing the post Why is Model Driven Systems Engineering So Important? and particularly the section on requirements analysis, one project stood out in my memory.  I have performed a lot of modeling and analysis with Foresight, but this job was different.  I was asked to help a small company that developed voice-interactive navigation systems rapidly prototype next-generation functionality for the CES show in Las Vegas.  As so often happens, I was engaged about 6 weeks before the deadline.  (Why is it always 6 weeks?  I mean really.  It’s almost always 6 weeks.  Why?)

To start out with, a small team was assembled in a room and the CEO began to describe his vision of the next generation system.  It was to have, not only the navigation and voice interactive games capability of the previous version, but also hands-free cell phone, audio (MP3), E-mail (compose and read E-mail via voice) and some other little web-based applications, all voice interactive.  The device would have no display at all.  Our objective was to have a demo (not full functionality) for the CES show, about 6 weeks away.  The team was composed of software developers with a variety of expertise appropriate to the new applications to be developed.  We quickly determined that we would do the system-level design as well as the integration in Foresight.  Applications would be developed in appropriate languages (C++ and Java were used), then connected to the Foresight model to create the integrated prototype behavior.  (Foresight’s implementation-in-the-loop SDK makes it easy to connect other software applications into the system model.)

As I listened that first day, I actually sketched the system block diagram in Foresight from the information being provided by the CEO and from his sketches on the whiteboard.  Asking questions allowed us to quickly add the first level of detail.  (Note that, had we been using a more formal systems engineering process, we would have spent more time with use cases and the like.  In this “rapid prototyping” approach, we just went straight to structure.)  Interestingly, this top-level diagram persisted with few changes (we only added detail) throughout the remainder of the project.  [I actually place a very high value on making the model look the way the customer draws the problem.  This greatly facilitates communication throughout the design process by eliminating costly and error-prone translation.  Whenever possible, use the same words for processes and flow names as the customer would use. ]

As we continued the modeling, it quickly became apparent that we were going to need a way to manage the interactions between the user and the multiple applications.  For instance, imagine the use case where you’re driving down the road using the navigation system, listening to music, get a call, answer the phone, then during the conversation, the navigation needs to announce an upcoming turn.  Clearly there is a sense of priority in the communications and applications.  Since all you have is audio, there has to be some kind of auditory queuing that lets the user know what’s going on so that they don’t get lost in the stack of applications they’re using.  We ended up developing a voice-interactive operating system (VIOS) that managed the interaction with the multiple applications in much the same way that Windows enables you to manage multiple applications that you have running.  We developed the behavior of this VIOS entirely in the Foresight model with lots of experimentation long before we had the applications.  In fact, the modeling effort quickly identified requirements on the interfaces of the applications for prompting and interruptibility.  [The Foresight simulatable model was connected to the voice recognizer and audio output so that we could directly “experience” the interactions during development.]

The command processing state machines for not only the VIOS but also the applications were developed using Foresight state transition diagrams.  This made it extremely easy to modify and debug the behavior.  We could interact with the system while watching the transitions and current state in the state transition diagrams.  This was invaluable.

Another core component of the architecture was a message passing bus that connected the applications to the VIOS and to each other.  Again, the bus behavior, which was fairly complex, was entirely designed in Foresight.

Because we had a simulatable model through all phases of the project, we were able to work at the system-level and on the applications simultaneously.  As applications were completed, we plugged them into the model for test and further refinement.  (We “implemented” some applications, such as E-mail, almost entirely in Foresight for the demo when little external behavior was needed.)

You’ll laugh, but the “demo” was actually the Foresight simulation, running in batch mode, on a tiny PC with only speakers, microphone, and cell phone attached.  We had it set up so that the simulation started automatically when the machine booted.  It would give its initial voice prompt and away you’d go.  Of course it didn’t completely work by the time we got to the show.  I hardly had time to eat!  I’d work on it all night and even during the daytime at the show, tuning the behavior, right up until and between demos.  One of the biggest problems was that we were in the automotive electronics section.  Imagine attempting to demo a voice-activated anything right amongst a dozen car stereo companies all showing off their subwoofers!

This was a fun project.  But I have a question.  What were we doing?  Were we modeling?  Were we designing?  Were we prototyping?  And this goes back to an early statement I made in my last post.  In the systems-level design activity, modeling and design can be one and the same.  Building the model is “designing”.  Modeling should not be considered or executed as a separate, high cost activity.  Otherwise, you’ll always be trying to decide “is it worth it?”

The beauty of the approach is that you have something tangible and interactive to work with from the beginning.  And, because you’ve worked out the kinks in a simulatable model, implementation is straightforward.  Implementing a complex state machine in a programming language is cake if you’ve got a nice graphical representation to follow and have the behavior all worked out.

I’ve now used the Model Driven Systems Engineering approach on a variety of projects.  The benefits are so obvious, I wouldn’t think of building any significant project any other way!

Comments are closed.