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 SE².

The team’s task is to demonstrate solutions to challenging problems using MBSE.

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

• 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.

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 SE² 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.

SKA

EUCLID

LSST

E-ELT

TMT

GMT

Mercator

Meetings

The Active Phasing Experiment (APE), a European Union Framework Program 6 project, was chosen as the subject of the SE² 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. 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.

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

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.

SE² 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.

• 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)

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

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

• 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

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 SE² 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.

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)

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

1. http://www.omgwiki.org/MBSE/doku.php
2. http://www.omgsysml.org/#Publications
3. http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group
4. https://vimeopro.com/user28256466/no-magic-world-symposium-2016-presentations
5. German Chapter of INCOSE
6. European Southern Observatory
7. HOOD
8. oose
9. SYSMOD
10. MagicDraw