Editor's note: The figures in this article, Part 3 of a three-part series, are numbered in continuation with the figures presented in Parts 1 and 2.
This multipart article introduces SysML, a standard modeling language for systems engineering. SysML gives systems engineers and architects a much-needed way to collaborate using a common language. By enabling an electronic representation of product design, SysML improves communication among development teams, helps manage system complexity, and can serve as the basis for analytics to drive faster and more effective decision-making across all phases of the systems development lifecycle.
In Part 1 of this three-part article, I explained the basic purpose and value of SysML, related it to Unified Modeling Language (UML), and described its Requirements Diagram, Use-Case Diagram, and test-case representations. In Part 2, I covered SysML's structural diagrams and requirements allocation mechanism.
Here, in Part 3, I will explain how SysML can be used to model the operating behavior of a product. As I have throughout the article, I make reference to a real-life example of an embedded system, a Rain Sensing Wiper (RSW) for an automotive application.
In this section, I explore how SysML is used to model the behavior of the product. The expression of the behavior of a system equates to realizing its use cases under a specified set of non-functional constraints. SysML offers three types of behavioral constructs: Interactions, State Machine, and Activities. Several behavioral models from UML are not reused in SysML, either for the sake of simplicity or because of some maturity concerns.
The first behavior model to be reviewed is the SysML Interaction Diagram. This diagram allows the designer to model a sequence of service calls between components. SysML leverages the UML 2.0 interaction model, but restricts its use to the Interaction Diagram only. Other forms of Interaction Diagrams (e.g., Communication Diagrams) are not used in SysML.
Figure 12 represents the initialization sequence of the RSW using an Interaction Diagram. The initialization sequence consists of a synchronization protocol between the components. This diagram is well-adapted to represent this type of behavior. Initially, the car electrical system starts the RSW, which in turn queries the sensor and the wiper interface for an acknowledgement. After that, the software is loaded in the memory of the engine control unit (ECU) and its execution begins. Once the software starts up, it reads the parameters stored in the calibration file.
Figure 12: Interaction Diagram for the initialization of the Rain Sensing Wiper system
Click to enlarge
The use case named Initialization (see Figure 4 in Part 1) is realized by the interaction model in Figure 11 (see Part 2). One mechanism for expressing the relationship between the interaction model and the realized use case is to use the SysML Allocation mechanism, as introduced below.
In Part 2 of this article, I showed how requirements are allocated to system elements aiming at satisfying or verifying them. SysML generalizes this concept by allowing any elements to be related to any other elements to express a particular relationship. I examine this mechanism in more detail below. As with requirements relationships, elements in SysML have derived properties to display the status of their allocations to other elements. For example, the bottom of Figure 12 shows that the behavior model is allocated to the use case Initialization. In addition, the model is allocated to the system state named Initializing (see below).
The SysML State Machine Diagram
The SysML State Machine Diagram is used to represent the different states of the product. This behavioral model is also reused from UML and not extended in SysML. Protocol State Machines from UML 2.0 are excluded from SysML for simplicity.
In Figure 13, the different states of the RSW are represented, as well as their transitions. Three states are identified: Deactivated, Initializing, and Activated. In Deactivated mode (manual deactivation by the user, for instance), the system waits for an activation command. When this signal is received, it transitions to the Initializing state. In that state, the interaction sequence in Figure 12 is executed. When completed successfully, the system transitions to the Activated state. Note that, when entering and exiting states, flags are set and unset, respectively. These flags are used, for example, to display the current status of the system on the driver dashboard.
Figure 13: State Machine Diagram for the Rain Sensing Wiper system
Click to enlarge
Allocation can also be shown in the State Machine Diagram as well. In Figure 12, the states Initializing and Activated both exhibit requirement and allocation compartments.
The SysML Activity Diagram leverages and extends the activity model from UML to support continuous systems. The SysML Activity Diagram offers many innovations, which I present briefly here.1
The modeling of activities in SysML consists of describing behavior as a flow graph. An activity is defined as a set of actions represented as graph nodes (where these actions are the usage of other activities) linked by edges carrying control flow and data flow between actions. Object nodes represent the type of data that can traverse the flow graph and are used as containers for the data as it traverses the graph. For example, object nodes are used to store the input parameters of action, called pins. Finally, control nodes are used to route control and data flows through the activity (to create forks, duplicate flows, etc.). An example of an activity model is shown in Figure 15 below.
Since UML 2.0, activities are classifiers and can be represented in a Class diagram. SysML clarifies the semantics of association between activities. As a result, activities can be related to each other to represent, for example, functional decomposition in a similar way to how Blocks represent structural decomposition in a Block Definition Diagram (BDD).
Figure 14 represents a decomposition of the main functions of the system. In this context, the upper limit at the part end (the end of the composition relationship where the part is connected to the whole) represents the maximum number of instances that can execute concurrently. In Figure 14, the lower and upper limits for each activity owned by Rain Sensing Wiper Main (i.e., Actuate, Process, and Sense) are enclosed in an illustrative box. The example setting allows only one instance of each activity to be run concurrently in the system.
Activities can also be associated to classifiers when the latter are used as a type of object node. In that case, the upper limit at the classifier end represents the maximum number of instances that can reside in an object node at any given time. Figure 13 above defines the upper limit for the number of instances that can be owned by the Process activity as ten.
Figure 13 also illustrates that the activities Sense and Process share a common type of object node named SensorMeasurement. Also, all activities use the type InterfaceCommand. Note that both these Blocks are specializations of a data type named Bitstream. The bitstream modeled by the Block InterfaceCommand is used to implement the services communications between the ECU and the wiper interface, which in turn is defined by the various service ports between the parts.
Figure 14: Activities and object node types for the sensing activity of the RSW
Click to enlarge
The requirements that the Actuate and Sense functions satisfy are also represented in Figure 14. In addition, the main function of the product is allocated to the Rain Sensing Wiper Block using an Allocate relationship. In this case, the designer expresses that the function is owned by this Block. The activity Actuate displays its allocation compartment, which shows that this activity is allocated to the Block WiperInterface.
The rain-sensing function is implemented in the Activity Diagram in Figure 15. The three functions defined in Figure 14 (Actuate, Process, and Sense) are used as actions in the activity.
In Figure 15, the data flows across edges that connect the actions through their pins. The type of data that can flow between actions is defined by the types of their pins. For example, objects of type InterfaceCommand are flowing from the action Process to the action Actuate.
SysML introduces methods to specify the rate at which data can flow across edges and parameters (pins) of activities. Two types of rates are defined: Discrete and Continuous. In the example of Figure 14, the bitstream exchanged between the functions Process and Actuate is limited in rate by the serial link that is used to connect the parts owning these functions (these parts are shown in Figure 8 in Part 2.) In Figure 15, this is modeled by the edge (of type Discrete) named "serial data channel." Edges of type Continuous are used when the time interval between objects tends towards zero. Note that, in order to use rate-controlled edges and pins, activity parameters must be "streaming."2 An activity with streaming parameters can accept values at any time during its operation.
Figure 15: Sensing activity for the Rain Sensing Wiper system
Click to enlarge
The UML 2.0 action model only enables actions to start. SysML introduces the notion of control operators as a special type of action that can enable or disable other actions. A control operator named ManualControl is used in Figure 15 to start and stop the rain sensing function. It deactivates the function upon reception of a "deactivate" signal (triggered by the pressure of a button on the dashboard, for instance). It can restart the function later upon receiving the proper signal. The type of data exchanged between the actions Process and ManualControl is of type ControlValue. SysML defines some types of control values (enable action, disable action) that can be extended by users according to their needs (for example, a suspend action value can be added).
SysML also introduces two new types of object nodes to support continuous concepts such as transient states (e.g., for the modeling of electrical signals). In Figure 15, the action Process exposes a pin of type Overwrite to collect the data sent from the sensor. An object node of type Overwrite will ensure that the latest measurements from the sensor are available to the Process action by erasing older ones in the object node. Note that up to ten values can be stored in the pin according to the bound (0..10) defined in Figure 14. The second new type of object node is NoBuffer. In this case, the pin does not store any value; hence, a value is discarded if it is not directly accepted by outgoing edges (in the case of an output pin) or an action (when used as input).
Lastly, SysML supports assigning probabilities to activity edges (whose source is a decision node or object node) and parameter sets. It allows the modeler to assign a probability for an object value in order for it to traverse an edge. In the case of a parameter set, it assigns a probability for the set to be assigned a value at runtime. This feature can be used, for instance, to simulate loss in a communication channel.
Allocation to requirements or other elements is shown in the Activity Diagram using the compartment notation. In Figure 15, the action called ManualControl satisfies the requirement named "manual disablement." Also, this action is allocated to the Block representing the dashboard button to emphasize that this button causes the system to deactivate.
The SysML Allocation mechanism
The concept of allocation allows the user to bridge between various modeling techniques. By allowing allocation between any pair of elements, the designer can enforce consistency between the various parts of the model.
Figures 12 to 15 show that allocations can be displayed in SysML using special compartments or using the Allocate dependency. The usage of this dependency is only possible when the related elements can be represented on the same diagram.
Allocation is often used to represent mapping of function to structure, as in Figure 14. Mapping between elements can be complex and require the display of several relationships. To allow a scalable display of dependencies between elements, SysML provides a tabular notation for relationships, as explained below.
Figure 16 shows the allocation relationships between the edge named Serial Data Channel in Figure 15 (linking the actions Process and Sense) and other elements in the model. Note that the type of an activity edge is shown as ObjectFlow in Figure 16, which shows that the edge is allocated to four elements in the model.
Figure 16: Display of allocation relationships using tabular notation
Click to enlarge
Requirement dependencies can also be displayed using the tabular notation. Figure 17 shows the result of an allocation query for the requirement System Calibration. Note that the direction of the relationship depends on whether the requirement is the client or the supplier.
Figure 17: Tabular notation used to display requirements relationships
Click to enlarge
This multipart article has provided a whirlwind tour of the different capabilities that SysML offers to system engineers and product designers. SysML is aimed at supporting the conceptual stage of the lifecycle of the product. This stage is preceded by the decomposition of customer needs into product features. SysML allows the representation of these features as requirements in the model. In turn, these requirements can be allocated to the use cases, subsystems, and components (whether functional or physical) identified for the product.
The conceptual stage requires the specification of the various subsystems, along with the need for details depending on their level of integration. SysML provides a set of constructs to support the description of the structure of the product. Blocks are used to model subsystems and components, and ports support the description of their interfaces. Dependencies between structural properties are expressed using constraints and represented using the parametric diagram.
In addition to defining product structure, the conceptual stage should clarify how the product behavior is expressed through the interaction of its components. For example, behavior modeling gives a detailed description of the product use cases. SysML provides three means for explicating product behavior, namely interactions, state machines, and activities. These three mechanisms comprise a unified behavioral concept and can consequently be leveraged as a single, uniform, and complex behavior model for the whole product.
A complex product model is formed by several "sub" models of different types (requirements, blocks, constraints, activities, etc.). SysML provides a mechanism to relate different aspects of the model and to enforce traceability across it.
The conceptual stage precedes the detailed elaboration of the components within the different engineering disciplines. The conceptual design plays therefore a central role in the product lifecycle. Below I emphasize what, in my opinion, are some of the most important roles.
Creating a formal description of the product at an early lifecycle stage improves the understanding of product requirements and how they answer customer needs. The allocation of requirements to the model elements ensures that these needs are covered and provides a rationale for the engineer in charge of fulfilling these requirements. The rationalization of the design is therefore a communication tool spanning organizational levels and lifecycle stages. It improves communication across teams, between teams (think of the different engineering disciplines), and between teams and decision makers. It uses a generic language -- in the sense that it is not specific to any engineering discipline -- that accommodates the incremental detailing of the product representation. This last aspect supports coping with organizational levels. Note that such formal descriptions are well suited to methodologies.
The SysML model provides an electronic representation of the product that is leveraged as a decision tool. Trade-off studies are performed by evaluating functions on the model (cost function, estimation of the integration effort). At an early stage in the lifecycle, often rough estimations are used; hence the model need not necessarily have a great amount of details in order to be used efficiently. When details are added, or artifacts (for example, subsystem simulations) are produced by detailed engineering work, the model is used to coordinate the various simulations and verify requirements. Thus, the SysML model is an evolving decision tool that is useful throughout the whole lifecycle of the product and not only at the conceptual stage.
The product model represents abstractions of artifacts that are progressively elaborated throughout the lifecycle. These artifacts are distributed across the engineering disciplines participating in the design. The model therefore forms a traceability scaffold that provides a means to measure development progress, perform change impact analysis, and manage dependencies between processes and the produced artifacts. In this regard, the SysML model is a management and integration tool for stakeholders.
The role of the system model clearly extends beyond the capabilities that I describe above. My aim has been to discuss some of the most attractive ones as I see it. Modeling for conceptual design is a young discipline and best practices will grow out of it.
1 A more thorough description of the SysML Activity Model is available in: Conrad Bock, SysML and UML 2 Support for Activity Modeling. Wiley InterScience (www.interscience.wiley.com) DOI 10.1002/sys.20046.
2 UML 2.0 notion.
Dr. Laurent Balmelli is a research staff member at the Watson Research Center and a member of several leadership councils in IBM. His areas of expertise are integrated product development solutions, metamodeling, and systems engineering methodologies. He has been the technical lead for several customer engagements in the area of product development and systems engineering. Since 2003, Laurent Balmelli has represented IBM within the SysML submission team and is one of the lead authors of the SysML language specification. He was recently awarded the position of invited professor at the Graduate School of Systems Engineering and Management at Keio University in Tokyo, Japan, where he currently resides. He can be reached at balmelli@us.ibm.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
With Rational Software Modeler you can increase productivity by dragging and dropping your way to a visual interpretation of your UML design.
- Try: Download a free trial version of Rational Software Modeler, a UML 2.0-based visual modeling and design tool for architects, systems analysts, and designers.
- Article: Learn what UML limitations are and how you can overcome them with Rational Software Modeler.
- Tutorial: This tutoral provides a tour of Rational Software Modeler's Visual UML modeling tools.
- Demo: This demo guides you through the creation of a UML modeling with Rational Software Modeler.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
