ICONIX Process for
A roadmap for embedded system
development using SysML
Doug Rosenberg, ICONIX
At ICONIX, we’ve had pretty good success when we defined an
unambiguous development process, and presented that development process in
“roadmap” form. We’ve developed process roadmaps for use case driven software development, business modeling,
design-driven testing, and algorithm-intensive software design. In this article
we’re going to do it again, this time using SysML to describe embedded systems
that involve a combination of hardware and software.
Figure 1 – ICONIX Process Roadmap for Embedded Systems
Figure 1 shows the top level roadmap for ICONIX
Process for Embedded Systems. As
you can see, our roadmap starts off by defining requirements, proceeds through
modeling of system behavior and block structure, and then through definition of
constraints and parametrics, simulation, and then implementation in both
hardware and software. We’ll illustrate our roadmap using an example model,
developed by Sam Mancarella from Sparx Systems, that describes an Audio Player.
We’ll also introduce you to some unique capabilities of
Enterprise Architect Systems Engineering edition, which supports advanced
features such as executable code generation from UML models (including support
for hardware description languages such as Verilog and VHDL), executable SysML
Parametric diagrams and advanced scripting.
Each of these capabilities, taken standalone, adds a
significant amount of “horsepower” to a systems engineering effort. We’ll
combine these capabilities into a single process roadmap that’s greater than
the sum of its parts.
The Four Pillars of SysML - Requirements, Structure, Behavior, and
Our Embedded System Development Process Roadmap is built
around producing a SysML model that is organized into four sections. These
parts of the overall system model (Requirements, Structure, Behavior, and
Parametrics) are sometimes referred to as “The Four Pillars of SysML”.
As with UML, Packages are used to organize the model.
SysML Pillar #1: Requirements
Requirements are generally categorized as Functional
Requirements, which represent capabilities of a system, and Non-Functional
Requirements, which cover such areas as Performance and Reliability. You can
organize Requirements into hierarchies on requirement diagrams (see Figure 2).
EA supports allocation of requirements to other elements
using a simple drag-and-drop, and automatic generation of traceability
Figure 2 – Requirements for the Audio Player include
Performance, Durability and User Friendliness
Figure 3 shows the steps for Requirements definition from
our process roadmap. Note that allocation of Requirements to System Elements is
really an ongoing process as the model is developed, and largely occurs within
other roadmap activities.
Figure 3 – Roadmap: Define System Requirements
SysML Pillar #2: Structure
Blocks can be
used to represent hardware, software, or just about anything else. Block
definition diagrams represent system structure. Internal block diagrams
describe the internals of a block such as parts, ports, and connectors.
Figure 4 – Block Structure for the Audio Player
Figure 5 shows how our process roadmap approaches defining
5 – Roadmap: Model System Structure
If you think of a Block as an electronic circuit (one of
many things that a Block can describe), the Ports define the input/output
signals to and from the circuit. SysML allows you to describe the I/O signals
and transformations in great detail, and EA contains a built-in simulator that
allows you to plot the output graphically.
SysML Pillar #3: Behavior
SysML provides four main constructs to represent different
aspects of system behavior; use cases,
activity diagrams, sequence diagrams, and state machines. As shown in
Figure 6, our roadmap shows two parallel branches for modeling system behavior.
6 – Roadmap: Model System Behavior
One branch starts with use cases,
which describe scenarios of how users will interact with the system. Use cases
generally consist of a “sunny-day” part, which describes a typical success-path
for the scenario, and multiple “rainy-day” parts which describe unusual
conditions, exceptions, failures, etc. Figure 7 shows a Use Case Diagram which
organizes the scenarios in listening to the Audio Player.
7 – Audio Player Use Cases
Use cases are typically detailed on Interaction (Sequence)
Diagrams, which can also be drawn at a higher level. Figure 8 shows Interactions between the
Listener and the Audio Player. Note the
use of parallel paths on the Interaction Diagram.
8 – Audio Player Interactions, showing interactions occurring in parallel
The other branch on the roadmap involves defining
event-driven, finite-state behavior of some part of a system using state
machines. As a simple example, Figure 9 shows some finite state behavior
associated with Playlist Maintenance for our Audio Player.
9 – Finite State Behavior for Playlist Maintenance
One of EA’s unique capabilities is the ability to generate
functional (algorithmic) code from state machines. As you’ll see, these state
machines can be realized in software or in hardware using Hardware Description
Requirements are allocated to both use cases and states.
SysML Pillar #4: Parametrics
Parametrics allow us to define detailed characteristics,
physical laws, and constraints on system blocks that allow us to simulate how a
system will behave, then make engineering tradeoffs, and re-simulate until our
design meets the specified requirements.
Figure 10 – Roadmap: Define Constraints and Parametrics
Our roadmap provides two high-level activities in this area;
the first to define constraint blocks and parametric diagrams (shown in Figure
10 and illustrated in Figures 11 and 12), and the second to configure and
execute the simulations (shown in Figure 13).
Figure 11 – Constraint Blocks for the Audio Player’s
“Echo” signal processing function
Figure 12 – Parametric model for the Audio Player’s
“Echo” signal processing function
The ability to configure and execute simulations within EA,
eliminating the need to export the model to external simulation software, is
one of the unique capabilities of the Sparx SysML solution.
Figure 13 – Roadmap: Simulate
EA’s built-in support for scripting and graphical display of
simulation results tightens the feedback loop on making engineering tradeoffs
in the model to rapidly ensure that all system requirements are met.
Figure 14 – Results of simulating the “Echo” function
are displayed within Enterprise Architect and do not require the use of
external simulation software.
Hardware Description Languages allow the
specification of electronic circuits in a software-like representation.
According to Wikipedia:
In electronics, a hardware description language or HDL
is any language from a class of computer languages and/or programming languages
for formal description of electronic circuits, and more specifically, digital
logic. It can describe the circuit's operation, its design and organization,
and tests to verify its operation by means of simulation.
Figure 15 – Roadmap: Implement Hardware
EA’s long-proven ability to generate code has been extended to
support code generation in VHDL, Verilog, and System C in the Systems
Engineering Edition. While code generation is independent of SysML usage, from
a process roadmap standpoint, this means we can drive both hardware and
software implementation from our SysML model. Once code is generated in an HDL,
it’s possible to “compile to silicon” to realize the hardware solution on a
chip. This process is shown in Figures
16 and 17, which show how a playback controller can be generated in VHDL.
Figure 16 – SysML model of hardware component for
controlling audio playback
Figure 17 – Audio playback controller, generated in VHDL
implementations can leverage a variety of powerful capabilities that are
included with the System Engineering Edition of EA. Two of the more important
and unique capabilities are:
- The ability to generate functional
(algorithmic) code from behavioral models (state machines, activity
diagrams, and interaction diagrams)
- The ability to integrate EA models into
development environments such as Eclipse and Visual Studio.
Figure 18 shows a
high-level look at the Software Implementation activity from the roadmap.
Figure 18 – Roadmap: Implement Software
This article has presented a high-level overview of ICONIX Process for Embedded Systems,
which leverages Enterprise Architect System Engineering Edition to build
hardware/software models that are structured around the “four pillars of
SysML”. We’ve illustrated our process
roadmap with diagrams from Sam Mancarella’s Audio Player Example.
This topic will soon be expanded into an “eBook”: Embedded Systems Development using SysML and
For more information, visit ICONIX on the web at www.iconixsw.com, or contact us at SysMLTraining@iconixsw.com