Eclipse Papyrus for Real Time (Papyrus-RT)

Eclipse Papyrus-RT is an industrial-grade, complete modeling environment for the development of complex, software intensive, real-time, embedded, cyber-physical systems.

The initial version of Papyrus-RT is based on the UML-RT approach, so the discussion below is representative of this decision. This decision was made from feedback from active interested parties, sponsors, and experience of the development team.

User Interface

At its base, a UML-RT model consists of capsules (UML active classes with composite structure, see figure 1) that communicate through ports using protocols (collaboration specifications, see figure 3) specifying the messages (signals) that can be exchanged as well as their payloads. Hierarchical state machines (see figure 5) are used to represent the behavior of capsules, where transitions between states are triggered by messages received on the capsule's ports. Passive classes (see figure 2) can be used as properties or parameters (e.g., as message data or as class utilities) and, instead or in addition to operations, their behavior can also be represented as state machine.

In the figures below, UML profiles provide definitions for UML-RT-specific constructs, spanning both structure and behavior. Papyrus-RT also provides tailored tools and perspectives facilitating and simplifying the creation, and development of UML-RT models, as well as validation specific to UML-RT models to ensure well-formedness of the models.

Figure 1: UML-RT Capsule (and capsule parts) notation as a composite structure

Fig 2: UML-RT Capsule and class notation on class diagrams

Protocols are specifications of valid signals and their directions. Protocols consists of list of incoming (provided) and outgoing (required) signals as well as their definitions (parameters).

A protocol implementation can be a rather complex UML structure (see figure 3). However, this complexity is abstracted through tooling support, such as a special pane in the properties view (see figure 4).

Fig 3: UML-RT protocol description (class diagram)

Fig 4: UML-RT Protocol Properties Editor

As stated previously, capsule behavior is described using a hierarchical state machine, as shown in figure 5, below. Programmatic behavior will be provided as opaque actions, initially containing C++ action code, with the goal of supporting other languages, including the UML action language (ALF), in the future, placed in state entry and exit code as well as in transitions. It will also be possible to use C++ opaque actions do define transition guards (and choice points exit selection).

Fig 5: UML-RT Capsule State Machine

Code Generation

A code generator will translate the UML-RT model into C++ code. This code generator will translate all structural elements (e.g., capsules, protocols, and classes) into C++ code that is based on and makes use of elements defined based on their stereotypes applied and on the UML-RT by the runtime. The code generator will also translate the behavior provided by each capsule's (or passive class') state machine into an intermediate model that will then be translated to optimized code. Based on user-provided thread allocation information, the code generator will also allocate capsules, or groups of capsules, to threads.

A make file is provided to compile the code and link it with the UML-RT runtime library, and any other external libraries used by the application.

The code generator will write the generated code files into an Eclipse C/C++ Development Toolkit (CDT) project to take advantage of capabilities provided by CDT, such as code formatting and debugging capabilities (see figure 6).

The code generator will implement an incremental generation feature, so that model elements that have not changed or that are not directly affected by a change will not be re-generated by a build, resulting in a fast change-compile-test cycle.

The code generator will be designed to be both extensible and replaceable, so that its capabilities can be enhanced. A fork of the transformation implementation will not be required to develop these extensions. Toolsmith documentation will describe the variation points that are available and provide information as to how they can be exploited.

Code generator releases will provide compatibility information with runtime service library versions.

Fig 6: UML-RT CDT project with generated code

Runtime System

The runtime system ("RTS") provides all the glue that actually allows the model to execute. It is, in effect, a UML-RT virtual machine. The RTS contains a library of services (runtime service library or "RSL") provided to the user to facilitate modeling.

The RTS provides representations of all the basic UML-RT constructs (e.g., capsules, capsule parts, ports, and messages), abstractions of OS-level elements (e.g., threads and semaphores), as well as services for the UML-RT designers (e.g., messaging and logging).

The RTS provides the framework to create the structure of the system as well as the messaging transport mechanism to manage and deliver messages between capsules. It also provides other services that control the dynamic allocation of capsules, timing services, and log services.

The RTS is designed to be extensible, modifiable, and portable, in particular with regards to the target platform. As such, it will be provided with an OS abstraction layer and a mechanism to specify the target the OS and for toolsmiths to be able to create new target OS. A reference Linux target will be supplied by default with Papyrus-RT.

RTS releases will provide compatibility information with code generator versions.

A UML-RT model library is provided for the RSL, containing elements and service protocols (interfaces) definitions that are useful for the UML-RT modeler (see figure 7).

Fig 7: UML-RT RSL Model Library

Observability and debugging

In a UML-RT environment, where the model can be considered as "being the code", a modeler/developer would expect to be able to see the execution of the code in the same environment as it was developed – just like a C++ developer is not expecting to debug in assembly. To accomplish this, the execution of the generated code will be linked to animation of the UML diagrams that were used in its creation. This is called observability, where the current state of the models and the transition taken will be highlighted on the model as they occur. One possible way to accomplish this could be through integration with Trace Compass, which already provides tracing and monitoring capabilities. In the same way, setting a breakpoint in the model will result in a breakpoint being created in the CDT (for a running C++ model), enabling debugging simultaneously at the model and C++ code levels.

General

Papyrus-RT will provide user documentation describing how to model UML-RT systems and how to generate code and execute from the model and toolsmith documentation describing how the modeling user interface, code generator and runtime services libraries can be augmented or modified

Papyrus-RT will also provide a library of sample models demonstrating aspects of tool usage.