Abstract

Complex software-intensive systems are increasingly relied upon for all kinds of activities in society, leading to the requirement that these systems should be resilient to changes that may occur to the system, its environment, or its goals. Traditionally, resilience has been achieved either through: (i) low-level mechanisms embedded in the implementation (e.g., exception handling, timeouts, redundancies), which are unable to detect subtle but important anomalies (e.g., progressive performance degradation); or (ii) human oversight, which is costly and unreliable. Architecture-based self-adaptation (ABSA) is regarded as a promising approach to improve the resilience and reduce the development/operation costs of such systems. Although researchers have illustrated the benefits of ABSA through a number of small-scale case studies, it remains to be seen whether ABSA is truly effective in handling changes at run-time in industrial-scale systems. In this paper, we report on our experience applying an ABSA framework (Rainbow) to a large-scale commercial software system, called Data Acquisition and Control Service (DCAS), which is used to monitor and manage highly populated networks of devices in renewable energy production plants. In the approach followed, we have replaced some of the existing adaptive mechanisms embedded in DCAS by those advocated by ABSA proponents. This has allowed us to assess the development costs associated with the reengineering of adaptive mechanisms when using an ABSA solution, and to make effective comparisons, in terms of operational performance, between a baseline industrial system and one that uses ABSA. Our results show that using the ABSA concepts as embodied in Rainbow enabled an independent team of developers to: (i) effectively implement the adaptation behavior required from such industrial systems; and (ii) obtain important benefits in terms of maintainability and extensibility of adaptation mechanisms.

Highlights

  • The increasing reliance on software systems to carry out virtually all activities in society has led to the requirement that these systems be resilient in face of internal faults, changing resources, varying loads, and even changing usage re5 quirements

  • 75 uations in which devices are persistently slow in reporting data – and assessed the difficulty of modifying adaptation behavior using architecture-based selfadaptation (ABSA) in Rainbow-Data Acquisition and Control Service (DCAS); (iii) we investigated the use of ABSA to automate some adaptations that in the original DCAS were handled by human oversight – a scale-out adaptation mechanism that allows the system to extended with new

  • During our experience in developing Rainbow-DCAS, we observed that architecturebased self-adaptation (ABSA) can successfully replicate the adaptation behavior required from an industrial-class software-based system such as DCAS

Read more

Summary

Introduction

The increasing reliance on software systems to carry out virtually all activities in society has led to the requirement that these systems be resilient in face of internal faults, changing resources, varying loads, and even changing usage re quirements. The primary goal in DCAS is providing service while maintaining acceptable levels of performance, measured in terms of processed data requests per second (rps) inserted in the database, while the secondary goal is optimizing the computational cost of operating the system, measured in number of active processes (called 145 Data Requester Processor Pollers or DRPPs – introduced in Section 2.1.1) in the processor nodes To achieve these quality goals, a DCAS-based system shall be able to scale-up, making use of the computational resources in the node(s) where the middleware is running, and scale-out, supporting the deployment of several instances of the middleware across different processor nodes within the 150 same system to extend the number of connected devices. This information is internally used by the polling scheduler to adjust the generation rate of requests for data from devices

Write Item
The Data Requester:
The Service Engine:
The Data Requester
One of the DRPPs in the DRP dequeues the request from the Secondary
Adaptation Mechanisms
Rescheduling
Scale-out
The Rainbow Approach
Implementing ABSA Mechanisms in DCAS
Re-implementation of Scale-up and Rescheduling
655 5. Evaluation
Lessons Learned
Threats to Validity
990 8. Related Work
Conclusions
1085 References

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.