[SOLVED] Cs-7639-o01 project #3-crazyflie design and analysis using aadl

CS-7639-O01 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. It is provided as a reference;
• Part 1 is a walkthrough of the provided Crazyflie model, where you’ll perform multiple analysis and then expand the model;
• Part 2 revisits the Crazyflie models, with the objective to perform safety analysis.
Deliverables
Part 1
• A PDF report with answers to questions
• A .zip archive with updated models
Part 2
• A PDF report with answers to questions
• A .zip archive with updated models
CS-7639-O01 – Project #3 Crazyflie design and analysis using AADL

PART 0 – AADL LANGUAGE AND TOOLCHAIN

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

Suggested reading: the following provide a comprehensive first reference to the AADL:
• Julien Delange, AADL in Practice, http://aadl-book.com

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 wellidentified 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 CS-7639-O01 – Project #3 Crazyflie design and analysis using AADL
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 Demonstrator
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.;

CS-7639-O01 – Project #3 Crazyflie design and analysis using AADL
• Safety analysis: are the failures modes correctly defined? handled?
To support these analyses, we will use OSATE, from http://osate.org, developed by CMU/SEI. This is the reference implementation of an AADL toolchain. It supports text or graphical editing, timing and safety analysis;
3. Using a virtual machine [recommended]
A virtual machine is provided with all the tools (see section 4 below). It is available at the address: https://drive.google.com/file/d/1oN9hWWVP9ocj3gKWPhRiVrDr0sUcU08L/view? usp=sharing login: cs7639 / password: pqsszd
To open the ova file,
1. download the ova file to your computer
2. install VMWare Workstation (https://www.vmware.com/ products/workstation-player.html)
3. open the ova file with VMWare using the default settings Make sure you read the readme file on the desktop of the VM.
4. Installation of the toolchain on your own machine
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.
• Download OSATE from http://osate.org/osate-releases.html#stable-releases
• Install Cheddar plug-in: go in Help -> Install Additional OSATE Components, and Cheddar from http://beru.univ-brest.fr/cheddar/
5. Project models
For this homework and the future project, we will use the AADL models from the following repository: https://github.com/OpenAADL/Crazyflie
It is advised you clone the repository, this would allow for future updates of the models.
The project files have been setup already in the virtual machine provided.
CS-7639-O01 – Project #3 Crazyflie design and analysis using AADL
6. Guided tour of the tools

a. OSATE

[ Note that OSATE is updated regularly, some modifications on the GUI have been done recently. The following text is compatible with OSATE2.4.0. ]

• Start OSATE.

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, with the list of model entities (system, thread, process, etc.).

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

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

Note #2: a right-click on the diagram allows to select elements that will be visible. Some properties, connections might not be visible immediately.

• 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 from the outline (right panel). We have two root systems:
o Crazyflie_Functional_Chain.Impl, in crazyflie_functional.aadl o Crazyflie_System.Impl, in crazyflie_system.aadl

Analyzing an AADL model is a two-step process:
1. Instantiate the root system: in the right panel that lists all components, rightclick on the top-most system implementation (i.e. System Crazyflie_System.impl) and select instantiate.
This will generate a .aaxl2 file in the models/instances directory
2. Perform the analysis: right click on the generated file, and select the analysis from the AADL Analyses menu.
3. For Cheddar, select the instance file, then the “Cheese” icon in the main menu bar to generate the Cheddar XML file. Then run Cheddar

Supported analyses are: o Safety –> Run Fault Tree Analysis / Fault Impact Analyses
o Timing –> Check Flow Latency
o Scheduling Analysis (using Cheddar)

CS-7639-O01 – Project #3 Crazyflie design and analysis using AADL

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: https://www.bitcraze.io/crazyflie-2/.
Crazyflie 2.0 System Architecture
Crazyflie 2.0 is architectured around 2 microcontrollers:
§ A NRF51, 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
§ An STM32F405, 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 the syslink protocol. It is a simple packetbased 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

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

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_final model to ensure all functions are bound to implementation elements.

Part 1.1: Flow latency analysis

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

Suggested reading:
“Impact of Runtime Architectures on Control System Stability” by Peter H. Feiler and Jürgen
Hansson, ERTS2008, https://hal-insu.archives-ouvertes.fr/insu-02270102

The proposed model has a few flows modeled through the system. In AADL, a flow captures the propagation of data and its processing by various model elements such as devices and threads. Flows are an interesting capability to model expected end-to-end latency in processing chain. Our CrazyFlie UAV has multiple paths from sensors to actuators, and it would be beneficial to review them all.

In AADL, a flow is a piecewise definition of data “flowing” through component interfaces. The root of a flow is an “end to end flow” that lists its constituent, or atomic flow.

Here is the definition of one end-to-end flow from the Crazyflie_System package:

flows
— etef1 represents the functional chain from MPU9250 IMU to STM32 — firmware to one of the propeller.

etef1 : end to end flow MPU9250.f1 -> C11 -> STM32F405_Firmware.f2 -> C12 -> M1.f1 { latency => 0 ms .. 2 ms;};

Each subcomponent (MPU9250, STM32F405_Firmware, etc.) lists additional flow, here f1 and f2 respectively. An end-to-end flow starts with a flow source (e.g. a sensor) and ends with a flow end (e.g. an actuator)

Q2: add the additional end-to-end flows from Q1 in the AADL models, as well as necessary flow source/path/sink.

For each of them, you’ll use specific notation to indicate the modified elements. Suggested annotation is to use AADL comments, like

— John Doe begin of addition for question Q2
— John Doe end of addition for question Q2

where John Doe is changed to your actual name, and question adjusted accordingly.

Q3: Execute the latency analysis on the instantiated model with the default settings. What do you observe on the obtained values?

Considering that the Crazyflie has a symmetrical mechanical design, can you consider that some of the flows are redundant, i.e. capture the same behavior? Remember that flows measure the latency, not the value, of a signal.

Q4: In the description of the Crazyflie architecture, the latency requirements for various aspects of the system are detailed (see figures page 9). You should convert the frequency to period. List, if any, the end-to-end flows that these requirements affect. How will the end-to-end latency for these flows be affected by the requirements? Does the current architecture meet these requirements? If not, which end-to-end flows need additional timing allocation?

Part 1.2 Simulation of the model

Note: in this part, we will use Cheddar to simulate the Crazyflie_System model.

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

device MPU9250 features
DOF6 : out data port Crazyflie_Types::Six_Axis.impl; i2c_bus : requires bus access 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;

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.

Part 1.3 Scheduling analysis of the model

In this part, we continue exploring the analysis of the model with Cheddar.

Scheduling analysis provides a mechanism to assess schedulability of a system. Cheddar has multiple plug-ins to perform scheduling analysis.

Q6: run scheduling analysis on the system by clicking the gear button, what can you conclude?

Q7: how would you relate flow analysis, simulation and scheduling analysis? What is their benefit in a complete Systems Engineering process?

Part 1.4 Adding new component: Flow Deck

This page: https://wiki.bitcraze.io/projects:crazyflie2:expansionboards:flow lists an expansion board for the CrazyFlie. In order to improve the maneuverability of the UAV, one needs to add an additional sensor to evaluate lateral movement of the UAV. This solves the “sliding” behavior of the drone, at the expanse of extended computation.
In this part, we want to add the Flow Deck expansion board to the initial model.

One strategy is to define the corresponding devices in the hardware package, and add them to the hardware system, and add related model blocks to the software and functional models.

To avoid losing the previous model, we want to use the refinement/extension capabilities of AADL to add elements related to the Flow Deck expansion board.

system implementation Crazyflie_System.impl extends Crazyflie_Hardware::Crazyflie.impl
subcomponents
nRF51822_Firmware : process Crazyflie_Software::nRF51822_Firmware; STM32F405_Firmware : process Crazyflie_Software::STM32F405_Firmware.impl;

Q8: provide an expanded model with the Flow Deck integrated. Ensure all previous analysis are still feasible. You’ll provide the rationale for all the updates you performed in your report.

PART 2 – Safety Analysis

In this part, we will evaluate the safety architecture of the UAV through multiple analysis mandated by the ARP4761 standard.

Additional reading:
[1] Julien Delange, Peter H. Feiler, David P. Gluch, John J. Hudak, “AADL Fault Modeling and Analysis Within an ARP4761 Safety Assessment”. This report explains how to leverage the Error-Model version 2 to follow the ARP4761 safety process. The full report is available as SEI Technical Report from
http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=311884

This document lists in section 1 and 2 how to map AADL to analysis that are mandated by the ARP4761 safety process. This process is part of the many steps to create a certified system. In the following, we will apply some safety analysis to the Crazyflie model.

Important Notes:

Functional Hazard Analysis of the functional chain

An FHA is a systematic examination of functions to identify and classify failure conditions of those functions according to their severity. The AADL Error Model Annex supports the FHA through property assignments within an AADL architecture model.

Users can generate an FHA report using the Error Model Annex and OSATE, by assigning Hazard, Likelihood, and Severity property values to points of failure. Then, OSATE can generate the FHA report.

The EMV2 is an annex language, it adds a set of new concepts and associated language elements to the model.

The Crazyflie_Errors package defines a set of error types that can be propagated:
ValueError, ValueErroneous and Lost.
• ValueError indicate the value cannot be produced;
• ValueErroneous indicates an incorrect value has been produced;
• Lost means the component is now defunct, and the associated function is lost.

The Crazyflie_Errors package also defines an empty state machine, made of two states, Operational and Failed. This state machine will serve as a skeleton to build the failures modes of our UAV component.

In the following example, we attach probability of occurrence of entering in the Failed mode, and some documentation attached to this faulty situation, in addition to its severity and likelihood. Section 2.10.1 of [1] provides a complete definition of the Hazards property.

abstract Accelero features
Accelero_Out : out data port;
— [..] annex emv2 {**
use types Crazyflie_Errors; — definition of error types use behavior Crazyflie_Errors::simple; — definition of error modes
properties
— Useful for FHA reports
EMV2::OccurrenceDistribution => [ ProbabilityValue => 1.0e-9 ;
Distribution => Poisson;] applies to Failed;
EMV2::severity => 1 applies to Failed;
EMV2::likelihood => C applies to Failed;
EMV2::hazards =>
([ crossreference => “”;
failure => “Loss of sensor readings”; phases => (“all”);
description => “Sensor failure”;
]) applies to Failed;
**}; end Accelero;

A typical issue when building this analysis is to get meaningful value for the probability of occurrence of errors for a component. OEMs usually do not publish them on a regular basis, except for military-grade ones . Here, we assumed an unrealistic value of 10-9.

Q10: Generate the corresponding FHA report using OSATE.

Note: you’ll observe OSATE simply aggregates the elements from the model. The additional benefit is that the modeling language performs cross-check on the name of the failure modes, the coverage of modes etc. These ensure the report is consistent and complete.

Reliability Analysis of the functional chain

To achieve this goal, one needs to capture the failure mode of the system as a composition of the failure mode of the system.
This can be captured in Crazyflie_Functional_Chain.impl using an EMV2 subclause and a composite error behavior. This behavior refined the error automata of the system with a Boolean equation stating when the system is either in Operational or Failed mode. Obviously, the system is in Operational mode when all sensors are Operational, but this is also incomplete.

system implementation Crazyflie_Functional_Chain.impl
— [..]
annex EMV2 {**
use types Crazyflie_Errors; use behavior Crazyflie_Errors::simple; composite error behavior states
[ Acc.Operational and Gyro.Operational and Magneto.Operational
]-> Operational;
[ TBD
]-> Failed; end composite;
**};
end Crazyflie_Functional_Chain.impl;

Q11: What are the conditions for all elements to be either in the Operational or Failed modes? Extend the model accordingly. What is the failure probability you get, using the “Fault Tree Analysis” plug-in?

Taking into account software “failure”

abstract Accelero
— [..]
annex emv2 {**
use types Crazyflie_Errors;
use behavior Crazyflie_Errors::simple;
error propagations — outgoing error propagation
Accelero_out: out propagation {ValueError}; flows
–When the sensor fails, its error is propagated through port Accelero_Out
ErrorSource: error source Accelero_out {ValueError} when {ValueError};
end propagations;
— [..] **}; end Accelero;

Q12: Update the model to capture all error sources (components) in the functional chain, using the Accelero abstract component as a template.

The Sensor_Fusion abstract component is in charge of combining the inputs from the three sensors. It outputs one vector state that corresponds to the attitude of the UAV.

• the component error behavior captures the error automata of the system. The TBD part is a Boolean equation that captures how the system moves from the Operational to the Failed mode. The propagations part indicates the error being reported in case of an error.

abstract Sensor_Fusion
— [..]
annex EMV2 {**
use types Crazyflie_Errors;
use behavior Crazyflie_Errors::simple;

error propagations
Accelero_In : in propagation {ValueError}; Data_F_Out : out propagation {ValueError}; flows
f1 : error path Accelero_In -> Data_F_Out; end propagations;

component error behavior transitions
t1 : Operational -[TBD ]-> Failed; propagations
Failed -[]-> Data_F_Out{ValueError}; end component;
**}; end Sensor_Fusion;

Q13: propose and implement an update to the model that captures the following hypothesis on the fusion algorithm used: any error as input will translate as an error as output.

Q14: run again the Fault Tree analysis, how does the value compare with the previous one? Is it expected?

Q15: the fault impact analysis plug-in allows one to see how an error propagated in the functional chain. Execute the plug-in and compare the output to your model. How can you link each element of the fault impact analysis to model elements?

Q16: for the moment, we mostly performed basic updates on the system. Complete the error model by adding failures on motors, and the propagation of error value through the controller.