Migrating Automotive Product Lines: a Case Study

1. Migrating Automotive Product Lines: a Case Study 1 Michalis Famelis, Levi Lúcio, Gehan Selim, Alessio Di Sandro, Rick Salay, Marsha Chechik, James R Cordy, Jürgen Dingel, Hans Vangheluwe, and Ramesh S

2. 2 Introduction • Modern cars (in particular) at GM typically contain tens of millions of lines of code, often synthesized from models • Powertrain control, active and passive safety features, climate control, comfort and convenience systems, security systems, entertainment systems, and middleware to interconnect all of the above. • High variability: over 60 car models, further variation for 150+ markets • Variation points depend on brand, model, region of sale, sensing/actuating • Number of product variants (i.e, size of the product family): low tens of thousands

3. 3 Migrating models:GM VCS to AUTOSAR [ECMFA12] GmToAutosar AUTOSAR model GM VCS model DSLTrans

4. Obfuscated 4 Migrating models:GM VCS to AUTOSAR in DSLTrans

5. 5 Migrating models:GM VCS to AUTOSAR in DSLTrans [SLE10] [MoDELS10]

6. Transformation proved to be correct with the SyVOLT contract prover! 6 Migrating models:GM VCS to AUTOSAR [ICGT14] GmToAutosar AUTOSAR model GM VCS model DSLTrans

7. Does lifting of industrial-size product lines scale? ↑ GmToAutosar Reinterpretationof GmToAutosar semantics. Requires lifting the transformation engine 7 [ICMT15] Migrating entire Product Families Product family of AUTOSAR models Product family of GM VCS models

8. 8 Migrating a family of models:GM VCS to AUTOSAR

9. 9 [ICSE14] Lifting Transformations Applies to any transformation that uses the same subset of the DSLTrans language as GmToAutosar.

10. 10 Lifting DSLTrans Lifted Relevant Parts of the Transformation Engine For a rule, at a specific match site: • Use a SAT solver (Z3) to check whether the rule is applicable to at least one product at that site; • Modify the domain model of the product line (i.e., apply the rule); • Modify the presence conditions of the changed domain model so the rule effect only occurs in applicable products. Changes required an addition of less than 300 lines of code to an existing codebase of 9250 lines (the DSLTrans transformation engine).

11. 11 Correctness [ICSE14] Applying lifted transformation T to product family A produces a product family B. That is exactly as if we had applied T to each product of family A and merged the results into a new product family B. (No products added, no products lost, each product transformed as in per product transformation.) Lifting preserves: • Confluence • Termination • Pre-post conditions

12. Does lifting of industrial-size product lines scale? GM- product lines 12 Applying to GM-sized Product Lines RQ1: Does GmToAutosar↑ scale to the needs of GM? RQ2: How does it scale with increasing product line complexity? Total runtime Complexity of presence conditions (clause-to-variable ratio)

13. Does lifting of industrial-size product lines scale? Realistic GM-like product lines Non-GM seed exemplar (due to IP) Artificially created inputs Threats to validity: 13 Applying to GM-sized Product Lines RQ1: Does GmToAutosar↑ scale to the needs of GM? RQ2: How does it scale with increasing product line complexity? a) Size of model b) Number of features Seed exemplar based on public models Total runtime Complexity of presence conditions (clause-to-variable ratio) GM feedback (parameters and validation)

14. SPL of requirements for exterior lighting system: 24 features, 400 elements 14 Experiments RQ1: Does GmToAutosar↑ scale to industrial-sized SPLs? Result: • Transform one product: 3.25 seconds • Transform all products (tens of thousands): 3.59 seconds • Huge increase in clause-to-variable-ratio: 0.08 to 293.53 No formula simplifications (yet) Implementation will have to balance runtime and formulasimplification

15. Runtime 15 Experiments RQ2: Does it scale with increasing product line complexity? • Almost linear increase with increasing domain model size • SPLs with more features take longer Number of model elements (log scale, base 2)

16. Runtime 16 Experiments RQ2: Does it scale with increasing product line complexity? • For large number of features, time seems not to be affected

17. Complexity of presence conditions Growth 17 Experiments RQ2: Does it scale with increasing product line complexity? • Almost exponential growth of presence conditions • Presence conditions of SPLs with fewer features grow faster Clauses to Variables ratio (log scale, base 10) Number of model elements (log scale, base 2)

18. Post-publication: Initial results using just naïve optimization give~75% reduction in presence condition size 18 Experiments RQ2: Does it scale with increasing product line complexity? Runtime Complexity of presence conditions Optimization balance Almost linear Almost exponential

19. Lifting is industrially relevant! And industrially scalable [ICSE14] Adapt engine, reuse transformations Did not lift: Existential match Indirect links NACs 19 Lessons Learned from GmToAutosar Experience lifting (part of) a transformation engine Confirmed previous claims DSLTrans based on graph rewriting Individual productions are atomic

20. 20 Next Steps • Lift all of DSLTrans: • Existential matching • Indirect link matching • NACs • Lift more complex transformation languages (possibly by mapping onto DSLTrans)

21. 21 Big(ger)Picture [MoDELS10] [MoDELS15] [SLE10] [ICMT15]

23. 23 References • [ECMFA12]”Model Transformations for Migrating Legacy Models: An Industrial Case Study”. Gehan M. K. Selim, Shige Wang, James R. Cordy and Jürgen Dingel. • [SLE10] “DSLTrans: A Turing Incomplete Transformation Language”, Levi Lúcio, Vasco Amaral, Roberto Félix, Vasco Sousa. • [MoDELS10] “A Technique for Automatic Validation of Model Transformations”, Levi Lúcio, Bruno Barroca, Vasco Amaral. • [ICGT14] “Specification and Verification of Graph-Based Model Transformation Properties”, Gehan M. K. Selim, Levi Lúcio, James R. Cordy, Jürgen Dingel and Bentley J. Oakes. • [ICSE14]”Lifting model transformations to product lines”, Rick Salay, Michalis Famelis, Julia Rubin, Alessio Di Sandro and Marsha Chechik. • [MoDELS15]“Fully Verifying Transformation Contracts for Declarative ATL”, Bentley J. Oakes, Javier Troya, Levi Lúcio, and Manuel Wimmer.

24. 24