1. 1 Context-dependent Product Line Practice for Constructing Reliable Embedded Systems Naoyasu UbayashiKyushu University, Japan Shin NakajimaNational Institute of Informatics, Japan Masayuki HirayamaIPA/Software Engineering Center, Japan September 15, 2010 SPLC 2010

2. Contexts in embedded systems  Many embedded systems not only affect their contexts through actuators but also are affected by their contexts through sensors.  However, traditional PLE is mainly conducted from the viewpoint of system functions, and contexts are only roughly analyzed. 2 Unexpected behavior might emerge in a system if a developer does not recognize any possible conflicting combinations between the system and contexts. Embedded System Actuator Sensor Contexts

3. Our proposal CD-PLP (context-dependent product line practice with lightweight formal approaches)  We propose a new style of PLE that focuses on constructing embedded systems that take into account the contexts. 3 CD-PLP Described in VDM++ A configuration can be formally checked!

4. 4 Outline 1. Motivation 2. Context-dependent PLE 3. Modeling and validation using VDM++ 4. Related work 5. Conclusion

5. 1. MOTIVATION 5

6. 6 Example: an electric pot water level sensor heater thermistor liquid context system pot The pot controls the water temperature by turning on or off the heater. The pot changes its mode to the heat- retaining mode when the temperature becomes 100 Celsius. The pot observes the volume from the water level.

7. 7 Requirement specification process in traditional PLE Step 1: Analyze features: Boil: () ==> () Boil() == while thermistor.GetTemperature() <= 100.0 do heater.On(); Step2: Select a set of features Step 3: Validate a composed system specification specification Controller Heater Thermistor Water level sensor The pot with the Boil function behaves correctly under the normal circumstances. However, faults may occur if the expected contexts are changed. --- for example, the circumstance of the low air pressure The boiling point of the water is below 100 Celsius. The controller continues to heat the water. As a result, its volume will be empty.

8. Problems in traditional PLE  It is not easy to reuse the specifications because the system logic tends to be specified by implicitly assuming the expected contexts.  It is not easy to validate a product specification as a whole because certain unexpected system behavior might emerge due to the conflict between the system and the contexts. 8 Boil: () ==> () Boil() == while thermistor.GetTemperature() <= 100.0 do heater.On(); System: pot Context: the circumstance of the low air pressure Conflict !

9. Our approach CD-PLP (context-dependent product line practice with lightweight formal approaches)  A product line is explicitly separated into two kinds of lines --the system line and the context line.  The specification of each feature is accumulated as a core asset.  These specifications are described in VDM++.  A configuration can be validated using VDM Tools. 9 Assets (VDM++) Validated (VDM Tools)

10. 2. CONTEXT-DEPENDENT PLE 10

11. Activities in context-dependent PLE  Core asset development System asset development Context asset development  Product development Definition of product configuration Definition of expected contexts Validation of overall specifications 11

12. Core asset development: system line and context line 12 How to model contexts ? How to extract context assets ?

13. Frame problem  It is difficult to decide the boundary of contexts that should be taken into account: which contexts should be included as the targets of requirements analysis. 13 Embedded System Actuator Sensor Contexts Boundary ? Association ? Frame Problem !

14. Context modeling 14 UML profile for context analysis Steps for exploring boundary 1.Context elements (value object) observed or controlled directly by a sensor or an actuator are extracted. 2.Impact factors that affect the states (values) of these context elements are extracted using guide words. Initial Boundary Sensor cannot observe original data Factor related to a specific value Contexts that do not change the values are ignored ! The frame problem is avoided ! Contexts that do not change the values are ignored ! The frame problem is avoided ! Final Boundary Factor that determines the upper limit

15. 3. MODELING AND VALIDATION USING VDM++ 15

16. Core asset development using VDM++ 16

17. 17 VDM++ Specification class Software instance variables heater : Heater; thermostat : Thermostat; liquid_level_sensor : LiquidLevelSensor; operations public Setup: RealWorld ==> () Setup(realworld) == (heater := new Heater(); heater.Setup(realworld); thermostat := new Thermostat(); thermostat.Setup(realworld); liquid_level_sensor := new LiquidLevelSensor(); liquid_level_sensor.Setup(realworld); ); public Boil: () ==> () Boil() == while thermostat.GetTemperature() <= 100.0 and liquid_level_sensor.IsOn() = true do heater.On() pre liquid_level_sensor.IsOn() = true post liquid_level_sensor.IsOn() = true; end Software Constraints From user requirements (water should not be empty) From user requirements (water should not be empty)

18. 18 Product development using VDMTools Specification can be validated by VDM++ test execution System Specification Context A Context B Normal Air pressure CONTEXT-atmospheric-air-pressureplace- normal CONTEXT-liquid-water Low Air Pressure CONTEXT-atmospheric-air-pressureplace- low CONTEXT-liquid-water [Step1] Define product configuration: [Step2] Define expected contexts: [Step3] Validate overall specifications:

19. Results of test execution 19 Error ! We must reconsider whether air pressure should be included in the expected contexts.

20. Requirements refinement 20 water level sensor heater thermistor Liquid context system pot Air Pressure Boundary Out of ScopeReconsider Hardware Requirements Fixed to 1.0 ATM Model-based testing based on lightweight formal methods is effective for exploring context boundary and refining requirements.

21. 4. RELATED WORK 21

22. Related work  Context modeling Introduction of real world knowledge into requirement specifications [Greenspan 82] Problem frame [Jackson 2001] We introduced the notion of contexts not only in individual products but also in product lines.  Contexts in PLE Four layer (capability, operating environment, domain technology, implementation technique) [Kang 98] Usage context Our proposal is a systematic approach to the context-dependent PLE. 22

23. 5. CONCLUSION 23

24. Conclusion  Context-dependent PLE  Lightweight validation using VDMTools 24 Assets (VDM++) VDMTools Validate Explore a context boundary

25. 25 Thank you for your attention.

26. Future work  In problem frames, relations between a machine (a system to be developed) and the real-world are explicitly described.  We are now exploring the possibility of integrating our approach with problem frames.  We found that there was the similarity between our UML profile and frame patterns. 26

27. Context analysis with problem frames 27 Trace Controller （ TC ） AA Body （ BD ） Line Trace C a: TC! { Right, Left} BD! { Line detected, Linemissed} b: LP! { On, Off} c: LC! { Ground Color} d: LS! { Reflected Light} r: BD! { Run, Return to Course} r b Control Machine Controlled Domain Required Behavior AA Light Sensor （ LS ） X Line recognition Controller (LC) AA Line Position （ LP ） X Transformation Machine Output Input Required Behavior Frame Transformation Frame c a d On if ground color is black