7th International Workshop on Java Technologies for Real-time and Embedded Systems – Madrid, Spain

Use of PERC Pico in the AIDA Avionics Platform

Eric JENN, Stéphane LERICHE – THALES Aerospace DivisionTobias SCHOOFS – SKYSOFTLudovic GAUTHIER, Kelvin NILSEN, Marc RICHARD-FOY – AONIX

2

Overview

A (long) preamble…

A few words about the context…

A few words about Java in the AIDA platform…

Some lessons learnt in DIANA…

A few words about Java and avionics certification…

And then?

3

Preamble

A slightly “THALES-centric” presentation…not so close to the paper

What could be the objectives of an “end-user” paper in JTRES?

Present subtle scientific achievements about Java, RTSJ, SCSJ? Definitively not (for me…)

Present some “embedded” applications using Java, RTSJ, SCSJ? Could be, but… Many applications in standard Java, representative of actual functions, not actual

designs (including development processes…) What would we learn from it?

Present benchmarks using std Java, RTSJ? Could be, but… (see above)

How can results be generalized?

(RTSJ benchmarks)

How can results be generalized?

(RTSJ benchmarks)

What about development processes?

(RTSJ benchmarks)

What about development processes?

(RTSJ benchmarks)

4

Preamble

What could be the objectives of an industrial paper in JTRES?

Express some industrial expectations…

Give a clearer statement of our problems…

Understand academics expectations…

Check that industrial / academics expectations match…

Understand what is going on…

Be here.

Good answers require good

questions require some maturity on

(new) issues…

Good answers require good

questions require some maturity on

(new) issues…

Open-source avionics “applications” ?

1-1 Cooperations + NDA

Open-source avionics “applications” ?

1-1 Cooperations + NDA

Causal relation between industry enthusiasm and

academia enthusiasm?

Causal relation between industry enthusiasm and

academia enthusiasm?

5

The Context

Industrial context (THALES Avionics, AMS)A few things we all know… A safety critical (avionics) system is not a “theoretical concept” Things shall be kept simple Things are not so bad today…

is a drastic change worth the risk? Can we convince other people

(airworthiness authorities…)?

(Making things hard to do is a means to) keep things simple… The language is only part of the problem / solution (education, tools, processes,..) (C is bad, Java is better, Whitespace is better, [A-Z][a-z]+ is better…)

SCSJ’s strategySCSJ’s strategy

An excellent protection

against unreasonable enthusiasm…

An excellent protection

against unreasonable enthusiasm…

What does “simple” mean?

What does “simple” mean? What about

runtimes, other

packages (java.lang…)?

What about runtimes,

other packages

(java.lang…)?

6

The Context

Industrial context (cont.)Heterogeneous requirements, complexity, development processes

Breaking and Steering SCADE diagrams, hard-real time Mono-threaded (cyclic scheduling)=> Not so complicated (from a SW design perspective)

Flight Warning System C, “soft”-real time Mono-threaded (cyclic scheduling)=> Not so complicated (from a SW design perspective)

Flight Management System Model-Driven, CCM-like framework (THALES-specific CIF) Ada 95, huge size Multiple timing constraints (hard, soft, none) and release patterns (periodic, aperiodic) Complex WCET / WCMU estimations (complex algorithms and data structures)=> Very complex problems (from all perspectives)

ComponentsTemporal isolation

(components)

ComponentsTemporal isolation

(components)

What would a high-level design look like

using RTSJ abstractions?

(schedulability)

What would a high-level design look like

using RTSJ abstractions?

(schedulability)

7

The Context

Industrial context (THALES Avionics, AMS) Development tools!!!!

Qualified, same constraints as for applications but… No real-time issues, Failures acceptable as far as they remain detectable

…

A less risky “first step” for us…

A less risky “first step” for us…

8

The Context

“Historical” context Two tracks

Java as a language for embedded systems Java as a prototyping language

Several research projects on “Java for embedded systems” First ports of application on PERC Ultra and Jamaica (FMS) First ports of JVMs on THALES’ IMA platform First benchmarks First analysis of language pros and cons First discussions about “Return On Investment” First questions about certification… Back to “wait-and-see” mode

Several developments of Java as a prototyping language

9

Java as a prototyping language : the “Airlab”

FunctionsFunctions

EnvironmentsEnvironments

OperationsOperations

Architecture

PerformanceRepresentative ofRepresentative of Not so

representative ofNot so

representative of

10

Java

What we are doing …

Main developm

ent cycle

Java

C / Ada / Ada 95

Java

Earlyvalidation of

functions / HMI

Earlyvalidation of

functions / HMI

Earlyvalidation ofalgorithms

Earlyvalidation ofalgorithms

11

What we would like to do…

Java

To allow a smoother, iterative, path from the mockup to the product

Separate concerns (when feasible)

Improve functional coverage

Improve verification coverage

Improve determinism

To end up with something

Representative of an actual airborne architecture

Potentially compliant with certification constraints,

12

DIANA and the AIDA platform

Distributed, equipment Independent environment for Advanced avioNics Applications European project (Skysoft , Aonix, Alenia Aeronautica, Embraer, Dassault Aviation,

SIA, University of Karlsruhe, BME, NLR)

Main objectives Enhance Integrated Modular Avionics (IMA) via

Clear definition of interfaces between “components” “Multistatic” Byzantine-resilient reconfiguration capabilities

Reduce cost of avionics software development via Simple Data Distribution Service Model transformations Decoupling of applications and execution platforms: the Neutral Execution Platform

Neutrality or Independence via The executive (A653 with VxWorks 653 [WindRiver] and IMADE [Skysoft]) The Java virtual machine (PERC Pico [Aonix])

Segregation based on “partitions”Temporal and

“spatial” isolation(components)

Segregation based on “partitions”Temporal and

“spatial” isolation(components)

Clarification of platform / components

mutual expectations via contracts

(scheduling)

Clarification of platform / components

mutual expectations via contracts

(scheduling)

13

Diego’s work:How can we support

refactoring? (Java for SC )

Diego’s work:How can we support

refactoring? (Java for SC )

The experiment

The target system

A simplified Flight Warning System

Initially developed in standard Java and then ported to PERC Pico

Under the constraint of minimizing architectural changes

Characteristics 14 KLOC 561 methods in 110 classes 1573 annotations Mohammed’s work:

How can we avoid refactoring using

patterns? (components)

Mohammed’s work:How can we avoid refactoring using

patterns? (components)

14

Pico

Overview of the system architecture

VxSIM 653/IMADE

Health and Mode management data

EWD

ECP

Alert messages and procedures

MWC button

Button state

Alert controler

Weight On Wheels, air data

FWS Back/Prim "ADIRU1"

AIDAto legacysystemscomm.bridge

Environ. Sim.

Button state

VxSIM 653/IMADE

FWS Prim/Back "ADIRU2"

AIDAto legacysystemscomm.bridge

VxSIM 653/IMADE

FWS Back/Prim

(cold spare) "ADIRU3"

AIDAto legacysystemscomm.Bridge

(cold spare)Pico Pico

Focus on memory management (no real-time issues)

15

PERC Pico

Main principles (regarding memory) The user expresses contracts about memory usage (transfer of references, memory

usage) via annotations The verifier checks

Intra-procedural compliance of a method’s code to the contract Inter-procedural compliance of contracts

@CaptiveScopedThis@ExternallyConstructedScope@CallerAllocatedResult(allowPreexistingResult=true)@ScopedMemorySize(bytes=37, instances={1}, types={DataInputStreamEmulator.class})private Integer extractInt(@CaptiveScoped SimpleBxmlHandler handler) {

try{

DataInputStreamEmulator dis = getInputStream(data);return handler.getAInt(dis.readInt());

}catch (IOException e) {

IOSystem.getOut().println("Problem during conversion byte[] to integer");IOSystem.getOut().println(e.getMessage());throw bxmlException;

}}

Diego’s work:Concept of “escape contract”, Role of behavioral contracts,

Selection of appropriate annotations

A unique annotation scheme?(Java for SC )

Diego’s work:Concept of “escape contract”, Role of behavioral contracts,

Selection of appropriate annotations

A unique annotation scheme?(Java for SC )

16

Our pragmatic “approach”

Justification

CompilationCompilation

FWSannotated

code(PERC Pico)

FWSannotated

code(PERC Pico)

AnnotationAnnotation

JustificationJustificationsJustifications

Annotationchange?

Annotationchange?

Design changeDesign change

AnalysisAnalysis

FWSoriginal

code(std Java)

FWSoriginal

code(std Java)

Error

NO

YES

72 cases

Prohibitive effort?

Prohibitive effort?

Functional & Structural “knowledge”

Functional & Structural “knowledge”

Relations between objects

Relations between objects

Lifespans of objects

Lifespans of objects How could the

user express his / her knowledge about object lifespans?

How could the user express his /

her knowledge about object lifespans?

17

Some lessons learnt

Positive aspects

The user does not directly manage scoped memory (enter/exit), this is the role of Pico

Code is modular (opposed to fragile) with respect to referential integrity

As far as the verifier is correct, then no memory related error may occur

Code can be executed on standard Java (with no stubs)

Analogy / complementarity with

Diego’s work?(Java for SC )

Analogy / complementarity with

Diego’s work?(Java for SC )

18

Some lessons learnt

Less positive aspects Difficulties to switch from std Java to Pico without modifying the architecture Documentation shall be enhanced, patterns shall be provided Diagnosis shall be facilitated Improve our confidence on the verifications

“Demonstrate” soundness / completeness of verification

Other topics Provide the compiler with the developer's knowledge about object lifecycles

Any formalization, “algebra” on memory references (transfer, lifespan…)?

Combine various formal techniques Abstract interpretation (the model is built from the code) Model-checking (the model / part of the model is provided by the developer)? Proof?

Diego’s Jscoper?

(Java for SC )

Diego’s Jscoper?

(Java for SC )

Possible link with Jean-Pierre’s work? :

Could Signal & model checking be used to verify absence of

(race | priority inversion | deadlock) conditons?

Possible link with Jean-Pierre’s work? :

Could Signal & model checking be used to verify absence of

(race | priority inversion | deadlock) conditons?

19

Java and Certification

Two examples A configuration generation tool developed in Java… A Flight Warning application developed in Java (to support early validation)…… both redeveloped in C In both cases Java was recognized as the most efficient language for the development… and rejected “due to certification concerns” / immaturity

From DO178B (1982) to DO178C Introduction of a “supplement” for Object Oriented Technologies, formal methods,

MDE, tools

Java and certification concerns Java is an Object Oriented Language : not specific, see OOTiA Java provides dynamic memory mngt : more non-deterministic than the application? Java has a large API: dead code, non executable code… Java relies on a runtime: keep it small

Filip’s Fiji! (RTVM impl.)

Filip’s Fiji! (RTVM impl.)

20

Tool qualification in DO178C

The toolset (compiler, verifier,…) plays an important role in Java Code generation, memory usage verification, unreachable code suppression Several activities being “interwoven” in the same tool Nothing new but…

DO178B principles Does not define a development process, but objectives Relies on the overlapping of verification activities Identifies two categories of tools Development / Verification

DO178C refinement on tools Criteria 1 applies for development tools Criteria 2 concern tools that automates verification process(es) and whose output is

used to justify the elimination or reduction of: Verification process(es) other than that automated by the tool, or Development process(es) which could have an impact on the resulting software. 

Criteria 3 applies for verification tools

21

Tool qualification (continued)

Category has an impact on activities: number of objectives to be achieved, level of independence to achieve these objectives

Category 2 or category 3? Proof tool used to automate some verification of source code.

=> Criteria 3 Claim that testing activity to detect a class of error becomes unnecessary thanks to the tool Reduction of Software Verification process(es) other than that automated by the tool => Criteria 2

Static code analyzer used to automate some verification of source code review. => Criteria 3 Claim to not include some specific mechanisms in the resulting software in order to detect and

treat the possible overflow, and run-time errors thanks to the tool Reduction of Software Development process(es) => Criteria 2

22

A few words to conclude

RTSJ and SCSJ Clarifies a lot of things left unclear in other languages Handles carefully things usually left to the users (e.g., memory mngt) Provides means for user to handle things correctly (e.g., schedulability)

Java will be ready to address forthcoming difficulties (soon?) Multicores…

What is missing (?) Some help to use all this: guidelines, patterns, tools Obtain some (first) evidences that API, runtimes and toolset will allow compliance with

DO178B/C objectives

Next steps… To resume activities… JTRES is a good electroshock… To update our justification case on Java To estimate cost to establish a DO qualification case

Jaroslav’s talk on JMMJaroslav’s

talk on JMM

Fiji could be a target

Fiji could be a target

23

Thank you for your attention