Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Incremental Queries and Transformations for Engineering Critical Systems


Published on

Invited talk @NJSZT Software Technology Forum 2015.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Incremental Queries and Transformations for Engineering Critical Systems

  1. 1. Budapest University of Technology and Economics Department of Measurement and Information Systems INCREMENTAL QUERIES AND TRANSFORMATIONS FOR ENGINEERING CRITICAL SYSTEMS Ákos Horváth, István Ráth Budapest University of Technology and Economics Fault Tolerant Systems Research Group
  2. 2. Outline of the Talk Model transformations in Critical Systems Engineering EMF-IncQuery and VIATRA: Incremental Queries and Transformations Industrial applications • Avionics, automotive, telecom, cloud Conclusions  Main Contributors o István Ráth o Ákos Horváth o Gábor Bergmann o Ábel Hegedüs o Zoltán Ujhelyi o Dániel Varró o ... and many more!
  4. 4. Development Process for Critical Systems Unique Development Process (Traditional V-Model) Critical Systems Design  requires a certification process  to develop justified evidence  that the system is free of flaws Software Tool Qualification  obtain certification credit  for a software tool  used in critical system design Qualified Tool  Certified Output DO-178B IEC 61508 Innovative Tool  Better System
  5. 5. Model-Driven Engineering of Critical Systems Traditional V-Model Model-Driven Engineering Main ideas of MDE • early validation of system models • automatic source code generation  quality++ tools ++ development cost-- • DO-178B/C: Software Considerations in Airborne Systems and Equipment Certification (RTCA, EUROCAE) • Steven P. Miller: Certification Issues in Model Based Development (Rockwell Collins)
  6. 6. Models and Transformations in Critical Systems System Design Model Architecture Design Model Component Design Model Refine Refine Design + V&V Artifacts (Source code, Glue code, Config. Tables, Test Cases, Monitors, Fault Trees, etc.) Code & Test Generation VerticalModelTransformations Component V&V Model Architecture V&V Model System V&V Model Model generation Back-Annotation Model generation Back-Annotation Model generation Back-Annotation Use Use Horizontal Model Transformations Formal methods Formal methods Design rules Design rules Design rules End-to-End Traceability End-to-EndTraceability Model Transformations • knowledge transfer: theoretical resultstools • bridge / integrate existing languages&tools Related projects • CESAR, SAVI, … • HIDE, DECOS, DIANA, MOGENTES, CERTIMOT, GENESYS, SENSORIA
  7. 7. Open Source Projects  Incremental query engine o Declarative language o Incremental, live queries o Highly scalable  Easy integration o On-the-fly validation o Derived features o Custom views o Traceability  Model transformation framework o Event-based + reactive execution platform o Internal DSL over Xtend o Scalable M2M & M2T  High-level features o Complex event processing o Design space exploration o Incremental transform. EMF-IncQuery VIATRA Official Eclipse member 2 Project leads 10 Eclipse committers Tool integration with: Papyrus UML, Sirius, RMF, Capella, ARTOP, mbeddr
  8. 8. • Declarative graph query language • Transitive closure, Negative cond., etc. • Compositional, reusable Definition • Incremental evaluation • Cache result set • Maintain incrementally upon model change Execution • Derived features, • On-the-fly validation • View generation, Notifications, Soft links, Databinding, Features EMF-IncQuery: An Open Source Eclipse Project
  9. 9. The IncQuery (IQ) Graph Query Language  IQ: declarative query language o Attribute constraints o Local + global queries o Compositionality+Reusabilility o Recursion, Negation, o Transitive Closure o Syntax: DATALOG style pattern routeSensor(sensor: Sensor) = { TrackElement.sensor(switch,sensor); Switch(switch); SwitchPosition. switch(sp, switch); SwitchPosition(sp); Route.switchPosition(route, sp); Route(route); neg find head(route, sensor); } pattern head(R, Sen) = { Route.routeDefinition(R, Sen); } route: Route sp: SwitchPosition Switch: Switchsensor: Sensor switchPosition switch sensor routeDefinition Query(A,B)  ∧condi(Ai,Bi) • all tuples of model elements a,b • satisfying the query condition • along the match A=a and B=b • parameters A,B can be input/ output
  10. 10. EMF-INCQUERY Architecture Transaction In-memory EMF model Rete net Indexer layer EMF-INCQUERY Indexing In-memory storage Production network • Stores intermediate query results • Propagates changes
  11. 11. Performance of EMF-INCQUERY  Incremental graph queries based on Rete  Models in the Eclipse Modeling Framework model size runtime batch queries incremental queries Exec. time is proportional to the size of the modification. Largest synthetic model (TrainBenchmark) • 2.8 million nodes • 11.2 million edges • revalidation time: 1 ms Largest real model (Eclipse 4.0 source code) • 8.6M nodes+26.2M edges • revalidation: <20 ms (except for 1 query)
  12. 12. Motivation: General Tooling Challenges  Interference between functions  Commonalities o Queries, rules, scheduling, conflicts User interaction (modify) SRC TRG Batch/Incremental transformation Traceability links Live validation Live views Derived features
  13. 13. Reactive Event Driven Transformations 1. First transformation 2. Source model changes 4. Fire rule activations (in relevant context) SRC1 SRC2 TRG1TRACE1 TRG2TRACE2 3. Detect new activations Pros: • Source incremental: driven by changes of query result • Chaining • Avoids continuous comp. Cons: • Language-level restrictions
  14. 14. Reactive Event Driven Transformations VIATRA: Reactive Transformation Engine Observed events Controlled events Actions What has changed? When to react? Perform in consistent state
  15. 15. Reactive Event Driven Transformations VIATRA: Reactive Transformation Engine Observed events Controlled events Actions • Model modified • Match appeared • Event sequence identified • „Run” button pushed • Consistent state reached after editing • Transaction committed • Modify model • Add error marker • Update view • Send e-mail
  16. 16. VIATRA: Overview of Features •Explore design model candidates •Satisfying multiple criteria •Rule based exploration •Optimization Design Space Exploration •Detect complex event sequences •Rule based reaction •Xtext based language Complex Event Processing •Remove sensitive information from confidential models •Original model  Obfuscated model Model Obfuscator  Reactive MT Platform o MT Language: • Internal DSL over Xtend • Transformation API o MT Engine: • Event-driven virtual machine • Batch + Incremental MTs • Control flow library • Compiles to Java • Debugger • High performance o Integrations: • EMF, IncQuery, Xtend, EMF-UML, …
  18. 18. Relevant application projects AUTOSAR (ThyssenKrupp Presta, etc.) •Support standard defined well-formedness rules •On-the-fly validation •Scale to large AUTOSAR models TRANS-IMA (Embraer) •Eclipse based development tooling •HW-SW allocation: avionics architecture •Integration to the distributed Embraer simulator •(1st time in Europe) EMDW (Ericsson) •Executable (UML) modeling •Incremental code generation to C++ •Multiple execution platform support •Model interpretation (ELTESoft) MONDO (EU FP7) •Modeling in the cloud •Scaling out MDE technologies •Collaborative modeling and version control •Access control •Model obfuscation
  19. 19. AUTOSAR- Early validation of design rules SystemSignalGroup design rule (from AUTOSAR) o A SystemSignal and its group must be in the same IPdu o Challenge: find violations quickly in large models o New difficulties • reverse navigation • complex manual solution AUTOSAR: • standardized SW architecture of the automotive industry • now supported by modern modeling tools Design Rule/Well-formedness constraint: • each valid car architecture needs to respect • designers are immediately notified if violated Challenge: • >500 design rules in AUTOSAR tools • >1 million elements in AUTOSAR models • models constantly evolve by designers
  20. 20. TRANS-IMA – HW-SW allocation and simulation Goal: Allocate SW components to ARINC653 compliant IMA platform 20 Functional Architecture Platform description Component database Allocation Integrated System Model
  21. 21. TRANS-IMA – HW-SW allocation and simulation Functional Architecture Platform description Component database Allocation Integrated System Model Inputs: • Platform Independent Model (PIM) (functional + nonfunc. reqs; Simulink) • Platform Description Model (PDM) for ARINC 653 (DSML) Output: • Integrated system model • Ready for simulation  Matlab Simulink • End-to-end traceability
  22. 22. Capture constraints Explore alternatives Human decision Automate consequences Functional Architecture Platform description Component database Allocation Integrated System Model Model transformation chains: • Designer-guided manual steps • Automated steps • Communication channels calculation • Integrated architecture model generation • Continuous validation of design rules TRANS-IMA – HW-SW allocation and simulation
  23. 23. EMDW – Executable Modeling Executable UML Modeling: • Class models with state machines • Components for modularization • High-level action language - rAlf Target • Ericsson core network servers • Optimized C++ and Java source code Challenges: • >short roundtrip (generate and compile) • >large models (complete 4G radio system)
  24. 24. EMDW – Executable modeling EMDW-MC Cpp EMF-UML xUML-RT Cpp rAlf C++ source Editor Model Execution and Compilation E M D W - M E Platform config Input: • Papyrus EMF-UML specification Output: • Optimized C++ and configuration Transformation: • Complex transformation chain • Incremental execution • Workflow based execution mechanism • Text-to-model transformations Integration: • One-way incremental synchronization • On-the-fly execution Model Execution: • Incremental Java generation
  25. 25. Scalable MDE: The MONDO Project Models and Languages • Large and heterogeneous • Construction • Visualization Queries and Transformations • Executed over large models • Incremental • Lazy • Parallel Collaboration • Offline (SVN) • Online (Gdocs) • Many collaborators • Secure access Persistent Storage • Efficient • Secure • Interoperability GOALS: • Scale to model sizes >100M elements Prototype tools: • open source software • open benchmarks Academic Partners: • Univ. York (UK) Univ. Autónoma Madrid (ES), ARMINES (FR), BME (HU) Industrial Partners: • The Open Group (UK), Uninova (PT), Softeam (FR), Soft-Maint (FR), IKERLAN (ES)
  26. 26. MONDO: From EMF-INCQUERY to INCQUERY-D Transaction In-memory EMF model Rete net Indexer layer EMF-INCQUERY Indexing In-memory storage Production network • Stores intermediate query results • Propagates changes
  27. 27. Database shard 0 MONDO: INCQUERY-D Architecture Server 1 Database shard 1 Server 2 Database shard 2 Server 3 Database shard 3 Transaction Server 0 Rete net Indexer layer INCQUERY-D Distributed query evaluation network Distributed indexer Model access adapter Distributed indexing, notification Distributed persistent storage Distributed production network • Each intermediate node can be allocated to a different host • Remote internode communication
  28. 28. MONDO: Collaborative Modeling View for HW Supplier1 View for SW Provider2 View for SW Provider1 Version Control System1 Integrated System Model Write-through access control checked by storage Write restrictions by property-based locks (at client) Secured views with filtered and obfuscated model
  30. 30. Conclusions •Find design candidates •Rules for operations •Queries for constraints •Hints and guidance •Potentially infinite state space Design Space Exploration •Connect to Matlab Simulink model •Export: Matlab2EMF •Change model in EMF •Re-import: EMF2Matlab •Library handling MASSIF: MATLAB-EMF Bridge •Runtime detection / verification •Live models (refreshed at very fast rate: 25 frame/sec) • E.g. gesture recognition, tracking Complex Event Processing •Provide simpified graphical views for complex models •Forward incremental view maintenance •Chaining of views •Sirius integration View Maintenance •Queries for validation •Complex model transformation chain •Extensibility •Virtual models (by derived objects) •Soft traceability links Tools •Itemis (developer) •Ericsson •Embraer, Thales •CERN, CEA •ThyssenKrupp, •Tools: ARTOP, Capella, Papyrus, RMF, mbeddr Known Users