Source-linked AI summary

Using Models at Runtime to Address Assurance for Self-Adaptive Systems

Betty Cheng, Kerstin Eder, Martin Gogolla, Lars Grunske, Marin Litoiu, Hausi Müller, Patrizio Pelliccione, Anna Perini, Nauman Qureshi, Bernhard Rumpe, Daniel Schneider, Frank Trollmann, Norha Villegas

arXiv:1505.00903v1cs.SE

TL;DR

Self-adaptive systems must satisfy requirements despite runtime changes, making assurance beyond development time a central challenge. This chapter surveys models at runtime as a foundation for runtime assurance and develops a research agenda. It concludes that runtime assurance offers significant opportunities, while certifiable trust for highly adaptive systems remains a formidable challenge.

  • Problem

    Self-adaptive systems need to maintain required properties through adaptation and changing conditions, so assurance tasks must extend beyond development time.

    Source: §1 · p. 2
  • Method

    The chapter develops a research agenda for runtime assurance grounded in M@RT, drawing on discussions from a 2011 Dagstuhl seminar and subsequent author discussions.

    Source: §7 · p. 25
  • Results

    The chapter concludes that runtime assurance offers significant opportunities, while certifiable trust for highly adaptive systems remains a formidable research challenge.

    Source: §7 · p. 26
  • Takeaways & Limitations

    The authors identify M@RT as a key enabling technology and call for communities to collaborate on SAS assurance for high-assurance application domains.

    Source: §7 · p. 26

Abstract

from arXiv · show

A self-adaptive software system modifies its behavior at runtime in response to changes within the system or in its execution environment. The fulfillment of the system requirements needs to be guaranteed even in the presence of adverse conditions and adaptations. Thus, a key challenge for self-adaptive software systems is assurance. Traditionally, confidence in the correctness of a system is gained through a variety of activities and processes performed at development time, such as design analysis and testing. In the presence of selfadaptation, however, some of the assurance tasks may need to be performed at runtime. This need calls for the development of techniques that enable continuous assurance throughout the software life cycle. Fundamental to the development of runtime assurance techniques is research into the use of models at runtime (M@RT). This chapter explores the state of the art for usingM@RT to address the assurance of self-adaptive software systems. It defines what information can be captured by M@RT, specifically for the purpose of assurance, and puts this definition into the context of existing work. We then outline key research challenges for assurance at runtime and characterize assurance methods. The chapter concludes with an exploration of selected application areas where M@RT could provide significant benefits beyond existing assurance techniques for adaptive systems.

1 Introduction

Self-adaptation makes assurance a runtime concern because requirements must continue to hold through changing conditions and adaptations. The chapter presents models at runtime (M@RT) as a foundation for continuous assurance and outlines the chapter’s scope.

1 Introduction

  • Unlike non-adaptive systems, whose assurance is typically performed at design and development time, SASs need assurance tasks at runtime and across the software life cycle.The chapter identifies verification, validation, testing, measurement, standards conformance, and certification as assurance activities.Source: §1 · pp. 2–3
  • Requirements for functional and non-functional properties must hold before, during, and after adaptation, despite uncertainty in the system and its environment.Assurance must cover both the target system and the adaptation process.Source: §1 · p. 3
  • Runtime assurance can benefit from variables becoming bound during execution, which narrows the state space for runtime verification and validation.The chapter identifies monitoring, analysis, guarantees, and prediction of system properties as opportunities of continuous assurance.Source: §1 · p. 3
  • The chapter presents M@RT as a foundation for SAS assurance, reviews assurance criteria and models, identifies research challenges, characterizes methods, and discusses selected application areas.It also distinguishes software assurance from software quality assurance to include safety, reliability, and security concerns.Source: §1 · pp. 2–3

2 Assurance Criteria for Self-Adaptive Software Systems

Assurance criteria for self-adaptive systems include requirements affected by adaptation, for both the target system and the adaptation process. The section discusses functional requirements and non-functional properties, including how runtime assessment relates to quality attributes and adaptation properties.

2 Assurance Criteria for Self-Adaptive Software Systems

  • Assurance criteria cover functional and non-functional requirements affected by self-adaptation, and apply both to the target system and to the adaptation process.Target-system criteria concern current or potential future states; adaptation-process criteria concern the adaptation itself.Source: §2 · p. 3

2.1 Functional Requirements

  • Functional requirements specify system behavior at its boundaries by relating inputs to expected outputs, while leaving implementation choices open.The section limits its discussion to formal descriptions, noting that natural-language requirements can be ambiguous.Source: §2.1 · p. 4
  • Adaptation may respond either to environmental changes while retaining functional behavior or to changed user or configuration needs by changing behavior.Functional requirements can account for context and assumptions; assume/guarantee specifications express conditions under which required properties are guaranteed.Source: §2.1 · p. 4

2.2 Non-functional Requirements

  • Non-functional requirements describe properties of the function, its inputs or outputs, or their relationships, including performance, dependability, safety, and security.Their quality attributes can concern either the target system or the adaptation mechanism.Source: §2.2 · p. 5
  • Non-functional requirements need continual monitoring on both the target system and adaptation process because context changes or adaptation side effects can invalidate desired properties.Adaptation properties such as stability, accuracy, settling time, and robustness can help assess effects on target-system properties.Source: §2.2 · pp. 5–6
  • Runtime criteria can be mapped to quality attributes and adaptation properties, with the measurement location depending on the property and its assessment metric.For example, settling time is measured on the target system; relevant mappings also depend on the system, implementation, and adaptations.Source: §2.2 · pp. 6–7, Table 1 · p. 6

3 Models at Runtime

The chapter treats models at runtime (M@RT) as abstractions for assuring self-adaptive systems across system aspects and life-cycle phases. It describes models for three interacting levels of system dynamics and extends the MAPE-K loop into a MAPE-MART loop with assurance activities.

3 Models at Runtime

  • M@RT encompasses models of application aspects and life-cycle phases, combined with instrumentation to monitor, analyze, guarantee, and predict system properties during operation.The aspects include requirements, design, implementation, infrastructure, instrumentation, and context of use.Source: §3 · p. 7
  • Runtime models can be classified by purpose, modeling language, and the aspects they describe.Purposes include predictive, prescriptive, constructive, and descriptive; described aspects include data, process state, I/O behavior, and interactions.Source: §3 · p. 7
  • A causal connection synchronizes models and the running system, allowing models either to reflect system changes or to cause adaptations.Descriptive connections support analysis of abstract models; prescriptive connections can implement adaptations intended to assure properties.Source: §3 · p. 7

3.1 M@RT and the Dynamics of Self-Adaptive Software

  • M@RT abstractions support feedback loops at three levels: control objectives, adaptation, and monitoring.The chapter proposes dedicated models for the control objectives manager, adaptation controller, and monitoring system.Source: §3.1 · p. 8, Figure 1 · p. 9
  • Models at the control-objectives level represent assurance requirements; adaptation models represent system states and plans; monitoring models represent context, monitoring requirements, and strategies.Changes at one level can require changes at others, and adaptation and monitoring models must explicitly map to control-objectives models.Source: §3.1 · p. 9

3.2 Models at Runtime during the Adaptation Process

  • The MAPE-MART loop extends MAPE-K by replacing its knowledge base with M@RT and adding assurance tasks alongside each adaptation stage.Monitors supply context; analyzers identify potential violations; planners form and check plans; executors adapt the system and check its safety and desired properties.Source: §3.2 · pp. 10–11, Figure 2 · p. 10

4 Research Challenges for Assurance at Runtime

Runtime assurance for self-adaptive systems draws on models to manage uncertainty and support assurance across system operation. The chapter identifies open challenges in model quality, monitoring, lifecycle methods, and adapting assurance to changing requirements and domains.

4.1 Research Avenues

  • M@RT can serve as a reference for feedback-based uncertainty management, with runtime evidence gathered by checking system conformance to the model.The chapter calls for connecting lessons from biology, control engineering, and software engineering to practical applications.Source: §4.1 · pp. 11–12
  • Existing runtime models range from control-centric to architecture-centric, leaving their relative benefits and synergies open for comparison and evaluation.The chapter also points to certifiable trust as a major challenge amid opportunities from integrating sensors, networks, cloud computing, and control.Source: §4.1 · pp. 11–12

4.2 Selected Research Challenges

  • Monitoring must make measured properties usable for assurance, yet relatively few approaches support requirements, assumptions, and changing environmental conditions.The criteria and adaptation properties matter only when they can be measured.Source: §4.2 · p. 12
  • Runtime assurance models must represent uncertainty, support trade-offs among quality criteria, and be evaluated for properties such as accuracy, performance, and safety.The chapter also notes that performance modeling is comparatively advanced, while quantifying criteria such as trust is difficult.Source: §4.2 · p. 13
  • Assurance methods must determine which development-time tasks and models can move to runtime, while retaining substantial assurance work at development time.The chapter asks which lightweight techniques and descriptive, prescriptive, constructive, and predictive methods can extend across the life cycle.Source: §4.2 · pp. 13–14
  • M@RT should support changes to monitoring, analysis, planning, and execution as requirements or execution environments change, across differing levels of system dynamics.The chapter also asks how runtime assurance techniques should be characterized by changes to context, requirements, adaptation mechanisms, and the target system.Source: §4.2 · p. 14
  • Runtime assurance criteria and techniques need classification by application domain and by the kinds of runtime changes they address.For example, safety-critical systems and service-oriented systems have distinct assurance models and obligations.Source: §4.2 · p. 14
  • Assurance can be decomposed into local component properties or separated functional and adaptation checks, but dependencies can prevent local properties from holding globally.AMOEBA uses assume/guarantee reasoning for incremental model checking; AMOEBA-RT monitors adaptation properties at runtime using state-based models of adaptive logic.Source: §4.2 · p. 15

5 Characterizing Assurance Methods

The chapter surveys selected runtime assurance approaches and classifies them by realization techniques and non-functional criteria. It presents the overview as a starting point for addressing research challenges, not as a comprehensive systematic review.

5.1 Classifying Assurance Methods According to Techniques

  • Goal-oriented approaches derive assurance criteria from requirements and use goals, context, preferences, and quality criteria to select suitable behavior as conditions change.RELAX addresses environmental uncertainty, while FLAGS evaluates degrees of goal satisfaction; Zanshin monitors awareness requirements and adaptation progress at runtime.Source: §5.1 · p. 16
  • Automatic test generation uses goals, quality functions, and adverse environments to produce relevant test cases or execution traces for adaptive systems.The MAPE-T loop and its realization Veritas adapt test cases to preserve their relevance as the system encounters environmental changes and reconfigures.Source: §5.1 · pp. 16–17
  • Model checking evaluates formal system models against specified properties, and runtime model checking is used to verify self-adaptive systems.The surveyed work includes checking resilience, harmful reconfigurations, functional properties, and adaptive logic; the cited survey found no standard tools, though 40% of surveyed studies used formal modeling or verification tools.Source: §5.1 · pp. 17–18
  • Rule-based analyses use graph transformations and related formalisms to check invariants, system correctness, and properties of reconfiguration.The cited approaches include graph grammars and AGG-based verification of self-adaptation properties at design time and runtime.Source: §5.1 · pp. 18–19
  • Synthesis approaches generate component assembly code intended to guarantee specified interactions, with some work extending the approach to non-functional properties and dynamic updates.Inverardi et al. distinguish coordinators from mediators for connecting networked systems; La Manna et al. reason about the safeness of updates after specification changes.Source: §5.1 · p. 19
  • Semantic-web models such as RDF graphs can represent context, monitoring strategies, requirements, and assurance criteria to support runtime adaptation of monitoring infrastructure.Ontologies and domain rules can infer infrastructure changes when requirements, criteria, or context change.Source: §5.1 · p. 19

5.2 Classifying Assurance Methods According to Non-Functional Criteria

  • Runtime safety approaches include just-in-time certification, modular conditional safety certificates, and runtime hazard analysis for adaptive or open systems.Traditional safety assurance can be infeasible when a complete understanding of the system and its environment is unavailable.Source: §5.2 · p. 20
  • Non-functional assurance spans performance, reliability, availability, security, and usability, using methods such as runtime performance models, probabilistic checking, and model-based interface evaluation.Security responses must balance goals such as confidentiality and availability; adaptive access policies and user-controlled privacy settings are examples of runtime approaches.Source: §5.2 · pp. 20–22

6 Compelling Applications for Models at Runtime

The chapter presents selected application areas where M@RT may support assurance of adaptive systems. The examples span multimedia streaming, autonomous vehicles, precision agriculture, and ambient assisted living.

Kaleidoscope

  • Kaleidoscope must adapt its network and software architecture to minimize latency and maximize capacity while delivering high-quality video streaming.Predictive models can anticipate near-future latency and capacity needs for preventive adaptations, while runtime formal models can support reliable reconfiguration.Source: §6 · pp. 22–23

Autonomous Vehicle Service

  • Autonomous vehicles need runtime-manageable models for context, sensor quality, uncertainty, and typical behavior to support reliable assurance.The chapter notes that such models are often developed implicitly and coded manually, and argues they should instead be managed rigorously throughout the life cycle.Source: §6 · p. 23

Autonomous Agricultural Operations

  • Precision agriculture combines machines for partially autonomous field tasks, making safety and security assurance important and requiring traditional techniques to be modified.Suitable M@RT and management facilities are presented as a way to shift parts of assurance into runtime.Source: §6 · p. 24

Ambient Assisted Living

  • Ambient assisted living must adapt to varying users, devices, and environments while maintaining seamless and reliable operation for user safety.M@RT can represent users and context and support reasoning about adaptive behavior and its impact; the Guardian Angels example also points to runtime decision-making and certification.Source: §6 · pp. 24–25

7 Conclusions

The chapter presents a research agenda for runtime assurance grounded in Models@run.time (M@RT), drawing on seminar breakout findings and author discussions. It identifies opportunities and challenges for advancing assurance in highly adaptive systems.

7 Conclusions

  • The chapter's research agenda uses M@RT as a foundation for runtime assurance techniques.It grew from the Assurance@run.time breakout group at the 2011 Schloss Dagstuhl Seminar and subsequent online discussions among the authors.Source: §7 · pp. 25–26
  • V&V has made the most progress among assurance subfields in transitioning design-time models and techniques to runtime, though not all tasks can be transitioned.Source: §7 · p. 26
  • Runtime assurance tasks offer opportunities to make self-adaptive systems more resilient, reliable, responsive, secure, and cost-effective.Source: §7 · p. 26
  • A formidable research challenge is developing techniques that guarantee certifiable trust for highly adaptive systems.Source: §7 · p. 26
  • The agenda is intended as a starting point for related research communities, whose collaboration matters as self-adaptive systems see greater use in high-assurance domains.M@RT is identified as a key enabling technology for progress in this area.Source: §7 · p. 26
Loading 1505.00903v1…