an incremental and multi-supplement compliant process for...

Frédéric POTHON - ACG Solutions

[email protected]

Tel: (33)4. 67. 609.487

www.acg-solutions.fr

An incremental and multi-supplement compliant process for Autopilot development

to make drones safer

Amin ELMRABTI - Sogilis

[email protected]

Tel: (33)4. 26.780.507

www.sogilis.com

Valentin Brossard - Hionos

[email protected]

Tel: (33)6.31.691.836

www.hionos.com

Agenda

1- Drones certification aspects

2- CAP2018 project

3- AGILE SW life cycle

4- Multi supplements

1- Drones certification aspects

Ongoing works

Drone classification

Operations Risk-Based

Open

Specific

Certified

Classifications/categories still under discussion

JARUS guidelines Specific Operations Risk Assessment (SORA) for the drones Specific category.

EASA shall develop AMC (Acceptable Means of Compliance) and CSs (Certification specifications)

Ongoing discussion on EUROCAE WG 105 work group to define applicable standards.

We decide to anticipate and to develop drone software

in compliance with DO-178C, Level A

2- CAP2018 Project

Hardware Platform

Autopilot Certification Plans

DO-178C Compliant development of the Autopilot

Autonomous drone advanced features: - Tracking a Target in mouvement - Collaborative drones - Detect & Avoid abostacles

Explo

itation

& D

issem

inatio

n

WP1

WP2

WP3

WP4

WP5

Objectives: Develop a reliable and safe autopilot for civil

commercial drones (Specific and Certified categories), compliant

with DO-178C, Level A in the software part.

Project Structure:

Partners:

Sogilis

ACG-Solutions

AdaCore

Squadrone System

SNCF

CEA-Leti

Gipsa-Lab

CAP2018: Certified AutoPilot for 2018

2- CAP2018 Project

Hardware Platform

Autopilot Certification Plans

DO-178C Compliant development of the Autopilot

Autonomous drone advanced features: - Tracking a Target in mouvement - Collaborative drones - Detect & Avoid abostacles

Explo

itation

& D

issem

inatio

n

WP1

WP2

WP3

WP4

WP5

SDVP : Software Development and Verification Plan

SCMP : Software Configuration Management Plan

SQAP : Software Quality Assurance Plan

PSAC : Plan for Software Aspects of Certification

Standards (Specification, Design, Coding)

Deployment of an Agile Software lifecycle

Deployment of various tools: Generic Test Framework, AdaCore Tools (for Ada2012 and Spark), Requirement Manager Tools, Versioning Management, Continuous Integration

Deployment of a Multi-supplement processes

Basic principles

- Incremental development

To develop progressively a limited number of new

functions/features. Iteration consists in adding/modifying some

features in the data developed during the previous iteration

cycles.

- Test Driven Development

Tests cases and requirements developed in the same process.

All tests re-executed at each delivery

- Continuous improvements

Application of plans and standards analyzed at the end of each

iteration and identification of possible improvements

3- AGILE Software Life Cycle

Life Cycle “processes”

DO-178C identifies several processes: planning, development

processes including requirements, design, coding, integration,

verification, CM, SQA, and certification liaison.

But is it possible to propose another “ordered collection of

processes”?


Life Cycle “processes”

The purpose of the life cycle is to organize the activities in order to

satisfy the objectives. Activities are grouped to form processes

Yes, processes may be organized as needed to create

an efficient life cycle, and to satisfy the objectives


CAP 2018 Selected Life Cycle

Development and verification activities are grouped into “ticket”

A ticket is a “process”

Tickets are

• Type 1: Process or System Improvement

• Type 2: Software Requirements

• Type 3: Architecture

• Type 4: Component

• Type 5: Source code

• Type 6: Integration

• Type 7: PDI Instance

• Type 8: Problem Report

• Type 9 Delivery



Each ticket include several activities

Example Ticket Type 2: Software Requirements

• Software requirement development

• PDI usage domain definition

• HW/SW interface description

• Software test cases development

• Software requirement self-check (no independence)

• Software requirement review (independence)

• Software Requirement coverage analysis

During implementation, tickets are re-assigned to ensure

independence, when applicable



Based on ticket implementation, status changes

Open at the ticket creation

ToDo: To be implemented during the iteration

Assigned: Resources identified and transition criteria met

Implemented: Data developed and/or updated and verified (no

independence)

Verified: Data developed and/or modified verified with independence

Done: at the end of iteration when all activities have been completed and in

case of errors or incompleteness, one or several Tickets Type 8 have been

opened.



The iteration planning phase identifies a set of tickets to be

addressed during the iteration in regard of

- Transition criteria (defined for each ticket)

- Priorities

- Available resources

- Need for delivery

Problems are recorded into ticket type 8. They are analyzed and

one or several tickets of other types are created to correct the

problem.


Component development: 3 methods may be applied:

• Simulink Model and QGen qualified code generator

=> DO-331/ED-218 - Model Based Supplement (and tool

qualification)

• Formal Model (SPARK functional specifications also called

Contracts)

=> DO-333/ED-216 Formal Model Supplement (and tool

qualification)

• Textual requirements in natural language and use of Object

Oriented Techniques

=> DO-332/ED-217 OOT Supplement

4- Multi-Supplements

Our rules: - One component = One method: No mix of methods inside the

same component

- Considerations on architecture

Decomposition allows the component development using a

single development method

- Simulink Model is identified as a single component in the

architecture. All requirements allocated to Simulink model are

allocated to that component


Model Development with Simulink and QGen

- One software requirement => One or several functional “blocks”

- The blocks may be decomposed in sub-blocks as necessary.

- As part of this decomposition, the developer identifies in each

development branch when a block represents a component

requirement.

- Then a trace data is provided between the block and one or

several software requirements.

- No derived requirements in the model

- Trace data developed using naming convention between block

name and Requirement_Id

- Code Ada generated with QGen (Qualified as Criteria 1/TQL-1)


Model Verification

- Model simulation performed based on Software Requirements

allocated to the model.

- Reviews of simulation data (independence).

- Model coverage analysis

Use of Mathworks simulation environment and tools.

Credit claimed of using QGen on source code verification and

component tests


Component Development and verification using Ada

contracts

- Formal analysis is applied on component for which it is possible

to describe all their requirements in form of Ada contracts.

SPARK technology is based on

- A formal model called SPARK contracts

- A formal analysis performed on SPARK contracts using

GNATProve tool.


Formal method: Key points

Credit claimed

Source code verification objectives (compliance to LLR, traceability,

accuracy, consistency) : Directly satisfied by the Formal analysis:

Components tests : Satisfied by the Formal analysis and the

property preservation between source and object code

“Soundness of method”

Description of the method in the PSAC, using international

publications references.

“Property preservation between source and object code”

Demonstration achieved through a second execution of the software

tests on EOC including the contracts in form of assertions


Formal method: Key points – FM specific objectives

“Formal analysis cases and procedures are correct”

Satisfied through the review of the component requirements: Ada

contracts are directly used as formal analysis cases. No need for

further cases into procedures.

“Formal analysis results are correct and discrepancies

explained”

Satisfied by the use of GNATProve, and analysis of GnatProve

results



Coverage of LLR is achieved:

Satisfied through the review of the requirements: Ada contracts are

directly used as formal analysis cases. Review includes

• Verification of complete description of expected behavior of the

component (normal and abnormal cases)

• Ada contracts may be used as a complete set of analysis cases.



Coverage of software structure

Achieved through

• Soundness of the method

• Completeness of requirements (Ada contracts): GNATMetric

ensures that the contracts references all inputs and all outputs

• Data flow coverage inside the component: Use of “Derives” aspect

in the contract guarantee that each output is properly linked to

corresponding inputs.

• Extraneous code (only dead code) addressed through source

code review


Component requirements:

Textual requirements

Contract requirements

Architecture (for component):

UML class, and/or

Sequence diagrams

Coding:

One component One Ada package

Use of naming convention

OOT implemented with Ada :

Inheritance / Interface / Tagged record

Generic types

String Typing

etc.

=> DO-332 could be used , we need to address some vulnerabilities

4- Multi-Supplements: Component Development using OOT

Vulnerabilities analysis: Vulnerabilities are addressed through: Ada2012 language and features

Coding standard rules.

Automated Verification with GnatCheck tool.

Code reviews

4- Multi-Supplements: Addressing DO-332 Vulnerabilities

Ada2012 Coding Standard

GnatCheck Code Review

Vulnerability Addressed Method Details

Inheritance - Multiple implementation inheritance

- Class attributes overriding

Inheritance - No static dispatch except for subclasses calling

their parents.

- No deactivated code in constructor: During

initialization, the first statement is the call to the

parent constructor.

- Multiple interface inheritance: a subclass cannot

inherit from two interfaces having the same

procedure name.

Coding Standard

Code Review

GnatCheck

Ada2012

4- Multi-Supplements: Addressing DO-332 Vulnerabilities

Vulnerability Addressed Method Details

Parametric

Polymorphism

- In Ada 2012 parametric polymorphism is possible

only with consistent types. The traceability between

source code and object code is addressed through

analysis including GnatPro compiler

- Strong Typing

Overloading - Not allowed, we asked AdaCore via Ticket to include

this rule in GnatCheck.

Type Conversion - No downcast nor narrowing conversions, we ask

AdaCore to add this rule in GnatCheck

Exception

Management

- Exceptions not allowed. “Last-Chance-Handler” Ada

Exception for runtime exception.

Dynamic Memory

Management

- All allocations done during Ada elaboration. After this

phase, no memory will be either allocated or

deallocated.

Ada2012

Coding Standard GnatCheck

Code Review

Coding Standard

Code Review

Coding Standard

Code Review

GnatCheck

Coding Standard

Code Review

PSAC: DO-178C objective coverage presentation Table A-6 example


an incremental and multi-supplement compliant process for...

Documents