broad scope by introducing an automated functional design concept for BAS. Following a continuous top-down design starting at a platform-independent ...
Realizing the Automated Design of Building Automation Systems H. Dibowski, C. Oezluek, J. Ploennigs, K. Kabitzsch Institute of Applied Computer Science, Dresden University of Technology, Dresden, Germany {hd6, s1890737, jpl4, kkl0}@inf.tu-dresden.de
Abstract The future design of large and complex building automation systems (BAS) needs to be increasingly efficient. The usage of prefabricated devices and design patterns alone is insufficient to face complex demands. New automated design approaches not only need to take over recurrent tasks, they also have to integrate more direct and smoother methods into the overall design process. This paper addresses that broad scope by introducing an automated functional design concept for BAS. Following a continuous top-down design starting at a platform-independent functional level, a semiautomatic composition over different levels of abstraction towards a full-developed and industry-spanning BAS network is accomplished. Here, devices from different manufacturers are integrated into a properly operating system by incorporating formal interoperability checks. The predominant technologies of the proposed automated design approach are ontologies, generative programming and evolutionary algorithms.
I. INTRODUCTION
n the domain of building automation systems (BAS) the size and complexity of the automation systems is rising strongly, whereas at the same time the engineering costs need to be reduced. This requires new automated design approaches for a more efficient design practice and improved quality. The usage of off-the-shelf devices simplifies design nowadays and reduces it to the composition of software function blocks [1], [12]. These function blocks encapsulate their implemented functionality and offer only input and output interfaces called data points, which represent the data exchange. The system integrator connects these data points in a design tool in the form of logical connections, which thereby realizes the proposed functionality of the distributed algorithm. Besides this functional design level, the system integrator needs to define the topology and the addressing of the devices, which is named further as physical and logical design level. Another best practice method for accelerating the design process is the usage of design patterns. Whereas the overall design for an individual BAS is mostly unique and can not be found in any other building in the same way, this is different for building subdivisions like rooms, sections and floors. Here a number of recurrent design patterns primarily covering the functional design level are applied in practice I
[2], resulting in similar layouts. BAS design tools usually do not support the definition of such design patterns, but allow for reuse by copy and paste. However, the usage of off-the-shelf devices also creates new complications in design. Though the system integrator starts with a definition of the function to realize, he is not entering the functional design level in the next step. He first selects all necessary devices, because only the function blocks of purchased devices are available to him. The selection process is not easy at all, because the to be selected devices need not only to provide the purposed functionality, but also have to be interoperable [6], which means that they properly work together by definition. This implies that the system integrator first has to decompose the functionality in function blocks and create a functional design in his mind. Afterwards, he compares his concept design with available device documentation or experience to select devices and evaluate their interoperability. This is not without problems: 92% of the system integrators report regular interoperability problems and problems in device selection [21]. II. RELATED WORK This paper proposes an automated design approach for BAS to reduce these complications and accelerate the design process. It extends a straightforward functional design concept and supports common function block based building automation standards like BACnet [17], EIB/KNX [15] or LON [6]. Nevertheless, the automated design is only usable if the created design correctly implements the proposed functionality and deals with the interoperability problems. The expression of function has already been addressed for embedded systems [4] and BAS [3] via formal language specifications and ontologies, respectively. Whereas in [3], the semantics of BAS processes were defined with ontologies, this paper focuses on the semantics of components. Interoperability can be simplified or predisposed [3], thus avoiding the related problems. Stein [5] proposed the formalized definition of standardized design patterns of a group of interoperable function blocks called collaborations. Such interoperable design patterns are also templates for common plug-and-play concepts [7], [15].
251
0-7803-9701-0/06/$20.00 C 2006 IEEE
However predisposition is only feasible for a small, fixed device portfolio, and existing approaches can not resolve functional conflicts. A proper evaluation of interoperability, as shown in this paper, must therefore incorporate the semantics of the devices.
The automated design approach that is presented in this paper is based on the use of three predominant highlyaccepted technologies: ontologies, generative programming and evolutionary algorithms. Before entering the chapter about the automated design approach, an introduction to these technologies is provided and the relevant state-of-theart technology is presented in the following paragraphs.
intelligence as a subdivision of artificial intelligence, are optimization algorithms that use mechanisms inspired by biological evolution, such as reproduction, mutation, recombination, natural selection and survival of the fittest. Populations of individual, candidate solutions to the optimization problem are rated and selected according to a fitness function and then exposed to the mentioned mechanisms. This evolutionary process, which results in a new population after each iteration, is repeated until a solution is found among the population, whose fitness is sufficient. Evolutionary algorithms have successfully been applied to many different optimization problems, including the design of analog circuits [8] and hardware for embedded systems [9].
A. Ontologies Having emerged from artificial intelligence, ontologies have become a widely-accepted and used format for representing knowledge in a wide range of domains. Ontology representations convey and encapsulate both syntax and semantics of concepts and their relationships in a formal, declarative and computer-understandable way, enabling the processing and deduction of knowledge with an inference engine, also called reasoner. Beside other established ontology languages, the Web Ontology Language (OWL) [14] has evolved to one of the most predominant languages in recent years. Mature environments that support the development of OWL ontologies are available on the market, e.g. the Java-based open source solution Protege [18].
IV. AUTOMATED DESIGN APPROACH The purposed automated design approach aims at reducing the existing design problems of BAS. It uses a semi-automatic functional top-down design workflow that relieves the system integrator from breaking down the application requirements on implementing devices and evaluating the interoperability himself. This avoids the prevailing discontinuity in the design process and diminishes the overall effort. Starting from the functions defined in the requirements specification, a stepwise and automated refinement is followed over different levels of abstraction. The result is a fully developed, requirementcompliant BAS network with the necessary information on the functional, physical and logical design level, optimized according cost, functionality and reliability criteria.
III. PREDOMINANT TECHNOLOGIES
B. Generative Programming Generative Programming is a software engineering paradigm that aims to model software system families [10], which are a group of single individualized software products that share many features and modules. The difference between this and standard programming is that the final software product is created by a generator and is individualized and optimized for the user requirements. To accomplish this, the generator uses modular implementations of the requested features, which are contained in an active library. It combines them into a final product using a construction plan (ICCL - implementation component configuration language) and a feature list (DSL
domain-specific language). The high modularization makes generative programming very applicable to component or function block based systems, both on the level of component composition and the creation of composite components. In the field of building automation Ryssel et al. [11] proposed the usage of generative programming for these purposes.
Platform-independent
Manufacturer-independent
252
[DataSource
DataProcessing
DataSink
Profiles Level Platform-dependent Manufacturer-independent
Level of Components and Devices
Profile A
CopoenI
Profile B
Profile C
Component T Device Z
-
C. Evolutionary Algorithms Evolutionary algorithms, which belong to computational
Placeholder
Functional Level
Component R
Platform -dependent Man ufacturer-dependent
Device X
Component S
DeviceY
Fig. 1. Levels of abstraction of the automated top-down design approach
An overview of the overall top-down design process is shown in Fig. 1. The workflow starts at a platformindependent functional level, where the requirements for the BAS constitute the initial input. A generative programming approach transforms those needs into a first
2006 IEEE International Conference on Industrial Informatics
network of abstract placeholders, representing general platform-independent types of field and automation devices, like diverse kinds of controllers, sensors and actuators. The abstract placeholders are specified and ordered in form of an ontology, which constitutes the semantic foundation for the whole design process. In the middle layer, called the profiles level, the development is refined towards a selected platform e.g. BACnet, EIB/KNX or LON. In this level a mapping is done from the platform-independent placeholders in the ontology to platform-dependent but manufacturerindependent concepts like standard objects and profiles, which constitute a common implementation basis. The level of components and devices comprises the biggest computation effort, namely the discovery, selection and composition of appropriate platform-dependent components and devices of diverse manufacturers, resulting in the final BAS design at the logical and physical network layer. Here, evolutionary optimization algorithms are applied. The following sections detail these three levels of the automated design process.
A. Functional Level As mentioned in the previous section, the whole design approach is assembled on a common semantic base, specified in terms of an ontology. To illustrate the structure and content of such an ontology, Fig. 2 shows a small excerpt of an building automation ontology that has been developed in compliance with existing international standards [12], specified in OWL. The displayed parts of the ontology cover concepts especially needed for room automation, which can be either industry-specific (e.g. sunblind controller, heating valve) or industry-spanning (e.g. window switch, occupancy). Placeholder is the root concept i.e. the most abstract concept of the ontology and super-concept of all other concepts defined. In its direct, disjunctive sub-concepts DataSource, DataProcessing and DataSink, a first important categorization from a data flow oriented aspect is achieved. Data sources are all the placeholders that represent devices with input functions mainly like switches and detectors (binary input) or sensors and setpoints (analog input). Data sinks on the other hand stand for devices implementing output functions mainly like actuators for switching (binary output) and positioning (analog output) or operator functions for visualization purposes (binary/analog output). Devices for category data processing are all of the units that perform processing functions, also known as controllers. From a data flow oriented viewpoint, controllers are in between data sources and data sinks by receiving data from and sending data to them respectively. The data flows express the functional dependencies of
the devices and are treated in the ontology as abstract connections. Neither details about the connections like parameters nor the number and data types of the exchanged messages are of interest at this abstract functional level and will be resolved at lower levels of the automated design approach. This allows for the modelling of functional dependencies in OWL simply by using object properties, i.e. directed binary relations connecting participating concepts. Two object properties are defined, namely connectionIn for data input and its inverse connectionOut for data output. Via property and cardinality restrictions, the admissible logical connections for each concept of the ontology are specified. In the given ontology this means, for example, that instances of the concept DataProcessing can be connected on one hand via connectionIn to instances of DataSource or other DataProcessing instances (in the case of cascade). On the other hand, outgoing connections from instances of DataProcessing via the relation connectionOut are allowed to instances of either DataSink or other DataProcessing instances.
_u
Valve Windo c
DataSourceTInk a
ea
atue
Positioningt
\~~~~uiaceot:1
/
|Placeholder
g , / meatrCn
in CtX t \
SM unblindsCon
tr-o
Condensation Detector|
LgtnCoorTeng ea ture , ~~~~~~~RoomTemperatueoto X
~~~~~~SupplyAirContr;ol Switchingh
S
Fig. 2. Ontology of functional placeholders for the BAS domain
The restrictions on the concepts DataSource, DataProcessing and DataSink are inherited to all of their sub-concepts, where they are refined in the sense of a further specialization. In that way, all semantically admissible dependencies and relations are specified in an object-centered way for the concepts of the ontology. Here it should be noted that these dependencies correspond to domain knowledge that is inherent in fundamental BAS design patterns. To illustrate the utilization of specialization and to demonstrate how BAS are modeled on a functional abstract level, a small example is given in Fig. 3. Here, a room temperature control network is shown that illustrates the previously-defined concepts. The instance rtControl of the concept RoomTemperatureCiontrol, which is a sub-concept of DataProcessing (see Fig. 2), is the central unit performing all processing functions. Several input devices like window switch, room temperature sensor, setpoint and
2006 IEEE International Conference on Industrial Informatics
253
a heating valve as actuator are mandatory for proper functionality. Others might be optional like an occupancy sensor (either manual or automatic), an outdoor temperature sensor or a cooling valve. |rTemperatu re: RoomTemperatu rel
I
occupancy ManualOccupancy OR Occupancy:.
1\- - - - - - - - - - - - - - ~ ~ ~ ~ ~ - - - - - - - - - -I- - - - - -
irtSetpoint:RoomTemperatureSetpoint 0
|wSwitch:WindowSwitch
connectionOut >>
c
ale Cooling
ale
> optional Part
In
