IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 7, NO. 4, NOVEMBER 2011 723

Software Support for Building AutomationRequirements Engineering—An Application of

Semantic Web Technologies in AutomationStefan Runde and Alexander Fay, Senior Member, IEEE

Abstract—Modern building automation systems consist of up toseveral thousands of components (e.g., sensors, controllers, actu-ators) with numerous attributes and dependencies. Additionally,different crafts of the building automation domain, e.g., heating,ventilation, lighting, access control, are involved in the design andimplementation of such a building automation system. In addi-tion, various engineering standards have to be considered withinthe requirements engineering phase. Although the modeling of therequirements for decentralized building automation systems re-quires a huge effort, there is little software support available forthis task today. This offers optimization potential not only for therequirements engineering, but also for subsequent phases of theengineering process in building automation. Within this paper, theauthors describe a knowledge-based requirements engineering ap-proach and a supporting software, which is based on Semantic Webtechnology.

Index Terms—Building automation, knowledge-based systems,ontology, requirements engineering, semantic web.

I. INTRODUCTION

M ODERN building automation systems (BASs) do notonly provide improved comfort but offer significant en-

ergy cost savings [1], especially in office buildings and pro-duction halls but also in home buildings, because of combinedcontrol systems such as coordinated lighting, cooling, and sun-blind functions. However, the initial investment costs in BASare higher than the costs for conventional building installation.Thus, the long payback period of BAS scares many potentialcustomers off the application of these systems. To achieve thepossible energy savings, the initial investment costs need to bereduced.

Engineering costs account for a considerable part of thewhole project cost of buildings. Consequently, the reductionof engineering costs can promote the dissemination of BAS.

Manuscript received March 09, 2011; revised June 13, 2011; accepted July14, 2011. Date of publication September 15, 2011; date of current versionNovember 09, 2011. This work was supported in part by the German FederalMinistry of Economics and Technology along with industrial partners in theframe of the AUTEG Project, based on a decision of the German Parliament(Project reference IN-5506). Furthermore, the authors acknowledge the plan-ning contractor “Heidemann & Schmidt” for offering the possibility to applythe outcome of the research project within a project in building practice. Paperno. TII-11-098.

S. Runde is with the I IA IA&DT-ATS 3 1, Siemens AG, D-76187, Karlsruhe,Germany (e-mail: stefan.runde@siemens.com).

A. Fay is with the Institute of Automation, Helmut Schmidt University Ham-burg, D-22043 Hamburg, Germany (e-mail: alexander.fay@hsu-hh.de).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TII.2011.2166784

Looking at the building automation (BA) engineering process,in general, optimization potential will become accessible byan automated process in design synthesis [2]. Within such anautomated design process, automated engineering mechanismshave proven to reduce engineering effort already in other au-tomation domains [3], [4]. The Automated Design for BuildingAutomation (AUTEG) research project [5]–[7] focused on thistopic. The basis for such an automated design synthesis are:(a) a consistent data exchange format to exchange engineeringdata between the planning phases of the different crafts and (b)a complete elicitation of requirements within the requirementsengineering (RE) phase regarding the BAS. Within this paper,the authors propose a methodical procedure for the RE basedupon a knowledge-based system (KBS), which implementsparts of the current BA engineering workflow and whichuses Semantic Web Technologies of the World Wide WebConsortium (W3C).

Section II gives a short introduction into the engineering ofBAS and describes disadvantages of today’s RE. In Section III,the methodical procedure for an improved RE is proposed.The requirements model in Section IV serves as the basis forthe knowledge-based RE. Section V introduces the basics ofthe KBS and continues with the implementation of the KBSby means of Semantic Web Technologies in more detail. InSection VI, implementation details of the knowledge-based REsoftware are shown, and in Section VII, some results from areference project are reported.

II. REQUIREMENTS ENGINEERING OF

BUILDING AUTOMATION SYSTEMS

BAS consist of a lot of “intelligent” devices [1], which com-municate via one or several bus systems (wired and/or wire-less) [8], [9], resulting in heterogeneous and complex automa-tion systems [10]–[12]. BAS are complex Networked ControlSystems [13], but due to the quite mature communication tech-nology used in BAS, today’s research focuses especially on the“Control of Network” [13] in the BA domain. Various aspects ofBAS have been dealt with by researchers, such as the integrationof different communication systems within BAS [8], [9], [12],safety requirements [11], and security requirements [10], [11].Nevertheless, in today’s practice, planners still have little sup-port in the early engineering phases of such BAS. These plan-ners are, e.g., electronic engineers or civil engineers, thus, theyhave different knowledge backgrounds. They usually do nothave skills on classical RE, as known in software engineering.Today’s engineering process in BA can be subdivided into thephases requirements engineering (RE), conceptual design, and

1551-3203/$26.00 © 2011 IEEE

724 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 7, NO. 4, NOVEMBER 2011

implementation design [7]. While for the implementation de-sign, various software tools are available (usually vendor-spe-cific or specific for a certain type of communication technologywithin the BAS), the planner still lacks support by methodsand tools in the RE phase. This issue will be addressed in thiscontribution.

The intention of the RE phase is to gather all relevant re-quirements for the two following phases. In today’s practice, therequirements are written down in project-specific documents,without a formalized notation. All these documents togetherform the so-called “room book(s)” [7]. In the conceptual designphase, the requirements are processed, and a control structure isdesigned. The results are presented, e.g., in control schematicsor functions lists [14], still independent of specific manufac-turer’s components. Within the implementation design phase,specific components from manufacturers are selected, based onthe requirements resulting from the previous phases. The se-lected components are listed in text documents. Additionally,this state-of-the-art engineering process is typically an itera-tive process. Furthermore, a multitude of different planners andcrafts are involved in several phases. The focus of this paper ison the RE phase. The subsequent phases conceptual and imple-mentation design are, e.g., dealt with in [5] and [6].

Today’s elicitation of requirements for BAS depends on cus-tomers’ requests (e.g., a building owner’s) and on planners’knowledge. Within RE practice, typically recurring, coherentrequirements of BAS will be assigned to similar rooms (e.g.,kitchens, bathrooms, corridors). This is called the “room-ori-ented” procedure. Today’s RE often results in suboptimal re-quirements. Reasons for this are the following.

— The basic document resulting from the RE phase, theso-called “room book,” does not follow a formalizednotation; instead, structure and notation vary from projectto project.

— Building owner and planner use different terminology,which results in misunderstandings.

— The planner cannot cope with all the possible differenttypes of requirements (regarding, e.g., controllers, sensors,actuators, communication systems) and their individualattributes.

— RE software, which is used, e.g., in the automotive oraerospace industry to capture requirements, is not cus-tomized to the phases, the crafts, and the terminology ofBAS and can therefore not be applied. Therefore, soft-ware support is still at a low level in this phase in buildingautomation.

Consistent requirements are, however, important for the twofollowing engineering phases. Especially, flaws in early phasesof the engineering process result in increased costs in laterphases and finally in suboptimally designed BAS, which in turnincrease overall building life cycle costs.

The authors propose to support the RE phase of BAS by asoftware tool which combines two basic methods.

— A systematic, “room-oriented” procedure, aligned withcurrent planners’ practice.

— The application of a KBS to manage the planner’s knowl-edge and the BAS planning data.

In Section III, this “room-oriented” procedure is described.Further details can be retrieved from [27].

III. SYSTEMATIC “ROOM-ORIENTED” PROCEDURE

Today’s approach to RE of BAS is based on a dialoguebetween the building owner and the planner. The requirementsare collected in a “room-oriented“ manner, i.e., collectedand grouped according to individual rooms, or types of sim-ilar rooms (e.g., “office for two workers”) and described asroom-specific templates on paper. To further structure andsystematize this procedure, we differentiate between the stepsdesign of room templates and instantiation of room tem-plates [15]. In the following, both these steps are describedbriefly. This procedure allows a function-oriented elicitation ofnecessary requirements of a BAS, which considers typical im-plementation constraints. Therefore, contrary to the approachdescribed in [16], an adaption of selected hardware in theimplementation design phase will not be required.

A. Step 1: Design of Room Templates

Recurring room-oriented requirements are typical for BAS.Therefore, planner-specific room templates can be designedin this first part. These project-independent templates canbe reused in further building projects. Such a requirementtemplate can, e.g., describe the requirements of a standard 20square meters office room: amongst other features, this roomcan be equipped with an automatic lighting system, whichcomprises of an automatic light controller with two connectedlamp actuators, which in turn activate two high-voltage halogenlamps. Additionally, all specific attributes of these requirementartifacts, as well as the causal dependencies to other artifacts,are described in such a template. These project-independenttemplates can be reused by assigning them project-specificallyto rooms.

B. Step 2: Instantiation of the Room Templates

Within the second step, the requirements, which were col-lected and allocated to room templates, are assigned to thebuilding structure. Therefore, the predefined room templatescan be instantiated according to the corresponding buildingstructure elements such as rooms. The information about thebuilding structure has to be collected manually from existingdrawings or has to be gathered automatically from specific datamodels such as the Industry Foundation Classes (IFC) dataplatform [17]. The IFC specification is a neutral data format tofoster the exchange and sharing of information typically usedwithin the building and facility management sector. In bothcases, the building structure information forms the backbonestructure for the instantiation of the room templates.

In addition to this approach for an improved RE, a require-ment model is mandatory for the application of a KBS. The ba-sics of the requirement model are described in the Section IV.Further information can be retrieved from [18].

IV. REQUIREMENT MODEL

Within the AUTEG project [6], [7], a requirement model hasbeen developed, which is the result of a detailed domain anal-ysis, as based on standards such as [14], [17], [19] and theguideline VDI 3813–2 (which is still in draft status, but will

RUNDE AND FAY: SOFTWARE SUPPORT FOR BUILDING AUTOMATION REQUIREMENTS ENGINEERING 725

Fig. 1. Requirement model.

become an inherent part of the ISO 16484-4 [20]). The require-ment model serves as the basis: (a) for the data exchange format(as described in the following) and (b) for the knowledge baseof the KBS (cf. Section V).

In short, the data exchange format has to provide the fol-lowing possibilities.

— Support different types of planning workflows, e.g.,bottom-up and top-down approaches.

— Represent manufacturer-, vendor-, and project-specific in-formation where requested, but also generic placeholders.

— Allow to deal with incomplete information, as this is fre-quently the case during the planning process.

— Allow to represent data for all crafts (also called “construc-tion packages”) of building automation.

Especially the fourth requirement makes product models suchas IFC [17], IGES [21] and STEP [22] unfeasible.

Computer Aided Engineering eXchange (CAEX), which isstandardized in the IEC 62424 standard [23], is a meta modelfor vendor- and tool-independent structuring and categorizationof CAE data. Nevertheless, it provides mechanisms to referto vendor specific information. CAEX allows a systematiclife-cycle-accompanying data exchange between the differentCAE systems and crafts in the different planning phases. Ob-ject oriented concepts, e.g., encapsulation, classes, instances,instance hierarchies, relations, attributes, and interfaces areexplicitly supported.

The semantic description of patterns is ensured by refer-encing engineering standards. CAEX is proven and tested inpractice in the process automation domain. Among the exam-ined data formats, CAEX fulfills the requirements describeabove and has therefore been chosen as the backbone for thedata exchange format. Because CAEX is a metamodel, modelelements (classes) have to be defined first to build domain-spe-cific models for BA based on CAEX.

In the following, some model elements and possible func-tional requirements for the RE phase of BAS are outlined.

—

—

—

—

—

—

—- and

execute various types offunctions. An -represents the user interface primarily on a functionallevel. Ancan be perceived as a connector between ,

, and , aswell as between - .

share the characteristics of aand . They can engage

into a physical process, but it is also possible to retrieve in-formation from the physical process, e.g., via human action(for example, a human operates a switch to rise the jalousie).Consequently, they do not fall into one of the other classes,and this additional class is defined within the requirementmodel. The -permit the functional access to the BAS by means of the

. These model elements and requirementsrespectively are specified by and, ifnecessary, by and ,which are again specified by [24].The and areagain specified by and typicaldefault values, including a unit. Furthermore, the require-ment model defines the causal dependencies between theserequirements, as shown in Fig. 1. For the purpose of abetter overall view, neither the model elements (possible re-quirements) and their individual, causal dependencies (e.g.,

-) are shown in Fig. 1, nor the causal dependencies of

model elements to a .To model a specific BAS in a particular building project, these

model elements (classes) have to be instantiated. The knowledgedescribed by means of the requirement model is an essential partof the KBS, hence, for the RE tool.

V. KNOWLEDGE-BASED SYSTEM BASED ON

SEMANTIC WEB TECHNOLOGIES

A. Concept of the Knowledge-Based System

KBS have already shown their suitability for the supportof engineering in other automation domains (e.g., factory and

726 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 7, NO. 4, NOVEMBER 2011

Fig. 2. Knowledge-based system for the engineering.

process automation) [4]. The proposed KBS for the RE withinthis paper is based on the well-proven concepts of [25] and[26], as shown in Fig. 2. Such a KBS is subdivided into twomain modules: control system and knowledge base.

The knowledge base comprises several parts. According tothe origin of the knowledge, it can be distinguished betweendomain-specific knowledge and case-specific knowledge. An-other way of subdividing the knowledge is by its use. This re-sults in the subdivisions of declarative knowledge and proce-dural knowledge. With regard to the knowledge-based RE, theknowledge is classified to factual and class knowledge, as wellas rule knowledge [27].

By means of factual knowledge (case-specific,declarative knowledge), facts of a building with itsautomation system can be described. For example,

of is con-nected to theof . Furthermore, is part of

.This factual knowledge is inferred from the class knowledge

(domain-specific, declarative knowledge), which is describedwith regard to the requirement model (cf. Section IV). So, thedomain knowledge can be described by means of semanticterms for the possible requirements, and for the correlationsbetween them (cf. Section IV). For example, the possiblerequirement withits attributes (e.g., ) and pos-sible attribute-values ( , , etc.) is described in the classknowledge. Furthermore, the causal dependencies of the

to other possiblerequirements, e.g., to or

and/orare defined by means of this type of knowledge.

Moreover, the rule knowledge (declarative, proce-dural knowledge) allows the “production” (i.e., creation,change, or extinguishment) of new factual knowledgebased on the available factual and class knowledge. Forexample, ifis planned for a , then the value of the attribute

is set automatically to .A more complex example is the detection as well as theelimination of redundant requirements. Thus, it is possible todetect an undesirably high number of planned sensors (e.g.,

Fig. 3. Knowledge-based system for the requirements engineering based onSemantic Web Technologies.

) at a by rule knowl-edge and to eliminate this undesired profusion.

The control system contains program code for the programexecution, problem-solving strategies, and interfaces to the userand the expert. It consists of the parts interviewer, explanation,and knowledge acquisition component, as well as the inferencemachine (cf. Fig. 2). The software code of the inference machinehas to be independent of the knowledge represented within theseveral parts classes, factual and rule knowledge. The inferencemachine applies rule knowledge to the class and factual knowl-edge [25] and allows to (re)write new factual knowledge or tosearch on the factual knowledge. The other parts, interviewer,explanation, and knowledge component, are not described fur-ther within this paper, because the focus is on the realization andapplication of the KBS by means of Semantic Web technologies.

B. Technical Implementation of the Knowledge-Based System

According to its founder Berner-Lee, the Semantic Web isdefined as “an extension of the current web in which informa-tion is given well-defined meaning, better enabling computersand people to work in cooperation” [28]. In the frame of the Se-mantic Web Initiative [33], many technologies are developed,not only for use in the internet but also in industrial applica-tions (see, e.g., [34]). In the following, the main technologiesand tools of the Semantic Web Initiative with regard to the KBSfor RE are described. Further information of the Semantic Weband its technologies can be retrieved from [33]. In Fig. 3, it isshown how the KBS for RE can be implemented based on Se-mantic Web Technologies.

The class knowledge and the factual knowledge of the KBSare represented by OWL (Web Ontology Language) [35].OWL, the major technology of the Semantic Web, has beendeveloped to represent machine-interpretable semantic content.The knowledge representation language with formal semanticsoriginating from artificial intelligence is based on RDF, RDFSchema, and XML.

In the BA domain, OWL has already been used to express thesimilarities within a generic model description for BAS com-munication systems [8], [12]. OWL allows a formal, semanticspecification of the knowledge. OWL distinguishes between theterminological level and the assertion level. The class knowl-edge can be described on the terminological level of OWL, asshown in Fig. 4.

RUNDE AND FAY: SOFTWARE SUPPORT FOR BUILDING AUTOMATION REQUIREMENTS ENGINEERING 727

Fig. 4. Details of the OWL-ontology.

Fig. 5. Details of the SWRL-rule.

Fig. 4 shows exemplarily causal dependencies for theRE of theon the sensors ,

, andshown. The assertion level of OWL ontologies yields thepossibility to represent the factual knowledge. Therefore, theclass knowledge can be instantiated on this level.

By means of SWRL-Rules (Semantic Web Rule Language)[36], the rule knowledge is represented. Some details of a rule,which is used within the knowledge-based RE tool, are exem-plarily shown in Fig. 5.

This rule describes the knowledge for the automatic detec-tion of the correct based on a

by means of the inference engine.The rules or queries for a search are declared by Semantic

Query-Enhanced Web Rule Language (SQWRL) [37]. SQWRLis a SWRL-based query language. Both these rule languages areexplicit for OWL ontologies and area a part of the Rule MarkupLanguage (RuleML) family [38], which is currently employed

and tested in engineering [3], [4], [7]. Based on the RuleMLinitiative, Rule Interchange Format (RIF) [39] is considered asa future standard of the W3C (World Wide Web Consortium).

Within a detailed analysis of different inference machineswith regard to requirements, especially the support of OWL,SWRL/SQWRL, and inference strategies such as backward rea-soning and forward reasoning, Jess [40], a JAVA-based infer-ence engine, has been selected as the inference engine for theKBS for RE, because it fulfills all these requirements. Based onthe OWL ontology, Jess inferences new knowledge by meansof the SWRL Rules and adds it to the ontology. Jess also al-lows queries in SQWRL as required. Furthermore, this SemanticWeb KBS allows to use SPARQL (SPARQL Protocol and RDFQuery Language) [40] as a second possibility for an efficientsearch on OWL ontologies. As a query language for the Se-mantic Web, SPARQL fulfills the same role as SQL in the fieldof relational databases. Semantic Web technologies can there-fore be used to implement the core of the KBS; however, theyare less suitable for the interview component, explanation com-ponent, and knowledge acquisition component, which had to beprogrammed in JAVA.

VI. IMPLEMENTATION OF THE REQUIREMENTS

ENGINEERING PROCEDURE

The RE software is based on the KBS by means of SemanticWeb technologies (cf. Section V) and implements the “room-oriented“ Procedure (cf. Section III). Thus, the RE procedure issubdivided into two parts, as described in Section III: the designof room templates and the instantiation of room templates.

A. Design of Room Templates

By means of the knowledge-based software and based on thedescribed class knowledge in OWL, the requirements are ac-quired in a guided, context sensitive dialogue. A method to sys-tematically develop context sensitive user interfaces has beenpublished in [29].

Based on the rule knowledge, the software automaticallydetermines inconsistencies, redundancies and necessary re-quirements, which cannot be determined with the help ofthe guided dialogue. For example, the software recognizesthat a sensor which is assigned to a must meet atleast class . The softwaresets the value of this attribute in the respective dialogue butnevertheless gives the planner the possibility to change it. Inaddition, more complex attributions are executed on the baseof the knowledge. For example, an ismandatory for the .The software tool detects this fact by means of the KBS andinforms the planner, who can include this sensor in the RoomTemplate. For applications in further engineering phases, corre-lations between the related requirements are created by meansof the software. This additional knowledge is also stored in theknowledge base and can thus be used by the KBS.

The room templates are be stored in the requirement ontologyby means of OWL (cf. Section IV) for the application within theautomated design [5]. Furthermore, the room templates can be

728 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 7, NO. 4, NOVEMBER 2011

Fig. 6. Proceeding of the software part design of room templates.

stored in the data exchange format for the engineering of BAS[30]. Fig. 6 shows some details of this part of the RE procedure.

B. Instantiation of Room Templates

In this part of the RE procedure, the requirements, which havebeen collected and allocated to room templates, are assigned tothe building structure.

The information about the building structure is gathered fromthe Industry Foundation Classes (IFC) data platform. The IFCspecification is a neutral data format to describe the exchangeand sharing of information typically used within the buildingand facility management sector [17]. Therefore, a software toolextracts and analyzes IFC information which is relevant for theRE and the automated design approach, respectively, and storesthis information by means of the independent data exchangeformat for the engineering of BAS [30]. The building structureinformation establishes the main structure for the requirementanalysis.

Subsequently, the predefined room templates within thepredefined attributes, correlations, etc., can be instantiatedaccording to the corresponding building structure element (e.g.,rooms). Still, it is possible to adjust the templates designed inthe first software part. These global adjustments have conse-quences on all room requirements, which have been assignedto the appropriate room template. It is also possible to adaptthe requirements assigned to a room by means of templatesroom-specifically. These local adjustments have only influenceon one instance and not on the template.

This software part also uses the rule knowledge, e.g., to solveinconsistencies and redundancies in order to assist the planner tosolve them. For example, anis defined within a room template. This template is instantiatedin five rooms. In such a case, it would not be necessary to instan-tiate five outdoor sensors. The RE tool detects this redundancyby means of rule knowledge and informs the planner to solvethis problem. Details of how such rules are constructed and rep-resented in XML are given in Section V-B.

The overall requirements (building structure with assignedrequirements) are stored in the OWL ontology for the subse-quent engineering phases within the automated design [5]. Al-ternatively, these requirements can be stored in the data ex-change format [30], for further approaches (like [12]) for theengineering of building automation.

VII. REFERENCE PROJECT

The approach described above has been applied and refinedtogether with a planning contractor in a building project. Thereference project, the new administration building of the admin-istrative district Sigmaringen (in the Southwest of Germany),

Fig. 7. Details of the BAS of the new administration building of the adminis-trative district Sigmaringen.

is a four-storey extension of the existing district administrationoffice with a floor space of about 6600 square meters and anoverall contract price of about 21 Mio US-$ [15].

The approach described above has been applied from theearly RE phases throughout the subsequent planning phases.Main requirements for the new building have been the possi-bilities to use rooms in a flexible manner, the availability, theenergy efficiency, the utilization of renewable energies, and lowlife cycle costs. The heating and cooling of the building followsa resource-saving approach, mainly by means of geothermalenergy using a reversible heat pump and by means of theapproach of natural cooling, respectively. Efficient lightingequipment additionally ensures low energy consumption.

The main part of the building’s technical and energy conceptis an integrated BA system based on the open LONWorks stan-dard, standardized in EN 14908 [31] into which all technicalequipment and systems in the building are integrated (cf. Fig. 7).

This allows the exchange of information between all com-ponents in the several crafts. Each room can be individuallycontrolled based on usage profiles and can automatically be ad-justed to the respective requirements of the user groups underconsideration of the utilization, based on the concept of roomtemplates described above. For example, natural lighted roomsare operated at a reduced artificial light level and non-occupiedrooms are operated at a reduced temperature level and a lightout of action. The automation system essentially contributes toachieve the energy efficiency grade according to DIN EN15232 [32].

RUNDE AND FAY: SOFTWARE SUPPORT FOR BUILDING AUTOMATION REQUIREMENTS ENGINEERING 729

Fig. 8. Details of a room template.

Such a room template includes requirements regarding one ormore crafts as exemplary shown in Fig. 8. For the purpose of abetter overall view, neither all requirements artifacts of the tem-plate are shown in detail in Fig. 8, nor the causal dependenciesof requirements to the appropriate room. Instead, Fig. 8 high-lights the overlapping of two crafts [here: room automation andHeating, Ventilation and Air Conditioning (HVAC)].

A and a areneeded in both crafts: by theand the , respec-tively. The adjusts the

by means of the(this is designed by the room automation craft). The

adjusts theby means of the .

Depending on the actual requirements, the artifacts aredescribed by specific attributes. For example, the requirementartifact is specified by the commonattributes , ,and . All attributes are described by specificvalues with a suitable physical unit. Furthermore, the causaldependencies between these artifacts and their signal flowdirections are described (cf. Section IV). This entire specificknowledge is represented as factual knowledge (in OWL) inthe KBS and is derived from class knowledge (cf. Section V).Further information regarding the description and theapplication of the requirements in further engineering phasescan be retrieved from [24].

For this project, six main room templates (e.g., single/doubleoffice) have been developed by the planners in the first projectphase. These room templates cover approximately 70% of allrequirements which are to be planned. The requirements re-garding further individual rooms have been derived from theseroom templates by means of global and local adjustments (cf.Section VI).

During the project, the RE tool has shown that it is a helpfulmeans to reduce misunderstandings and communication prob-lems, because of the common semantic described by means ofthe requirement model and the knowledge base of the KBS.Hence, a formalized and uniform room book has been producedin the project. The room-oriented procedure now facilitates theplanning of the BAS, because the predefined room templatesprovide a high degree of reusability. The capabilities of thetool support the planner to cope with a wide set of domain re-quirements. On this basis, a complete elicitation of requirements

for the BAS has been feasible in this project. Furthermore, thedescribed RE approach saved capacities of the planner, whichcould be spend, e.g., on specific applications. As a result, anoptimized BAS can be designed, as achieved in this referenceproject.

VIII. CONCLUSION

Modern building automation systems (BAS), which servedifferent crafts of building technology, tend to show complexrequirements, which are gathered within the requirementsengineering phase and dealt with in the subsequent engineeringphases. In practice, today’s requirements engineering (RE)often results in suboptimal requirements for a BAS, and thussuboptimal implementations.

The RE of BAS can be improved by a systematic “room-ori-ented” procedure (aligned with current planners’ practice) andthe application of a knowledge-based system (KBS) to manageall planner-specific knowledge, as well as all possible differenttypes of requirements. A requirement model for the engineeringof BAS, which defines the possible requirements with all theirattributes and possible values, as well as their causal dependen-cies on other requirements, has been developed. Furthermore,the paper describes a possibility to design a KBS for the REof BAS by means of Semantic Web technologies: room tem-plates can be designed first and instantiated to the correspondingbuilding structure element later on. This procedure, combinedwith the KBS, facilitates an improved RE, as achieved in a ref-erence project: The RE tool has reduced misunderstandings andcommunication problems; furthermore, a formalized and uni-form room book could be created. The room-oriented procedurefacilitates the planning of BAS, because the predefined roomtemplates offer a high degree of reusability. With only six mainroom templates, 70% of all requirements could be modeled, andthe remaining 30% with the provided possibilities to adjust thetemplates. A complete and efficient elicitation of requirementsfor a BAS has shown to be feasible.

ACKNOWLEDGMENT

The authors acknowledge the planning contractor “Hei-demann & Schmidt” for offering the possibility to apply theoutcome of the research project within a project in buildingpractice.

REFERENCES

[1] S. Soucek and D. Loy, “Vertical integration in building automation sys-tems,” in Proc. 4th IEEE Int. Conf. Ind. Inform. (INDIN’07), Vienna,2007, pp. 81–86.

[2] K. Kabitzsch, Open Control Networks, D. Loy, D. Dietrich, and H.Schweinzer, Eds. Boston, MA: Kluwer, 2001, pp. 59–72.

[3] T. Schmidberger, A. Horch, A. Fay, and R. Drath, “Rule based engi-neering of asset management system functionality,” in Proc. 5th Vi-enna Symp. Math. Modelling (Mathmod’06), Vienna, Austria, 2006,pp. 2.1–2.8.

[4] R. Drath, A. Fay, and T. Schmidberger, “Computer aided design andimplementation of interlocking control code,” in Proc. IEEE Int. Symp.Comput.-Aided Control Syst. Design (CACSD’06), Munich, Germany,2006, pp. 2653–2658.

[5] H. Dibowski, J. Ploennings, and K. Kabitzsch, “Automated design ofbuilding automation systems,” IEEE Trans. Ind. Electron., vol. 57, no.11, pp. 3606–3613, Nov. 2010.

730 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 7, NO. 4, NOVEMBER 2011

[6] H. Dibowski, C. Oezluek, J. Ploennigs, and K. Kabitzsch, “Realizingthe automated design of building automation systems,” in Proc.4th IEEE Int. Conf. Ind. Inform. (INDIN’06), Singapore, 2006, pp.251–256.

[7] S. Runde, H. Dibowski, A. Fay, and K. Kabitzsch, “Integrated auto-mated design approach of building automation systems,” in Proc. 13thIEEE Int. Conf. Emerging Technol. Factory Autom. (ETFA’08), Ham-burg, 2008, pp. 1280–1288.

[8] C. Reinisch, W. Granzer, F. Praus, and W. Kastner, “Integration ofheterogeneous building automation systems using ontologies,” in Proc.34th Annu. Conf. IEEE Ind. Electron. Soc. (IECON ’08), Orlando, FL,2008, pp. 2736–2741.

[9] 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.

[10] W. Granzer, F. Praus, and W. Kastner, “Security in building automationsystems,” IEEE Trans. Ind. Electron., vol. 57, no. 11, pp. 3622–3630,Nov. 2010.

[11] T. Novak, A. Treytl, and P. Palensky, “Common approach to func-tional safety and system security in building automation and controlsystems,” in Proc. 12th IEEE Int. Conf. Emerging Technol. FactoryAutom. (ETFA’07), Patras, Greece, 2007, pp. 1141–1148.

[12] F. Praus, W. Granzer, and W. Kastner, “Enhanced control applicationdevelopment in building automation,” in Proc. 6th IEEE Int. Conf. Ind.Inform. (INDIN’09), Cardiff, U.K., 2009, pp. 390–395.

[13] R. A. Gupta and M.-Y. Chow, “Networked control system: Overviewand research trends,” IEEE Trans. Ind. Electron., vol. 57, no. 7, pp.2527–2528, Jul. 2010.

[14] International Organization for Standardization: Buildling automationand control systems (BACS)—Part 3: Functions, ISO 16484–3, 2005.

[15] S. Runde, A. Heidemann, A. Fay, and P. Schmidt, “Engineering ofbuilding automation systems—State-of-the-art, deficits approaches,” inProc. 15th IEEE Int. Conf. Emerging Technol. Factory Autom. (ETFA),Bilbao, Spain, 2010.

[16] P. Marino, F. Poza, M. A. Dominguez, and S. Otero, “Electronics inautomotive engineering: A top-down approach for implementing in-dustrial fieldbus technologies in city buses and coaches,” IEEE Trans.Ind. Electron., vol. 56, no. 2, pp. 589–600, Feb. 2009.

[17] International Organization for Standardization: Industry Founda-tion Classes, Release 2x Platform Specification, (IFC2x Platform),ISO/PAS 16739, 2005.

[18] S. Runde and A. Fay, “Modelling of the requirements of the decentral-ized building automation systems,” in Proc. 6th Vienna Symp. Math.Modelling (Mathmod’09), Vienna, Austria, 2009, pp. 2416–2425.

[19] International Organization for Standardization: Building Automationand Control Systems (BACS)—Part 2: Hardware, ISO 16484-2, 2004.

[20] International Organization for Standardization: Building Automationand Control Systems (BACS)—Part 4: Applications, ISO 16484-4,2011.

[21] National Institute of Standards and Technology: Initial GraphicsExchange Specification, ANS US PRO/IPO-100-1996, 1996. [Online].Available: http://www.uspro.org/documents/IGES5–3_forDown-load.pdf

[22] International Organization for Standardization: Industrial AutomationSystems and Integration—Product Data Representation and Exchange,ISO 10303, 1994.

[23] International Electrotechnical Commission: Representation of ProcessControl Engineering Requests in P&I Diagrams and Data ExchangeBetween P&ID Tools and PCE-CAE Tools, IEC 62424, 2007.

[24] S. Runde, H. Dibowski, A. Fay, and J. Kabitzsch, “Semantic require-ment ontology for the engineering of building automation,” in Proc.IEEE Int. Conf. Emerging Technol. Factory Autom. (ETFA’09), Mal-lorca, 2009, pp. 8–8.

[25] E. A. Feigenbaum, A Personal View of Expert Systems. Looking Backand Looking Ahead. Stanford, CA: Stanford Univ., Knowledge Sys-tems Laboratory, Department of Computer Science, 1992.

[26] F. Puppe, Systematic Introduction to Expert Systems—KnowledgeRepresentations and Problem-Solving Methods. Berlin, Germany:Springer, 1993.

[27] S. Runde, A. Fay, and W.-O. Wutzke, “Knowledge-based requirementengineering of building automation systems by means of semantic webtechnologies,” in Proc. 6th IEEE Int. Conf. Ind. Inform. (INDIN’09),Cardiff, U.K., 2009, pp. 267–272.

[28] T. Berners-Lee, J. Hendler, and O. Lassila, The Semantic Web. CampHill, PA: Scientific American, 2001.

[29] Q. Limbourg, J. Vanderdonckt, B. Michotte, L. Bouillon, M. Florins,and D. Trevisan, “Usixml: A user interface description language forcontext-sensitive user interfaces,” in Proc. ACM AVI’2004 WorkshopDeveloping User Interfaces With XML: Advances on User InterfaceDescription Languages, 2004, pp. 55–62.

[30] S. Runde and A. Fay, “Data exchange format for the engineering ofbuilding automation systems,” in Proc. 13th IEEE Int. Conf. EmergingTechnol. Factory Autom. (ETFA’08), Hamburg, Germany, 2008, pp.303–310.

[31] European Committee for Standardization: Open Data Communicationin Building Automation, Controls and Building Management—ContolNetwork Protocol, EN 14908: , 2009.

[32] European Committee for Standardization: Energy Performance ofBuildings—Impact of Building Automation, Controls an BuildingManagement, DIN 15232, 2007.

[33] W3C Semantic Web Activity, Word Wide Web Consortium (W3C),2008. [Online]. Available: http://www.w3.org/2001/sw/

[34] Semantic Web Case Studies and Use Cases, World Wide Web Consor-tium (W3C), 2009. [Online]. Available: http://www.w3.org/2001/sw/sweo/public/UseCases/

[35] OWL Ontology Web Language, World Wide Web Consortium (W3C),2004. [Online]. Available: http://www.w3.org/TR/owl-features/

[36] SWRL: A Semantic Web Rule Language—Combining OWL andRuleML, World Wide Web Consortium (W3C), 2008. [Online].Available: http://www.w3.org/Submission/SWRL/

[37] SQWRL, Protégé, 2009. [Online]. Available: http://protege.cim3.net/cgi-bin/wiki.pl?SQWRL

[38] The Rule Markup Initiative, RuleML, 2008. [Online]. Available: http://www.ruleml.org/

[39] RIF Working Group, World Wide Web Consortium (W3C),2009. [Online]. Available: http://www.w3.org/2005/rules/wiki/RIF_Working_Group

[40] Jess, The Rule Engine 2008. [Online]. Available: http://www.jessrules.com/jess/index.shtml

[41] SPARQL Query Language for RDF, World Wide Web Consortium(W3C), 2008. [Online]. Available: http://www.w3.org/TR/rdf-sparql-query/

Stefan Runde received the Diploma degree in elec-trical engineering for automation from the Univer-sity of Applied Sciences and Arts, Hannover, Ger-many, and the Ph.D. degree in electrical engineeringfrom the Helmut Schmidt University/University ofthe Federal Armed Forces, Hamburg, Germany, in2011.

Since 2010, he has been a Project Manager for thetopic Future Architectures for Process Automation atthe Department of Advanced Technologies & Stan-dards, Siemens AG. His main research interests are

models, methods and tools for an improved engineering and architecture of au-tomation systems with regard to aspects as quality, efficiency, and simplicity.

Alexander Fay (M’02–SM’07) received theDiploma degree and the Ph.D. degree in electricalengineering and from the Technical Universityof Braunschweig, Germany, in 1995 and 1999,respectively.

After five years at ABB Corporate Research,where he led the Mechatronic Systems Group andlater the Engineering Systems Group in the Cor-porate Research Center, Ladenburg, Germany, hebecame a Professor of Automation Technology atHelmut-Schmidt-University/University of the Fed-

eral Armed Forces, Hamburg, Germany, in 2004. His main research interestsare models and methods for the engineering of large automated systems.

Dr. Fay received the Ring of Honor from The Association of German En-gineers (VDI) in 2009. He is member of the Scientific Advisory Board of theGerman Society for Measurement and Automation (GMA) and Head of its En-gineering and Operation of Automated Facilities Department. He is member ofthe IEEE Industrial Electronics Administration Committee.