The development of complex systems is often a problematic endeavor, mainly due to the scope and complexity of solution, spanning multiple disciplines. One of the disciplines affected by this complexity is the development of software-intensive systems and, especially, that of real-time embedded systems.
Over the years, various attempts have been made to make complex real-time embedded systems developers to be more productive. In addition to textual programming languages becoming more abstract (C++, Ada, Erlang), graphical languages were also proposed as a solution to address this growing complexity. Examples of these approaches to model complex systems are, e.g., the Real-Time Object-Oriented Modeling (ROOM) approach from Bran Selic, Garth Gullekson, and Paul T. Ward [1](which became known as UML-RT in the early 2000’s), the Shlaer-Mellor approach, which became Executable UML (e/x/xt-UML) [2], Bruce Douglas' Real-Time UML (RTUML) [3], the Arthaud and Leblanc methodology based on OMT, SDL and MSC (UML-SDL) [4, 5], the McLaughlin and Moore approach [6], and the Gerard methodology (Accord) [7].
The advent of the Unified Modeling Language (UML) made many of the concepts found in aforementioned methodologies (e.g., ROOMcharts/state machines, capsule/structured classifiers, ports, and connectors) more visible and accessible to the modeling community. The various approaches also either made their way into or were based on the UML and the profile for Scheduling, Performance and Time (SPT) [8], and MARTE [9].
Contributions from these sources and others helped augment the capability of the UML, but also its complexity, somewhat compounding that of system development. However, the introduction of UML-based modeling languages such as SysML and the addition of formalized semantics provided by fUML, also helped extend modeling across systems engineering disciplines, as will ongoing work on new formalism such as the Precise Semantics of Composite Structure (PSCS). This has allowed for new tool capabilities and better communication across typical system and software development silos. And more importantly, this has promoted the idea of convergence of the early methodologies into a formalized, UML-based approach for distributed, real-time and embedded domain.
Parallel to this, the International Council on Systems Engineering (INCOSE) promoted the move from a document-centric to a model-centric systems engineering approach as part of its Systems Engineering Vision 2020 document [10]. This approach has also been reiterated in INCOSE's 2025 vision [11] with the "Advancing the TOOLS and METHODS to address complexity" imperative.
[1] Bran Selic, Garth Gullekson, Paul T. Ward: "Real-Time Object-Oriented Modeling", New York, John Wiley & Sons Inc, 1994, ISBN 978-0-471-59917-3.
And also:
Bran Selic, Jim Rumbaugh: "Using UML for Modeling Complex Real-Time Systems", 1998. [Available from Tallinn University of Technology or IBM developerWorks].
[2] Stephen J. Mellor, Marc J. Balcer: "Executable UML: A Foundation for Model-Driven Architecture", Boston, Addison-Wesley Professional, 2002, ISBN 978-0-201-74804-8.
[3] Bruce Powel Douglass: "Real-Time UML: Developing Efficient Objects for Embedded Systems", Boston, Addison-Wesley, 1997, ISBN 978-0-201-32579-9.
A more recent version exists as:
Bruce Powel Douglass: "Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition), Boston, Addison-Wesley Professional, 2004, ISBN 978-0-321-16076-8.
[4] R. Arthaud, "OMT-RT: Extensions of OMT for better describing dynamic behavior", Sixteenth International Conference on Technology of Object Oriented Languages and Systems (TOOLS EUROPE'95), Prentice Hall, pp. 173-182, Versailles, France, 1995.
[5] P. Leblanc, "Object-Oriented and Real-Time Techniques: Combined Use of OMT, SDL and MSC", 1996.
[6] M. J. McLaughlin, A. Moore, "Real-Time Extensions to UML", in Dr. Dobb's, 1998.
[7] S. Gérard, "Executable UML modeling for embedded automotive systems", PhD thesis Report, 2000.
[8] RT-UML appeared at the OMG as the "UML Profile for Schedulability, Performance and Time".
[9] OMG, "UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems", (Available from OMG).
[10] "SYSTEMS ENGINEERING VISION 2020. INCOSE-TP-2004-004-02." INCOSE, 2007.
[11] "A World in Motion - Systems Engineering Vision 2025" INCOSE, 2014.
This project meets both the UML goal of method neutrality, in our case through convergence of a solution, and INCOSE's Model-Based Systems Engineering (MBSE) vision by creating an open-source, advanced, configurable "Model is the Code" tool that can easily be used in a complete systems engineering approach for systems having concerns in the distributed, real-time, and embedded domain, often referred to as "cyber-physical systems".
Papyrus-RT provides an industrial-grade, complete and full-fledged environment for the development of software and systems that has to present at least one of the following features: reactive, distributed, real-time, or embedded. It covers several concerns related to designing such systems, i.e., modeling, code generation, runtime support, advanced debugging facilities, and schedulability and performance analysis.
Papyrus-RT provides an open framework to facilitate the implementation and adoption of new and existing approaches and methods to build real-time solutions.
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.
Future work will incorporate and support other approaches, such as those discussed in “Background”. It is expected that although the content will largely be similar, differences will be expected depending on the approach and method used, affecting the various part of this section. Papyrus-RT provides an architecture to support these differences.
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.
There are no known legal issues with this project.
Papyrus-RT does not rely on or use projects or libraries outside of Eclipse.
Either CEA or Zeligsoft employees wrote all the code in the initial contribution.
The Eclipse Papyrus project provides a complete UML tool platform that is supremely extensible, making it an ideal base on which to build and further customize a tool for distributed, real-time and embedded systems. This will allow the tool to easily adapt to other approaches and to support different use cases in the development of complex cyber-physical systems. Also, Papyrus uses the UML2 project that is widely recognized to be the best Java library for the UML metamodel and the basis for many commercial offerings. The strong Eclipse community also encourages the establishment and growth of a Papyrus-RT community, itself contributing to Eclipse's growth. By going with Eclipse, we profit from the existing Papyrus community and infrastructure, as well as from Eclipse's own ecosystem and the guarantees that are offered by Eclipse processes with regards to code provenance, IP due diligence, etc. This is beneficial for systems development companies that are typically risk-adverse. By also being under the PolarSys umbrella, we benefit from other advantages such as the long-term support that is essential for many systems developers.
The initial release of Papyrus-RT will concentrate on providing the basic UML-RT capabilities, including user interface, code generation, runtime service library, and local model execution. Future work will enhance these capabilities to provide advanced features (e.g., remote execution, testing, and analysis) and integrations across the systems development lifecycle (e.g., reporting and traceability) as well as incorporating and supporting other approaches specific to the design of distributed, real-time and embedded systems [2, 3, 4, 5, 6, 7, 8] including also all MARTE-based approaches.
We will also continue to consolidate our community of users and partners from both industry and academia.
Work on this project has already started both within (for the user interface work) and outside of Eclipse (for code generation, RTS, and samples), with builds running for all executable components.
Once this project is approved, we will upload the initial contribution in the following days, and get a build ready within two weeks.
An initial incubation release of Papyrus-RT, targeting a UML-RT tool implementation, is planned to align with the Mars release.
- Bran Selić, Malina Software Corp.
- Dominique Toupin, Ericsson
- Francis Bordeleau, Ericsson
- Dr. Henrik Rentz-Reichert, Protos
- Juergen Dingel, Queen's University
- Sébastien Gérard, CEA
- Thomas Schütz, Protos
The initial contribution consists of four parts:
-
User interface elements:
The UML-RT Profiles and toolset support are Eclipse plugins and already available as part of the Papyrus "UML-RT" extra component, along with all related source files.
CEA has ownership of this code. -
Code generator:
The code generator is an Eclipse plugin.
The code generator code currently resides in a limited-access Zeligsoft git and gerrit repository. Zeligsoft has ownership of this code. -
Runtime Service Library:
The Runtime Service Library is a set of C++ source files that can be built into a C++ library.
The Runtime Service Library code currently resides in a limited-access Zeligsoft git and gerrit repository.
Zeligsoft has ownership of this code. -
Sample models:
Sample models are Papyrus-RT model files, packages as Eclipse project archives.
The Sample models currently resides in a limited-access Zeligsoft git and gerrit repository.
Zeligsoft has ownership of this code.
Papyrus-RT uses the Apache Commons CLI library licensed under "Apache License, Version 2.0" and owned by the Apache Software Foundation.
- Log in to post comments