What is on your white board?

In meetings or in your office the humble white board(0) is a rapid prototyping environment through which we communicate ideas. Chances are if I have ever spoken with you in a room with a white board, I have drawn this(1) representation of Model-Based Design system architecture. 

 As I drew I would have spoken about the following concepts

1.) The Green: model hierarchy:

a.) To support team based and unit testing development workflows create your models in a hierarchical fashion. Use model reference to encapsulate each level of the model.

b.) The “final” level of the hierarchy should be a model that is owned by a single developer and should be of a size and complexity that someone besides the developer (2) can understand it with an hour review.

2.) The Red: separation of hardware

a.) Calls to hardware functionality should be separated from the algorithmic code

b.) For simulation based testing create “I/O” which enables the

                   i.) Validate of interfaces

                   ii.) Stimulate the algorithmic model with “safe” values

c.)Within the hardware I/O modules convert the date from digital (counts, volts,…) to engineering units.

3.) The Blue: version control / software practices…

a.) Place the objects into version control (e.g. model, data, test files, reports...)

b.) Identify objects that can be reused across projects

c.) Requirement documents, test results, and utility functions should exist within the repository (3)

4.) The Black: Data and tests

a.) Create a data dictionary that exists separate from the models

                   i.) The data dictionary includes model and test data (test inputs and results)

                  ii.) The data dictionary includes model and build configuration information

b.) Create a generic test infrastructure for

                   i.) Running the tests

                   ii.) Creating test reports

                   iii.) Performing common test validation tasks

c.) Reports: use the testing infrastructure to create reports for status tracking and internal review   

Cleaning the board

I would be interested in seeing what is on your white board. To start things off I have captured a few of my co-workers boards….

Information dense

Delta estimates

Project specific

Footnotes:

0.) I still prefer chalk boards to white boards(4) even though I see the advantages of white boards; I just like the tactile feel.

1.)   Honestly if you have seen me draw this in person it was not this neat and clean as the discussion would have included redrawn lines to incorporate the bits of your own process.

2.)   Always be ready for the developer of an algorithm to move on; 95% of the time I want clarity over cleverness in design. 

3.)   The requirements documents don’t show up in this white board picture, this is to represent the reality of many engineering environments

4.) These footnotes are using C zero-based indexing.

BIO

Michael Burke is a consultant with The MathWorks and former coordinator for the MathWorks Automotive Advisory Board (MAAB). I currently focus on Model-Based Design Process Adoption projects. Views expressed in this article do not represent the views of The MathWorks.