AdaCore Paris Tech Day 2016: Jose Ruiz - QGen Tech Update
Transcript of AdaCore Paris Tech Day 2016: Jose Ruiz - QGen Tech Update
Jose Ruiz
QGen Tech UpdatePlans, Markets, Technology
QGen Technical Lead
What’s New
• More than just a code generator:§ includes Processor-In-the-Loop testing support§ supports an add-on interactive model-level Debugger
• Multiple user interfaces:§ an advanced GUI plug-in for Matlab®/Simulink®§ a Matlab® command-line interface§ an integration with AdaCore’s GPS IDE§ a stand-alone command-line interface
• Basis for ongoing research:§ focused on preserving System to Software Integrity§ based on formalized higher-level requirements and model-based development
Why Model-Based Development?
System Engineers vs. Software Engineers
“Who needs programmers?
Why do we have to depend on them to
implement our design? Why can’t I just push a button
and get code?”
“Uh boy, not another attempt at Programming with Pictures… These
folks don’t know the first thing about
software”
System Engineers + Software Engineers
System Engineers focus on High-level design represented in a modeling language that supports automated code generation.
Software engineers focus on providing new or enhanced parameterized building blocks, code-generation capabilities, and infrastructure.
User-DefinedDerivatorimplementedinSPARK
The Unique Value AdaCore Brings to Model-Based Development
Modeling ToolsDrawing, Analysis, Simulation, Autocoding
Coding ToolsCompiling, Analysis, Scheduling, Debugging
Architecture ToolsDefinition, Analysis, Documentation
Verification ToolsTesting, Analysis, Coverage, Proof
QGen
GNAT ProQGen Debugger
CodePeerSPARKPro
GNATCoverage
Ongoing Research
Full
Dev
elop
men
t Sta
ck
QGen focusedhere
GNATPro focusedhere
The V-Model ofSystem Development
Code Generation
QGen Code Generation
• Several code generation strategies§ One file per atomic subsystem, one file per model, inlining, reusable code, …
• Traceable and readable code
• QGen version independent of Simulink version
• Customizable code generation§ Possible to redefine operators or code for block libraries without changing the
model
• Optimized code generation§ Inlining and removal of temporal variables, keeping the traceability between model
and code
QGen Code GenerationCustomization
Block-Level CustomizationProblem:reuseofpre-certifiedcodelibraries
MappingtoblockfunctionalitiesImplementationspecifictoaproject/platform
Canyoutranslatethismodel tosourcecodebutuseoursourcecodelibrary forLookupTables?
???
Block-Level Customization
• Classic approach: use S-Functions§ Need to modify model to use them§ Need to modify model when a new function is available
• Solution: tell the code generator§ QGen allows to specify which function to call for every block type
Block-Level CustomizationExample- functioncallforLookuptable
Call:float flookup(const float ** table, float x, y)
Providethefollowingspecificationinaconfigurationfile:
Lookup_nd : //Blocktype
double = (double, double) //BlocksignatureI/O
double y1 = flookup(double[][] p1, double u1, u2) //functiontocall
my_block_lib.h //Headerfile
ThisisenoughtoinstructQGentogeneratethecallaboveforallLookup_ndblocks
Arithmetic Level CustomizationProblem:reuseofpre-certifiedcodelibrariesMappingtoarithmeticoperations(+,-,/,*,…)Implementationspecifictoaproject/platform
Canyoutranslatethismodel tosourcecodebutuseourvectorizedprocessorlibrary forall“+”betweencomplexscalarnumbers?
???
Arithmetic Level Customization
• Classicapproach1:usecodegenerationreplacementlibraries§ Limiteduse:nocomplextypes
§ Maynotworkinmodelsimulationbecausetheyrelyonintrinsicfunctions
§ RequiretorunMatlabscriptstoupdatethereplacementfunction(notpractical)
• Solution:tellthecodegenerator§ QGenallowstospecifywhichthereplacementlibraryforanytypeasanexternalconfigurationfile
Arithmetic Level Customization
Example- sumofcomplexnumbersCall:cfloat dcsum (const cfloat x, y)
Provide thefollowing specificationinaconfiguration file:
cfloat = cfloat + cfloat : //operationsignature
cfloat y1 = dcsum(cfloat u1, cfloat u2) //function tocall
my_complex_lib.h //Headerfile
ThisisenoughtoinstructQGentogeneratethecallaboveforallsumbetweencomplexnumbers.Changingthefunctiontocallrequiresjusttoedittheconfigurationfile,noMatlabrequired.
QGen Code Generation Demo
QGen TQL1 Qualification
DO-178C, Tool Qualification Levels
Criteria1:Atoolwhoseoutputispartoftheairbornesoftwareandthuscouldinsertanerror.Criteria2:Atoolthatautomatesverificationprocess(es)andthuscouldfailtodetectanerror,and
whoseoutputisusedtojustifytheeliminationorreductionof:• Verificationprocess(es)other thanthatautomatedbythetool,or• Developmentprocess(es) thatcouldhaveanimpactontheairbornesoftware.
Criteria3:Atoolthat,withinthescopeofitsintendeduse,couldfailtodetectanerror.
SoftwareLevels,failureis…
LevelA:Catastrophic
LevelB:Hazardous
LevelC:Major
LevelD:Minor
Benefits of TQL-1 Qualification
• TQL-1 Qualification provides many user benefits:§ Can bypass reviewing the generated source code
• No need to check against coding standard, compliance of code against requirements, …
§ Can bypass creating specific low-level requirements for the generated source code
§ Can bypass creating low-level tests for the generated source code• Can reuse the high-level tests created for the model
§ Can bypass coverage analysis of generated source code
• But ... Qualification puts strong requirements on QGen development
DO-178C ObjectivesAssociated with QGen TQL-1 Qualification
No Objective Satisfaction Methods in DO-331 Notes
1 SC complies with LLRs QGen TQL1
2 SC complies with SA QGen TQL1
3 SC is verifiable QGen TQL14 SC conforms to standards QGen TQL1
5 SC is traceable to LLRs QGen TQL1 (plus User activity) It is also required to verify that the tool has been exercised on the complete set of input files to ensure that all the low-level requirements have been developed into Source Code
6 SC is accurate and consistent QGen TQL1 (plus User activity) Worst-case execution time or stack usage analyses may only be satisfied after the Source Code generation
7..9 Responsibility of Tool User
MB.A-5 Verification of Outputs of Software Coding & Integration Process
Table A-5: Source code verification objectives
No Objective Satisfaction Methods in DO-331 Notes
1 EOC complies with HLRs. Responsibility of Tool User2 EOC is robust with HLRs. Responsibility of Tool User
5 EOC is compatible with target computer. Responsibility of Tool User
MB.A-6 Testing of Outputs of Integration Process: Summary of options
3 EOC complies with LLRs.
4 EOC is robust with LLRs. User executes HLR-based testing with final executable and target hardware
User executes HLR-based testing with final executable and target hardwareQGen TQL1
QGen TQL1
Table A-6: Executable object code verification
No Objective Satisfaction Methods in DO-331 Notes
1..4 Responsibility of Tool User
8Test coverage of software structure (data coupling and control coupling) is achieved.
Responsibility of Tool User
9..12 Responsibility of Tool User
7 Test coverage of software structure (statement coverage) is achieved. Presumes test coverage of model (block coverage) is achieved.
5 Test coverage of software structure (MC/DC) is achieved. Presumes test coverage of model (MC/DC) is achieved.
6 Test coverage of software structure (decision coverage) is achieved. Presumes test coverage of model (decision coverage) is achieved.
QGen TQL1
QGen TQL1
QGen TQL1
MB.A-7 Verification of Verification Process Results
Table A-7: Code CoverageVerification
QGen Debugger
QGen DebuggerUnique Model-Level Debugging Capability
• Synchronized view among:§ Simulink model§ Generated Code§ Assembly Code
• Model-Level Breakpoints§ Stop on entering block§ Stop on signal computation
• Model-Level Data Display and Update§ Display values on each Signal line§ Override values to force Model
• Model-Level Stepping§ Step one Block Computation/Update§ Step into/out of Subsystem
QGen Debugger Demo
QGen Roadmap andResearch Directions
QGen RoadmapsInternal Focus
• Code Generator
• Ease of Installation and Use
• Qualification
• Model Testing and Debugging
• Model Verifier (CodePeer)
• Internal QA and Infrastructure
• Formalized Requirements Research
• Multicore Support
External Roadmap
• 2016 (QGen 17.0)• Enhanced User Interface• Code Generation• Processor-In-The-Loop Support• QGen Subset Checkers• Model-Level Debugging• Better Integration with external
code• 2017 (QGen 18.0)
• Initial Tool Qualification Kit• Multiple Version Support• Requirements Checking
• 2018 (QGen 19.0) • Full Tool Qualification Kit• Scripting Language Support• Partial SysML translation• Multicore Support
QGen Research directions
• Formal methods support for Qualification
• High-level architecture definition (SysML, AADL)§ Driven by Automotive Industry
• Workflow for defining formal contracts (OCL, VDM)§ Driven by Aerospace Industry
QGen Automotive Research Proposal: Formalized Requirements
• Four Objectives, to investigate…1. formal notations for expressing control-system requirements2. connecting these formalized requirements to Simulink models3. converting these formalized requirements into SPARK4. verifying conformance between the formalized requirements and the code
for the control system, including both static and dynamic methods (combinations of both “proof” and “test”)
QGen Automotive Research Proposal: Formalized Requirements• Four Objectives, to investigate…
1. formal notations for expressing control-system requirements2. connecting these formalized requirements to Simulink models3. converting these formalized requirements into SPARK4. verifying conformance between the formalized requirements and the code for
the control system, including both static and dynamic methods (combinations of both “proof” and “test”)
Formalized Requirements and SysML• High-Level Architecture
§ SysML Structure Diagram• Requirements
§ Structured Natural Language§ Template-Based Requirements System (e.g. ArgoSim STIMULUS)§ SysML Object Constraint Language (OCL)
• Traceability between requirements and architecture§ Satisfy relationship that determines the block that implements the
requirement
<<requirement>>DisabledCruiseControl
Id=“4.3.5”Text=“CC_StateshallnotbeTrueifBrakeorClutchisTrue”
<<block>>CruiseControl
<<flowPort>>Clutch :Boolean
<<flowPort>>CC_State :Boolean
<<satisfy>>
RequirementsStructure
<<flowPort>>Brake:Boolean
<<flowPort>>ChangeState :Boolean
Simulink skeleton generated: Specification Model • Architecture of the application
§ Simulink skeleton tied to Formalized Requirements• Executable and verifiable requirements
§ Requirements represented as SPARK contracts
Simulink implementation:Design Model
• Refinement of the Simulink model§ Fill the skeleton to produce Design Model
• Requirements Verifiable statically and dynamically§ Using executable contracts§ Formal verification§ Testing using simulation cases§ Test using Hardware-In-the-Loop (HIL)
SPARK contract
Formal proof
SPARK Toolset used to verify model against requirements represented as SPARK contracts
QGen Value Proposition
Aerospace & Defense MarketValue Proposition• QGen designed as a TQL-1 qualifiable code generator• QGen only Simulink code generator that produces SPARK/Ada• QGen debugger helps track down problems that only show up on
the target• QGen can support code generation for multiple Simulink versions,
making it easier for customers upgrading to new Simulink versions
• QGen research is integrating with Architecture-oriented languages
Automotive MarketValue Proposition• QGen code generation has customizability and tunability• QGen supports adoption of Formal Methods by generating
SPARK/Ada• QGen is a powerful transformation framework which enables
bridges between modeling languages (SysML, UML, ...)• QGen is appropriate as code generator for ASIL C & D applications• QGen debugger provides unique model-level insight into
generated code • QGen can support code generation for multiple Simulink versions,
making it easier for customers upgrading to new Simulink versions
• QGen research is connecting with Formalized Requirements languages