Sargon

SARGON Workshop: On the definition of User Requirements for a Robot Control Operating System

Introduction

This document intends to gather the technical notes taken and serves as a memo or MoM of the SARGON Workshop held in ESA/ESTEC on July 19th 2016. The workshop was organised and prepared by the SARGON consortium and chaired by Maxime Perrotin and Martin Azkarate (ESA/ESTEC). For convenience the proposed agenda for the workshop is shown here below followed by the elaborated notes and discussion.

Agenda

SARGON: Background
09:00 – 09:15 Introduction to the Workshop (ESA)
09:15 – 09:30  The case for an RCOS at ESA (ESA) [RD0]
09:30-   10:00  Introduction to TASTE (ESA) [RD1]
What is SARGON

10:00 – 10:30 SARGON: Introduction and Overview  (GMV) [RD2]
[COFFEE BREAK]
 
The SARGON approach  

11:00 – 11:15 Tasks Modeling – AADL and Life Cycle. Demo (GMV/DFKI) [RD3]
11:15 – 11:30 Data types – ASN1 – Demo Inertial Sensors (GMV/DFKI) [RD3]
11:30 – 11:45 Taste2Rock tool [RD4]
11:45 – 12:00 Visualization in a 3D World – Vizkit3D (GMV/DFKI) [RD5] [Skipped]
12:00 – 12:30 Tools for rigorous design, modeling and scheduling beyond  independent-tasks model   – TASTE2BIP (UGA) [RD6]
[LUNCH BREAK]
 
Future activities & Feedback

14:00 – 14:45 Evolution towards Distributed Computation in Autonomous Robotic Systems (DFKI) [RD7]
14:45-  15:30 SARGON & ESROCOS –Future evolution & contact points with OG1  (GMV) [RD8]
15:30 – 16:30 List of Requirements, Conclusions & Open Discussion (Attendees feedback is welcome) [RD9]

Reference documents

0. SARGON – The case of an RCOS for Space

1. SARGON-TASTE.compressed

2. SARGON-Workshop-Intro

3. SARGON-TaskModelling_AADL_AndCycleDemo

4. SARGON-Workshop-Taste2rock

5. SARGON-Workshop-Vizkit_Integration

6. Taste2BIP_Sargon_Wkshop

7. SARGON – towards DC in Heterogeneous RCOS

8. SARGON_Workshop-ESROCOS_Presentation

9. SARGON_Workshop-Requirements

Memo

The workshop started with little delay after scheduled time and following the proposed agenda a brief welcome and introduction to the workshop was given quickly followed by the first presentation of the day:

  • Introduction to the case of an RCOS at ESA [RD0]

The presentation triggered a discussion related to Safety:

QUESTION: How is the Safety being tackled in SARGON? Can I rely that if I use this RCOS the underlying OS and other building blocks are already qualified?
ANSWER: There is already an RTEMS version that is fully qualified and stable for space (v4.8), still when you build an application for space you will need to qualify your complete software.

The second presentation a quick introduction to TASTE, its features and SW engineering approach:

  • TASTE Presentation [RD1]

The presentation raised questions in several domains, from low-level to higher level of abstraction:

QUESTION: What is the state of RTEMS v4.11 & 4.12?
ANSWER: 4.11 is stable, in use and supported by TASTE. SMP is working and will be pre-qualified.

COMMENT: Audience claims that some properties (e.g., WCET) that are present in TASTE cannot be guaranteed when moving to a complex robotics system because of the fact that in such systems there are many unknowns or uncontrolled properties/behaviours. When you model with SDL, you cannot assume that these states are stable in a robotic system. Remember that robustness is more than correctness. There are no known tools or models that allow you specify the properties and atomic state of a robot system. There is a need to introduce additional formal languages that capture the complexity of the robot interacting with the environment.
ANSWER: We are trying to put in place the tools that at least guide the user to write/develop their code in accordance to some RAMS properties (even if some are dependent on the target hardware and the runtime environment).

QUESTION: TASTE is addressing only SW development, what about the system-level requirements management? Some industries use Capella and Magic Draw for that purpose, is there a link to TASTE?
ANSWER: Not at the moment. We are looking at these tools to find solutions to fill the gap between System and SW Engineering but at the moment the information captured at system level with these tools remain too “informal” to be processed by tools (in order to ensure traceability, verification of SW against System requirements, etc.).

The next presentation was intended to give the audience an introduction to the SARGON project, the proposed approach and developments to be done.

  • SARGON Introduction [RD2]

The only question made after the presentation was concerning the amount of building blocks that seemed to be present in TASTE/SARGON and how transparent these are supposed to be for the user. It was concerning the user friendliness and the amount of “windows” that one needs to have open to use this environment.

TASTE is actually run by a combination of command line tools, graphical editors and programming editors, in principle quite user friendly and automatized in terms of features and tools. The demo later on helped to show this.

The following presentations and demo focused on the advances and developments that had been already done during the SARGON project:

  • Presentation on Task Modelling [RD3]
  • Presentation on Data Types [RD3]

COMMENT: Audience insist on the fact that the work of transforming from one model to another (here from Rock to TASTE) is just ok but still does not resolve the problem. The languages and tools we have at the moment available do not allow adding semantics to the models, there is no defined meaning linked to the data structures. Briefly, ASN.1 is not sufficient to express high-level semantics of the data types.
ANSWER: In OG1 of PERASPERA the intention is to enhance the meta-models to add more semantics to it (ASN.1 and AADL).

QUESTION: What is the relation between the states and outputs of the component? Which states are supposed to produce output and is this modelled somewhere?
ANSWER: The proposed life cycle model specifies this relation (in SDL), this proposed model is still subject to change.

QUESTION: Is the component life cycle complete and sufficient?
ANSWER: We made this life cycle model as default for any component but can be extended and modified (or even deleted) at any time.
COMMENT: Part of the audience believes the life cycle is not sufficient, does not allow reconfiguration. We probably should move towards hierarchical state machines. Additionally, states should be representative of their meaning and their capabilities.

  • Demo of current SARGON developments: IMU sensor and 3D data visualisation. [video]

QUESTION: Where is the information relating the properties of the IMU and the Kalman filter configuration?
ANSWER: So far it is hardcoded. But the idea is to move to an approach with a configuration file (like the .yml in rock) so semantics can be added to their values.

QUESTION: How do you model the deployment and distribution of your implementation?
ANSWER: This can be done at the Deployment view of TASTE.

This was followed by a discussion on the actual added value of TASTE (SARGON). Has TASTE any added value outside of TASTE? Is it applicable to other use cases? Some attendees were critic with the fact that currently SARGON is “just” integrating existing tools or supporting legacy code. It is questioned whether if with this approach people will actually re-use and contributing to TASTE or not. Instead of taking the approach of integrating “XXX” and saying “I support XXX” another proposed way forward could be that different frameworks/environments should share the same models. However, those models don’t exist yet.

The next presentation focused on the transformation tool developed in the scope of SARGON that allows deploying a Rock component from a TASTE .aadl “component”.

  • Presentation on the TASTE2Rock tool [RD4]

COMMENT: Attendee inquiries about the possibility to reconfigure your deployment at runtime. We need a model to define a system, so that a supervisor can start/stop/reconfigure systems. There is little value in legacy! We should move towards the concept of System of Systems.

The following presentation was addressing the TASTE2BIP tool and the ways to increase the expressiveness functions in TASTE with regards to their schedulability.

  • Presentation on TASTE2BIP [RD6]

QUESTION: What kind of properties were you able to prove?
ANSWER: Only checking deadlines.

QUESTION: Why do you say TASTE does not support dependencies?
ANSWER: It should be clarified. They are supported in interface view by asynchronous call but not entirely in concurrency view.

The following presentation given by one of the DFKI colleagues is showing the roadmap that Rock framework is following for the next generation of robotics software development. Is strongly based on MDA and tackles the topic of ontologies to increase the semantics of the models to be developed.

  • Presentation on D-Rock [RD7]

QUESTION: What is the link between ontologies and graph library?
ANSWER: The nodes in the graph are instances of the entity classes in different ontologies and the edges are already known or inferred relations between instances. Hierarchical hypergraph is foundation ontology of the domain specific ontologies that are shown in the presentation [RD7].

Recently, OG1 of PERASPERA was granted and the consortium led by GMV will perform this activity following the developments done in SARGON. The name of the project is ESROCOS.

  • Presentation on ESROCOS [RD8]

QUESTION: I see there are 3 levels of quality, is code necessarily different between them?
ANSWER: Yes, the code for them is different due to the fact that the rules to be followed for the coding are different for each case.

The reason for the 3 different levels of quality is to provide three different types of environments according to their criticality. As explained in the firt part, the generation of safety critical software (the SW that can reach a high level of TRL) is very costly, both in terms of effort and schedule. SARGON identifies three different environments

– the laboratory environment, in which prototypes can be developed quickly and easily,

– the high-fidelity environment, in which more strict rules for the coding and verification activities can be followed, to ensure a higher level of Reliability, Availability, Maintenance and Safety (RAMS), and finally

– the space application environment, for the development of space robots or robots in which a failure might cause the loss of human lives

You can reuse the code from higher level of criticality (f.i.space quality) to lower lever of criticality (f.i. lab quality), that is, code that matches higher level of RAMS capabilities can be reused in  environments that have lower RAMS, but surely not the other way around. In fact, at the laboratory environment we reuse existing libraries that were not developed having these RAMS capabilities in mind, which would be very difficult to migrate to the space application environment.

QUESTION: Will we use two runtime engines, TASTE (PolyORB-HI) and BIP?
ANSWER: We probably need to achieve a mix of both.

QUESTION TO THE AUDIENCE: How do you think we can improve the current design approach (slide with all building blocks)?
ANSWER: We are missing the definition of models at different levels of abstraction. We don’t have models that can improve the existing semantics. The ontologies presented in [RD7] are the way forward into the definition of these. Proposed to go from procedural models (e.g. state machine) towards declarative models (e.g. ontologies).

QUESTION: How is ESROCOS related to ESA?
ANSWER: It’s not an ESA project but there is a link to ESA (it’s on ESA’s interest).

Finally, to conclude the workshop the list of user requirements (available at the workshop website) was presented and discussed one by one with the audience. This triggered different discussions as explained below.

  • Review of list of requirements [RD9]

QUESTION: Shouldn’t we define the boundaries of the scenarios that this development is addressed to and the standards to which we conform.
ANSWER: Maybe our framework is not applicable just to “any” robotic application. Maybe we have to say it is valid for only some specific application(s)/areas. We have to specify more the boundaries of the project. However, any comment from the audience regarding requirements that are not valid for a specific environment would be welcome

QUESTION: When I don’t want to use Linux or RTEMS then what will I do?
ANSWER: If you provide some POSIX-API then you can integrate it into PolyORB-HI. It already has been solved. PolyORB-HI has an OS abstraction layer that facilitate OS porting. Note to SARGON consortium: Add a requirement to specify a HW abstraction layer in order to include any other OS as TASTE targets.

COMMENT: Maybe we should review the compliance table of the modelling requirements. Maybe some of the requirements marked as already compliant (‘C’) can be reconsidered/improved. We should also ask for missing and/or non-compliant requirements.
ANSWER: The robotics community has to provide specific requirements not generic ones. Then they can be added to TASTE.

QUESTION: What is the vision of TASTE. Do you want to include models or do you just want to support different languages?
ANSWER: This is exactly the question SARGON should tackle/answer. It should integrate different languages and not be yet another editor.

COMMENT: Suggestion that TASTE can be seen as the lower-level part of the higher-level models/frameworks in robotics.

COMMENT: Another possibility is to add to AADL the things (e.g. semantic models) missing in the robotic domain.

Conclusions

Overall:

  1. The aim of the SARGON team is to enhance the current capabilities of TASTE to ease its possible use by the robotics community. In that sense, we are open to any suggestion or comment from the robotics community to improve our outcome and we will be happy to incorporate new ideas into the RCOS.
  2. There are for sure weaknesses in the current capabilities that will not be tackled in the frame of SARGON (for instance, the meta-model of TASTE can be extended). Most of these new features will be done in the frame of ESROCOS; an European Project that will start during the autumn, that has a much wider scope.
  3. However, as in any RCOS, many different stakeholders are involved, each one with its own views, its own background and beliefs, and its vision on how new techniques and technologies (MDA, correct-by-design methods, IMA, etc..) can be applied successfully to provide a reliable RCOS. Knowing that we cannot fully satisfy all these different views, we are in the path for delivering a distributed RCOS with unique and relevant features for the development of safety critical robots, an RCOS based on MDA techniques and that allows the coexistence of different environments, each aimed to a different levels of criticality.
  4. We are also aware that the robotics community relies on existing software assets based on other RCOS (ROS, Rock, GeNOM, among others), and that the communication with other RCOS is crucial to increase the usability by the community (by communication we mean, methods to be able to import existing developments into SARGON and to export SARGON designs to other OSs). We are working on that aspect as well, and we plan to continue working in that area, to keep SARGON open to newcomers.
  5. Even if SARGON is meant to be used in different areas of robotics applications it is true that ESA’s focus is on mobile platforms for planetary exploration (slow dynamics). Therefore, the applicability of the first outcome of TASTE after SARGON (but not necessarily ESROCOS) should be reconsidered and boundaries for scenarios specified.
  6. While SARGON is making TASTE more robotics friendly, the project is not intended to tackle the question of how to build a full control architecture for autonomous robots for space exploration. Strictly speaking within SARGON “only” a few components will be developed (using the *new* TASTE) at the lower part of the functional layer of the robot control architecture. How to build up from there to the rest of the architecture (executive, deliberative, etc.) is not in the scope of SARGON. In the workshop however several comments were discussed on the topic of building control architectures and approaches to this, mainly: 1) the redefinition and specification of models at different levels of abstraction that allow to increase the semantics of the models used in the control system (keywords: ontologies, system of systems, etc.), and 2) the use of hierarchical state machines with decompositions from higher level activity plans to lower level robot task (keywords: ExoMars).

Final note to the reader:

Any comments, ideas, (constructive) criticism, contributions, references to existing work, etc. are more than welcome. And help us spread the word.