1 / 93

Transformation based assessment of dependability

Transformation based assessment of dependability. András Pataricza Budapest University of Technology and Economics pataric@mit.bme.hu. Focus. Technology background. Challenges. Measurement and extraction. Completeness consistency. Mobile, ad-hoc, large scale. Complexity?. SOA.

doyle
Download Presentation

Transformation based assessment of dependability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Transformation based assessment of dependability András Pataricza Budapest University of Technology and Economics pataric@mit.bme.hu

  2. Focus

  3. Technology background

  4. Challenges Measurement and extraction Completeness consistency Mobile, ad-hoc, large scale Complexity? SOA Fault modelling, testing Benchmarking, data processing Design fortrust Specification Parameterization Transformation Optimization Design modell Simulation Partitioning Verification Scheduling Communicationsynthesis Behavioral model Hardware synthesis Software synthesis Implementation & testing

  5. Dependability vs. design correctness

  6. Automation vs. QoS

  7. Feasibility objectives and constraints

  8. Cost estimation PLATFORM Platform volatility Execution time Main storage PRODUCT SW reliability Documentation Database size Product complexity Reusability COCOMO II. PERSONNEL Personnel continuity Application experience Analyst capability Programmer capability Language & tool exp. PROJECT Development schedule SW tools Multi-site development Extra low Very low Low Nominal High Very high Extra high

  9. Factor analysis

  10. MDA MDA Cost impact estimate Req. anal. Design Implementation Effort (PM) 100% 42% 11% 7% Formal analysis

  11. Quality improvement estimate EN5012x for railway interlocking systems SIL-4 11 6 2.5 0.25

  12. Basic approach to dependability What are the general challenges imposed by dependabilityrequirements?

  13. Impairments (IFIP WG10.4)

  14. Faults

  15. Fault model – origin of misfunctioning Automated generation Good/faulty models Faults

  16. Errors – propgation along the states

  17. Failures – observable deviance

  18. Attributes of dependability

  19. Methods of dependability assurance

  20. Basic differences • The (formal) analysis has to focus on: • Modeling of faults • Error propagation (shared resources) • Failure modes

  21. Schedulabilty profile

  22. RT modeling: Common framework, different techniques Timeliness, performance, and schedulability Two levels in modeling: target design - full model platform - resource model Application – platform interactions General Resource Model: resources + QoS attributes GRM objectives

  23. Domain models and profiles

  24. Resource usage Further: resource protection and management

  25. Managing complexity in dependability analysis Model size=original x fault modes ??

  26. Problem Specific metamodel (e.g fault mechanism) Problem specific metamodel Problem Specific metamodel (e.g fault mechanism) T T T Faulty mutations Extended models Faulty mutations Faulty mutations Extended models Extended models Dependabilty modeling • Type of the fault • Security • HW defect • SW design • Confidentiality • … System model Uniformization of methodology and tools for all aspects needed

  27. Evaluation objectives • UML (or other) mathematical models • Assessment of fault impacts: • Fault: general rule to generate mutations • Error propagation derived from behavioral specification • Proof of robustness • Quantitative reliability/availability analysis • Availability aware code generation • Generation of reconfiguration rules • Security analysis • Authentication: Bell-la Padula

  28. Main idea (borrowed from AI)

  29. Abstraction: qualitative modeling • Formal methods have strict complexity limitations • Efficient, but faithful abstractions are needed • Qualitative abstraction: • A few of qualitative values out of an enumerated data type set • No detailed data representation • Drastic state space (analysis complexity) reduction • Systematic methodology: predicate abstraction

  30. Example Full model: rich (continuous) data domain Full model: IF credit_requested < 2.000.000 THEN approval(director) ELSE approval(board) Qualitative model with control flow preservation: IF minor_credit_requested THEN approval(director) ELSE approval(board) Non-deterministic model: CHOOSE ( approval (director), approval (board) ) Predicate abstraction: Only a single binary value- operation domains Nondeterministic abstraction: Random choice, control flow saved

  31. Predicate abstraction (0,1) successors?

  32. Predicate abstraction

  33. Predicate abstraction and CSP

  34. Application to dependability analysis Problems: Fault modeling Error propagation analysis Failure assessment

  35. Fault (meta-)model s-a-x derived from the technology The old days Faulty model instance Functional/structural model

  36. Fault modeling • Fault mechanisms: known at the metamodel level • Example: communication • Behavior • Structural level

  37. Fault modeling by transformations message Original component O1 O2 Substitution (graph transformation) good O1 O2 omission x Extended component corrupted Fault mode Value err

  38. Extended model

  39. Objectives of VIATRA • VIATRA = VIsual Automated model TRAnsformations • a general-purpose model transformation engineering (transware) framework • support of the entire life-cycle for transformations • specification • design • execution • validation • maintenance • within and between various modeling languages

  40. The VIATRA 2.0 framework Eclipse VIATRA 2.0 Model Transformation Plug-in Source metamodel Xform. rules (UML/QVT) Target metamodel Source model Xform Target model Native tool Native model Native XForm Plugin Native target model

  41. Graph transformation: typed components + interconnections Next :next :Cell :Cell LHS+RHS (“reader”) :val :Int :this :this LHS, not RHS (“eraser”) :x :x RHS, not LHS (“creator”) :Append :Append :control :caller :control NAC (“embargo”) :next :next :Cell :Cell :Cell :Cell :val :Int :Int :this :this :this :x Next :x :x :Append :Append :Append :control :caller :control + control structures (ASM)

  42. Application to error propagation Abstract models vs. derivation from engineering models

  43. Composite error propagation model Complexity ?

  44. Qualitative component models • Dynamic by spatial abstraction: error propagation automaton • Same description paradigm, as the original one • Same set of states • Domain restricted to error modes • Static by subsequent temporal abstraction:errorsensitivity combinations • Input-output syndrome relations • Common features • Drastic complexity reduction (domain restricted to error modes) • False alarms possible, but no dangerous case is lost • Automated derivation from the functional model

  45. Qualitative abstraction - spatial Actual Actual Error values Good Spatial compressor Faulty Reference Reference

  46. Qualitative abstraction - error types Actual Actual Out of range Good Good Spatial compressor Minor deviance Out of range Minor deviance Major deviance Major deviance Reference Reference

  47. Metamodeling and qualitativeabstraction

  48. Qualitative error propagation model: (bounded) model checking 122, 256, 311…. good, major, minor…. 122, 666, 312….

  49. Error propagation as CSP

  50. Failures

More Related