Behaviours as Design Components of Cyber-Physical Systems

Abstract

System behaviour is proposed as the core object of software development. The system comprises both the software machine and the problem world. The behaviour of the problem world is ensured by the combination of its given properties and the interacting behaviour of the machine. The fundamental requirements do not mandate specific system behaviour but demand that the behaviour exhibit certain desirable properties and achieve certain effects. These fundamental requirements therefore include usability, safety, reliability and others commonly regarded as ‘non-functional’. A view of behaviour content and structure is presented, based on the Problem Frames approach, leading to a specification in terms of concurrent behaviour instances created and controlled within a tree structure. Development method is not addressed in this short paper; nor is software architecture. For brevity, and clearer visibility of the thread of the paper’s theme, much incidental, explanatory, illustrative and detailed material is relegated to end notes. A final section summarises the claimed value of the approach in addressing the characteristic challenges of cyber-physical systems.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introductory Remarks

In a cyber-physical system the software controls a part of the physical and human world. The system comprises both the computing equipment and the parts of the physical world it governs. Examples are vending machines, radio-therapy machines, cars, aircraft, trains, lifts, cranes, heart pacemakers, automatic lathes, ATMs, and countless others.

This paper aims to explain and justify an improved version of the Problem Frame approach [1] to the development of such systems. The approach deals with the pre-formal¹ work that creates a bridge from the stakeholders’ purposes and desires², leading to a detailed software specification, emphasising the centrality of the system behaviour. The main text of the paper is itself no more than an outline: some illustrations, clarifications and additional details are presented in notes, along with appeals to some eminent authorities.

The process of creating the bridge must start from the stakeholders’ purposes and desires—that is, from the system requirements. But the satisfaction of those requirements by the running system in operation starts from the other end. The machine—the system’s computing equipment executing the system’s software—interacts with the physical problem world to monitor and control what happens there: it is the resulting system behaviour ³ that must satisfy the requirements. The system behaviour is the essential product of software development.

The requirements⁴ are desired properties of the system behaviour; but they are distinct from it. The development problem, therefore, is to design a behaviour that satisfies the requirements, with an accompanying software specification that can be shown to ensure that behaviour. Evaluating whether a proposed behaviour design is satisfactory must be a co-operative task for developers and stakeholders together⁵; producing and validating the accompanying software specification is primarily the developers’ responsibility.

2 The World and the Machine

The problem world is, in general, a heterogeneous⁶ assemblage of identifiable distinct parts of the material and human world that are of interest to the stakeholders. These parts are called problem domains: a vital task in development is investigating and analysing their given properties and behaviours on which the design will rely⁷. These properties are given, in the sense that they are independent of the machine⁸; but in combination with the domains’ acceptance of the constraints imposed by the machine⁹ they will determine the system behaviour¹⁰.

The problem world must not exclude human domains. People participate in systems in many different roles—for example: as a casual user of a vending machine, as a plant operator, as the driver of a car or train or the pilot of an aircraft, as a passenger, as the patient in a surgical operation or a radiotherapy system, as the recipient of medication dispensed by an infusion pump, as the wearer of a cardiac pacemaker, as a source of problem world data that is otherwise inaccessible¹¹ to the machine. In various ways and to various extents the physical and behavioural properties of a human participant contribute to the system behaviour¹². The development must investigate and understand them in all their relevant aspects.

We speak of the machine in the singular: a development problem has multiple problem domains, but only one machine. This is, of course, a conceptual simplification: the computing equipment of a realistic system may be distributed, and even shared with another system. The simplification is appropriate in an initial view of the problem: while the physical structure of the problem world is largely given, and offers clear enough distinctions among problem domains, the structure of the machine¹³, which we must develop, has not yet been designed¹⁴.

3 Challenges of Cyber-Physical Systems

Each system presents its own particular challenges to the developers; but some important challenges are common to all cyber-physical systems that are to any degree critical. Among the most salient are two intertwined challenges: formal description of the ineluctably physical problem world, and dependable design of the complex system behaviour. If the system behaviour resulting from its interactions with the designed software is to be the subject of fully convincing reasoning, the problem world must be formally described. But the problem world is not a formal universe¹⁵: any formalisation is an approximation, at best barely adequate to its particular purpose, context and use. The system behaviour of any realistic system is inevitably complex, and the non-formal nature of the problem world adds greatly to this complexity.

The response to the physicality challenge must itself be twofold. First: it must embody the practice of a sound modelling discipline¹⁶ to minimise uncertainty in the mapping between each description and its physical subject. This is a requirement for any development method, and we will not discuss it further here.

Second: a dependable structuring of the system behaviour must address both the inherent complexity of the system’s function and purpose, and the added complexity due to the non-formal physical problem world. Inherent complexity arises from the multiplicity of system functions, features, modes and phases of any realistic system. Further, design of a critical system is likely to demand a wide operating envelope, encompassing a very wide variety of conditions in which the system must behave dependably. This inherent complexity cannot be mastered by ad hoc variations within one monolithic behaviour. Instead, multiple behaviours must be specifically designed for specific conditions and functions and activated as conditions and needs demand.

The complexity added by the physicality of the problem world springs from reality’s deviations from any one formal model, manifested as equipment failures, unexpected behaviour due to neglected physical effects, operator errors, and other exceptional contingencies. These deviations must be accommodated while maintaining safe and dependable—though possibly degraded—operation. This complexity may require a variety of formalisations of the same physical domains¹⁷, which in turn requires a variety of behaviours that depend on those domains.

4 Dependability and the Problem World Boundary

The general form of a development problem is shown in Fig. 1.

Fig. 1.

Problem diagram

The single striped box represents the machine; the plain boxes represent problem domains; the solid lines (labelled a,b,.. f) represent interfaces of physical shared phenomena such as events and states¹⁸. Together, the machine, the problem domains, and their mutual interfaces constitute the system; the system boundary is represented by the dotted box. The ellipse represents the system behaviour¹⁹ resulting from the interaction of the machine with the problem world. The document symbol represents the requirements.

Let us suppose that the developers have calculated or otherwise determined that the desired system behaviour is to be B; and that their designed behaviour of the machine at its problem world interfaces a,b,c is M²⁰. Then, if the given behaviours of the problem domains are {Wi}, it is necessary for system dependability to demonstrate convincingly the fundamental entailment, that

$$ {\text{M}},\left\{ {{\text{W}}i} \right\}\,| = \,{\text{B}}. $$

That is: the designed machine M installed as shown in the problem world whose given domain properties are {Wi}, will ensure the behaviour B²¹. For a critical system this demonstration should be formal²², to provide the strongest possible assurance of the system behaviour. The domain properties {Wi}—and the machine specification M—must therefore be captured in an adequate formalisation that is sufficiently faithful²³ to the physical realities it approximates.

Furthermore, the problem world and machine must be regarded as a closed system: the demonstration of the fundamental entailment must not rely on any assertion that cannot be inferred from the physical laws of nature and the explicitly stated properties²⁴ of the problem domains²⁵. These constraints on the problem world necessitate the distinction²⁶ shown in Fig. 1 between the system behaviour and the stakeholders’ requirements—which are often informal, and often related to parts of the world outside the system boundary.

5 Complexity of System Behaviour

Satisfying the system requirements may demand great behavioural complexity. Some of this complexity springs from normal system operation, which may comprise many necessary functions and features structured in multiple phases and modes²⁷. Interaction among these functions (especially when they operate concurrently, but also when they are consecutive, or nested, or alternating) is a source of further complexity²⁸. Some complexity is due to the need to detect and mitigate equipment faults, operator errors or other exceptional events. Some springs from the need to coordinate normal operation with equipment maintenance and repair. Some is due to the need to maintain safe operation even in extreme adverse conditions.

In general, dependable system behaviour means behaviour that varies in a comprehensibly dependable²⁹ way, according to what is possible and desirable in different circumstances. Fault tolerance, for example, does not demand that normal functional behaviour continue in the presence of a major fault, but permits it to be replaced by a different behaviour, functionally degraded but dependable and preserving safety³⁰. Complex system behaviour is understood as a combination of simpler constituent behaviours. A constituent behaviour has the same structure and pattern as the complete system behaviour pictured in Fig. 1: it has a machine, an assemblage of problem domains, and a number of relevant requirements. The development problem, both for the complete behaviour and for each constituent behaviour, has two interrelated aspects: to design a behaviour to satisfy the requirements; and to specify an associated machine that will ensure that behaviour³¹.

An ill-chosen constituent can complicate the task of developing the whole to which it belongs—either by itself presenting excessive difficulty in its own development, or by leaving a misshapen residual complement³². Identifying suitable constituent behaviours is the primary task in structuring the system behaviour. An essential guide in this task is a set of explicit criteria of behavioural simplicity. These criteria include: regularity of the machine’s software structure³³; constancy of given domain properties during the behaviour³⁴; a clear and tersely explicable purpose for the behaviour³⁵; and simplicity of the causal pattern by which the machine ensures the behaviour in the problem world³⁶.

6 Large Behaviour Structure: Principles

This structuring of complex system behaviour, in terms of constituent behaviours, aims above all at producing an understandable and verifiable³⁷ specification of system behaviour. It is not the immediate aim of this structuring to produce a modular software structure capable of translation into efficient executable code. If a specification is executable, that is an advantage. But the primary aim is intelligibility of the system behaviour, demanding a correspondence between constituent behaviours and functional purposes that can be understood and evaluated by the stakeholders³⁸.

A constituent behaviour should initially be analysed in a simplified form in which its possible interactions with other behaviours are ignored: consideration of those interactions and the complexities they introduce should be postponed until a later point at which the behaviours are to be combined³⁹. The same strategy—an incremental approach to inescapable complexity⁴⁰—can be applied to other complexities due to exceptional conditions that can arise within the behaviour itself.

Initially considering constituent behaviours—more exactly, candidate constituent behaviours⁴¹—in isolation encourages an important separation of concerns. To the greatest extent possible, the functional content of each behaviour should be separated from the control of its initiation and, in certain circumstances, of its termination. Since the concept of a constituent behaviour rests on a relationship of inclusion of an instance of one behaviour in an instance of another, this separation cannot be complete. But its aim remains valid: to maintain modularity in the explicit structure of the behaviour specification⁴². This modularity supports the understanding of each constituent behaviour as an independent unit of system functionality: it must be allowed to persist as long and as fully as possible, throughout the development and use of the specification⁴³.

7 Large Behaviour Structure: Designed Domains

Large behaviour structure is defined in terms of a designed structure of the machines that ensure the constituent behaviours⁴⁴. One—but not the only—design motivation for structuring is decomposition⁴⁵: a behaviour which is proving less simple than originally expected, is restructured with two or more constituent behaviours.

Figure 2 shows, in general terms, a trivial case. In behaviour B0, machine MB0 monitors Domain X and controls Domain Y so that its behaviour is kept in some required relationship with Domain X. The Stop Switch allows behaviour B0 to be terminated on command. On analysis, we are supposing, the tasks of monitoring X and controlling Y prove too complex to be combined in a single undecomposed behaviour B0⁴⁶: so B0 is decomposed into B0’ and two constituent behaviours BX and BY.

Fig. 2.

Decomposition of a simple behaviour

In B0, the information obtained from Domain X and needed for proper control of Domain Y would be represented and maintained in a data structure in the local store of machine MB0. In B0’ this data structure has been ‘promoted’ from a machine local variable to a problem domain, X-to-Y, common to the two constituent behaviours BX and BY. A problem domain originated in this way is represented by a box with a single stripe: it is a designed domain because it is a design artifact of the software development, not a given part of the physical problem world of the original undecomposed problem⁴⁷.

In general, the function of a designed domain is to communicate information across time and space between parts of the system behaviour which we want—or are compelled—to separate. The X-to-Y domain allows the constituent behaviours BX and BY to be separated for reasons of behaviour simplicity, while allowing each to conform to the general pattern and structure of a development problem as shown in Fig. 1, and to benefit from the attendant advantages. The concept of a designed domain is very versatile: its ubiquitous utility reflects the ubiquitous utility of program variables. Some examples of designed domains are: a database in a bank accounts system; a data structure in a road traffic control system, representing the road layout and the positions of traffic light units, pedestrian buttons and vehicle sensors; a train operating timetable; the seat configuration data maintained for each driver by the software of a luxury car; the content and format of a document in an editing and presentation system; and countless others⁴⁸.

In some of these examples the designed domain is clearly an analogical model of the problem world—dynamic in the accounts system, and static in the traffic system⁴⁹. In other examples it is less obviously a model of the physical problem world. In the editing system, for example, it would be very contrived to regard the document domain as a model of the editing events by which it was created. But in all cases the purpose of a designed domain, as of a program variable, is to communicate information between separate behaviours performed or evoked by the machine⁵⁰.

8 Large Behaviour Structure: Control Mechanism

The original machine of a decomposed behaviour controls the machines corresponding to its immediate constituent behaviours. This control relationship induces a rooted tree whose nodes are machines and designed domains, represented in a behaviour control diagram as shown in Fig. 3:

Fig. 3.

Behaviour control diagram: controlling and controlled machines and a designed domain

A machine node can be either a leaf or the root of the tree or of a subtree; a designed domain node can only be a leaf. A machine node represents possible instantiations of the machine: each instantiation starts the machine’s execution and hence starts the corresponding problem world behaviour. The machine root node of the tree represents an instantiation of the whole system by an external agent; in any other case a machine is instantiated by its immediately controlling machine⁵¹. Machine execution instances may be specialised by arguments bound to instances of problem domains⁵².

Temporal relationships among machine instances, including concurrency, are determined by the controlling machine⁵³. For example, the execution pattern in Fig. 3 may be:in which MBX and MBY execute concurrently.

Machine execution may be terminated in several ways. First: a terminating behaviour may come to an autonomous designed halt—that is, a halt corresponding to a particular final outcome foreseen in the design of the machine⁵⁴. Second, although the instantiating agent of a machine is responsible for ensuring that the relevant assumed conditions are present at instantiation, changing environment conditions and other vicissitudes may require pre-emptive abortion of the instantiated behaviour by the instantiating agent⁵⁵. Third: it may be necessary in the ordinary course of system execution to bring a non-terminating behaviour, or a terminating behaviour that has not yet reached a designed halt, to an orderly stop—for example to cease operation of a vending machine when next there is no customer interacting with the machine. This, too, must be commanded by the instantiating agent.

Where two constituent behaviours fulfil closely related functions, their controlling behaviour becomes responsible for orderly termination of the whole. For example, in a system to control paid admissions to a zoo, there may be two constituent behaviours: one to manage payments, the other to manage admissions. On terminating the system behaviour when the zoo closes it is necessary for the controlling behaviour to command an orderly stop of the payments, followed by an orderly stop of admissions when the payments received have been exhausted—or, perhaps when it is clear that there are no more visitors to be admitted.

The controlled states of a machine are shown in Fig. 4.

Fig. 4.

Standard interface for behaviour control

On instantiation the machine enters its initialising state. If initialisation completes successfully the machine enters its running state; alternatively, it may first reach a designed halt, or receive a stop command from its controller. A stop command causes the machine to halt at the next occurrence of a stable problem world state satisfying a defined condition: for example, orderly termination of a lift behaviour might require the lift car to be stationary at a floor with the doors open⁵⁶. While stopping, the machine may reach a state [term] in which it is designed to terminate unconditionally, or it may first reach a stable [non-term] state at which termination is not unconditional.

The controller can observe—but not modify—the states of the controlled behaviour shown in Fig. 4, along with more specific state details explicitly exported by the controlled behaviour. For example, the Halted state may be accompanied by an indication failed or OK.

9 Bottom-up Structuring of Large Behaviour

The starting point for the problem depicted in Fig. 2 was a broad, somewhat abstract, understanding of the functional goal of B0: maintaining a certain stated relationship between domains X and Y, constraining Y but not X. Understanding of this abstract goal behaviour B0 led to the problem diagram on the left in Fig. 2. On closer examination of the problem, simplicity criteria demanded the decomposition to behaviours B0’, BX and BY. Understanding of the desired abstract goal behaviour B0, and the analysis which revealed its complexity, anchored the decomposition and provided a first view of the constituent behaviours BX and BY. B0 might even be imagined as the initial step in a refinement process of which the decomposition, and the design of the three behaviours and the designed domain X-to-Y, are the product of imagined subsequent steps. The end effect of these refinement steps is that the original causal chain X → MB0 → Y has been refined to X → MBX → X-to-Y → MBY → Y⁵⁷.

For a complete system of realistic size and complexity no abstract goal behaviour can be identified that captures the overall behaviour as a whole⁵⁸. Instead, the many modes, features, functions, phases, fault mitigations and exception handlers present an almost chaotic population of foreseeable constituent behaviours. Some candidates may be motivated by apparently discrete features or by particular requirements. Others may be hard to identify clearly or even to think of. The eventual interactions and temporal relationships among these candidate behaviours are largely unknown when development is begun. Study and design of these interactions and relationships cannot begin until the constituent behaviours have themselves been brought under some degree of intellectual control by identifying and analysing the subproblems that will define them.

When some candidate constituent behaviours have been identified and analysed in their simplest forms, it becomes possible to consider their relationships and interactions. The whole behavioural structure of the system is progressively⁵⁹ built up as a behaviour control tree of accepted candidates. Some constituent behaviours are identified from needs arising only in the process of constructing the tree. Some constituent behaviours and designed domains are introduced by local applications of top-down design. Very often these designed domains will be analogic models of parts of the system. Behaviour control may be exerted to terminate one behaviour in order to allow another, incompatible, behaviour to be initiated.

10 From Behaviour Specification to Software Execution

The distinction between the problem and subproblem view, as sketched in Figs. 1 and 2, and the behaviour control diagram, as exemplified in Fig. 3, is essentially the distinction between a set of system behaviour views and a unified software view⁶⁰.

The software specification, in terms of machine executions, resulting from the approach described here can be regarded as a large concurrent program, in which each instantiated machine execution corresponds to a process execution. (We note, however, that if two concurrent behaviours produce identical machine responses to the same instance of a problem world event or state change, duplication of the response may be assumed to be harmful. It is then necessary to ensure that the response occurs only once in the problem world for each occurrence of the stimulus.)

If the problem world descriptions {Wi} are expressed in a suitable form they may form the basis for a simulation of the physical problem world, as is normal practice for some systems (an avionics example is presented by O’Halloran [2]). Alternatively, if actual instances of the problem world are conveniently, cheaply and safely available, they may provide a test environment for the software.

Finally, for some purposes—including formal verification of pre-formal reasoning—it may prove expedient to fragment the machine behaviour specification into a set of stimulus-response pairs. In this transformation the structure and dynamic state of the behaviour control tree, the designed domains, and the text pointers of the machine instances must all be faithfully represented.

11 System Behaviour and the Salient Challenges

This paper has sketched an approach to development whose central theme and constant concern is the structuring and design of the system behaviour. The system behaviour is the visible intended effect of software execution, and is therefore the true end product of software development. The identification of the stakeholders’ role as stating and validating desired properties of the system behaviour—rather than mandating behavioural details—is entirely appropriate: responsibility for designing a feasible behaviour that exhibits those properties must lie with the developers.

The focus on system behaviour provides an intellectual tool for addressing the salient development challenges of cyber-physical systems. The behaviour control tree, of which a trivial example is shown in Fig. 3, allows the complex overall behaviour to be comprehended in a nested structure of potentially concurrent constituent behaviour components. There is a parallel here with the advantages of classical structured programming. The nested behaviour structure establishes a tree of regions of the system’s operating envelope⁶¹, each with the accompanying assumptions that justify the chosen formalisations of the problem world properties. Construction of this tree must proceed largely bottom-up. Until a good understanding has been achieved of its components at every level, it is impossible to determine the scope either of proposed invariant requirements or of the validity of proposed formalisations of given problem domain properties.

At the level of a constituent behaviour the approach to complexity is incremental. In a subproblem the behaviour is initially considered in isolation as a complete system in itself. This initial treatment clarifies the simplest case of the behaviour, in which nothing goes wrong and there is no interference from interaction with other behaviours at common problem domains. At later stages the subproblem is revisited to address these and other sources of complexity. For example: deviation from the simplest case to handle a minor exception; modification to ensure compatibility with other behaviours; and interaction with the controlling parent or child behaviours. It may then become necessary to distinguish multiple versions of the behaviour according to the complexities of the context.

The fundamental thesis of this paper is that behaviour is an indispensable concept for developing dependable cyber-physical systems. The approach briefly presented here is still very much a work in progress, aiming to address, directly and effectively, the salient challenges of behavioural design and structuring.