WP6-12: Difference between revisions
Line 41: | Line 41: | ||
The following figure shows an excerpt of an AADL-like representation of an autopilot. | The following figure shows an excerpt of an AADL-like representation of an autopilot. | ||
[[File:wp6-12-02.svg | [[File:wp6-12-02.svg|upright=1.0|center|Excerpt of an AADL-like representation of an autopilot]] | ||
The figure represents two parts of the viewpoint: on the left-hand side, we can see all the threads of a ChibiOS based Paparazzi autopilot: the ones marked (1) are four threads in charge of UART, (2) is a shell thread, (3) is a log thread, and (4) is the main autopilot thread. On the right-hand side, (5) is an excerpt of the functions present in the main autopilot thread. These are functions called to check if the UAV lost communication with the ground station or is too high compared to the allowed altitude, and in both cases, will change the actual mode of the autopilot. This representation is giving a global view of Paparazzi implementation on the Ulysse rotorcraft platform, which is requiring the compilation of 161 C and C++ files. At the very bottom of the left-hand side, we can see green bent up and down arrows for every access (read or write) to a software bus (global variables or middleware). Several properties are accessible from the environment for each represented element, but in this mode we directly displayed the LOC (Lines of Code) field to quickly indicate to the developer which functions may be computationally intensive, and require some WCET computation. | The figure represents two parts of the viewpoint: on the left-hand side, we can see all the threads of a ChibiOS based Paparazzi autopilot: the ones marked (1) are four threads in charge of UART, (2) is a shell thread, (3) is a log thread, and (4) is the main autopilot thread. On the right-hand side, (5) is an excerpt of the functions present in the main autopilot thread. These are functions called to check if the UAV lost communication with the ground station or is too high compared to the allowed altitude, and in both cases, will change the actual mode of the autopilot. This representation is giving a global view of Paparazzi implementation on the Ulysse rotorcraft platform, which is requiring the compilation of 161 C and C++ files. At the very bottom of the left-hand side, we can see green bent up and down arrows for every access (read or write) to a software bus (global variables or middleware). Several properties are accessible from the environment for each represented element, but in this mode we directly displayed the LOC (Lines of Code) field to quickly indicate to the developer which functions may be computationally intensive, and require some WCET computation. |
Revision as of 14:06, 10 March 2023
Introduction
ID | WP6-12 |
Contributor | ENSMA |
Levels | Tool |
Require | Capella with AADL-like point of view plugin |
Provide | Retro-engineering of Paparazzi C/C++ code into a Capella point of view, offset adjustment to avoid interferences in telemetry messages or in the kernel |
Input | C/C++ code and Makefile of Paparazzi UAV |
Output | Model for Capella AADL-like point of view, offsets computed by GCD+ offset choosing method |
C4D tooling | System-Level modelling and analysis |
TRL | 3 |
Contact | grolleau at ensma.fr |
Retro engineering from autopilot source code to model
Our toolchain allows the retro-engineering of an autopilot programmed in C/C++, to obtain a AADL-like model, an extension of AADL semantics following COMP4DRONES implementation. The AADL-like model is expressed in a Capella Point of View, allowing the end-user to obtain a graphical representation of threads, functions seen as a dataflow graph, software buses and shared global variable access. The flow is represented in the following figure.
Our framework is based on ANTLR and it is composed of a parsing engine, which is the program that is responsible for the traversal and the transformation of the parse tree. The processing consists of three layers. From top to bottom, the program that performs the tree traversal and its text-to-text transformation layer. This program is built on top of the two other layers, which are provided by ANTLR, namely the built parse tree as well as the generated bricks (lexer, parser, tokens, and the listeners).
Building the parse tree consists in parsing the GIMPLE code (e.g., Paparazzi GIMPLE files) that is conforming to the GIMPLE grammar and requires the three given components of the first layer, namely the Parser, the Lexer, and the Tokens. Once the parse tree is built, it is then transformed into XML code. This process requires the generated listeners of the first layer.
This toolchain has been tested on instances of Paparazzi UAV autopilots, and still requires some rare (compared to the hundreds of source code files) manual addition.
AADL-like point of view in Capella
We developed this point of view in order to visualize tasks and their interactions with an AADL graphical syntax. Note that there are additional semantics related to COMP4DRONES D3.3 definitions, in order to be able to represent the core elements of an autopiot.
The following figure shows an excerpt of an AADL-like representation of an autopilot.
The figure represents two parts of the viewpoint: on the left-hand side, we can see all the threads of a ChibiOS based Paparazzi autopilot: the ones marked (1) are four threads in charge of UART, (2) is a shell thread, (3) is a log thread, and (4) is the main autopilot thread. On the right-hand side, (5) is an excerpt of the functions present in the main autopilot thread. These are functions called to check if the UAV lost communication with the ground station or is too high compared to the allowed altitude, and in both cases, will change the actual mode of the autopilot. This representation is giving a global view of Paparazzi implementation on the Ulysse rotorcraft platform, which is requiring the compilation of 161 C and C++ files. At the very bottom of the left-hand side, we can see green bent up and down arrows for every access (read or write) to a software bus (global variables or middleware). Several properties are accessible from the environment for each represented element, but in this mode we directly displayed the LOC (Lines of Code) field to quickly indicate to the developer which functions may be computationally intensive, and require some WCET computation.