A Semantic Theory of the Internet of Things

A Semantic Theory of the Internet of Things

Valentina Castiglioni The contribution of this author is limited to an early writing of some of the proofs in the Appendix. Dipartimento di Scienza e Alta Tecnologia, Università dell’Insubria, Como, Italy Ruggero Lanotte Dipartimento di Scienza e Alta Tecnologia, Università dell’Insubria, Como, Italy Massimo Merro Dipartimento di Informatica, Università degli Studi di Verona, Italy

We propose a process calculus for modelling systems in the Internet of Things paradigm. Our systems interact both with the physical environment, via sensors and actuators, and with smart devices, via short-range and Internet channels. The calculus is equipped with a standard notion of bisimilarity which is a fully abstract characterisation of a well-known contextual equivalence. We use our semantic proof-methods to prove run-time properties as well as system equalities of non-trivial IoT systems.

1 Introduction

In the Internet of Things (IoT) paradigm, smart devices, such as smartphones, automatically collect information from shared resources (e.g. Internet access or physical devices) and aggregate them to provide new services to end users [16]. The “things” commonly deployed in IoT systems are: RFID tags, for unique identification, sensors, to detect physical changes in the environment, and actuators, to pass information to the environment.

The research on IoT is currently focusing on practical applications such as the development of enabling technologies [32], ad hoc architectures [30], semantic web technologies [9], and cloud computing [16]. However, as pointed out by Lanese et al. [20], there is a lack of research in formal methodologies to model the interactions among system components, and to verify the correctness of the network deployment before its implementation. Lanese et al. proposed the first process calculus for IoT systems, called IoT-calculus [20]. The IoT-calculus captures the partial topology of communications and the interaction between sensors, actuators and computing processes to provide useful services to the end user. A behavioural equivalence is then defined to compare IoT systems.

Devising a calculus for modelling a new paradigm requires understanding and distilling in a clean algebraic setting the main features of the paradigm. The main goal of this paper is to propose a new process calculus that integrates a number of crucial features not addressed in the IoT-calculus, and equipped with a clearly-defined semantic theory for specifying and reasoning on IoT applications. Let us try to figure out what are the main ingredients of IoT, by means of an example.

Figure 1: A simple smart home

Suppose a simple smart home in which the user can use her smartphone to remotely control the heating boiler of her house, and automatically turn on lights when entering a room. In Fig. 1, we draw a small smart home with an entrance and a lounge, separated by a patio. Entrance and lounge have their own lights (actuators) which are governed by different light manager processes, . The boiler is in the patio and is governed by a boiler manager process, . This process senses the local temperature (via a sensor) and decides whether the boiler should be turned on/off, by setting a proper actuator to signal the state of the boiler.

The smartphone executes two processes: and . The first one reads user’s commands, submitted via the phone touchscreen (a sensor), and forward them to the process , via an Internet channel. Whereas, the process interacts with the processes , via short-range wireless channels (e.g. Bluetooth), to automatically turn on lights when the smartphone physically enters either the entrance or the lounge.

The whole system is given by the parallel composition of the smartphone (a mobile device) and the smart home (a stationary entity).

Now, on such kind of systems one may wish to prove run-time properties. Think of a fairness property saying that the boiler will be eventually turned on/off whenever some conditions are satisfied. Or consistency properties, saying the smartphone will never be in two rooms at the same time. Even more, one may be interested in understanding whether our system has the same observable behaviour of another system. Think of a variant of our smart home, where lights functionality depends on GPS coordinates of the smartphone (localisation is a common feature of today smartphones). Intuitively, the smartphone might send its GPS position to a centralised light manager, (possibly placed in the patio), via an Internet channel. The process will then interact with the two processes , via short-range channels, to switch on/off lights, depending on the position of the smartphone. Here comes an interesting question: Can these two implementations, based on different light management mechanisms, be actually distinguished by an end user?

In the paper at hand we develop a fully abstract semantic theory for a process calculus of IoT systems, called CaIT. We provide a formal notion of when two systems in CaIT are indistinguishable, in all possible contexts, from the point of view of the end user. Formally, we use the approach of [18, 33], often called reduction (closed) barbed congruence, which relies on two crucial concepts: a reduction semantics, to describe system computations, and the basic observables, to represent what the environment can directly observe of a system. In CaIT, there here are at least two possible observables: the ability to transmit along channels, logical observation, and the capability to diffuse messages via actuators, physical observation. We have adopted the second form as our contextual equality remains invariant when adding logical observation. However, the right definition of physical observation is far from obvious as it involves some technical challenges in the definition of the reduction semantics (see the discussion in Sec. 2.3).

Our calculus is equipped with two labelled transition semantics (LTS) in the SOS style of Plotkin [31]: an intensional semantics and an extensional semantics. The adjective intensional is used to stress the fact that the actions here correspond to activities which can be performed by a system in isolation, without any interaction with the external environment. While, the extensional semantics focuses on those activities which require a contribution of the environment. Our extensional LTS builds on the intensional one, byintroducing specific transitions for modelling all interactions which a system can have with its environment. Here, we would like to point out that since our basic observation on systems does not involve the recording of the passage of time, this has to be taken into account extensionally in order to gain a proper extensional account of systems.

As a first result we prove that the reduction semantics coincides with the intensional semantics (Harmony Theorem), and that they satisfy some desirable time properties such as time determinism, patience, maximal progress and well-timedness [17].

However, the main result of the paper is that weak bisimilarity in the extensional LTS is sound and complete with respect to our contextual equivalence, reduction barbed congruence: two systems are related by some bisimulation in the extensional LTS if and only if they are contextually equivalent. This required a non-standard proof of the congruence theorem (Thm. 3). Finally, in order to show the effectiveness of our bisimulation proof method, we prove a number of non-trivial system equalities.


Sec. 2 contains the calculus together with the reduction semantics, the contextual equivalence, and a discussion on design choices. Sec. 3 gives the details of our smart home example, and provides desirable run-time properties for it. Sec. 4 defines both intensional and extensional LTSs. In Sec. 5 we define bisimilarity for IoT-systems, and prove the full abstraction result together with a number of non-trivial system equalities. Sec. 6 discusses related work, and concludes.

2 The calculus

In Tab. 1 we give the syntax of our Calculus for the Internet of Things, shortly CaIT, in a two-level structure: a lower one for processes and an upper one for networks of smart devices. We use letters to denote nodes/devices, for channels, for (physical) locations, for sensors, for actuators and for variables. Our values, ranged over by and , are constituted by basic values, such as booleans and integers, sensor and actuator values, and coordinates of physical locations.

Table 1: Syntax

A network is a pool of distinct nodes running in parallel. We write to denote the empty network, while represents parallel composition. In channel is private to the nodes of . Each node is a term of the form , where is the device ID; is the physical interface of , a partial mapping from sensor and actuator names to physical values; is the process modelling the logics of ; is the physical location of the device; is a tag to distinguish between stationary and mobile nodes.

For security reasons, sensors in can be read only by its controller process . Similarly, actuators in can be modified only by . No other devices can access the physical interface of . Nodes live in a physical world which can be divided in an enumerable set of physical locations. We assume a discrete notion of distance between two locations and , i.e. .

In a node , denotes a timed concurrent process which manages both the interaction with the physical interface and channel communication. The communication paradigm is point-to-point via channels that may have different transmission ranges. We assume a global function that given a channel returns an element of . Thus, a channel can be used for: i) intra-node communications, if ; ii) short-range inter-node communications (such as Bluetooth, infrared, etc) if ; iii) Internet communications, if .

Our processes build on CCS with discrete time [17]. We write , with , to denote intra-node actions. The process sleeps for one time unit. The process gets the current location of the enclosing node. Process reads a value from sensor . Process writes the value on the actuator . We write , with , to denote channel communication with timeout. This process can communicate in the current time interval and then continues as P; otherwise, after one time unit, it evolves into . We write for conditional (guard is always decidable). In processes of the form and the occurrence of is said to be time-guarded. The process denotes time-guarded recursion, as all occurrences of the process variable may only occur time-guarded in . In processes , and the variable is said to be bound. Similarly, in process the process variable is bound. In the term the channel is bound. This gives rise to the standard notions of free/bound (process) variables, free/bound channels, and -conversion. A term is said to be closed if it does not contain free (process) variables, although it may contain free channels. We always work with closed networks: the absence of free variables is preserved at run-time. We write for the substitution of the variable with the value in any expression of our language. Similarly, is the substitution of the process variable with the process in .

Actuator names are metavariables for actuators like or . As node names are unique so are actuator names: different nodes have different actuators. The sensors embedded in a node can be of two kinds: location-dependent and node-dependent. The first ones sense data at the current location of the node, whereas the second ones sense data within the node, independently on the node’s location. Thus, node-dependent sensor names are metavariables for sensors like or ; whereas a sensor , for external temperature, is a typical example of location-dependent sensor. Like actuators, node-dependent sensor names are unique. This is not the case of location-dependent sensor names which may appear in different nodes. For simplicity, we use the same metavariables for both kind of sensors. When necessary we will specify the type of sensor in use.

The syntax given in Tab. 1 is a bit too permissive with respect to our intentions. We could rule out ill-formed networks with a simple type system. For the sake of simplicity, we prefer to provide the following definition.

Definition 1.

A network is said to be well-formed if

  • it does not contain two nodes with the same name

  • different nodes have different actuators

  • different nodes have different node-dependent sensors

  • for each in , with a prefix (resp. ) in , (resp. ) is defined

  • for each in with defined for some location-dependent sensor , it holds that .

Last condition implies that location-dependent sensors may be used only in stationary nodes. This restriction will be commented in Sec. 2.3. Hereafter, we will always work with well-formed networks. It is easy to show that well-formedness is preserved at runtime.

To end this section, we report some notational conventions. denotes the parallel composition of all , for . We identify and , if . Sometimes we write when the index set is not relevant. We write instead of . We write as an abbreviation for . For , we write as a shorthand for , where prefix appears times. Finally, we write as an abbreviation for , for .

2.1 Reduction semantics

Table 2: Structural congruence

Table 3: Reduction semantics

The dynamics of the calculus is specified in terms of reduction relations over networks described in Tab. 3. As usual in process calculi, a reduction semantics [27] relies on an auxiliary standard relation, , called structural congruence, which brings the participants of a potential interaction into contiguous positions. Formally, structural congruence is defined as the congruence induced by the axioms of Tab. 2.

As CaIT is a timed calculus, with a discrete notion of time, it will be necessary to distinguish between instantaneous reductions, , and timed reductions, . Relation denotes activities which take place within one time interval, whereas represents the passage of one time unit. Our instantaneous reductions are of two kinds: those which involve the change of the values associated to some actuator , written , and the others, written . Intuitively, reductions of the form denote watchpoints which cannot be ignored by the physical environment (in Ex. 2, and more extensively at the end of Sec. 2.3, we explain why it is important to distinguish between and ). Thus, we define the instantaneous reduction relation , for any actuator . We also define .

The first seven rules in Tab. 3 model intra-node activities. Rule (sensread) represents the reading of the current data detected at some sensor . Rule (pos) serves to compute the current position of a node. Rules (actunchg) and (actchg) implement the writing of some data on an actuator , distinguishing whether the value of the actuator changes or not. Rule (loccom) models intra-node communications on a local channel (). Rule (timestat) models the passage of time within a stationary node. Notice that all untimed intra-node actions are considered urgent actions as they must occur before the next timed action. As an example, position detection is a time-dependent operation which cannot be delayed. Similar argument applies to sensor reading, actuator writing and channel communication. Rule (timemob) models the passage of time within a mobile node. This rule also serves to model node mobility. Mobile nodes can nondeterministically move from one physical location to a (possibly different) location , at the end of a time interval. Node mobility respects the following time discipline: in one time unit a node located at can move to any location such that , for some fixed (obviously, it is possible to have and ). For the sake of simplicity, we fix the same constant for all nodes of our systems. The premises of Rules (timestat) and (timemob) ensure that if a node can perform a timed reduction then the same node cannot perform an instantaneous reduction . Actually, due to the syntactic restrictions in the premises of both rules, that node cannot perform an instantaneous reduction either. This is formalised in Prop. 2.

Rule (glbcom) models inter-node communication along a global channel (). Intuitively, two different nodes can communicate via a common channel if and only if they are within the transmission range of . Rule (timepar) is for inter-node time synchronisation; the passage of time is allowed only if all instantaneous reductions have already fired. Well-timedness (Prop. 4) ensures the absence of infinite instantaneous traces which would prevent the passage of time. The remaining rules are standard.

We write as an shorthand for consecutive reductions ; is the reflexive and transitive closure of . Similar conventions apply to the reduction relation .

Below we report a few standard time properties which hold in our calculus: time determinism, maximal progress, patience and well-timedness.

Proposition 1 (Local time determinism).

If and , then and , with , for all .

In its standard formulation, time determinism says that a system reaches at most one new state by executing a reduction . However, by an application of Rule (timemob), our mobile nodes may change location when executing a reduction , thus we have a local variant of time determinism.

According to [17], the maximal progress property says that processes communicate as soon as a possibility of communication arises. In our calculus, we generalise this property saying that instantaneous reductions cannot be delayed.

Proposition 2 (Maximal progress).

If , then there is no such that .

On the other hand, if no instantaneous reductions are possible then time is free to pass.

Proposition 3 (Patience).

If for no , then there is such that .

Finally, time-guardedness in recursive processes allows us to prove that our networks are always well-timed.

Proposition 4 (Well-timedness).

For any there is a such that if then .

2.2 Behavioural equivalence

In this section we provide a standard notion of contextual equivalence for our systems. Our touchstone equivalence is reduction barbed congruence [18, 28], a standard contextually defined process equivalence. Intuitively, two systems are reduction barbed congruent if they have the same basic observables in all contexts and under all possible computations.

As already pointed out in the Introduction, the notion of reduction barbed congruence relies on two crucial concepts: a reduction semantics to describe system computations, and the basic observable which denotes what the environment can directly observe of a system111See [33] for a comparison between this approach and the original barbed congruence [28].. So, the question is: What are the “right” observables, or barbs, in our calculus? Due to the hybrid nature of our systems we could choose to observe either channel communications -logical observation- as in standard process calculi, or the capability to diffuse messages via actuators -physical observation- or both things. Actually, it turns out that in CaIT logical observations can be expressed in terms of physical ones (see Sec. 2.3 for more details). So, we adopt as basic observables the capability to publish messages on actuators.

Definition 2 (Barbs).

We write if with . We write if .

The reader may wonder why our barb reports the location and not the node of the actuator. We recall that actuator names are unique, so they somehow codify the name of their node. The location is then necessary because the environment is potentially aware of its position when observing an actuator: if on Monday at 6.00AM your smartphone rings to wake you up, then you may react differently depending whether you are at home or on holidays in the Bahamas!

Definition 3.

A binary relation over networks is barb preserving if and implies .

Definition 4.

A binary relation over networks is reduction closed if whenever the following conditions are satisfied:

  • implies with

  • implies with .

We require reduction closure of both and , for any (for understanding this choice, please see Ex. 2).

In order to model sensor updates made by the physical environment on a sensor in a given location , we define an operator on networks.

Definition 5.

Given a location , a sensor , and a value in the domain of , we define:

As for barbs, the reader may wonder why when updating a sensor we use its location, also for node-dependent sensors. This is because when changing a node-dependent sensor (e.g. touching a touchscreen of a smartphone) the environment is in general aware of its position.

Definition 6.

A binary relation over networks is contextual if implies that

  • for all networks ,

  • for all channels ,

  • for all sensors , locations , and values in the domain of , .

The first two clauses requires closure under logical contexts (parallel systems), while the last clause regards physical contexts, which can nondeterministically update sensor values.

Finally, everything is in place to define our touchstone behavioural equality.

Definition 7.

Reduction barbed congruence, written , is the largest symmetric relation over networks which is reduction closed, barb preserving and contextual.

Remark 1.

Obviously, if then and will be still equivalent in any setting where sensor updates are governed by specific physical laws. This is because the physical contexts that can affect sensor values, according to some physical law, are definitely fewer than those which can change sensors nondeterministically.

We recall that the reduction relation ignores the passage of time, and therefore the reader might suspect that our reduction barbed congruence is impervious to the precise timing of activities. We will show that this is not the case.

Example 1.

Let and be two networks such that and , with . It is easy to see that . As the reduction relation does not distinguish instantaneous reductions from timed ones, one may think that networks and are reduction barbed congruent, and that a prompt transmission along channel is equivalent to the same transmission delayed of one time unit. However, let us consider the test , with , for some (fresh) actuator . Our claim is that test can distinguish the two networks, and thus . In fact, if , with , then there is no such that with . This is because can perform a reduction sequence that cannot be matched by any .

Behind this example there is the general principle that reduction barbed congruence is sensitive to the passage of time.

Proposition 5.

If and then there is such that and .


Suppose . Consider the test such that both systems and are well-formed, and . By construction, the presence of a barb in a derivative of one of those systems implies that exactly one timed reduction has been inferred in the derivation.

Since it follows that , with and . As and is contextual, the reduction sequence above must be mimicked by , that is , with . As a consequence, . This implies that exactly one timed reduction has been inferred in the reduction sequence . As and are well-formed networks, the actuator can appear neither in nor in . So, the above reduction sequence can be decomposed as follows:

with . From it is easy to derive (for details see Lem. 1 in Sec. 5). ∎

Now, we provide some insights into the design decision of having two different reduction relations and .

Example 2.

Let and be two networks such that and , with and undefined otherwise. Then, within one time unit, may display on the actuator either the sequence of values or the sequence , while can only display the sequence . As a consequence, from the point of view of the physical environment, the observable behaviours of and are clearly different. In the following we show how can observe that difference. We recall that the relation is reduction closed. Now, if , with , the only possible reply of respecting reduction closure is . However, it is evident that because can turn the actuator to while cannot. Thus, .

Notice that if the relation was merged together with then in the previous example we would have . In fact, if we would merge the two reduction relations then the capability to observe messages on actuators, given by the barb, would not be enough to observe changes on actuators within one time unit. On the other hand, the decision of not including as part of gives to enough distinguishing power to observe strong preservation of barbs.

Proposition 6.

If and then .


We recall that . Let us suppose that . As is barb preserving it follows that , namely, , for some . We note that both reduction relations and do not modify actuator values. As a consequence, this holds also for . Thus, . ∎

2.3 Design choices

In this section we provide some insights into the design choices adopted in CaIT. The main goal of CaIT is to provide a simple calculus to deal with the programming paradigm of IoT systems. Thus, for instance, CaIT is a value-passing rather than a name-passing calculus, as the -calculus [33]. However, the theory of CaIT can be easily adapted to deal with the transmission of channel names at the price of adding the standard burden of scope-extrusion of names. Furthermore, as both actuators and sensors can only be managed inside their nodes, it would make little sense to transmit their names along channels.

CaIT is a timed process calculus with a discrete notion of time. The time model we adopt in CaIT is known as the fictitious clock approach (see e.g. [17]): a global clock is supposed to be updated whenever all nodes agree on this, by globally synchronising on a special timing action . Thus, time synchronisation relies on some clock synchronisation protocol for mobile wireless systems [36]. However, our notion of time interval is different from that adopted in synchronous languages [4, 1, 6] where the environment injects events at the start of instants and collect them at the end. In the synchronous approach, events happening during a time interval are not ordered while in our calculus we want to maintain the causality among actions, typical of process calculi.

In cyber-physical systems [34], sensor changes are modelled either using continuous models (differential equations) or through discrete models (difference equations)222Difference equations relate to differential equations as discrete math relate to continuous math.. However, in this paper we aim at providing a behavioural semantics for IoT applications from the point of the view of the end user. And the end user cannot directly observe changes on the sensors of an IoT application: she can only observe the effects of those changes via actuators and communication channels. Thus, in CaIT we do not represent sensor changes via specific models, but we rather abstract on them by supporting nondeterministic sensor updates (see Def. 5 and 6). Actually, as seen in Rem. 1, behavioural equalities derived in our setting remains valid when adopting any specific model for sensor updates.

Another design decision in our language regards the possibility to change the value associated to sensors and actuators more than once within the same time interval. At first sight this choice may appear weird as certain actuators are physical devices that may require some time to turn on. On the other hand, other actuators, such as lights or displays, may have very quick reactions. A similar argument applies to sensors. In this respect our calculus does not enforce a synchronisation of physical events as for logical signals in synchronous languages. In fact, actuator changes are under nodes’ control: it is the process running inside a node that decides when changing the value exposed on an actuator of that node. Thus, if the actuator of a node models a slow device then it is under the responsibility of the process running at that node to change the actuator with a proper delay. Similarly, sensors should be read only when this makes sense. For instance, a temperature sensor should be read only when the temperature is supposed to be stable.

Let us now discuss on node mobility. The reader may wonder why CaIT does not provide a process to drive node mobility, as in Mobile Ambients [7]. Notice that, unlike Mobile Ambients, our nodes do not represent mobile computations within an Internet domain. Instead, they represent smart devices which do not decide where to move to: an external agent moves them. We also decided to allow node mobility only at the end of time intervals. This is because both intra-node and inter-node logical operations, such as channel communications, can be considered significantly faster than physical movements of devices. For instance, consider a transmitter that moves at 20 m/s and that transmits a 2000-byte frame over a channel having a 2 megabit/s bandwidth. The actual transmission would take about 0.008 s; during that time, the transmitter moves only about 16 cm away. In other words, we can assume that the nodes are stationary when transmitting and receiving, and may change their location only while they are idle. However, to avoid uncontrolled movements of nodes we decided to fix for all of them the same bound , representing the maximum distance a node can travel within one time unit. There would not be problems in allowing different for different nodes. Finally, for the sake of simplicity, in the last constraint of Def. 1 we impose that location-dependent sensors can only occur in stationary nodes. This allows us to have a local, rather than a global, representation of those sensors. Notice that mobile location-dependent sensors would have the same technical challenges of mobile wireless sensor networks [38].

Another issue is about a proper representation of network topology. A tree-structure topology, as in Mobile Ambients, would be desirable to impose that a device cannot be in two mutually exclusive places at the same time. This desirable property cannot be expressed in [20], where links between nodes can be added and removed nondeterministically. However, a tree-structured topology would imply an higher-order bisimulation (for details see [26]); while in the current paper we look for a simple (first-order) bisimulation proof-technique which could be easily mechanised.

Finally, we would like to explain our choice about barbs. As already said in the previous section there are other possible definitions of barb. For instance, one could choose to observe the capability to transmit along a channel , by defining if , with and . However, if you consider the system , with , for some appropriate , then it is easy to show that if and only if . Thus, the barb on channels can always be reformulated in terms of our barb. The vice versa is not possible. The reader may also wonder whether it is possible to turn the reduction into by introducing, at the same time, some special barb which would be capable to observe actuators changes. For instance, something like if , with and . It should be easy to see that this extra barb would not help in distinguishing the terms proposed in Ex. 2. Actually, here there is something deeper that needs to be spelled out. In process calculi, the term of a barb is a concise encoding of a context expressible in the calculus and capable to observe the barb . However, our barb does not have such a corresponding physical context in our language. For instance, in CaIT we do not represent the “eyes of a person” looking at the values appearing to some display. Technically speaking, we don’t have terms of the form that could be used by the physical environment to read values on the actuator . This is because such terms would not be part of an IoT system. The lack of this physical, together with the persistent nature of actuators’ state, explains why our barb must work together with the reduction relation to provide the desired distinguishing power of .

3 Case study: a smart home

Table 4: A smart home in CaIT

In this section we model the simple smart home discussed in the Introduction, and represented in Fig. 1. Our house spans over contiguous physical locations , for , such that . The entrance (also called Room1) is in , the patio spans from to and the lounge (also called Room2) is in . The house can only be accessed via its entrance, i.e. Room1.

Our system consists of the smartphone, , and the smart home, . The smartphone is represented as a mobile node, with , initially placed outside the house: , for . As the phone can only access the house from its entrance, and , we have , for any and . Its interface contains only one sensor, called , representing the touchscreen to control the boiler. This is a node-dependent sensor. The process reads and forwards its value to the boiler manager, , via the Internet channel (). The domain of the sensor is , where stands for manual and for automatic; initially, .

In there is a second process, called , which allows the smartphone to switch on lights only when getting in touch with the light managers installed in the rooms. Here channels and serve to control the lights of Room 1 and 2, respectively; these are short-range channels: . The light managers are , , respectively. These are stationary nodes running the processes and to manage the corresponding lights via the actuators , for . The domain of these actuators is ; initially, , for .

Let us describe the behaviour of the boiler manager in node . Here, the physical interface contains a sensor and an actuator ; is a location-dependent temperature sensor, whose domain is , and is an actuator to display boiler functionality, whose domain is . Processes and model the two boiler modalities. In mode sensor is periodically checked: if the temperature is under a threshold then the boiler will be switched on, otherwise it will be switched off. Conversely, in manual mode, the boiler is always switched on. Initially, and .

Our system enjoys a number of desirable run-time properties. For instance, if the boiler is in manual mode or its temperature is under the threshold then the boiler will get switched on, within one time unit. Conversely, if the boiler is in automatic mode and its temperature is higher than or equal to the threshold , then the boiler will get switched off within one time unit. These two fairness properties can be easily proved because our calculus is well-timed. In general, similar properties cannot be expressed in untimed calculi like that in [20]. Finally, our last property states the phone cannot act on the lights of the two rooms at the same time, manifesting a kind of “ubiquity”. Again, this undesired behaviour is admissible in the calculus of [20]. For the sake of simplicity, in the following proposition we omit location names both in barbs and in sensor updates, writing instead of , and instead of . The system denotes an arbitrary (stable) derivative of .

Proposition 7.

Let , for some .

  • If then

  • If , with , then

  • If , with , then

  • If then , and vice versa.

Finally, we propose a variant of our system, where lights functionality depends on the GPS coordinates of the smartphone. Intuitively, the smartphone sends its actual position to a centralised light manager via an Internet channel , . The centralised manager will then interact with the local light managers to switch on/off lights of rooms, depending on the position of the smartphone.

Table 5: Smart home: a position based light management

In Table 5, new components have been overlined. Short-range channels have now different ranges and they serve to communicate with the centralised light manager . Thus, and .

Prop. 7 holds for the new system as well. Actually, the two systems are closely related.

Proposition 8.

For , .

The bisimulation proof technique developed in the remainder of the paper will be very useful to prove such kind of non-trivial system equalities.

We end this section with a comment. While reading this case study the reader should have realised that our reduction semantics does not model sensor updates. This is because sensor changes depend on the physical environment, while a reduction semantics models the evolution of a system in isolation. Interactions with the external environment will be treated in our extensional semantics (see Sec. 4)

4 Labelled transition semantics

Table 6: Intensional semantics for processes

Table 7: Intensional semantics for networks

In this section we provide two labelled semantic models, in the SOS style of Plotkin [31]: the intensional semantics and the extensional semantics. The adjective intensional is used to stress the fact that the actions of that semantics correspond to those activities which can be performed by a system in isolation, without any interaction with the external environment. Whereas, the extensional semantics focuses on those activities which require a contribution of the environment.

4.1 Intensional semantics

Since our syntax distinguishes between networks and processes, we have two different kinds of transitions:

  • , with , for process transitions

  • , with , for network transitions.

In Tab. 6 we report standard transition rules for processes. As in CCS, we assume if , and if . Rule (Com) model intra-node communications along channel ; that’s why . The symmetric counterparts of Rules (ParP) and (Com) are omitted.

In Tab. 7 we report the transition rules for networks. Rule (Pos) extracts the position of a node. Rule (SensRead) models the reading of a value from a sensor of the enclosing node. Rules (ActUnChg) and (ActChg) describes the writing of a value on an actuator of the node, distinguishing whether the value of the actuator is changed or not. Rule (LocCom) models intra-node communications. Rule (TimeStat) models the passage of time for a stationary node. Rule (TimeMob) models both time passing and node mobility at the end of a time interval. Rules (Snd) and (Rcv) represent transmission and reception along a global channel. Rule (GlbCom) models inter-node communications. The remaining rules are straightforward. The symmetric counterparts of Rule (ParN) and Rule (GlobCom) are omitted.

As expected, the reduction semantics and the labelled intensional semantics coincide.

Theorem 1 (Harmony theorem).

Let :

  • implies

  • implies .

4.2 Extensional semantics

Table 8: Extensional semantics: additional rules

Here we redesign our LTS to focus on the interactions of our systems with the external environment. As the environment has a logical part (the parallel nodes) and a physical part (the physical world) our extensional semantics distinguishes two different kinds of transitions:

  • , logical transitions, for , to denote the interaction with the logical environment; here, actuator changes, - and -actions are inherited from the intensional semantics, so we don’t provide inference rules for them;

  • , physical transitions, for , to denote the interaction with the physical world.

In Tab. 8 the extensional actions deriving from rules (SndObs) and (RcvObs) mention the location of the logical environment which can observe the communication occurring at channel . Rules (SensEnv) and (ActEnv) model the interaction of a system with the physical environment. In particular, the environment can nondeterministically update the current value of a (location-dependent or node-dependent) sensor with a value , and can read the value appearing on an actuator at . As already discussed in Sec. 2.2 the environment is potentially aware of its position when doing these actions.

Note that our LTSs are image finite. They are also finitely branching, and hence mechanisable, under the obvious assumption of finiteness of all domains of admissible values, and the set of physical locations.

5 Full abstraction

Based on our extensional semantics, we are ready to define a notion of bisimilarity which will be showed to be both sound and complete with respect to our contextual equivalence. We adopt a standard notation for weak transitions. We denote with the reflexive and transitive closure of -actions, namely , whereas means , and finally denotes if and otherwise.

Definition 8 (Bisimulation).

A binary symmetric relation over networks is a bisimulation if and imply there exists such that and . We say that and are bisimilar, written , if for some bisimulation .

Sometimes it is useful to count the number of -actions performed by a process. The expansion relation [2], written , is an asymmetric variant of such that holds if and has at least as many -moves as .

As a workbench we can use our notion of bisimilarity to prove a number of algebraic laws on well-formed networks.

Theorem 2 (Some algebraic laws).