Interface control documents and Model-Based Design

An Interface Control Document (ICD) can be defined as

document that describes the interface(s) to a system or subsystem. It may describe the inputs and outputs of a single system or the interface between two systems or subsystems.

Within the traditional textual based development process, an ICD was either a text-based document or, a UML type diagram or a combination of the two.  Within the MBD development process, it is not entirely clear if additional supporting documentation is required or if the Model can serve as the ICD.

With most topics that I write about I have reached a firm conclusion on what is the accepted best practice.  In this area, I still have open questions.  In this post, I lay out the pros and cons for using models as ICDs.

Why models are sufficient:

The simplest argument as to why models are sufficient is that the models can be used in place of UML diagrams provided the interface has the sufficent markup.  For example in the image below the Simulink Interface View provides the data types and rates of all the inputs and outputs to the system.


When the model is part of a model hierarchy than the calling structure can be derived from the model.  (Simulink Model Dependency View)

Why models are lacking:

While the two views above are good, they lack information that is commonly found in ICD documents; the function interface (e.g. the C or C++ calling methods) and the data interface.  The models contain and use this information however they do not, natively, display the information.   Note: this is a limitation of UML diagrams as also.

The next issue with models as an ICD document is a question of “push and pull.”  By having the model as a development artifact and the ICD document you need to implement a change request process.

Lacking-Leaders-4-NEW_04.gifWhat can be done?

Use of automatic report generation can augment the information provided natively by the model.  Doing this could, in fact, generate a “standard” text-based ICD with the advantage being that the model would stay the single source of truth.

As with most issues in the development where there is not a native tool it is the implementation of a process that helps to bridge the gap.  All ready for text-based ICDs people have change request processes in place.  The question with an MBD approach is who implements the change at the model, and at the system level?

As always, please feel free to share your thoughts in the comment section.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s