Telescope Modeling Challenge Team


In the framework of INCOSE’s strategic initiative, the Systems Engineering Vision 2020, one of the main areas of focus is model-based systems engineering. In keeping with this emphasis, the European Southern Observatory (ESO) is collaborating since 2007 with the German Chapter of INCOSE (GfSE) in the form of the “MBSE Challenge” team SE2.

The team’s task is to demonstrate solutions to challenging problems using MBSE. The Active Phasing Experiment (APE), a European Union Framework Program 6 project, was chosen as the subject of the SE2 Challenge Team. Many technical products in the telescope domain show an increasing integration of mechanics with electronics, information processing, and also optics, and can therefore be rightly considered as optomechatronic systems.

The SysML models were created by reverse engineering from existing documentation and from interviews with systems engineers.

The introductory presentation provides information on context, goals, and results of the Challenge team.

Measure of Success

  • Modelers - Recipes and best practices for common modeling problems
  • OMG´s Revision Task Force (RTF) - Examples of challenges and problems of SysML when applied to real projects
  • Tool vendors - Usability of tools and implementation issues of the SysML standard when used in real projects.

Topic Overview / Description

Our system case study is the Active Phasing Experiment technology demonstrator for the future European Extremely Large Telescope, which is a high-tech, interdisciplinary optomechatronical system in operation at the Paranal observatory.

The next generation of telescopes needs to collect significantly more light than current telescopes, therefore requiring larger reflecting surfaces that consist of many individual mirror segments. Due to different disturbances (such as vibrations, wind, and gravity), the segments must be actively controlled to provide a continuous mirror surface with a phasing error of only a few nanometers over the main mirror’s diameter of 42 m. The main challenge is to correctly detect the positioning errors of the segments via specific phasing sensors in order to create a continuous mirror surface.

APE was developed to evaluate those sensors, and was installed on one of the 8 m telescopes that constitutes part of the Very Large Telescope in Chile (VLT) for sky tests. For the installation at the telescope it had to comply with various mechanical, electrical, optical, and software interfaces. APE consists of about two hundred sensors and actuators such as wheels, translation stages, lenses, detectors, mirrors, light sources, an interferometer, and twelve computing nodes for control. Since APE had to be deployed in the test lab and in an already existing telescope, for each context it was necessary to model variants of function, interfaces, and structure. All of these characteristics made APE well suited to evaluate the potential of SysML in tackling similar issues.

 APE installed at VLT UT1 Partially populated APE bench


DateMilestoneStatusPoint of Contact
IW11Cookbook and reference model, issue 1CompletedRobert
IW11Ontologies for modeling recipesCompletedRobert
IW11OCSMP white paperCompletedTim
IW11MBSE modeling pluginCompletedMichele
IW11Model Based DocumentCompletedMichele


2011-02-03 Requirements Modeling - getting textual requirements from models Rudi
2010-12-16 Variant Modeling with SysML Tim
2010-12-02Model Based Document GenerationMichele
April 2009Modeling Recipes and Challenges with SysML IIRobert
Nov 2008Modeling Recipes and Challenges with SysML IRobert

Team Members

NameOrganizationContact Information
Robert Karban (lead)
Tim Weilkiens oose
Rudolf Hauber
Berthil Muth HOOD
Rainer Diekmann Consultant
Michele Zamparelli
Andreas Hein
Christian Zingel IPEK – Institut für

MBSE Challenge Goals

SysML is a graphical language and defines a modeling elements with a notation, a formal syntax, and semantics. The SysML model is not merely a mental abstraction, but a collection of complex data structures that can be edited, augmented, queried, and reported on by means of a suitable tool, which is an indispensable pillar for MBSE. Like any language (formal or informal), it can be used in many different ways, including many wrong ways.

The main goals of the SE2 MBSE Challenge Team are to

  • create modeling guidelines and conventions for all system aspects, hierarchy levels, and views;
  • provide examples in SysML, solving common modeling problems;
  • build a comprehensive model, which serves as the basis for providing different views to different engineering aspects and subsequent activities; and to demonstrate that SysML is an effective means to support systems engineering.


SysML is a language and does not prescribe any methodology. For example, SysML allows to use the «allocate» relationship between nearly any model element. But where is this feature useful in a specific project? How can the relationship be determined from the model, e.g. for traceability? What are the consequences of having an «allocate» relationship between two elements? You do not find answers to these questions in the SysML specification.

SE2 did not define a MBSE methodology. The modeling work is based on different existing methodologies like SYSMOD, OOSEM, or Wymore´s MBSE theory. The Challenge Team has found some best practices and modeling guidelines to complement them but each project needs its own specific set of methods (see the Survey of Methodologies for more information). The results are supposed to be mostly method independent.


You find a complete version of the model and other material like presentations on our website: Telescope and Space Systems Modeling Challenge Teams.

Major problems already addressed

  • Use properly SysML language and its elements to represent a system
    • Representative model
    • Practices and guidelines
  • Scalable model organization
  • Reuse of blocks (catalog)
  • Modeling challenges
    • Identified and provided feed back to OMG´s Revision Task Force (RTF) Working Groups
    • Notation (e.g. Connection of nested blocks)
    • Modeling technicalities (e.g. Grouping of interfaces, Variant modeling)
    • Tool (e.g. Configuration and Quality Control)
  • Methodology (e.g. multi-layer allocation)
  • Feed back to vendor for improvement of tool
  • And many more smaller problems (see Cookbook)

Cookbook for MBSE with SysML

The Cookbook addresses a variety of modeling areas, illustrated with real world examples.

 APE Junction Box Interface APE electrical view
  • Style and Layout
  • Model Organization
  • System Aspects and Views
  • Requirements and Use Case modeling
  • Structure Modeling
  • Behavior Modeling
  • Interface Modeling
  • Guidelines for Modeling Non-Functional Aspects
  • Integration with other Disciplines
  • Variant Modeling
  • Cross-cutting the Model and Traceability
  • Constraint Modeling
  • Ontologies
  • Metrics
  • Model Based Document Generation
  • Boilerplates for Requirements
  • Modeling reusable Parts in a Catalog
  • SE Profile, Customization, and Meta-Modeling

Online Model

The APE SysML Model provides the complete model navigable online in any web-browser.


From the SE2 Readings section you can download most given presentations and published papers related to MBSE and SysML by the SE2 Challenge team members.


In Downloads section you will find the complete model in MagicDraw´s mdzip format as well as the Open-Source MBSE Plugin for the modelling tool, which helps in querying the model, create automatically basic organizational structure, extracts model variants, and supports model based document generation based on DocBook.

Modeling challenges

SysML is a new language. This creates two inherent challenges: Is SysML sufficiently mature for real projects and is it accepted by a wide range of systems engineers? Especially the fact that SysML is based on UML sheds a special light on these challenges. Could a modeling language, which was initially defined for software development, be used to model systems and will systems engineers accept a language with origins in the software discipline? An overall result of our project is, that this question can be answered with yes.

The APE project is a pretty good challenge for SysML. It is complex, interdisciplinary without a special focus on software; it is a real system and no simplified coffee machine as often used as demonstration project. Although we found that SysML is practicable to model complex systems, we have found a list of SysML shortcomings.

The most significant ones are:

  • Variant modeling
  • Connection of nested blocks
  • Grouping of interfaces with nested ports
  • Logical vs. Physical decomposition
  • Functional multi-layer abstraction
  • Reuse of blocks, allocation and instances
  • Structural multi-layer allocation
  • Defining Quality of Service
  • Transition to UML for software
  • Configuration and Quality Control
  • Navigability
  • Modelling Frames of Reference and Coordinate Systems
  • Modelling Work Breakdown Structures

We will continue working on these topics.

Early Adopters of MBSE at SKA

This section contains information how the experiences of the Challenge team are applied to a new project, namely the Square Kilometer Array.


One example is the model of Level 1 Requirements:


Early Adopters of MBSE at ESO

This section contains information how the experiences of the Challenge team are applied to a new project, namely the telescope control system of the E-ELT.


Related Papers


  • Abstract: Large telescopes are characterized by a high level of distribution of control-related tasks and will feature diverse data flow patterns and large ranges of sampling frequencies; there will often be no single, fixed server client relationship between the control tasks. The architecture is also challenged by the task of integrating heterogeneous subsystems which will be delivered by multiple different contractors. Due to the high number of distributed components, the control system needs to effectively detect errors and faults, impede their propagation, and accurately mitigate them in the shortest time possible, enabling the service to be restored. The presented Data-Driven Architecture is based on a decentralized approach with an end-to-end integration of disparate, independently-developed software components. These components employ a high-performance standards based communication middle-ware infrastructure, based on the Data Distribution Service. A set of rules and principles, based on JPL's State Analysis method and architecture, are use to constrain component to component interactions, where the Control System and System Under Control are clearly separated. State Analysis provides a model-based process for capturing system and software requirements and design, greatly reducing the gap between the requirements on software specified by systems engineers and the implementation by software engineers. The method and architecture has been field tested at the Very Large Telescope, where it has been integrated into an operational system.

Three years of MBSE for a large scientific programme: Report from the Trenches of Telescope Modeling

  • The most ambitious projects of the European Southern Observatory’s (ESO) is the construction of the European Extremely Large Telescope (E-ELT) which will be by far the world's largest optical and near-infrared telescope, and. will provide images 15 times sharper than those from the Hubble Space Telescope. Such a project poses continuous challenges to systems engineering due to its complexity in terms of requirements, operational modes, long operational lifetime, interfaces, and number of components. Since 2008 the Telescope Control System (TCS) team has adopted a number of Model Based Systems Engineering (MBSE) practices in order to cope with the various challenges ahead. This paper provides an overview of the different approaches we took during this time - which ones worked, and which did not.
  • Paper will be added after the conference

Wiki Articles

Model Based Document Generation

The document is modeled in the same model as the system, using UML/SysML elements. A subset of the DocBook markup language is mapped to stereotypes, and applied to UML/SysML model elements, e.g. chapter to package, paragraph to comment. The MBSE plug-in which you can download from this site creates a DocBook file from the model. Note, that it is just a proof of concept with limitations. For example, only a limited number of DocBook elements are supported but sufficient to make reasonable use of it.

The plug-in can be downloaded here: MBSE Plugin.

The advantages are manifold

  • consistent integration of system model and system documentation
  • direct linking to model elements (also diagrams) from the document
  • changes of diagram names is automatically reflected in the document
  • using proper definition of the stereotype associations only compatible elements can be selected to compose the document, e.g. a figure references diagrams, a chapter references paragraphs.
  • the documentation is at the same time navigable in the model and printable
  • documents are modeled in a tool independent way. Only a small plug-in is needed to generate DocBook XML.

There are also disadvantages (which we hope will be solved by tool vendors in the future…)

  • which subset of DocBook should be supported?
  • creating cross-references (also internal ones) is possible but a bit cumbersome
  • comments are elements without a name and therefore a bit difficult to find in the model browser
  • MagicDraw's text editor supports only HTML which is not compliant with DocBook and the text has to be transformed (which is done automatically when generating)

Model Execution

This section will contain progress on Model Execution of SysML models.


Reference Links

mbse/telescope.txt · Last modified: 2013/12/09 22:25 by robertkarban
OMG Home Logos and Trademarks Become a Member Become a Sponsor Upcoming TC Meeting TOP