Project #3 Crazyflie Design and Analysis Using AADL

Q10: Update Crazyflie_Functional::Crazyflie_Functional_Chain.impl and its subcomponents with EMV2 properties to support the Functional Hazard Analysis FHA. You may adjust the hazards considering only failure of hardware (CPU, memory, sensors, etc.) or mechanical elements only. We consider, for the moment that the pilot and the software are defect free.

Answer:

The Crazyflie_Functional::Crazyflie_Functional_Chain.impl package allows one to create a FHA from this functional chain, by attaching the identification of failure conditions as illustrated below:

abstract windows user

features

windows user_Out : out data port;

-- [..]

annex emv2 {**

use types Crazyflie_ Functional::Crazyflie_Functional_Chain.impl -- definition of error types

use behavior Crazyflie_Error:: Crazyflie_Functional_Chain.impl; -- 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 =>

([ cpu failure => "";

failure => "Loss of sensor readings";

phases => ("all");

memory failure => "Sensor failure";

sensors failure => "May be critical as no redundancy on UAV";

]) applies to Failed;

**};

end windows user;

Q11: Generate the corresponding FHA report using OSATE.

Note: youll 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.

FHA report:

-- 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 =>

([ cpu failure => "";

failure => "Loss of sensor readings";

phases => ("all");

memory failure => "Sensor failure";

sensors failure => "May be critical as no redundancy on UAV";

]) applies to Failed;

**};

end windows user;

Applying Boolean equation; the user is able to notice when the system is either in Operational or Failed mode in as much as the system is in Operational mode when all sensors are Operational.

Q12: 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 Reliability Block Diagram plug-in?

Answer:

In consideration of the Sensor_Fusion function, when the windows_user device sends ValueError through its windows-user_Out feature:

abstract windows-user

-- [..]

annex emv2 {**

use types Crazyflie_Error;

use behavior Crazyflie_Error::simple;

 

error propagations

-- outgoing error propagation

Windows-user_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 windows-user;

Q13: Update the model to capture all error sources in the functional chain, using the accelero abstract component as a template:

Answer:

Through the Sensor_Fusion abstract component, the windows-user can compile inputs from three sensors as well as capture the propagation of errors within a system. The possible errors include:

the error propagations

the component error behavior.

abstract Sensor_Fusion

-- [..]

 

annex EMV2 {**

use types Crazyflie_Error;

use behavior Crazyflie_Error::simple;

 

error propagations

windows-user_In : in propagation {ValueError};

Data_F_Out : out propagation {ValueError};

flows

f1 : error path windows-user_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;

Q14: Propose 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.

Involves consolidation of the Sensor_Fusion and Crazyflie_Functional:: Crazyflie_Functional_Chain.impl

abstract windows user

features

windows user_Out : out data port;

-- [..]

annex emv2 {**

use types Crazyflie_ Functional::Crazyflie_Functional_Chain.impl:sensor_fusion-- definition of error types

use behavior Crazyflie_Error:: Crazyflie_Functional_Chain.impl; sensor_fusion -- 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 =>

([ cpu failure => "";

failure => "Loss of sensor readings";

phases => ("all");

memory failure => "Sensor failure";

sensors failure => "May be critical as no redundancy on UAV";

]) applies to Failed;

**};

end windows user;

Q15: run again the Reliability Block Diagram analysis, how does the value compared with the previous one? Is it expected?

Gross estimate of system reliability on OSTATE becomes as a result of using an evaluation of state occurrence. This metrics is produced using the composite error behavior from the main system (root component) and the Occurrence. Distribution value associated to its state in the same component. This is illustrated as shown below:

Properties

 

-- The following values are used rather for the RDB

-- They are not used by PRISM itself

EMV2::OccurrenceDistribution => [ProbabilityValue => 0.00009; Distribution => Fixed;] applies to f1.Failed;

EMV2::OccurrenceDistribution => [ProbabilityValue => 0.00009; Distribution => Fixed;] applies to f2.Failed;

EMV2::OccurrenceDistribution => [ProbabilityValue => 0.00009; Distribution => Fixed;] applies to f3.Failed;

EMV2::OccurrenceDistribution => [ProbabilityValue => 0.00009; Distribution => Fixed;] applies to f1.Failed;

EMV2::OccurrenceDistribution => [ProbabilityValue => 0.00009; Distribution => Fixed;] applies to f2.Failed;

Q16: 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?

Ways of linking each element of the fault impact analysis is through comparing the Severity, the Likelihood and the Hazard landing on a system fault event and their propagation. The element values of the model are then compiled into an Excel document

Q17: 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.

On motors and the propagation of error value through the controller:

 

abstract windows user

features

windows user_Out : out data port;

-- [..]

Annex emv2 {**

use types motor: controller -- definition of error types

use behavior motor: controller; -- 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 =>

([ cpu failure => "";

failure => "Loss of sensor readings";

phases => ("all");

memory failure => "Sensor failure";

sensors failure => "May be critical as no redundancy on UAV";

]) applies to Failed;

**};

end windows user;