A private look at the integration of automated systems.

When analyzing technical specifications and initial data for the design of automated systems (AS) for managing and monitoring buildings and structures, one often encounters the task of integrating certain systems into a common automation platform.

Any objects — cottages, office centers, factories, production facilities (except for technological processes), buildings, housing and communal services facilities and others — pose a number of tasks for the designer regarding equipping the AS, which can be divided into three groups:

1. Life support systems of buildings and structures:
– supply and exhaust ventilation;
– central air conditioning;
– cooling towers, boiler houses, central heating points;
– water and heat supply;
– refrigeration;
– pumping and drainage stations;
– general power supply;
– internal and external lighting;
– sewerage.

2. Systems for power supply and metering of electricity, heat or energy consumption (gas, water, steam and others).

3. «Low-current» systems:
– fire protection (FP), these systems are often referred to as the first group;
– security alarm (SA);
– access control and management (ACM) and parking (SP);
– television surveillance (TSN);
– notification (SO);
– radiofication (SR) and clock fication (SC);
– collective television reception (SKPT);
– telephone installation (STLF), it can also be partially attributed to the first group.

Each of these three groups has its own automation platform, which includes three levels:
– field (sensors, analyzers, counters, flow meters and others);
– controller;
– SCADA level – automated workstation (AWP).

Controller levelhas its own application software and is designed for the primary collection and processing of information coming from the field level. One of the important and, as a rule, complex tasks is the collection of information via interface communication lines. The fact is that at the stage of equipment selection when designing the AS of buildings and structures, some developers proceed from political and administrative considerations. This leads to the fact that local control systems have various communication interfaces and closed data exchange protocols. When solving the issues of integrating these systems into an automated dispatch control system (ASDU), it can be difficult, and in some cases impossible, to collect and process data from these systems. That is why the use of open protocols is currently one of the most important tasks. In practice, unfortunately, when implementing ASDU, it is necessary to use various methods of converting and linking protocols into a single exchange protocol, using expensive equipment, which ultimately leads to an increase in the cost of the project.

The picture is similar at the SCADA level. Some integrator companies offer their automation products, from sensors to automated workplaces. These are usually closed systems. The RTSoft company uses the Citect SCADA system in its projects at the top level. It has dozens of drivers for various devices, and its openness allows for free expansion of the system without spending additional resources.

The second group of AS is integrated on a single platform of automated systems for dispatching control of energy resources (ASDU E). This approach is applicable for large enterprises. ASDU E, in addition to displaying technical parameters and the operation of various transformer substations, can perform switching functions both according to scenarios and for consumption control.

The functions of the ASDU E include recording the consumption of thermal energy and the consumption of various energy sources. For small objects, this system is fully integrated into the ASDU.

The third group of AS is quite specific in terms of integration. All these systems have their own set of software and hardware. Often, the technical specifications for the design of AS require full integration of these systems into the ASDU. I believe that these requirements are not appropriate.

Why?
Firstly, each «low-current» system is functionally complete.
Secondly, it belongs to the relevant services of the enterprise in terms of responsibility.
Thirdly, it has its own specific closed protocols, and this is quite logical from a technical and administrative point of view.

What is the threat of the requirements for full integration of systems into the ASDU?
– The need to «hack» closed protocols or use appropriate conversion devices, which will entail an increase in the cost of the project.
– Reducing the level of responsibility of the relevant services.
– Reducing the acuity of information perception and the degree of operator reaction due to the redundancy of information on the automated workstation.

Now let's talk about the degree and depth of integration of «low-current» systems.
Fire protection includes the following subsystems:
– fire alarm (SPS);
– fire extinguishing (SPT): sprinkler, gas or powder;
– smoke protection and fire protection (SPDZ and OZ);
– air pressure in stairwells (APS).

All these subsystems, together with the notification system, are fully integrated on a separate three-level platform with its own software and hardware level.

The integration of the fire protection system into the ASDU is carried out by one «dry» contact of the generalized command «Fire». Upon this command, the corresponding scenario (algorithm) is processed in the ASDU, for example, switching off the supply and exhaust ventilation, switching on the SPV, switching off the elevators (transferring the elevators to the first floor).

In the same way, one «dry» contact is used to integrate the fire protection system into the television surveillance system and the ACS. Upon the command «Fire», each of these systems processes its own scenario. For example, the STN displays an image from a video camera located in the fire or evacuation zone on the monitor, the ACS unblocks the evacuation exits and doors along the evacuation route.

The access control and management system can be integrated into the ASDU; in this case, the system will receive information about the number of people in a particular room in order to implement the climate control algorithm. And when integrating the security alarm system into the ASDU, information about the presence of people in the room will be transmitted to implement light control scenarios.

These are some examples of integrating «low-current» systems into the ASDU. In any case, the degree and depth of integration of these systems should be based on technical feasibility. The integration of the AS should expand the capabilities of the systems included in it and in no way interfere with the performance of the functions of each group of systems with unnecessary and redundant information.

To summarize the above, we can conclude that the implementation of any technical solutions must be feasible. This applies not only to technical aspects, but also to some extent to administrative and economic ones. The company «RTSoft» is fully prepared to implement such tasks.

ZAO «RTSoft»