Engineering and IT Insight: UML (Unified Modeling Language) is the language of software engineering, and State Models in UML are used to define internal logic. When state diagrams, use case diagrams, and sequence diagrams are combined with UML class diagrams they define a system, can be easily understood by non-programmers, and can be rapidly converted into executable code.

UML (Unified Modeling Language) is the language of software engineering, and the ever increasing software content of automation means that it is a language that automation engineers must understand. There are three basic parts to any software; structure (data and or messages), system behavior and interactions, and internal logic. UML defines a standard language for each of these elements. Last month’s column described two parts of UML that deal with structural information; class models and object models. The structural models can be used to generate databases, function block libraries, messages, IEC 61131-3 structured text STRUCT definitions, C# classes or C++ classes. System behavior is defined through Use Case Diagrams and Sequence Diagrams. State Models in UML are used to define internal logic.

UML state models are an extended version of finite state models, which are diagrams containing states and events. State models define the internal behavior of objects that can be implemented in procedures, function blocks, or any other type of code. UML state models are extended to include nested states, variable values associated with states, and guard conditions. Nested states support complex state models, where one event may cause a transition from multiple states. Nested states are commonly used in specifications to reduce state model complexity and make them easier to understand. Variable values support looping of state/event values, allowing different actions depending on the loop value. Guard conditions define Boolean checks that prevent an event from causing a state change, and are also used to simplify state model designs. Each event in a state model defines the actions that are to occur when the event happens. In control systems, there can also be logic that is repetitively executed while in a state.

The following diagram illustrates a simple nested state model for a device. It starts in the IDLE state and when it receives a START event it will go to the RUNNING state. The device may be paused and when performing pausing logic, or waiting for the physical device to respond, it is in the PAUSING state. When pausing is complete the device enters the PAUSED state. On a RESUME event the device goes back to RUNNING. If a STOP event is received, then it goes to the IDLE state independent of the current state. If the run time in the RUNNING state is exceeded, then the device also goes to the IDLE state.

Use case diagrams (UCDs) define system behavior through the interactions of actors and processes. They essentially define the needed interfaces to processes or objects. UCDs contain one or more use cases and illustrate how external systems interact with each use case. External systems may be a person, organization or other system and are called “actors’ in UML terminology. An actor performs one or more “roles” in an interaction diagram, such as a person performing the role of an Operator or a Supervisor or a PLC performing the role of a safety system. Use cases are represented as ellipses, and, in one of the unfortunate accidents of collaborative standards (such as UML), actors are drawn as stick figures, making UCDs look like badly drawn cartoons. Each use case represents one scenario. A scenario represents either a normal situation with no errors or an abnormal situation where one or more errors can occur. Use cases may be nested so that one use case represents a complete UCD, which contains more detailed smaller use cases.

An association is defined whenever an actor is involved with a use case and is represented as a solid line. Many interactions are two way, with multiple related transactions. If the interaction is only a one way interaction, then it is documented with an arrowhead on the line. Each use case in a UCD is defined through a sequence of actions that provide some basic function of the system that has importance or value to the actor. A typical UCD may involve 3 to 10 use cases and from 1 to 10 actors. UCDs provide an overview of major external interactions, defining either normal or abnormal situations, and provide a structure for Sequence diagrams.

The following diagram illustrates a typical UCD. It shows two actors (an operator and a data historian), two systems (a control system and a safety system), and three use cases. Each use case has an associated sequence of actions (shown in a sequence diagram) that describe the sequence of interactions with the actor.

Use cases in a UCD may be grouped together into systems when the system substructure in know. Use cases may also be related through “Uses” or “Extends” relationships. For example, an Equipment Startup use case may extend a Machine Power-up use case and a Machine Self-Check use case, where the Machine Power-up use case and Machine Self-Check use case are defined in different UCDs.

UCDs should not be used to represent a sequence of steps. Sequence Diagrams should be used to represent the time sequence communication among two or more processes or objects. A sequence diagram is a type of message sequence chart, even though the communication may not be messages but may be procedure calls, object method invocations, web service calls, or any other method of inter-process communication. A sequence diagram is used to describe the expected, or desired, flow of information for one specific use case. For example, one use case may be a no-error use case which describes normal communication, while another use case may describe the sequence of communications when an error occurs.

As in message sequence charts, sequence diagrams are represented as a set of vertical lines, one line for each process or actor that participates in the sequence. Each communication event between participants is represented as a horizontal arrow, and the communication event contains the content of the event (such as the parameters used if the event is a procedure call). The communication events are ordered by time, with the first message at the top and time increasing as you move down the vertical lines.

The following example shows a message sequence between an operator, a process, and a data historian. It shows the messages for the normal equipment operation. There are many other options available in Sequence Diagrams, including the ability to show object creation and deletion, loops of message transactions, alternate paths, and guard statements (which define a condition that must be met before the message is sent).

Sequence diagrams are used to define the interfaces to processes or objects. Each communication defines a possible interface, which can be implemented as a function block interface, an IEC 61131-3 structured text function definition, a network message definition, or object method definition. The diagrams are also used to define the process that should occur when a communication is received.

The combination of state models, UCDs and sequence diagrams define the internal logic and behavior of the system, defining how the system will respond to normal and abnormal conditions. When state diagrams, UCDs, and sequence diagrams are combined with UML class diagrams they provide a complete definition of a system which can be easily understood by non-programmers, and can also be rapidly converted into executable code. UML is the software engineering language that all control engineers should understand and start to use in their specification and designs.

– Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Edited by Mark T. Hoske, Control Engineering, www.controleng.com.

See diagrams and additional explanation above. Also read: Part 1: Understanding UML is an important part of your toolkit. Link follows.