Crazyflie Design and Analysis Using AADL

CS 8803-O09 Project#3

Crazyflie design and analysis using AADL

About this project

For this project, we aim at using AADL to analyze an existing design of a small UAV, the Crazyflie, and then to extend it to add new capabilities.

This project is organized in multiple parts:

Part 0 is an introduction to AADL and toolchain. Please reference the attached «Tool Installation Instructions.doc. file. It only contain instructions to install the tools. I would recommend to use the option to install manually.
Part 1 is a walkthrough of the provided Crazyflie model (see attached ‘Crazyflie-master.zip’ file.), where you’ll perform multiple analysis and then expand the model;

PART 0 – AADL LANGUAGE AND TOOLCHAIN

In this part, we introduce the basic elements of the AADL Language and its toolchain.

These suggested readings may serve as a more comprehensive first reference to the AADL:

Julien Delange, AADL in Practice,
John J. Hudak, Peter H. Feiler,Developing AADL Models for Control Systems: A Practitioner's Guide, Software Engineering Institute (SEI) Technical ReportCMU/SEI-2007-TR-014, July 2007.

1.About AADL

The “Architecture Analysis and Design Language” (AADL) is both a textual and graphical language for model-based engineering of embedded real-time systems. AADL is used to design and analyze software and hardware architectures of embedded real-time systems.

The AADL allows for the description of both software and hardware parts of a system. It focuses on the definition of clear block interfaces, and separates the implementations from these interfaces. From the separate description of these blocks, one can build an assembly of blocks that represent the full system. To take into account the multiple ways to connect components, the AADL defines different connection patterns: subcomponent, connection, and binding.

An AADL model can incorporate non-architectural elements: non-functional properties (execution time, memory footprint, . . .), behavioral or fault descriptions. Hence it is possible to use AADL as a backbone to describe all the aspects of a system. Let us review these elements:

An AADL description is made of components. Each component category describes well-identified elements of the actual architecture, using the same vocabulary of system or software engineering. The AADL standard defines software components (data, thread, thread group, subprogram, process) and execution platform components (memory, bus, processor, device, virtual processor, virtual bus) and hybrid components (system) or imprecise (abstract).

Component declarations have to be instantiated into subcomponents of other components in order to model architecture. At the top-level, a system contains all the component instances. Most components can have subcomponents, so that an AADL description is hierarchical. A complete AADL description must provide a top-most system that will contain certain kind of components (processor, process, bus, device, abstract and memory), thus providing the root of the architecture tree. The architecture in itself is the instantiation of this system, which is called the root system.

The interface of a component is called component type. It provides features (e.g. communication ports). Components communicate one with another by connecting their features. To a given component type correspond zero or several implementations. Each of them describes the internal structure of the components: subcomponents, connections between those subcomponents. They can also refine non- functional properties, or add new ones.

The AADL defines the notion of properties. They model non-functional properties that can be attached to model elements (components, connections, features, instances, etc.). Properties are typed at- tributes that specify constraints or characteristics that apply to the elements of the architecture such as clock frequency of a processor, execution time of a thread, bandwidth of a bus. Some standard properties are defined, e.g. for timing aspects; but it is possible to define new properties for different analysis (e.g. to define particular security policies). Besides, the language is defined by a companion standard document that defines legality rules for component assemblies, its static and execution semantics.

The Figure 1 illustrates a complete space system, used as a demonstrator during the ASSERT project. It illustrates how software and hardware concerns can be separately developed and then combined in a complete model.

Figure 1 AADL Assert Demontrator

2.About AADL toolchain

The correct engineering of Cyber Physical Systems entails the designer to perform multiple types of analysis on a candidate architecture.

Semantic analysis: is the model correct w.r.t. to basic concerns? e.g. interfaces, containment hierarchy, consistency of configuration parameters, etc.;
Timing analysis: a model captures functional chain, and end-to-end flow path for data. One may want to assess if a given time budget allocated to each function is sufficient to support the system capabilities;
Scheduling analysis: at a later stage of refinement, one may want to ensure the low-level architectures (threads, buffers, etc.) are correctly configured so as to support all timing requirements;
Safety analysis: are the failures modes correctly defined?handled?

To support these analysis, we will combine three tools

OSATE, from developed by CMU/SEI. This is the reference implementation of an AADL toolchain. It supports text or graphical editing, timing and safety analysis;
AADL Inspector, from a product by Ellidiss. This tool proposes model simulation capabilities, and scheduling analysis.
Ocarina, from developed by ISAE. This toolchain proposes code generation capabilities from AADL models.

3.Installation of the toolchain

To install the toolchain, you have two options

a.AADL Virtual Machine

A Virtual Machine, to be used with Virtual Box, has been setup with all the necessary tools. It can be downloaded from

When imported in Virtual Box and started, use cs-8803-o09 / cs-8803-o09 as login and password. This Virtual Machine is built on top of debian 9.0 and has all the necessary tools and workspace already configured. This is the recommended option.

b.Install tools manually

It is expected you can install all tools on a laptop in less than 1.5 hours. Simply refer to each web site for details. We strongly suggest you opt for a Linux-based installation.

Warning: a Windows installation is possible, but would limit you to perform only 75% of the future project.

Note that AADL Inspector is available only for Linux and Windows. It requires a license file, contact the instructors to get it separately.

c.Project models

For this homework and the future project, we will use the AADL models from the following repository: FILE IS ATTACHED IN THE EMAIL. ‘Crazyfile-master.zip’)

This repository is configured in the VM; if you opted for a manual installation, it is advised you also clone the repository, this would allow for future updates of the models.

4.Guided tour of the tools

a.OSATE

Start OSATE.

If you are using the VM, click on the “run_osate.sh” link that is on the desktop

The workspace is organized using regular conventions of IDE:

The left panel is the list of files,
the central panel the current model/file being edited,
the right panel is the outline.

To update the repository: right click on the Crazyflie project in the left panel, then select Team -> Pull

To view graphical models corresponding to textual ones, you may either open files from the diagrams folder, or right-click on a model element in the outline panel, and click on “Open Diagram”.

Note: some graphical models have been built and organized, some others not. Expect some obfuscated diagrams.

To analyze a model, one has to identify the “root” of the system. The root is defined as the top-most component of a model. We have two root systems:
Crazyflie_Functional_Chain.Impl, in crazyflie_functional.aadl
Crazyflie_System.Impl, in crazyflie_system.aadl

Analyzing an AADL model is a two-step process:

Instantiate the root system: right-click on the top-most system. This wil generated a .aaxl2 file in the models/instances directory
Perform the analysis: right click on the generate file and select the analysis from the AADM Analyses menu

Supported analysis are:

Fault Analyses –> View FTA / Fault Impact Analyses
Check Flow Latency

b.AADL Inspector

Start AADL Inspector.

If you are using the VM, click on the “run_ai.sh” link that is on the desktop.

To load the Crazyflie project, load the crazyflie.aic file, located in

/home/cs8803-o09/git/crazyflie/models.

Note these are exactly the same files used in OSATE

AADL Inspector has three panels:
Left panel is the set of files in the current project
Central panel is the set of files being edited
Right panel is for analysis the model

Supported analysis
In the right panel, open Timing Analysis, perform all 4 scheduling analysis
In the right panel, bottom part, you can run the simulator

PART 1 – Unboxing the Crazyflie

About the Crazyflie UAV

The Crazyflie 2.0 is a versatile flying development platform that weighs only 27g and fits in the palm of your hand.

The Crazyflie 2.0 is an open source project, with source code and hardware design both documented and available. All information is available from BitCraze.io website:

Crazyflie 2.0 System Architecture[1]

Crazyflie 2.0 is architectured around 2 microcontrollers:

ANRF51, Cortex-M0, that handles radio communication and power management:
ON/OFF logic
Enabling power to the rest of the system (STM32, sensors and expansion board)
Battery charging management and voltage measurement
Master radio bootloader
Radio and BLE communication
Detect and check installed expansion boards
AnSTM32F405, Cortex-M4@160MHz, that handles the heavy work of flight control and everything else:
Sensor reading and motor control
Flight control
Telemetry (including the battery voltage)
Additional user development

See Figure 2 for more details.

The nRF51822

The two main tasks for the nRF51 is to handle the radio communication and the power management. It acts as a radio bridge (it communicates raw data packet to the STM).

Crazyflie 2.0 use the radio for both CRTP and BLE, but the hardware also supports other protocols like ANT. The CRTP mode is compatible with the Crazyradio USB dongle and it provides a 2Mbit/seconds data link with low latency. Test shows that the latency of the radio link is between 360us and 1.26ms, at 2Mbps without retry and a packet size of respectively 1 and 32 bytes. The minimum achievable latency with Bluetooth is 7.5ms but current implementation is more around 20ms. The main benefit of the CRTP link with the Crazyradio is that it’s easily implemented on any system that supports USB host which, makes it the first choice to hack and experiment with the Crazyflie. BLE is implemented mostly with the use case of controlling the Crazyflie 2.0 from a mobile device.

One of the other particularities of the nRF51 chip is that it was designed to run from a coin battery, which means that it is pretty well suited for low energy operation. So, the NRF51 is also responsible for power management. It handles the ON/OFF logic which means that the NRF51 is always powered and that different action are possible when pressing the ON/OFF button for a long time (i.e. this is used to start the bootloader). It is also possible to wake Crazyflie 2 from one pin of the expansion port, which allows wake-up by an external source.

Figure 2 Crazyflie 2.0 system architecture

The STM32F405

The STM32 runs the main firmware. Even though it is started by the NRF51, it acts as a master towards the NRF51. It implements flight control, and all communication algorithm. The expansion port is mainly connected to the STM32 so the driver for expansion boards sits in the STM as well.

The STM32F405 has 196kB of RAM which should be enough for anyone (famous last words…). This is overkill for just the flight controller but it allows for more computationally intensive algorithms, for example sensor fusion between inertial sensors and the GPS data.

Inter-MCU communication

The communication between the two CPUs is handled by thesyslink protocol. It is a simple packet-based protocol we made to have an extensible communication scheme.

Syslink provides messages for carrying all required communication between the CPUs. The STM32 is the master and the NRF51 the slave. As much as possible we try to keep the NRF51 simple and stupid to offload complex algorithm in the STM32.

Example of syslink message are:

Raw radio packets, to be sent and received
Power management measurement

Crazyflie 2.0 Controller architecture[2]

The following images illustrate the architecture of the controller at system-level and implementation levels. The controller is split in two sub-controllers: one Attitude PI-Controller running at 250Hz, and one Rate P-Controller running at 500Hz.

Note: the detail of the controllers is outside the scope of the assignements.

AADL modeling of the Crazyflie

We built a set of AADL models to serve as an entry point for our project. The models are both graphical and textual, they are organized as follows:

crazyflie_functional.aadl: abstract functional chain of the Crazyflie, adapted from the functional architecture
crazyflie_hardware.aadl: hardware part of the UAV, capturing the various hardware elements.
crazyflie_software.aadl: software part of the UAV, it is a candidate implementation only
crazyflie_types.aadl: list AADL data types used for the component interfaces;
crazyflie_system.aadl : one candidate full system, combining the hardware and software elements;
crazyflie_final.aadl : mapping of the abstract functional chain to the candidate implementation.

These models capture the outcome of a typical design flow for CPS.

First, we built the high-level functional chain (crazyflie_functional.aadl),
Then,we built the hardware (crazyflie_hardware.aadl) and software (crazyflie_software.aadl) candidates and one system combining them (crazyflie_system.aadl. By combining, we mean that the software elements are mapped to hardware ones.
Later, we built the crazyflie_finalmodel to ensure all functions are bound to implementation elements.

Note: the provided models are starting elements for the next steps of the project only! You may only assume they can be opened by the various tools.

Part 1.1: Flow latency analysis

Note: in this part, we will use OSATE to analyze and extend the model.

Part 1.2 Simulation of the model

Note: in this part, we will use AADL Inspector to simulate the model.

The following material provides an overview of the simulation framework used:

A typical error when building models is lacking ways to “debug” your system. Simulation is one possible option to address this issue.

AADL Inspector proposes a simulator that will exploit scheduling information from tasks and devices. For instance, the following indicates that every 10ms this device will output some data through the DOF6 port. Later on, we may infer the bus used for this communication.

device MPU9250

features

DOF6 : outdataport Crazyflie_Types::Six_Axis.impl;

i2c_bus : requiresbusaccess Buses::I2C::I2C.impl;

properties

Dispatch_Protocol => Periodic;

Period => 10 ms;

Another example is the definition of this thread:

thread Power_Management

properties

Priority => 2;

Dispatch_Protocol => Periodic;

Period => 500 us;

Compute_Execution_Time => 10 us .. 20 us;

end Power_Management;

The Compute_Execution_Time defines an interval for the time necessary to execute this thread. By construction, we assume that the deadline of an execution is equal to the period of the component.

In this model, we use two dispatch protocols:

Periodic: the component will be executed periodically
Sporadic: the component will be executed only if an event is received on one of its event (data) port, and after some time elapsed represented by the Period property.

Q5: simulate the model using the AADL Inspector simulator. Are all elements executed?How would you correct the system?