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