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

1. Efficient Evaluation of
Embedded-System Design Alternatives
Maxime Cordy, Sami Lazreg

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. Part I.
Constrained
Computing System
Engineering

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. 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. • 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. • 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. • 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. • 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. 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. • 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. • 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. Part II.
Model-Based
Embedded-System
Design Evaluation

14. Instruments Cluster

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. 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. 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. 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. 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. State of Practice: Y-Chart
RAM
DCU
Diagnoses

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. Application Model

23. Platform Model

24. Map/Deploy the Application
onto the Platform
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

25. Map/Deploy the Application
onto the Platform
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

26. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

27. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

28. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

29. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

30. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

31. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

32. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

33. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

34. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

35. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

36. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

37. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

38. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

39. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

40. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

41. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

42. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

43. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

44. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

45. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

46. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

47. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

48. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

49. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

50. Simulate the Application Execution
Mapping1 = {(d1,RAM), (a, gpu.a), (p2, RAM), (d2, ROM), (c, dcu.c)}

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. 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. 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. 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. 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. 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. Executable Model
(Application)

58. Executable Model (Platform)

59. UPPAAL SIMULATION

60. Part III.
The Many Design
Alternatives

61. 7
HIGH
VARIABILITY

62. High Variability
• Into the Application
• Image resolution (HD, WQVGA, …)
• Alternatives data processing
• rotate à scale OR scale à rotate,
• optional/alternative tasks

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. HIGH
VARIABILITY!!
8
HIGH
VARIABILITY

65. High Variability
• Into the platform
• Configurable component properties
(storage capacity, processor frequencies …)
• Optional components / alternatives
architectures

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. 9
HIGH
VARIABILITY

68. High Variability
• Into the mapping
• Bind data to storage (RAM, ROM, Buffers, …)
• Bind task to processors (DCU, GPU, …)

69. High Variability
App1 Map1 over Plt 4:

70. High Variability
App1 Map2 over Plt 4:

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. 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. 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. A Multifaceted Problem
• Feasibility/satisfiability and optimality
• Functional and non-functional requirements
• Structure and behaviour

75. Part IV.
Methods and Tools

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. Mindshift: Variability Awareness

78. Mindshift: Variability Awareness

79. Mindshift: Variability Awareness
79

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Verification “All In One”
Contraintes NF :
Quality >= 2
Cost <= 180
Time <= 512

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. Part V.
Evaluation

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. 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. 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. RQ2: checking structural
requirements only

99. RQ3: Variability-aware vs.
design by design

100. Takeaway

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. 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.