An overview of Systems Modeling Language -

An overview of Systems Modeling Language

Since its inception in 1997, the Unified Modeling Language (UML) has proved immensely popular with software engineers to the point where it's now the only widely used visual modeling language for software engineering. In the past, UML's software focus has discouraged many system-level engineers from adopting it in earnest. Those who did adopt it developed strategies to cope with its shortcomings. A common approach was to model additional systems-engineering concepts in other modeling tools ranging from Visio to Verilog and then integrate the models. Because integrating the different viewpoints and achieving traceability was difficult using this approach, the Object Management Group (OMG) decided to pursue UML for systems engineering.

In March 2003, the OMG issued a Request for Proposal (RFP) for a customized version of UML suitable for systems engineering to be commissioned by the OMG's System Engineering Domain Special Interest Group (SE DSIG). The customization of UML for systems engineering is intended to support modeling of a broad range of systems, which may include hardware, software, data, personnel, procedures, and facilities. Only one submission to the RFP arrived: a consortium called SysML Partners ( proposed the Systems Modeling Language (SysML). The SysML Partners has a broad range of members, including system engineers, tool vendors, government organizations, and academic institutions. Artisan Software Tools (our employer) is an active member of the SysML consortium.

In this article, we'll look at why SysML is necessary and summarize the SysML specification including the modifications to UML 2.0 that are being proposed as well as new elements such as requirements and parametric diagrams.

Shortcomings of UML
Systems engineers have taken various approaches to address the shortcomings of UML. Some engineers use the stereotypes provided in UML to create libraries or profiles of entities in their application domain. By applying these libraries, they're able to express nonsoftware concepts. Others used software such as Visio to model their systems engineering concepts, in conjunction with their UML model. However, with this approach they were left with two separate models that they were unable to integrate or cross-reference. Some tool manufacturers extended UML to allow integration of hardware, software, and systems engineering concepts in a single model. This left the tools open to a charge of being “nonstandard.” But, since most systems engineers are pragmatists, this argument wasn't usually very compelling. Finally, others simply ignored the problem and bent UML to fit or used words to fill the gap.

Those who know UML find it to be an effective modeling language. The roots of UML are firmly in software. The OMG (1997) states that the “Unified Modeling Language (UML) is a general-purpose visual modeling language that is designed to specify, visualize, construct and document the artifacts of a software system.”1 However, many systems engineers believed the UML to be sufficiently flexible to support extensions to address the needs of systems engineering. One of the strengths of UML is its built-in mechanisms for specializing the generic forms of its modeling elements to more application-specific variants. Collectively, these built-in mechanisms provide a capability for UML Profiles that package specific terminology and substructures for a particular application domain. By exploiting Profiles, SysML has the potential to achieve OMG's goal of a “standard modeling language for systems engineering to analyse, specify, design, and verify complex systems, intended to enhance system quality, improve the ability to exchange systems engineering information amongst tools, and help bridge the semantic gap between systems, software, and other engineering disciplines.”2 However, the modifications to UML needed for systems engineers require more than just the addition of stereotypes.

The starting point for many systems engineers is the System Context Diagram, which depicts the input/output flow among the system and its components, interfaces, and elements. The Deployment Diagram is used to “define the execution architecture of systems that represent the assignment of software artifacts to nodes.”3 This diagram's most basic fault is the inability to model hierarchical system architectures in any detail.

In previous versions of UML, the Object Sequence Diagrams were also clumsy to use. Systems engineers had no way to link to other subsequences, such as included or extended Use Cases. As much of the systems engineer's work in UML dealt with the Use Case or behavioral view, the workaround for linking sequences became awkward and repetitious. Additionally, systems engineers had no way to link to requirements; nor could they model parametric equations.

UML 2.0 went some way toward addressing the problems of modeling architectures. Although its Structured Class Diagram provides a hierarchical architecture, UML 2.0 doesn't allow the modeling of flows on those links. Nor has the OMG addressed links to requirements, parametric equations, and other issues.

The OMG's goal is to provide a “standard modeling language for systems engineering to analyse, specify, design, and verify complex systems, intended to enhance systems quality, improve the ability to exchange systems engineering information amongst tools, and help bridge the semantic gap between systems, software, and other engineering disciplines.” 2 Other models include parametric models, requirements relationships, causal analysis, verification models, and decision trees.

In this section, we'll outline some of the additions and modifications to be made to UML 2.0. By no means is this a complete list; instead it's a list of only the major highlights for systems engineers. We've taken many of the descriptions and examples directly from the specification, with additional information added for those readers not familiar with UML. For a complete description, you can read the SysML specification at Unlike many other UML specifications, it contains a worked example and is written in more accessible language.

Major changes to UML 2.0
One goal of the SysML Partners is to use UML 2.0 as much as possible and avoid making changes unless absolutely necessary. During the initial stages, many new diagrams were considered; these diagrams have now been edited down to just two—the Requirements Diagram and the Parametric Equations Diagram.

Requirements Diagrams
The starting and ending points for any system are the system requirements. Traditionally, requirements are large documents provided in printed or electronic form. Additional documents and models are created to demonstrate a system that will meet these requirements. To link the requirements to the models or other documents, system engineers create compliance matrices, initially in written form or directly in spreadsheets or databases when these tools became available. Specialist tools for requirements management were created such as Calibre and RTM. These worked well for text-based documentation but couldn't link to models. To address this, “surrogate” documents were created where each element in the document corresponded to an element in the model. Other tools such as Cradle and RDD-100 combine requirements and modeling together, normally making use of proprietary notation. However, as these were specialist systems-engineering tools, handing over the information to software engineers and other disciplines was laborious and difficult.

One of UML's strengths is that it's more than just a set of diagrams. There is an underlying model that supports the diagrams. The Requirements Diagram therefore also has an underlying requirements model. SysML states: “The requirements model describes the SysML support for describing textual requirements and relating them to the specification, analysis models, design models, etc. A requirement represents the behavior, structure, and/or properties that a system, component, or other model element must satisfy.”4

Requirements specifications can be modeled containing sets of requirements. Each requirement will have attributes to specify the text “shall” statement. Other aspects of a requirement, such as its priority, safety critical level, and so forth, can also be modeled. Requirements can be shared between specification packages. The requirements model includes relationships among requirements and between requirements and other model elements. The containment relationship , (circle with a “+” sign) will be used to decompose a requirement into its constituent requirements. A derived requirement can be related to one or more source requirements using the trace relationship.

A requirement can be assigned to a model element that is intended to realize or satisfy the requirement. The trace and assignment relationship are both UML dependencies. The trace and assignment dependencies can be grouped for various purposes using a dependency group. One use of the dependency group is to define the rationale for a set of traces or a set of assignments. This enables the modeler to identify supporting information that provides the basis for a derived requirement, a design rationale, or a reference to a test case that verifies a particular assignment.

Only the most basic attributes modeled directly. More specialized requirements can be specified using stereotypes . Typical examples may include operational, functional, interface, control, performance, physical, storage, design constraints, and other specialized requirements for reliability, safety, producibility, and so forth. The stereotypes may also restrict the types of model elements that may be assigned to satisfy the requirement or the models that specify the requirement. For example, a Performance Requirement may require a Parametric Relation along with an associated tolerance and/or probability distribution on the properties to specify the requirement, or a functional requirement may require an activity or class operation to specify the requirement. The requirements model can be shown in graphical, tree structure, or tabular format. The graphical format using nodes and paths is shown in Figure 1.

Full size image

In this diagram, The Spec package with a Specification stereotype, groups Top Level requirements, which are modeled as classes. Their attributes are modeled. Functional and Performance Requirements are modeled in the Design Spec and are linked with trace dependencies. Finally, in the System Scope Package, System Classes are linked to requirements via an assign relationship. This is an abstract example showing what is possible. Figure 2 shows a requirements diagram for a vehicle.

Full size image

Figure 2 contains Vehicle Specification, Vehicle Design, and Derived Requirements Packages. The Derived Requirement Provide Fuel Flow is linked to the Functional Requirement of Provide Acceleration, the Vehicle Class is linked to the Vehicle Specification Package, and the Engine Class is linked to the Performance Requirement of Horsepower.

Requirements can also be shown in a tree format. This format is used to show the requirements hierarchy and is a traditional format for this purpose.

Finally, the Requirements Table is used for three principal purposes:

  • Providing a table of requirements with their properties in columns
  • Providing a matrix of trace relationships between requirements
  • Providing a matrix of assignment relationships between requirements and system elements

The requirements model is not meant to replace external requirements tools but is meant to be used in conjunction with them to increase traceability within UML models. It could also be used for modeling the requirements and system for smaller projects.

Parametric Equations Diagrams
Parametric Equations Diagrams are traditionally used to model properties and their relationships. The diagrams specify the allowable range values when faced with complex mathematical and logical expressions as well as constraints. Usually a reference to the language is used to state the expressions and constraints. The parametric model can include differential equations, logical expressions such as {when Y =7 or X <1}, or other constraints such as {Y< 3x +7}, expressed in a specific language, such as MathML or a programming language. Parametric models are generally captured in analysis models to support feedback and control; performance models; and engineering models for reliability, safety, mass properties, and design to cost. Some products, of course, provide these capabilities; however, it's advantageous to include these capabilities in the UML model. An example of the Parametric Diagram and its relationships is shown in Figure 3.

Full size image

In the Class section we have modeled the Weapon and MetalObject classes and their attributes. In the Composite Structure, we model the Cannon instance of the Weapon class, and the shot instance of the MetalObject class. These characteristics are then linked together on the Parametric Diagram. Mass is calculated as volume times density, both of which are attributes of the MetalObject class, and force as mass times acceleration. The relationship between the equations is also shown, demonstrating traceability throughout the model.

Minor changes to UML 2.0
As stated earlier, one of the goals of the SysML Partners is to make modifications to UML diagrams only when strictly necessary. Therefore, the SysML Partners are only proposing minor modifications to Activity, Structured Class, and State Diagrams.

Activity Diagrams
The modifications to UML 2.0 Activity Diagrams include Control as Data, Parameters, Continuous Systems, Probability, and the Enhanced Function Flow Block Diagram (EFFBD) profile. These diagrams are summarized in the following sections.

Control as Data— SysML extends control in Activity Diagrams in three interrelated ways to give the function of data:

  • In UML 2.0 Activities, control can only enable actions to start. In SysML, control can disable actions that are already executing, and behaviors can also declare that they cannot be disabled once started, that is, declare themselves noninterruptible.
  • SysML will allow control tokens to be queued. SysML will allow pins to accept control tokens, calling them control pins. This supports queuing of control and other features of object nodes.
  • SysML extends control to have a type so that it can be processed by actions, rather than control them.

UML 2.0 provides a value action that can insert values into the flow of an activity. SysML defines value actions so that values can be output from activities. Since control is a type, value actions can output control values as well as data values.

Parameters— SysML defines some extensions to parameters and parameter sets:

  • UML 2.0 supports declaration of the effect of actions on inputs and outputs. This is recorded on pins. SysML defines the same effects for parameters.
  • UML 2.0 defines preconditions and post conditions for parameters. In the meantime, SysML also allows them for parameter sets.

Continuous systems— SysML provides extensions that might be loosely grouped under the term “continuous” but are generally applicable to any sort of distributed flow of information and physical items through a system. These extensions are:

  • SysML defines a model of quantity that binds units to values and provides restrictions on quantities.
  • SysML supports restrictions on the rate at which entities flow along edges in an activity or in and out of parameters of a behavior. This restriction includes both discrete and continuous flows, either of material, energy, or information. Discrete and continuous flows are unified under rate of flow, as is traditionally done in mathematical models of continuous change.
  • SysML allows newly arriving values to replace values that are already in the object nodes. It also allows the discarding of values arriving at actions that are already executing or are not already executing, as needed by the application. This feature allows applications to make use of the most recent information by indicating when old values should not be kept in object nodes.
  • SysML distinguishes between behaviors that are intended to run indefinitely until they are disabled, and those that run to completion and stop of their own accord (see Figure 4). The modeler's intention is declared on the behavior.

Full size image

Finally, SysML provides the definition of collections of entities where the identity of the members of the collection are not important or even determined. For example, you can indicate a vat of nails or ball bearings or water in a tank as collections of unidentified entities. You'll also able to restrict the size of the collection.

Figure 4, which was taken from the SysML specification, shows a simplified model of driving and braking in a car that has an antilock brake system.

Turning the key on starts two behaviors, Driving and Braking, which are the responsibility of the Driver and Brake System respectively, as shown by partitions. These behaviors execute until the key is turned off, as indicated by runToDisable keywords and the interruptible region. The Driving behavior outputs a brake pressure continuously to the Braking behavior while both are executing, as indicated by the streaming and rate properties (streaming is a characteristic of UML behavior parameters that supports the input and output of items while a behavior is executing, rather than only when the behavior starts and stops). Brake pressure information also flows to a control operator that outputs a control value to enable or disable the Monitor Traction behavior. No control pins are used on Monitor Traction, so once it is enabled, the continuously arriving enable control values from the control operator have no effect, per UML semantics. When the brake pressure goes to zero, a disable control value is emitted from the control operator.

The first one disables the monitor, and the rest have no effect. Whilethe monitor is enabled, it outputs a modulation frequency for applyingthe brakes as determined by the ABS system.

Probability— SysML also introduces the concept of probability:

  • In a model library there will be a datatype for probability, which is a kind of behavior for calculating probabilities, and a value specification for constant probabilities.
  • Edges can contain expressions evaluating to constant probabilities. The probabilities give the likelihood that a value leaving the decision node or object node will traverse an edge. Output parameter sets may have the same function.
  • SysML extends elements that hold values, such as properties and parameters, with a probability distribution for the values. The distribution can apply to a single instance or execution over time, or to across all instances of a class and or executions of a behavior.

EFFBD profile— the Function Flow Block Diagram (FFBD ) was one of the first to be used by systems engineers and continues to be widely used today. The purpose of the FFBD is to show the functions that a system is to perform and the order in which they're to be enabled (and performed). It doesn't contain the semantics for the flow of data between functions and therefore doesn't represent any data triggering of functions. The Enhanced FFBD displays the control as well as data flow, which allows the engineer to model data dependencies. Thus, the EFFBD represents functions, control flows, and data flows. An EFFBD provides a graphical notation to distinguish between triggering and nontriggering data inputs. As with the FFBD, the trigger, which can be data, is required before a function can begin execution. This means that triggers are data items with control implications. It's also possible to show the status of the queuing of triggering data.5 Based on this description, it's easy to see that many of the changes to Activity Diagrams proposed for SysML have been made to enable engineers to express them as EFFBDs.

There are however, some constraints on Activity Diagrams for applications that would like to adhere to EFFBD notation:

  • All actions require at least one control edge coming into them.
  • All forks have a corresponding join.
  • The EFFBD OR notation is inclusive. It translates to a UML fork.

Structured Class Diagrams
SysML extends UML classes, which describe the parts of an object, and links between the parts. Each instance of the Structured Class has the same pattern of interconnected parts. This means that complex architectures can be defined and reused throughout the model. The structure of these Classes may be applied recursively to define hierarchical composition of arbitrary depth. Of course, structure is not exclusively through recursive decomposition. Component-based architecture based on a network of collaborating components is equally valid. Structured Classes can represent any level of the system hierarchy, including the top-level system, a subsystem, or logical or physical component of a system or environment.

Parts are roles in a Structured Class that are filled by particular objects when the class is instantiated. Similarly, connectors between the parts/roles are filled by links between the particular objects when the Structured Class is instantiated. Ports are a special kind of part that gives access to internal structure from the outside of a composite object. In SysML, unlike UML, Ports can also be complex hierarchical structures. Figure 5 shows a modem cable with a complex port structure. It contains a male and female D9. The male D9 contains nine pins, while the female D9 contains nine holes. This sort of complex structure would not be possible in UML 2.0.

Full size image

Composite class structures can be the basis for defining interactions between parts. Part connectors can support many forms of interaction, from static, such as a force balance across a physical interface, to dynamic, such as continuous flow of current through a terminal or a discrete series of calls to software services. This will allow systems engineers to more correctly describe systems with UML that are not purely software. Figure 6 shows a compressor with parts that are a tank, valves, and a pump. Flows shown on the connectors are IO (data), voltage, and fluid, demonstrating the versatility of these extensions.

Full size image

State Diagrams
There are only diagrammatic differences for SysML state machines: the modeling of multiple state machines on a single diagram to demonstrate component interactions as they transition between states. This is shown in Figure 7, which was taken from the SysML specification.

Full size image

This diagram models the states for a telephone and the line to which it's attached. Lifting the telephone receiver affects the line by causing it to transition from Inactive to Active. Hanging up the telephone, will cause the line to transition to Inactive. Modeling both state machines on the same diagram makes it easier to view this effect. Whilst this notation is useful for the simple example shown here, it will quickly become unreadable for any systems of great complexity.

The first UML 2.0 diagram to be excluded from SysML is the Communication Diagram, which used to be known as the Collaboration Diagram. The reason for this is likely because much of the capability of this diagram will be covered by the SysML version of the Structured Class Diagram. The Deployment Diagram will also be excluded as it leans too heavily toward software. SysML is considering showing deployment on the Structure Class Diagram.

Model interchange
The SysML specification is architecturally aligned with the evolving ISO AP233 standard. AP233 is a data exchange protocol for systems engineering data based on ISO 10303. STEP (ISO 10303) is a standard to describe, represent, and exchange industrial data in a computer interpretable format. For different application domains for data exchange a neutral (in other words, tool independent) data model has to be defined. This is called AP (application protocol). Currently around 40 different APs are defined. The intent of AP233 is to support the whole system development life cycle ranging from requirements definition to system verification and validation. Different application areas include engineering analysis, algorithm design, planning tools, testing tools, software design, Mechanical Computer Aided Design (CAD), and Electrical Computer Aided Engineering (CAE). This goal is consistent with that of systems engineering in general, which is to tie together the different domain engineering disciplines into one consistent view of the system.

The AP233 SysML alignment activity is performed as part of the SysML Partners definition of SysML to ensure that:

  • SysML models can be exchanged using the AP233 data exchange protocol
  • Data available in AP233—being generated by another tool—can be visualized in a SysML tool

Another option to exchange SysML models is XMI (XML Metadata Interchange). Because SysML is defined as an extension of the UML metamodel, SysML models can also be exchanged using an XMI schema. But with respect to the data exchange based on AP233, using XMI has the following disadvantages:

  • Current implementation of XMI only exchanges whole models; it is not possible to exchange parts of a model. Some tools do implement such features either based on XMI or on a proprietary format but this is not standardized and therefore not usable for data exchange across tool borders.
  • As XMI is just the serialization of a complete model to be read by another UML tool it doesn't contain configuration control data.
  • The AP233 metamodel for the data being exchanged makes reuse of the STEP PDM metamodels possible and eases the integration with PDM systems to archive the model data.

Work in progress
The extensions that are being made to UML 2.0 will definitely help systems engineers to more adequately model their systems. Artisan has argued for many of these for several years. Additionally, the work done by the SysML Partners has helped to highlight some deficiencies in UML 2.0, which are being addressed by the finalization task force. Readers should remember that this article is a report on a work in progress. Changes will continue to be made until the proposal is ratified. The SySML Submission Team presented it's specification for SySML to the OMG on November 14 for review. Further information on the SysML specification can be obtained at

Matthew Hause is chief consultant, Artisan Software Tools. Matthew has developed real-time systems for the past 25 years, working in the power systems industry, process control, communications, SCADA, distributed control, and many other areas of real-time systems. His role at Artisan includes mentoring, sales presentations and training courses. He can be reached at .

Francis Thom is principal consultant for Artisan Software Tools. He has been developing real-time systems for the past 15 years, starting with developing C3I Systems for surface and sub-surface vessels. He has also worked on multirole military and commercial avionics systems, on safety-critical railway signaling systems, and on-board computers for space rockets. His role at ARTiSAN includes mentoring, sales presentations and training courses. He can be reached at .

Alan Moore is vice president of product strategy at Artisan Software Tools. He is responsible for the development and evolution of Real-time Perspective, Artisan's process for real-time systems development. He is an active member of the Object Management Group and is chair of the revision task force for the UML Profile for Schedulability and Performance and Time, and co-chair of the OMG's Real-time Analysis and Design Working Group. He is Artisan's technical lead in the SysML consortium. He can be reached at .


  1. Object Management Group (OMG), 1997. Unified Modeling Language: Semantics 1.1 Final Adopted Specification ptc/97-08-04 . [online] Available from [Accessed Septem

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.