Talk from DFF 2011 workshop at SE 2011.

1. © ABB Group February 21, 2011 | Slide 1 TowardsSoftware Sustainability Guidelines for Long-living Industrial Systems Heiko Koziolek, Roland Weiss, Zoya Durdik, Johannes Stammel, Klaus Krogmann

2. Context: Industrial Automation DomainLong-living Software-Intensive Systems © ABB Group February 21, 2011 | Slide 2

3. Context: Software EvolutionExample Release History of a Process Control System © ABB Group February 21, 2011 | Slide 3 Version A First version release with complete system concept Single environment from independent solutions Outstanding Operations Offering Function based Engineering Redundant Controllers and I/O capabilities Connectivity for Harmony and Melody Foundation Fieldbus, Redundant Profibus, HART Version C3 Windows 7 support Alarm Analysis and Alarm Shelving WirelessHART Integration Profinet, Ethernet IP, DeviceNet Engineering efficiency improvements Detailed difference reporting Foundation Fieldbus improvements 2004 2005 2006 2007 2008 2009 2010 Version C1 Multi-system Integration SPI Integration (PETI) MODBUS TCP Version B Increased system size SIL 2 Integrated Safety Connectivity for DCI and MOD 300 Alarm and Event Improvements Remote Clients via MS Terminal Services Version C2 Virtualization support MS WPF Graphics SIL3 Safety IEC 61850 (Intel Elect Devices) New PM866 controller (2x PM864) New S800 I/O (non-red HART) New Power Supplies, smaller footprint Evolution Libraries MOD300 and Infi90 Version C Online Upgrade Capability Multi-User / Distributed Engineering Large screen / Multi-screen enhancements Digital Security Improvements

4. ChallengesSustainable Software Development © ABB Group February 21, 2011 | Slide 4 Limited education of architects and developers for sustainable development Significant costs for software maintenance and evolution Repeating evolution problems and solutions

5. Our approach © ABB Group February 21, 2011 | Slide 5 1. Document re-occuring evolution scenarios in the industrial domain 2. Create guidelines for sustainable software development Scenario XYZ Overview: Data volume exceeds, ... System environment: Normal volume: 1.5 GB, ... Environment changes: Volume changed to 4 GB, ... Required system behaviour: Processing takes less than 4 hours, ... Scenario XYZ Overview: Data volume exceeds, ... System environment: Normal volume: 1.5 GB, ... Environment changes: Volume changed to 4 GB, ... Required system behaviour: Processing takes less than 4 hours, ... Scenario XYZ Overview: Data volume exceeds, ... System environment: Normal data volume: 1.5 GB, ... Environment changes: Datavolume changes to 4 GB, ... Required system behaviour: Processing takes less than 4 hours, ... Method ABC Name: ... Relevance: ... Application effort: ... Short Description: ... Tools: ... Risks: ... Checklist: ... Method ABC Name: ... Relevance: ... Application effort: ... Short Description: ... Tools: ... Risks: ... Checklist: ... Method ABC Name: ... Relevance: ... Application effort: ... Short Description: ... Tools: ... Risks: ... Checklist: ... 3. Validation C1 C2 C3

6. Re-occurring evolution scenariosIndustrial software systems Perfective new services and features integration of third party components integration of third party applications safety certification (IEC61508) performance improvements (I/Os) usability improvements (workplace) security improvements (Stuxnet) ... © ABB Group February 21, 2011 | Slide 6 Adaptive new industry standards migration to new GUI framework migration to new middleware / OS support for virtualization support for multi-core processors updated controller and field devices new network standards ...

7. Sustainability GuidelinesDevelopment Process © ABB Group February 21, 2011 | Slide 7

8. Sources Journals: IEEE TSE, JSME, JSS, EMSE, LNCS, IST, ... Conferences: ICSE, ICSM, IWPSE, CSMR, WICSA, ... Interviews, > 30 Books, Internal ABB documents, ... Keywords agility and architecture, software evolution, strategies, strategy, tactic(s), method(s), approach software maintenance,maintainability, evolvability, longevity, modifiability, flexibility, sustainability, COTS, (data) mining, virtualization, software quality, architecture compliance checking, architecture analysis, code and architecture consistency, architecture(al) enforcements, survey, evaluation Data Collection development phase, relevance automation, relevance sustainability, applicability, tool, preventive/reactive, formalization, perspective, abstraction level, benefits for sustainable software development Sustainability GuidelinesLiterature Review Reviewed Topics (Selection) Software Comprehension using Historical Data Quality Indicators Software Architecture (Analysis) Variability Strategies Automation of Software Development Knowledge Management and Documentation Software Infrastructure Conclusions Wide solutions overview (136 pages) Reference list in each chapter Baseline for sustainability guidelines Not all approaches investigated in detail © ABB Group February 21, 2011 | Slide 8

9. Initial Sustainability GuidelinesOverview © ABB Group February 21, 2011 | Slide 9 Phase IndependentSustainable Documentation, Knowledge Management, Process Improvement, Organizational Structures, ...

10. Sustainability Guidelines ExampleALMA (Architecture-Level Modifiability Analysis) Short Description: Architecture-level modifiability analysis (ALMA) is an analysis approach that focuses on modifiability. For the description of the architecture, an architectural model, i.e., views from several architectural viewpoints have to be created. Change scenario elicitation is done by interviewing stakeholders. … Tool Support: no tool support Why useful? (selection) Helps to estimate long-term impact of design decisions. Quantifies the expected costs of changes to a system pro-actively to support decisions during system evolution. Improves the initial design upfront to avoid maintenance and evolution problems. Risks (selection) Missing critical change scenarios can lead to missing modifiability Selection of non-relevant change scenario might lead to modifiability overhead High overall effort for involving too many stakeholders or due to inefficient execution of the ALMA process Application effort: (medium, manual) Relevance for evolution: The approach can help identifying evolution risks, i.e. changes that can only be performed at high costs. Learning effort: Medium (requires architecture modelling skills and knowledge about modifiability) Addressed problem: The architecture has influence on architecture level. Ensures that critical change scenarios are well-supported by an architecture. General validation: 7 industrial case studies ABB internal validation: n/a © ABB Group February 21, 2011 | Slide 10

11. Validation (1/3)Goals Validate the usability of the guidelines interview developers apply in three post-mortem case studies apply initially in regular projects Validate the applicability of the recommended methods only possible for selected methods conduct case study research, collect best practices reuse empirical studies from literature © ABB Group February 21, 2011 | Slide 11

12. Validation (2/3)Mapping the Guidelines to a Sample Scenario © ABB Group February 21, 2011 | Slide 12

13. Validation (3/3)Planned Case Studies 1. Apply ALMA to compare two software architectures 2. Apply code analysis 3. Recover design rationale on third party component from architectural document. © ABB Group February 21, 2011 | Slide 13

14. ConclusionsSustainability Guidelines for Long-living Systems Maintenance and evolution of industrial software systems are significant cost drivers. Software sustainability guidelines help architects and developers in avoiding and mitigating evolution problems. Further validation is needed in interviews and case studies. © ABB Group February 21, 2011 | Slide 14

15. © ABB Group February 21, 2011 | Slide 15