Self-Organisation for Building Automation Systems:Middleware LINC as an Integration Tool

F. Pacull1, L.-F. Ducreux1, S. Thior1, H. Moner2, D. Pusceddu3, O. Yaakoubi1

C. Guyon-Gardeux1, S. Fedor2, S. Lesecq1, M. Boubekeur2, D. Pesch3

Abstract—Building Automation usually involves alarge number of systems that should cooperate inorder to improve e.g. the user comfort, security, butalso decrease the overall energy consumption. One aimof the EU funded SCUBA project is to improve thecoordination among devices and systems installed ina building. This paper deals with the extension ofa framework dedicated to Building Automation andbuilt on top of the LINC resource-based middleware.Two particular tools developed in SCUBA and thatmake use of the middleware are also presented to-gether with the encapsulation of the ontology-basedBuilding Automation System model named BASOnt.

I. Introduction

Building Automation (BA) is a particular case ofSystem-of Systems (SoS) as it is usually made of alarge variety of systems ranging from HVAC to lighting,but also access control, intrusion alarm, fire detection,etc. [1]. One of the main objectives of BA is to control theindoor environment for user comfort and safety, buildingand goods security and energy consumption reduction.

Usually, the di↵erent systems that control the buildingwork without any cooperation/coordination, leading to alack of e�ciency as each independent control is indepen-dent. Hence, cooperation between the systems installedin a building must be improved, especially for systemswith heterogeneous and sometimes proprietary proto-cols. Another aspect of Building Automation Systems(BAS) is their intrinsic dynamicity because componentsmay ”disappear” when batteries need recharging. Oneobjective of the SCUBA EU funded project is to o↵erautomatic discovery or reconfiguration of the systemswhen devices appear or disappear so as to improve therobustness of the whole building control and monitoring.

Cooperation between BASs is easier when the devicesimplement the same communication protocol. Despitethe existence of open ones (e.g. BACnet, LonWorks),devices often adhere to di↵erent standards, leading toa complex heterogeneous network with a variety of tech-nologies [2]. A Middleware can provide an abstractionview of the underlying systems in order to cope withheterogeneity [3]. This abstraction level will ease the

1CEA, LETI-MINATEC Campus, 17 rue des Martyrs, 38000,Grenoble, France. Francois.pacull@cea.fr

2UTRC-I, Cork, Republic of Ireland. FedorS@utrc.utc.com3Cork Institute of Technology, Nimbus Centre for Embedded

Systems Research, Cork, Republic of Ireland. dpesch@cit.ie

cooperation between devices that implement di↵erenttechnologies. It will also allow the development of appli-cations that need the coordination among di↵erent BASs.One of the objectives of the SCUBA project is to extendthe capabilities of the PUTUTU dedicated framework [4]built on top of the LINC resource-based middleware inorder to address the properties required by the BA area.The paper is organised as follows. Section II sum-

marises the main concepts of the LINC middleware. Sec-tion III draws a short view of the SCUBA architecture.Then three blocks of this architecture are described,namely, the BASont, the Rescue Worker Interface andthe Coordination Scheme Editor. The middleware capa-bilities as an Integration Tool and a Coordination Toolare summarized in section IV. Specifically, the BASontencapsulation is discussed together with the main con-cepts behind the framework developed on top of LINC.Then specific drivers developed for the SCUBA demo-sites are presented.

II. Overview of Resource Based CoordinationMiddleware

The LINC middleware provides a uniform abstractionlayer over the di↵erent software and hardware compo-nents to ease their integration and coordination. This ab-straction layer relies on the associative memory paradigmimplemented here as a distributed set of bags containingresources (tuples). Following the Linda [5] approach, thebags are accessed only through three operations:

• rd() takes a partially instantiated tuple as inputparameter and returns a set of fully instantiatedtuples from the bag, where the fields match the giveninput pattern;

• put() takes a fully instantiated tuple as input pa-rameter and inserts it in the bag;

• get() takes a fully instantiated tuple as input pa-rameter, verifies if matching resources exist in thebag and consumes them in an atomic way.

A. Examples of components encapsulated as bags

A typical sensor, measuring a physical quantity canbe modelled through a Sensor bag containing tuplesformed as (sensorid, value). The measured quantity isthen retrieved with a rd() or get() operation where thetargeted sensorid is provided. To di↵erentiate sensors ca-pabilities (temperature, humidity, etc.), a Type bag canbe modelled to contain (sensorid, type) tuples. Generic

sensor data and metadata are then totally accessiblethrough rd() and get() operations.

In a similar way, actuators may be modelled with anActuator bag designed as (actuatorid, function, param-

eter1, parameter2). Then, when a resource is insertedwith a put() operation, the bag triggers the awaitedaction over the targeted actuator (respectively deducedfrom the function and actuatorid fields) adapted withthe appropriate parameters (other fields). The Type

bag introduced earlier may be used to manage actuatorscapabilities. In the software area, any remote componentor service which provides an API can be encapsulatedin a bag (or set of bags). This API may be based onSOAP, RPC, CORBA or any existing remote invoca-tion mechanism. The rd() operation is used to querythe remote component/service. The rd() input tupleis partially instantiated and provides the specific inputparameters required by the targeted remote method. Thebag performs the remote invocation and receives thecomponent response which it unpacks and instantiatesin the complementary output parameters of the thenfully instantiated tuple returned as the operation result.Alternatively, put() operations are used to invoke re-mote methods which only modify the internal state ofthe component/service, without returning any response.

The three rd(), get() and put() operations are usedwithin Production rules [6] to define how the resourcesare manipulated in the classical pattern based on pre-condition and performance phases. The rules are enactedby dedicated LINC components called coordinators.

B. Precondition phase

A precondition phase relies on a sequence of rd()

operations which detect or wait for the presence ofresources in several given bags. It can be sensed values,result of service calls or states stored in tuple spaces ordatabases. In the precondition phase:

• the output fields of a rd() operation can be used todefine input fields of subsequent rd() operations;

• a rd() is blocked until at least one resource corre-sponding to the input pattern is available.

C. Performance phase

The performance phase of a production rule combinesthe three rd(), get() and put() operations to respec-tively verify that some resources found in the precondi-tion phase are still present, consume some resources andinsert new resources in the same or other bags.

In this phase, the operations are embedded in oneor multiple distributed transactions, tested in sequence.Each transaction contains a set of operations that areperformed in an atomic manner. This ensures that ac-tions executed on devices geographically distributed,and that belong to the same transaction are either allexecuted or not. This ensures properties and behavioursthat go beyond traditional production rules, particularly:

System Model Services (BaSont)

Rescuer Worker

Interface

Fire Sensor Lightning Actuator

Temperature Sensor

Pututu framework

Strategy Manager (SM)

RFID Reader

Dev

ice

Laye

r

PIR Sensor

Tool

Lay

erM

iddl

ewar

e La

yer

Self-X Middleware(based on LINC)

Smart Plug Other Sensors & Actuators

Coordination Scheme Editor

Wireless Deployment

Planning Tool

Other ToolsOther ToolsOther

Tools

Systematic Engineering

Tool

Fig. 1: Abstract vision of the SCUBA Architecture

• LINC ensures that conditions responsible for firingthe rule (precondition) are still all valid at the timeof the performance phase completion;

• all the bags involved are e↵ectively accessible.

These properties are very important as they ensure thatall the set of required objects, bags and resources, areactually available ”at the same time”.

III. SCUBA architecture

Figure 1 presents an abstract vision of the SCUBAarchitecture. The top layer corresponds to the tool layer.Among the di↵erent tools considered in SCUBA, twoof them are presented hereafter, namely, the RescueWorker Interface (RWI) and the Coordination SchemeEditor (CSE). Both tools are used to define the waythe sensors and actuators are used either to react to anabnormal situation (RWI) or in the daily usage of thebuilding (CSE). On the bottom part of the figure, thedevice layer contains the di↵erent sensors and actuatorsdistributed over the buildings considered. This devicelayer is encapsulated by the LINC middleware in anabstraction layer that hides the complexity, the distri-bution and the heterogeneity of sensors and actuators.Indeed a framework (called PUTUTU) based on thismiddleware has been developed to ease the integrationof the various technologies considered in SCUBA. It alsoo↵ers a methodology to integrate a new technology in acouple of hours, see section IV.In the middleware layer, the Self-X block is respon-

sible for the enactment of the coordination rules andthe interaction with the abstraction layer. It allows theintegration and the coordination of the other tools. Twoother blocks can be seen: the BASont which contains thedesign templates and the Strategy Manager (SM) whichtakes decision when this cannot be done at the Self-Xlevel. The role of these components is now described.

A. System Model Services : BASont

The BASont is designed to be an ontology-based Build-ing Automation System (BAS) model that integrates therequirements and provides an open data exchange formatfor system engineering, operation and reconstruction of

Fig. 2: RWI screenshot

the BAS. It stores templates of the designs, specify-ing which devices shall be installed in each room orbuilding segment according to the system requirements.These templates are generated, updated or used by otherSCUBA tools, e.g. the SCUBA Systematic EngineeringTool and the Wireless Deployment Planning Tool [7] thatare not represented in Figure 1. Basically, the WirelessDeployment Planning Tool helps to define the preciselocation of the devices to ensure robust wireless com-munication links while the Systematic Engineering Toolspecifies which devices shall be installed in each room orbuilding segment according to system requirements. Notethat this latter tool intends to deal with scenarios wherea unique technology is deployed. However, it is sometimesrequired to define much global and complex scenariosthat involve di↵erent technologies or subsystems. This isactually possible using the Coordination Scheme Editorpresented hereafter.

B. Rescue Worker Interface (RWI)

One of the targeted applications of SCUBA system isto assist emergency wardens and rescue workers whenan emergency event (e.g. fire alarm) is detected. In thisscenario, the SCUBA system will reconfigure the buildingautomation subsystems to facilitate the evacuation of thebuilding and limit the fire spread. At the same time,rescue workers will be provided with a SCUBA-enableddevice (e.g. smartphone, tablet) running an applicationthat will assist them in their rescue tasks by providingmonitoring information and enabling control of buildingsubsystems in real time. The RWI is a mobile application(app) which interacts with the LINC middleware andimplements the following features:

• Continuous monitoring of the building subsystems.The app retrieves real time data from the deployedsensors/actuators that provide valuable informationto the rescuer (e.g. CO2 levels). This information isprojected on the interactive building floor plan, seeFig. 2. Moreover, a user can see a summary of thebuilding status on a per-floor basis to help identifyareas which require most urgent attention;

• Real-time control of the building subsystems. The appalso enables modification of the state of actuators,which gives the rescuers the ability to control the

building in order to avoid the fire spread and facil-itate the evacuation (open/locking doors, windows,switching lights on/o↵, etc.);

• Display notifications of incidents or emergencyevents. Notifications about emergency events (e.g.spread of a fire) are displayed on the app as thealarms to increase rescuers’ situational awareness;

• Historical information retrieval. The app will collecthistorical data and combine it with real-time ones toestimate and display the current occupancy distri-bution throughout the building (using access controlevents and motion sensor data) and the fire location(using fire system events, HVAC sensors and devicefailures notification);

• Mark the rooms/areas that have been evacuated.After checking that a room is evacuated, the rescueworker can not only control the building subsystemsto take the proper actions (e.g. switch o↵ the lights),but also mark the room as ”cleared”.”Evacuation”virtual actuators will trigger LINC events eachtime the status of an ”evacuation” virtual sensor ischanged. These events will be distributed to otherrescue workers evacuating the building;

• Establish location of the rescue workers and facilitatethe evacuation of the building. The location of therescuers is estimated on the basis of their interac-tion with the Access Control system. They will beequipped with an ID tag (e.g. access control card)which will be detected when a rescuer gets into prox-imity of a card reader. Moreover, rescuers will havean option to indicate their locations manually onan interactive floor map. Therefore a rescuer will beprovided with information about his own location,other rescuers’ locations, estimated location of fire,presence of people in the building and evacuatedareas. This valuable information will help him toevacuate the building in a most e�cient way.

C. Coordination Scheme Editor (CSE)

The main role of the CSE is to define scenarios in-volving di↵erent sensor/actuator technologies as they arenot easily handled by the Systematic Engineering Tool.This relies on the rule-based language of the LINC mid-dleware [4]. Basically, the user expresses his needs anddefines the behaviour of devices installed in the buildingwith these rules. They could be written manually whenthe tasks to be performed are simple, but when severaltens of sensors and actuators are handled, spread outon several rooms over several floors, software assistanceis needed. The Coordination Scheme Editor (CSE) toolo↵ers a user friendly interface that eases the definitionand the dynamic generation of complex scenarios. Notethat a scenario is a set of actions that is performed onlyif certain conditions are validated, e.g.:

1) ”In the meeting room, if the luminosity sensorreading is greater than 150lux and a presence is

detected (condition to check), then switch on thelight and adapt the lighting (action to perform)”;

2) ”For working days at 8pm, if no presence is detected(condition to check), then adjust the HVAC in”energy saving” mode, turn o↵ the lights, close theblinds and turn on the alarm (action to perform)”.

In addition, a new type of device called software deviceis introduced to ease the definition of scenarios. It canbe either a software sensor or a software actuator. Asoftware actuator is a combination of physical actuators.For example a software actuator named ”Softact”may bethe aggregation of parallel actions on shutters, light andHVAC. Given the abstraction level o↵ered by LINC, thisis done regardless of the actual technology used for eachindependent system.

Once defined, a software device is considered as theother devices and can be used either to define othersoftware devices or scenarios. The development of com-plex scenario is then very simple. Once defined throughthe graphical user interface, a scenario is automaticallytranslated into coordination rules that are executed bya dedicated component of the Self-X middleware respon-sible for the enactment and the control or a scenario.An example of such an automatically generated rule forexample 2 is given above:

[" ZigBee"," Type"].rd(id_pres, "presence") &[" ZigBee","Sensors"]. rd(id_pres, "1 ") &[" ZigBee"," Type"].rd(id_lum, "luminosity") &[" ZigBee","Sensors"]. rd(id_lum, value_lum) &ASSERT lib.lowerthan(value_lum,"150") &COMPUTE setpoint = lib.convert_lux (value_lum)::{[" ZigBee","Sensors"]. rd(id_pres, "1 ") ;[" ZigBee","Sensors"]. rd(id_lum, value_lum) ;[" Zigbee","Actuators"].put("leds_01", setpoint)}.

Note that a scenario is controlled by the presence ornot of a resource in a bag managing its enablement.

IV. LINC as an Integration Tool and aCoordination Tool

LINC o↵ers an abstraction layer in order to developof applications that require the coordination of di↵erentBASs. A framework dedicated to BA has been devel-oped on top of LIN in order to ease the integration oftechnologies and make them cooperate, including withinformation stored in a database.

A. Encapsulation of BASont

As explained above, the BASont contains all relevantinformation for installing a model of a BAS. This infor-mation can be accessed through a web-service interfacethat exposes the set of methods which o↵ers either thepossibility to get, add or set details for a given model.

In the LINC model each method exposed is associatedto a bag having the same name. Three types of bags aredistinguished, namely the bags that correspond to add-methods (adder-bags), get-methods (getter-bags) and

Fig. 3: Particular implementation of the primitives in-voked when put() is applied to the bag

set-methods (setter-bags), respectively. Each type hasa specific behaviour which will be inherited by all thebags that belong to its category. The behaviour of thebag is characterised by the special implementation of theprimitives that are invoked when a rd(), get() or put()operation coming from a rule is applied to the bag. Forexample, when a put() operation is in the performancephase of a rule the bag will receive several invocationscorresponding to the two phase commit protocol enforcedby the LINC coordination, see figure 3. Thus, the bagexecutes first the primitive preput() for the 1st phase ofthe transaction and confirm_put() or release_put()

depending on the outcome to apply to the whole trans-action according to the di↵erent replies received in the1st phase by the coordinator.In the LINC model, the implementation of the be-

haviour is open. As a consequence, in the implementationof an adder or a setter-bag behaviour, the pre_put()

method is verified if

• the BASont is accessible and the web service to beinvoked on the BASont is operational;

• the resources to be added or set are in accordancewith the specification of the bag.

If both the previous conditions are true then an ”OK”is returned otherwise an ”NOK” is returned. When theconfirm_put() method is called, the add or the setmethod of the BASont is actually done.The interesting side e↵ect of the transactional aspect

is that when a new template is added in the BASont, thisimplies to call di↵erent primitives of BASont. While donein the same transaction, either all the parts are updatedor none of them, avoiding to have an inconsistent statein the BASont that would be di�cult to discover and fix.For a get() or a rd() operation in the performance

phase of a rule, the mechanism is quite similar andnot detailed hereafter. Note that rd() operation in theprecondition phase of the rule is slightly di↵erent since ard() returns one by one the resources corresponding tothe partially instantiated resource passed as a parameter.In this case, when the first rd() is performed, the open-stream() method is invoked at the bag level in order toinitialize the stream of returned resources. The BASontis called to obtain all the possible resources that areinserted in the bag in order to keep the default behaviour

of the LINC bag. Then a read() is called within the bagreturning the 1st corresponding resource. Any subsequentrd() will trigger a call to the BASont in order to updatethe set of resources contained in the bag. The oneswhich have no longer correspondence in the BASont areremoved, the new ones being inserted. This maintains theconsistency between the BASont and its ”LINC proxy”.Moreover, it also o↵ers to the BASont a richer interactionmechanism since it can be interrogated directly fromrules and behave as an associative memory. Note that:

• the bags are automatically generated from theWSDL description given by the BASont. Thus, anyother primitive added at the BASont level can beadded at the BASont proxy with a minimal e↵ort;

• if in a first and educational implementation, 3 dif-ferent bags are considered for the setter, getter andadder aspects of a BASont primitive, but as it corre-sponds to di↵erent primitives of the bag behaviour,a single bag might be used for the 3 aspects.

B. Abstraction layer

The LINC middleware provides an abstraction layer tohide the underlying technology of sensors and actuators.as a consequence, all sensors and actuators are seen as acollection of bags providing the di↵erent aspects neededto interact with the physical devices. A framework calledPUTUTU has been developped on top of LINC [4]. Ito↵ers the encapsulation of a dozen of wired and wirelesstechnologies. Once integrated in the framework, at theapplication (e.g. scenario) level, nothing distinguishes aKNX sensor from a 433Mhz one. This means for instancethat if a scenario is referring to the sensors by their type(e.g. temperature, luminosity) the rules can be used withno modification at all to manage a newly encapsulatedsystem. Moreover, a methodology and a set of predefinedcomponents have been provided in order to ease theintegration of a new technology in a couple of days whenminimal information is known. A short description of thePUTUTU framework is now given.

1) PUTUTU framework: Firstly, PUTUTU o↵ers astandalone environment for testing a technology in isola-tion. A cookbook with a template example is provided.It helps the programmer to define a new driver fora given technology. A test module has been defined.Itmanages the connection mode to access the devicesnetwork (via IP address, USB dongle, etc.). It also pro-vides a set of methods ensuring communication and dataexchanges with the devices (initialisation, get frames,decode/encode frames, close connection, etc.). All theprimitives that are called are gathered in a library mod-ule. Once this is done, the library can be directly usedwithin a generic LINC object without any further testand becomes a new PUTUTU object ready for use. Themajor advantage of this approach is that the developerresponsible for the driver does not need to know anythingabout LINC and PUTUTU.

PUTUTU framework

Object_dongles_modules

Object_Wsan_sensors Object_Wsan_actuators

Object_Wsan_sensors_actuators

KNXPLUGWISE

Tellstick

LetibeeRFXCOM

iRIO

Homes

Watteco

TelosB

Fig. 4: PUTUTU objects and various technologies inher-iting from these objects

2) PUTUTU generic objects: Each PUTUTU objectinherits from one of the four generic objects that containcommon features and mechanisms related to sensorsand/or actuators networks. These objects are (see Fig. 4):

• the dongle modules is responsible for setting inplace the communication. This means in particularthat this object is able to scan the USB port todetect the hot plug of a dongle, to iterate theinitialization bootstrap until the connection is finallydone, to re-initialize the gateway in case of lost ofcommunication, to deal with authentication, etc. Itis based on the primitive defined the library;

• the object wsan sensors manages the featurescommon to sensor networks. In particular it definesthe bags that are mandatory for the sensors in anykind of technology. This object inherits from thedongle modules;

• the object wsan actuators manages the featurescommon to the actuator networks. It also inheritsfrom the dongle modules object;

• the object wsan sensors actuators manages fea-tures common to networks containing devicesthat have sensing and actuation capabilities. Itinherits from both object wsan sensors andobject wsan actuators. Even if double inheri-tance is possible, this object really eases the inte-gration of technologies presenting sensing/actuationcapabilities for non expert developers.

C. PUTUTU in the SCUBA project

As already said, the PUTUTU framework has beenused to make cooperate various technologies encounteredin the BA field, see Figure 4. The so-called drivers forTelosB 2.4GHz, Watteco 868MHz, LON network andiRIO network (IP SOAP protocol) technologies havebeen developed for the SCUBA project purpose. Theexperience gained for the integration of the three firstones is now reported.1) TelosB technology integration: TelosB devices

(http://www.willow.co.uk/html/telosb mote platform.html)use 6LoWPAN (IPv6 packets over IEEE 802.15.4based network) under 2.4GHz frequency band as

communication protocol. In SCUBA, four types of nodesare considered, namely:

• basic nodes with temperature (temp.), humid-ity, photosynthetic active radiation & total-solar-radiation sensors;

• basic nodes with added air velocity sensor;• basic nodes with added air velocity & water temp.

sensors;• basic nodes with added 3D air velocity sensor.

For each node type, a specific UDP destination portof the network gateway is defined to receive the corre-sponding Sensor data packets. Another UDP destinationport is defined to receive the Network statistics packets.Moreover commands such as Synchronisation packet

or Unicast packet can be sent to nodes to changetheir parameters (e.g. sampling period). To access thenetwork gateway from a PC, a tun interface has tobe created. Then datagram sockets can be created foreach UDP port used. Methods to access the gatewayand to decode/encode IPv6 and UDP packet headersas well as the data part of the IPv6 packets specificto the TelosB devices have been written. These basicfeatures have been gathered in a library associated to thistechnology. The TelosB PUTUTU object inherits fromobject wsan sensors actuators.

2) Watteco technology integration: Watteco deviceshttp://www.watteco.com/) use 6LoWPAN under 868MHZfrequency band as communication protocol.Watteco sen-sors (e.g. CO2 level, electric power consumption) or ac-tuators (smart plug) are available. The network gatewayreceives sensor data packets from Watteco devices on aunique UDP port. As for the TelosB network, the accessto the gateway from a PC is done via a tun interfaceand datagram sockets have to be created. The methodswritten for the TelosB devices can be reused to configure,decode and encode IPv6 and UDP headers. Thus theTelosB library is adapted to create the Watteco library.Only methods to decode and encode the data part ofthe packets specific to each Watteco device had to bespecially written for this library. The PUTUTU objectinherits from object wsan sensors actuators.

3) Local Operating Network (LON) integration: Lon-works Local Operating Network (LON) is a building andhome automation network. Each LON device integrates aspecific controller (called the Neuron Chip) which enablesits programming/configuration and its communicationwith other devices using the LonTalk protocol. Thislatter is a dedicated communication protocol which im-plements all the 7 layers of the ISO standard model.At the upper level, devices are viewed as nodes inte-grating function blocks which basically expose variables(e.g. network configuration, DataPoints) and exchangemessages. Functional links between variables are definedas bindings. In the SCUBA context, the devices arephysically linked together with a twisted pair, accessedthrough a USB/LON gateway.

Typically, LON networks are designed, monitored andmanaged through a dedicated MS-Windows softwarestack. This stack is based on the LonWorks Network Ser-vices (LNS) tool which provides a database to store LONdesigns and a relatively complex API to interact with thenetwork (ActiveX component). In classical commercialo↵ers, network management applications are built on topof the component and provide human-machine interfaces.In SCUBA, a software layer is built on top of thiscomponent. It aggregates LON low level concepts andit exposes more comprehensive primitives that are thenused in a LINC LON object. The PUTUTU frameworkis used to configure and initialize the connection betweenthe software and the network via the USB interface,and to provide the e�cient abstraction layer requiredto monitor variables (DataPoints) and operate actua-tors. The object is also supplemented with specific bagswhich retrieve the actual network configuration from theLNS (systems, subsystems, bindings and devices logicalhierarchical organization), enable to register/commissionpreviously unknown devices, and allow bindings retrievaland live reconfiguration.

V. Conclusion

This paper presents two tools that have been developedin the SCUBA project, namely, the Rescue Worker In-terface and the Coordination Scheme Editor. Both toolsmake use of the LINC middleware and of the PUTUTUframework that have been extended with technologiesimplemented on SCUBA prototypes. The BASont thatintegrates the requirements and provides an open dataexchange format for system engineering, operation andreconstruction of the BAS has been encapsulated so asto access its information from PUTUTU. All these toolswill be tested on the SCUBA demo sites.

Acknowledgement

This work has been partially funded by the FP7SCUBA project under grant nb 288079.

References

[1] W. Kastner, G. Neugschwandtner, S. Soucek, and H. M. New-man, “Communication systems for building automation andcontrol (invited paper),”Proceedings of the IEEE, vol. 93, no. 6,June 2005.

[2] H. Jarvinen, A. Litvinov, and P. Vuorimaa, “Integration plat-form for home and building automation systems,” in 5th IEEEWorkshop on Personalized Networks (PerNets 2011), 2011.

[3] S. Krakowiak, Middleware Architecture with Patterns andFrameworks, http://creativecommons.org/licenses/by-ncnd/3.0/, Ed., 2009.

[4] L.-F. Ducreux, C. Guyon-Gardeux, S. Lesecq, F. Pacull, andS. Thior, “Resource-based middleware in the context of hetero-geneous building automation systems,” in IECON 2012 - 38thAnnual Conference on IEEE Industrial Electronics Society,2012.

[5] N. Carriero and D. Gelernter, “Linda in context,” Commun.ACM, vol. 32, pp. 444–458, April 1989.

[6] T. A. Cooper and N. Wogrin, Rule Based Programming withOPS5. Morgan Kaufmann, July 1988.

[7] SCUBA, “Deliverable d1.1: Requirements, use cases, ar-chitecture and semantic specification,” in available fromhttp://www.aws.cit.ie/scuba/, 2012.

View publication statsView publication stats