A step towards open systems within architectures for monitoring and control of buildings
In order to disseminate the concept of intelligent building inside a wider number of industries, it is mandatory to have some common models available. This reference models support independent developments and further interoperability.
This means that products can become available independently, although having integration capabilities. As far as they comply with the reference models, their integration into the building will be done without problems.
In the current and following sections, we will focus on a set of proposals towards the adoption of open systems and open protocols (with extensive usage of web technologies), originated inside academic institutions (namely at UNINOVA, Portugal). These proposals can be seen as a first step towards the adoption of open protocols supporting full interoperability among building systems (something difficult to reach in the current state of commercially available systems).
To assure that those integration activities stay coherent, two types of reference models and associated open protocols were proposed. The first reference model is associated with the definition of a template for systems and devices interconnection (at the physical level); it is the hardware reference architecture.
The second one is related with the interconnection of process and applications all over the distributed system; it is the software reference architecture. As a complement to this reference model, the specific protocol that will be used by each of the process has to be known.
The next three sub-sections are devoted to present individually those three aspects of the system.
Hardware architecture
A two level distributed system organisation has been used as a reference to enable sub-system and device integration, from the hardware (HW) point of view. Figure 1 shows a typical example, taking one of UNINOVA’s buildings as a case study, considering three types of building systems: CCTV for surveillance, intrusion detection system, and a PABX system.
Figure 1. HW architecture for building systems interconnection
The top level is composed by monitoring workstations interconnected through a Local Area Network (LAN), namely an Ethernet based TCP-IP LAN. The bottom level is composed by dedicated control systems, interconnected by some dedicated network, typically a multi-drop serial line network, namely RS-485.
This two-level structure is well known and widely used as reference architecture adequate for distributed system monitoring and supervision. Industrial production environments are another example where this architecture is widely used and from where know-how could be integrated almost directly.
One of the interesting characteristics of this architecture is its support to incremental implementation, which means that adding new systems to the building or expand existing ones is a simple task.
Among the less interesting characteristics, one could point out some features like limited bandwidth and hierarchical accesses with their associated bottlenecks. To access the information associated with some low level device is necessary to get access to the associated monitoring workstation, which means that this architecture is strongly hierarchically organised, although allowing implementation of local control strategies at the bottom level.
Software architecture
The second reference model that has been used is related with the processes logical interconnection architecture, i.e. from a software point of view.
An open-system distributed architecture based on different process communicating is used. The paradigm of client-server programming using web technologies through TCP-sockets is extensively used.
This type of architecture enables the use of heterogeneous workstations, ranging from low-cost to high-performance workstations. The bridge to low level process associated with dedicated hardware is accomplished through the use of specific gateways and protocol converters, namely TCP-IP-network to RS-485-network.
Figure 2. Reference SW architecture showing inter-process communication
Figure 8.6 presents the reference model associated with the execution framework. Bold arrows refer to client-server connections through TCP-IP and thin arrows refer to specific links supported by “slow” serial network connections. The process associated in the first group can be installed anywhere in the reachable IP network.
The set of process presented in Figure 2 is divided into three groups, devoted to “building activity direct support”, “data collection” and “sensing and actuation”, respectively.
The building activities group is associated with the high-level control and monitoring activities.
It is roughly associated with directly interaction with the building occupant. Included in this group are user interfaces and auxiliary systems.
The first ones manage specific resources and provide information related with the different building activities. Typical examples of auxiliary systems include expert systems and other automatic control process responsible to autonomously supervise specific resources or emit diagnostics and suggestions to the users or managers.
The second group, named data collection group, is the core of the monitoring system itself and is composed by a set of servers associated with specific resources to be supervised. These servers are responsible to provide on-line information about the status of the resources under monitoring and to assure the long-term storage of the related information.
These servers could be organised into two groups. The first one groups the specific servers; they are responsible for a specific resource management. Examples of specific servers already developed include servers to manage intrusion systems, PABX and cameras (CCTV); complementary developments can address access control and energy management systems, among others.
The second type of servers is named by auxiliary servers and, currently, includes the name server. The name server is responsible to provide information related with all components of the system (devices and sub-systems), including name and associated specific server(s); it has a similar role as the domain name server in a TCP-IP network.
The last group of processes, the data acquisition and action group, is associated with the low-level control processes. These processes are responsible for data acquisition, sensing and action, and run in dedicated controllers; these processes are accessed through communication servers, responsible for protocol conversion (namely TCP-IP sockets based communication to RS-485 network).
Brief description of available services
As referred, the client-server paradigm is extensively used; whenever possible, communication should be supported by open protocols. This attitude emphasises the strong commitment towards the portability and interoperability of the developed prototypes.
In the following, a very brief description of the available services for a typical server will be produced. Among the ones already referred servers, the sensors’ server was selected, as an example of the type of interaction of a server with the other applications running in the building.
In general terms, the services can be divided into two groups: common services and specific server services. As the names denote, the first group includes similar services (hopefully) available for all servers and the second group implements the specific services associated with each server.
Examples of common services expected to be available include “Change_Password”, and “Server_Characteristics”. The first service enables the change of the password used during the connection establishment.
This password is stored in an encrypted table to improve confidentiality and is necessary to be known by a new client in order to establish a new connection. Finally, the last referred service gives a signature about the server in use.
The server could be seen as a dedicated SCADA (Supervisory, Control and Data Acquisition) system that manages programmable controllers’ networks. The sensor server has capabilities to get information about the state of the different sensors and to actuate the controller’s outputs.
The sensor server also supports two types of concepts: physical sensors and logical sensors. Physical sensors are managed directly by the low level controllers while logical sensors are obtained through data processing. As an example, logical sensors may implement alarm structures composed by several dependencies involving one sensor or a group of sensors.
Following, (some) specific server services offered by the sensor server are presented, namely:
- Read_Sensor_State
- Advice_On_Sensor
- Forget_Sensor
- Actuate_Output
- Reset_Device
- Sensor_Characteristics
The first three services are related with activities of reading sensor state. The Read_Sensor_State service provides the current state of a specific sensor and the Advice_On_Sensor (Forget_Sensor) service activates (deactivates) the monitoring cycle associated with a specific sensor. The last two referred services allow, from the client point of view, to ask for a periodic notification or for a notification whenever a change occurs on the sensor state.
The next two services (Actuate_Output and Reset_Device) offer output activation/deactivation, and the capability of returning a device to its reset state.
Regarding the last referred service, the Sensor_Characteristics service, it gives information about the sensors, namely type (for example presence detector, contact, logical sensor for alarm detection and so on) and location.