The document summarizes a presentation on the Project P project for developing model compilers for safety critical systems. Some key points: - Project P developed a generic framework and code generator called QGEN to generate code from models in languages like Simulink and Stateflow to languages like C and Ada. - The framework and QGEN were qualified up to DO-178C level TQL1 to allow their use in safety critical systems. - Case studies demonstrated the use of QGEN at companies like Thales Alenia Space to generate Ada code for a spacecraft attitude control system from Simulink models.

1. Pproject
Model Compilers
for Safety Critical Systems
Open Workshop
Palaiseau, June 16th, 2015

2. Agenda
14:00 – 16:00 Project presentation
• Project introduction
• Development and qualification of a generic framework
• QGEN code generator
• QGEN code generation in operational environment
• Others code generators
• UML code generator for UML models
• Formal verification perspective
• Question and answers
16:00 - 17:30 Demonstrations in Room 1 and 2
Slide 2 / 86

3. Pproject
Model Compilers
for Safety Critical Systems
Project Introduction
Continental
Slide 3 / 86

4. Project Introduction
From Sept. 2011 to July 2015 / Total effort of 67 py
DO-178 ISO 26262
ECSS
Slide 4 / 86

5. A Qualifiable GCC for Modeling Languages
Pivot Meta Model
An intermediate internal representation
Code Generation
(C, ADA)
Verification and
Integration
Control algorithm
Signal processing
Hardware DesignSystem Platform
System Engineer Hardware EngineerAutomation Engineer
Refinement and
model
transformation
Software Design
Software Engineer
Slide 5 / 86

6. Major Results 1/2
• Process guidance for Tool Qualification
• Based on DO-330, up to TQL1
• Templates as base for qualification material
• Centered around common intermediate representation
• Open, XML-based intermediate representation
• Code generation from multiple input to multiple output languages
• IN: Simulink, Stateflow, XCos, Scicos, Scicos Pro, UML
• OUT: Ada, C, VHDL
Slide 6 / 86

7. Major Results 2/2
• Formal verification on input
• Starting from a common intermediate representation
• Leverage on existing verification tools (PolyChrony, SynDEx,
SPARK…)
• Also for heterogeneous systems
• Run-time errors, formal verification, real-time properties at
model level
• Formal verification on the P Toolset itself
• Application of DO-333 to tool development
Slide 7 / 86

8. Pproject
Model Compilers
for Safety Critical Systems
Development and Qualification
of a Code generator
ACG
Slide 8 / 86

9. Qualification
Qualification and use of a qualified code
generator
Why qualifying a
code generator?
How qualifying
QGEN?
Slide 9 / 86

10. Why qualification a code generator ?
System
Requirements
Tests
Software
Requirements
Design
Code and EOC
Typical SW life cycle
Slide10 / 86

11. Why qualification a code generator ?
System
Requirements
Software
Requirements
Code and EOC
Tests
Typical SW life cycle with an ACG
Impact on Design format=
Model
Coding step automated
Slide 11 / 86

12. Why qualification a code generator ?
System
Requirements
Software
Requirements
Code and EOC
Tests
Code and EOC verification
alleviation
Typical SW life cycle with a qualified ACG
Slide 12 / 86

13. Why qualification a code generator ?
Hummm, the qualification replaces a recurrent
activity performed in the scope of the Software
life cycle, with a non-recurrent activity
performed at tool level.
Slide 13 / 86

14. Why qualification a code generator ?
Certification credit:
- Elimination of source code verification
- Alleviations of tests
- Alleviations of test verification (structural coverage analysis)
=> Based on the activities performed in the scope of the ACG
qualification effort
Recurrent
Non Recurrent
Slide 14 / 86

15. How qualifying QGEN?
Qualification Principles
- Certification basis: DO-330/ED-215 Tool Qualification
document, Used for all domains
- Highest level: TQL-1
- Equivalent as developing an airborne software
- Qualification only in a scope of a project
- COTS (Commercial Off The Shelves) Tool: Work-sharing
between tool developer and tool user
Slide 15 / 86

16. How qualifying QGEN?
“Tool User” and “Tool Developer”
- Qualification: In the scope of a specific project/context
(described in the Plan of Software Aspects of Certification)
- Some errors may be detected only in the user context
=> Specific DO-330 Objectives for the user context
This separation facilitates reuse,
COTS and further qualification
after changes
Slide 16 / 86

17. How qualifying QGEN?
Does the tool fits with user needs?
Process: «Tool Operational Verification and validation »:
- Verification : The tool is compliant with its requirements
- Validation : The tool is compliant with the user needs
(software life cycle) as described in the TOR (Tool
Operational Requirements) (or NOT!)
Not enough to verify the
compliance to the requirements
Validation is necessary!
Slide 17 / 86

18. How qualifying QGEN?
Tool Developer activities
- A pre-TOR is develop, defining operational domain (list of
symbols), generation options …
- All development activities are performed based on the
pre-TOR
- All verification, configuration management and quality
assurance activities on the development outputs
Slide 18 / 86

19. How qualifying QGEN?
Tool Operational Verification and Validation
Verification performed by the Tool-Developer
- Verification of the Pre-TOR
- Verification of compliance of the tool (source code
produced) based on the Pre-TOR
- Development and verification performed accordingly to this
pre-TOR.
Slide 19 / 86

20. How qualifying QGEN?
Tool Operational Verification and Validation
Validation performed by the Tool-User
- Pre-TOR assessment
- Develop additional information in the TOR
- Validation of the TOR based on the certification credit
- Validation of the tool: Development and verification
performed accordingly to this pre-TOR.
Slide 20 / 86

21. How qualifying QGEN?
Tool Operational Verification and Validation
Validation consists in
- To define a set of inputs that include all of the allowed
elements, and a combination of that may be generated
(additional information to be included in the TOR)
- To execute the QGEN on the set of inputs and generate
source code
- To generate executable object code by using the
compiler/linker with the selected options,
- To verify the compliance of the executable object code to
the input files, through testing.
Equivalent to low-level requirements based tests,
performed through equivalent classes of inputs
Slide 21 / 86

22. How qualifying QGEN?
Tool User data
- Finalization of Tool Qualification Plan defining user activities
- Tool Accomplishment Summary and Tool Configuration
Index with user activities status and data identification
- Review report of pre-TOR assessment
- Operational validation data
User data template
and example provided
Slide 22 / 86

23. Pproject
Model Compilers
for Safety Critical Systems
QGen: a commercial product
developed within Project P
AdaCore
Slide 23 / 86

24. What is QGen
• An instantiation of Project P toolset as a COTS
• Commercially available since October 2014
• Input: Simulink and Stateflow
• Output: MISRA C and SPARK
• Integrated with AdaCore V&V technology
• Static analysis: run-time errors, logical errors, safety properties
• Dynamic analysis: processor-in-the-loop testing, coverage analysis
• Qualification material available separately
• Come and see the demo at the AdaCore booth!
Slide 24 / 86

25. Using QGen
• Integrated in Matlab®
• From command line
qgenc MyModel.slx [code-generation-options]
Slide 25 / 86

26. QGen for code generation
Slide 26 / 86

27. QGen for code generation
Slide 27 / 82

28. QGen integration with AdaCore verification tools
Developed within Project P
Existing AdaCore Products
Slide 28 / 86

29. QGen for static verification
Slide 29 / 86

30. QGen for static verification
>> qgenv(‘cruise_control.slx’, ‘proof’)
Producing verification model…
Analysing verification model…
Analysis results:
assertion might fail: cruise_control/Assertion
assertion might fail: requires (not cruise_control/Brake and not
cruise_control/Clutch) or not cruise_control/Subsystem/Switch
>> Slide 30 / 86

31. QGen and Project P partners
• 10 official releases between Oct 2013 and July 2015
• 75% of Project P industrial partners have tested Qgen
• 8 total industrial partners
• 1 partner have just provided a use case
• 5 partners have engaged active evaluations
• 4 partners have opened accounts at AdaCore to track the evaluation
• 80% of academic partners integrated/extended QGen
• 100% of SMEs / Service Providers integrated/extended QGen
• Business model under study
Slide 31 / 86

32. QGen and Project P partners
time
partners
6
3
July 2014 (beta2) October 2014 (v1) July 2015 (v2)Oct. 2013 (beta1)
real evaluations
just test case
Slide 32 / 86

33. Supporting QGen (6 major releases)
0
5
10
15
20
25
1 2 3 4 5 6
Remaining new features backlog
0
5
10
15
20
25
1 2 3 4 5 6
Total number of bugs per
release
Reported Bugs Fixed Bugs
0
2
4
6
8
10
12
14
1 2 3 4 5 6
Total number of features per
release
Requested features Implemented features
0
5
10
15
20
25
1 2 3 4 5 6
Remaining bugs backlog
Slide 33 / 86

34. Supporting Qgen (performance study)
Latest 3 official releases, automotive case study
courtesy of Aboard Engineering
-70%-42%
Slide 34 / 86

35. QGen business impact OUTSIDE Project P
partners
time
clients
10
5
Feb. 2015 June 2015 Sept. 2015Oct. 2014
prospects
evaluations
Slide 35 / 86

36. QGen business impact OUTSIDE Project P
partners
• QGen and AdaCore business (Sept 2014 – June 2015)
• Highest marketing impact
• Shortest sales funnel
• Easiest prospects qualification
• Can piggyback to upsell existing products (GNAT Pro, GNATemulator,
…)
Slide 36 / 86

37. QGen: Lean Startup in a Collaborative Project
• Main difficulty: evaluation / adoption cycles are long
• Focus on shipping products: 10 releases in 20 months
• Consider partners as early adopters / champions
• This implies you need to be able to properly support them
• Short and frequent R&D cycles
• Incorporate users feedback into product roadmap
• Need for a product (not technology) vision
• Iterate and measure!
Slide 37 / 86

38. Pproject
Model Compilers
for Safety Critical Systems
QGen: Project P in operational context
Thales Alenia Space and Sagem
Slide 38 / 86

39. Case Studies in Project P
• Aboard Engineering (automotive)
• C code generation for motor control (RTW/EC proven)
• Airbus and Airbus D&S (aerospace)
• C code generation for spacecraft attitude control (RTW/EC proven)
• VHDL code generation for image processing
• C code generation from UML
• Sagem (aeronautic)
• C code generation for engine control and navigation system
Slide 39 / 86

40. Case Studies in Project P
• Continental (automotive)
• C code generation for engine management system (Simulink)
• C code generation for Tire pressure management system (Stateflow)
• C code and VHDL code for simple vehicle controller
• Rockwell Collins (aeronautic)
• Representative models for software generation for cockpit display
• Thales Alenia Space (space)
• Ada code generation for spacecraft attitude control w/ Stateflow
Slide 40 / 86

41. TAS Case Study
• The Sentinel 3 mission
• Part of the Copernicus framework of the European Commission
• Sea-surface topography, measurement of the sea-surface temperature, oceal colour
characteristics
• TAS was the prime contractor for the satellite, the avionics and the OBSW
• The case study is based on the Sentinel-3 Attitude and Orbit Control System (AOCS)
• One of the major subsystems of the satellite
• Controllers, estimators, equipment data processing, mode management
Slide 41 / 86

42. Current operational process
• For Sentinel-3
• AOFT functions (elementary AOCS functions) were generated
automatically in C language using TargetLink
• Remaining parts of the AOCS application (function initialization /
function connection & mode management) were specified in a
dedicated specification document for manual coding
• Unit test phase: Blocks are tested in stand-alone, with pre-defined
inputs. Outputs are analyzed to check the correct behavior of the
block.
• Integrated-level model validation: blocks are tested in closed-loop,
interconnected with spacecraft dynamics and models of
equipments
RelevantintheperimeterofProjetP
Slide 42 / 86

43. Vision
• An integrated toolset for modeling, code generation and verification of Matlab /
Simulink models
• Suitable for application in the space domain
• Qualifiable
• How can QGen contribute to this vision?
• Support for verification of properties at model level
• Generation of code from a qualifiable tool
• Permits to remove coding defects
• Permits to drastically cut cost of verification of code
• At the moment, code generated from non-qualified tools is considered
as manually coded, and undergoes the same V&V process
• Qualification of the tool is taken into account from the inception of the
development of QGen
Slide 43 / 86

44. Case study goals 1/2
• Use of QGEN for generating the Sentinel 3 AOFT functions
• Generation of Ada 2012 / SPARK code => first generator to support the
language!
• Comparison of code with the equivalent TargetLink C code
• In terms of functionality (blocks taken into account by the tool,
restrictions to achieve a “safe subset” of blocks)
• In terms of quality of generated code (modularity, readability,
maintainability, configurability of the generated code)
• In terms of suitability of code generation strategy (full generation of
application vs. suitability for generation of a library)
• In terms of suitability for the space domain (adherence to coding
rules, performance of the generated code, suitability for a resource-
constrained processor)
Slide 44 / 86

45. Case study goals 2/2
• Use of QGEN to further the Sentinel 3 code generation process
• Evaluation of Stateflows
• Some equipment data processing (Solar Array Drive
Mechanism) was re-modeled using stateflows
Slide 45 / 86

46. Case study results 1/2
• 100% of Sentinel 3 Simulink models are generated with QGEN
• ~26K blocks
• User feedback
• QGen easy to use
• Error reporting needs some improvements
• Support for Ada 2012 / Spark very appreciated
• Easier integration with the rest of the OBSW, which is coded or
generated in Ada 95
• Reasonable code generation performance
Slide 46 / 86

47. Case study results 2/2
• Preliminary results
• Good readability of code
• Unit tests are under finalisation
• Performance of the code under assessment
• Some violation of TAS coding rules (e.g., use clauses)
• Some limitations still present
• Duplicated code for Simulink blocks used several times even with
identical typing
• Full-flattening of code not configurable
• Feedback on the tool provider
• Reactive support (for information or bug analysis)
• Available to implement feature requests of interest for the case study
• Available to provide temporary toolset versions to unblock critical bugs
Slide 47 / 86

48. Sagem Case Study
Use case: navigation systems
Model-based software
engineering
Early phase of development
M88-4E
16,500 lb
Rafale
Mirage F50
Atar 09K50
15,840 lb
AlphaJet
Larzac®
3,082 lb
Apache
TR60
1,320 lb
EC120
Arrius
504 shp
EC145
Arriel
692 shp
NH90
RTM322
2 400 shp
Adour*
6,160 lb
Hawk
PPS®135
0
9 g
Satellites
200 N
44 lb
Silvercrest®
9,500 to
12,000 lb
Falcon 5X
* Rolls-Royce Turbomeca Ltd, a 50/50 joint company of Turbomeca and Rolls-Royce (U.K.)
Use case: Engine control units
(FADEC)
Model-based software engineering
1st certification DO178B: Dec. 2014
PROPULSION: THE BROADEST POWER RANGE
Slide 48 / 86

49. Case study sizing
Silvercrest engine control software
 125 software components: Simulink models including a few
stateflow
 41000 blocks
 Based on Simulink 2009b
 Certified in 2014
Navigation system software
 1 model with no Stateflow
 2500 blocks
 Based on Simulink 2012
 Early phase project
Slide 49 / 86

50. Case study goals
SELECTION OF MODELING ELEMENTS
• Simulink set of modeling elements
• Stateflow set of modeling elements
GENERAL REQUIREMENTS ON CODE GENERATION
• Compliance to in-house coding standards (partially MISRA-based)
• Static performance
• Dynamic performance
• Functional compliance
• Structural compliance (for test coverage)
TOOLSET REQUIREMENTS
• Tool Qualification level
• Certification effort
• Usability in software process
• Flexibility (parameterization and customization)
Slide 50 / 86

51. Case study results 1/4
no significant improvement achieved
expectations not fully met
expectation from
the proposal met
beyond expectations
Performance
1 2 3 4
4 4 8 12 16 Interesting for case study and ready for application in the field
Interest 3 3 6 9 12 Interesting for case study but to needs be matured for application in the field
2 2 4 6 8 Not of interest for the specific case study but interesting anyway for application in the field
1 1 2 3 4 Out of scope of case study, not of interest for application in the field.
Performance
The evaluation is performed within the following rating system:
EVALUATION RESULT = INTEREST * PERFORMANCE
Slide 51 / 86

52. Case study results 2/4
Issues on code generation
• 45 issues detected
• 7 irrelevant issues
• 34 corrections delivered (2 planned)
• 3 remaining limitations with impact
• 1 blocking (constant 3D-tables not supported)
Engine control SW
• Code generation 115 out of 125 components
• Blocking issues: constant 3D tables not supported
• Workarounds applied:
• Observable variables S-function replaced by Data Store Memory and option
WRAP_STATE
• S-functions connection to the C source file: S-function design modified from the
current one.
• Model configuration: solver forced to FixedStep:Discrete (currently overwritten by
tools)
Navigation SW
• Software not yet generated
• All issues corrected or planned
1 2 3 4
4 4 8 12 16
Interest 3 3 6 9 12
2 2 4 6 8
1 1 2 3 4
Performance
Slide 52 / 86

53. Case study results 3/4
0
2
4
6
8
10
12
14
16
Compliance to in-
house coding rules
code size
stack size
lines of code
Presence of
commentary
Readability &
Traceability: sample
a functional subset
of a model and try to
recognise the
functionality…
Impact of minor or
major change in the
model in the source
code
Dynamic
performance
GENERAL REQUIREMENTS ON CODE GENERATION
Status
• Coding rules non- conformities: No major
risk detected wrt source to object code
traceability
• Code size: same row of magnitude
• Stack size: non evaluated. Link to the
WRAP_STATE option
• Readability, traceability from model to
source code: correct
• Dynamic performance: not evaluated
Not confirmed issues
• Functional test on a component: 2 issues
under investigation
Slide 53 / 86

54. Case study results 4/4
0
2
4
6
8
10
12
14
16
Tool Qualification level: DO-
330 ED215 tool qualification
level TQL-1
Qualification file instanciation
effort
Usability in software process:
model coverage implies code
coverage
Usability in software process:
model sequencing and code
sequencing equivalent
Usability in software process:
multi-recurrence entry points
support
interoperabiity
Execution Environment
Generation independant of
modeling framework
Generate duration for code
generation
Cost usage
Documentation quality,
ergonomics
Flexibility: to control the
performance versus memory
consumption
Flexibility: to be customizable
to face customer specific
modeling guideline or tools
TOOLSET REQUIREMENTS
Status
• Qualification file not
mature
• Cost usage under
evaluation
• Reactive support of
AdaCore
• Documentation to be
improved (ex: types
customization)
Slide 54 / 86

55. Conclusion
Safran confirms its interest in Qgen for critical model-based
softwares
Main remaining topics
• Qualification file
• Failed functional tests
Way forward :
• Full scale assessment on a project, based on Simulink 2014
• Qualification file audit for certificability assessment
Slide 55 / 86

56. Pproject
Model Compilers
for Safety Critical Systems
Extending and Customising QGen
AdaCore
Slide 56 / 86

57. QGen extensions and customisations
• A “GCC for modeling languages”
• XCos, Scicos, Scicos Pro, NSP and UML
• Scheduling, real-time analysis and code generation
• PolyChrony and SynDEx
• New targets
• VHDL code generation with GAUT
Slide 57 / 86

58. QGen extensions and customisations
Slide 58 / 86

59. Xcos integration: Scilab Enterprises
C / Ada
QGen
Design Model
P export
external module
Packaged as a Scilab module
Support by Scilab Enterprises
Fully integrated into Xcos
From XCos to the P formalism
Any tool based on P can be used
Validated on the shared use-case
Rely on QGen for code generation
Slide 59 / 86

60. Xcos integration: Scilab Enterprises
• “P export” external module
• Support a subset of XCos blocks
• Mathematical blocks
• Discrete blocks
• Sources and sinks blocks
• Support synchronous dataflow on a single clock
• Application on the Continental use-case
• Manual translation from Simulink to Xcos
• Validation on reference datasets
• Analysis of the variations using numerical estimators
• Discretization of the model on XCos
• C code generation using the “P export” external module and QGen
Slide 60 / 86

61. Scicos / NSP integration: Inria, Enpc, Altair
C / Ada VHDL
QGen
Code Model
Nsp
Block semantics
specification
SimPort: Simulink Import Toolbox
P Export Toolbox
Nsp Script
GAUT
A semantically-preserving
migration path from Simulink
to Scicos / Scicos Pro
Slide 61 / 86

62. Scicos / NSP integration: Inria, Enpc, Altair
• P export toolbox
• Generating Nsp scripts from Scicos/ScicosPro
• Development of Nsp functions associated with library blocks
• Transformation of Scicos/ScicosPro diagrams into Nsp main scripts
• Generation of CodeModel from NSP script using partial evaluation
methodology
• Automatic testing environment
• Generate Ada and C with QGen, VHDL with GAUT
• Import of C code in Scicos environment for comparative testing
• Simulink import toolbox
• A migration path from Simulink to Scicos/ScicosPro
• Rely on QGen for code-level customization / optimisation
Slide 62 / 86

63. QGen and PolyChrony: Inria Rennes
• From input languages to SSME
• Compute guarded dependency graph
• Statement A is computed before B when condition C holds
• Static Scheduling of distributed, deadlock-free read/write operation
• From SSME to P: rely on the P integration for code generation
SSME
(PolyChrony)
QGen Design
Model
P2S exporte
r
Simulate &
Compute static schedul
ing
Physical architecture
(AADL, …)
Scicos, Xcos
exporters
QGen Design
Model
S2P importe
r
Slide 63 / 86

64. QGen and SynDEx – Inria Rocquencourt
Slide 64 / 86

65. QGen and SynDEx – Inria AOSTE
• Use Case evaluation
Slide 65 / 86
Blocs
number
Scheduling
analysis time
Archi MonoProc
Scheduling
analysis time
Archi BiProc
Scheduling
analysis time
Archi QuadProc
Balance_drive_controler.sdx
(AdaCore)
103 0.1 sec 0.1 sec 0.1 sec
Top_Vehicle_Controler.sdx
(Continental)
185 0.2 sec 0.5 sec 1 sec
Horizon.sdx
(Rockwell Collins France)
403 2 sec 4 sec 8 sec
Adc_sl.sdx
(Rockwell Collins France)
1403 38 sec 1 min 28 sec 3 min 28 sec
Measurements made on a processor Intel 8 cores Xeon ES-1620v2 @ 3.70Ghz

66. Targeting VHDL with GAUT
• G.A.U.T. HLS tool
• Input : C/C++ or P model descriptions
• Output: VHDL and SystemC
• GAUT IDE Integrated in Eclipse environment
• Model based tool
• Model-to-model with
• Model-to-Text with XTEXT/ACCELEO
Front-End Middle-End Back-End
IDE
source language
dependent
target
dependent
source & target
independent
QGen
Code Model
Scicos, Xcos
exporters
VHDL
(hw synthesis)
SystemC
(Simulation,
Virtual prototyping, DSE)
Slide 66 / 86

67. GAUT: Hardware prototyping
Sobel Filter
C/C++ or P Model
G.A.U.T.
Fir Filter
SoC design on a FPGA Xilinx Virtex 5 LX110 (XUPV5) board
01010010101
10101010101
10101010111
01010010101
10101010101
10101010111
01010010101
10101010101
10101010111
01010010101
10101010101
10101010111
Microblaze (100 Mhz, 8 ko cache) Local Memory Tft Controller
Memory Controller DDR OffChipSysAce
memory
FIR
Sobel Slicing Kernel
Plb bus
Plb bus
Line Buffer
Line Buffer
Pixel_in
Pixel_out
ul
ml
lllr
mr mm
ur um
lm
Aging Vector
Slicing Kernel
Aging Vector
Data in Data out
GAUT IDEApplication examples
1-
2- Bitstream
Slide 67 / 86

68. Pproject
Model Compilers
for Safety Critical Systems
Generating code from UML using QGen
ATOS
Slide 68 / 86

69. Positioning
• Initial goal: develop a generic, off-the-shelf, qualifiable model verification and code
generation tool for a subset of UML fitting the needs of the industrial partners
• Try to define a common working solution.
2 roadblocks specific to the use of UML made this initial objective impossible
• Different practices in the usage of UML
• Different experiences for UML code generation, reflecting the different
usage patterns of UML modeling.
• Focus on a specific usage of UML
• Target a very precise usage of UML for a single industrial partner, Airbus.
• Demonstrate the feasibility of using the P toolset to support a specific
usage of UML
• UML Profile
• HOOD methodology for the software structures
• ALF (fUML) language for the behavioral description.
Slide 69 / 86

70. Overview
UML
Alf
Design
P Importer
P
Code QGENC
C
Code
Slide 70 / 86

71. UML/Alf C concepts
UML
• Modeling language for
software engineering
• 2 kinds of diagrams:
• Static:
• Class diagram,
• Component diagram,
• Object diagram,
• etc…
• Dynamic
• Activity diagram,
• Sequence diagram,
• State diagram,
• etc…
• Originally object-oriented
design
Alf
• Action Language for
Foundational UML
• Alf has a largely C-legacy
syntax
C language
• Imperative computer
programming language
• Influenced many later
languages
• Wide range of platforms, from
embedded microcontrollers to
supercomputers
Slide 71 / 86

72. Generation
UML Design
• Structure
• Specific block diagram view to design with Hood method
• Behavior
• Alf code, textual representation for UML modeling elements
Used Tools
• Eclipse Indigo with Tophoo tool
• QGen generator
Tests
• Basics of C structure generation
• Airbus A380 sub-system design
Slide 72 / 86

73. Screenshots
Slide 73 / 86

74. Alf Code
Slide 74 / 86

75. Pproject
Model Compilers
for Safety Critical Systems
Formal Verification Perspectives
IRIT
Slide 75 / 86

76. Verification purpose
• Model correctness with respect to:
• Functional requirements
• Real time requirements
• Implementation correctness with respect to:
• Functional requirements
• Tool development (Automated Code Generator):
• Requirement completeness, consistency
• Transformation correctness
Slide 76 / 86

77. Functional correctness
• QGen Verifier by AdaCore (stand 1)
• Simulink annotation block
• Runtime errors (array bound, divide by zero, …)
• Dimension verifier by ONERA
• Data dimension annotation
• Controler robustness by GA’Tech, IRIT & ONERA
• Observers as requirements
• Software annotation synthesis (proof carrying code)
Slide 77 / 86

78. Observers as requirements
Slide 78 / 86

79. Software annotation synthesis
Slide 79 / 86

80. Real time correctness
• Syndex toolset by INRIA AOSTE (stand 3)
• Schedulability
• Hardware architecture synthesis
• PolyChrony toolset by INRIA TEA
• Clock calculus
• Logical architecture synthesis
• UML Real Time Verifier prototype by IRIT
• Requirements: CCSL models
• AADL-BA to FIACRE prototype by IRIT
• Requirements: Temporal logic, Timed observers
Slide 80 / 86

81. Implementation verification
• Models as requirements for:
• Hand written software verification
• Generated software verification
• Translate models to annotations
• Data-flow to Why3 and ACSL by IRIT (stand
6)
• UML to ACSL by ATOS (stand 9)
Slide 81 / 86

82. UML annotation generators (stand 9)
• State Machine Flow (https://code.google.com/a/eclipselabs.org/p/agrum/)
• Activity Flow (https://code.google.com/a/eclipselabs.org/p/a2acsl-
project/)
• Pre/Post OCL (https://code.google.com/a/eclipselabs.org/p/ocl2acsl/)
StateMachine
generator
« Agrum »
ACSL Frama-C/WP
Activity
generator
« A2ACSL »
ACSL Frama-C/WP
PrePost OCL
generator
« OCL2ACSL
»
ACSL Frama-C/WP
Slide 86/ 86

83. Tool correctness
• TOR formal specification
• Expected software using translation patterns by AdaCore
• Translation rules using annotations by AdaCore
• Dynamic verification during translation
• TR formal specification
• Block Library specification DSL by IRIT (stand 6)
• Block parameters, memories, inputs, outputs
• Block semantics : Annotations, Algorithms
• Specification completeness, consistency, correctness
• Software verification using generated annotations (proof carrying code)
Slide 83 / 86

84. Generated annotations
Slide 84 / 86

85. Pproject
Model Compilers
for Safety Critical Systems
Questions & Answers
Slide 85 / 86

86. C / Ada
Verif
PIL testing
QGen
C / Ada
XCos Exp.
QGen
Real-time
allocation
Scheduling tableTiming attributes
Architecture
QGen
SynDEx
C / Ada
UML Exp.
QGen
C / Ada
UML Exp.
QGen
QGen
GAUT
C / Ada
NSP Exp.
QGen
VHDL
3
7
Room 1 Room 2
1 3
6
7 8
Generation of formalized req
uirement from the model
9
Formalization of requirement
for the code generator
4 5
2
158
69 2
4
C
Slide 86 / 86