1. 17/06/2015 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 Division Tobias SCHOOFS – SKYSOFT Ludovic GAUTHIER, Kelvin NILSEN, Marc RICHARD-FOY – AONIX

2. 1 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. 2 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) What about development processes? (RTSJ benchmarks)

4. 3 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… Open-source avionics “applications” ? 1-1 Cooperations + NDA Causal relation between industry enthusiasm and academia enthusiasm?

5. 4 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 strategy An excellent protection against unreasonable enthusiasm… What does “simple” mean? What about runtimes, other packages (java.lang…)?

6. 5 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) Components Temporal isolation (components) What would a high- level design look like using RTSJ abstractions? (schedulability)

7. 6 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…

8. 7 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. 8 Java as a prototyping language : the “ Airlab” Functions Environments Operations Architecture Performance Representative of Not so representative of

10. 9 Java What we are doing … Main development cycle Java C / Ada / Ada 95 Java Early validation of functions / HMI Early validation of algorithms

11. 10 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. 11 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) Clarification of platform / components mutual expectations via contracts (scheduling)

13. 12 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)

14. 13 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" AIDA to legacy systems comm. bridge Environ. Sim. Button state VxSIM 653/IMADE FWS Prim/Back "ADIRU2" AIDA to legacy systems comm. bridge VxSIM 653/IMADE FWS Back/Prim (cold spare) "ADIRU3" AIDA to legacy systems comm. Bridge (cold spare) Pico Focus on memory management (no real-time issues)

15. 14 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  )

16. 15 Our pragmatic “approach” Justification Compilation FWS annotated code (PERC Pico) Annotation Justification Justifications Annotation change? Design change Analysis FWS original code (std Java) Erro r NO YES 72 cases Prohibitive effort? Functional & Structural “knowledge” Relations between objects Lifespans of objects How could the user express his / her knowledge about object lifespans?

17. 16 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  )

18. 17 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  ) Possible link with Jean-Pierre’s work? : Could Signal & model checking be used to verify absence of (race | priority inversion | deadlock) conditons?

19. 18 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.)

20. 19 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. 20 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. 21 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 JMM Fiji could be a target

23. 22 Thank you for your attention