Top 10 modeling hints for system engineers: #6 Model-based hand offs preserve fidelity

Learn to build good system engineering models in such a way as to support the hand-off of models and text to downstream engineering.

Share:

Bruce Douglass (Bruce.Douglass@us.ibm.com), Rational Chief Evangelist, Systems Engineering, IBM

author photoEmbedded Software Methodologist. Triathlete. Systems engineer. Contributor to UML and SysML specifications. Writer. Black Belt. Neuroscientist. Classical guitarist. High school dropout. Bruce Powel Douglass, who has a doctorate in neurocybernetics from the USD Medical School, has over 35 years of experience developing safety-critical real-time applications in a variety of hard real-time environments. He is the author of more than 5,700 book pages from a number of technical books including Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, and Design Patterns for Embedded Systems in C. He is the Chief Evangelist at IBM Rational, where he is a thought leader in the systems space. Bruce consults with and mentors IBM customers all over the world. Follow Bruce on Twitter @BruceDouglass.



12 November 2013

Also available in Chinese Russian Japanese

A typical hand off from systems engineering to downstream engineering (including mechanical, electronic, and software engineering) involves the production of textual requirements. Not only is this a labor intensive, but, as with system requirements, is fraught with problems:

  • Lack of precision
  • Completeness Accuracy
  • Correctness

If you're going to the trouble of building good system engineering models, you might as well construct them in such a way as to support the hand-off of models and text. Figure 1 shows the workflow in the Harmony process for the hand-off to downstream engineering.

Figure 1. Harmony workflow for the hand off from systems engineering
Downstream hand off

The two threads in this workflow specify the physical interfaces between elements. This is known as the shared model. They then create a downstream engineering model for each and every subsystem.

The shared model contains elements to share or reference by more than one subsystem. This includes interfaces between the system and the actors. It also includes interfaces between the subsystems themselves. Much of this system engineering model has specified logical interfaces. But, at this point, the subsystems must refer to the actual intended implementation of the interfaces; that is, the physical interfaces. The workflow on the left of Figure 2 translates the logical interface information into physical interface specifications, which are then configuration managed.

On the right-hand side of the first, the subsystem models first import their specifications from the system engineering model. Then the requirements are allocated to the contributing engineering disciplines (e.g. mechanical, electrical, and software) within the subsystem. Some requirements may be simply allocated to a discipline. It is common for a requirement to be realized by a combination of elements from different engineering disciplines. Those requirements must be decomposed into derived requirements which may then be allocated to a single engineering discipline. I most commonly use block diagrams for this, using stereotypes and naming conventions to identify blocks which are exclusively software, mechanical, or electronic in nature. Requirements are then easily allocated to these elements.

Figure 2. Breaking down a subsystem into elements from different engineering disciplines
subsystems with boxes for each engineering discipline

Click to see larger image

Figure 2. Breaking down a subsystem into elements from different engineering disciplines

subsystems with boxes for each engineering discipline

It is also important to define the interfaces between elements of the different engineering disciplines, such as the software-electronic interfaces. This way, the engineers on both sides of that interface have a common set of expectations. For this, I use a feature of UML and SysML called tagged values. Tagged values allow you to define metadata important to the model. In the case of software-electronic interfaces, this includes:

  • Type of interface (e.g. memory mapped, port mapped, or interrupt mapped)
  • Structure of the interface
  • Timing information

The specification for a software-electronic interface is shown in Figure 3.

Figure 3. Specifying a software-electronics interface
metadata for the model

Once the model hand-off work flow is complete, true downstream engineering can begin.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=952385
ArticleTitle=Top 10 modeling hints for system engineers: #6 Model-based hand offs preserve fidelity
publish-date=11122013