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
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
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
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
Once the model hand-off work flow is complete, true downstream engineering can begin.
- Learn more about Rational System Architect:
- To learn more about the tool for collaborative, model-driven development for embedded systems, start with the Rational Rhapsody product line overview and the Rational Rhapsody page on IBM developerWorks. Also see the Rational Rhapsody 7.6 information center and the Changing the location of help content to get a local copy of the documentation.
- Explore the various versions, too: IBM Rational Rhapsody Architect for Software, a visual development environment for embedded systems and software
- IBM Rational Rhapsody Architect for Systems Engineers
- IBM Rational Rhapsody Designer for Systems Engineers
- IBM Rational Rhapsody Developer for collaborative, model-driven development of embedded systems. This edition is required for Eclipse users, and editions are available to create specialized projects in C, C++, Java, and Ada languages.
- To learn more about Rational Rhapsody design management capabilities, check out the IBM Rational Rhapsody Design Manager to see how to collaborate, share, review, and manage designs and models with the entire engineering team. Also see the Design Management page on Jazz.net.
- Explore the Rational software area on developerWorks for technical resources, best practices, and information about Rational collaborative and integrated solutions for software and systems delivery.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, anytime, and many of the Getting Started ones are free.
Get products and technologies
- Download a free, fully enabled trial version of Rational System Architect.
- Take an online tour of Rational Rhapsody with an online trial or download Rational Rhapsody or special editions to Evaluate, free of charge, for 30 days.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, or use it in a cloud environment.
- Participate in the Enterprise Architecture and Business Architecture forum, where you can share information about methods, frameworks, and tool implementations. Discussions include tool-specific technical discussions about Rational System Architect.
- Join the discussion in the Rational Rhapsody forum.
- Get connected with your peers and keep up on the latest information in the Rational community.
- Rate or review Rational software. It's quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.