Post on 20-Dec-2015
transcript
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