Engineering Trustworthy Self-Adaptive Software with Dynamic … · 2018-11-26 · Engineering Trustworthy Self-Adaptive Software with Dynamic Assurance Cases Radu Calinescu, Danny

This is a preliminary version of the IEEE Trans. Softw. Eng. paper at https://ieeexplore.ieee.org/document/8008800.

Engineering Trustworthy Self-Adaptive Softwarewith Dynamic Assurance Cases

Radu Calinescu, Danny Weyns, Simos Gerasimou, M. Usman Iftikhar, Ibrahim Habli, and Tim Kelly

Abstract—Building on concepts drawn from control theory, self-adaptive software handles environmental and internal uncertainties bydynamically adjusting its architecture and parameters in response to events such as workload changes and component failures.Self-adaptive software is increasingly expected to meet strict functional and non-functional requirements in applications from areas asdiverse as manufacturing, healthcare and finance. To address this need, we introduce a methodology for the systematic ENgineering ofTRUstworthy Self-adaptive sofTware (ENTRUST). ENTRUST uses a combination of (1) design-time and runtime modelling andverification, and (2) industry-adopted assurance processes to develop trustworthy self-adaptive software and assurance cases arguingthe suitability of the software for its intended application. To evaluate the effectiveness of our methodology, we present a tool-supportedinstance of ENTRUST and its use to develop proof-of-concept self-adaptive software for embedded and service-based systems fromthe oceanic monitoring and e-finance domains, respectively. The experimental results show that ENTRUST can be used to engineerself-adaptive software systems in different application domains and to generate dynamic assurance cases for these systems.

Index Terms—Self-adaptive software systems, software engineering methodology, assurance evidence, assurance cases.

F

1 INTRODUCTION

Software systems are regularly used in applications charac-terised by uncertain environments, evolving requirementsand unexpected failures. The correct operation of theseapplications depends on the ability of software to adaptto change, through the dynamic reconfiguration of its pa-rameters or architecture. When events such as variationsin workload, changes in the required throughput or com-ponent failures are observed, alternative adaptation optionsare analysed, and a suitable new software configuration maybe selected and applied.

As software adaptation is often too complex or toocostly to be performed by human operators, its automationhas been the subject of intense research. Using conceptsborrowed from the control of discrete-event systems [87],this research proposes the extension of software systemswith closed-loop control. As shown in Fig. 1, the paradigminvolves using an external software controller to monitorthe system and to adapt its architecture or configurationafter environmental and internal changes. Inspired by theautonomic computing manifesto [63], [69] and by pioneer-ing work on self-adaptive software [67], [82], this researchhas been very successful. Over the past decade, numerousresearch projects proposed architectures [51], [72], [115] andframeworks [14], [41], [100], [114] for the engineering of self-adaptive systems. Extensive surveys of this research and itsapplications are available in [64], [85], [91].

In this paper, we are concerned with the use of self-adaptive software in systems with strict functional and

• R. Calinescu, S. Gerasimou, I. Habli and T. Kelly are with the Departmentof Computer Science at the University of York, UK.

• D. Weyns is with the Department of Computer Science of the KatholiekeUniversiteit Leuven, Belgium.

• M. U. Iftikhar is with the Department of Computer Science at LinnaeusUniversity, Sweden.

Effectors Controlledsoftwaresystem

ControllerRequirements

Sensorsclosed-loop control

Fig. 1. Closed-loop control is used to automate software adaptation

non-functional requirements. A growing number of sys-tems are expected to fit this description in the near fu-ture. Service-based telehealth systems are envisaged to useself-adaptation to cope with service failures and workloadvariations [14], [42], [111], avoiding harm to patients. Au-tonomous robots used in applications ranging from man-ufacturing [38], [54] to oceanic monitoring [18], [52] willneed to rely on self-adaptive software for completing theirmissions safely and effectively, without damage to, or lossof, expensive equipment. Employing self-adaptive softwarein these applications is very challenging, as it requiresassurances about the correct operation of the software inscenarios affected by uncertainty.

Assurance has become a major concern for self-adaptivesoftware only recently [24], [28], [34], [35]. Accordingly,the research in the area is limited, and often confinedto providing evidence that individual aspects of the self-adaptive software are correct (e.g. the software platformused to execute the controller, the controller functions, or theruntime adaptation decisions). However, such evidence isonly one component of the established industry process forthe assurance of software-based systems [10], [77], [102]. Inreal-world applications, assuring a software system requiresthe provision of an assurance case, which standards such as[103] define as

“a structured argument, supported by a body of evi-dence, that provides a compelling, comprehensible and

1

arX

iv:1

703.

0635

0v2

[cs

.SE

] 2

2 N

ov 2

018

https://ieeexplore.ieee.org/document/8008800

2

valid case that a system is safe for a given application ina given environment”.

Our work addresses this discrepancy between the stateof practice and the current research on assurances for self-adaptive software. To this end, we introduce a genericmethodology for the joint development of trustworthy self-adaptive software systems and their associated assurancecases. Our methodology for the ENgineering of TRUstwor-thy Self-adaptive sofTware (ENTRUST) is underpinned by acombination of (1) design-time and runtime modelling andverification, and (2) an industry-adopted standard for theformalisation of assurance arguments [56], [94].

ENTRUST uses design-time modelling, verification andsynthesis of assurance evidence for the control aspects ofa self-adaptive system that are engineered before the sys-tem is deployed. These design-time activities support theinitial controller enactment and the generation of a partialassurance case for the self-adaptive system. The dynamicselection of a system configuration (i.e., architecture andparameters) during the initial deployment and after internaland environmental changes involves further modelling andverification, and the synthesis of the additional assuranceevidence required to complete the assurance case. Theseactivities are fully automated and carried out at runtime.

The ENTRUST methodology is not prescriptive aboutthe modelling, verification and assurance evidence gener-ation methods used in its design-time and runtime stages.This generality exploits the fact that the body of evidenceunderpinning an assurance case can combine verificationevidence from activities including formal verification, test-ing and simulation. As such, our methodology is applicableto a broad range of application domains, software engineer-ing paradigms and verification methods.

ENTRUST supports the systematic engineering and as-surance of self-adaptive systems. In line with other researchon self-adaptive systems (see e.g. [91], [113]), we assumethat the controlled software system from Figure 1 alreadyexists, and we focus on its enhancement with self-adaptationcapabilities through the addition of a high-level monitor-analyse-plan-execute (MAPE) control loop. The componentsof the controlled software system may already support low-level, real-time adaptation to localised changes. For instance,the self-adaptive embedded system used as a running ex-ample in Section 5 is a controlled unmanned vehicle thatemploys built-in low-level control to maintain the speedselected by its high-level ENTRUST controller. Mature ap-proaches from the areas of robust control of discrete-eventsystems (e.g. [76], [87], [98], [116]) and real-time systems(e.g. [73], [78]) already exist for the engineering of suchlow-level control, which is outside the scope of ENTRUST.Likewise, established assurance processes are available forthe non-self-adaptive aspects of software systems (e.g. [9],[10], [58], [61], [90]). We do not duplicate this work. Usingthese processes to construct assurance arguments for thecorrect design, development and operation of the controlledsoftware system, and for the derivation, validity, complete-ness and formalisation of the requirements from Fig. 1 isoutside the scope of our paper. Thus, ENTRUST focuseson the correct engineering of the controller and on thecorrect operation of self-adaptive system, assuming that thecontrolled system and its requirements are both correct.

The main contributions of our paper are:

1) The first end-to-end methodology for (a) engineeringself-adaptive software systems with assurance evidencefor the controller platform, its functions and the adapta-tion decisions; and (b) devising assurance cases whoseassurance arguments bring together this evidence.

2) A novel assurance argument pattern for self-adaptivesystems, expressed in the Goal Structuring Notation(GSN) standard [56] that is widely used for assurancecase development in industry [94].

3) An instantiation of our methodology whose stages aresupported by the established modelling and verificationtools UPPAAL [6] and PRISM [75]. This methodologyinstance extends and integrates for the first time our pre-viously separate strands of work on developing formallyverified control loops [65], runtime probabilistic modelchecking [19] and dynamic safety cases [36].

These contributions are evaluated using two case studieswith different characteristics and goals, and belonging todifferent application domains.

The remainder of the paper is organised as follows. InSection 2, we provide background information on assurancecases, GSN and assurance argument patterns. Section 3introduces two proof-of-concept self-adaptive systems thatwe use to illustrate our methodology, which is described inSection 4, and to illustrate and evaluate its tool-supportedinstance, which is presented in Section 5. Section 6 presentsour evaluation results, which show that the methodologycan be used for the effective engineering of self-adaptivesystems from different domains and for the generation ofdynamic assurance cases for these systems. In Section 7, weoverview the existing approaches to providing assurancesfor self-adaptive software systems, and we compare themto ENTRUST. Finally, Section 8 concludes the paper with adiscussion and a summary of future work directions.

2 PRELIMINARIES

This section provides background information on assurancecases, introducing the assurance-related terminology andconcepts used in the rest of the paper. We start by definingassurance cases and their components in Section 2.1. Next,we introduce a commonly used notation for the specificationof assurance cases in Section 2.2. Finally, we introduce theconcept of an assurance argument pattern in Section 2.3.

2.1 Assurance Cases

An assurance case1 is a report that supports a specific claimabout the requirements of a system [9]. As an example,the assurance case in [81] provides documented assurancethat the “implementation and operation of North EuropeanFunctional Airspace Block (NEFAB) is acceptably safe ac-cording to ICAO, EC and EUROCONTROL safety require-ments.” The documented assurance within an assurancecase comprises (1) evidence and (2) structured arguments

1. Assurance cases developed for safety-critical systems are alsocalled safety cases. In this work, we are concerned with any self-adaptivesoftware systems that must meet strict requirements, and therefore wetalk about assurance cases and assurance arguments.

3

Away Goal

<Goal Statement>

<Module Identifier>

{Goal Identifier}

<Goal Statement>

{Strategy Identifier}

<Strategy Statement>

{Solution Identifier}

<Solution Statement>

{Context Identifier}

<Context Statement>J

{Justification Identifier}

<Justification Statement>

A

{Assumption Identifier}

<Assumption Statement>

Supported by

In context of Optionality

Multiplicity

Choice

Uninstantiated Entity

Undeveloped Entity

Away Goal

<Goal Statement>

<Module Identifier>

{Goal Identifier}

<Goal Statement>









A



Supported by


Multiplicity

Choice


Undeveloped Entity

Away Goal

<Goal Statement>

<Module Identifier>

{Goal Identifier}

<Goal Statement>









A



Supported by


Multiplicity

Choice


Undeveloped Entity

Away Goal

<Goal Statement>

<Module Identifier>

{Goal Identifier}

<Goal Statement>









A



Supported by


Multiplicity

Choice


Undeveloped Entity

Away Goal

<Goal Statement>

<Module Identifier>

{Goal Identifier}

<Goal Statement>









A



Supported by


Multiplicity

Choice


Undeveloped Entity

Away Goal

<Goal Statement>

<Module Identifier>

{Goal Identifier}

<Goal Statement>









A



Supported by


Multiplicity

Choice


Undeveloped Entity

Away Goal

<Goal Statement>

<Module Identifier>

{Goal Identifier}

<Goal Statement>









A



Supported by


Multiplicity

Choice


Undeveloped Entity

Away Goal

<Goal Statement>

<Module Identifier>

{Goal Identifier}

<Goal Statement>









A



Supported by


Multiplicity

Choice


Undeveloped Entity

Fig. 2. Core GSN elements

that link the evidence to the claim [9], possibly throughintermediate claims.

Assurance cases are becoming mandatory for softwaresystems used in safety-critical and mission-critical applica-tions [10], [77], [102]. They are used in domains rangingfrom nuclear energy [104] and medical devices [106] to airtraffic control [43] and defence [103]. A growing number ofassurance cases from these and other domains are openlyavailable (e.g., [81], [105]).

The development of assurance cases comprises processescarried out at all stages of the system life cycle [102]. Re-quirements analysis evidence and design evidence demon-strate that system reliability, safety, maintainability, etc. areconsidered in the early stages of the life cycle. Implementa-tion, validation and verification evidence are then generatedas the system is developed. Finally, evidence collected atruntime is used to update assurance cases during systemmaintenance.

As aptly described in [102], the assurance case mustbe “a living, cradle-to-grave document.” This is particularlytrue for self-adaptive software systems. For these systems,existing evidence needs to be continuously combined withnew adaptation evidence, i.e., evidence that the system willcontinue to operate safely after self-adaptation activities.

2.2 Goal Structuring NotationThe assurance cases for self-adaptive systems introducedlater in the paper are devised in the Goal Structuring Notation(GSN) [68], a community standard [56] widely used forassurance case development in industry [94]. The main GSNelements (Fig. 2) can be used to construct an argument byshowing how an assurance claim (represented in GSN bya goal) is broken down into sub-claims (also representedby GSN goals), until eventually it can be supported byGSN solutions (i.e., assurance evidence from verification,testing, etc.). Strategies are used to partition the argumentand describe the nature of the inference that exists betweena goal and its supporting goal(s). The rationale (assumptionsand justifications) for individual elements of the argumentcan be captured, along with the context (e.g. to describe theoperational environment) in which the claims are stated.

In a GSN diagram, claims are linked to strategies, sub-claims and ultimately to solutions using ‘supported by’ con-

Context 1

Heating system

Strategy 1

Argument based on addressing the safety of system functions

Goal 1

Heating system is safe

Context 2

Control and monitor system functions

Goal 2

Control system function is safe

Goal 3

All system functions are independent

Goal 2’

Monitor system function is safe

Solution 1

Simulation results

Solution 2

Test results

Solution 3

Formal proof

Fig. 3. Example of a GSN assurance argument

nectives, which are rendered as lines with a solid arrowheadand declare inferential or evidential relationships. ‘Sup-ported by’ connectives may be decorated with their multi-plicity or marked as optional. The ‘in context of ’ connective,rendered as a line with a hollow arrowhead, declares acontextual relationship between a goal or strategy on theone hand and a context, assumption or justification on theother hand.

Large or complex sections of the assurance argument canbe organised into modules by means of GSN away goalsreferenced in the main argument and defined separately.Finally, GSN entities can be marked as uninstantiated toindicate that they are placeholders that need to be replacedwith a concrete instantiation, and GSN goals can be markedas undeveloped to indicate that they need to be furtherdeveloped into sub-goals, strategies and solutions.

As an example, Figure 3 shows a simple GSN assuranceargument for the software part of a heating system. Its rootgoal (Goal 1) claims that the system is safe at all times.This claim is partitioned into sub-claims using a strategy(Strategy 1) that addresses the safety of the two systemfunctions (i.e. control and monitoring) separately throughsub-claims Goal 2 (for the control system) and Goal 2’ (forthe monitor system), and includes sub-claim Goal 3 thatthe two functions are independent. The three sub-claims aresupported by three solutions comprising assurance evidencefrom simulation, testing and formal proof, respectively.

2.3 Assurance Argument PatternsTo reduce the significant effort required to develop assur-ance cases, in our previous work on software assurance [58],[60] we collaborated to the creation of a catalog of reusableGSN assurance argument patterns [59]. Each pattern considersthe contribution made by the software to system hazardsfor a particular class of systems and scenarios. The GSNelements of a pattern that are generic to the entire class arefully developed and instantiated, whereas the entities thatare specific to each system and scenario within the class areleft undeveloped and/or uninstantiated.

As an example, Fig. 4 depicts an assurance argumentpattern that is instantiated by the GSN assurance argument

4

n (n=#functions)

Context 1

{System X}

Strategy 1

Argument based on addressing the safety of system functions

Goal 1

{System X} is safe

Context 2

{List of system functions}

Goal 2

{Function Y} is safe

Goal 4Interactions between system functions are non-hazardous

Goal 3

All system functions are independent

1 of 2

Fig. 4. Example of a GSN assurance argument pattern

from Fig. 3. The elements surrounded by curly brackets ‘{’and ‘}’ in the pattern must be instantiated for each assur-ance argument based on the pattern, as further indicatedby the triangular ‘uninstantiated’ symbol under the GSNentities that contain them. Goal 2 is marked with boththis ‘uninstantiated’ symbol (because it contains elementsin curly brackets) and a diamond-shaped ‘undeveloped’symbol (because, like for the ‘choice’ sub-claims Goal 3 andGoal 4, additional GSN entities must be added underneathto complete the assurance argument); the two symbols arerendered overlapping under Goal 2.

In this paper, we devise a new assurance argument pat-tern, which is applicable to self-adaptive software systems.

3 SELF-ADAPTIVE SYSTEM EXAMPLES

This section introduces two examples of self-adaptive soft-ware systems that we will use to illustrate our the genericENTRUST methodology in Section 4, and to illustrate andevaluate its tool-supported instantiation in Section 5.

3.1 Unmanned Underwater Vehicle (UUV) System

The first system is a self-adaptive UUV embedded sys-tem adapted from [52]. UUVs are increasingly used in awide range of oceanographic and military tasks, includingoceanic surveillance (e.g., to monitor pollution levels andecosystems), undersea mapping and mine detection. Limita-tions due to their operating environment (e.g., impossibilityto maintain UUV-operator communication during missionsand unexpected changes) require that UUV systems areself-adaptive. These systems are often mission critical (e.g.,when used for mine detection) or business critical (e.g., theycarry expensive equipment that should not be lost).

The self-adaptive system we use consists of a UUVdeployed to carry out a data gathering mission. The UUV isequipped with n ≥ 1 on-board sensors that can measure thesame characteristic of the ocean environment (e.g., watercurrent, salinity or temperature). When used, the sensorstake measurements with different, variable rates r1, r2, . . . ,rn. The probability that each sensor produces measurementsthat are sufficiently accurate for the purpose of the missiondepends on the UUV speed sp, and is given by p1, p2,. . . , pn. For each measurement taken, a different amount

of energy is consumed, given by e1, e2, . . . , en. Finally, then sensors can be switched on and off individually (e.g., tosave battery power when not required), but these operationsconsume an amount of energy given by eon

1 , eon2 , . . . , eon

n

and eoff1 , eoff

2 , . . . , eoffn , respectively. The UUV must adapt to

changes in the sensor measurement rates r1, r2, . . . , rn andto sensor failures by dynamically adjusting:

(a) the UUV speed sp

(b) the sensor configuration x1, x2, . . . , xn (where xi = 1 ifthe i-th sensor is on and xi = 0 otherwise)

in order to meet the quality-of-service requirements below:

R1 (throughput): The UUV should take at least 20 mea-surements of sufficient accuracy for every 10 metres ofmission distance.

R2 (resource usage): The energy consumption of the sen-sors should not exceed 120 Joules per 10 surveyed me-tres.

R3 (cost): If requirements R1 and R2 are satisfied by mul-tiple configurations, the UUV should use one of theseconfigurations that minimises the cost function

cost = w1E + w2sp−1, (1)

where E is the energy used by the sensors to surveya 10m mission distance, and w1, w2 > 0 are weightsthat reflect the relative importance of carrying out themission with reduced battery usage and completing themission faster.2

R4 (safety): If a configuration that meets requirements R1–R3 is not identified within 2 seconds after a sensorrate change, the UUV speed must be reduced to 0m/s.This ensures that the UUV does not advance more thanthe distance it can cover at its maximum speed within2 seconds without taking appropriate measurements,and waits until the controller identifies a suitable con-figuration (e.g., after the UUV sensors recover) or newinstructions are provided by a human operator.

3.2 Foreign Exchange Trading System

Our second system is a service-based system from thearea of foreign exchange trading, taken from our recentwork in [53]. This system, which we anonymise as FXfor confidentiality reasons, is used by an European foreignexchange brokerage company. The FX system implementsthe workflow shown in Fig. 5 and described below.

An FX customer (called a trader) can use the system intwo operation modes. In the expert mode, FX executes aloop that analyses market activity, identifies patterns thatsatisfy the trader’s objectives, and automatically carriesout trades. Thus, the Market watch service extracts real-time exchange rates (bid/ask price) of selected currencypairs. This data is used by a Technical analysis service thatevaluates the current trading conditions, predicts futureprice movement, and decides if the trader’s objectives are:

2. Cost (or utility) functions that employ weights to combine severalperformance, reliability, resource use and other quality attributes ofsoftware—accounting for differences in attribute value ranges andrelative importance—are extensively used in self-adaptive softwaresystems (e.g. [14], [41], [51], [91], [109]).

5

Fig. 5. Foreign exchange trading (FX) workflow

(i) “satisfied” (causing the invocation of an Order serviceto carry out a trade); (ii) “unsatisfied” (resulting in a newMarket watch invocation); or (iii) “unsatisfied with highvariance” (triggering an Alarm service invocation to notifythe trader about discrepancies/opportunities not covered bythe trading objectives). In the normal mode, FX assesses theeconomic outlook of a country using a Fundamental analysisservice that collects, analyses and evaluates informationsuch as news reports, economic data and political events,and provides an assessment on the country’s currency. Ifsatisfied with this assessment, the trader can use the Orderservice to sell or buy currency, in which case a Notificationservice confirms the completion of the trade. We assumethat the FX system has to dynamically select third-partyimplementations for each service from Fig. 5, in order tomeet the following system requirements:

R1 (reliability): Workflow executions must complete suc-cessfully with probability at least 0.9.

R2 (response time): The total service response time perworkflow execution must be at most 5s.

R3 (cost): If requirements R1 and R2 are satisfied by multi-ple configurations, the FX system should use one of theseconfigurations that minimises the cost function:

cost = w1price + w2time, (2)

where price and time represent the total price of theservices invoked by a workflow execution and the re-sponse time for a workflow execution, respectively, andw1, w2 > 0 are weights that encode the desired trade-offbetween price and response time.

R4 (safety): If a configuration that ensures requirementsR1–R3 cannot be identified within 2s after a change inservice characteristics is signalled by the sensors of theself-adaptive FX system, the Order service invocation isbypassed, so that the FX system does not carry out anytrade that might be based on incorrect or stale data.

Note that requirements R1–R3 express two constraints andan optimisation criterion that are qualitatively different fromthose specified by the requirements from our first case study(cf. Section 3.1). Nevertheless, our tool-supported instanceof the ENTRUST methodology enabled the development ofthe self-adaptive FX system as described in Section 5.3.

4 THE ENTRUST METHODOLOGY

The ENTRUST methodology supports the systematic engi-neering and assurance of self-adaptive systems based onmonitor-analyse-plan-execute (MAPE) control loops. This isby far the most common type of control loop used to deviseself-adaptive software systems [13], [34], [35], [41], [64], [74],[79], [91]. The engineering of self-adaptive systems based onessentially different control techniques, such as the controltheoretical paradigm proposed in [47], is not supported byour methodology.

ENTRUST comprises the tool-supported design-timestages and the automated runtime stages shown in Figure 6,and is underpinned by two key principles:

1) Model-driven engineering is essential for developing trustwor-thy self-adaptive systems and their assurance cases. As em-phasised in the previous section, model-based analysis,simulation, testing and formal verification—at designtime and during reconfiguration—represent the mainsources of assurance evidence for self-adaptive software.As such, both the design-time and the runtime stages ofour methodology are model driven. Models of the struc-ture and behaviour of the functional components, con-troller and environment are the basis for the engineeringand assurance of ENTRUST self-adaptive systems.

2) Reuse of application-independent software and assurance arte-facts significantly reduces the effort and expertise required todevelop trustworthy self-adaptive systems. Assembling anassurance case for a software system is a costly processthat requires considerable effort and expertise. There-fore, the reuse of both software and assurance artefactsis essential for ENTRUST. In particular, the reuse ofapplication-independent controller components and oftemplates for developing application-specific controllerelements also enables the reuse of assurance evidencethat these software artefacts are trustworthy.

The ENTRUST stages and their exploitation of these twoprinciples are described in the remainder of this section.

4.1 Design-time ENTRUST Stages

4.1.1 Stage 1: Development of Verifiable ModelsIn ENTRUST, the engineering of a self-adaptive system withthe architecture from Figure 1 starts with the developmentof models for:

1) The controller of the self-adaptive system;2) The relevant aspects of the controlled software system

and its environment.

A combination of structural and behavioural models maybe produced, depending on the evidence needed to assem-ble the assurance case for the self-adaptive system underdevelopment. ENTRUST is not prescriptive in this respect.However, we require that these models are verifiable, i.e.,that they can be used in conjunction with methods such asmodel checking or simulation, to obtain evidence that thecontroller and the self-adaptive system meet their require-ments. As an example, finite state transition models may beproduced for the controllers of our UUV and FX systemsfrom Section 3, enabling the use of model checking to verifythat these controllers are deadlock free.

6

1. Developverifiablemodels

2. Verifycontrollermodels

4. Enactcontroller

5. Deployself-adaptive

system

3. Partiallyinstantiate

arg. pattern

7. Updateassuranceargument

EN

TR

US

Tst

ag

esS

oft

war

ear

tefa

cts

ap

p.

spec

ific

reu

sab

le

Incompletesystem&env.models

Controllermodel(s)

Verifiedcontrollerplatform

ap

p.

spec

ific

reu

sab

le

Controllerassuranceevidence

Assuranceargumentpattern

Controller

Dynamicassuranceargument

Adaptationassuranceevidence

M A P E

6. Self-adapt

Deployedself-adaptivesystem

Up-to-datesystem&env.models

Reconfiguredself-adaptivesystem

Design-time stages

Ass

ura

nce

arte

fact

s

Systemrequirements

Controllermodeltemplate(s)

Genericcontrollerrequirements

Domainknowledge

Controlledsystemspecification

Platformassuranceevidence

Partialassuranceargument

Runtime stages

Controlledsystem

Fig. 6. Stages and key artefacts of the ENTRUST methodology. In line with the two principles underpinning the methodology, its first stage involvesthe development of verifiable models for the controller, controlled system and environment of the self-adaptive system used throughout the remainingstages, and multiple stages reuse application-independent software and assurance artefacts.

The verifiable models are application-specific. As il-lustrated in Figure 6, their development requires domainknowledge,3 is based on a controlled system specification, andis informed by the system requirements. As in other areasof software engineering, we envisage that tool-supportedmethods will typically be used to obtain these models.However, their manual development or fully automatedsynthesis are not precluded by ENTRUST.

In line with the “reuse of artefacts” principle, ENTRUSTexploits the fact that the controllers of self-adaptive sys-tems implement the established MAPE workflow, and usesapplication-independent controller model template(s) to devisethe controller model(s). These templates model the genericaspects of the MAPE workflow and contain placeholders forthe application-specific elements of an ENTRUST controller.

Given the environmental and internal uncertainty thatcharacterises self-adaptive systems, only incomplete systemand environment models can be produced in this ENTRUSTstage. These incomplete models may include unknownor estimated parameters, nondeterminism (i.e., alternativeoptions whose likelihoods are unknown), parts that aremissing, or some combination of all of these. For example,parametric Markov chains may be devised to enable theruntime analysis of the requirements for our UVV and FXsystems detailed in Sections 3.1 and 3.2, respectively, bymeans of probabilistic model checking or simulation.

4.1.2 Stage 2: Verification of Controller ModelsThe main role of the second ENTRUST stage is to producecontroller assurance evidence, i.e., compelling evidence that

3. The ENTRUST software and assurance artefacts that appear initalics in the text are also shown in Figure 6.

a controller based on the controller model(s) from Stage 1will satisfy a set of generic controller requirements. These arerequirements that must be satisfied in any self-adaptive sys-tem (e.g., deadlock freeness) and are predefined in a formatcompatible with that of the controller model templates andwith the method that will be used to verify the controllermodels. For example, if labelled transition systems are usedto model the controller and model checking to establish itscorrectness as in [38], [39], these generic controller require-ments can be predefined as temporal logic formulae.

The controller assurance evidence may additionally in-clude evidence that some of the system requirements aresatisfied. Thus, it may be possible to show that—despitethe uncertainty characteristic to any self-adaptive system—application-specific failsafe operating modes (e.g. thosespecified by requirements R4 of our UUV and FX systemsfrom Section 3) are always reachable.

The assurance evidence generated in this stage of themethodology may be obtained using a range of methodsthat include formal verification, theorem proving and sim-ulation. The methods that can be used depend on the typesof models produced in the previous ENTRUST stage, andon the generic controller requirements and system require-ments for which assurance is sought. The availability of toolsupport in the form of model checkers, theorem provers,SMT solvers, domain-specific simulators, etc. will influencethe choice of these methods.

Preparing the design-time models, i.e., developing ver-ifiable models and verifying the controller models, comeswith a cost. However, by using tool-supported methodsand exploiting reusable application-independent software,this cost can significantly be reduced and does not affect

7

the usability of ENTRUST compared to other related ap-proaches. Related approaches that only provide a fractionof the assurances that ENTRUST achieves (as detailed whenwe discuss related work in Section 7) operate with design-time models that require a comparable effort to specify themodels and provide the controller assurance evidence.

4.1.3 Stage 3: Partial Instantiation of Assurance ArgumentPatternThis ENTRUST stage uses the controller assurance evidencefrom Stage 2 to support the partial instantiation of a genericassurance argument pattern for self-adaptive software. Asexplained in Section 2.3, this pattern is an incomplete as-surance argument containing placeholders for the system-specific assurance evidence. A subset of the placeholderscorrespond to the controller assurance evidence obtained inStage 2, and are therefore instantiated using this evidence.The result is a partial assurance argument, which still con-tains placeholders for the assurance evidence that cannotbe obtained until the uncertainties associated with the self-adaptive system are resolved at runtime.

For example, the partial assurance argument for ourUUV and FX systems should contain evidence that theircontrollers are deadlock free and that their failsafe require-ments R4 are always satisfied. These requirements can beverified at design time. In contrast, requirements R1–R3 forthe two systems cannot be verified until runtime, whenthe controller acquires information about the measurementrates of the UUV sensors and the third-party services avail-able for the FX operations, respectively. Assurance evidencethat requirements R1–R3 are satisfied can only be obtainedat runtime.

In addition to the two types of placeholders, the as-surance argument pattern used as input for this stage in-cludes assurance evidence that is application independent.In particular, it includes evidence about the correct opera-tion of the verified controller platform, i.e. the software thatimplements application-independent controller functional-ity used to execute the ENTRUST controllers. This platformassurance evidence is reusable across self-adaptive systems.

4.1.4 Stage 4: Enactment of the ControllerThis ENTRUST stage assembles the controller of the self-adaptive system. The process involves integrating the ver-ified controller platform with the application-specific con-troller elements, and with the sensors and effectors thatinterface the controller with the controlled software systemfrom Figure 1.

The application-specific controller elements must be de-vised from the verified controller models, by using a trustedmodel-driven engineering method. This can be done usingmodel-to-text transformation, a method that employs a trustedmodel compiler to generate a low-level executable represen-tation of the controller models. Alternatively, the ENTRUSTverified controller platform may include a trusted virtualmachine4 able to directly interpret and run the controllermodels. The second, model interpretation method [93], has the

4. Throughout the paper, the term “virtual machine” refers to asoftware component capable to interpret and execute controller models,much like a Java virtual machine executes Java code.

advantage that it eliminates the need to generate controllercode and to provide additional assurances for it.

4.1.5 Stage 5: Deployment of the Self-Adaptive SystemIn the last design-time stage, the integrated controllerand controlled components of the self-adaptive system areinstalled, preconfigured and activated by means of anapplication-specific process. The pre-configuration is re-sponsible for setting the deployment-specific parametersand architectural aspects of the system. For example, thepre-configuration of the UUV system from Section 3.1 in-volves selecting the initial speed and active sensor set forthe UUV, whereas for the FX system from Section 3.2 itinvolves choosing initial third-party implementations foreach FX service.

The deployed self-adaptive system will be fully configuredand a complete assurance argument will be available onlyafter the first execution of the MAPE control loop. Thisexecution is typically triggered by the system activation,to ensure that the newly deployed self-adaptive systemtakes into account the current state of its environment asdescribed next.

4.2 Runtime ENTRUST Stages4.2.1 Stage 6: Self-adaptationIn this ENTRUST stage, the deployed self-adaptive systemis dynamically adjusting its parameters and architecturein line with observed internal and environmental changes.To this end, the controller executes a typical MAPE loopthat monitors the system and its environment, using theinformation obtained in this way to resolve the “unknowns”from the incomplete system and environment models. Theresulting up-to-date system and environment models enablethe MAPE loop to analyse the system compliance with itsrequirements after changes, and to plan and execute suitablereconfigurations if necessary.

Whenever the MAPE loop produces a reconfigured self-adaptive system, its analysis and planning steps generateadaptation assurance evidence confirming the correctness ofthe analysis results and of the reconfiguration plan devisedon the basis of these results. This assurance evidence is a by-product of analysis and planning methods that may includeruntime verification, simulation and runtime model check-ing. Irrespective of the methods that produce it, the adapta-tion assurance evidence is essential for the development ofa complete assurance argument in the next ENTRUST stage.

4.2.2 Stage 7: Synthesis of Dynamic Assurance ArgumentThe final ENTRUST stage uses the adaptation correct-ness evidence produced by the MAPE loop to fill in theplaceholders from the partial assurance argument, and todevise the complete assurance case for the reconfiguredself-adaptive system. For example, runtime evidence thatrequirements R1–R3 of the UUV and FX systems fromSection 3 are met will be used to complete the remainingplaceholders from their partial assurance arguments. Thus,an ENTRUST assurance case is underpinned by a dynamicassurance argument that is updated after each reconfigurationof the system parameters and architecture. This assurancecase captures both the full assurance argument and the

8

evidence that justifies the active configuration of the self-adaptive system.

The ENTRUST assurance case versions generated forevery system reconfiguration have two key uses. First,they allow decision makers and auditors to understandand assess the present and past versions of the assurancecase. Second, they allow human operators to endorse majorreconfiguration plans in human-supervised self-adaptivesystems. This type of self-adaptive systems is of particularinterest in domains where human supervision representsan important risk mitigation factor or may be required byregulations. As an example, UK Civil Aviation Authorityregulations [101] permit self-adaptation in certain functions(e.g., power management, flight management and collisionavoidance) of unmanned aircraft of no more than 20 kgprovided that the aircraft operates within the visual line ofsight of a human operator.

5 TOOL-SUPPORTED INSTANCE OF ENTRUSTThis section presents an instance of ENTRUST in which thestages described in Section 4 are supported by the modellingand verification tools UPPAAL [6] and PRISM [75]. We startwith an overview of this tool-supported ENTRUST instancein Section 5.1, followed by a description of each of its stagesin Section 5.2. The UUV self-adaptive system introducedin Section 3.1 is used as a running example throughoutthese stage descriptions. We conclude with an end-to-endillustration of how the ENTRUST instance can be used todevelop the FX self-adaptive system in Section 5.3.

5.1 Overview

The ENTRUST methodology can be used with differentcombinations of modelling, verification and controller en-actment methods, which may employ different self-adaptivesystem architectures and types of assurance evidence. Thissection presents a tool-supported instance of ENTRUSTthat uses one such combination of methods. We developedthis instance of the methodology with the aim to validateENTRUST and to ease its adoption.

Our ENTRUST instance supports the engineering of self-adaptive systems with the architecture shown in Fig. 7.The reusable verified controller platform at the core of thisarchitecture comprises:

1) A Trusted Virtual Machine that directly interprets andexecutes models of the four steps from the MAPE controlloop5 (i.e., the ENTRUST controller models).

2) A Probabilistic Verification Engine that is used to verifystochastic models of the controlled system and its envi-ronment during the analysis step of the MAPE loop.

Using the Trusted Virtual Machine for controller model inter-pretation eliminates the need for a model-to-text transfor-mation of the controller models into executable code, whichis a complex, error-prone operation. Not having to devisethis transformation and to provide assurance evidence for itare major benefits of our ENTRUST instance. Although westill need assurance evidence for the virtual machine, this

5. Hence the controller models are depicted as software componentsin Figure 7.

Controller

Controlled software system

Sensors Effectors

ProbabilisticVerification Engine

TrustedVirtual Machine

Monitor Analyzer Planner Executor

Controller models

Verified controller platform

Knowledge Repository

Systemrequirements

Stochasticsystem&env.models

Partialassuranceargument

Adaptationassuranceevidence

Dynamicassuranceargument

Fig. 7. Architecture of an ENTRUST self-adaptive system

was obtained when we developed and verified the virtualmachine,6 and is part of the reusable platform assuranceevidence for the ENTRUST instance.

The Probabilistic Verification Engine consists of theverification libraries of the probabilistic model checkerPRISM [75] and is used by the analysis step of the MAPEcontrol loop. As such, our ENTRUST instance works with:

1) Stochastic finite state transition models of the con-trolled system and the environment, defined inthe PRISM high-level modelling language. Incom-plete versions of these models are devised inStage 1 of ENTRUST, and have their unknownsresolved at runtime. All types of models that PRISMcan analyse are supported, including discrete-and continuous-time Markov chains (DTMCs andCTMCs), Markov decision processes (MDPs) andprobabilistic automata (PAs).

2) Runtime-assured system requirements expressedin the appropriate variant of probabilistic tempo-ral logic, i.e., probabilistic computation tree logic(PCTL) for DTMCs, MDPs and PAs, and continuousstochastic logic (CSL) for CTMCs.

This makes our instantiation of the generic ENTRUSTmethodology applicable to self-adaptive systems whosenon-functional (e.g., reliability, performance, resource usageand cost-related) requirements can be specified in the above

6. This assurance evidence is in the form of a comprehensive testsuite and a report describing its successful execution by the virtualmachine, both of which are available on our ENTRUST project websiteat https://www-users.cs.york.ac.uk/simos/ENTRUST/.

https://www-users.cs.york.ac.uk/simos/ENTRUST/

9

TABLE 1Stages of the tool-supported instance of the ENTRUST methodology

Stage Type Description Supporting tool(s)

1 tool supported Timed automata controller models developed from UPPAAL templates UPPAALIncomplete stochastic models of the controlled system and environmentdeveloped based on system specification and domain knowledge

PRISM

2 tool supported Controller models verified to obtain controller assurance evidence UPPAAL3 manual Partial assurance argument devised from GSN assurance argument pattern –4 manual Controller enacted by integrating the verified controller models and platform –5 manual Controlled system, controller and knowledge repository deployed –6 automated MAPE control loop continually executed to ensure the system requirements PRISM & ENTRUST

controller platform7 automated GSN dynamic assurance argument generated ENTRUST controller

platform

logics, and whose behaviour related to these requirementscan be described using stochastic models. As shown bythe recent work of multiple research groups (e.g., [14],[19], [26], [42], [45], [48], [86], [96]), this represents a broadand important class of self-adaptive software that includesa wide range of service-based systems, web applications,resource management systems, and embedded systems.

Also developed in Stage 1 of ENTRUST, the four con-troller models form an application-specific network of inter-acting timed automata [2], and are expressed in the mod-elling language of the UPPAAL verification tool suite [6].

Accordingly, UPPAAL is used in Stage 2 of ENTRUSTto verify the compliance of the controller models withthe generic controller requirements and with any systemrequirements that can be assured at design time. These re-quirements are defined in computation tree logic (CTL) [29].

In Stage 3 of our ENTRUST instance, a partial assuranceargument is devised starting from an assurance argumentpattern represented in goal structuring notation (GSN) [68].GSN is a community standard [56] that is widely used forassurance case development in industry [94].

The controller enactment from Stage 4 involves integrat-ing the timed-automata controller models with our verifiedcontroller platform.

In Stage 5 of ENTRUST, the controlled software systemand its enacted controller are deployed, together with aKnowledge Repository that supports the operation of thecontroller. Initially, this repository contains: (i) the partialassurance argument from Stage 3; (ii) the system require-ments to be assured at runtime; and (iii) the (incomplete)stochastic system and environment models from Stage 1.

During the execution of the MAPE loop in Stage 6 ofENTRUST, the Monitor obtains information about the sys-tem and its environment through Probes. This information isused to resolve the unknowns from the stochastic modelsof the controlled system and its environment. Examplesof such unknowns include probabilities of transition to‘failure’ states for a DTMC, MDP or PA, rates of transition to‘success’ states for a CTMC, and sets of states and transitionsmodelling certain system behaviours. After each update ofthe stochastic system and environment models, the Analyzerreverifies the compliance of the self-adaptive system withits runtime-assured requirements. When the requirementsare no longer met, the Analyzer uses the verification resultsto identify a new system configuration that restores this

compliance, or to find out that such a configuration does notexist and to select a predefined failsafe configuration. Thestep-by-step actions needed to achieve the new configura-tion are then established by the Planner and implemented bythe Executor through the Effectors of the controlled system.

Using the Probabilistic Verification Engine enables the An-alyzer and Planner to produce assurance evidence justifyingtheir selection of new configurations and of plans for transi-tioning the system to these configurations, respectively. Thisadaptation assurance evidence is used to synthesise a fully-fledged, dynamic GSN assurance argument in Stage 7 ofour ENTRUST instance. As indicated in Figure 7, versionsof the adaptation assurance evidence and of the dynamicassurance argument justifying each reconfiguration of theself-adaptive system are stored in the Knowledge Repository.

The implementation of the ENTRUST stages in our tool-supported instance of the methodology is summarised inTable 1 and described in further detail in Section 5.2. TheUUV system introduced in Section 3.1 is used to supportthis description.

5.2 Stage Descriptions

5.2.1 Development of Verifiable ModelsController models. We devised two types of templates forthe four controller models from Fig. 7: (i) event triggered,in which the monitor automaton is activated by a sensor-generated signal indicating a change in the managed systemor the environment; and (ii) time triggered, in which themonitor is activated periodically by an internal clock. Theevent-triggered automaton templates are shown in Fig. 8using the following font and text style conventions:

• Sans-serif font is used to annotate states with the atomicpropositions (i.e. boolean properties) that are true inthose states, e.g. PlanCreated from the Planner automa-ton;• Italics text is used for the guards that annotate state

transitions with the conditions which must hold forthe transitions to occur, e.g. time≤MAX TIME from theAnalyzer automaton;• State transitions are additionally annotated with the

actions executed upon taking the transitions, and theseactions are also shown in sans-serif font, e.g. time=0 toinitialise a timer in the Monitor automaton;

10

(a) Monitor

WaitP

plannerCleanup()

Application-specificplanner

Plan

PlanCreated

startPlanning?

startExecuting!

(c) Planner

executorInit()

executorCleanup()planExecuted!

Application-specificexecutor

WaitE

Execute

PlanExecuted

startExecuting?

<executorSignal1!>

<executorSignalm!>

… … …

(d) Executor

startAnalysis!

WaitM ProcessSensorData CheckMprocess()

�analysisRequired()

monitorCleanup()

<sensorSignal1?>

<sensorSignaln?>

...

MonitorFinished

analysisRequired()

StartAnalysis

Key:

Automaton stateState transition

analysisRequired() Guard

analyse()

startAnalysis!

ActionstartAnalysis?

Sent signalReceived signal

Initial state

Atomic propositionPlanCreated

time=0

startPlanning!

startAnalysis?WaitA

CheckA Analyse

StartVerif

analyse()adaptationRequired()

EndVerifverify!

verifDone?

�adaptationRequired()

Adapt

analyserCleanup()

AnalysisFinished

(b) Analyzer

WaitVeriftime ≤ MAX_TIME

time > MAX_TIMEuseFailsafeConfig()

Fig. 8. Event-triggered MAPE model templates

(a) Monitor

(c) Planner (d) Executor

UUV planner

ChangeSpeed

WaitP

plannerCleanup()

Plan

PlanCreated

addStepChangeSpeed()

sensorID==SENSORS-1

ChangeSensorsConfiguration

CheckSpeedSensorsConfigurationCompleted

changeSensorsConfig() sensorID<SENSORS -1

step==TURN_ON

step==TURN_OFF

step==DO_NOTHING

�changeSpeed()

changeSpeed()

�changeSensorsConfig()

addStepSensorOff(sensorID)

addStepSensorOn(sensorID)

sensorID=0step=checkConfig(sensorID)

sensorID++

startPlanning?

startExecuting!

UUV executor

WaitE

PlanExecuted

Execute

executorInit()startExecuting?


�allPlanStepsExecuted()

allPlanStepsExecuted()

planStep=nextPlanStep()data=nextPlanData()

planStep==SENSOR_ON

planStep==SENSOR_OFF

planStep==CHANGE_SPEED

ExecutePlanStep

SensorOn

SensorOff

ChangeSpeed

sensorID=data

sensorID=data

newSpeed=datachangeSpeed!

sensorOFF!

sensorON!

startAnalysis!


�analysisRequired()

monitorCleanup()

newRate?

MonitorFinished

analysisRequired()

StartAnalysis

time=0

startPlanning!

startAnalysis?WaitA

CheckA Analyse

StartVerif


EndVerifverify!

verifDone?

�adaptationRequired()

Adapt

analyserCleanup()

AnalysisFinished

(b) Analyzer

WaitVeriftime ≤ 2

time > 2useFailsafeConfig()

Fig. 9. UUV MAPE automata that instantiate the event-triggered ENTRUST model templates

• Bold text is used for the synchronisation channels be-tween two automata—these channels are specified aspairs comprising a ‘!’-decorated sent signal and a ‘?’-decorated received signal with the same name, e.g.,startAnalysis! and startAnalysis? from the monitor andanalyzer automata, respectively. The two transitions as-sociated with a synchronisation channel can only betaken at the same time.

Finally, signals in angle brackets ‘〈〉’ are placeholders forapplication-specific signal names, and guards and actionsdecorated with brackets ‘()’ represent application-specific C-style functions.

To specialise these model templates for a particularsystem and application, software engineers need: (a) toreplace the signal placeholders with real signal names; (b) todefine the guard and action functions; and (c) to devise theautomaton regions shaded in Fig. 8. For example, for the

monitor automaton the engineers first need to replace theplaceholders 〈sensorSignal1?〉, . . . , 〈sensorSignaln?〉 withsensor signals announcing relevant changes in the managedsystem. They must then implement the functions process(),analysisRequired() and monitorCleanup(), whose roles are toprocess the sensor data, to decide if the change specified bythis data requires the “invocation” of the analyzer throughthe startAnalysis! signal, and to carry out any cleanupthat may be required, respectively. Details about the otherautomata from Fig. 8 are available on our project website,which also provides implementations of these MAPE modeltemplates in the modelling language of the UPPAAL verifi-cation tool suite [6].

EXAMPLE 1. We instantiated the ENTRUST model templatesfor the UUV system from Section 3.1, obtaining the au-tomata shown in Fig. 9. The signal newRate? is the only sen-sor signal that the monitor automaton needs to deal with, by

11TABLE 2

Stochastic models supported by the ENTRUST instance, with citationsof representative research that uses them in self-adaptive systems

Type of stochastic model Non-functional require-ment specification logic

Discrete-time Markov chains[14], [22], [42], [44], [45], [55]

PCTLa, LTLb, PCTL*c

Markov decision processes [48] PCTLa, LTLb, PCTL*c

Probabilistic automata [20], [66] PCTLa, LTLb, PCTL*c

Continuous-time Markov chains[18], [21], [52]

CSLd

Stochastic games [25], [26] rPATLe

aProbabilistic Computation Tree Logic [8], [57]bLinear Temporal Logic [84]cPCTL* is a superset of PCTL and LTLdContinuous Stochastic Logic [3], [4]ereward-extended Probabilistic Alternating-time Temporal Logic [27]

reading a new UUV-sensor measurement rate (in process())and checking whether this rate has changed to such extentthat a new analysis is required (in analysisRequired()). Ifanalysis is required, the analyzer automaton sends a verify!signal to invoke the runtime verification engine, and thusverifies which UUV configurations satisfy requirements R1and R2 and with what cost . The function analyse() uses theverification results to select a configuration that satisfies R1and R2 with minimum cost (cf. requirement R3). If no suchconfiguration exists or the verification does not completewithin 2 seconds and the guard ‘time>2’ is triggered, azero-speed configuration is selected (cf. requirement R4).If the selected configuration is not the one in use, adap-tationRequired() returns true and the startPlanning! signalis sent to initiate the execution of the planner automaton.The planner assembles a stepwise plan for changing to thenew configuration by first switching on any UUV sensorsthat require activation, then switching off those that areno longer needed, and finally adjusting the UUV speed.These reconfiguration steps are carried out by the execu-tor automaton by means of sensorON!, sensorOFF! andchangeSpeed! signals handled by the effectors from Fig. 7,as described in Section 5.2.4.

Parametric stochastic models. These models used by theENTRUST control loop at runtime are application specific,and need to be developed from scratch. Their parameterscorrespond to probabilities or rates of transition betweenmodel states, and are continually estimated at runtime,based on change information provided by the sensors of thecontrolled system. As such, the verification of these mod-els at runtime enables the ENTRUST analyzer to identifyconfigurations it can use to meet the system requirementsafter unexpected changes, as described in detail in [14], [19],[21], [42], [44]. The types of stochastic models supported byour ENTRUST instance are shown in Table 2. As illustratedby the research work cited in the table, the temporal logicsused to express the properties of these models support thespecification of numerous performance, reliability, safety,resource usage and other non-functional requirements thatrecent surveys propose for self-adaptive systems [28], [108].

To ensure the accuracy of the stochastic models de-scribed above, ENTRUST can rely on recent advances indevising these models from logs [55], [83] and UML activity

s0 s1 s2 s3 s5

s4s6

xi

1−xi

ri pi

1−pi1

11

1eoffi

ei 1

{starti} {oni}

{offi}

{accuratei}{donei}

{inaccuratei}

{readi}eoni

Fig. 10. CTMC model Mi of the i-th UUV sensor, adopted from [52]

diagrams [16], [50], and in dynamically and accurately up-dating their parameters based on sensor-provided runtimeobservations of the controlled system [15], [22], [42], [46].

EXAMPLE 2. Fig. 10 shows the CTMC model Mi of the i-th UUV sensor from our running example. From the initialstate s0, the system transitions to state s1 or s6 if the sensoris switched on (xi = 1) or off (xi = 0), respectively. Thesensor takes measurements with rate ri, as indicated bythe transition s1 → s2. A measurement is accurate withprobability pi as shown by the transition s2 → s3; wheninaccurate, the transition s2 → s4 is taken. While the sensoris active this operation is repeated, as modelled by thetransition s5 → s1. The model is augmented with tworeward structures. A “measure” structure, shown in a dashedrectangular box, associates a reward of 1 to each accuratemeasurement taken. An “energy” structure, shown in solidrectangular boxes, associates the energy used to switch thesensor on (eon

i ) and off (eoffi ) and to perform a measurement

(ei) with the transitions modelling these events. The modelM of the n-sensor UUV is given by the parallel compositionof the n sensor models: M = M1||...||Mn; and the QoSsystem requirements are specified using CSL as follows:R1: R measure

≥20 [C≤10/sp ]

R2: R energy≤120 [C≤10/sp ]

R3: minimise(w1E+w2sp−1), where E=R energy

=? [C≤10/sp ]

where 10/sp is the time taken to travel 10m at speed sp.As requirement R4 is a failsafe requirement, we verify itat design time as explained in the next section, so it is notencoded into CSL.

5.2.2 Verification of Controller ModelsDuring this ENTRUST stage, a trusted model checker isused to verify the network of MAPE automata devised inthe previous section. This verification yields evidence thatthe MAPE models satisfies a set of key safety and livenessproperties that may include both generic and application-specific properties. Table 3 shows a non-exhaustive list ofgeneric properties that we assembled for the current versionof ENTRUST. Although these properties are application-independent, verifying that an ENTRUST controller sat-isfies them is possible only after its application-specificMAPE models were devised. This involves completing theapplication-specific parts of the planner and executor au-tomata, and implementing the functions for the guards andactions from all the model templates.

Additionally, automata that simulate the controller sen-sors, runtime probabilistic verification engine and effectorsfrom Fig. 7 need to be defined to enable this verification.The sensors, verification engine and effectors automata haveto synchronise with the relevant monitor, analyzer andexecutor signals, respectively. The sensors automaton and

12

TABLE 3Generic properties that should be satisfied by an ENTRUST controller

ID Informal description Specification in computation tree logic (CTL) [29]

P1 The ENTRUST controller is deadlock free. A� not deadlockP2 Whenever analysis is required, the Analyser eventually

carries out this action.A� (Monitor.StartAnalysis → A♦ Analyzer.Analyse)

P3 Whenever the system requirements are violated, a step-wise reconfiguration plan is eventually assembled.

A� (Analyzer.Adapt → A♦ Planner.PlanCreated)

P4 Whenever a stepwise plan is assembled, the Executoreventually implements it.

A� (Planner.PlanCreated → A♦ Executor.PlanExecuted)

P5 Whenever the Monitor starts processing the receiveddata, it eventually terminates its execution.

A� (Monitor.ProcessSensorData → A♦ Monitor.Finished)

P6 Whenever the Analyser begins the analysis, it eventuallyterminates its execution.

A� (Analyzer.Analyse → A♦ Analyzer.AnalaysisFinished)

P7 A plan is eventually created, each time the Planner startsplanning.

A� (Planner.Plan → A♦ Planner.PlanCreated)

P8 Whenever the Executor starts executing a plan, the planis eventually executed.

A� (Executor.Execute → A♦ Executor.PlanExecuted)

P9 Whenever adaptation is required, the current configura-tion and the best configuration differ.

A� (Analyzer.Adapt → currentConfig != newConfig)

verification automaton also have to exercise the possiblepaths through the monitor, analyzer and planner automata(and indirectly the executor automaton). To this end, theycan nondeterministically populate the knowledge reposi-tory with data that satisfies all the different guard combina-tions. Alternatively, a finite collection of the two automatacan be used to verify subsets of all possible MAPE paths,as long as the union of all such subsets covers the entirebehaviour space of the MAPE network of automata.

Note that these application-specific elements of theMAPE automata are much larger than the application-independent elements from the MAPE model templates.Therefore, we do not use compositional model checking[30], [66] to verify the two parts of the MAPE automataseparately, with the application-independent elements ver-ified once and for all. Such an approach would increasethe complexity of the verification task (e.g. by requiringthe identification and verification of less intuitive “assump-tions” [31] that the application-specific parts of the automataneed to “guarantee”) without any noticeable reduction inthe verification time, almost all of which would be requiredto verify the application-specific automata elements.

EXAMPLE 3. We used the UPPAAL model checker [6] toverify that the network of MAPE automata from Fig. 9(which we made available on our project website) satisfiesall the generic correctness properties from Table 3, as wellas the application-specific property

R4: A� (Analyzer.Analyse ∧ Analyzer.time>2→A♦ Planner.Plan ∧ newConfig.speed==0),

which represents the CTL encoding of requirement R4. Tocarry out this verification, we defined simple sensors, veri-fication engine and effectors automata as described above.We used a simple one-state effectors automaton with tran-sitions returning to its single state for each of the receivedsignals sensorON?, sensorOFF? changeSpeed? and planEx-ecuted?; and a finite collection of sensor–verification engineautomata pairs that together exercised all possible paths of

the MAPE automata from Fig. 9. These auxiliary UPPAALautomata are available on the project website.

5.2.3 Partial Instantiation of Assurance Argument Pattern

We used the Goal Structuring Notation (GSN) introduced inSection 2.2 to devise a reusable assurance argument pattern(cf. Section 2.3) for self-adaptive software. Unlike all existingassurance argument patterns [59], our new pattern capturesthe fact that for self-adaptive software the assurance pro-cess cannot be completed at design time. Instead, it is acontinual process where some design features and codeelements are dynamically reconfigured and executed duringself-adaptation. As such, the detailed claims and evidencefor meeting the system requirements must vary with self-adaption, and thus ENTRUST assurance cases must evolvedynamically at runtime.

The ENTRUST assurance argument pattern is shown inFig. 11. Its root goal, ReqsSatisfied, states that the systemrequirements are satisfied at all times. These requirementsare typically allocated to the software from the higher-levelsystem analysis process, so the justifications of their deriva-tion, validity and completeness are addressed as part of theoverall system assurance case (which is outside the scopeof the software assurance case). ReqsSatisfied is supportedby a sub-claim based on (i.e. in the context of) the currentconfiguration (ReqsConfiguration) and by a reconfigurationsub-claim (Reconfig). That is, the pattern shows that weare guaranteeing that the current configuration satisfiesthe requirements (in the absence of changes) and that theENTRUST controller will plan and execute a reconfigurationthat will satisfy these requirements (should a change occur).

The pattern justifies how the system requirements areachieved for each configuration by using a sub-goal Rx-Achieved for each requirement Rx. Further, a new config-uration has the potential to introduce erroneous behaviours(e.g., deadlocks). The justification for the absence of these er-rors is provided via the away goal NoErroneousBehaviour(described below). The pattern concludes with the goals

13

number of reqs

J

Justification: ReconfigSystem supports reconfiguration if current configuration

cannot meet {system requirements}

Context: ConfigDef

{current configuration}

Goal: ReqsSatisfied

formalised {system requirements} satisfied

Goal: ReqsConfiguration

{system requirements} achieved in {current configuration}

Goal: Reconfig

{system requirements} achieved via reconfiguration

Strategy: ConfigReqs

Argument over formalised requirements for {current configuration}

Goal: RxAchieved

Requirement {Rx} achieved through using {current configuration}

Away Goal: NoErroneousBehaviour

Erroneous behaviours are acceptably managed

Err. Behaviour Arg.

Context: ReqsRequirements formalised for {current configuration}

Goal: RxVerified

Requirement {Rx} verified for {current configuration}

Away Goal: ReqsPreservedByPlatformRequirement {Rx} verified for {current configuration} is implemen-ted by controlled software system

Platform Arg.

Fig. 11. ENTRUST assurance argument pattern.

RxVerified and ReqsPreservedByPlatform, which justifythe verification and the implementation of the formalisedrequirements, respectively. The away goal ReqsPreserved-ByPlatform confirms that the controlled system handlescorrectly the reconfiguration commands received througheffectors. This away goal is obtained using standard assur-ance processes, which are outside the scope of this paper.

As shown Fig. 12, the NoErroneousBehaviour awaygoal is supported by two sub-claims. The FMsManagedsub-claim uses the goals FMsIdentified and ResDerivedto state that the relevant “failure modes” for the self-adaptive system have been identified and that the sys-tem requirements fully address these failure modes. Weleave the two goals undeveloped, as they are achievedusing standard requirements engineering and assurancepractices. The EngErrorsAbsent sub-claim states that theengineering of the self-adaptive system does not intro-duce errors in the context of the ENTRUST reusable arte-facts (i.e., of our trusted virtual machine and probabilisticverification engine) and of the generic properties that anENTRUST controller has to satisfy. EngErrorsAbsent is inturn supported by two sub-goals, NoProcessError and No-Controller&SystemError. The former sub-goal is obtainedthrough using suitable software engineering processes (viathe away goal SuitableSoftEngProcess, which also cov-ers the use of the methods mentioned in Section 5.2.1to ensure the accuracy of the ENTRUST stochastic mod-els) and through avoiding methodological errors by usingthe ENTRUST methodology. The latter sub-goal, NoCon-troller&SystemError, is achieved by claims about:

1) The absence of controller errors. This is supported (i) bythe controller verification evidence from Stage 2 of EN-TRUST (cf. Fig. 6); and (ii) by the reusable platformassurance evidence, which includes (testing) evidenceabout the correct operation of the model checkers UP-PAAL and PRISM, based on their long track record ofsuccessful adoption across multiple domains and on ourown experience of using them to develop self-adaptivesystems.

2) The absence of controlled system errors, covered by theControlledSystem away goal.

The away goals SuitableSoftEngProcess and Con-trolledSystem are obtained following existing software as-surances processes, and thus we do not describe them here.

The partial instantiation of the assurance argument pat-tern in the last design-time stage of ENTRUST producesa partially-developed and partially-instantiated assurance ar-gument [36]. This includes placeholders for items of evi-dence that can only be instantiated and developed basedon operational data, i.e., the runtime verification evidencethat is generated by the analysis and planning steps of theENTRUST controller.

EXAMPLE 4. Fig. 13 shows the partially-instantiated assur-ance argument pattern for the self-adaptive UUV system, inwhich we shaded the (partially) instantiated GSN elements.To keep the diagram clear, we only show the expansion forrequirements R1 and R4, leaving R2 and R3 undeveloped.The goal R1Achieved (which needs to be further instanti-ated when the system configuration is dynamically selected)is supported by: (a) sub-claim R1Verified, whose associatedsolution placeholder R1Result remains uninstantiated andshould constantly be updated by the ENTRUST controller atruntime; and (b) the away goal ReqsPreservedByPlatformdescribed earlier in this section. The undeveloped and par-tially instantiated goals R2Achieved and R3Achieved havethe same structure as R1Achieved. In contrast, the (failsafe)goal R4Achieved is fully instantiated because the solutionR4Result, comprising UPPAAL verification evidence thatR4 is achieved irrespective of the configuration of the self-adaptive system, was obtained in the second ENTRUSTstage (verification of controller models), cf. Example 3.

5.2.4 Enactment of the Controller

In this stage, the controller from Fig. 7 is assembled byintegrating the MAPE controller models discussed in Sec-tion 5.2.1, the ENTRUST verified controller platform andapplication-specific sensor, effector and stochastic modelmanagement components. The application-specific compo-nents include generic functionality such as the signalsthrough which these components synchronise with theMAPE automata (e.g., verify? and planExecuted?). Accord-ingly, our current version of ENTRUST includes abstractJava classes that provide this common functionality. Theseabstract classes, which we made available on the projectwebsite, need to be specialised for each application. Thus,the specialised sensors and effectors must use the APIs ofthe managed software system to observe its state and envi-ronment, and to modify its configuration, respectively. Thestochastic model management component must specialise

14

Goal: NoController&SystemErrorENTRUST controller and system do not contain errors

Context: FailureModes

Relevant FMs for the SAS

Context: EngErrors Engineering errors addressed by the self-adaptive system (e.g., P1-P9 from Table 5)

Away Goal: NoErroneousBehaviourErroneous behaviours are acceptably managed

Goal: FMsIdentified

Relevant FMs correctlyidentified for the SAS

Goal: ReqsDerived

Requirements can address identified FMs

Goal: NoProcessError

ENTRUST engineeringprocess does notintroduce errors

Goal: FMsManaged

System requirements ad-dress the relevant failure modes (FMs) of the SAS

Goal: EngErrorsAbsent

Engineering errors arenot introduced in the self-adaptive system (SAS)

Context: ReusableArts Reusable software artefacts (trusted VM, probabilistic verification engine)

Goal: NoMethodologi calError

ENTRUST methodology does not introduce errors

Away Goal: SuitableSoft EngProcess

Standard software engi-neering process adopted

Soft. Eng. Process Arg.

Away Goal: ControlledSystem

Controlled system does not introduce errors

Controlled System Arg.

Goal:NoControllerError

ENTRUST controller does not contain errors

Solution: PlatfEvidence

ENTRUST platform assurance evidence

Solution: Methodology

ENTRUST methodology

Solution: ContrEvidence

ENTRUST controller assurance evidence

Fig. 12. Away goal NoErroneousBehaviour, which justifies the absence of errors due to reconfiguration and is based on the existing GSN patternHazardous Contribution Software Safety Argument from the existing GSN catalogue [59]

the probabilistic verification engine so that it instantiates theparametric stochastic models using the actual values of themanaged system and environment parameters (provided bysensors) and analyses the application-specific requirements.

EXAMPLE 5. To assemble an ENTRUST controller for theUUV system from our running example, we implementedJava classes that extend the functionality of the abstractSensors, Effectors and VerificationEngine classes from theENTRUST distribution. In addition to synchronising withthe relevant application-specific signals from the MAPEautomata (e.g., newRate?), the specialised sensors and effec-tors invoke the relevant API methods of our UUV simulator.The specialised verification engine instantiates the paramet-ric sensor models Mi from Fig. 10, 1≤ i≤n, and verifies theCSL-encoded requirements from Example 2.

5.2.5 Deployment of the Self-Adaptive System

As explained in Section 4.1.5, the role of this stage is tointegrate the ENTRUST controller and the controlled soft-ware system into a self-adaptive software system that isthen installed, preconfigured and set running. In particular,the pre-configuration must select initial values for all theparameters of the controlled system. Immediately after itstarts running and until the first execution of the MAPEcontrol loop, the system functions as a traditional, non-adaptive software system. As such, a separate assuranceargument (which is outside the scope of this paper) must bedeveloped using traditional assurance methods, to confirmthat the initial system configuration is suitable.

The newly running software starts to behave like aself-adaptive system with the first execution of the MAPEcontrol loop, as described in the next two sections.

EXAMPLE 6. For the system from our running example,we used the open-source MOOS-IvP7 platform (oceanai.mit.edu/moos-ivp) for the implementation of autonomousapplications on unmanned marine vehicles [7], and wedeveloped a fully-fledged three-sensor UUV simulator thatis available on the ENTRUST website. We then exploitedthe publish-subscribe architecture of MOOS-IvP to interfacethe ENTRUST sensors and effectors (and thus the controllerfrom Example 5) with the UUV simulator, we installedthe controller and the controlled system on a computerwith a similar spec to that of the payload computer of amid-range UUV, and we preconfigured the system to startwith zero speed and all its sensors switched off. We chosethis configuration, corresponding to initial UUV parame-ter values (x1, x2, x3, sp) = (0, 0, 0, 0), to ensure that thesystem started with a configuration satisfying its failsaferequirement R4 (cf. Section 3.1).8

5.2.6 Self-AdaptationIn this ENTRUST stage, the deployed self-adaptive systemis dynamically adjusting its configuration in line with theobserved internal and environmental changes. The use ofcontinual verification within the ENTRUST control loopproduces assurance evidence that underpins the dynamicgeneration of assurance cases in the next stage of ourENTRUST instance.

EXAMPLE 7. Consider the scenario in which the UUV systemfrom our running example comprises n = 3 sensors with:

7. Mission-Oriented Operating Suite – Interval Programming8. The use of a failsafe initial configuration is our recommended ap-

proach for ENTRUST self-adaptive systems. When this is not possible,an execution of the MAPE loop must be initiated as part of the systemstart-up, to ensure that an initial configuration meeting the systemrequirements is selected.

oceanai.mit.edu/moos-ivp

oceanai.mit.edu/moos-ivp

15

J


cannot meet UUV requirements

Context: ConfigDef

{current configuration


UUV requirements achieved in {current configuration}

Goal: ReqsSatisfied

formalised UUV requirements satisfied

Goal: Reconfig

UUV requirements achieved via reconfiguration



Err. Behaviour Arg.


Goal: R1Achieved

Requirement R1 achieved through using {current configuration}

Goal: R4Achieved

Requirement R4achieved for any configuration

Goal: R2Achieved

Requirement R2achieved through using {current configuration}

Goal: R3Achieved


Away Goal: ReqsPreservedByPlatformRequirement R1 verified for {current configuration} is implemented by controlled software system

Platform Arg.

Solution: R4Result

Verification result for CTL encoding of R4

Goal: R1Verified

Requirement R1 verified for {current

configuration}

Goal: R4Verified

Requirement R4 verified for any

configuration

Away Goal: ReqsPreservedByPlatformRequirement R4 verified for any configuration is implemented by controlled software system

Platform Arg.

Solution: R1Result

Verification result for R1



Fig. 13. Partially-instantiated assurance argument for the UUV system

initial measurement rates r1 = 5s−1, r2 = 4s−1, r3 = 4s−1;energy consumed per measurement e1 = 3J, e2 = 2.4J,e3 = 2.1J; and energy used for switching a sensor on andoff eon

1 = 10J, eon2 = 8J, eon3 = 5J and eoff

1 = 2J, eoff2 = 1.5J,

eoff3 = 1J, respectively. Also, suppose that the current UUV

configuration is (x1, x2, x3, sp) = (0, 1, 1, 2.8), and thatsensor 3 experiences a degradation such that rnew

3 = 1s−1.The ENTRUST controller gets this new measurement ratethrough the monitor. As the sensor rates differ from thosein the knowledge repository, the guard analysisRequired()returns true and the startAnalysis! signal is sent. Uponreceiving the signal, the analyser model invokes the prob-abilistic verification engine, whose analysis results for re-quirements R1–R3 are depicted in Fig. 14. The analyse() ac-tion filters the results as follows: configurations that violaterequirements R1 or R2, i.e., the shaded areas from Fig. 14aand Fig. 14b, respectively, are discarded.9 The remaining

9. Note that R1 and R2 are “conflicting” requirements, in the sensethat the configurations that satisfy R1 by the widest margin violateR2, and the other way around. In such scenarios, ENTRUST supportsthe selection of configurations based on trade-offs between the con-flicting requirements, as specified by a cost (or utility) function. Ifeither requirement became much stricter (e.g. if R1 required over 50measurements per every 10m), no configuration would satisfy bothR1 and R2. In this case, ENTRUST would choose the configurationspecified by the failsafe requirement R4, i.e. would reduce the UUVspeed to 0m/s, and would record the probabilistic model checkingevidence showing the lack of a suitable non-failsafe configuration.

configurations are feasible, so their cost (1) is computed forw1 = 1 and w2 = 200. The configuration minimising thecost (i.e., (x1, x2, x3, sp) = (1, 1, 0, 3.2) – circled in Fig. 14a-c) is selected as the best configuration. Since the best andthe current configurations differ, the analyzer invokes theplanner to assemble a stepwise reconfiguration plan withwhich i) sensor 1 is switched on; ii) next, sensor 3 is switchedoff; and iii) finally the speed is adjusted to 3.2m/s. Once theplan is assembled, the executor is enforcing this plan to theUUV system. The adaptation results from Fig. 14 providethe evidence required for the generation of the assurancecase as described next.

5.2.7 Synthesis of Dynamic Assurance Argument

The ENTRUST assurance case evolves in response to theresults of the MAPE process, e.g., time-triggered and event-triggered outputs of the monitor, the outcomes of the an-alyzer, the mitigation actions developed by the plannerand their realisation by the executor. This offers a dynamicapproach to assurance because the full instantiation of theENTRUST assurance argument pattern is left to runtime, i.e.the only stage when the evidence required to complete theargument becomes available. As such, the assurance caseresulting from this stage captures the full argument andevidence for the justification of the current configuration ofthe self-adaptive system.

EXAMPLE 8. Consider again the partially-instantiated as-surance argument pattern for our UUV system (Fig. 13).After the ENTRUST controller activities described in Exam-ple 7 conclude with the selection of the UUV configuration(x1, x2, x3, sp)= (1, 1, 0, 3.2) and the generation of runtimeverification evidence that this configuration satisfies require-ments R1–R3, this partially-instantiated assurance argumentpattern is fully instantiated as shown in Fig. 15.

5.3 Self-Adaptive Service-Based System

We complete the presentation of the tool-supported instanceof ENTRUST with a description of its use to engineer of thesecond self-adaptive system introduced in Section 3.

Stage 1 (Development of Verifiable Models) We specialised ourevent-triggered MAPE model templates for the FX system.The resulting MAPE models are shown in Fig. 16, where theshaded areas in Planner and Executor automata indicate theFX-specific steps for assembling a plan and executing theadaptation, respectively. The implementations of all guardsand actions decorated with brackets ‘()’ (which representapplication-specific C-style functions, as explained in Sec-tion 5.2.1) are available on our project website.

To model the runtime behaviour of the FX system, weused the parametric discrete-time Markov chain (DTMC)depicted in Fig. 17. In this DTMC, constant transitionprobabilities derived from system logs are associated withthe branches of the FX workflow from Fig. 5. In contrast,state transitions that model the success or failure of serviceinvocations are associated with parameterised probabilities,which are unknown until the runtime selection of the FXservices. Likewise, the “price” and (response) “time” rewardstructures (shown in solid and dashed boxes, respectively)

16

1 2 3 4 5speed [m/s]

0

40

80

120

160

200

240

280

Exp

ecte

d e

ne

rgy u

sa

ge

pe

r 1

0m

[J]

(a)

1 2 3 4 5speed [m/s]

0

20

40

60

80

Exp

ecte

d a

ccu

rate

me

asu

rem

en

ts p

er

10

m

1 2 3 4

speed [m/s]

160

200

240

280

co

st

Key: x1=1, x2=1, x3=1x1=1, x2=0, x3=1x1=0, x2=0, x3=1x1=1, x2=0, x3=0 x1=0, x2=1, x3=0 x1=0, x2=1, x3=1x1=1, x2=1, x3=0

(b) (c)

Fig. 14. Verification results for requirement (a) R1, (b) R2, and (c) cost of the feasible configurations; 21 speed values between 1m/s and 5m/s areconsidered for each of the seven combinations of active sensors, corresponding to 21× 7 = 147 alternative configurations. The best configuration(circled) corresponds to x1 = x2 = 1, x3 = 0 (i.e. UUV using only its first two sensors) and sp = 3.2m/s, and the shaded regions correspond torequirement violations.

⋮

Goal: ReqsSatisfied

formalised UUV requirements satisfied

J


cannot meet UUV requirements



Err. Behaviour Arg.

Context: ReqsRequirements formalised for configuration (1, 1, 0, 3.2)

Goal: Reconfig

UUV requirements achieved via reconfiguration


UUV requirements achieved in configuration(1, 1, 0, 3.2)

Goal: R2Achieved

Requirement R2achieved through using configuration (1, 1, 0, 3.2)

Goal: R3Achieved


Away Goal: ReqsPreservedByPlatformRequirement R1 verified for configuration (1, 1, 0, 3.2) is implemented by controlled software system

Platform Arg.

Solution: R1Result

R1 result (measurements: 21)

Solution: R4Result


Goal: R1Verified

Requirement R1 verified for config-

uration (1, 1, 0, 3.2)

Goal: R4Verified

Requirement R4 verified for config-

uration (1, 1, 0, 3.2)

Away Goal: ReqsPreservedByPlatformRequirement R4 verified for configuration (1, 1, 0, 3.2) is implemented by controlled software system

Platform Arg.

Context: ConfigDef

(x1, x2, x3, s) = (1, 1, 0, 3.2)

Goal: R1Achieved

Requirement R1 achieved through using configuration (1, 1, 0, 3.2)

Goal: R4Achieved



Argument over formalised requirements for configuration (1, 1, 0, 3.2)

⋮

Fig. 15. Fully-instantiated assurance argument for the UUV system; thesubgoals for R2Achieved and R3Achieved (not included due to spaceconstraints) are similar to those for R1Achieved, and shading is used toshow the elements instantiated at runtime

are parametric and depend on the combination of FX ser-vices dynamically selected by the ENTRUST controller.

Finally, we formalised requirements R1–R3 in rewards-augmented probabilistic computational tree logic (PCTL),

and the failsafe requirement R4 in CTL as follows:

R1: P≥0.9[F done]R2: R time

≤5 [F done]R3: minimise(w1price + w2time), where

price = R price=? [F done] and time = R time

=? [F done]

R4: A� (Analyzer.Analyse ∧ Analyzer.time>2→A♦ Planner.Plan ∧ newConfig.Order==NoSvc)

where ‘newConfig.Order==NoSvc’ signifies that no serviceis used to implement the Order operation (i.e., the operationis skipped).

Stage 2 (Verification of Controller Models) We used the modelchecker UPPAAL to verify that the MAPE automata net-work from Fig. 16 satisfies the generic controller correctnessproperties in Table 3, and the FX-specific CSL property R4.

Stage 3 (Partial Instantiation of Assurance Argument Pattern)We partially instantiated the ENTRUST assurance argumentpattern for our self-adaptive FX system, as shown in Fig. 18.

Stage 4 (Enactment of the Controller) To assemble the EN-TRUST controller for the FX system, we combined the con-troller and stochastic models from Stage 1 with our genericcontroller platform, and with FX-specific Java classes thatwe implemented to specialise the abstract Sensors, Effectorsand VerificationEngine abstract classes of ENTRUST. TheSensors class synchronises with the Monitor automatonfrom Fig. 16 through the newServicesCharacteristics! signal(issued after changes in the properties of the FX servicesare detected). In addition, the Sensors and Effectors classesuse the relevant API methods of an FX implementation thatwe developed as explained below. The specialised Verifica-tionEngine instantiates the parametric DTMC model fromFig. 17 at runtime, and verifies the PCTL formulae devisedin Stage 1 for requirements R1–R3.

Stage 5 (Deployment of the Self-Adaptive System) We imple-mented a prototype version of the FX system using Javaweb services deployed in Tomcat/Axis, and a Java FX

17

(a) Monitor

(d) Executor(c) Planner

FX planner

WaitP

plannerCleanup()

Plan

PlanCreated

startPlanning?

startExecuting!

sType==MAX_TYPE

step==DO_NOTHINGaddStep(NOTIFICATION, serviceID)step==CHANGE_NOTIFICATION

addStep(ALARM, serviceID)step==CHANGE_ALARM

addStep(FUNDAMENTAL_ANALYSIS, serviceID)step==CHANGE_FUNDAMENTAL_ANALYSIS

addStep(ORDER, serviceID)step==CHANGE_ORDER

addStep(TECHNICAL_ANALYSIS, serviceID)step==CHANGE_TECHNICAL_ANALYSIS

addStep(MARKET_WATCH, serviceID)step==CHANGE_MARKET_WATCH

step = checkConfig() sType++

FX Executor

WaitE

PlanExecuted

Execute

executePlan()startExecuting?




ChangeNotificationService

ChangeAlarmService

ChangeOrderService

ChangeTechnicalAnalysisService

ChangeFundamentalAnalysisService

ChangeMarketWatchService

changeService!

planStep=nextPlanStep()serviceType=nextPlanServiceType()serviceID=nextPlanServiceID()

planStep== ORDER

planStep== FUNDAMENTAL_ANALYSIS

planStep==TECHNICAL_ANALSYSIS

planStep== MARKET_WATCH

planStep== ALARM

planStep== NOTIFICATION

startAnalysis!


analysisRequired()

monitorCleanup()

newServicesCharacteristics?

MonitorFinished

analysisRequired()

StartAnalysis

time=0

startPlanning!

startAnalysis?WaitA

CheckA Analyse

StartVerif


EndVerifverify!

verifDone?

adaptationRequired()

Adapt

analyserCleanup()

AnalysisFinished

(b) Analyzer

WaitVeriftime ≤ 2

time > 2useFailsafeConfig()

Fig. 16. FX MAPE automata that instantiate the event-triggered ENTRUST model templates

TABLE 4Initial characteristics of the service instances used by the FX system

Operation: Market Watch Technical Analysis Fundam. Analysis Alarm Order NotificationService ID: MW0 MW1 TA0 TA1 FA0 FA1 Al0 Al1 Or0 Or1 No0 No1

response time [s] .5 .5 .6 1.0 1.6 .7 .6 .9 .6 1.3 1.8 .5reliability .976 .995 .998 .985 .998 .99 .995 .99 .995 .95 .99 .99price 5 10 6 4 23 25 15 9 25 20 5 8

Fig. 17. Parametric DTMC model of the FX system; pMW, pTA, . . . ,timeMW, timeTA, . . . , and priceMW, priceTA, . . . , represent the reliability(i.e. success probability), the response time and the price, respectively,of the implementations used for the MW, TA, . . . system services.

workflow that we integrated with the ENTRUST controllerfrom Stage 4. Our self-adaptive FX system (whose codeis available on our project website) could select from twofunctionally equivalent web service implementations foreach of the six FX services from Fig. 5, i.e. from 12 webservices with the initial characteristics shown in Table 4. Forsimplicity and without loss of generality, we installed thecomponents of the self-adaptive FX system on a single com-puter with the characteristics detailed in Section 6.2.1, andwe preconfigured the system to start by using the first webservice implementation available for each service (i.e. MW0,TA0, etc.), except for the Order service. For Order, NoSvcwas selected initially, to ensure that the failsafe requirementR4 was satisfied until a configuration meeting requirementsR1–R3 was automatically selected by the first execution ofthe MAPE loop, shortly after the system started.

The remainder two stages of ENTRUST, presented next,were continually performed by the self-adaptive FX systemas part of its operation.

Stage 6 (Self-Adaptation) In this stage, the self-adaptive FXsystem dynamically reconfigures in response to observed

18

Goal: ReqsSatisfied

formalised FX requirements satisfied

J


cannot meet FX requirements



Err. Behaviour Arg.


Goal: Reconfig

FX requirements achieved via reconfiguration

Context: ConfigDef

{current configuration

Goal: R1Achieved

Requirement R1 achieved through using {current configuration}

Goal: R4Achieved

Requirement R4achieved for any configuration




FX requirements achieved in {current configuration}

Goal: R2Achieved


Goal: R3Achieved


Away Goal: ReqsPreservedByPlatformRequirement R1 verified for {current configuration} is implemented by controlled software system

Platform Arg.

Solution: R4Result


Goal: R1Verified

Requirement R1 verified for {current

configuration}

Goal: R4Verified

Requirement R4 verified for any

configuration

Away Goal: ReqsPreservedByPlatformRequirement R4 verified for any configuration is implemented by controlled software system

Platform Arg.

Solution: R1Result

Verification result for R1

Fig. 18. Partially-instantiated assurance argument for the FX system; theelements (partially) instantiated in Stage 3 of ENTRUST are shaded.

changes in the characteristics of the web services it uses.Several such reconfigurations are described later in thepaper, in Section 6.2.1 and in Fig. 22. To illustrate this processin detail, consider the system configuration immediatelyafter change C from Fig. 22, where the FX workflow uses theservices MW1, TA0, FA0, Al0, Or0 and No1. This configura-tion is reached after the FX services, initially operating withthe characteristics from Table 4, experience degradations inthe reliability of MW0 (pnewMW0

= 0.9, change B in Fig. 22)and in the response time of FA1 (timenewFA1

= 1.2s, changeC in Fig. 22). With the FX system in this configuration,suppose that the Market Watch service MW0 recovers, i.e.,pnewMW0

= 0.976 as in Table 4. Under these circumstances,which correspond to change D from Fig. 22, the ENTRUSTcontroller receives the updated characteristics of MW0 viaits monitor. As the new service characteristics differ fromthose in the knowledge repository, the guard analysisRe-quired() holds and the startAnalysis! signal is sent. Theanalyser model receives the signal and invokes the runtimeprobabilistic verification engine, whose analysis of the FXrequirements R1–R3 over the 26 = 64 possible system con-figurations (corresponding to six services each provided bytwo implementations) is shown in Fig. 19. As part of thisanalysis, configurations that violate requirements R1 or R2(i.e., those from the shaded areas in Fig. 19a and Fig. 19b,

respectively) are discarded. The remaining configurationsare feasible, so their cost is calculated (for w1 = 1 andw2 = 2) as shown in Fig. 19c. The feasible configurationusing services MW0, TA0, FA0, Al1, Or0 and No1 has thelowest cost and is thus selected as the best system configura-tion. Since the best and the current configurations differ, theguard adaptationRequired() holds and the analyser invokesthe planner through the startPlanning! signal to assemblea stepwise reconfiguration plan through which: (i) MW0

replaces MW1; and (ii) Al1 replaces Al0. Once the plan isready, the executor automaton receives the startExecuting?signal and is ensuring the implementation of this plan bysending the signal changeService! to the system effectors.

Stage 7 (Synthesis of Dynamic Assurance Argument) The par-tially instantiated FX assurance pattern from Fig. 18 isupdated into a full assurance argument after each selectionof a new configuration by the ENTRUST controller. Thisinvolves using the new evidence generated by the runtimeprobabilistic verification engine to complete the instantia-tion of the assurance pattern. As an example, Fig. 20 showsthe complete assurance pattern synthesised as part of theconfiguration change that we have just used to illustrate theprevious stage of ENTRUST.

6 EVALUATION

This section presents our evaluation of ENTRUST. We startwith a description of our evaluation methodology in Sec-tion 6.1. Next, we detail our experimental results, and dis-cuss the findings of the ENTRUST evaluation in Section 6.2.Finally, we assess the main threats to validity in Section 6.3.

6.1 Evaluation Methodology

To evaluate the effectiveness and generality of ENTRUST,we used our methodology and its tool-supported instance toengineer the two self-adaptive software systems from Sec-tion 3. In each case, we first implemented a simple version ofthe managed software system using an established develop-ment platform for its domain (cf. Example 6 and Section 5.3– Stage 5). We then used our methodology to develop anENTRUST controller and a partially-instantiated assuranceargument pattern for the system. Next, we deployed theENTRUST self-adaptive system in a realistic environmentseeded with simulated changes specific to the applicationdomain. Finally, we examined the correctness and efficiencyof the adaptation and of the assurance cases produced byENTRUST in response to each of these unexpected environ-mental changes. The experimental results are discussed inSection 6.2. The aim of our evaluation was to answer thefollowing research questions.

RQ1 (Correctness): Are ENTRUST self-adaptive systemsmaking the right adaptation decisions and generatingvalid assurance cases?

RQ2 (Efficiency): Does ENTRUST provide design-time andruntime assurance evidence with acceptable overheadsfor realistic system sizes?

RQ3 (Generality): Does ENTRUST support the develop-ment of self-adaptive software systems and dynamicassurance cases across application domains?

19

(a)

Re

liab

ility

Configuration index

0.950

0.925

0.900

0.875

0 20 40 60

(b)

Configuration index

Re

sp

on

se

Tim

e [

s]

0 20 40 60

6.5

6.0

5.5

5.0

(c)

Configuration index

co

st

0 20 40 60

85

80

75

70

Fig. 19. Runtime verification results for FX requirement (a) R1, (b) R2, and (c) R3—cost of the feasible configurations, where the configuration indexi1i2i3i4i5i6 in number base 2 corresponds to the FX configuration that uses services MWi1 , TAi2 , FAi3 , Ali4 , Ori5 and Noi6 . The best configuration(circled) has index 5(10) = 000101(2), corresponding to MW0, TA0, FA0, Al1, Or0 and No1. Shaded regions correspond to requirement violations.

⋮ ⋮

Goal: ReqsSatisfied

formalised FX requirements satisfied

J


cannot meet FX requirements



Err. Behaviour Arg.

Context: ReqsRequirements formalised for configuration (MW0, TA0, FA0, Al1, Or0, No1)

Goal: Reconfig

FX requirements achieved via reconfiguration


FX requirements achieved in configuration(MW0, TA0, FA0, Al1, Or0, No1)

Goal: R2AchievedRequirement R2achieved through using configuration (MW0, TA0, FA0, Al1, Or0, No1)


Away Goal: ReqsPreservedByPlatformRequirement R1 verified for configuration (MW0,TA0,FA0,Al1, Or0, No1) is implemented by controlled software system

Platform Arg.

Solution: R1Result

R1 result (reliability: 0.926 )

Solution: R4Result


Goal: R1VerifiedRequirement R1 verified for config-

uration (MW0, TA0, FA0, Al1, Or0, No1)

Goal: R4VerifiedRequirement R4 verified for config-

uration (MW0, TA0, FA0, Al1, Or0, No1)

Away Goal: ReqsPreservedByPlatformRequirement R4 verified for configuration (MW0,TA0,FA0,Al1, Or0, No1) is implemented by controlled software system

Platform Arg.

Context: ConfigDef(MW, TA, FA, Al, Or, No) = (MW0, TA0, FA0, Al1, Or0, No1)


Goal: R4AchievedRequirement R4 achieved through using configuration (MW0, TA0, FA0, Al1, Or0, No1)


Argument over formalised requirements for configura- (MW0, TA0, FA0, Al1, Or0, No1)

Fig. 20. Fully-instantiated assurance argument for the FX system; thesubgoals for R2Achieved and R3Achieved (not included due to spaceconstraints) are similar to those for R1achieved, and shading is used toshow the elements instantiated at runtime

As the focus of our evaluation was the ENTRUST method-ology and its tool-supported instance, we necessarily made

a number of assumptions. In particular, we assumed thatestablished assurance processes could be used to constructassurance arguments for all aspects of the controlled sys-tems from our case studies, including their correct design,development, operation, ability to respond to effector re-quests, and any real-time considerations associated withachieving the new configurations decided by the ENTRUSTcontroller. As such, these aspects are outside the scope ofENTRUST and are not covered in our evaluation. We furtherassumed that the derivation, validity, completeness andformalisation of the self-adaptive system requirements areaddressed as part of the overall system assurance cases forthe two case studies, and therefore also outside the scope ofour evaluation of ENTRUST.

6.2 Experimental Results and Discussion6.2.1 RQ1 (Correctness)To answer the first research question, we carried out exper-iments that involved running the UUV and FX systems inrealistic environments comprising (simulated) unexpectedchanges specific to their domains. For the UUV system,the experiments were seeded with failures including sud-den degradation in the measurement rates of sensors andcomplete failures of sensors, and with recoveries from theseproblems. For the FX system, we considered variations inthe response time and the probability of successful comple-tion of third-party service invocation. All the experimentswere run on a MacBook Pro with 2.5 GHz Intel Core i7processor, and 16 GB 1600 MHz DDR3 RAM.

For the UUV system, we described a concrete changescenario and the resulting self-adaptation process and gen-eration of an assurance case in Examples 7 and 8, earlier inthe paper. The complete set of change scenarios we used inthis experiment is summarised in Fig. 21, which depicts thechanges in the sensor rates and the new UUV configurationsselected by the ENTRUST controller. The labels A–H fromFig. 21 correspond to following key events:A) The UUV starts with the initial state and configuration

from Example 7;

20

sp

[m

/s]

Time [s]

r 3 [

s-1]

GCB

r 1 [

s-1]

Ar 2

[s

-1]

D E F H

Fig. 21. Change scenarios for the self-adaptive UUV system over 2100seconds of simulated time. Extended shaded regions indicate the sen-sors switched on at each point in time, and narrow shaded areas showthe periodical testing of sensors switched off due to degradation (todetect their recovery).

B) Sensor 3 experiences the degradation described in Exam-ple 7 (rnew3 =1), so the higher-rate but less energy efficientsensor 1 is switched on (allowing a slight increase inspeed to sp=3.2m/s) and sensor 3 is switched off;

C) Sensor 3 recovers and the initial configuration is re-sumed;

D) Sensor 2 experiences a degradation, and is replaced bysensor 1, with the speed increased to sp=3.1m/s;

E) Sensor 2 recovers and the initial configuration is re-sumed;

F) Both sensor 2 and sensor 3 experience degradations, sosensor 1 alone is used, with the UUV travelling at a lowerspeed sp=2.1m/s;

G) Periodic tests (which involve switching sensors 2 and 3on for short periods of time) are carried out to detect apotential recovery of the degraded sensors;

H) Sensors 2 and 3 resume operation at nominal rates andthe initial UUV configuration is reinstated.

If the UUV system was not self-adaptive, it would haveto operate with a fixed configuration, which would leadto requirement violations for extended periods of time. Tounderstand this drawback of a non-adaptive UUV, considerthat its fixed configuration is chosen to coincide with theinitial UUV configuration from Fig. 21 (i.e. (x1, x2, x3, sp) =(0, 1, 1, 2.8)) – a natural choice because manual analysiscan be used to find that this configuration satisfies theUUV requirements at deployment time. However, with thisfixed configuration, the UUV will violate its throughputrequirement R1 whenever one or both of UUV sensors 1and 2 experience a non-trivial degradation, i.e. in the timeintervals B–C (only 13 measurements per 10m instead of therequired 20 measurements, according to additional analysiswe carried out), D–E (only 15 measurements per 10m)and F–H (only 7 measurements per 10m) from Fig. 21.Although a different fixed configuration may always meet

requirement R1, such a configuration would violate otherrequirement(s), e.g. having all three UUV sensors switchedon meets R1 but violates the resource usage requirement R2at all times.

Finally, we performed experiments to assess how theadaptation decisions may be affected by changes in theweights w1, w2 from the UUV cost (1) and the energyusage of the n UUV sensors. We considered UUVs withn ∈ {3, 4, 5, 6} sensors, and for each value of n we carriedout 30 independent experiments with the weights w1, w2

randomly drawn from the interval [1, 500], and the energyconsumption for taking a measurement and switching onand off a sensor (i.e., ei, eon

i and eoffi , 1 ≤ i ≤ n) randomly

drawn from the interval [0.1J, 10J ]. The experimental re-sults (available, together with the PRISM-generated assur-ance evidence, on the project website) show that ENTRUSTsuccessfully reconfigured the system irrespective of theweight and energy usage values. In particular, if a config-uration satisfying requirements R1–R3 existed for a specificchange and system characteristics combination, ENTRUSTreconfigured the UUV system to use this configuration.As expected, the configuration minimising the cost (1) de-pended both on the values of the weights w1, w2 and onthe sensor energy usage. When no configuration satisfyingrequirements R1–R3 was available, ENTRUST employed thezero-speed failsafe configuration from requirement R4 untilconfigurations satisfying requirements R1–R3 were againpossible after a sensor recovery.

For the FX system, a concrete change scenario is detailedin Section 3.2, and the complete set of change scenarios usedin our experiments is summarised in Fig. 22, where labelsA–G correspond to the following events:

A) The FX starts with the initial services characteristicsfrom Table 4 and uses a configuration comprising theservices MW0, TA0, FA0, Al1, Or0 and No1, which satisfiesrequirements R1 and R2 and optimises R3;

B) The Market Watch service MW0 experiences a significantreliability degradation (pnewMW0

= 0.9), so FX starts usingthe significantly more reliable MW1, and thus “affords”to also switch to the slightly less reliable but fasterFundamental Analysis service FA1 in order to minimisethe cost defined in requirement R3;

C) Due to an increase in response time of FundamentalAnalysis service FA1 (timenewFA1

= 1.2s), the FX switchesto using FA0 and also replaces the Alarm service Al1 withthe faster but more expensive service Al0 (to meet thetiming requirement R2);

D) The Market Watch service MW0 recovers, so FX switchesback to this services and also resumes using the lessreliable Alarm service Al1;

E) The Technical Analysis service TA0 and the Notificationservice No1 exhibit unexpected degradations in reliabil-ity (pnewTA0

= 0.98) and in response time (timenewNo1 = 1s),respectively, so the FX system self reconfigures to useMW0, TA1, FA1, Al0, Or0 and No0;

F) As a result of a reliability degradation in the Orderservice Or0 (pnewOr0

= 0.91) and recovery of the TechnicalAnalysis service TA0, the FX system replaces servicesMW0, TA1, FA1 and Or0 with MW1, TA0, FA0 and Or1,

21

Time [s]

FA0

FA1

FundamentalAnalysis C

BMW0

MW1

MarketWatch

D

TA0

TA1

TechnicalAnalysis

E F

Al0

Al1Alarm A

Or0

Or1

Order F G

No0

No1

Notification EG

Fig. 22. Change scenarios for the self-adaptive FX system, with theinitial services characteristics shown in Table 4. The thick continuouslines depict the services selected at each point in time.

respectively;G) All the degraded services recover, so the initial configu-

ration MW0, TA0, FA0, Al1, Or0 and No1 is reinstated.

As in the case of the UUV system, a non-adaptive FXversion will fail to meet the system requirements for ex-tended periods of time. For example, choosing to alwaysuse the initial FX configuration from Fig. 22 would lead toa violation of the reliability requirement R1 while serviceMW0 experiences a significant reliability degradation in thetime interval B–D. While using service MW1 instead of MW0

would avoid this violation, MW1 is more expensive but nofaster than MW0 (cf. Table 4) so its choice would increase thecost (2), thus violating the cost requirement R3 in the timeinterval A–B.

For each change scenario from our experiments withinthe two case studies (cf. Figs. 21 and 22), we performedtwo checks. For the former check, we confirmed that theENTRUST controller operated correctly. To this end, weestablished that the change was accurately reported by thesensors and correctly processed by the monitor, leading theanalyzer to select the right new configuration, for which acorrect plan was built by the planner and implemented bythe executor.

For the latter check, we determined the suitability of theENTRUST assurance cases. We started from the guidelinesset by safety and assurance standards, which highlight theimportance of demonstrating, using available evidence, thatan assurance argument is compelling, structured and valid[32], [77], [103]. Also, we considered the fact that ENTRUSThas been examined experimentally but has not been testedin real-world scenarios to generate the industrial evidencenecessary before approaching the relevant regulator. How-ever, our preliminary results show, based on formal design-time and runtime evidence, that the primary claim of EN-TRUST assurance cases is supported by a direct and robustargument. Firstly, the argument assures the achievementof the requirements either based on a particular activeconfiguration or through reconfiguration, while maintaininga failsafe mechanism. Secondly, the argument and patternsare well-structured and conform to the GSN community

ENTRUST controller generic properties

100

140

180

220

P1 P2 P3 P4 P5 P6 P7 P8 P9

CP

U T

ime

[s]

300

400

500

600

700

P1 P2 P3 P4 P5 P6 P7 P8 P9

UUV System FX System

Fig. 23. CPU time for the UPPAAL verification of the generic controllerproperties in Table 3 (box plots of 10 independent measurements)

standard [56]. Thirdly, ENTRUST provides rigorous assess-ments of validity not only at design time but also through-life, by means of monitoring and continuous verificationthat assess and challenge the validity of the assurance casebased on actual operational data. This continuous assess-ment of validity is a core requirement for safety standards,as highlighted recently for medical devices [89]. As such, ourapproach satisfies five key principles of dynamic assurancecases [36]:• continuity and updatability, as evidence is generated and

updated at runtime to ensure the continuous validityof the assurance argument (e.g. the formal evidence forsolution R1Result from the UUV argument in Fig. 15,which satisfies a system requirement given the currentconfiguration);• proactivity, since the assurance factors that provide the

basis for the evidence in the assurance argument areproactively identified (e.g. the ConfigDef context fromthe UUV argument in Fig. 15, which captures the pa-rameters of the current configuration);• automation, because the runtime evidence is dynamically

synthesised by the MAPE controller;• formality, as the assurance arguments are formalised

using the GSN standard.In conclusion, subject to the limitations described above,

our experiments provide strong empirical evidence thatENTRUST self-adaptive systems make the right adaptationdecisions and generate valid assurance cases.

6.2.2 RQ2 (Efficiency)To assess the efficiency of the ENTRUST generation ofassurance evidence, we measured the CPU time taken by(i) the design-time UPPAAL model checking of the genericcontroller properties from Table 3; and (ii) the runtimeprobabilistic model checking performed by the ENTRUSTanalyzer. Fig. 23 shows the time taken to verify the genericcontroller properties from Table 3 for a three-sensor UUVsystem, and for an FX system comprising two third-partyimplementations for each workflow service. With typicalCPU times of several minutes per property and a maximumbelow 12 minutes, the overheads for the verification of allcontroller properties are entirely acceptable.

The CPU times required for the runtime probabilisticmodel checking of the QoS requirements for alternative con-

22

UUV System FX System

Fig. 24. CPU time for the runtime probabilistic model checking of theQoS requirements after changes (box plots based on 10 system runscomprising seven changes each—70 measurements in total)

figurations of the two systems (Fig. 24) have values below1.5s and 2s, respectively. These runtime overheads, whichcorrespond to under 10ms for the verification of a UUVconfiguration and under 30ms for the verification of an FXconfiguration, are acceptable for two reasons. First, failuresand other changes requiring system reconfigurations areinfrequent in the systems for which ENTRUST is intended.Second, these systems have failsafe configurations that theycan temporarily assume if needed during the infrequentreverifications of the ENTRUST stochastic models.

As shown in Fig. 24, we also ran experiments to assessthe increase in runtime overhead with the system sizeand number of alternative configurations, by consideringUUVs with up to six sensors, and FX system variants withup to five implementations per service. Typical for modelchecking, the CPU time increases exponentially with thesesystem characteristics. This makes the current implemen-tation of our ENTRUST instance suitable for self-adaptivesystems with up to hundreds of configurations to analyseand select from at runtime. However, our recent workon compositional [20], incremental [66], caching-lookahead[52] and distributed [18] approaches to probabilistic modelchecking and on metaheuristics for probabilistic model syn-thesis [53] suggests that these more efficient model check-ing approaches could be used to extend the applicabilityof our ENTRUST instance to much larger configurationspace sizes. As an example, in [52] we used caching ofrecent runtime probabilistic model checking results andanticipatory verification of likely future configurations (i.e.lookahead) to significantly reduce the mean time required toselect new configurations for a variant of our self-adaptiveUUV system (by over one order of magnitude in manyscenarios). Integrating ENTRUST with these approaches iscomplementary to the purpose of this paper and representsfuture work.

6.2.3 RQ3 (Generality)

As shown in Table 5, we used ENTRUST to develop an em-bedded system from the oceanic monitoring domain, and aservice-based system from the exchange trade domain. Self-adaptation within these systems was underpinned by theverification of continuous- and discrete-time Markov chains,respectively; and the requirements and types of changes forthe two systems differed. Finally, the ENTRUST assurance

TABLE 5Comparison of self-adaptive systems used to evaluate ENTRUST

UUV FX

Type embedded system service-based system

Domain oceanic monitoring exchange trade

Requirements throughput, resource use,cost, safety

reliability, response time,cost, safety

Sensor data UUV sensor measure- service response timement rate and reliability

Adaptation switch sensors on/off, change service instanceactions change speed

Uncertaintymodelling

CTMC models of UUVsensors

DTMC model of system

Assurance testing evidence for correct operation of trustedevidence virtual machine; model checking evidence forbefore correctness of MAPE controller and for UUV/FXdeployment safety requirement

Assurance probabilistic model probabilistic modelevidence checking evidence for checking evidence forobtained throughput, resource use reliability, response timeat runtime and cost requirements and cost requirements

arguments for the two systems were based on evidenceobtained through testing, model checking, and probabilisticmodel checking. Although evaluation in additional areas isneeded, these results indicate that our ENTRUST instancecan be used across application domains.

To assess the overall generality of ENTRUST, we notethat probabilistic model checking can effortlessly be re-placed with simulation in our experiments, because theprobabilistic model checker PRISM can be configured touse discrete-event simulation instead of model checkingtechniques. Using this PRISM configuration requires nochange to the Markov models or probabilistic temporal logicproperties we analysed at runtime. As for any simulation,the analysis results would be approximate, but would beobtained with lower overheads than those from Fig. 24.

The uncertainties that affect self-adaptive systems areoften of a stochastic nature, and thus the use of stochasticmodels and probabilistic model checking to analyse the be-haviour of these systems is very common (e.g. [14], [19], [26],[42], [45], [48], [86], [96]). As such, our ENTRUST instance isapplicable to a broad class of self-adaptive systems.

Nevertheless, other methods have been used to synthe-sise MAPE controllers and to support their operation. Manysuch methods (e.g. based on formal proof, traditional modelchecking, other simulation techniques and testing) are de-scribed in Section 7. Given the generality of ENTRUST,these methods could potentially be employed at designtime and/or at runtime by alternative instantiations ofENTRUST, supported by different modelling paradigms, re-quirement specification formalisms, and tools. For example,the use of the (non-probabilistic) graph transformation mod-els or dynamic tests proposed in [5] and [49], respectively, inthe self-adaptation ENTRUST stage is not precluded by anyof our assumptions (cf. Section 4.2.1), although the methodchosen for this stage will clearly constrain the types ofrequirements for which assurance evidence can be providedat runtime.

23

6.3 Threats to Validity

Construct validity threats may be due to the assumptionsmade when implementing our simple versions of the UUVand FX systems, and in the development of the stochasticmodels and requirements for these systems. To mitigatethese threats, we implemented the two systems using thewell-established UUV software platform MOOS-IvP and(for FX) standard Java web services deployed in Tom-cat/Axis. The model and requirements for the UUV systemare based on a validated case study that we are familiar withfrom previous work [52], and those for the FX system weredeveloped in close collaboration with a foreign exchangeexpert.

Internal validity threats can originate from how theexperiments were performed, and from bias in the interpre-tation of the results due to researcher subjectivity. To addressthese threats, we reported results over multiple independentruns; we worked with a team comprising experts in all thekey areas of ENTRUST (self-adaptation, formal verificationand assurance cases); and we made all experimental dataand results publicly available to enable replication.

External validity threats may be due to the use of onlytwo systems in our evaluation, and to the experimental eval-uation having been done by only the authors’ three researchgroups. To reduce the first threat, we selected systems fromdifferent domains with different requirements. The evalua-tion results show that ENTRUST supports the developmentof trustworthy self-adaptive solutions with assurance casesfor the two different settings. To reduce the second threat,we based ENTRUST on input from, and needs identifiedby, the research community [24], [28], [34], [35]. In addition,we fine tuned ENTRUST based on feedback from industrialpartners involved in the development of mission-criticalself-adaptive systems, and these partners are now usingour methodology in planning future engineering activities.Nevertheless, additional evaluation is required to confirmgenerality for domains with characteristics that differ fromthose in our evaluation (e.g., different timing patterns andtypes of requirements and disturbances) and usability by alarger number of users.

7 RELATED WORK

Given the uncertain operating conditions of self-adaptivesystems, a central aspect of providing assurances for suchsystems is to collect and integrate evidence that the re-quirements are satisfied during the entire lifetime. To thisend, researchers from the area of self-adaptive systems haveactively studied a wide variety of assurance methods andtechniques applicable at design time and/or at runtime [28],[34], [80], [99], [110], [113], [118]. Tables 6 and 7 summarisethe state of the art, partitioned into categories based on themain method used to provide assurances, e.g. formal proof,model checking or simulation. We consider as the mainmethod of a study from our analysis the method that thestudy primarily focuses on; the approaches from these stud-ies may implicitly use additional methods, such as testingof their platforms and tools, but this is not emphasised bytheir authors. We summarise the representative approachesincluded in each category according to their:

1) Assurances evidence, comprising separate parts for themethods used to provide assurance evidence for: (i) thecorrectness of the platform used to execute the controller,(ii) the correctness of the controller functions, and (iii) thecorrectness of the runtime adaptation decisions;

2) Methodology, comprising three parts: the engineeringprocess (i.e. a methodical series of steps to provide theassurances), tool support (i.e., tools used by engineers toprovide evidence at design time and tools used at run-time by the controller, e.g. during analysis or planning),and other reusable components (i.e. third-party librariesand purpose-built software components used as part ofthe controller, and other artefacts that can be used atdesign time or at runtime, including models, templates,patterns, algorithms).

Providing assurances for self-adaptive systems with strictrequirements requires covering all these aspects, as well asan assurance argument that integrates the assurance evidenceinto a compelling, comprehensible and valid case that thesystem requirements are satisfied. Unlike ENTRUST (Ta-ble 8), the current research disregards this need for an assur-ance argument. We discuss below the different approachesand point out limitations that we overcome with ENTRUST.

Formal proof establishes theorems to prove properties ofthe controller or the system under adaptation. Proof wasused to provide evidence for safety and liveness proper-ties of self-adaptive systems with different semantics (one-point adaptation, overlap adaptation, and guided adapta-tion) [117]. Formal proof was also used to provide evidencefor properties of automatically synthesised controllers, e.g.the completeness and soundness of synthesised behavioralmodels that satisfy an expressive subset of liveness prop-erties [40] and correctness and deadlock free adaptationsperformed by automatically synthesised controllers [70]. Fi-nally, formal proof was used to demonstrate the correctnessof adaptation effects, e.g. proofs for safety, no deadlock, andno starvation of system processes as a result of adaptation[12], and guarantees for the required qualities of adapta-tions, e.g. proofs for optimised resource allocation, whilesatisfying quality of service constraints [1]. The focus of allthese approaches is on providing assurance evidence forparticular aspects of adaptation. All of them offer reusablecomponents, however, these solutions require completespecifications of the system and its environment, and—unlike ENTRUST—cannot handle aspects of the managedsystem and its environment that are unknown until runtime.

Model checking enables verifying that a property holdsfor all reachable states of a system, either offline by en-gineers and/or online by the controller software. Modelchecking was used to ensure correctness of the adaptationfunctions that are modeled as interacting automata, withthe verified models directly interpreted during executionby a thoroughly tested virtual machine [65]. Model check-ing was also used to provide guarantees for automaticcontroller synthesis and enactment, e.g. to assure that asynthesised controller and reusable model interpreter haveno anomalies [11]. Model checking has extensively beenused to provide guarantees for the effects of adaptationactions on the managed system, e.g. for safety propertiesof the transitions of a managed system that is modeled as

24

TABLE 6Overview of related research on assurances for self-adaptive systems - part I

ApproachAssurance evidence Methodology

Controller Controller Adaptation Engineering Tool Other reusableplatform functions decisions process support components

Formal proofAdaptation

semantics [117]Proof of safety and liveness

properties of adaptive programsand program compositions

Model checkingalgorithm

Synthesis ofbehavioralmodels [40]

Proof of completeness andsoundness of synthesized

behavioral models

Controllersynthesistechnique

Controllersynthesis [70]

Proof that controller synthesisalgorithm generates controllers

that guarantee correct anddeadlock free adaptations

Controllersynthesis

process only

Tool to generatecontroller offline

Controllersynthesisalgorithm

Correctnessadaptationeffects [12]

Proof of safety, no deadlock,and no starvation of system

processes as a result ofadaptation

Verified middle-ware that ensures

safety and livenessof monitored system

Guaranteedqualities [1]

Proof of optimizing resourceallocation under QoS constraints

Ad-hoc solver of op-timisation problem

Model checkingCorrect

adaptationfunctions [65]

Thoroughlytested virtual

machine used tointerpret and runcontroller models

UPPAAL model checking ofinteracting timed automata to

ensure controller deadlockfreeness, liveness, etc. and

functional system requirements

UPPAAL usedto verify

controllermodels at

design time

Tested reusablevirtual machine;controller model

templates

Controllersynthesis andenactment [11]

Synthesised controller that isguaranteed not to be

anomalous

Tool used forcontrollersynthesis

Reusable inter-preter and config-uration manager

for controllerenactment

Safe adaptationconfigurations

[5]

Verification of safety propertiesof system transitions using agraph transformation model

Symbolicverificationprocedure

Guaranteedqualities [17]

Probabilistic model checking ofcontinually updated stochastic

models of the controlled systemand the environment to ensure

non-functional requirements

PRISM verificationlibrary for analysis

of stochasticsystem and envir-

onment modelsResilience to

controllerfailures [23]

Probabilistic model checking ofresilience properties of

synthesized Markov models ofthe managed system

Procedure tocheck resilience

to controllerfailures

Reusableoperational

profiles to checkresilience

a graph transformation system [5], to ensure non-functionalrequirements by runtime verification of continually updatedstochastic models of the controlled system and the environ-ment [17], and to provide evidence for resilience propertiesof synthesized Markov models of the managed system [23].Again, the focus of all the approaches is on providingassurance evidence for particular aspects of adaptation. TheENTRUST instance presented in Section 5 uses two of thesetechniques (i.e., [65] and [17]) to verify the correctness ofthe MAPE logic at design time and to obtain evidence thatadaptation decisions are correct at runtime, respectively.In addition, ENTRUST offers a process for the systematicengineering of all components of the self-adaptive system,which includes employing an industry-adopted standardfor the formalization of assurance arguments.

Simulation approaches provide evidence by analysing theoutput of the execution of a model of the system. Simulationwas used to evaluate novel self-adaptation approaches, e.g.to ensure the scalability and robustness to node failures andmessage loss of a self-assembly algorithm [97], and to sup-port the design of self-adaptive systems, e.g., to check if theperformance of a latency-aware adaptation algorithm fallswithin predicted bounds [26]. Recently some efforts havebeen made to let the controller exploit simulation at runtime

to support analysis, e.g. runtime simulation of stochasticmodels of managed system and environment has been usedto ensure non-functional requirements with certain levelof confidence [112]. The primary focus of simulation ap-proaches has been on providing assurance evidence for theadaptation actions (either as a means to check the controllereffects or to make a prediction of the expected effects ofdifferent adaptation options). The approaches typically relyon established simulators.

Testing is a standard method for assessing if a softwaresystem performs as expected in a finite number of scenarios.Testing was used to test the effectiveness of adaptationframeworks, e.g. checking whether a self-repair frameworkapplied to a client-server system keeps the latencies ofclients within certain bounds when the network is over-loaded [51]. Testing was used to provide evidence forthe robustness of controllers by injecting invalid inputs atthe controller’s interface and use the responses to classifyrobustness [23]. Several studies have applied testing atruntime, e.g. to validate safe and correct adaptations ofthe managed system based on adapt test cases generatedin response to changes in the system and environment[49]. While simulation and testing approaches can be em-ployed within the generic ENTRUST methodology to obtain

25

TABLE 7Overview of related research on assurances for self-adaptive systems - part II


Controller Controller Adaptation Engineering Tool Other reusableplatform functions decisions process support components

SimulationEvaluation

novel approach[97]

Offline simulation to ensure thescalability and robustness to

node failures and message lossSupport fordesign [26]

Offline simulations to check ifthe performance of a

latency-aware adaptationalgorithm falls within predicted

bounds

OMNeT++simulator for

checkingalgorithm

performanceRuntime

analysis [112]Runtime simulation of

stochastic models of managedsystem and environment to

ensure non-functionalrequirements with certain level

of confidence

UPPAAL-SMCused for onlinesimulation of

stochastic systemand environment

modelsTesting

Testeffectiveness of

adaptationframework [51]

Offline stress testing inclient-server system, showingthat self-repair significantly

improves system performance

Rainbowframework to

realiseself-adaptation

Test controllerrobustness [23]

Robustness testing of controllerby injecting invalid inputs atthe controller’s interface andemploy responses to classify

robustness

Robustnesstesting

procedure only

Probabilisticresponse

specificationpatterns for

robustness testingRuntime

testing [49]Dynamic tests to validate safe

and correct adaptation ofsystem using test cases adapted

to changes in the system andenvironment

One-stageprocess for testcase adaptation

Other approachesControl-theoretic

approaches,e.g., [47]

Control-theoretic guaranteesfor one goal (setpoint) using

automatically synthesisedcontroller at runtime

Controller guarantees forstability, overshoot, setting time

and robustness of systemoperating under disturbances

ARPE tool to buildonline a first-order

model of thesystem

Kalman filter andchange point

detectionprocedure for

model updatesRuntime

verification[95]

Online verification of theprobability that a temporalproperty is satisfied given a

sample execution trace

TRACE-CONTRACT tool

used for traceanalysis

Sanity checks[107]

Sanity checks evaluate thecorrectness of resource sharingdecisions made by a reasoning

engine

CHAMELEONtool providingperformanceguarantees

TABLE 8Comparison of ENTRUST to related research on assurances for self-adaptive systems


Controller Controller Adaptation Assurance Engineering Tool Other reusableplatform functions decisions argument process support components

GenericENTRUST

methodology

Reuse of verifiedapplication-independent

controllerfunctionality

Verification ofcontrollermodels to

ensure genericcontroller

requirementsand some

systemrequirements

Automatedsynthesis ofadaptationassurance

evidence duringthe analysis andplanning stepsof the MAPEcontrol loop

Development ofpartial

assuranceargument at

design time, andsynthesis of

dynamicassuranceargument

duringself-adaptation

Seven-stage processfor the systematicengineering of allcomponents of the

self-adaptive system,and of an assurance

case arguing itssuitability for the

intended application

Tools specific to eachENTRUST instance

Reusable softwareartefacts: controllerplatform, controller

model templates;Reusable assuranceartefacts: platform

assurance evidence,generic controller

requirements,assurance argument

patternTool-

supportedENTRUST

instance

Reuse ofthoroughly

tested virtualmachine to

directlyinterpret andrun controllermodels, and of

establishedprobabilistic

model checkingengine

UPPAAL modelchecking ofinteracting

timed automatamodels to

ensure controllerdeadlock-freeness,

liveness, etc.and functional

systemrequirements

PRISMprobabilistic

model checkingof continually

updated stochasticmodels of the

controlledsystem and theenvironment to

ensurenon-functionalrequirements

Assuranceargument

synthesisedusing theindustry-

adopted GoalStructuring

Notation (GSN)standard

Seven-stage processfor the systematicengineering of allcomponents of the

self-adaptive system,and of an assurance

case arguing itssuitability for the

intended application

UPPAAL used toverify controller

models; PRISM usedto verify stochastic

system andenvironment models

Reusable controllerplatform (virtual

machine, probabilisticverification engine),

timed automatacontroller model

templates; Reusableplatform assurance

evidence, CTL genericcontroller require-

ments, GSN assuranceargument pattern

26

assurance evidence for particular aspects of self-adaptivesystems, they need to be complemented by assurances forother components of a self-adaptive system and integratedin a systematic process as provided by ENTRUST.

Other approaches. To conclude, we highlight some otherrelated approaches that have been used to provide assur-ances for self-adaptive systems. Recently, there has been agrowing interest in applying control theory to build “correctby construction” controllers. The approach was used toautomatically synthesise controllers at runtime, providingcontrol-theoretic guarantees for stability, overshoot, settingtime and robustness of system operating under disturbances[47]. This research is at an early stage, and its potential to de-liver solutions for real-world systems and scenarios has yetto be confirmed. In contrast, ENTRUST relies on proven soft-ware engineering techniques for modelling and analysingsoftware systems and assuring their required properties.Runtime verification is a well-studied lightweight verifi-cation technique based on extracting information from arunning system to detect whether certain properties areviolated. For example, sequences of events can be modeledas observation sequences of a Hidden Markov Model al-lowing to verify the probability that a temporal propertyis satisfied by a run of a system given a sampled exe-cution trace [95]. Sanity checks are another approach tocheck the conformance of requirements of adaptive systems.Sanity checks have been used to evaluate the correctnessof resource sharing decisions made by a reasoning engine[107]. Approaches such as runtime verification and sanitychecks are often supported by established tools. However,these approaches provide only one piece of evidence. Suchapproaches can also be used by our generic ENTRUSTmethodology, which supports the integration of assuranceevidence from multiple sources in order to continuouslygenerate an assurance case.

Another line of related research (not specifically target-ting self-adaptation and thus not included in Table 7) isruntime certification, proposed in [90] and further developedin [71], [92]. Runtime certification involves the proactiveruntime monitoring of the assumptions made in the assur-ance case, thereby providing early warnings for potentialfailures. ENTRUST goes beyond the mere monitoring ofassumptions, to evolving the arguments and evidence dy-namically based on the runtime verification data, particu-larly for self-adaptive software assurance. ENTRUST alsoextends existing work on assurance argument patterns [37]by enabling runtime instantiation.

The ENTRUST methodology and the other researchsummarised in this section also build on results from theareas of configurable software, configuration optimisation,and performance tuning. For instance, symbolic evaluationhas been used to understand the behaviour of configurablesoftware systems [88], dedicated support to automaticallyverify the correctness of dynamic updates of client-serversystems has been proposed [62], and specification languageshave been devised to help program library developers ex-pose multiple variations of the same API using differentalgorithms [33]. However, none of these results could bedirectly applied to self-adaptive software systems, whichneed to reconfigure dynamically in response to runtimeenvironmental uncertainties and goal changes.

The sparsity of Tables 6 and 7 makes clear that existingapproaches are confined to providing correctness evidencefor specific aspects of the self-adaptive software. In contrastto existing work on assurances for self-adaptive systems,Table 8 shows that ENTRUST offers an end-to-end method-ology for the development of trustworthy self-adaptivesoftware systems. Unique to our approach, this includesthe development of assurance arguments. The upper partof Table 8 shows how the generic ENTRUST methodologycovers the whole spectrum of aspects that are requiredto provide assurances for self-adaptive systems with strictrequirements. The lower part of Table 8 shows a concretetool-supported instantiation of ENTRUST and summariseshow the various assurances aspects are covered for thisinstance. Details about the information summarised in thetable are provided in Sections 4 and 5.

8 CONCLUSION

We introduced ENTRUST, the first end-to-end methodologyfor the engineering of trustworthy self-adaptive softwaresystems and the dynamic generation of their assurancecases. ENTRUST and its tool-supported instance presentedin the paper include methods for the development of verifi-able controllers for self-adaptive systems, for the generationof design-time and runtime assurance evidence, and for theruntime instantiation of an assurance argument pattern thatwe devised specifically for these systems.

The future research directions for our project includeevaluating the usability of ENTRUST in a controlled ex-periment, extending the runtime model checking of systemrequirements to functional requirements, and reducing theruntime overheads by exploiting recent advances in proba-bilistic model checking at runtime [18], [20], [44], [52], [66].In addition, we are planning to explore the applicability ofENTRUST to other systems and application domains.

REFERENCES

[1] J. Almeida, V. Almeida, D. Ardagna, C. Francalanci, and M. Tru-bian, “Resource management in the autonomic service-orientedarchitecture,” in 2006 IEEE International Conference on AutonomicComputing, June 2006, pp. 84–92.

[2] R. Alur and D. L. Dill, “A theory of timed automata,” TheoreticalComputer Science, vol. 126, no. 2, 1994.

[3] A. Aziz, K. Sanwal, V. Singhal, and R. Brayton, “Model-checkingcontinuous-time Markov chains,” ACM Trans. on ComputationalLogic, vol. 1, no. 1, pp. 162–170, 2000.

[4] C. Baier, B. R. Haverkort, H. Hermanns, and J. P. Katoen, “Model-checking algorithms for continuous-time Markov chains,” IEEETrans. Softw. Eng., vol. 29, no. 6, pp. 524–541, 2003.

[5] B. Becker, D. Beyer, H. Giese, F. Klein, and D. Schilling, “Symbolicinvariant verification for systems with dynamic structural adap-tation,” in 28th International Conference on Software Engineering.ACM, 2006, pp. 72–81.

[6] G. Behrmann, A. David, K. G. Larsen, J. Hakansson, P. Petterson,W. Yi, and M. Hendriks, “UPPAAL 4.0,” in QEST’06, 2006, pp.125–126.

[7] M. Benjamin, H. Schmidt, P. Newman, and J. Leonard, “Auton-omy for unmanned marine vehicles with MOOS-IvP,” in MarineRobot Autonomy. Springer, 2013, pp. 47–90.

[8] A. Bianco and L. de Alfaro, “Model checking of probabilistic andnondeterministic systems,” in FSTTCS’95, 1995, pp. 499–513.

[9] P. Bishop and R. Bloomfield, “A methodology for safety casedevelopment,” in Industrial Perspectives of Safety-critical Systems.Springer, 1998, pp. 194–203.

27

[10] R. Bloomfield and P. Bishop, “Safety and assurance cases: Past,present and possible future — an Adelard perspective,” in Mak-ing Systems Safer. Springer, 2010, pp. 51–67.

[11] V. Braberman, N. D’Ippolito, N. Piterman, D. Sykes, and S. Uchi-tel, “Controller synthesis: From modelling to enactment,” in 35thInternational Conference on Software Engineering, 2013, pp. 1347–1350.

[12] O. Brukman, S. Dolev, and E. K. Kolodner, “A self-stabilizingautonomic recoverer for eventual byzantine software,” J. Syst.Softw., vol. 81, no. 12, pp. 2315–2327, Dec. 2008.

[13] Y. Brun, G. Marzo Serugendo, C. Gacek, H. Giese, H. Kienle,M. Litoiu, H. Muller, M. Pezze, and M. Shaw, “Engineeringself-adaptive systems through feedback loops,” in SoftwareEngineering for Self-Adaptive Systems, B. H. Cheng, R. Lemos,H. Giese, P. Inverardi, and J. Magee, Eds. Berlin, Heidelberg:Springer-Verlag, 2009, pp. 48–70. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02161-9 3

[14] R. Calinescu, L. Grunske, M. Kwiatkowska, R. Mirandola, andG. Tamburrelli, “Dynamic QoS management and optimization inservice-based systems,” IEEE Trans. Softw. Eng., vol. 37, no. 3, pp.387–409, 2011.

[15] R. Calinescu, K. Johnson, and Y. Rafiq, “Using observation ageingto improve Markovian model learning in QoS engineering,” in2nd ACM/SPEC Intl. Conf. on Performance Engineering, 2011, pp.505–510.

[16] ——, “Developing self-verifying service-based systems,” in Au-tomated Software Engineering (ASE), 2013 IEEE/ACM 28th Interna-tional Conference on, Nov 2013, pp. 734–737.

[17] R. Calinescu, “General-purpose autonomic computing,” in Auto-nomic Computing and Networking, M. K. Denko, L. T. Yang, andY. Zhang, Eds. Springer, 2009, pp. 3–30.

[18] R. Calinescu, S. Gerasimou, and A. Banks, “Self-adaptive soft-ware with decentralised control loops,” in FASE’15, ser. LNCS.Springer, 2015, vol. 9033, pp. 235–251.

[19] R. Calinescu, C. Ghezzi, M. Kwiatkowska, and R. Mirandola,“Self-adaptive software needs quantitative verification at run-time,” Commun. ACM, vol. 55, no. 9, pp. 69–77, Sep. 2012.

[20] R. Calinescu, S. Kikuchi, and K. Johnson, “Compositional reveri-fication of probabilistic safety properties for large-scale complexIT systems,” in Large-Scale Complex IT Systems, ser. LNCS, vol.7539. Springer, 2012, pp. 303–329.

[21] R. Calinescu and M. Z. Kwiatkowska, “Using quantitative anal-ysis to implement autonomic IT systems,” in ICSE’09, 2009, pp.100–110.

[22] R. Calinescu, Y. Rafiq, K. Johnson, and M. E. Bakir, “Adaptivemodel learning for continual verification of non-functional prop-erties,” in 5th ACM/SPEC International Conference on PerformanceEngineering, 2014, pp. 87–98.

[23] J. Camara, R. de Lemos, N. Laranjeiro, R. Ventura, and M. Vieira,“Robustness-driven resilience evaluation of self-adaptive soft-ware systems,” IEEE Transactions on Dependable and Secure Com-puting, vol. PP, no. 99, pp. 1–1, 2015.

[24] J. Camara, R. de Lemos, C. Ghezzi, and A. Lopes, Eds., Assurancesfor Self-Adaptive Systems - Principles, Models, and Techniques, ser.Lecture Notes in Computer Science. Springer, 2013, vol. 7740.

[25] J. Camara, D. Garlan, B. Schmerl, and A. Pandey, “Optimal plan-ning for architecture-based self-adaptation via model checkingof stochastic games,” in 30th Annual ACM Symposium on AppliedComputing, 2015, pp. 428–435.

[26] J. Camara, G. A. Moreno, D. Garlan, and B. Schmerl, “Analyzinglatency-aware self-adaptation using stochastic games and simu-lations,” ACM Transactions on Autonomous and Adaptive Systems,vol. 10, no. 4, pp. 23:1–23:28, Jan. 2016.

[27] T. Chen, V. Forejt, M. Kwiatkowska, D. Parker, and A. Simaitis,“Automatic verification of competitive stochastic systems,” inProc. 18th International Conference on Tools and Algorithms forthe Construction and Analysis of Systems (TACAS’12), ser. LNCS,C. Flanagan and B. Konig, Eds., vol. 7214. Springer, 2012, pp.315–330.

[28] B. H. C. Cheng, K. I. Eder, M. Gogolla, L. Grunske, M. Litoiu,H. A. Muller, P. Pelliccione, A. Perini, N. A. Qureshi, B. Rumpe,D. Schneider, F. Trollmann, and N. M. Villegas, “Using modelsat runtime to address assurance for self-adaptive systems,” [email protected]: Foundations, Applications, and Roadmaps, N. Ben-como, R. France, B. H. C. Cheng, and U. Aßmann, Eds. Springer,2014, pp. 101–136.

[29] E. M. Clarke, E. A. Emerson, and A. P. Sistla, “Automatic ver-ification of finite-state concurrent systems using temporal logicspecifications,” ACM Trans. Program. Lang. Syst., vol. 8, no. 2, pp.244–263, Apr. 1986.

[30] E. Clarke, D. Long, and K. McMillan, “Compositional modelchecking,” in Proc. 4th Intl. Symp. Logic in Computer Science, 1989,pp. 353–362.

[31] J. M. Cobleigh, D. Giannakopoulou, and C. S. Pasareanu, “Learn-ing assumptions for compositional verification,” in 9th Interna-tional Conference on Tools and Algorithms for the Construction andAnalysis of Systems (TACAS), 2003, pp. 331–346.

[32] Common Criteria Recognition Arrangement, “ISO/IEC 15408 –Common Criteria for Information Technology Security Evalua-tion, Version 3.1, Revision 4,” September 2012.

[33] C. Tapus, I.-H. Chung, and J. K. Hollingsworth, “Active har-mony: Towards automated performance tuning,” in ACM/IEEEConference on Supercomputing, ser. SC ’02. Los Alamitos, CA,USA: IEEE Computer Society Press, 2002, pp. 1–11. [Online].Available: http://dl.acm.org/citation.cfm?id=762761.762771

[34] R. de Lemos, D. Garlan, C. Ghezzi, and H. Giese, “SoftwareEngineering for Self-Adaptive Systems: Assurances (DagstuhlSeminar 13511),” Dagstuhl Reports, vol. 3, no. 12, pp. 67–96, 2014.

[35] R. de Lemos, H. Giese, H. A. Muller, M. Shaw et al., “Soft-ware engineering for self-adaptive systems: A second researchroadmap,” in Software Engineering for Self-Adaptive Systems II, ser.LNCS. Springer, 2013, vol. 7475, pp. 1–32.

[36] E. Denney, I. Habli, and G. Pai, “Dynamic safety cases forthrough-life safety assurance,” in ICSE’15, 2015, pp. 587–590.

[37] E. Denney and G. Pai, “A formal basis for safety case patterns,” inComp. Safety, Reliability, and Security, ser. LNCS. Springer, 2013,vol. 8153, pp. 21–32.

[38] N. D’Ippolito, V. Braberman, J. Kramer, J. Magee, D. Sykes, andS. Uchitel, “Hope for the best, prepare for the worst: Multi-tier control for adaptive systems,” in Proceedings of the 36thInternational Conference on Software Engineering, ser. ICSE 2014.New York, NY, USA: ACM, 2014, pp. 688–699.

[39] N. D’Ippolito, V. A. Braberman, N. Piterman, and S. Uchitel,“Synthesis of live behaviour models for fallible domains,” in 33rdInternational Conference on Software Engineering, 2011, pp. 211–220.

[40] N. R. D’Ippolito, V. Braberman, N. Piterman, and S. Uchitel,“Synthesis of live behaviour models,” in 18th ACM SIGSOFTInternational Symposium on Foundations of Software Engineering,2010, pp. 77–86.

[41] A. Elkhodary, N. Esfahani, and S. Malek, “FUSION: a frameworkfor engineering self-tuning self-adaptive software systems,” inFSE’10, 2010, pp. 7–16.

[42] I. Epifani, C. Ghezzi, R. Mirandola, and G. Tamburrelli, “Modelevolution by run-time parameter adaptation,” in 31st InternationalConference on Software Engineering, 2009, pp. 111–121.

[43] European Organisation for the Safety of Air Navigation, “Safetycase development manual,” 2006.

[44] A. Filieri, C. Ghezzi, and G. Tamburrelli, “Run-time efficientprobabilistic model checking,” in ICSE’11, 2011, pp. 341–350.

[45] ——, “A formal approach to adaptive software: continuous as-surance of non-functional requirements,” Formal Asp. Comput.,vol. 24, no. 2, pp. 163–186, 2012.

[46] A. Filieri, L. Grunske, and A. Leva, “Lightweight adaptive filter-ing for efficient learning and updating of probabilistic models,”in 37th IEEE/ACM International Conference on Software Engineering,2015, pp. 200–211.

[47] A. Filieri, H. Hoffmann, and M. Maggio, “Automated designof self-adaptive software with control-theoretical formal guaran-tees,” in Proceedings of the 36th International Conference on SoftwareEngineering, ser. ICSE 2014. New York, NY, USA: ACM, 2014,pp. 299–310.

[48] V. Forejt, M. Kwiatkowska, D. Parker, H. Qu, and M. Ujma,“Incremental runtime verification of probabilistic systems,” inRuntime Verification, ser. LNCS, vol. 7687. Springer, 2012, pp.314–319.

[49] E. M. Fredericks, B. DeVries, and B. H. C. Cheng, “Towards run-time adaptation of test cases for self-adaptive systems in theface of uncertainty,” in 9th International Symposium on SoftwareEngineering for Adaptive and Self-Managing Systems, 2014, pp. 17–26.

[50] S. Gallotti, C. Ghezzi, R. Mirandola, and G. Tamburrelli, “Qualityprediction of service compositions through probabilistic modelchecking,” in Proc. 4th International Conference on the Quality of

http://dx.doi.org/10.1007/978-3-642-02161-9_3

http://dx.doi.org/10.1007/978-3-642-02161-9_3

http://dl.acm.org/citation.cfm?id=762761.762771

28

Software-Architectures, QoSA 2008, ser. LNCS, S. Becker, F. Plasil,and R. Reussner, Eds., vol. 5281. Springer, 2008, pp. 119–134.

[51] D. Garlan, S.-W. Cheng, A. C. Huang, B. Schmerl, andP. Steenkiste, “Rainbow: architecture-based self-adaptation withreusable infrastructure,” Computer, vol. 37, no. 10, pp. 46–54, Oct2004.

[52] S. Gerasimou, R. Calinescu, and A. Banks, “Efficient runtimequantitative verification using caching, lookahead, and nearly-optimal reconfiguration,” in SEAMS’14, 2014, pp. 115–124.

[53] S. Gerasimou, G. Tamburrelli, and R. Calinescu, “Search-basedsynthesis of probabilistic models for quality-of-service softwareengineering,” in 30th Intl. Conf. Automated Softw. Eng. (ASE’15),2015.

[54] L. Gherardi and N. Hochgeschwender, “RRA: Models and toolsfor robotics run-time adaptation,” in Intelligent Robots and Systems(IROS), 2015 IEEE/RSJ International Conference on, Sept 2015, pp.1777–1784.

[55] C. Ghezzi, M. Pezze, M. Sama, and G. Tamburrelli, “Miningbehavior models from user-intensive web applications,” in 36thInternational Conference on Software Engineering, 2014, pp. 277–287.

[56] GSN Working Group Online, “Goal structuring notation stan-dard, version 1,” November 2011.

[57] H. Hansson and B. Jonsson, “A logic for reasoning about timeand reliability,” Formal Aspects of Computing, vol. 6, no. 5, pp.512–535, 1994.

[58] R. Hawkins, I. Habli, and T. Kelly, “The principles of softwaresafety assurance,” in 31st Intl. System Safety Conf., 2013.

[59] R. Hawkins, K. Clegg, R. Alexander, and T. Kelly, “Using asoftware safety argument pattern catalogue: Two case studies,”in Comp. Safety, Reliability, and Security. Springer, 2011, pp. 185–198.

[60] R. Hawkins, I. Habli, and T. Kelly, “Principled construction ofsoftware safety cases,” in SAFECOMP 2013 Workshop on NextGeneration of System Assurance Approaches for Safety-Critical Sys-tems, 2013.

[61] R. Hawkins, I. Habli, T. Kelly, and J. McDermid, “Assurance casesand prescriptive software safety certification: A comparativestudy,” Safety Science, vol. 59, pp. 55–71, 2013.

[62] C. M. Hayden, S. Magill, M. Hicks, N. Foster, andJ. S. Foster, “Specifying and verifying the correctness ofdynamic software updates,” in International Conference onVerified Software: Theories, Tools, Experiments, ser. VSTTE’12.Berlin, Heidelberg: Springer-Verlag, 2012, pp. 278–293. [Online].Available: http://dx.doi.org/10.1007/978-3-642-27705-4 22

[63] P. Horn, “Autonomic computing: IBM’s perspective on the stateof information technology,” 2001.

[64] M. C. Huebscher and J. A. McCann, “A survey of autonomiccomputing—degrees, models, and applications,” ACM Comput.Surv., vol. 40, no. 3, pp. 1–28, 2008.

[65] M. U. Iftikhar and D. Weyns, “ActivFORMS: Active formal mod-els for self-adaptation,” in 9th International Symposium on SoftwareEngineering for Adaptive and Self-Managing Systems, 2014, pp. 125–134.

[66] K. Johnson, R. Calinescu, and S. Kikuchi, “An incremental veri-fication framework for component-based software systems,” in16th Intl. ACM Sigsoft Symposium on Component-Based SoftwareEngineering, 2013, pp. 33–42.

[67] G. Karsai and J. Sztipanovits, “A model-based approach to self-adaptive software,” Intelligent Syst. and their Applications, IEEE,vol. 14, no. 3, pp. 46–53, May 1999.

[68] T. Kelly and R. Weaver, “The goal structuring notation – a safetyargument notation,” in Assurance Cases Workshop, 2004.

[69] J. Kephart and D. Chess, “The vision of autonomic computing,”Computer, pp. 41–50, 2003.

[70] N. Khakpour, F. Arbab, and E. Rutten, “Synthesizing structuraland behavioral control for reconfigurations in component-basedsystems,” Formal Aspects of Computing, vol. 28, no. 1, pp. 21–43,2016.

[71] J. Knight, J. Rowanhill, and J. Xiang, “A safety condition moni-toring system,” in 3rd Intl. Workshop on Assurance Cases for Softw.Intensive Syst., 2015.

[72] J. Kramer and J. Magee, “Self-managed systems: an architecturalchallenge,” in Future of Software Engineering, 2007. FOSE ’07, May2007, pp. 259–268.

[73] C. M. Krishna, Real-Time Systems. John Wiley & Sons, Inc., 2001.[74] C. Krupitzer, F. M. Roth, S. VanSyckel, G. Schiele, and

C. Becker, “A survey on engineering approaches for self-

adaptive systems,” Pervasive and Mobile Computing, vol. 17,Part B, pp. 184–206, 2015. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S157411921400162X

[75] M. Kwiatkowska, G. Norman, and D. Parker, “PRISM 4.0: Verifi-cation of probabilistic real-time systems,” in CAV’11, ser. LNCS,vol. 6806. Springer, 2011, pp. 585–591.

[76] M. Lahijanian, S. B. Andersson, and C. Belta, “Formal verificationand synthesis for discrete-time stochastic systems,” IEEE Trans.Automat. Contr., vol. 60, no. 8, pp. 2031–2045, 2015.

[77] B. Littlewood and D. Wright, “The use of multilegged argumentsto increase confidence in safety claims for software-based sys-tems,” IEEE Trans. Softw. Eng., vol. 33, no. 5, pp. 347–365, 2007.

[78] C. Lu, J. A. Stankovic, S. H. Son, and G. Tao, “Feedback controlreal-time scheduling: Framework, modeling, and algorithms*,”Real-Time Systems, vol. 23, no. 1, pp. 85–126, 2002.

[79] F. D. Macıas-Escriva, R. Haber, R. del Toro, and V. Hernandez,“Self-adaptive systems: A survey of current approaches, researchchallenges and applications,” Expert Systems with Applications,vol. 40, no. 18, pp. 7267 – 7279, 2013. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0957417413005125

[80] J. Magee and T. Maibaum, “Towards specification, modellingand analysis of fault tolerance in self managed systems,” inSEAMS’06, 2006, pp. 30–36.

[81] North European Functional Airspace Block, “NEFAB Project—Safety Case Report, Version 3.01,” Dec. 2011.

[82] P. Oreizy, M. M. Gorlick, R. N. Taylor, D. Heimbigner, G. Johnson,N. Medvidovic, A. Quilici, D. S. Rosenblum, and A. L. Wolf,“An architecture-based approach to self-adaptive software,” IEEEIntelligent Syst., vol. 14, no. 3, pp. 54–62, May 1999.

[83] D. Perez-Palacin, R. Calinescu, and J. Merseguer, “Log2Cloud:Log-based prediction of cost-performance trade-offs for clouddeployments,” in 28th Annual ACM Symposium on Applied Com-puting, 2013, pp. 397–404.

[84] A. Pnueli, “The temporal logic of programs,” in 18th AnnualSymposium on Foundations of Computer Science, 1977, pp. 46–57.

[85] H. Psaier and S. Dustdar, “A survey on self-healing systems:approaches and systems,” Computing, vol. 91, no. 1, pp. 43–73,2011.

[86] T. Quatmann, C. Dehnert, N. Jansen, S. Junges, and J. Katoen,“Parameter synthesis for markov models: Faster than ever,” in14th International Symposium on Automated Technology for Verifica-tion and Analysis (ATVA), 2016, pp. 50–67.

[87] P. J. G. Ramadge and W. M. Wonham, “The control of discreteevent systems,” Proceedings of the IEEE, vol. 77, no. 1, pp. 81–98,Jan 1989.

[88] E. Reisner, C. Song, K.-K. Ma, J. S. Foster, and A. Porter,“Using symbolic evaluation to understand behavior inconfigurable software systems,” in ACM/IEEE InternationalConference on Software Engineering, ser. ICSE ’10. New York,NY, USA: ACM, 2010, pp. 445–454. [Online]. Available:http://doi.acm.org/10.1145/1806799.1806864

[89] Royal Academy of Engineering, “Establishing High-Level Evi-dence for the Safety and Efficacy of Medical Devices and Sys-tems,” January 2013.

[90] J. Rushby, “The interpretation and evaluation of assurance cases,”Comp. Science Laboratory, SRI International, Tech. Rep. SRI-CSL-15-01, 2015.

[91] M. Salehie and L. Tahvildari, “Self-adaptive software: Landscapeand research challenges,” ACM Trans. Auton. Adapt. Syst., vol. 4,no. 2, pp. 14:1–14:42, May 2009.

[92] D. Schneider and M. Trapp, “Conditional safety certification ofopen adaptive systems,” ACM Trans. Auton. Adapt. Syst., vol. 8,no. 2, pp. 8:1–8:20, Jul. 2013.

[93] D. Spinellis, “Notable design patterns for domain specific lan-guages,” Journal of Systems and Software, vol. 56, no. 1, pp. 91–99,Feb. 2001.

[94] J. Spriggs, GSN – The Goal Structuring Notation. A StructuredApproach to Presenting Arguments. Springer, 2012.

[95] S. D. Stoller, E. Bartocci, J. Seyster, R. Grosu, K. Havelund,S. A. Smolka, and E. Zadok, “Runtime verification with stateestimation,” in Proceedings of the Second International Conferenceon Runtime Verification, ser. RV’11. Berlin, Heidelberg: Springer-Verlag, 2012, pp. 193–207.

[96] G. Su, T. Chen, Y. Feng, D. S. Rosenblum, and P. S. Thiagara-jan, “An iterative decision-making scheme for Markov decisionprocesses and its application to self-adaptive systems,” in 19th

http://dx.doi.org/10.1007/978-3-642-27705-4_22

http://www.sciencedirect.com/science/article/pii/S157411921400162X

http://www.sciencedirect.com/science/article/pii/S157411921400162X

http://www.sciencedirect.com/science/article/pii/S0957417413005125

http://www.sciencedirect.com/science/article/pii/S0957417413005125

http://doi.acm.org/10.1145/1806799.1806864

29

International Conference on Fundamental Approaches to SoftwareEngineering (FASE), 2016, pp. 269–286.

[97] D. Sykes, J. Magee, and J. Kramer, “Flashmob: Distributedadaptive self-assembly,” in Proceedings of the 6th InternationalSymposium on Software Engineering for Adaptive and Self-ManagingSystems, ser. SEAMS ’11. New York, NY, USA: ACM, 2011, pp.100–109.

[98] P. Tabuada, Verification and Control of Hybrid Systems. Springer,2009.

[99] G. Tamura and et al., “Towards practical runtime verificationand validation of self-adaptive software systems,” in SoftwareEngineering for Self-Adaptive Systems II, ser. LNCS. Springer, 2013,vol. 7475.

[100] G. Tesauro, D. M. Chess, W. E. Walsh, R. Das, A. Segal, I. Whalley,J. O. Kephart, and S. R. White, “A multi-agent systems approachto autonomic computing,” in Third Intl. Conf. on AutonomousAgents and Multiagent Syst., 2004, pp. 464–471.

[101] UK Civil Aviation Authority, “Unmanned aircraft system opera-tions in UK airspace — Guidance. CAP 722. Sixth edition,” 2015.

[102] UK Health & Safety Commission, “The use of computers insafety-critical applications,” 1998.

[103] UK Ministry of Defence, “Defence Standard 00-56, Issue 4: SafetyManagement Requirements for Defence Systems,” June 2007.

[104] UK Office for Nuclear Regulation, “The Purpose, Scope, andContent of Safety Cases, Rev. 3,” July 2013.

[105] University of Virginia Dependability and Security ResearchGroup, “Safety case repository,” 2014.

[106] US Dept. Health and Human Services, Food and Drug Adminis-tration, “Infusion Pumps Total Product Life Cycle—Guidance forIndustry & FDA Staff,” 2014.

[107] S. Uttamchandani, L. Yin, G. A. Alvarez, J. Palmer, and G. A.Agha, “Chameleon: A self-evolving, fully-adaptive resource ar-bitrator for storage systems,” in USENIX Annual Technical Confer-ence, General Track, 2005, pp. 75–88.

[108] N. M. Villegas, H. A. Muller, G. Tamura, L. Duchien, and R. Casal-las, “A framework for evaluating quality-driven self-adaptivesoftware systems,” in 6th International Symposium on Software

Engineering for Adaptive and Self-Managing Systems, 2011, pp. 80–89.

[109] W. Walsh, G. Tesauro, J. Kephart, and R. Das, “Utility functionsin autonomic systems,” in IEEE International Conference on Auto-nomic Computing, 2004, pp. 70–77.

[110] D. Weyns, N. Bencomo, R. Calinescu, J. Camara, C. Ghezzi,V. Grassi, L. Grunske, P. Inverardi, J.-M. Jezequel, S. Malek, R. Mi-randola, M. Mori, and G. Tamburrelli, “Perpetual Assurances inSelf-Adaptive Systems,” in Software Engineering for Self-AdaptiveSystems IV, Lecture Notes in Computer Science, R. de Lemos, D. Gar-lan, C. Ghezzi, and H. Giese, Eds. Springer, 2016.

[111] D. Weyns and R. Calinescu, “Tele Assistance: A self-adaptiveservice-based system examplar,” in 10th International Symposiumon Software Engineering for Adaptive and Self-Managing Systems,2015, pp. 88–92.

[112] D. Weyns and M. U. Iftikhar, “Model-based simulation at runtimefor self-adaptive systems,” in Proceedings of the 11th InternationalWorkshop on [email protected], ser. MODELS 2016, 2016.

[113] D. Weyns, M. U. Iftikhar, D. G. de la Iglesia, and T. Ahmad, “Asurvey of formal methods in self-adaptive systems,” in C3S2E’12,2012, pp. 67–79.

[114] D. Weyns, S. Malek, and J. Andersson, “FORMS: Unifying refer-ence model for formal specification of distributed self-adaptivesystems,” ACM Trans. Auton. Adapt. Syst., vol. 7, no. 1, p. 8, 2012.

[115] S. R. White, D. M. Chess, J. O. Kephart, J. E. Hanson, andI. Whalley, “An architectural approach to autonomic computing,”in Intl. Conf. on Autonomic Computing. IEEE Computer Society,2004, pp. 2–9.

[116] M. Zamani, N. van de Wouw, and R. Majumdar, “Backsteppingcontroller synthesis and characterizations of incremental stabil-ity,” Systems & Control Letters, vol. 62, no. 10, pp. 949–962, 2013.

[117] J. Zhang and B. H. Cheng, “Using temporal logic to specifyadaptive program semantics,” Journal of Syst. and Softw., vol. 79,no. 10, pp. 1361 – 1369, 2006.

[118] P. Zoghi, M. Shtern, M. Litoiu, and H. Ghanbari, “Designingadaptive applications deployed on cloud environments,” ACM

Trans. Auton. Adapt. Syst., vol. 10, no. 4, pp. 25:1–25:26, Jan. 2016.

Documents

Engineering Trustworthy Self-Adaptive Software with Dynamic … · 2018-11-26 · Engineering Trustworthy Self-Adaptive Software with Dynamic Assurance Cases Radu Calinescu, Danny