Automated Design of Building Automation Systems - IEEE Xplore

3606

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 57, NO. 11, NOVEMBER 2010

Automated Design of Building Automation Systems Henrik Dibowski, Joern Ploennigs, Member, IEEE, and Klaus Kabitzsch, Member, IEEE

Abstract—The design of large building automation systems (BASs) with thousands of devices is a laborious task with a lot of recurrent works for identical automated rooms. The usage of prefabricated off-the-shelf devices and design patterns simplifies this task nowadays but creates new interoperability problems. As a result, the selection of devices is essential for a good system design but is often limited by a lack of information. This paper introduces a novel automatic design approach for large BASs that covers the device selection, interoperability evaluation, and composition of BASs. It follows a continuous top–down design with different levels of abstraction starting at requirement engineering and ending at a fully developed and industry-spanning BAS design. Index Terms—Building automation systems (BASs), design automation, interoperability analysis, semantic specification.

I. I NTRODUCTION

E

FFICIENT design methods are a significant precondition for the further growth of automation networks. It is not only the mere number of devices in a network that has to be handled nowadays but it is also the complexity of the device interaction. New intelligent control functions, as introduced, for example, in [1], combine multiple information sources to perform their task. This increases the design complexity for each device and the number of device variants, making it hard to select appropriate devices and leaving the interoperability as an ever-contemporary issue. To reduce the design effort, the industry uses off-the-shelf devices with preimplemented profiles. In the context of BASs and within this paper, profiles are function-block-oriented application programs with input and output data points, which can be connected with other profiles to form logical networks. They can implement standardized profiles and are hence not to be understood as profiles in the classical automation sense but as manufacturer-specific implementations of standardized profiles. Specialized design tools have been available for years. They reduce the system design to the selection of devices and their profiles, the setting of parameters, and the definition of datapoint connections. The system integrator has only a few minutes per device to accomplish this. Nevertheless, most of the engineering tasks remain recurring manual work and bear several risks, leaving the process improvable, as Section II shows. This paper introduces a novel automated design approach for building automation systems (BASs) that aim to overcome

Manuscript received December 23, 2008; revised May 28, 2009 and August 5, 2009; accepted August 20, 2009. Date of publication September 22, 2009; date of current version October 13, 2010. The authors are with the Department for Computer Science, Dresden University of Technology, 01062 Dresden, Germany (e-mail: [email protected]; [email protected]; [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TIE.2009.2032209

these problems. It summarizes the results from the German research project “AUTEG—Automated Design for Building Automation” (http://www.ga-entwurf.de), carried out by universities and companies alike. It was funded by the German Federal Ministry of Economics and Technology upon the decision of the German Parliament (Promotional Reference 16IN0405). II. R ELATED W ORK A. Design of BASs The engineering of BASs covers the process from the project planning of the system to its commissioning [2]. The configuration of devices is a part in this process and includes the following steps: 1) selecting an adequate communication technology; 2) decomposing the functional requirements to profiles; 3) selecting devices that realize the profiles and implementation of new unsupported components; 4) design of a network topology and the wiring; 5) assigning of logical addresses to devices; 6) defining the communication connections between data points of profiles (composition); 7) setting the device parameters. The steps 4) to 7) of this configuration process are usually carried out with specialized commercial software tools like LonMaker, Engineering Tool Software, ALEX, NL220, or NL Facilities [3]. These tools support an offline design without an existing network and already automate steps like the addressing. The whole design is downloaded in the network automatically by the tools during commissioning, when all devices get physically assigned their address, parameter values, and communication connections. This separation of the configuration from the commissioning process aims to reduce primarily the time spent at the building side and permits a deliberate system design beforehand. However, this classical network design has its pitfalls. Ninety-two percent of the system integrators report regular issues with interoperability and device selection. This renders the commissioning as time consuming as the configuration and often complicates both steps to an extensive trialand-error approach [4]. B. Interoperability The interoperability problem—that two devices do not work properly together—is caused already when the system integrator selects the devices in the third design step. It implies that the system integrator first decomposes the required functionality to profiles and creates a conceptual design in his mind. Design tools cannot be used for this step, because no device search functionality is supported, but profiles and devices have to be

0278-0046/$26.00 © 2010 IEEE

DIBOWSKI et al.: AUTOMATED DESIGN OF BUILDING AUTOMATION SYSTEMS

selected manually. Hence, he has to compare his design concept with the available device documentation and his experience to select appropriate devices and evaluate their interoperability. Due to the broad variety of functions and manufacturers, he can choose from thousands of devices available on the market. Finding the right ones is a challenging task, and he often ends with devices that do not work properly together, even if they are from the same manufacturer. The interoperability issue was addressed in all widespread building automation technologies like KNX, LON, and BACnet with interoperability standards. The standards cover different functional levels, starting with the specification of variable types for data points (e.g., temperature) up to the definition of standardized profiles [5]–[7]. In particular, the lower level standards (variable types and services) are accepted in the domain, while standardized profiles are often vague. The reason is that standardized profiles usually regard only the few common properties shared by all manufacturers. Each manufacturer adds his specific extensions, whose interoperability again is not guaranteed. Furthermore, the standardized profiles lack formally defined semantics. The specification is limited to a syntactical definition of the data points and a textual description of the profile function. It is not guaranteed that the same variable types are interpreted by different profile implementations in the same way. However, also the dynamic behavior of profiles has influence on their interoperability, which is also not part of the standardized profiles. As a result, interoperability standards and standardized profiles are an important step to solve the interoperability problem but can never solve it completely. C. Design Automation Other approaches addressing the interoperability problem are already taking the direction of automating the design. Stein [8] proposed the formalized definition of standardized design patterns of a group of interoperable function blocks called collaborations. Such interoperable design patterns are also used by common plug-and-play concepts for KNX and LON [9] or UPnP approaches [10], [11], where pairs of connectable devices are predefined. This simplifies the design and commissioning for closed systems using only one product line. However, it has to fail in multivendor systems, because it presumes interoperability to be standardizable. Another best practice method to accelerate the design process is the usage of design patterns. Whereas installed BASs are mostly unique, this is different for building subdivisions like rooms, sections, and floors. Here, a number of recurrent design patterns exist, which cover primarily the functional design level [12]. Most design tools support copy and paste operations to duplicate design parts easily. The next development step is a pattern library, which was first introduced by the NL Facilities tool [3]. However, the disadvantage of these libraries is known as library scaling problem [13]. With time, the number of design patterns in the library grows, as each pattern needs some modifications in the next project. This results in multiple variants of equal patterns that are difficult to distinguish. Generative programming is one approach to solve this problem [14]. It uses a generator to combine a specific software

3607

Fig. 1. Automated design workflow.

product from basic components, following generic construction plans and a domain-specific requirement definition. Generative programming can also be used for generating function-blockbased designs and adapted resource efficient device applications instead of software products, as shown in [15] and [16]. Automated design approaches were developed for different fields of computer-aided design. One of the first application fields was circuit and hardware designs for embedded systems. In this field, several approaches focus strongly on the optimization of the final circuit design using evolutionary algorithms for design synthesis [17]. More abstract approaches are used in component-based software engineering [18] and for Web services [19] using their capabilities to express and discover services. None of these approaches is directly applicable to the design of BASs. BASs neither need to be optimized on a circuit level nor do they offer semantic services that are free to connect. However, all these approaches share the same idea. It is the structural optimization of elements, may they be circuit elements, software components, services, or function blocks, according to a semantic description of the elements’ functionality and behavior. This concept is also followed in the automated design approach introduced here. III. AUTOMATED D ESIGN A PPROACH The automated design approach, which has been developed in the project AUTEG, is shown in Fig. 1. Its main characteristic is the reordering of the workflow introduced in Section II-A to

3608


a functional top–down approach [20]–[22]. It starts from the general structural information of the building. The requirements of BAS are inquired from the system integrator, together with planners or owners in a knowledge-based process. Here lies the key role for engineers in the automated design workflow. All subsequent design phases proceed automatically by applying specialized algorithms and design methods until the detailed network design is released. At first, abstract designs that define the functional schematics for each room of the BAS are created by generative programming. Abstract designs are deliberately independent of any platform or manufacturer. This permits a validation of the automation concept on the functional level and manufacturerindependent calls for tenders often demanded by governments. The transition to a certain platform with manufacturerspecific devices and profiles is done afterward in an iterative optimization process using evolutionary algorithms. Different technical platforms are supported, such as LON, KNX, or BACnet. This process requires semantic knowledge about automation devices to enable the selection of appropriate devices and profiles and their composition to consistent interoperable multivendor solutions. Therefore, semantic device descriptions are introduced, which are managed and accessed by a knowledge-based component repository. The result of the automated design is a fully developed requirement-compliant multivendor BAS design. It is detached from the manufacturer-specific product line solutions prevalent today and optimized to provide high interoperability and small hardware and installation costs regarding all existing devices on the market. All steps of the automated design approach and the semantic specification of devices and profiles are explained in the following sections. A. Extraction of Building Structure To avoid time-consuming editing, the building-structure may be extracted from existing 3-D CAD models provided by architects. With rooms and their segments, the models define the basic structure for the BAS to be designed. The Industry Foundation Classes (IFC) data model [23], [24] is used as an extraction source, which is a neutral and open specification that is supported by all major CAD tools. From a given IFC model of a building, the storeys, rooms, and facades and their arrangement are extracted, as well as additional information, such as number, size, and orientation of windows. This has influence on several design decisions like the number and dimensioning of sunblinds. B. Knowledge-Based Requirement Engineering Based on the structure and corresponding properties of a given building, the requirements for the BAS are specified in the next step. Requirements are inquired from the system integrator, together with planners or owners in a contextsensitive knowledge-based process supported by a tool. A domain-specific requirement ontology in Web Ontology Language (OWL) [25] serves as the foundation for this process. All

Fig. 2.

Building structure and templates.

requirements, either given by the system integrator directly or deduced via reasoning, are formally specified by instances of concepts from this ontology and relations between them. Ontologies emerged from artificial intelligence and have become a widely accepted and used format for knowledge representation in a wide range of domains. Ontology representations convey and encapsulate syntax and semantics of concepts and their relationships in a formal, declarative, and computer-understandable way. Aside from other established ontology languages, OWL has evolved to one of the most predominant languages in recent years. Ontologies also enable the processing and deduction of knowledge with an inference engine, also called reasoner. Therefore, the OWL requirement ontology is completed by logical rules in Semantic Web Rule Language (SWRL) [26]. The inference system can thus recommend reasonable demands, detect and resolve inconsistencies between given facts and requirements, and complete information via reasoning. To avoid repeated definitions for identical sets of rooms, requirements are grouped to templates. A template defines the requirements for a certain type of room, e.g., a two-person office room with three windows and southward orientation. The system integrator only has to define the template once and can assign it to all matching rooms. Requirements are distinguished between functional and nonfunctional requirements, as explained in the following. Functional requirements specify the functionality that should be realized by the BAS. Nonfunctional requirements, on the other hand, specify manufacturer-independent device hardware criteria such as platform, mounting form, ingress protection, supported transmission medium, or operating voltage. They serve as demands for the automatic selection of appropriate devices during the creation of detailed designs and thereby constrain the variability of the resulting BASs. Fig. 2 shows, for example, the floor plan of a seminar room that should be automated in the course of this paper. Based on the description given by the owner, the system integrator defines, for example, the following functional requirements for a seminar room: Due to the size of the room, the owner requests


3609

The transformation of the requirements is done by using generative programming (see Section II-C), which has been extended to the specific problem in AUTEG [28]. It uses a generator to combine an abstract design from abstract function blocks following a generic construction plan and the functional requirements specified in OWL before, as can be seen in Fig. 3. Each construction plan represents a number of design patterns consisting of VDI 3813 function block constellations to realize a function class (e.g., lighting). Construction plans and function blocks are stored as active elements (AEs) in an active library, which is also based on OWL and SWRL. The active library is less prone to the library scaling problem, as the AEs feature parameters that affect the specific shape of the resulting abstract designs according to the requirements. Thereby, many different function block variants can be covered by the same single AE solely by changing the parameterization. One AE, for example, defines the shape of a light control, be it either an automatic light (nondimmable; occupancy dependent), a luminance-dependent automatic light (nondimmable; occupancy and luminance dependent), or a constant light control (dimmable; occupancy and luminance dependent). Via a parameter and depending on the requirements, one of the three functions is selected together with all other required function blocks, which results in the desired function block constellation. Fig. 3.

Automatic generation of abstract designs.

two lights. For the first light, he wants an automatic light control that activates the light, depending on the occupancy state of the room. The occupancy state is to be detected by an occupancy sensor and an occupancy switch. Second, he specifies a constant light control for the second light holding a light level. In addition, the lights should also be manually operable individually by a switch or in groups by a scene panel. As nonfunctional requirements, the system integrator specifies that the system should be realized as LON network, where, for each device, the following properties should hold: The ingress protection is 20 or higher, the operating voltage is 24-V dc, and the transmission medium is a twisted pair. The light actuator and all required control devices should be mounted at the intermediate ceiling, and the scene panel and occupancy switch are to be flush mounted in the wall. Both lights are 230-V ac halogen lamps and need a corresponding light actuator. C. Automatic Generation of Abstract Designs The template-based requirements are transformed to abstract designs in the next step. Abstract designs already show a similar function-block-based structure like BAS networks at the logical layer but on a generic, platform, and vendor-independent level. The model uses the emerging German standard VDI 3813 for the generic representation of room automation systems to permit a functional centered planning phase and vendorindependent calls for tenders often demanded by governments. From the latest draft of the VDI 3813 comes the representation used for the abstract design in Figs. 1 and 3. The standard is intended to be integrated in the International Standards Organization 16484-4 [27].

D. Semantic Device Descriptions and Component Repository Additional information about devices and specific semantic knowledge about the profiles realized on them is required for the automatic transition from abstract designs to detailed designs (see next section). This includes knowledge about the specific functions implemented by each profile (e.g., constant light, automatic light, and occupancy control), how profiles should be parameterized, what purpose their input and output data points has (more precisely than standardized variable types allow for), and how they can be connected appropriately. System integrators can get information about those facts by reading the device manuals that manufacturers provide. However, device manuals are in natural language, which is not easily interpretable for computers. The electronic device descriptions used by the established design tools, on the other hand, are machine readable but lack the required semantic information as they list only the device interfaces (profiles, data points, and configuration parameters). Hence, the existing resources are not sufficient for an automated design. Therefore, a new semantic description of devices and profiles of BASs has been developed in the AUTEG project [29]. It takes advantage of OWL ontologies to enable a formal specification of the mentioned knowledge in computer-understandable form. Another benefit of OWL is that it natively supports the serialization from and to Extensible Markup Language (XML). A BAS device and its profiles can thus be easily specified file based and open readable in XML. As a valuable feature, the device descriptions ideally should be created and supplied by the device manufacturers. Each BAS device and its profiles are characterized in the ontology by hardware-specific nonfunctional properties and

3610


between data points and to analyze the interoperability between profiles. Semantic types are also predefined in the ontology in a hierarchy and assigned to data points. The OWL-based semantic device descriptions are accumulated in the component repository, which constitutes a knowledge-based database based on semantic Web technologies. It allows among others for queries of suitable devices and profiles according to all specified properties. SPARQL [30] as a graph-based query language is applied here. Furthermore, the knowledge-based format of the semantic device descriptions allows for reasoning with an inference system to evaluate interoperability between profiles, as well as the correctness and completeness of the entire detailed designs [29]. SWRL [26] as a rule language and Jess [31] as an inference system are used for it. E. Creating Optimized Detailed Designs

Fig. 4. Semantic specification of a LON profile.

software-specific functional properties. Nonfunctional properties, on one hand, characterize device hardware criteria such as mounting form, ingress protection, supported transmission medium, or operating voltage. They are expressed with the same OWL properties as the nonfunctional requirements from the requirement engineering step (see Section III-B) and are used for selecting appropriate devices. Software-specific functional properties, on the other hand, define the semantics of profiles. The specification of a LON light controller at a specific operation mode is shown in Fig. 4 as an example. The syntactical definition of profile interfaces is typically already contained in an electronic device description called XIF-File. This is extended by a profile semantic layer that defines among others that the profile realizes the constant light control function. All functions are predefined as concepts in OWL. The functions can be refined by function-specific attributes, which are realized as OWL properties. As the same OWL concepts and properties are used in requirement engineering and abstract design, requirements can be mapped directly to function blocks and functional compliant profiles during the evolutionary optimization. The example profile in Fig. 4 is quite advanced and supports multiple functions like automatic light, luminance-dependent automatic light, and constant light. It therefore distinguishes different operation modes set by the configuration parameter cpClCtrlMode. This change of the functional behavior needs to be expressed in the semantic model, which therefore allows defining different semantic operation modes for one profile conditioned by parameters. As a result, the device is automatically parameterized to cpClCtrlMode = 0 to realize the required function constant light control during commissioning. Semantic types are required to give a precise meaning to input and output data points, far beyond standardized variable types. They are used to create semantically correct connections

With ontology-based semantic information, it is now possible to transform abstract designs to detailed designs of a specific BAS platform as it defines a mapping from requirements and abstract function blocks to profiles and devices. Nevertheless, it poses a challenge due to the variety of profiles and devices implementing the same functions, particularly if all market available devices should be regarded. It is an even greater challenge that the interoperability between selected devices should be ensured. The abstract designs from the previous design step define the fundamental logical network structure. Each abstract function block now needs to be replaced by an appropriate manufacturerspecific profile of a specific device and platform, and all necessary connections (bindings) between data points need to be created. Possible candidates can be determined with SPARQL by querying the component repository for profiles that implement the functions provided by the abstract design and that run on devices compliant with the given nonfunctional requirements. It is an N -to-one mapping, which means that one or even more abstract function blocks can be replaced by one profile. This complicates the design process since the structure changes and more variants are possible than in a strict one-toone mapping. As several profiles can run on the same device, another N -to-one mapping occurs. The complexity of the transformation task can be very high. Consider the simplistic assumption for the quite basic abstract design in Fig. 3, in which, for each of the 13 function blocks, ten device candidates exist on the market. Then, 1013 different device combinations would exist for this example only for the strict one-to-one mapping. It is clear that a system integrator would never be able to consider even a fraction of these combinations with conventional approaches. He would select what seems to him the best choice for each function block and test them to evaluate their interoperability. This way, he probably iterates to a working solution, but it is a laborious and troublesome approach as surveys confirm [4]. Moreover, as the solution found is only one from the multitude of options, it probably will be suboptimal. The computational power of modern computers, however, can handle this complexity easier. Still, the numerical example


given previously is too large to evaluate all combinations in a reasonable time. Combinational optimization algorithms cope with that, like evolutionary algorithms (Section II-C) from the computational intelligence field of artificial intelligence. Their benefit is that they combine strategic development with experimental randomness. They develop different solutions (individuals) in parallel using mechanisms inspired by biological evolution, such as selection, which means that, from each population of individuals, survivors are selected by a fitness function to create the next generation. As in nature, the fittest individuals have the best chance to survive and to produce descendants, which are then exposed to mechanisms such as recombination (combining the properties of two individuals to a new third) and mutation (random change of properties). This sequence of selection, recombination, and mutation is repeated over several generations, leading to more and more optimized solutions. While the basic idea of evolutionary algorithms sounds quite simple, their power depends much on using adequate selection, mutation, and recombination operators for the problem considered. Thus, special operators were developed, which resemble the basic approach that a system integrator takes. For the initial population, suitable profile and device candidate sets are queried from the component repository for each abstract function block. Then, profiles and devices are randomly chosen from the candidate sets to create the initial population. Mutation operations alter individual designs in each generation by replacing profiles by other suitable profiles, including the corresponding devices among the set of all candidates. Recombination, on the other hand, exchanges profiles between two individual designs to create a new individual. By iteratively applying the operations, more and more optimized detailed designs evolve from generation to generation. Please refer to [32] and [33] for more details about the operations and algorithm implementation. In each step, the interoperability between the selected profiles is evaluated using the component repository, and possible bindings are created. It is estimated—via reasoning over the semantic device descriptions—whether data points of two profiles can be connected. A range of different hardware- and softwarespecific criteria is considered in the pairwise interoperability evaluation. The criteria are organized in levels that build upon each other to allow a bottom–up check beginning with the lowest level “Compatible.” Only if all levels are fulfilled, interoperability can be deduced. The levels are as follows. 1) Compatible and Interconnectable. The devices need to support the same platform, transmission protocol, transmission medium, transmission rate, and topology to share the same bus. 2) Interworkable. In addition, the profile and variable types of the data points to be connected are syntactically compatible. 3) Interoperable. Last, the operation modes, functions, and resulting semantic types from the profile semantic layer are evaluated (Fig. 4). An input–output data point pair and, consequently, the two profiles are semantically interoperable at a given operation mode, if all required

3611

semantic types of the output data point are matched by the corresponding input data point. The semantically interoperable data point pairs then constitute the necessary bindings. The evolutionary algorithm performs a multiobjective optimization, meaning that several optimization criteria are regarded in parallel. The most important optimization criteria are as follows. 1) Compliance: the degree of compliance of the detailed design with the given requirements and abstract design. Full compliance requires all functions to be implemented and arranged accordingly. 2) Interoperability: the fraction of interoperable bindings among all bindings. All bindings are required to be interoperable for a full interoperability. 3) Cost: the hardware and installation cost as the sum of the individual cost of devices and their expected installation expense. The cost is to be minimized. All optimization criteria are estimated for each individual design of a population, and a separate normalized numerical value in the interval from zero to one is computed for each criterion. The individuals are compared to each other and ranked with a Pareto dominance relationship with regard to all optimization criteria (multiobjective optimization). It is defined that an individual dominates another individual, if it is not worse in any optimization criterion and better in at least one criterion than the other. Two individuals are not dominated by each other, if no one dominates the other. By crosswise comparing the individuals with the Pareto dominance relationship, a set of nondominated individuals can be selected. Those individuals are the best among the population and receive the highest probability for surviving in the selection phase. For the rest of the population, again, the set of nondominated individuals is estimated. Individuals of this set receive the second best probability for surviving. The selection is repeated again and again, until the whole population is separated in sets of nondominated individuals. Within a set of nondominated individuals, a weighted normalized sum of all optimization criteria can be used to compute an internal ranking position for each individual. The optimization is stopped when one or multiple solutions are found among the population, whose fitness meets the requirements, and when no more improvement is possible or a predefined timer expires. Several alternative, optimized, and platform-specific detailed designs constitute the output of the algorithm. Each solution consists of a list of specific devices along with their general installation location (rooms), their selected profiles, bindings between the data points, and fundamental parameterizations. The alternatives are presented to the system integrator, who can browse the results and choose a favored solution. The topology and addressing are designed in a very direct way. All interconnectable devices are assigned to one channel for each floor, which are then connected to a backbone via routers or gateways. If the limit of devices per channel or subnet is reached, a repeater is placed or a new subnet is defined. However, this algorithm does not consider the limited line length

3612


of cables or the physical building layout. The algorithm tries more to create a structured topology that a system integrator can easily understand and change. Here, the quality of the designs in terms of network performance is evaluated with specialized tools [34], and unobserved design faults like an overloaded channel in the topology design are detected and can easily be changed. In the case of LON designs, the complete design is stored in an LNS database, which is accessible by all LON design tools (LonMaker, ALEX, NL220, etc.). Thus, a system integrator can use his favorite design tool to adjust the design to his specific needs. These design tools take over also the commissioning of the network where the logical designs are uploaded to the installed devices. IV. I MPLEMENTATION AND R ESULTS The presented approach and all its algorithms have been implemented in Java, including the requirement engineering tool, abstract design generator, component repository, and evolutionary algorithms. The manifold tests of the implementations with different examples have shown that the automated design is feasible and results in qualified designs. Whereas the requirement evaluation and the abstract design generation promptly deliver results, the generation of detailed designs is computationally intensive and requires the largest computation time. For example, the evolutionary optimization of the abstract design from Fig. 3 takes 227 s to find the optimal solution with a 3-GHz standard desktop PC, given a total of 86 appropriate devices for the 13 function blocks. This results in 4.5 billion device combinations for a strict one-to-one mapping and even a multiple of it for an N -to-one mapping. The best solution in this case consists of three devices and 12 profiles and is found after an average of 12 generations. Tests with larger abstract designs with up to 25 function blocks and more device candidates succeeded within a mean time of 11 min [32], which is reckoned as acceptable for practical usage. Although the computation time further increases with a growing number of function blocks and device candidates, it is expected that the automatic design approach is still applicable and delivers good results after a computation time of at most several hours. We can substantiate this with three reasons: First of all, abstract designs will not grow ad infinitum, rather they are limited since they are defined for rooms and the number of functions per single room will be limited. Second, a large number of device candidates can always be reduced by defining specific requirements for devices, such as a certain ingress protection, mounting form, operating voltage, or even manufacturer(s). Finally, powerful computers with multicore processors and a parallelization of the evolutionary algorithm provide much room for improvement, which have not been exploited so far. V. C ONCLUSION The presented design approach has realized the automated design of multivendor BASs. Based on formal requirements

gathered in knowledge-based requirement elicitation, abstract designs are generated according to generic design patterns. The introduction of semantic device descriptions and component repository introduces a unified specification of all devices and profiles and affords their retrieval and interoperability analysis. Interoperability is analyzed via reasoning, and bindings are defined automatically. This establishes a shift toward a new paradigm, where it is no longer necessary to unify all devices to be interoperable. Now, it will be entirely sufficient, if, among the large pool of available devices, at least a few devices can be found to be interoperable to each other. Ontologies have played the central role in the whole automated design workflow. They are used as common vocabulary and semantic specification format for the requirement engineering, abstract design, and component repository. By using the same ontology concepts and properties, functional and nonfunctional requirements can be mapped to function blocks and further to devices and profiles, which constitutes an essential prerequisite for the refinement of abstract designs to detailed designs. The refinement is done in a multiobjective optimization performed by an evolutionary algorithm. It delivers optimized solutions by considering multiple criteria like compliance, interoperability, and costs. The definition and maintenance of the ontologies, however, require much work to be done, particularly in the beginning. Requirements, function blocks, abstract design patterns, and the semantic device description vocabulary should be extended concisely and cooperatively by a community of domain experts. A consensus on a set of commonly used ontologies must be reached here. Furthermore, a sufficient number of manufacturers should provide semantic device descriptions for their devices. Otherwise, the evolutionary optimization could result in incomplete detailed designs due to the absence of adequate and interoperable devices. Consequently, the practical applicability of the design approach depends much on the willingness and participation of experts and manufacturers. To simplify the specification task, future work will cover learning approaches from existing knowledge, simplified specification tools, and the creation of an Internet-based component repository that is open and accessible to vendors. The approach will also be extended to design wireless building automation networks based on ZigBee or EnOcean [35], together with the placement of the devices considering radio propagation. R EFERENCES [1] G. Pratl, D. Dietrich, G. P. Hancke, and W. T. Penzhorn, “A new model for autonomous, networked control systems,” IEEE Trans. Ind. Informat., vol. 3, no. 1, pp. 21–32, Feb. 2007. [2] ISO 16484-1—Building Automation and Control Systems (BACS)— Part 1: Definitions, draft. [3] Newron-Sytem, “NLSuite,” 2006. [Online]. Available: http:// www.newron-system.com/ [4] J. Naake, S. Theiss, V. Vasyutynskyy, and K. Kabitzsch, “Untersuchung zum Fernzugriff auf Automatisierungstechnik,” atp - Automatisierungstechnische Praxis, vol. 48, no. 7, pp. 32–37, Jul. 2006. [5] W. Kastner, G. Neugschwandtner, S. Soucek, and H. M. Newman, “Communication systems for building automation and control,” Proc. IEEE, vol. 93, no. 6, pp. 1178–1203, Jun. 2005. [6] J. P. Thomesse, “Fieldbuses and interoperability,” Control Eng. Pract., vol. 7, no. 1, pp. 81–94, Jan. 1999.


[7] D. Dietrich, D. Loy, and H.-J. Schweinzer, Open Control Networks. Boston, MA: Kluwer, 2001. [8] G. Stein, “Composite ports for an architecture-oriented assembling of components,” in Proc. IEEE Int. Workshop Factory Commun. Syst., 2004, pp. 119–124. [9] G. Neugschwandtner, “Towards plug and play in home and building automation networks,” in Proc. IEEE Int. Conf. Emerging Technol. Factory Autom., Sep. 2006, pp. 461–464. [10] S. Knauth, R. Kistler, D. Kaslin, and A. Klapproth, “SARBAU towards highly self-configuring IP-fieldbus based building automation networks,” in Proc. Int. Conf. Adv. Inf. Netw. Appl., Mar. 2008, pp. 713–717. [11] B. A. Miller, T. Nixon, C. Tai, and M. D. Wood, “Home networking with Universal Plug and Play,” IEEE Commun. Mag., vol. 39, no. 12, pp. 104– 109, Dec. 2001. [12] M. Schutze, J. P. Riegel, and G. Zimmermann, “PSiGene—A patternbased component generator for building simulation,” Theory Pract. Object Syst., vol. 5, no. 2, pp. 83–95, 1999. [13] T. J. Biggerstaff, “The library scaling problem and the limits of concrete component reuse,” in Proc. IEEE Int. Conf. Softw. Reuse, 1994, pp. 102–109. [14] K. Czarnecki and U. W. Eisenecker, Generative Programming: Methods, Tools and Applications. Reading, MA: Addison-Wesley, 2000. [15] U. Ryssel, J. Ploennigs, and K. Kabitzsch, “Generative function block design and composition,” in Proc. IEEE Int. Workshop Factory Commun. Syst., 2006, pp. 253–262. [16] A. Metzger, “Feature interactions in embedded control systems,” Comput. Netw., vol. 45, no. 5, pp. 625–644, Aug. 2004. [17] J. R. Koza, F. H. Bennett, III, D. Andre, M. A. Keane, and F. Dunlap, “Automated synthesis of analog electrical circuits by means of genetic programming,” IEEE Trans. Evol. Comput., vol. 1, no. 2, pp. 109–128, Jul. 1997. [18] I. Crnkovic, H. W. Schmidt, J. Stafford, and K. Wallnau, “Automated component-based software engineering,” J. Syst. Softw.—Special Issue, vol. 74, no. 1, pp. 1–3, Jan. 2005. [19] N. Milanovic and M. Malek, “Current solutions for Web service composition,” IEEE Internet Comput., vol. 8, no. 6, pp. 51–59, Nov./Dec. 2004. [20] H. Dibowski, C. Oezluek, J. Ploennigs, and K. Kabitzsch, “Realizing the automated design of building automation systems,” in Proc. IEEE Int. Conf. Ind. Informat., Aug. 2006, pp. 251–256. [21] S. Runde, H. Dibowski, A. Fay, and K. Kabitzsch, “Integrated automated design approach for building automation systems,” in Proc. IEEE Int. Conf. Emerging Technol. Factory Autom., Sep. 2008, pp. 1488–1495. [22] H. Dibowski and K. Kabitzsch, “Automated design of LON based building automation systems,” LonMark Mag. Int., vol. 5, no. 1, pp. 28–31, Jan. 2009. [23] Industry Foundation Classes, Release 2x, Platform Specification (IFC2x Platform), ISO/PAS 16739, 2005. [24] A. Karavan, M. Neugebauer, and K. Kabitzsch, “Merging building automation network design and IFC 2x construction projects,” in Proc. Conf. Inf. Technol. Constr., Dresden, Germany, Jun. 2005, pp. 575–581. [25] World Wide Web Consortium (W3C), “OWL Web Ontology Language Reference,” W3C Recommendation, Feb. 2004. [Online]. Available: http://www.w3.org/TR/owl-ref/ [26] I. Horrocks, P. F. Patel-Schneier, H. Boley, S. Tabet, B. Grosof, and M. Dean, “SWRL: A Semantic Web Rule Language Combining OWL and RuleML,” W3C Member Submission, May 2004. [Online]. Available: http://www.w3.org/Submission/SWRL/ [27] ISO 16484-4—Building Automation and Control Systems (BACS)— Part 4: Applications, draft. [28] U. Ryssel, H. Dibowski, and K. Kabitzsch, “Generation of function block based designs using semantic Web technologies,” in Proc. IEEE Int. Conf. Emerging Technol. Factory Autom., Sep. 2009, pp. 698–705. [29] H. Dibowski and K. Kabitzsch, “Semantic device descriptions based on standard semantic Web technologies,” in Proc. IEEE Int. Workshop Factory Commun. Syst., May 2008, pp. 395–404. [30] World Wide Web Consortium (W3C), “SPARQL Query Language for RDF,” W3C Recommendation, Jan. 2008. [Online]. Available: http:// www.w3.org/TR/rdf-sparql-query/ [31] Sandia National Laboratories, Jess Rule Engine for the Java Platform. [Online]. Available: http://herzberg.ca.sandia.gov/ [32] C. Oezluek, H. Dibowski, and K. Kabitzsch, “Automated design of room automation systems by using an evolutionary optimization method,” in Proc. IEEE Int. Conf. Emerging Technol. Factory Autom., Sep. 2009, pp. 766–773. [33] C. Oezluek, U. Ryssel, and K. Kabitzsch, “Multi-objective combinatorial optimization for designing room automation systems by using evolution-

3613

ary algorithms,” in Proc. Annu. Conf. IEEE Ind. Electron. Soc., Nov. 2009, pp. 3335–3340. [34] J. Ploennigs, M. Neugebauer, and K. Kabitzsch, “Diagnosis and consulting for control network performance engineering of CSMA-based networks,” IEEE Trans. Ind. Informat., vol. 4, no. 2, pp. 71–79, May 2008. [35] C. Reinisch, W. Kastner, G. Neugschwandtner, and W. Granzer, “Wireless technologies in home and building automation,” in Proc. IEEE Int. Conf. Ind. Informat., Jul. 2007, vol. 1, pp. 93–98.

Henrik Dibowski received the Diploma in computer science from the Dresden University of Technology, Dresden, Germany, in 2005. Since 2005, he has been a Research Assistant of the Chair for Technical Information Systems with the Dresden University of Technology, working in the area of automated design methods for building automation systems, semantic specification of automation devices and profiles, and automatic interoperability analysis.

Joern Ploennigs (M’06) received the Diploma in electrical engineering for automation and control and the Ph.D. degree from the Dresden University of Technology, Dresden, Germany, in 2001 and 2007, respectively. Since 2002, he has been a Research Assistant of the Chair for Technical Information Systems with the Dresden University of Technology, working in the area of network performance engineering, fault analysis, and component-based design for building automation networks, and wireless sensor networks.

Klaus Kabitzsch (M’05) received the Diploma and the Ph.D. degree in electrical engineering and communications technology from the Ilmenau University of Technology, Ilmenau, Germany, in 1982. He has been a Professor and the Head of the Chair for Technical Information Systems with the Department of Computer Science, Dresden University of Technology, Dresden, Germany, since 1993. His current projects focus on wireless networks and their application in the automation domain, componentbased software design, performance engineering, and design for networked building automation. Dr. Kabitzsch is a member or the Chair of various national and international organizations. He founded the Fieldbus Competence Center in 1995 in Dresden and the SAP Ubiquitous Computing Laboratory in 2004.