© ABB Group February 21, 2011 | Slide 1TowardsSoftware Sustainability Guidelines for Long-living Industrial SystemsHeiko Koziolek, Roland Weiss, Zoya Durdik, Johannes Stammel, Klaus Krogmann
Context: Industrial Automation DomainLong-living Software-Intensive Systems© ABB Group February 21, 2011 | Slide 2
Context: Software EvolutionExample Release History of a Process Control System© ABB Group February 21, 2011 | Slide 3Version 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 MelodyFoundation  Fieldbus, Redundant Profibus, HARTVersion C3 Windows 7 supportAlarm Analysis and Alarm ShelvingWirelessHART IntegrationProfinet, Ethernet IP, DeviceNetEngineering efficiency improvementsDetailed difference reportingFoundation Fieldbus improvements2004	2005	2006	2007	2008	2009	2010Version C1 Multi-system IntegrationSPI Integration (PETI) MODBUS TCPVersion BIncreased system sizeSIL 2 Integrated SafetyConnectivity for DCI and MOD 300 Alarm and Event ImprovementsRemote Clients via MS Terminal ServicesVersion C2Virtualization supportMS WPF GraphicsSIL3 SafetyIEC 61850 (Intel Elect Devices)New PM866 controller (2x PM864)New S800 I/O (non-red HART)New Power Supplies, smaller footprintEvolution Libraries MOD300 and Infi90Version COnline Upgrade CapabilityMulti-User / Distributed EngineeringLarge screen / Multi-screen enhancementsDigital Security Improvements
ChallengesSustainable Software Development© ABB Group February 21, 2011 | Slide 4Limited education of architects and developers for sustainable developmentSignificant costs for software maintenance and evolutionRepeating evolution problems and solutions
Our approach© ABB Group February 21, 2011 | Slide 51. Document re-occuring evolution scenarios in the industrial domain2. Create guidelines for sustainable software developmentScenario 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 ABCName:  ... Relevance: ...  Application effort: ... Short Description: ... Tools: ... Risks: ... Checklist: ...Method ABCName:  ... Relevance: ...  Application effort: ... Short Description: ... Tools: ... Risks: ... Checklist: ...Method ABC Name:  ... Relevance: ...  Application effort: ...Short Description: ... Tools: ...Risks: ...Checklist: ...3. Validation C1C2C3
Re-occurring evolution scenariosIndustrial software systemsPerfectivenew services and featuresintegration of third party componentsintegration of third party applicationssafety certification (IEC61508)performance improvements (I/Os)usability improvements (workplace)security improvements (Stuxnet)...© ABB Group February 21, 2011 | Slide 6Adaptivenew industry standardsmigration to new GUI frameworkmigration to new middleware / OSsupport for virtualizationsupport for multi-core processorsupdated controller and field devicesnew network standards...
Sustainability GuidelinesDevelopment Process© ABB Group February 21, 2011 | Slide 7
SourcesJournals: IEEE TSE, JSME, JSS, EMSE, LNCS, IST, ...Conferences: ICSE, ICSM, IWPSE, CSMR, WICSA, ...Interviews, > 30 Books, Internal ABB documents, ...Keywordsagility 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, evaluationData Collectiondevelopment phase, relevance automation, relevance sustainability, applicability, tool, preventive/reactive, formalization, perspective, abstraction level, benefits for sustainable software developmentSustainability GuidelinesLiterature ReviewReviewed Topics (Selection)Software Comprehension using Historical DataQuality IndicatorsSoftware Architecture (Analysis)Variability StrategiesAutomation of Software DevelopmentKnowledge Management and DocumentationSoftware InfrastructureConclusionsWide solutions overview (136 pages)Reference list in each chapterBaseline for sustainability guidelinesNot all approaches investigated in detail© ABB Group February 21, 2011 | Slide 8
Initial Sustainability GuidelinesOverview© ABB Group February 21, 2011 | Slide 9Phase IndependentSustainable Documentation, Knowledge Management, Process Improvement, Organizational Structures, ...
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 supportWhy 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 modifiabilitySelection of non-relevant change scenario might lead to modifiability overheadHigh overall effort for involving too many stakeholders or due to inefficient execution of the ALMA processApplication 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 studiesABB internal validation: n/a© ABB Group February 21, 2011 | Slide 10
Validation (1/3)GoalsValidate the usability of the guidelinesinterview developersapply in three post-mortem case studiesapply initially in regular projectsValidate the applicability of the recommended methodsonly possible for selected methodsconduct case study research, collect best practicesreuse empirical studies from literature© ABB Group February 21, 2011 | Slide 11
Validation (2/3)Mapping the Guidelines to a Sample Scenario© ABB Group February 21, 2011 | Slide 12
Validation (3/3)Planned Case Studies1. Apply ALMA to compare two software architectures2. Apply code analysis 	3. Recover design rationale on third party component	from architectural document.© ABB Group February 21, 2011 | Slide 13
ConclusionsSustainability Guidelines for Long-living SystemsMaintenance 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
© ABB Group February 21, 2011 | Slide 15

Towards Software Sustainability Guides for Industrial Software Systems

  • 1.
    © ABB GroupFebruary 21, 2011 | Slide 1TowardsSoftware Sustainability Guidelines for Long-living Industrial SystemsHeiko Koziolek, Roland Weiss, Zoya Durdik, Johannes Stammel, Klaus Krogmann
  • 2.
    Context: Industrial AutomationDomainLong-living Software-Intensive Systems© ABB Group February 21, 2011 | Slide 2
  • 3.
    Context: Software EvolutionExampleRelease History of a Process Control System© ABB Group February 21, 2011 | Slide 3Version 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 MelodyFoundation Fieldbus, Redundant Profibus, HARTVersion C3 Windows 7 supportAlarm Analysis and Alarm ShelvingWirelessHART IntegrationProfinet, Ethernet IP, DeviceNetEngineering efficiency improvementsDetailed difference reportingFoundation Fieldbus improvements2004 2005 2006 2007 2008 2009 2010Version C1 Multi-system IntegrationSPI Integration (PETI) MODBUS TCPVersion BIncreased system sizeSIL 2 Integrated SafetyConnectivity for DCI and MOD 300 Alarm and Event ImprovementsRemote Clients via MS Terminal ServicesVersion C2Virtualization supportMS WPF GraphicsSIL3 SafetyIEC 61850 (Intel Elect Devices)New PM866 controller (2x PM864)New S800 I/O (non-red HART)New Power Supplies, smaller footprintEvolution Libraries MOD300 and Infi90Version COnline Upgrade CapabilityMulti-User / Distributed EngineeringLarge screen / Multi-screen enhancementsDigital Security Improvements
  • 4.
    ChallengesSustainable Software Development©ABB Group February 21, 2011 | Slide 4Limited education of architects and developers for sustainable developmentSignificant costs for software maintenance and evolutionRepeating evolution problems and solutions
  • 5.
    Our approach© ABBGroup February 21, 2011 | Slide 51. Document re-occuring evolution scenarios in the industrial domain2. Create guidelines for sustainable software developmentScenario 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 ABCName: ... Relevance: ... Application effort: ... Short Description: ... Tools: ... Risks: ... Checklist: ...Method ABCName: ... Relevance: ... Application effort: ... Short Description: ... Tools: ... Risks: ... Checklist: ...Method ABC Name: ... Relevance: ... Application effort: ...Short Description: ... Tools: ...Risks: ...Checklist: ...3. Validation C1C2C3
  • 6.
    Re-occurring evolution scenariosIndustrialsoftware systemsPerfectivenew services and featuresintegration of third party componentsintegration of third party applicationssafety certification (IEC61508)performance improvements (I/Os)usability improvements (workplace)security improvements (Stuxnet)...© ABB Group February 21, 2011 | Slide 6Adaptivenew industry standardsmigration to new GUI frameworkmigration to new middleware / OSsupport for virtualizationsupport for multi-core processorsupdated controller and field devicesnew network standards...
  • 7.
    Sustainability GuidelinesDevelopment Process©ABB Group February 21, 2011 | Slide 7
  • 8.
    SourcesJournals: IEEE TSE,JSME, JSS, EMSE, LNCS, IST, ...Conferences: ICSE, ICSM, IWPSE, CSMR, WICSA, ...Interviews, > 30 Books, Internal ABB documents, ...Keywordsagility 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, evaluationData Collectiondevelopment phase, relevance automation, relevance sustainability, applicability, tool, preventive/reactive, formalization, perspective, abstraction level, benefits for sustainable software developmentSustainability GuidelinesLiterature ReviewReviewed Topics (Selection)Software Comprehension using Historical DataQuality IndicatorsSoftware Architecture (Analysis)Variability StrategiesAutomation of Software DevelopmentKnowledge Management and DocumentationSoftware InfrastructureConclusionsWide solutions overview (136 pages)Reference list in each chapterBaseline for sustainability guidelinesNot all approaches investigated in detail© ABB Group February 21, 2011 | Slide 8
  • 9.
    Initial Sustainability GuidelinesOverview©ABB Group February 21, 2011 | Slide 9Phase 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 supportWhy 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 modifiabilitySelection of non-relevant change scenario might lead to modifiability overheadHigh overall effort for involving too many stakeholders or due to inefficient execution of the ALMA processApplication 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 studiesABB internal validation: n/a© ABB Group February 21, 2011 | Slide 10
  • 11.
    Validation (1/3)GoalsValidate theusability of the guidelinesinterview developersapply in three post-mortem case studiesapply initially in regular projectsValidate the applicability of the recommended methodsonly possible for selected methodsconduct case study research, collect best practicesreuse empirical studies from literature© ABB Group February 21, 2011 | Slide 11
  • 12.
    Validation (2/3)Mapping theGuidelines to a Sample Scenario© ABB Group February 21, 2011 | Slide 12
  • 13.
    Validation (3/3)Planned CaseStudies1. Apply ALMA to compare two software architectures2. Apply code analysis 3. Recover design rationale on third party component from architectural document.© ABB Group February 21, 2011 | Slide 13
  • 14.
    ConclusionsSustainability Guidelines forLong-living SystemsMaintenance 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 GroupFebruary 21, 2011 | Slide 15

Editor's Notes

  • #3 industrial automation domainprocess control systemssoftware-intensive systemslong life cycles, more than 15 years, up to 40 years
  • #4 many changes to a software product after releaseperfective: new features, new devices, ...adaptive: technologies become obsolete must be replacedcorrective: bug reportssoftware development mainly focussed on the phases after release
  • #5 high percentage of overall development costs = maintenance costssame evolution problems for different products, patterns and tactics as solutionsustainable development not taught at universities, also sometimes sacrifies due to timing constraints, time-to-market pressure
  • #6 Validation:map methods to scenarios3 case studiesdeveloper feedback
  • #7 just as overview, need to be documented in detail using templatescorrective and preventive scenario are omitted here for brevity
  • #9 - this slide is not to be read in detail, just to provide some information about the literature search
  • #10 structure of the guidelines aligned with ABB software development guidelines structuredoes not imply waterfall process, merely an orientation to the reader
  • #11 - one short example for a detailled guide line, should give general idea of the content of the document