Enterprise Architect version 13

download
purchase

English Chinese (Simplified) Czech Dutch French German Italian Korean Polish Portuguese Russian Slovak Spanish Swedish

My Profile

Social Media Channels

facebook google plus twitter youtube linkedin

Monday, 09 November 2009 23:59

ICONIX Process for Embedded Systems - A roadmap for embedded system development using SysML

Written by 

 

 

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 roadmapsfor 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 Development

Figure 1 – ICONIX Process Roadmap for Embedded Systems Development

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 Parametrics

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”.[1] 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 matrices.

Figure 2 – Requirements for the Audio Player include Performance, Durability and

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

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 4 – Block Structure for the Audio Player

 

Figure 5 shows how our process roadmap approaches defining system structure.

Figure 5 – Roadmap: Model System Structure

Figure 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.

Figure 6 – Roadmap: Model System Behavior

Figure 6 – Roadmap: Model System Behavior

One branch starts with use cases[2], 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.

Figure 7 – Audio Player Use Cases

Figure 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.

Figure 8 – Audio Player Interactions, showing interactions occurring in parallel

Figure 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.

Figure 9 – Finite State Behavior for Playlist Maintenance

Figure 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 Languages (HDLs).

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

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 fu

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 fun

Figure 12 – Parametric model for the Audio Player’s “Echo” signal processing function


Simulation

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

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 Enter

Figure 14 – Results of simulating the “Echo” function are displayed within Enterprise Architect and do not require the use of external simulation software.

Implement Hardware

Hardware Description Languages allow the specification of electronic circuits in a software-like representation. According to Wikipedia[3]:

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 16 – SysML model of hardware component for controlling audio playback

 

Figure 17 – Audio playback controller, generated in VHDL

Figure 17 – Audio playback controller, generated in VHDL

Implement Software

Software 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

Figure 18 – Roadmap: Implement Software

Conclusion

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 Enterprise Architect.

For more information, visit ICONIX on the web at www.iconixsw.com, or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.

 

 

 


[1] OMG Systems Modeling Language Tutorial, INCOSE 2008

[2] See Use Case Driven Object Modeling with UML: Theory and Practice by Doug Rosenberg and Matt Stephens for a lot more information about use cases.

[3] http://en.wikipedia.org/wiki/Hardware_description_languages

Read 11993 times Last modified on Tuesday, 09 April 2013 22:54
Rate this item
(2 votes)
doug rosenberg

doug rosenberg

ICONIX (Chief Executive Officer)
 
Doug Rosenberg founded ICONIX in his living room in 1984 and began training companies in object-oriented analysis and design around 1990. ICONIX specializes in JumpStart training for UML and SysML, and offers both onsite and open-enrollment courses.
 
Doug developed a Unified Booch/Rumbaugh/Jacobson approach to modeling in 1993, several years before the advent of UML, and began writing books around 1995. Design Driven Testing is his 6th book on software engineering. He’s also authored numerous multimedia tutorials (including Enterprise Architect for Power Users) and several eBooks, including Embedded Systems Development with SysML.
 
Doug has spent the last few years doing "deep dive" consulting into cutting-edge technology including cross-platform mobile app development, REST APIs, and NoSQL databases, and gaining first-hand experience on some "hardcore agile" projects of varying sizes.  He's also been working with dozens of graduate students at the University of Southern California Center for Systems and Software Engineering (USC CSSE), managing Directed Research projects and developing/piloting the Resilient Agile process. 

Website: www.iconixsw.com/
Login to post comments