Recent advancements in the elds of embedded systems, communication technologies and computer science, have laid the foundations for new kinds of applications in which a plethora of physical devices are interconnected and immersed in an environment together with human beings. These so-called Cyber-Physical Systems (CPS) issue a design challenge for new architecture in order to cope with problems such as the heterogeneity of devices, the intrinsically distributed nature of these systems, the lack of reliability in communications, etc. In this paper we introduce Rainbow, an architecture designed to address CPS issues. Rainbow hides heterogeneity by providing a Virtual Object (VO) concept, and addresses the distributed nature of CPS introducing a distributed multi-agent system on top of the physical part. Rainbow aims to get the computation close to the sources of information (i.e., the physical devices) and addresses the dynamic adaptivity requirements of CPS by using Swarm Intelligence algorithms.
The increasing use of smart devices and appliances opens up new ways to build
applications that integrate the physical and virtual world into consumer-oriented
context-sensitive Cyber-Physical Systems (CPS) [
The emerging cyber-physical world interconnects a vast variety of static and
mobile resources, including computing/medical/engineering devices,
sensor/actuator networks, swarm of robots etcetera. Examples of CPS applications include
[
This scenario is supported by recent technology advancement in the elds of
communication, embedded systems and computer science. On the
communication side, new protocols like EPC TDS and IPv6 ensure unique addressability
for all the elements involved in a CPS, while connectivity technologies like IEEE
802.11, ZigBee, Umts and ZTE, could ensure light and fast connection between
the devices involved in the system and between the devices and the Internet. On
the embedded systems side, the miniaturization and the constant improvement
of energy e ciency of electronic components enables the environment to be easily
instrumented with sensors, actuators and computing devices, while the presence
on the market of cheap and general purpose single-board computers, like
Raspberry PI [
The complexity of a CPS, and the large number of elements involved, makes data analysis and operation planning a very di cult task. A currently used approach involves two layers: a physical layer and a remote (cloud) cyber layer. The physical layer sends sensed data to a remote server, which processes them and computes a suitable operation plan. Afterwards, the remote server sends the sequence of operations it must execute to each device on the physical layer. The reasoning is performed in the remote layer. This solution cannot be applied when there are constraints on responsivity time, that is, when a system needs to react fast to critical events that may overwhelm its integrity and functionality. Communication lag and remote processing can cause delays that a system simply cannot bear. A wide variety of applications means a wide variety of devices. Currently, there is a plethora of di erent devices, each with its own particular functionalities and capabilities. There are simple devices without any computational unit as well as \smarter" devices with high computation power inside. There are devices with no operating systems and devices with simple or complex operating systems, such as tinyOS or Android. Our framework is designed to cope with this inherent heterogeneity. To addressing the issues described above, our proposal moves on these main lines: { Hiding the heterogeneity of CPS by introducing a virtual object layer. { Moving the computation as close as possible to the physical resources in order to foster good performance and scalability. { Introducing a distributed intelligence layer between the physical world and remote servers (cloud), which can execute complex tasks and horizontally/vertically coordinate the devices. { Switching from a cloud-based model to a cloud-assisted one, where the intelligent intermediate level carries out almost all the real-time control tasks, whereas the remote cloud level remains in charge of non-real-time tasks such as o ine data analysis or presentation. The information provided by the data analysis executed by the remote server are used by the intermediate level to optimize its operations and behaviour.
In this paper we propose a three-tier architecture (Rainbow) that uses singleboard computers such as the Raspberry PI to connect massive-scale networks of sensors to the Cloud. This architecture is composed by the Cloud layer, the Intermediate layer and the Physical layer. Sensors are partitioned into groups, each of which is managed by a single computing node. These computing nodes host multi-agent applications designed to monitor multiple conditions or activities within a speci c environment. Furthermore, agents can be intelligently assisted by cloud services, that support complex analytics, modeling, optimization and visualization tools, to make better operation decisions.
We present a new integrated vision that allows the designing of a
largescale networked CPS based on the decentralization of control functions and the
assistance of cloud services to optimize their behaviour. Decentralization will
be obtained using a distributed multi-agent system in which the execution of a
CPS application is carried out through agents' cooperation [
The remainder of this paper is structured as follows: Section 2 is devoted to a description of the proposed Rainbow Architecture; Section 3 describes two example of use; nally, we draw conclusions and the future works. 2
Rainbow is a three-layer architecture designed in order to bring the computation (i.e the controlling part) as close as possible to the physical part. Since CPS foresees that physical entities are spread across a large (even geographic) area, the previous assumption implies the controlling part to be intrinsically distributed.
Our proposal foresees the use of a distributed agent-based layer in order to address the aforementioned issues. The agent paradigm has several important characteristics: Autonomy. Each agent is self-aware and has a self-behaviour. It perceives the environment, interacts with others and plans its execution autonomously. Local views. No agent has a full global view of the whole environment but it behaves solely on the basis of local information.
Decentralization. There is no \master" agent controlling the others, but the system is made up of interacting \peer" agents.
Through these basic features, multi-agent systems make it possible to obtain complex emergent behaviours based on the interactions among agents that have a simple behaviour. Examples of emergent behaviour could refer to the properties of adaptivity, fault tolerance, self-recon guration, etcetera. In general, we could talk about swarm-intelligence when an \intelligent" behaviour emerges from interactions among simple entities. There are many swarm intelligence algorithms in the literature that could be properly adopted in the context of CPS. In 3.2 we show an example where Swarm Intelligence is used to map noise pollution inside a city area.
Rainbow architecture is shown in Figure 1. As it can be seen, the architecture is structured into three layers. The bottom layer is the one that is devoted to the physical part. It encloses sensors and actuators, together with their relative computational capabilities, which are directly immersed in the physical environment.
In the Intermediate layer, sensors and actuators of the physical layer are represented as virtual objects (VOs). VOs o er to the agents a transparent and ubiquitous access to the physical part due to a well-established interface Computing Node
A A
VO VO VO
exposed as API. VO allows agents to connect directly to devices without care about proprietary drivers or addressing some kind of ne-grained technological issues. Each VO comprises \functionalities" directly provided by the physical part. Essentially, a VO exposes an abstract representation (i.e. machine-readable description) of the features and capabilities of physical objects spread in the environment. Functionalities exposed by di erent types of VOs can be combined in a more sophisticated way on the basis of event-driven rules which a ect highlevel applications and end-users.
In summary, as detailed in section 2.1, all the devices are properly wrapped in VOs which, in turn, are enclosed in distributed gateway containers. The computational nodes that host the gateways represent the middle layer of the Rainbow architecture. Each node also contains an agent server that permits agents to be executed properly. Gateways and agent servers are co-located in the same computing nodes in order to guarantee that agents exploit directly the physical part through VO abstraction. Instead of transferring data to a central processing unit, we actually transfer the process (i.e. ne-grain agent's execution) toward the data sources. As a consequence, less data needs to be transferred over a long distance (i.e. toward remote hosts) and local access and computation will be fostered in order to achieve good performance and scalability .
The upper layer of Rainbow architecture concerns the cloud part. This layer addresses all the activities that cannot be properly executed in the middle layer like, for instance, algorithms needing complete knowledge, tasks that require high computational resources or when a historical data storage is mandatory. On the contrary, all tasks where real time access to the physical part is required could be suitably executed in the middle layer. 2.1
We address issues about heterogeneity in CPS by introducing the Virtual Object (VO) concept. VO aims to hide heterogeneity by supplying a well-established interface permitting the physical parts to be suitably integrated with the rest of the system.
VO could be de ned as a collection of physical entities like sensors and actuators, together with their computational abilities.
It can be composed of just a simple sensor or it can be a more complex object that includes many sensors, many actuators, computational resources like CPU or memory and so on.
In general, VO outputs can be represented by punctual values (e.g. the temperature at a given point of a room) or aggregate values (e.g. the average of moisture during the last 8 hours). Also, the values returned by VOs could be just the measurement of sensors or could be the result of complex computations (e.g. the temperature of a given point of space computed by means of interpolation of the values given by sensors spread across the environment).
Furthermore, a VO could supply actuation functionality by changing the environment on the basis of external triggers or internal calculus.
These di erent kinds of behaviour that VO can expose must be taken into account. VO is therefore conceived as a complex object that can read and write upon many simple physical resources. More in detail, we consider that each VO exposes di erent functionalities. Each functionality can be either sensing or actuating and can be re ned by further parameters that dynamically con gure it.
The previous assumption leads to the de nition of resource as the following triplet :
[V OId; V OF unctionId; P arams]
Where VOId uniquely identi es the VO, VOFunctionId identi es the speci c functionality and Params is an ordered set of parameter values that con gure the functionality.
For example let's consider a Virtual Room made of sensors for measuring different physical quantities inside a room such as temperature, moisture, brightness and so on. Suppose now you want to read from Smart Room the temperature in a given spatial point of the room. In that case the triplet could be: [V irtualRoom; temperature; [x; y; z]] Where x, y and z are the cartesian coordinate of the point of interest.
Using object oriented terminology, a Resource could be seen as a particular \instance" of a functionality of a given VO.
Besides read and write operations (i.e. sensing and actuation), it is provided for VOs to be able to manage events that occur in the physical part. To that scope, our proposed middleware includes a publish/subscribe component for managing events in each computing node. Each event is de ned by a logical rule where one or more VOs could be involved.
Each rule is a logical proposition in which the atomic predicates can be of the following kinds: - resource < threshold (e.g. temperature < 300) - resource > threshold - boolean resource (e.g. the door was unlocked)
Just an example of rule: (temperature < 100 and brightness >500) or people > 3 or door unlocked All the physical things linked to a computing node together with relative VOs is enclosed in the Gateway container. The Gateway exposes an interface to interact directly with the VOs.
Each gateway represents the \entry point" that agents can use to exploit VOs of the relative computing node.
In the following is described the interface of Gateway that will be used by the overlying layer: interface GatewayInterface { void resourceNaming(String name, VOId voId, VOFunctionId functionId,
VOFunctionParams params); VOResult check(String name); VOResult check(String name, VOFunctionParams params); VOResult acting(String name); VOResult acting(String name, VOFunctionParams params); void setRule(Rule rule, String idRule); void subscribe(String idRule, EventHandler handler); }
The method resourceNaming assigns an identi cation name to a given resource supplied by a given VO. A resource is a speci c instance of a functionality of a VO re ned by some parameters. In other word, a resource is the above-mentioned triplet: [V OId; V OF unctionId; P arams]. The name assigned to a resource via resourceNaming can be used in the other methods in order to simply identify the resource. Furthermore, the identi cation name of a resource is useful to compose the rules in a more human-readable fashion.
The method check reads the current value of the resource identi ed by name whereas acting triggers the actuation operation upon the resource identi ed by name. Both check and acting methods are of two kinds: the rst take only name as parameter and refers to the resource as it is previously de ned in resourceNaming; the second kind, instead, permits the parameters of the referred resource to be re ned dynamically.
The method setRule permits a complex rule to be published (e.g. (temperature < 100 and brightness >500) or number of person > 3 or door unlocked ) and to assigns an id (i.e. idRule) useful for subscribing the rule afterwards.
The method subscribe permits a previously published rule (identi ed by idRule) to be subscribed. The occurrence of the event identi ed by idRule will be noti ed to the handler passed as a parameter to the method. 2.2
The Multi Agent component of the Rainbow architecture is made up of the following entities: Agents, Messages, the Agent Server and the Deployer. Figure 2 shows these entities and how they interact among themselves and with the Gateway.
The Agent Server is the container for the execution of agents. It o ers functionalities concerning the life cycle of the agents as well as functionalities for agents' communication. Agent servers are arranged in a peer-to-peer fashion where each agent server hosts a certain number of agents and permits them to execute and interact among themselves in a transparent way. In other words, when an agent requests the execution of a functionality, its host agent server is in charge of redirecting transparently the request to the suitable agent server. In the following are listed the main functionalities each agent server exposes:
Deployer Check Acting Set Rule
Subscribe Gateway
HANDLE_EVENT REMOAVDE_DA_RCAEQCCUQEAUIVIANEI_TNMATNAECSNSCAEGE
E SN E D_M
ES G SA
E
ADD_AGENT REMOVE_AGENT
Send acquaintance msgs Agent
Server
SEND MSG. Through this functionality, the communication between agents is performed. The Agent Server is responsible for correctly delivering messages from the sender agent to the receiver one. If the sender and the receiver do not belong to the same agent server, the message is forwarded to the suitable \peer" agent server which is, in turn, engaged nally to deliver the message.
The latter mechanism is showed in gure 3(a).
ADD AGENT. It instances an agent to an agent server. Rainbow Multi Agent system is designed to permit agents to be dynamically loaded to the agent server they have to belong to. As in SEND MSG operation, agent servers are in charge for exchanging information among themselves in order to guarantee the ADD AGENT request to be delivered to the correct agent server. This mechanism is shown in gure 3(b). The latter gure also shows how the code is dynamically loaded exploiting class repository server. More in detail, when an ADD AGENT request reaches the suitable agent server, if the agent code is not already available, the agent server automatically downloads it from a class repository.
REMOVE AGENT. It removes an instance of an agent hosted by an agent server.
This operation also exploits the \forwarding" mechanism described above.
ADD_AGENT“A”
Class Repository A
Agent Agent
Agent SEND_MESSAGE
SEND_MESSAGE forwarding
B Agent Agent Agent Agent Agent Agent
Agent Server request class
A send class
Agent Agent fAoDrwDa_rAdGinEgNT Agent
ADD_AGENT“A” Agent Server (a) SEND MSG
(b) ADD AGENT
A Message is the atomic element of communication between agents. It carries an application speci c content together with informations about the sender agent and the receiver one.
Our architecture provides for speci c kinds of message, that are the acquaintance messages. Those messages are used for establishing an acquaintance relationship among agents. The acquaintance message carries information about the location of a given agent (i.e. location of hosting agent server). The agent who receives the acquaintance message will use this information when it needs to send messages toward that destination. This kind of mechanism ensures agent behaviour to be completely independent w.r.t. the locations of agents it has to collaborate with.
For instance, let's consider that an agent is a computing node interconnected with others by means of a ring network. Each agent, therefore, can only interact with its previous agent nodes and its next one. Whenever further nodes must be connected to the ring network, only the acquaintance relationships have to be updated. In other words, a third entity can establish dynamically those acquaintance relationships without resorting to modifying, re-building or restarting any agent.
In Rainbow architecture the entity which is in charge of sending acquaintance messages in order to establish the acquaintance network is called Deployer. Deployer could be an external process as well as an agent, it can run during the con guration phase as well as during application execution. The Deployer concept will be described in details in section 2.2.
An Agent is an autonomous entity which executes its own behaviour interacting with other agents via Agent Server. In addition, each agent can interact with the physical part exploiting functionalities exposed by the Gateway (i.e. using the Virtual Object abstraction).
The functionalities of an agent are exposed to its own Agent Server and Gateway. As said before, Agent Servers are in charge of the \forwarding" mechanism that eventually ends with the calling of these functionalities, while the Gateway is in charge of notifying the events that occur in the physical part. In the following are listed the main functionalities of an agent: RECEIVE MESSAGE. It is called when there is a Message to be delivered for the agent.
HANDLE EVENT. It is called by the Gateway to notify that an event is occurred in the physical part.
ADD ACQUAINTANCE. It is called when there is an acquaintance message to be delivered to the agent. The implementation of this functionality concerns the store of the acquaintance relationship between the agent itself and the agent identi ed inside the message.
REMOVE ACQUAINTANCE. It is called for removing a previously stored acquaintance relationship.
The speci c behaviour of an Agent is realized through the implementation of RECEIVE MESSAGE and HANDLE EVENT functionalities. Dynamic Deployment and Roles The deployment of the agents as well as the con guration of the acquaintance relationships and the start-up of the application are all actions performed by the so-called Deployer. An external process or even an agent can act as a Deployer. The deployment phase is typically executed just before the application can start properly; however, it is possible to act as Deployer even during application execution in order to update the con guration dynamically for hosting new features or adapting to foreseen and unforeseen changes in the environment. Deployer can be implemented centrally or in a distributed way. Basically, who acts as a Deployer operates using the ADD AGENT functionality for deploying a new instance of an agent into an agent server, REMOVE AGENT for removing a running agent from an agent server. Furthermore, Deployer is responsible for sending acquaintance messages that eventually end with calls to ADD ACQUAINTANCE or REMOVE ACQUAINTANCE on the speci c agents. Finally, Deployer is also in charge of sending suitable \start" messages using SEND MSG in order to start the application properly.
The acquaintance relationship is formally de ned by a triplet: [A, B, R] where A and B are the agents involved in the relationship and R is a Role label. The triplet above means that agent A knows agent B and that B has the role R as acquaintance of A. During the execution, an agent exploits the Roles of its acquaintances to discriminate about how to interact with them.
As an instance, let's consider that each agent represents a physical person in a town. The relationship between two agents could have roles of neighbourhood and/or friendship. A deployer is in charge of con guring those relationships during the initial phase. In addition, as soon as a person changes home or starts a new friendship, the deployer has to re-arrange relationships dynamically among agents through sending acquaintance messages. During the execution of that system, each agent will use roles of neighbourhood and friendship to discriminate how to interact with other agents. For instance he/it can exchange information about its district with its neighbours while it invites its friends to a party. 3
In this section we introduced two examples of using the Rainbow architecture. The rst one aims to show our architecture from a practical perspective in order to understand and better gure out all the system details. The second example is useful to understand how Rainbow can host suitable swarm intelligence strategies in order to realize CPS applications owning properties such as adaptivity, fault tolerance, self-recon guration, etcetera. 3.1
In this example we show an application for monitoring and controlling a oor of a building hosting o ces. Each oor contains a certain number of room.
Figure 4(a) shows how a generic oor could be. In general, each room contains: doors, desks, chairs and adjustable brightness lights.
Each room is instrumented by some sensors and actuators listed below. Sensors: { sensors that detect the opening and closing of doors; { sensors that detect when a person enters or leaves a room; { proximity sensors detecting presence of the people in each zone of a room; { a weight sensor for each chair in order to detect if the chair is currently used. Actuators: { adjustable brightness lights for all zones of a room; { a display on each desk.
The use of the above described devices, for example, permits adjusting lights on the basis of people movements, writing informational messages on displays and so on.
controlling part in a object-oriented fashion, it is required to integrate the above described physical things with Rainbow middleware de ning the suitable Virtual Object(VO). Each VO abstracts and wraps a certain number of sensors as well as actuators. For the sake of simplicity, in this example we chose to design VOs in a human-readable fashion: virtual desk, virtual chair, virtual door and virtual wall.
The functionalities exposed by these VOs are listed in table 1, 2, 3, 4. It is worth to note that each functionality of the virtual wall is parametric: the zone parameter speci es which area of the room is referred.
Each VO is located on the same computing node where the sensors and actuators that VO encloses are connected to. A computational node can generally host VOs that may refer to more than one room. Assuming than we have only three computational nodes available to monitor and control the whole oor, we can assign rooms to nodes as in gure 4(b). Functionality Type Description lock Sensing Boolean, true if the door is closed unlock Sensing Boolean, true if the door is open entry Sensing Boolean, true when a person enter the room through the door exit Sensing Boolean, true when a person exit the room through the door Multi-agent oor application The application is designed for managing the oor and its rooms. For each room a energy-saving light-management is developed which considers people presence for suitably adjusting the brightness of the various zones of a room. This control management will also consider if the chairs are utilized or not in order to better adjust the lights. In addition, it permits a message to be displayed on a certain desk when needed. All those features are implemented in the RoomAgent. The code inside the RoomAgent is a typical object-oriented code where VOs are exploited as simple objects. The code is omitted in this paper for sake of brevity.
Besides this room-wise features, the application is also designed for addressing issues concerning the entire oor (i.e. where more than one room is involved). For instance, it could be useful to know how many people are in the oor at a given time in order to properly manage the locking of the main door of the oor as well as to shut down all the lights where the oor is empty. In this example, instead, the knowledge of the number of people is used to notify a person when he is alone in the oor writing a message on the display of his desk.
The FloorAgent is designed for addressing the above mentioned issues. Summarizing, there is a RoomAgent per room and a unique FloorAgent as it is shown in gure 4(c).
charge to load the agents upon the agent servers, to establish acquaintance relationships among them and to start the application.
In our application, each RoomAgent must be located in the computing node where the VOs of the relative room belong to.
Conversely, the FloorAgent can be located everywhere in the system (it has not connection with any physical part), even in a remote cloud node. The process made by the Deployer is summarized in gure 5.
agent in the proper location, the Deployer sends acquaintance messages to each RoomAgent in order to let them know the FloorAgent. Afterwards, each agent sends an acquaintance message to the FloorAgent in order to be known by it. This is an example of an agent that acts as Deployer. Once the deployment phase is completed, the application execution can start. When a person leaves a room, RoomAgent will be noti ed by the gateway and, consequently, will send a message carrying the number of people currently inside the room to the FloorAgent. The latter will update its people counter on receiving such a message. When it veri es that there is only one person in the oor, it will send a message to the relative RoomAgent that, in turn, will write a message on the desk display. 3.2
Many environments, such as airports, road works, factories, construction sites,
and other environments producing loud noises, require e ective noise pollution
monitoring systems. Noise pollution is a common environmental problem that
a ects people's health by increasing the risk of hypertension, ischemic heart
disease, hearing loss, and sleep disorders, which also in uence human productivity
and behavior [
Noise maps are mostly based on numerical calculations that have shown to give good estimates of long term averaged noise levels. However, such maps does not take into account the real-time variation of the noise levels.
Using the Rainbow platform we designed an agent-based, self-organizing system for the real-time construction of noise maps and identi cation of the sources of noise.
Noise sensors are spread into the environment, linked to the computational nodes, and suitably wrapped inside the VOs. Each agent is directly associated with a VO representing a noise sensor. During the deployment phase, each agent is supplied by the knowledge of its neighbours (i.e. agent associated with a spatially near sensor).
We use a simple self-organizing algorithm, proposed by [
In the following the details of the algorithm. Let si and sj be two neighbour sensor agents. Let n(si) and n(sj) the values of noise sensed by si and sj, respectively. Let us assume that a distance function D can be de ned for couples of v values. Region formation is then based on iteratively computing the value of a logical link l(si; sj ) for each and every agent of the system as in following update link procedure:
Update link: if (D(n(si); n(sj )) < T f
l(si; sj ) = min(l(si; sj ) + gelsef g l(si; sj ) = max(l(si; sj ) ; 1) ; 0)
Where: T is a threshold that determines whether the measured values are close enough for l(si; sj ) to be re-enforced or, otherwise, weakened; and is a value a ecting the reactivity of the algorithm in updating link. Based on the above algorithm, it is rather clear that if D(n(si); n(sj )) is lower than threshold T , l(si; sj ) will rapidly converge to 1. Otherwise it will move towards 0. Transitively, two nodes sh and sk are de ned in the same region if and only if there is a chain of agents such that each pair of neighbours in the chain are in the same region. From the Rainbow perspective, region information is stored adding/removing new acquaintance relationships among agents.
In order to properly map the noise pollution, it is necessary that each and
every agent within a region is locally provided with information related to the
overall status of the region. To this end, it is possible to integrate forms of
di usive gossip-based aggregation [
In this paper we introduced Rainbow, an architecture that permits an easy development of large-scale cyber-physical applications. The novelty of Rainbow is that it relies on the adoption of a distributed multi-agent layer on top of the physical part that is, in turn, wrapped in suitable Virtual Objects. Rainbow aims to hide heterogeneity, cope with complexity and real-time issues. In the future, new intelligent, adaptive and decentralized algorithms will be explored for developing large-scale cyber-physical applications using Rainbow, such as those related to smart cities, power grid, water networks and so on. Furthermore, a well-established interface for the cloud part of the architecture will be de ned.
This work has been partially supported by RES-NOVAE - \Buildings, roads, networks, new virtuous targets for the Environment and Energy" project, funded by the Italian Government (PON 04a2 E)