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.

Efficient Evaluation of Embedded-System Design Alternatives (SPLC Tutorial 2019)

17 views

Published on

Tutorial presented by Maxime Cordy and Sami Lazreg at the 23rd System and Software Product Line Conference

Published in: Software
  • Be the first to comment

  • Be the first to like this

Efficient Evaluation of Embedded-System Design Alternatives (SPLC Tutorial 2019)

  1. 1. Efficient Evaluation of Embedded-System Design Alternatives Maxime Cordy, Sami Lazreg
  2. 2. Maxime Cordy Research Scientist at U. Luxembourg since 01/2019 (SerVal group, SnT centre) PhD from U. Namur (Belgium) in 2014 “Model Checking for the Masses” Start-up founder from 2015 to 2018 Sami Lazreg Freelance consultant in embedded systems since 07/2019 Embedded system engineer at Visteon Corporation from 2014 to 2019 Industrial PhD thesis at U. Côte d’Azur(France) since 2016 “Variability-Intensive Applications over Highly-Configurable Platforms: Early Feasibility and Optimality Analysis” (to be defended soon) Acknowledgement: Philippe Collet, Patrick Heymans, Sebastien Mosser, Axel Legay
  3. 3. Part I. Constrained Computing System Engineering
  4. 4. • The system must offer the required functionality to the users while its structure/behavior must meet various constraints. What is a Constrained Computing System? And other…
  5. 5. Hard Constrained Computing System • Computing Property • Functionality and timing, quality/precision • Safety/security/reliability • Run-time and energy consumption • Code size/footprint, Memory usage • Data/Processing bandwidth consumption • Weight/Dimensions, extreme temperatures • Manufacturing, ecological cost • etc… MUST MEET CONSTRAINTS TO FULLFILL CUSTOMER NEEDS
  6. 6. • Computing Property • Functionality and timing, quality/precision • Safety/security/reliability • Run-time and energy consumption • Code size/footprint, Memory usage • Data/Processing bandwidth consumption • Weight/Dimensions, computing temperatures • Manufacturing, ecological cost • etc… High Quality Computing System MUST OPTIMIZE OBJECTIVES TO BEST MEET CUSTOMER NEEDS
  7. 7. • Does it exist a system design/implementation that fulfill customer needs? • Functional requirements • Non-Functional requirements (constraints/optimizations) Computing System Design Engineering? System Requirements /specifications System Designs/Implementations
  8. 8. • YES/NO? • Time to find the most suitable design at early stage (time to market) • Relevance of the design/prototype and its documentation (trust/confidence) Computing System Design Engineering? System Requirements /specifications System Designs/Implementations
  9. 9. • Customer needs can be captured in multiple requirements/specifications alternatives. • Multiple business task/logic can be used to specify the requirements • Configurable or product line of system specifications • System specifications can be implemented in various design alternatives. • Business task/logic implemented on different processing units • Or synthesized by different specific hardware algorithms • Generally resulting in a concurrent system Difficulties in System Design Engineering
  10. 10. State of Practice • Prototyping/Intuition and experience X lack of confidence, opportunity miss X disagreements between engineers • Theoretical analyses X time consuming X not effective or completely wrong • Platform/System simulator X not always available X simulate many designs is time consuming NONE OF THESE METHODS CAN FORMALLY FIND THE MOST SUITABLE DESIGN IN BOTH • Reasonable time • Reasonable relevance
  11. 11. • Domain Specific Modeling Languages (capturing multiple specifications alternatives) • Operational Semantics = reasonable approximation of systems behaviors • Efficient analyses of design alternatives that capitalize over their commonalities (variability-aware) • Explainable report (system execution Proposed Method
  12. 12. • Improving RFI/RFQ process quality • Reduce Time to Market/Development cost • Find design optimization missed by competitors • Increasing relevance/confidence in the design of the solution (Align engineering teams) • But, could be limited (i.e., need knowledge about functional & non-functional) Practical Benefits
  13. 13. Part II. Model-Based Embedded-System Design Evaluation
  14. 14. Instruments Cluster
  15. 15. Instruments Cluster 4 ingredients : • 1. Application HMI Data-flow (Concurrent) • 2. Platform hardware components (non programmable) • 3. Mapping of Application over the Platform (also called Assignment / Implementation / Deployment) • 4. Scheduling: application execution over the platform ROM DCU Time to render a frame
  16. 16. Strong Requirements • Functional: render correctly the HMI application (without bugs, buffer overflows, deadlocks, etc.) • Non-functional (aka quality): graphic quality, time performance, manufacturing cost, … • Market: faster and better than competitors!
  17. 17. Strong Requirements • Functional requirements ü Map application over the platform ü Execute the application over the platform • Quality requirements ü Satisfy quality constraints • Manufacturing cost, quality … • Execution time, energy … ü Optimize the trade-off between the quality attributes
  18. 18. Strong Requirements • Functional requirements ü Map application over the platform è structural ü Execute the application over the platform è behavioral • Quality requirements ü Satisfy quality constraints • Manufacturing cost, quality … è structural • Execution time, energy … è behavioral ü Optimize the trade-off between the quality attributes
  19. 19. Engineering questions • Does my system design produce a proper rendering? • Can my system design be built under $20 while executing under 200 µs? • Is my system design optimal? Is there a better trade-off between graphic quality, cost and execution time?
  20. 20. State of Practice: Y-Chart RAM DCU Diagnoses
  21. 21. State of Practice : Y-Chart RAM GPU DCU Diagnoses Iteratively find the most suitable design! RAM GPU DCU RAM GPU DCU RAM GPU DCU RAM GPU DCU Academic & Industrial TOOLS • Cadence • Simulink • Scade • MetroII • Multicube • ForSyDe • Deadalus/Sesame • SystemCoDesigner • …
  22. 22. Application Model
  23. 23. Platform Model
  24. 24. Map/Deploy the Application onto the Platform Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  25. 25. Map/Deploy the Application onto the Platform Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  26. 26. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  27. 27. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  28. 28. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  29. 29. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  30. 30. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  31. 31. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  32. 32. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  33. 33. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  34. 34. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  35. 35. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  36. 36. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  37. 37. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  38. 38. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  39. 39. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  40. 40. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  41. 41. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  42. 42. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  43. 43. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  44. 44. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  45. 45. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  46. 46. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  47. 47. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  48. 48. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  49. 49. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  50. 50. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}
  51. 51. Simulate the Application Execution Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)} ROM DCU Time to render a frame
  52. 52. Mapping 1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 2 = {(d1,ROM), (a,dcu. a), (p2, dcu.r0), (d2, ROM), (c, dcu.c)} Mapping 3 = {(d1,ROM), (a,dcu. a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 4 = {(d1,ROM), (a, gpu.a), (p2, RAM), (d2, RAM), (c, dcu.c)} OK OK
  53. 53. Mapping 1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 2 = {(d1,ROM), (a,dcu. a), (p2, dcu.r0), (d2, ROM), (c, dcu.c)} Mapping 3 = {(d1,ROM), (a,dcu. a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 4 = {(d1,ROM), (a, gpu.a), (p2, RAM), (d2, RAM), (c, dcu.c)} OK OK ?
  54. 54. Mapping 1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 2 = {(d1,ROM), (a,dcu. a), (p2, dcu.r0), (d2, ROM), (c, dcu.c)} Mapping 3 = {(d1,ROM), (a,dcu. a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 4 = {(d1,ROM), (a, gpu.a), (p2, RAM), (d2, RAM), (c, dcu.c)} OK OK Behavioural constraint violated: DCU cannot write in RAM! KO
  55. 55. Mapping 1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 2 = {(d1,ROM), (a,dcu. a), (p2, dcu.r0), (d2, ROM), (c, dcu.c)} Mapping 3 = {(d1,ROM), (a,dcu. a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 4 = {(d1,ROM), (a, gpu.a), (p2, RAM), (d2, RAM), (c, dcu.c)} OK OK KO ?
  56. 56. Mapping 1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 2 = {(d1,ROM), (a,dcu. a), (p2, dcu.r0), (d2, ROM), (c, dcu.c)} Mapping 3 = {(d1,ROM), (a,dcu. a), (p2, RAM), (d2, ROM), (c, dcu.c)} Mapping 4 = {(d1,ROM), (a, gpu.a), (p2, RAM), (d2, RAM), (c, dcu.c)} OK OK KO 1024+512 Structural constraint violated: RAM capacity violated! KO size : 512B
  57. 57. Executable Model (Application)
  58. 58. Executable Model (Platform)
  59. 59. UPPAAL SIMULATION
  60. 60. Part III. The Many Design Alternatives
  61. 61. 7 HIGH VARIABILITY
  62. 62. High Variability • Into the Application • Image resolution (HD, WQVGA, …) • Alternatives data processing • rotate à scale OR scale à rotate, • optional/alternative tasks
  63. 63. Variability from Application App3 Quality 3, Data 2MB App2 Quality 0, Data 1MB App4 Quality 5, Data 3MB App1 Quality 3, Data 3MB
  64. 64. HIGH VARIABILITY!! 8 HIGH VARIABILITY
  65. 65. High Variability • Into the platform • Configurable component properties (storage capacity, processor frequencies …) • Optional components / alternatives architectures
  66. 66. Variability from Platform Platform1 Cost: 14.0$ Storage: 4MB Platform2 Cost:16.0$ Storage: 4,5MB Platform3 Cost: 30.0$ Storage: 5MB Platform4 Cost: 34.0$ Storage: 6MB
  67. 67. 9 HIGH VARIABILITY
  68. 68. High Variability • Into the mapping • Bind data to storage (RAM, ROM, Buffers, …) • Bind task to processors (DCU, GPU, …)
  69. 69. High Variability App1 Map1 over Plt 4:
  70. 70. High Variability App1 Map2 over Plt 4:
  71. 71. Engineering questions • Which system designs produce a proper rendering? • Which system designs can be built $20 while executing under 200 µs? • Which system designs optimize the trade-off between graphic quality, cost and execution time?
  72. 72. State of Practice: Y-Chart App 1 … N Platform 1 … M • Hundreds of application variants • Thousands of platform configurations • Millions of mappings Mapping 1 … K For each p in Platforms For each a in Applications For each m in Mappings(a,p) if (isValid(Execution(a,m,p))) put(valid, (a,p,m))
  73. 73. State of Practice: Y-Chart App 1 … N Platform 1 … M Mapping 1 … K RAM GPU DCU RAM GPU DCU RAM GPU DCU RAM GPU DCU RAM GPU DCU
  74. 74. A Multifaceted Problem • Feasibility/satisfiability and optimality • Functional and non-functional requirements • Structure and behaviour
  75. 75. Part IV. Methods and Tools
  76. 76. Mindshift: Variability Awareness • System design share commonalities • same/similar constituents • same executions • Iterative Y-chart works system-by-system • Go for a variability-aware analysis • reasons in terms of constituting units (features) • binds execution to groups of system
  77. 77. Mindshift: Variability Awareness
  78. 78. Mindshift: Variability Awareness
  79. 79. Mindshift: Variability Awareness 79
  80. 80. Tool Chain Priced Feature Model, Featured Weighted Automata Variability- Aware Mapping (Section V) Variability-Intensive Design Space Contributions on expressiveness Non-Functional Constraints and Cost Function Generation of executable models (Section VI) Variability-Aware Cost Optimal Model Checking (Section VII) Contributions on reasoning power Extensions and novel applications of existing back-ends  Execution traces Optimal variants Variable Platform Variable Application
  81. 81. Variable System Design App 1 … N Configurable Platform Variable Application Variable Application D1 D2 A B rend. quality+2 C sizes : 256,512,1024KB rend. quality:+0,+1,+2 P1 P2 P3 size : 512KB D P4 Task Data Path path  split/joinLegend
  82. 82. Variable System Design App 1 … N Configurable Platform Variable Application Variable Application D1 D2 A B rend. quality+2 C sizes : 256,512,1024KB rend. quality:+0,+1,+2 P1 P2 P3 size : 512KB D P4 Task Data Path path  split/joinLegend
  83. 83. Variability System Design App 1 … N Configurable Platform Resource interconnection size: 4096KB cost: 60 4 bytes per cycles 2 latency cycles freq: 100, 200 GPU needs RAM A 4bpc C 8bpc R0 B 2bpc A 8bpc R0 ROMRAM D 4bpcR1 D 16bpc size: 512,1024, 2048KB cost: 20, 40, 80 8 bytes per cycles 2 latency cycles freq: 100, 200 cost: 80 freq: 100 cost: 120 freq: 100,200 DCU GPU Function Memory Storage Buffer optional Legend Processor Platform 1 … M
  84. 84. Priced Feature Model, Featured Weighted Automata Variability- Aware Mapping (Section V) Variability-Intensive Design Space Contributions on expressiveness Non-Functional Constraints and Cost Function Generation of executable models (Section VI) Variability-Aware Cost Optimal Model Checking (Section VII) Contributions on reasoning power Extensions and novel applications of existing back-ends  Execution traces Optimal variants Variable Platform Variable Application Tool Chain
  85. 85. Resource interconnection size: 4096KB cost: 60 4 bytes per cycles 2 latency cycles freq: 100, 200 GPU needs RAM A 4bpc C 8bpc R0 B 2bpc A 8bpc R0 ROMRAM D 4bpcR1 D 16bpc size: 512,1024, 2048KB cost: 20, 40, 80 8 bytes per cycles 2 latency cycles freq: 100, 200 cost: 80 freq: 100 cost: 120 freq: 100,200 DCU GPU Function Memory Storage Buffer optional Legend Processor Variability-Aware Mapping D1 D2 A B rend. quality+2 C sizes : 256,512,1024KB rend. quality:+0,+1,+2 P1 P2 P3 size : 512KB D P4 Task Data Path path  split/joinLegend Mappings to Mappings Rules: A on DCU => D1 on (RAM or ROM) && P2 on DCU_R0 A on GPU => D1 on (RAM or ROM) && P2 on RAM B on GPU => D1 on (RAM or ROM) && P2 on RAM … Application Mappings Rules A <=> (A on DCU or A on GPU) B <=> B on GPU … Platform mappings Rules D1 on RAM or D2 on RAM => RAM B on GPU => GPU …
  86. 86. Priced Feature Model, Featured Weighted Automata Variability- Aware Mapping (Section V) Variability-Intensive Design Space Contributions on expressiveness Non-Functional Constraints and Cost Function Generation of executable models (Section VI) Variability-Aware Cost Optimal Model Checking (Section VII) Contributions on reasoning power Extensions and novel applications of existing back-ends  Execution traces Optimal variants Variable Platform Variable Application Tool Chain
  87. 87. Structure of Design Space D1 D2 A B rend. quality+2 C sizes : 256,512,1024KB rend. quality:+0,+1,+2 P1 P2 P3 size : 512KB D P4 Task Data Path path  split/joinLegend Resource interconnection size: 4096KB cost: 60 4 bytes per cycles 2 latency cycles freq: 100, 200 GPU needs RAM A 4bpc C 8bpc R0 B 2bpc A 8bpc R0 ROMRAM D 4bpcR1 D 16bpc size: 512,1024, 2048KB cost: 20, 40, 80 8 bytes per cycles 2 latency cycles freq: 100, 200 cost: 80 freq: 100 cost: 120 freq: 100,200 DCU GPU Function Memory Storage Buffer optional Legend Processor Priced feature model (excerpt)
  88. 88. Behavior of Design Space Memory RAM Processor GPUInput Data D2 Task A 26 D1 D2 A B rend. quality+2 C sizes : 256,512,1024KB rend. quality:+0,+1,+2 P1 P2 P3 size : 512KB D P4 Task Data Path path  split/joinLegend Resource interconnection size: 4096KB cost: 60 4 bytes per cycles 2 latency cycles freq: 100, 200 GPU needs RAM A 4bpc C 8bpc R0 B 2bpc A 8bpc R0 ROMRAM D 4bpcR1 D 16bpc size: 512,1024, 2048KB cost: 20, 40, 80 8 bytes per cycles 2 latency cycles freq: 100, 200 cost: 80 freq: 100 cost: 120 freq: 100,200 DCU GPU Function Memory Storage Buffer optional Legend Processor Featured weighted automata (f)Promela active proctype storage_SoC_RAM(){ gd :: f.SoC_RAM -> int freq; int bpc = 8; int latency =0; int _delay = 0; data in; gd :: f.SoC_RAM_frequency_100 -> freq = 100; :: f.SoC_RAM_frequency_200 -> freq = 200; dg; _delay = (latency*main_freq/freq) +(burst/bpc*main_freq/freq); do :: transfer[SoC_RAM_ID]?in -> soc_ram_idle = false; wait(_delay) then skip; soc_ram_idle = true; od; dg; }
  89. 89. Priced Feature Model, Featured Weighted Automata Variability- Aware Mapping (Section V) Variability-Intensive Design Space Contributions on expressiveness Non-Functional Constraints and Cost Function Generation of executable models (Section VI) Variability-Aware Cost Optimal Model Checking (Section VII) Contributions on reasoning power Extensions and novel applications of existing back-ends  Execution traces Optimal variants Variable Platform Variable Application Tool Chain
  90. 90. Mapping Variant Fct. Req. Non Fct. Req Optimum Scheduling Trace Verification “All In One” Variability-Aware Model Checking Mapping Variant Fct. Req. Non Fct. Req Optimum Scheduling Trace Functional • Overflow! • Deadlock! Non Functional • Exec. Time • Manuf. Cost Simple question : What are the designs that can produces this bad behavior? Simple answer : The designs that try to allocate a D2 of 1024KB on a RAM of 512KB && &&D2_SIZE_1024 RAM_CAP_512 D2_On_RAM Simple action : Discard all designs that could contains this feature combination
  91. 91. Verification “All In One” Mapping Variant Fct. Req. Non Fct. Req Optimum Scheduling Trace D2_SIZE_1024 RAM_CAP_512 D2_On_RAM Non Functional • Exec. Time RAM_CAP_1024 Do we visit the state with new designs? Yes: continue No: stop Are the new designs/executions better? Yes: continue No: stop
  92. 92. Verification “All In One” Contraintes NF : Quality >= 2 Cost <= 180 Time <= 512
  93. 93. Verification “All In One” RAM GPU DCU RAM GPU DCU RAM GPU DCU RAM GPU DCU RAM GPU DCU RAM GPU DCU execution traces (task/memory scheduling) corresponding designs satisfiability/optimality D2_SIZE_1024 RAM_CAP_512 D2_On_RAM RAM_CAP_1024D2_SIZE_1024 D2_On_RAM D2_SIZE_1024 D2_On_ROM D2_On_RAM D2_SIZE_512 D2_On_ROM ROM_FRE_100 D2_SIZE_512 ROM_FRE_200 D2_On_ROM D2_SIZE_512 best trade-off cheapest fastest
  94. 94. Part V. Evaluation
  95. 95. Research Questions 1. Can our method help engineers build the right design? 2. Can we check structural requirements only? 3. To what extent is variability-aware verification more efficient than design-by-design analysis?
  96. 96. RQ1: Qualitative Evaluation • Reverse-engineered a problematic instrument cluster module from 2016 • 1.548.288 potential designs • 1.878 valid mappings • 894 satisfying structural req. • 279 satisfying all requirements • 6 optima • The design implemented by Visteon design is one of the 6 found by the tool chain! • Slight differences in execution time (< 10%), relative ordering is preserved
  97. 97. Quantitative Evaluation • Dataset: instrument cluster case study (#0) + 11 models generated randomly based on Visteon historical statistics • Tools: • ProVeLines with variability-aware heuristics (late splitting and early joining) • ProVeLines without heuristics (= system by system) • ClaferMOO (structural optimization) • Hardware: MacBook Pro 2014 with a 2,8 GHz Intel Core i7 processor and 16 GB of DDR3 RAM.
  98. 98. RQ2: checking structural requirements only
  99. 99. RQ3: Variability-aware vs. design by design
  100. 100. Takeaway
  101. 101. Takeaway • Embedded system design is an interesting playground for behavioural variability analysis • At design level, exactitude can be sacrificed for practical utility • Full-fledged applications are way larger
  102. 102. THANK YOU maxime.cordy@uni.lu lazreg@i3s.unice.com • Lazreg et al. Multifaceted automated analyses for variability-intensive embedded systems. ICSE ‘19. • Cordy et al. Towards sampling and simulation-based analysis of featured weighted automata. FormaliSE@ICSE ‘19. • Lazreg et al. Assessing the functional feasibility of variability-intensive data flow-oriented systems. SAC ‘18.

×