Integrated Automated Design Approach for Building ...

Integrated Automated Design Approach for Building Automation Systems Stefan Runde1, Henrik Dibowski2, Alexander Fay1, Klaus Kabitzsch2 Helmut Schmidt University Hamburg Department of Mechanical Engineering Institute for Automation [email protected] [email protected]

Dresden University of Technology Department of Computer Science Institute for Applied Computer Science [email protected] [email protected]

Abstract

these overall costs. Thus, it suggests itself to reduce engineering costs. Automated mechanisms in the engineering workflow save engineering costs [2] [3]. Especially automated design processes offer a huge optimization potential [1]. The research project “AUTEG” (Automated Design for Building Automation) [4] focuses on this topic. Section 2 describes the problems in the state-of-theart design of BAS. Consecutively, Section 3 describes the new automated design approach. The last section summarizes the automated design approach.

The planning and design of building automation systems is a time consuming, error prone and nowadays more and more expensive task, consisting of a lot of repeated manual design steps done by specialized engineers. To reduce the engineering costs for such systems, the authors present a new automated top-down design approach within this paper. A knowledge-based system supports the planner at the requirement analysis by means of a guided dialog. Subsequently, the complete automation system is automatically designed in two steps. The abstract design proceeds a design based on platform- and manufacturer-independent function blocks via generative programming. The detailed design replaces the function blocks by platform- and manufacturerspecific profiles by means of evolutionary techniques.

2. Design of building automation systems – the state-of-the-art 2.1. Engineering Workflow The intention of the engineering process is to design an optimized BAS in terms of functionality and engineering costs. The planning workflow in building automation can be distributed into the phases Requirement-Analysis, Planning-Stage and Implementation-Planning as shown in Figure 1. In the following, the content of the workings in these several phases are outlined:

1. Introduction Typically, decentralized automation systems with intelligent components (e.g. sensors, actuators, and controllers) are prevalent in modern building automation. These intelligent components will continually gain in importance [1]. Such modern building automation systems (BAS) bring along several advantages like high comfort by e.g. intelligent lighting and sunblind functions or room temperature functions. Moreover, the high degree of linking of BAS allows information interchange between the several subdomains (henceforth named Assembly Section, AS) e.g. heating, ventilation, air-conditioning (HVAC), lighting and shading (room automation). Therefore, it is possible to design such comfort functions also under the consideration of saving energy costs. Particularly, the last mentioned topic is an important matter in times of increasing energy costs. Decreasing overall project costs will push the prevalence of BAS. Engineering costs of BAS make up for a major part of

1-4244-1506-3/08/$25.00 ©2008 IEEE

Figure 1. Engineering workflow today •

•

1488

Requirement-Analysis: The intention of this phase is to gather all relevant requirements for the BAS, which is to be planned. The requirements are gathered in a device-oriented way by the planner in order to realize funtions required by e.g. the building owner. As a result, nonformalized, non-uniformed room books are issued. Planning-Stage: In the planning-stage, the requirements will be processed, and a control

•

between building automation components still is an unsolved problem. The above-mentioned points impose challenges for the application engineer, who has to search for and to compose the correct components under consideration of the standards and interoperability at the implementation planning phase. Therefore, application engineers tend to stick to their previous solutions of BAS. These previous solutions are often based on the choice of only few manufacturers and a low degree of functionality, because it is impossible for the planner to cope with all the functionalities and different types of components of several manufacturers. Thus, the BAS is often not optimal with regard to both functionality and costs. Furthermore, the current device-oriented bottom-up design leads to non- realizable requirements, which are required by e.g. the building owner. The following section describes the fundamental tasks of the automated design approach within the AUTEG project [4], which addresses the described problems and develops intelligent solutions.

structure will be designed. The results are presented in e.g. control schematics, function lists [5]. Typically, both these engineering phases are to be done by consulting engineers, independently of manufacturer specific components. Implementation-Planning: In this phase, concrete components from specific manufacturers are selected. The selected components will be listed in text-documents. In contrast to both previously mentioned phases, this engineering phase distinguishes between the different AS.

Furthermore, a multitude of different planners and working groups is involved in the different phases of the workflow. Depending on the particular AS, on the current planning phase and on the assigned organizational unit, engineers use Computer Aided Engineering (CAE) systems in their specific environment. Electronic exchange of engineering data is, however, still in the early stages [6]. Mostly, the data exchange between the different engineering phases is based on paper or low-level electronic exchange with e.g. spreadsheets or electronic documents.

3. The automated design approach

2.2. Critique to the state-of-the-art In modern BAS, decentralized components equipped with own processors that run application programs communicate “peer-to-peer” through a communication network. Nowadays, application engineers design such building automation networks manually. This task is time consuming and error prone. Among others, application engineers are confronted with the following fundamental problems. • Modern BAS consist of a high number of components from different manufacturers. • Thousands of components from different manufacturers are available on the market. • Each component performs a certain task within an AS. The different AS are often planned by different planners.

If it were possible for the planner to cope with all functionalities and different types of components from several manufacturers under consideration of standards and interoperability, an optimized design of BAS in terms of functionality and engineering costs represented by an integrated data exchange format (cf. Section 2.1) would be feasible. For a human planner, however, this task is almost impossible to solve, but computer technology offers possibilities to fulfill this objective. For that purpose, established data sheets have to be replaced by semantic specifications of components, which are stored in a standardized repository (cf. Section 3.3). This repository has to organize the large number of components on the market in order to facilitate an effective search and choice of components. Such a repository offers a completely new approach for the design of BAS. An integrated function-oriented top-down design is feasible and can also replace the current device-oriented bottom-up design of BAS at implementation planning. The integrated, automated and function-oriented design with its three phases Requirement Analysis, Abstract Design and Detailed Design (cf. Figure 2) is aligned with today’s planning workflow as shown in Figure 1.

Communication standards [7] [8] ensure a compatible communication of the components (OSI layers 1 to 6). However, the interoperability of the components on the application layer (layer 7) is not guaranteed. Existing data type and standard profile definitions improve interoperability between components from different manufacturers, but they are not detailed enough to ensure a proper interoperability in every case. Not only the syntax, e.g. the data types and profile interfaces, but also the semantics of the transported information and the internal behavior are of great importance for a seamless interoperability. Because this has not yet been explicitly addressed by the component manufacturers, the interoperability

Requirement Analysis

Abstract Design

Detailed Design

Data Model for BAS

Figure 2. Automated workflow of BAS

1489

engineering

In the Requirement Analysis engineering phase (Section 3.1), required functionalities are gathered in a guided dialog by means of the Knowledge Base System (KBS). In the Abstract Design phase (Section 3.2), the requirements will be processed and a control structure, consisting of abstract components independently of specific manufacturers, is designed automatically. The Detailed Design engineering phase (Section 3.3) compares to Implementation Planning (cf. Figure 1). In this phase, the above-mentioned repository is needed and, hence, concrete components from specific manufacturers are used and combined. An independent Data Model for data exchange (cf. Figure 2) between the engineering phases is fundamental for such an automated design approach as described in Section 2.2. Furthermore, it is also a big step towards an optimized integrated design of BAS. CAEX (Computer Aided Engineering eXchange) has been selected for the data exchange within the AUTEG-Project. This choice is the result of a detailed analysis. CAEX is standardized in the IEC 62424 standard [9], and has been proved and tested in practice for process automation. CAEX is a meta model for vendor- and tool-independent structuring and categorization of CAE (Computer Aided Engineering) data. Nevertheless, it provides mechanisms to refer to vendor specific information. CAEX allows a systematic life-cycle-accompanying data exchange between the different CAE systems within the various AS in the different planning phases. CAEX does not define domain (e.g. process automation, building automation) or AS specific objects, because of its meta format concept. Due to this, a specification to adapt CAEX to the terminology of the building automation domain was established [10]. The intention is to define an improved data exchange (cf. Section 2.1) for an optimized engineering process in general and for the AUTEG-Project [4] by means of the specified CAEX.

The new approach of automated Requirement Analysis differs from the current elicitation of requirements in the application of an intelligent software tool. This Requirement Analyzing Tool supports the planner at the elicitation of requirements and solves the above-mentioned problems as far as possible. A catalogue of BAS-requirements for such an intelligent requirement elicitation is mandatory. Within the AUTEG-Project [4], a catalogue of requirements has been gathered, which is the result of a detailed domain analysis, as based on, among others, [5], [11], [12] and VDI 3813-2 (which is in draft, and will be an inherent part of the ISO 16484-4 [13]). In the following, some details of this catalogue are shown. Furthermore, the catalogue defines possible correlations between the requirements. Functional Requirements: Application Function: constant light control, automatic light, etc. o Operating / Display Function: set light, set occupancy, etc. • Non-Functional Requirements: o Sensor: illuminance sensor, temperature sensor, occupancy sensor, etc. o Actuator: high/low voltage halogen lamp, jalousie drive, etc. o Control Element: switch, control panel, etc. • Attributes (Attributes can qualify Functional and Non-Functional Requirements): o Operating voltage, ingress protection (IP), current consumption, etc. •

o

Figure 3. Details of the catalogue of requirements The essential intention of this Requirement Analysis phase is to gather all relevant Functional and NonFunctional Requirements, which are necessary for the automated design of BAS. These decentralized BAS (cf. Section 1) lead to complex requirements, which are assigned to the corresponding building structure elements (e.g. rooms). Within Requirement-Analysis practice, typical recurring, coherent requirements of BAS will be assigned to similar rooms (e.g. kitchens, bath rooms, corridors). Recurring coherent requirements are automatic light, 2 fluorescent lamps, illuminance sensor, switch, etc., for example. This is the result of a detailed domain analysis. On this basis, two fundamental approaches for the automated elicitation of requirements and Requirement Analysis respectively are defined: • Application of a KBS to manage all planerspecific knowledge. • Methodical, “room-oriented” procedure aligned with practice.

3.1. Automated elicitation of requirements The current elicitation of Requirements for the Building Automation System (BAS), which is to be planned, depends on customers’ requests (e.g. building-owner) and on planner knowledge (cf. Section 2.1). Today’s elicitation of requirements often leads to sub-optimal requirements for the further engineering phases. Especially, failures in early phases of the engineering workflow lead to increased costs in later phases. In the following, fundamental causes for this non-optimal requirements elicitation are outlined: • Building-owner and planner use different vocabularies, leading to misunderstandings and communication problems. • Software support is at a low level in this phase. • The planner cannot cope with all the functionalities and different types of components.

1490

The KBS is the fundamental component of the Requirement Analyzing Tool. Within the domainspecific Knowledge-Base, expert knowledge of several planners is stored in a machine interpretable form. In that case Requirements, e.g. all types of Functional, Non-Functional Requirements (cf. Figure 3), their attributes, but also their individual correlations, are stored. Just as the fact that the constant light control application function does not work with a fluorescent lamp is planner-specific knowledge, so is the fact that the automatic light application function needs an occupancy sensor, for example. This knowledge in the Knowledge-Base will be used by the Requirement Analyzing Tool to perform a complete requirement analysis. The knowledge is represented in terms of rules, which is an intuitive form of knowledge representation. Within a KBS, Rules have successfully been applied to engineering problems in process automation [2] [3]. The Inference-Machine infers solutions by means of the Knowledge-Base and FactBase. Thereby, the Inference-Machine applies knowledge of the Knowledge-Base to the Fact-Base [14]. Only by cooperation of the three described fundamental components Knowledge-Base, InferenceMachine and Fact-Base of the KBS, an active support of the methodical, “room-oriented” procedure is feasible. For this procedure, the Requirement Analysis differentiates between the parts Design of RoomTemplates and Instantiation of Room-Templates. In the following both parts are disclosed.

1..* Application Function 1..* 0..*

1..*

Sensor

Actuator

1

1..* 1 Actuator Group

1 1..*

0..*

Operating / Display Function - AG Operating / Display Function - AF

1

1

1..*

1..*

Control Element - AG

Control Element - AF

Figure 4. Class Model Room-Template Part 2: Instantiation of the Room-Templates This software part assigns the requirements, which were collected and allocated to Room-Templates, to the building structure. Therefore, the pre-defined RoomTemplates within the pre-defined attributes, correlations, etc. can be instantiated according to the corresponding building structure element, e.g. storeys and rooms. The information about the building structure will be gathered from the Industry Foundation Classes (IFC) data platform. The IFC specification is a neutral data format to describe the exchange and sharing of information typically used within the building and facility management sector [11] [15]. Therefore, a software tool extracts and analyzes relevant IFC information for the automated design approach and stores them by means of the independent data exchange format for the engineering of BAS [10]. The building structure information establishes the substructure for the Requirement Analysis, and subsequently for the Abstract Design and Detailed Design phases. A special adaptation of the instantiated templates to the current BAS, which is to be planned, is feasible. The software tool here also completes the necessary requirements automatically. For example, an outdoor temperature sensor is defined within a Room-Template. This template is instantiated in five rooms. Now, it is not necessary to instantiate five outdoor sensors. Instead, the Requirement Analyzing Tool detects and lets the user solve this inconsistency by means of a guided dialog.

Part 1: Evaluation of Room-Templates As mentioned above, recurring room-oriented coherent-requirements are typical for BAS, which are to be planned. Therefore, various planner-specific Room-Templates can be evaluated by this part of the software. The class model of such Room-Templates is shown in Figure 4 (cf. Figure 3). The Requirement Analyzing Tool acquires the requirements in a guided dialog by means of the KBS. For applications in the further engineering phases of the automated design, correlations among the related requirements will be created during Requirement Analysis. The Room-Templates are stored in the data exchange format. The software automatically evaluates inconsistencies or necessary requirements for such a Room-Template, which cannont be covered by the guided dialog. For example, an illuminance sensor is mandatory for the constant light control application function. The software tool detects this fact by means of the KBS and instantiates this sensor automatically.

1491

The collected and analyzed requirements are stored in the data exchange format for the Engineering of BAS [10]. A complete elicitation of requirements for a BAS, which is to be planned, is feasible using the Requirement Analyzing Tool. This room-oriented procedure facilitates the planning of BAS, because the pre-defined Room-Templates yield a high degree of reusability. The function oriented approach allows early statements of possible energy savings by means of an intelligent BAS (cf. Section 1). Furthermore, the approach of an “intelligent” Requirement-Analysis saves capacities of the planner for e.g. specific applications. As a result, an optimized BAS is feasible. Storing the requirements in the integrated data exchange format enables the application of automated design tools in the following engineering phases.

no more occupied, the light is switched off after a configured delay. The paradigm of Generative Programming as a software engineering paradigm [16], which aims to model software system families by grouping single individualized software products, is applied to generate the abstract designs. The usability for the composition of function block based systems instead of software is a new approach and has been demonstrated in [17]. One of the main challenges here is to comprehensively collect and formalize the atomic function block based design patterns in electronic format, especially their links in form of logical connections between each other (e.g. commonly used sensors and operating functions, AS spanning information exchange). An active library forms the repository, where all design patterns are collected, as shown in Figure 5. It contains a multitude of active elements (AE) specified in an ICCL (implementation component configuration language). Each active element here represents one AS specific design pattern, such as design patterns for lighting, shading or HVAC. A generator can then take functional requirements from the Requirement Analysis specified in a DSL (domain-specific language) and select appropriate active elements. The particular active elements are automatically instantiated according to the given requirements, resulting in room specific abstract designs for the involved AS. In a second step, the different AS are combined to complete abstract designs for each given room along their links. This process of automatically generating abstract designs is repeatedly executed for all rooms and sections of a building, resulting in abstract designs for every room and section.

3.2. Vendor-independent preliminary design The functional and non-functional requirements for BAS, which have been gathered by means of a knowledge-based tool and analysed and completed in the Requirement Analysis, as explained in the previous section, form the base for all following steps of the automatic design workflow of BAS. It is a fundamental scope of the AUTEG project to automate these steps by providing software tools which are able to automatically compose complete BAS, consisting of the logical and physical network designs. In this section, the Abstract Design as the first step of the automated design is outlined. The next section presents the subsequent Detailed Design. The Abstract Design proceeds at a purely functional level, based on platform- and manufacturerindependent function blocks according to ISO 16484-3 [5] for HVAC systems and the emerging ISO 16484-4 [13] for room automation. Such function blocks represent commonly accepted functions and can be considered as abstract placeholders for specific field and automation devices, which are to be selected in the Detailed Design. By composing such function blocks in form of control diagrams, the functionality of BAS is modelled in an abstract way, detached from any concrete technical realization. The aim is now to generate the abstract designs fully automatically based on the given requirements. Typical design patterns that are recurrent in building automation are the key for automating this step. Such design patterns are typical constellations of sensors, controllers and actuators for specific functions. A constant light control for example, which balances fluctuating daylight and regulates the room luminance at a constant level, requires the room luminance from an illuminance sensor and the occupancy state from an occupancy sensor as basic requirements. Via controlling one or more light actuators, the controller regulates the room luminance to a given setpoint, whenever people are present in the room. If the room is

Figure 5. Automatic abstract designs

generation

of

3.3. Semantic specification of devices Established device descriptions for automation devices e.g. EDDL [18], GSDML and FDCML [19] and CANopen EDS [20] lack a machine understandable semantics, thus inhibiting necessary tasks like the semantic retrieval of devices, their automatic parameterization and interoperability

1492

Special attention is put on the devices’ software applications. For this purpose, a semantic component model underlying the profile descriptions has been developed. It introduces five modeling primitives: the operation modes, their parameterization, functions, semantic types and internal variables. These primitives, realized in OWL, facilitate an enriched semantic specification of profiles from a functional view. The developed OWL-based semantic device specifications allow for a functional retrieval of devices and their applications and an automatic parameterization. With OWL as logical language with formal semantics, the interoperability analysis between profiles of different devices can be encountered with reasoning. Finally, complete network designs can be validated for correctness and completeness. For a more detailed description of semantic device descriptions and their applications we refer to [21]. The semantic device descriptions, which were shortly introduced in this section, form the basis for the Detailed Design. The Detailed Design phase is described in the following section.

analysis. Especially the functionality of the profiles, the software part, can not adequately be described with current standards. Because those tasks are essential for automating the design of BAS in the Detailed Design phase (Section 3.4), established device descriptions are not suitable for this purpose. To overcome these limitations, an approach for a semantic specification of building automation devices has been developed in the AUTEG project, which covers the devices’ hardware and particularly their applications [21]. The approach is based on the application of Semantic Web technologies, especially OWL (Web Ontology Language) as a formal language for the specification and distribution of ontologies [22]. The developed OWL-based specification of the hardware part comprehends the processors, RAM, ROM, EEPROM, transceivers, I/O modules and their characteristics. They cause further properties like the supported transmission mediums and topologies, data rates and input and output functions. An example of an OWL-based transceiver specification is given in Figure 6. 64 2700 FTT-10 78000

3.4. Detailed design and selection of vendor-specific components On the second design level, the Detailed Design, an automated refinement of the abstract designs towards a specific platform, e.g. LON, EIB/KNX or BACnet, is carried out. The platform-independent function blocks need to be replaced by manufacturer-specific profiles. In parallel, field and automation devices are selected and the logical and physical BAS networks are composed. At this point, a huge number of available devices on the market of the chosen platform are to be considered, which can be realized by the introduction and application of semantic device descriptions (cf. Section 3.3). Because the multiple degrees of freedom at this design level render it impossible to find an optimal solution in a direct and straightforward way, the design process is considered as an optimization task. By applying evolutionary algorithms, which are inspired by biological evolution and which support a parallel trial and error of different solutions, this complexity can be faced. Evolutionary algorithms have successfully been applied for similar design problems like the design of analog circuits [23]. The basic evolutionary cycle is shown in Figure 7.

Figure 6. OWL-based specification of an FTT-10 transceiver

1493

Figure 7 Optimization evolutionary algorithms

cycle

of

An initial population, which typically contains several hundreds of individuals, forms the starting point of the optimization. Individuals herein represent solutions to the optimization problem. They are rated according to a fitness function, which incorporates different criteria like refinement state, interoperability, correctness, completeness and financial costs for the BAS networks. In the beginning, the individuals are the Abstract Design, which is to be refined to a Detailed Design. The evolution takes place over several cycles (generations), where each cycle consists of the steps selection, recombination and mutation. Via selection, the best individuals in the sense of their fitness are selected and survive, while others are eliminated. The survivors can then create offsprings via recombination. Subnetworks of both parents are here combined to new detailed designs. Subsequently a random mutation operation adapts the individuals by refining a randomly chosen function block to a compliant profile and corresponding device, or by replacing a randomly chosen profile with another functionally equivalent profile of another device. During the network modifying steps, the logical and physical connections between the devices are updated, thereby ensuring a consistent network at each step. Thus, over several generations, a stepwise refinement of Abstract Designs to Detailed Designs takes place, as can be seen in Figure 8. It shows the logical (left part) and physical network design (right part) of the best individuals of generation 1 (initial population), generation n and generation z (final population). If the termination criterion is met and the optimization does not lead to any further improvement, the optimization is stopped. The user, typically the system integrator, can then decide, if he wants to use the Detailed Design with the best fitness measure or any other individual of the final population. Regardless of which design he selects, the user will get a full parameterized design on the logical and physical level that is ready for final customizations.

Figure 8. Stepwise refinement of abstract designs with evolutionary algorithms

4. Conclusions and Outlook The paper describes the problems in the design of building automation systems today, which will be solved by the automated design approach. Within the Requirement Analysis, a knowledge-based software system supports the planner by the elicitation of requirements. Furthermore, the tool completes the relevant requirements automatically with explicit knowledge also stored in the knowledge base. These requirements are necessary for the subsequent engineering phase Abstract Design. Typical design patterns that are recurrent in building automation are the key for automating this step under appliance of Generative Programming. Both these phases are manufacturer-independent. Based on the abstract design, a semantic description of components from several manufacturers in a component repository allows the automated composition of complete BAS, consisting of the logical and physical network. By applying evolutionary algorithms in the Detailed Desgin phase, the final output of the automated design process is an optimized, fully developed BAS. The automated design approach allows the integration of components from any manufacturer and several Assembly Sections e.g. room automation, Heating Ventilation and Air Conditioning (HVAC) to an integrated complete system. This approach results in a reduction of engineering costs while offering a high degree of functionality.

1494

[14] E.-A. Feigenbaum, A Personal View of Expert Systems. Acknowledgements

Looking Back and Looking Ahead, Stanford University, Knowledge Systems Laboratory, Department of Computer Science, 1992. [15] International Alliance for Interoperability: Industry Foundation Classes IFC, (IFCWiki), http://w.ifcwiki.org/index.php/Main_Page [16] K. Czarnecki, U. W. Eisenecker, Generative Programming: Methods, Tools and Applications. Addison-Wesley, 2000. [17] U. Ryssel, J. Ploennigs, K. Kabitzsch, “Generative Function Block Design and Composition” in Proc. WFCS 2006, Turin, pp. 253-262, 2006. [18] ANSI/ISA-61804, Function Blocks (FB) for Process Control – Part 3: Electronic Device Description Language (EDDL), June 2007. [19] ISO 15745, Industrial automation systems and integration – Open systems application integration framework - Part 3: Reference description for IEC 61158-based control systems, Std., March 2003. [20] CAN in Automation, CANopen – Overview, http://www.canopen.org [21] H. Dibowski, K. Kabitzsch, “Semantic Device Descriptions based on Standard Semantic Web Technologies” in Proc. WFCS 2008, Dresden, 2008, pp. 395-404. [22] M. Dean, G. Schreiber, “OWL Web Ontology Language Reference”, W3C Recommendation, February 2004. Available: http://ww.w3.org/TR/ol-ref/ [23] J.R. Koza, M.A. Keane, M.J. Streeter; “Routine HighReturn Human-Competitive Evolvable Hardware” in Proc. of the NASA/DoD Conference on Evolvable Hardware, 2004, pp. 3-17, 2004.

The authors gratefully acknowledge the financial support provided by the German Federal Ministry of Economics and Technology along with industrial partners in the frame of the AUTEG project. (Promotional Reference IN5506) References [1] H. Dibowski, C. Oezluek, J. Ploennigs, K. Kabitzsch, “Realizing the Automated Design of Building Automation Systems” in Proc. of the 4th IEEE International Conference on Industrial Informatics, Singapur, 2006, pp. 251-256. [2] T. Schmidberger, A. Horch, A. Fay, and R. Drath, “Rule Based Engineering Of Asset Management System Functionality”, in 5th Vienna Symposium on Mathematical Modelling,, pp. 2.1–2.8, Vienna. F. Breitenecker and I. Troch, 2006. [3] R. Drath, A. Fay, and T.Schmidberger, “Computeraided design and implementation of interlocking control code”, in 2006 IEEE International Symposium on Computer-Aided Control Systems Design (CACSD06), pp. 2653–2658, Munich. IEEE, 2006. [4] Dresden University of Technology, Automated Design for Building Automation (AUTEG), 2007, http://www.ga-entwurf.de [5] International Organization for Standardization: ISO 16484-3 – Buidling automation and control systems (BACS) - Part 3: Functions [6] M. Fedai, R.Draht, “CAEX - a neutral data exchange format for engineering data”, atp international, 2005. [7] ENV 13321-1, Data communication for HVAC application automation net. BACnet, Profibus, World FIP, 1999. [8] ENV 13154-2, Data communication for HVAC application field net. Protocols, 1998. [9] International Electrotechnical Commission: IEC PAS 62424 - Representation of process control engineering requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools [10] S. Runde, A. Fay, “A Data Exchange Format for the engineering of Building Automation Systems” submitted for publication in Proc. ETFA 2008, Hamburg, 2008. [11] International Organization for Standardization: ISO 16484-2—Building automation and control systems (BACS)—Part 2: Hardware [12] International Organization for Standardization, ISO/PAS 16739: Industry Foundation Classes, Release 2x, Platform Specification (IFC2x Platform) [13] International Organization for Standardization: ISO 16484-4—Building automation and control systems (BACS)—Part 4: Applications

1495