2.1 Multi-dimensional activity

Pervasive systems comprise many different facets and so we will need to describe/specify not just their basic dynamic behaviour, but also how all these facets/dimensions evolve and interact. Even in the relatively trivial ‘shopping’ example above, we can see that the system involved has many different facets.

• ∙ It clearly has dynamic behaviour, together with (changing) knowledge about people and their plans.

• ∙ There are real-time aspects, not only in scheduling an appropriate meeting time but also in responding to shopper movements in a timely manner.

• ∙ As at least some part of the pervasive system has to try to model the ‘real world’, or at least an abstraction of the environment, and since the sensors that are typically used for this can never be perfect, then uncertainty must, necessarily, be involved.

• ∙ There is collaboration and cooperation, both at the level of agents ‘representing’ shoppers and at the level of shops and agents cooperating to provide appropriate information and capabilities.

• ∙ Many elements are mobile, and there are many programs working at once but in different areas. Thus, mobility, distribution and concurrency are essential.

• ∙ Clearly, the software representing a shopper must also carry out autonomous decision making (see Section 2.2), for example, to instigate a meeting for coffee.

And so on. As we can see, even from this simple example, a pervasive system can have many different facets. As we wish to specify and verify such systems, then we must ensure our specification (Section 3.1) and verification (Section 4.1) techniques take these dimensions into account.

We will later see how a typical pervasive message forwarding system, such as Scatterbox (Knox et al., Reference Knox, Shannon, Coyle, Clear, Dobson, Quigley and Nixon2008), requires a wide range of additional dimensions in order to explain/describe its behaviours:

So, in general, to be able to clearly specify any non-trivial pervasive system we will require descriptions that combine, and explain interactions between, many such dimensions.

2.2 Autonomous decision making

Pervasive systems contain components that can make autonomous choices, that is, are often separated from direct human control. Thus, with this autonomy the computational components can decide, for themselves, what to do and when to do it. The specific form of autonomy we consider is that captured by the concept of a rational agent. An agent (Wooldridge, Reference Wooldridge2002) essentially captures the idea of an autonomous entity, being able to make its own choices and carry out its own actions. Beyond this, rational agents are typically employed to represent more complex autonomous decision making where communication and explanation are vital (see Figure 2).

Figure 2

Motivation for use of rational agents

These agents are rational in the sense that they take their decisions in a rational and explainable way (rather than, e.g., purely randomly). The central aspects of the rational agent metaphor is that such agents are autonomous, but can react to changes in circumstance and can choose what to do based on their own agenda. In assessing such systems it may not be sufficient to consider what the agent will do, but we must often also consider why is chooses to do it. The predominant view of rational agents is that provided by the BDI (beliefs–desires–intentions) model (Rao & Georgeff, Reference Rao and Georgeff1991, Reference Rao and Georgeff1995) in which we describe the goals the agent has, the ‘beliefs’ it has and the choices it makes. The rational agent’s intentions are then determined by its beliefs and goals.

2.3 Humans ‘in the loop’

Pervasive systems typically involve humans, or at least external autonomous entities, and a variety of tools or artefacts within the system. Often, humans are actually embedded within pervasive systems, with computation and communication happening all around them. In many cases, the overall behaviour of the whole pervasive system depends on appropriate behaviour of the humans involved; in this case we can see the human/system relationship as a very weak form of cooperation.

In some areas, computational/robotic elements play an even more collaborative role in the human–system scenario. This is particularly the case if actual physical robots are involved. Although many practical activities suggest human–robot cooperation, space exploration is an area at the forefront of this where cooperation and teamwork is clearly required. As an example, NASA is interested in Robot–Astronaut teams to be deployed on Mars (Sierhuis et al., Reference Sierhuis, Bradshaw, Acquisti, Hoof, Jeffers and Uszok2003; see Figure 3(a)).

Figure 3

Human–robot teamwork (a) in planetary exploration (photo courtesy of NASA (Astronaut-Robot-Team-Concept)) and (b) in the home (RoboSafe, 2013)

While not directly involving such space applications, pervasive systems not only can involve multiple robotic elements but also can require human–system interaction of a similar form. Consequently, the problems raised by human–robot interactions can often re-appear in pervasive scenarios. On the domestic front, the close interaction of multiple humans and robots in pervasive scenarios is becoming more prevalent, particularly in health-care situations. Thus, the Robotics industry is actively developing ‘Robots for the Home’, particularly as human assistants (see Figure 3(b)). Clearly, this leads to safety concerns:

• ∙ Are the robots safe?

• ∙ How can we tell a robot what we want?

• ∙ Will a robot work out what we want it to do?

• ∙ And then, are we sure it will decide to do what we want?

This is a natural area where formal verification should, and can, make an impact (Fisher et al., Reference Fisher, Dennis and Webster2013). Indeed, as we will see later, specification and verification techniques developed for human–robot interaction have an important role to play in assessing (high-level and abstracted) human involvement in pervasive systems.

2.4.2 Complex context view

Another, more general, view is that ‘context’ should cover much more than location or activity. For example, in the MetateM agent programming language (Fisher & Hepple, Reference Fisher and Hepple2009) the context in which an agent is acting is a first-class construct. Indeed, contexts are also agents and an agent is considered to reside in (or be contained by) zero or more contexts. Context in MetateM is conceived as the more abstract and flexible notion of anything that has an influence over an agent in a system. Specifically, contexts do not just concern location, but can be

• ∙ roles or societal norms;

• ∙ teams or organizational structures;

• ∙ Activities;

• ∙ styles or preferences;

• ∙ Locations;

• ∙ etc.

This gives a very powerful mechanism for programming and describing quite complex context-dependent behaviours and so complex organizations and systems (Hepple et al., Reference Hepple, Dennis and Fisher2008). While there remains debate about exactly what an ‘agent’ is, this view of hierarchical and active agents perhaps needs further comment. While we can see an agent as capturing basic autonomous behaviour, there are many different levels of abstraction over which this can be taken. Consider, for example, a flock of birdsFootnote ¹. Seen at a high level of abstraction, the ‘flock’ can be viewed as an autonomous entity with its emergent behaviour being opaque to an external viewer. So, we could model the flock as an agent. But then, of course, if we move into the flock we can discern local interactions between individual birds. Correspondingly, once we look inside the agent’s content we can see (and interact with) representations of individual birds.

This duality, being able to treat the larger entity as an agent while at the same time being able to move inside to interact with further agents in its content, is very powerful. It clearly has ancestry on object-based systems, but extends this to agents with active, autonomous behaviour. The context/content view is, thus, very useful for modelling entities that are autonomous and active at many different levels of abstraction and often do not correspond to physical entities, for example, roles and norms, teams and other organizational structures, styles and preferences, etc.

It is important, in our later sections, that we are able to verify both varieties of the notion of ‘context’ described above. The first is simpler, but is used in many deployed pervasive systems. The second approach is more powerful, and something like this is likely to become used in future pervasive system development. Below we give an example for each approach.

Example (Knoxet al., Reference Knox, Shannon, Coyle, Clear, Dobson, Quigley and Nixon2008). The Scatterbox system, as well as exhibiting multi-dimensional behaviour as described in Section 2.1, also involves context-dependent behaviours. As described in Knox et al. (Reference Knox, Shannon, Coyle, Clear, Dobson, Quigley and Nixon2008), Scatterbox is a message forwarding system, primarily designed as a testbed for context-aware computing in pervasive scenarios. Each Scatterbox user’s context is defined by tracking his/her location and by monitoring his/her daily schedule. These data are analyzed and ‘situations’ are identified that indicate the user’s level of interruptibility. Once a message arrives, Scatterbox forwards it to the subscribed user provided the user’s available context suggests they are in a situation where they may be interrupted. A schematic diagram of Scatterbox is given in Figure 4.

Figure 4

Scatterbox message forwarding system (Konur et al., Reference Konur, Fisher, Dobson and Knox2014)

Example (Hepple,Reference Hepple2010). Consider an abstract ‘cookery’ example. Here, a cooking agent simply wants to ‘cook’. But, to begin with, it does not know how to cook and does not know about any contexts. Specifically, it initially has one goal (i.e. to ‘cook’) but has no plans telling it how to go about this. So, this cooking agent now moves into a chef role context, which is itself another agent (see Figure 5(a)). This context agent provides the cooking agent with appropriate information, plans and capabilities associated with the ‘role’ of being a ‘chef’ (see Figure 5(b)). Once the agent has received and assimilated these aspects then it can legitimately take on the role of a ‘chef’ and can indeed satisfy its goal to be able to ‘cook’. So, just by moving into a new context, the cookery agent has obtained new computational capabilities. Moving into further contexts can bestow additional capabilities, or even constraints, upon the agent. In this way, contexts are active, providing more than just a representation of ‘location’.

Figure 5

Cooking scenario (Dennis et al., Reference Dennis, Fisher and Hepple2008)

3.1 Multi-dimensional activity

In the specification of different aspects and dimensions, we use formal logics (Konur, Reference Konur2013). Logics provide a well-understood and unambiguous formalism for describing the behaviours, requirements and properties of systems. In addition, as we are concerned with the verification of pervasive systems, the well-researched proof, complexity and satisfiability in checking results can provide us with many practical tools such as automated deduction or model checking systems.

An obvious issue with formally specifying pervasive systems is that formal logics have limitations. For example, there might be system properties that cannot be represented formally in a particular logical system. In order to maximize the expressivity of logics and hence to be able to verify more complex properties, we combine different aspects of different logics.

Beyond classical Boolean logic there are many logics devised for a huge array of different types of system. Choosing the appropriate logic provides a level of abstraction close to the key concepts of the software, for example:

• ∙ dynamic communicating systems → temporal logics;

• ∙ systems managing information → logics of knowledge;

• ∙ situated systems → logics of belief, contextual logics;

• ∙ timed systems → real-time temporal logics;

• ∙ uncertain systems → probabilistic logics;

• ∙ cooperative systems → cooperation/coalition logics.

As we cannot easily describe all aspects of a pervasive system in one of these logics, we will often need to combine formalisms. There are several standard ways to combine logics, with the three standard ones being (Gabbay et al., Reference Gabbay, Kurucz, Wolter and Zakharyaschev2003): temporalization (Finger & Gabbay, Reference Finger and Gabbay1996); fusion (or independent join); and product (or full join). Now, imagine we have two logics to combine, logic A (typically, a temporal logic) and logic B.

We assume the logics A and B are graphically represented as in Figure 7.

Figure 7

Notation (Konur et al., Reference Konur, Fisher and Schewe2013)

The temporalization permits only a restricted way that two component languages can interact with each other. It is denoted by A(B), where a pure subformula of logic B can be treated as an atom within logic A. This combination is not symmetric—A is the main logic, but at each world/state described by logic A we might have a formula of B describing an embedded ‘B-world’ (see Figure 8).

Figure 8

Temporalization of two logics (Konur et al., Reference Konur, Fisher and Schewe2013)

As Figure 8 suggests, after we take some A-step(s) (straight arrow), we can take a B-step (dotted arrow). From this point on, we are in the B-world, and we cannot take an A-step anymore.

The fusion A ⊕ B is more symmetric than temporalization in that, at any state/world, we can either take an ‘A-step’ or a ‘B-step’ (see Figure 9). It is important to note that the two logical dimensions are essentially independent (hence ‘independent join’).

Figure 9

Fusion of two logics (Konur et al., Reference Konur, Fisher and Schewe2013)

The product combination, A ⊗ B, is similar to the fusion, but with a much tighter integration of the logics (see Figure 10). Operators of the constituent logics tend to be commutative. This provides a stronger integration of the component logics but, correspondingly, often results in logics of higher complexity than fusions or temporalizations.

Figure 10

Product of two logics (Konur et al., Reference Konur, Fisher and Schewe2013)

Example. Once we can combine logics, for example, using fusions, then we can combine several logics together in order to provide a quite powerful descriptive framework. As an example of why combinations of logics may be appropriate for formally specifying multi-dimensional behaviour in a pervasive system, consider the following statement from an assistive health-care scenario.

In formalizing this we might write:

$$needs\_medicine(patient)\to B_{{patient}}^{{\geq 0.65}} \diamondsuit ^{{\leq 10}} G_{{nurse}} \,\:assist(patient)$$

where $$B_{{patient}}^{{\geq 0.65}} $$ means patient believes with 95% probability: probabilistic logics; ◊^⩽10 means within 10 minutes: temporal logics; G _nurse means the nurse robot has a goal, and so wants to help the patient: BDI logics.

3.2 Autonomous decision making

As our autonomous decision-making components are to be characterized as rational agents, we program such autonomous decision making using high-level programming languages for rational agents. Typical programming languages for rational agents (Bordini et al., Reference Bordini, Dastani, Dix and El Fallah Seghrouchni2005, Reference Bordini, Dastani, Dix and El Fallah-Seghrouchni2009) provide representations of

• ∙ beliefs;

• ∙ desires (often referred to as goals);

• ∙ intentions (or invocations of rules/plans);

• ∙ actions;

• ∙ deliberation mechanisms.

Based on its beliefs and desires an agent can select an intention, or plan of action, which can then invoke further basic procedures. This makes the programming and inspection of the decision making much more intuitive as the programmer is encouraged to describe the situations in which a given course of action is applicable or desirable.

An example of agent rule/plan in a typical programming languages for rational agents is given below (Fisher et al., Reference Fisher, Dennis and Webster2013):

Goal (eat) : Belief (has_money),

Belief (not has_food)

<- Goal (go_to_shop),

Action (buy_food),

Goal (go_home),

Action (eat),

+Belief (eaten).

This means that if the agent intends to eat and if it believes it has money, but does not have food, then it will intend to go to the shop. Once the agent achieves its desire (i.e. goal), it will buy some food and then intends to go home. When it is at home, the agent will eat and then update its beliefs to record that it believes it has eaten.

Modern agent programming languages in this BDI paradigm were pioneered by the PRS in the early 1990s (Georgeff & Lansky, Reference Georgeff and Lansky1987; Rao & Georgeff, Reference Rao and Georgeff1992), which sought to abstract decision making away from the more procedural aspects where control systems were used. This BDI architecture has been shown to generalize widely to any situation in which autonomous decision making is required to control complex software processes and a family of programming languages has been developed to support the paradigm, for example, AgentSpeak (Rao, Reference Rao1996; Bordini et al., Reference Bordini, Hübner and Vieira2005), 2APL (Dastani et al., Reference Dastani, van Riemsdijk and Meyer2005), GOAL (Hindriks et al., Reference Hindriks, de Boer, van der Hoek and Meyer2001) and Gwendolen (Dennis & Farwer, Reference Dennis and Farwer2008).

3.3 Modelling teamwork: humans ‘in the loop’

In a pervasive system, we can often see humans and autonomous components as working together as a team. But how might we try to describe behaviours within such human–computer teams? To simplify, we choose to model the high-level cooperation and interaction, behaviours of the team participants, abstracting away from low-level details such as movement. Specifically, we choose to carry out the modelling of these high-level behaviours using the Brahms framework (van Hoof, Reference van Hoof2000; Sierhuis, Reference Sierhuis2001; Sierhuis & Clancey, Reference Sierhuis and Clancey2002). This is a framework designed to model both human and robot activity, again using rational agents. As it was developed to represent activities in real-world contexts, it also allows the representation of artefacts, data and concepts in the form of classes and objects. Both agents and objects can be located in a model of the world (the geography model) giving agents the ability to detect objects and other agents in the world and have beliefs about the objects. Agents can move from one location in the world to another by executing move actions, so simulating physical movement (for a more detailed description, see Sierhuis (Reference Sierhuis2001, Reference Sierhuis2006).

The Brahms language was originally conceived of as a language for modelling contextually situated activity behaviour of groups of people. This has now evolved into a language for modelling both people and robots/agents. As such it is ideal for describing human–agent/robot teamwork and indeed has been used for this both in mundane scenarios and in modelling the ‘Robot–Astronaut teams on Mars’ mentioned earlier. It has been particularly successful as it allows us to describe, concisely and precisely, the overall team behaviours and so assess how well such teams work together.

Example (Stockeret al., Reference Stocker, Dennis, Dixon and Fisher2012). We now consider a domestic home care application as an example to illustrate the Brahms specification language. In this scenario, the helper robot reminds the assisted person Bob to take his medication. The scenario is explained as follows:

A fragment of the Brahms specification of this scenario is given below (Stocker et al., Reference Stocker, Dennis, Dixon and Fisher2012):

workframe wf_checkMedicationC

{

repeat: true;

priority: 3;

detectables:

detectable takenMedicationC

{

when (whenever)

detect ((Bob.hasMedicationC=false), dc:100)

then abort;

}

when (knownval (current.perceivedtime >14) and

knownval (Bob.hasMedicationC=true) and

knownval (current.checkMedicationC=true))

do

{

checkMedication ();

remindMedicationC ();

conclude ((current.checkMedicationC=false));

conclude ((current.missedMedicationC=current.missedMedicationC+1));

}

}

A workframe corresponds to a plan in standard rational agent programming languages. This particular one has a certain priority level, events that can be detected, a set of triggers (captured within the when clause) and a list of outcomes (after they do) such as calling further workframes or updating beliefs.

3.4 Context dependency

3.4.1 Simple context view

In the shallow view of ‘context’ we can simply describe/specify contextual information in terms of changes in location. For example, we might describe a simple model of user movement by a straightforward state-machine (see Figure 11). This then allows us to use a simple formal language, such as temporal logic to describe changes in context, such as ‘◊SHOPPING’, meaning ‘eventually the user will be in a SHOPPING context’.

Figure 11

A simple model of user movement

4.1 Verifying combined specifications

Formal description of pervasive and ubiquitous systems can involve many different logical dimensions. This makes the verification task extremely difficult, as the interactions between these dimensions increase complexity significantly. The techniques currently used for formalizing and verifying aspects of pervasive and ubiquitous systems are very limited, often trying to describe system behaviour by considering just one dimension rather than dealing with multiple formalisms at the same time.

One idea to tackle the problem would be to introduce complex logics comprising all the aspects needed and develop new model checking methods and tools. However, devising new model checking methods/tools for such complex logics is both difficult and time consuming.

In Konur et al. (Reference Konur, Fisher and Schewe2013), we present a verification technique that allows the combination of model checking techniques for different formal frameworks. Namely, instead of introducing new logics for different combined aspects and developing model checkers for these logics, we combine existing logics and devise a generic model checking method for these combined frameworks. A combined model checking procedure can then be synthesized, in a modular way, from model checkers for constituent logics. This avoids the re-implementation of model checking procedures.

An overview of our approach is presented in Figure 13. As the figure illustrates, a combined model checker MC_A⊕B for the combined logic A⊕B employs the model checkers MC_A and MC_B for the constituent logics A and B, respectively. Note that in the generic model checking procedure there are several calls to MC_A and MC_B, but they are not shown in the figure to keep the presentation simple.

Figure 13

Overview of the combined model checking approach of Konur et al. (Reference Konur, Fisher and Schewe2013)

This technique can be used to verify combined real-time, probabilistic, informational aspects, etc., which are at the core of pervasive and ubiquitous systems. Using this method, we can model check the combinations of the logics discussed in Section 3.1: temporal logics, logics of knowledge, logics of beliefs, real-time temporal logics and probabilistic logics.

4.2 Verifying autonomous behaviour

An advantage of using the BDI paradigm to program and model autonomous decision making is that several BDI programming languages now have associated formal verification techniques (Bordini et al., Reference Bordini, Fisher, Visser and Wooldridge2006; Fisher et al., Reference Fisher, Singh, Spears and Wooldridge2007; Jongmans et al., Reference Jongmans, Hindriks and van Riemsdijk2010; Dennis et al., Reference Dennis, Fisher, Webster and Bordini2012). The property specification languages within such model checkers have to be extended in order to describe the key reasoning components (beliefs, desires, etc.) but as these environments generally do not implement full logics of knowledge or belief, such modalities can be treated in a simple and efficient fashion, normally as propositions within a temporal logic.

The points where an autonomous decision-making layer must interact with lower-level control layers or the real world are more of a challenge and involve the construction of abstract models of these parts of the system. There are two approaches to this problem: one is to use advanced mathematical techniques such as hybrid automata to model the real world and the other is to use simple, highly abstract models, and focus on capturing, clearly, the conditions under which the rational layer makes valid decisions.

The AIL/AJPF model checking toolkit (Dennis et al., Reference Dennis, Fisher, Webster and Bordini2012), which we have developed, not only takes the second of these approaches but, through the generic Agent Infrastructure Layer, provides a Java framework to enable the implementation of interpreters for various agent programming languages and the direct use of the AJPF agent program model checker. Through this AIL/AJPF approach (see Figure 14) verification for several high-level agent programming languages has already been carried out.

Figure 14

Verification of multiple agent programming languages (Bordini et al., Reference Bordini, Dennis, Farwer and Fisher2008)

Here, operational semantics can be provided for a range of agent programming languages, including AgentSpeak and MetateM, and then these semantics can be used within the generic model checking procedure provided by Java PathFinder (Visser et al., Reference Visser, Havelund, Brat and Park2000).

4.3 Verifying human–agent teams

As we have seen from Section 3.3, the Brahms simulation/modelling language is not only appropriate for describing human–agent teamwork, but has been used in practice for non-trivial human–robot interactions (van Hoof, Reference van Hoof2000; Sierhuis, Reference Sierhuis2001; Sierhuis & Clancey, Reference Sierhuis and Clancey2002). Consequently, Brahms provides us with a ready-made framework for describing human–agent teamwork, as well as providing a range of examples in specific areas (Clancey et al., Reference Clancey, Sierhuis, Kaskiris and van Hoof2003; Sierhuis et al., Reference Sierhuis, Bradshaw, Acquisti, Hoof, Jeffers and Uszok2003; Sierhuis, Reference Sierhuis2006). It seems natural, therefore, to aim towards the formal verification of Brahms models. The formal operational semantics for the Brahms language produced in Stocker et al. (Reference Stocker, Sierhuis, Dennis, Dixon and Fisher2011) now forms the basis of our formal verification of Brahms (see Figure 15). In Stocker et al. (Reference Stocker, Dennis, Dixon and Fisher2012) a Brahms model of a human–agent team scenario is translated to a Java representation of the corresponding semantics structure, which is then translated into the Spin model checker’s input language, Promela (Holzmann, Reference Holzmann2003). Formal proerties are also represented in Promela, and the verification problem is passed on to the Spin tool. This approach has been extended and refined, particularly improving efficiency by translating to alternaitve model checkers (Hunter et al., Reference Hunter, Raimondi, Rungta and Stocker2013).

Figure 15

Formal verification process of Brahms (Stocker et al., Reference Stocker, Dennis, Dixon and Fisher2012)

4.4 Verifying context-dependent behaviour