UNIVERSITY OF CINCINNATI
______, 20 _____
I,______, hereby submit this as part of the requirements for the degree of:
______in: ______It is entitled: ______
Approved by: ______
A Web-based Commissioning System
A thesis submitted to the
Division of Research and Advanced Studies Of the University of Cincinnati
In partial fulfillment of the Requirements for the degree of
MASTER OF SCIENCE
In the Department of Electrical & Computer Engineering and Computer Science
Of the College of Engineering
2002
by
Lan Ye
B.S., Fudan University, P.R.China, 2000
Committee Chair: Dr. Chia Y. Han
Abstract
This thesis work focuses on the design and implementation of a Web-based building commissioning system in order to help building commissioner go through the whole building commissioning process. The commissioning system provides a framework to extract information from the web server or other file server in a distributed environment, do automatic information acquisition based on commissioning procedure, do analysis based on expert experience or industry standard codes, do verification based on the cooperative construction fields’ requirements, and provide report based on the results of the inspection. This system provides a basis for future expansion when the construction industry standards gradually get more detailed and refined.
The system utilizes the most prevalent web technology. The combination of Java and
XML technology provides the system the desirable “portable code, portable data” feature. Java
Servlet technology used makes the system a thin-client architecture; so the commissioner could use this system by only carrying light portable tools when working on commissioning job.
Acknowledgment
This research was accomplished with great direction and inspiration of Professor Chia
Yung Han of the University of Cincinnati. He suggested me this topic, a web-based commissioning system. His patient advice and most cutting-edge academic vision in the research are greatly appreciated. In addition to this, Dr. Han spent mounts of his own time on this project.
As one of his students, I was greatly impressed and encouraged by his serious and strict spirit in academic research. I sincerely feel I really learn a lot from him in both research ability and academic life style. Without his marvelous advise on this research, I would never have been started and completed.
I would like to acknowledge great help from my friend Jie Situ on the construction information collection. Also, I would like to take this opportunity to express my deep appreciation to my thesis committee: Dr. Carla Purdy and Dr. George Purdy for their critical assistances and tireless teaching on my research and study.
Table of Content
Chapter 1 Introduction …………………………………………………………….…………...4
Chapter 2 Background Review (Existing work and current technology) .…………………..9
2.1 Access smart systems to help do testing, inspection and verification ………….………...9
2.2 The system provides easy-to-use commissioning tools for end users …………………..10
2.3 The Commissioning Knowledge Management system ………………………………….11
2.4 Web-based technology used in the Commissioning Knowledge Management System ...13
2.4.1 Java Technology …………………………………………………………………..13
2.4.2 Java Servlet Technology …………………………………………………………..13
2.4.3 XML Approach ……………………………………………………………………14
2.4.4 JDBC Database Technology ………………………………………………………15
2.4.5 Component Technology ……………………………………………….....………..15
2.4.6 JAXB Approach ……………………………………………………….....………..15
2.4.7 Converting the XML Data to HTML with XSLT …………………………………16
Chapter 3 Problem Statement ……………………………………………………….………..18
Chapter 4 Proposed Solution / Supposed Architecture ……………………………………...20
4.1 Proposed Commissioning System ………………………………………………………20
4.2 Developing Environment ………………………………………………………………..23
4.3 Web Technology Used …………………………………………………………………..24
4.4 Commissioning System Control Interface Design……………………………………….26
Chapter 5 Implementation Details ……………………………………………………………28
5.1 System War Files and Deployment …………………………………………….………..28
5.2 Modeling Databases in XML ………………………………………………...... ………..32
1 5.3 Creating the XML object class ………………………………………………………… 35
5.4 Developing the Data Access Object (DAO) …………………………………………… 37
5.5 Developing a Servlet for HTTP Access ……………………………………...... ………..38
Chapter 6 Illustration Cases & Discussion ………………………………………….………. 42
6.1 Define Commission Plan ………………………………………………………………..42
6.2 Generate Commissioning Guideline …………………………………………………….44
6.3 Generate Component Check Sheet and Report ………………………………………….45
Chapter 7 Conclusion + Future Work ………………………………………………………..48
Bibliography ……………………………………………………………………………………51
2 Table of Figure
Figure 1.1 Building commissioning coordination process ..……………………………………...6
Figure 2.1 XML marshalling and unmarshalling ……………………………………………….16
Figure 2.2 XML Transformation Pattern ………………………………………………………..17
Figure 4.1 Commissioning System Architecture ………………………………………………..21
Figure 4.2 Client-Server Web Schemas …………………………………………………………23
Figure 4.3 XML Rule Transformation …………………………………………………………..24
Figure 4.4 Data Access Object Design Pattern ………………………………………………….25
Figure 4.5 Apply XSLT Style sheet to the output file …………………………………………..26
Figure 5.1 Web Application Files Structure ………………………………………….…………29
Figure 5.2 Rule Database Schema ………………………………………………………………33
Figure 5.3 Check Code Database Schema ………………………………………………………33
Figure 5.4 Check Procedure Database Schema …………………………………………………34
Figure 6.1 Building Number Control List ………………………………………………………42
Figure 6.2 Rule Contributor Control List ……………………………………………………….43
Figure 6.3 Inspection Type Control List ……………………………………………….………..43
Figure 6.4 General Commission Check Sheet …………………………………………………..44
Figure 6.5 Fire-protective Element Check Sheet ………………………………………………..45
Figure 6.6 Fire Protective Commission Report …………………………………………………46
Figure 6.7 Plumbing element check sheet generated with another XSLT style sheet …………..47
Figure 7.1 Two Database Solution approaches ………………………………………………….48
3 Chapter 1 Introduction
According to the National Environmental Balancing Bureau [1], building commissioning is a
process of an authorization to act in a prescribed manner to ready all building mechanical and
electrical systems for active service. Essentially, it is the process of systematically evaluating
building equipment, subsystems, and operation and maintenance procedures, and the
performance of all building components to ensure that they function efficiently as a system [2].
Moreover, commissioning determines if a building or facility provides a safe, efficient, and comfortable shelter conducive to the activities for which it is used. Integrating commissioning into the design and post-construction phases of new buildings helps the whole building system operate efficiently.
A good commissioning can benefit a lot to the construction process. Building
Commissioning Association identified commissioning process a critical and valuable part in
construction industry [3]. First, It can provide better building operation. Commissioning assures
that retrofit and design specifications and drawings are updated to reflect actual modifications to
the building ("as-installed" and "as-built") and that O&M manuals have been delivered and can be easily understood by those who use them. Commissioning provides operation and maintenance personnel with the knowledge and training to operate building equipment properly
and generally perform their responsibilities in a manner that will increase operational savings. It
schedules activities that maintain and extend equipment life. Secondly, through commissioning
process, the construction can have improved design and construction. Commissioning results in
greater cooperation among professionals involved in the retrofit and permits a cross-check of the
performance of a building's equipment and systems. This ultimately results in fewer call-backs
and fewer construction litigation problems. Thirdly, it can reduce the construction liability.
4 Commissioning can decrease complaints and consumer construction injuries, and lower the risk of post-construction legal action stemming from conditions like indoor environmental pollution.
Commissioning buildings usually covers air conditioning, electrical, communications, security and fire management systems and their controls. They may also include other systems and components, particularly if they are unusual or complex.
According to NEBB’s operational procedures [4], the building commissioning process consists of five main steps. They are: 1) commission plan preparation, 2) plan field coordination,
3) functional performance testing, 4) acceptance and post acceptance. They are detailed described as following:
Commission plan preparation: Review plan provided in specifications or developed by the NEBB system commissioning administrator, which is specific to each project.
Commissioning plan field coordination: Review project commissioning plan with the owner’s representative, architects or design team, construction engineers, contractors, selected vendors, project managers and any other involved parties. These separate parties coordinate and generate a commission guideline. Figure 1.1 shows the relationships of these parties in the building commissioning process. During the commissioning process, except for the generic procedures like general windows inspection defined by the industry standard, the commissioner also needs to do specific inspection on the customized features. Such as windows may be required by the owner to be made of aluminum. It is necessary that these different parties work smoothly and efficiently.
5 Regional Commissioning Code
Construction Architecture Engineers Owner or Designer (Comply to the Owner's (Comply to Contractors Builders drawing and Representative owner's construction requirement) specification)
Building Drawings Commission Guidelines
Commissioning Commissioning Checklist Vendor Level
Commissioning Report (Accepted or not)
Figure 1.1 Building commissioning coordination process
Functional performance testing: Coordinate, write, verify and report on applicable electrical and mechanical systems and subsystems to determine whether they operate as intended. The tests and checks should verify items such as: All construction dirt and debris have been removed and that all systems (where required) have been cleaned; Check sheets have been completed on each system and component of each applicable building system to ensure compliance with specifications and contract document; All equipment and systems have been put into operation and functioning normally; Testing-adjusting-balancing work (where required) has been completed; Operating characteristics are compared to expected performance of equipment,
6 subsystems and systems; All interactions between equipment, subsystems and systems are functioning properly; Test results are evaluated and modifications to equipment and system are made(where required) with resultant retests; All test data and information are recorded on forms provided in the commissioning plan or approved by building owner.
Acceptance: Submit commissioning report and all required documentation, including systems commissioning plan, functional performance test check sheets, as-built drawing, updated documents and specifications, equipment instructions and operation and maintenance manuals,
Report should note uncorrected (or uncorrectable) variations from design/specification.
Post acceptance: Monitor preventive maintenance program (where required). Address all system, subsystem and equipment operational and interaction deficiencies that may arise.
An average home inspection will take 2 to 3 days, depending on the size of the house.
Larger and more complex houses may take longer for the inspector to evaluate it completely and accurately, while the quickest commissioning might take only 2-3 hours. Another factor that may affect the inspection time is the condition of the components at the property. If the house and appliances have not been properly maintained, the inspector may need additional time to explain to the buyer what options they may have to either maintain or replace these items.
While offering many obvious benefits to the owner, commissioning requires an investment of both time and money. This investment can become quite significant depending on the criticality and complexity of the involved systems. In fact, many buildings do not go through a formal commissioning process unless it is required by a detailed specification or by a code body. This needs to change and technology can play a critical role in reducing both the time and cost of commissioning building systems.
7 A major step of the building commissioning process is the site inspection. Traditionally, an inspector carries engineering drawings and other paper documents to the site, conducts inspection following set of prescribed procedures, and records inspection results manually. At the end, reports of the inspection must be generated. It takes too much time to gather documents and to read all the procedures for commissioning. And it is almost impossible to do intelligent analysis on the tremendous amount of data without a database. Thus, it is highly desirable to automate some of the procedures of the commissioning process.
The desired commissioning system focus on the needs of inspector. It should be able to help inspectors reduce the burden in checking every detail of every requirement and specification. This system should be able to help store data, organize data and manage data.
Also, the system should be flexible, updateable and expansible for future development. The data could come from many sources in a distributed environment. On the front end, this project is to help commissioner intelligently generate a commissioning guideline based on the intending commission time, or the commission requirement from a specified party. Then after the commissioner finished fulfilling the generated check sheet, this system can verify and test the real construction based on the commission specification, and finally produce a report to the owner.
8 Chapter 2 Background Review
Smart control devices, easy to use commissioning tools and advanced building automation system capabilities can all be used to help automate the commissioning process as well as to collect, analyze and report system performance data. The time has come to let technology do its share of the heavy lifting associated with building commissioning, and provide a means for verifying and improving system performance at the lowest cost. This chapter reviews the smart control devices, major commissioning tools, and some current technologies used in building commissioning.
2.1 Smart systems access for testing, inspection and verification
There are already some component-related smart systems to facilitate the commissioning process [5]. Most of these systems could also save time and money across the entire range of building mechanical and electrical systems.
The first step of the systems commissioning process involves the verification of installed devices including sensors, actuators and controllers. To support the installer in being able to verify proper operation during installation, a handheld tool based on a popular personal digital assistant (PDA) has been developed to automate and streamline common verification tests, and records the results of the tests in a computer-readable file.
Commissioning sometimes needs I/O device like actuators calibration. This involves manually calibrating devices using reference instrumentation, then adjusting device settings or software configuration parameters to match the reference values. some recently introduced electric actuators include self-calibration capabilities that automatically determine their own zero and span adjustments via a self-test procedure initiated during device power-up or on demand.
9 Sequence verification typically involves downloading the DDC controller application
programs and then verifying the proper sequence of operations. It is a program written using
finite state machines. Sophisticated applications of this technology include special states (e.g.,
commissioning) that eliminate the normal state transition delays in order to accelerate sequence
verification at the job-site.
At the heart of commissioning, a knowledge management system is desirable to be used
to perform functional testing which is a critical and time-consuming process. It would benefit a
lot if the above smart devices could incorporate into this central system.
2.2 Easy-to-use commissioning tools for end users
Some commission company view web access as an "accessory" to their standalone
software, Their system will display key sensor readings on a web page, and may let the operator
adjust a point or two, but for anything more complex the operator needs to use the proprietary
local software [6]. System configuration, schedules, trending, reports, and other "normal"
features are not available through their web interface. When a company takes this approach, each
new feature that is added to the web interface represents a significant additional workload on the
developers. It soon becomes natural for them to ask "why do users need to do this through the
web?" Since their proprietary local software already provide this tool. It's easy for them to decide it isn't necessary to provide this feature over the web. As a result, their web system's feature set tends to remain very limited. Alternatively, some companies are trying to develop web systems that replace their proprietary workstation software. Not surprisingly, the web-based commissioning systems offered by these companies provide a much richer environment than those that are merely intended as an adjunct to a traditional workstation-based system. Trending, scheduling, alarming, reports, program changes, memory downloads - all can be accomplished
10 through a browser. It also follows that these systems provide a better platform to support the new
generation of "gadgets," such as WAP cell phones, because these devices are also based on a
browser interface.
In this approach, the system could provide easy-to-use commissioning tools like wired or
wireless web-browser device. Such as desktop or laptop, or pocket PC or tablet PC.
2.3 The Commissioning Knowledge Management system
Building operators, mechanics, and design professionals have traditionally relied on
"hard copy" written documents in the form of three ring binders or architectural, mechanical,
electrical or plumbing drawings. These documents have a life of their own and are typically
relied upon at different times and in different ways during the life cycle of a building -- often
from its original design/construction to startup or commissioning, and renovation/rehabilitation
work phases.
These documents can be generic or site specific. In the design phase they are used by the
design professional as selection or engineering manuals, during construction as installation manuals by the contractor, and afterwards as operating and maintenance manuals by the maintenance mechanic or service technician.
Over the last ten years or so many of these types of documents have been developed, made available and distributed in electronic form. There has been a migration from hard copy documents to CDs, or "read only" electronic books viewable via the Internet using web browsers via hypertext links or uniform resource locators (URLs). This offers instant access. Documents are now able to stand the test of time and can be reprinted if necessary when needed.
Thus, a knowledge management (KM) system would be very much desirable. This knowledge management system can take information from many sources including a scheduled
11 and preventive maintenance system, links to/from web-enabled direct smart digital control systems, facility asset surveys as well as long range capital planning -- all of this under the concept of living documents.
Actually there are operational web-based commissioning knowledge management systems in use today [7]. Web-based commissioning systems are not different to other systems in this regard. The degree to which a system supports standard protocols has a dramatic effect on its ability to interact with a control system made by a different manufacturer, and it also affects the freedom the user has to compare manufacturers when the system needs to be modified or expanded. Thus a knowledge management system with highest degree open to standard protocol is the industry current developing approach.
Another design focus of the Knowledge Management System developing is the methods used to generate the web pages [11]. There are many web authoring tools on the market today that can be used to generate web pages for a building automation system. The problem is that hand crafting individual web pages for even a moderately sized commission system is a very time consuming process. The commission company is ultimately the one who pays for the labor required to create these pages, whether the system provider creates these pages as part of the system design or merely gives the tools to the user so he can create his own pages. Maintenance can also become a costly proposition when hand crafted pages are used. If every change to a sequence of processing requires manual editing of the associated web pages, costs can skyrocket.
Also, there is always the danger of having the web pages get out of sync with the actual commission process. A better approach is to develop a system where the web pages are automatically generated by the same tools that are used to engineer the whole system. Write a program for, say, a VAV Air Handling Unit and the web page that provides the user interface to
12 this unit [12], which is created automatically. Make a change to this program and the web page is automatically updated to reflect this change. Here again, systems in which the browser serves as the primary user interface may have an advantage because these systems are designed from the ground up to be web-based. For these systems, the web pages are not an afterthought - they are an integral part of the system design. Since the providers of these systems must provide a way to access every single element of their system through a browser, it is in their own best interest to automate the creation of web pages.
2.4 Web-based technology used in the Commissioning KM
2.4.1 Java Technology
Java based technology provides a good portable features which could make "write once, run anywhere" possible. Also, The Java API is a large collection of ready-made software components that provide many useful capabilities. With java language, the system could be set up with less and better codes, and avoid platform dependencies with 100% pure java.
2.4.2 Java Servlet Technology
Now servlet is a better replacement to CGI. The servlet engine can run for as long as the web server runs, servlets can be loaded into memory once and kept around for subsequent requests. The JVM simply loads the servlet objects into memory, hanging on to the references for as long as the web application runs. The persistent nature of servlets results in two additional benefits, both of which push servlets well beyond the capabilities of basic CGI. First, state information can be preserved in memory for long periods of time, even though the browser loses its connection to the web server. Secondly, since java has built-in threading capability, it is
13 possible for numerous clients to share the same servlet instance. Creating additional threads is far more efficient than spawning additional external processes, making servlets very good performers.
Also a key advantage to using servlets is the thin-client interface. The servlets handle the request on the server side and respond by generating an HTML page dynamically. This lowers the requirement on the client browser. The browser only has to provide support of HTML. As a result, there is zero client-side administration.
2.4.3 XML Approach
XML stands for Extensible Markup Language. The most attractive feature of XML is its portability and an unprecedented degree of interoperability. On one hand, with XML, developers can get portable data and the combination of Java and XML can provide an excellent result of
“portable code, portable data”. On the other hand, XML allows high interoperability. The various furniture chains can agree upon a certain set of constraints for XML, and then exchange data in those formats; they get all the advantages of XML (like portability), as well as the ability to apply their business knowledge to the data being exchanged. With its interoperability, XML- based application supports all kinds of document formats like HTML, WML (Wireless Markup
Language), or as binary formats like Adobe’s PDF (Portable Document Format) which are highly desirable in our system.
2.4.4 JDBC Database Technology
The JDBC API allows developers to take advantage of the Java platform's "Write Once,
Run Anywhere” capabilities for industrial strength, cross-platform applications that require access to enterprise data. With a JDBC technology-enabled driver, a developer can easily
14 connect all corporate data even in a heterogeneous environment. Also, JDBC Technology lets programmer send SQL statements to a database and process the returned results. Programmer could get uniform access to a wide range of relational databases and a common base upon which database tools can be built.
2.4.5 Component Technology
Component technology is the future extension of the object-oriented programming technique. It provides practical technology for automated semantic based composition. It automatically compose independently developed software components and gives easy interoperation in any functionally compatible context. It greatly reduces the time of software developing and testing and increases the components’ reusability.
2.4.6 JAXB Approach
JAXB makes XML easy to use by compiling an XML schema (currently only DTDs are supported) into one or more Java technology classes. The generated classes handle all the details of XML parsing and formatting. Similarly, the generated classes ensure that the constraints expressed in the schema are enforced in the resulting methods and Java technology language data types.
In many cases, the generated classes are much more efficient than using a SAX (Simple
API for XML) parser or an implementation of the DOM (Document Object Model) API. They are, generally, more efficient, because using the generated classes is usually faster and, perhaps most importantly, often requires a much smaller footprint in memory than a generic parser.
JAXB provides a framework for representing XML documents as java objects. This technique is referred as unmarshaling. The JAXB also provides the capability to generate XML
15 documents from Java objects, which are referred to as marshalling. These operations are showed
in Figure 2.1 below:
Figure 2.1 XML marshalling and unmarshalling
With these basic JAXB technologies, the system could be expanded easily. The system maintainers just need to revise some elements or attributes in DTD (Data Type Definition, which is used to define a specific category of XML documents) or XML schema. With this convenient feature, some element objects could be created automatically.
2.4.7 Converting the XML Data to HTML with XSLT
XSLT is explicitly designed for XML transformation [15]. With XSLT, XML data can be transformed into any other text format, including HTML, XHTML, WML, and even unexpected formats such as java source code.
An XSLT processor, such as Apache’s Xalan, which was used here, performs transformations using one or more XSLT style sheets, which are also XML documents. XSLT can be utilized on the web tier while web browsers on the client tier deal only with HTML.
16 HTML XSLT Processor XML Files Output Data
Database
XSLT Stylesheett
Figure 2.2 XML Transformation Pattern
17 Chapter 3 Problem Statement
Our purpose is to design and implement a computer system to assist people in the building commissioning process. It should automate the several critical and time-consuming steps in building commissioning process. This knowledge management tool should be able to capture and reuse the related rule based on the requirements and construction specification.
The system should be able to incorporate all kinds of document type, like CAD drawings,
HTML files, Text files, XML commission rules, etc. Thus, the system could incorporate resources from many different construction fields.
The schema of this system should be run on a web server and the resources are accessible through Internet or intranet. So the commissioner could access the system by a portable, PDA through standard client side web browser. And a web-based knowledge management system could also provide enough flexibility for future expansion.
The Main problem here is to automatically generate a commissioning guideline based on different requirement while complying with the regional construction code. After that, the system could create a specification procedure to the inspector. Finally, after the inspector fulfill the commission check sheet; a commission report is automatically generated based on the result of commission.
We have the assumption that the system proactively offers relevant information learned from those coordination parties to commissioners, also the logic of reasoning and process is the same.
The system can provide different levels of commissioning guidelines to commissioner:
Timing-based
18 1. Fast commissioning
2. Thorough commissioning
3. Re-commissioning (retro-commissioning or adjusting the performance of existing
buildings)
Different parties
1. Owner’s representative requirement
2. Architecture requirement
3. Engineer requirement
4. Consultant requirement
5. Vendor requirement
6. Regional specification
It is also required that the system is extendable. In addition to this basic schema, the system could provide more commission selections if further requirement arise.
19 Chapter 4 Proposed Solution
This chapter describes a proposed solution to solve the problem. A distribute system architecture for the commissioning system is proposed and the techniques used to implement are presented.
4.1 Proposed Commissioning System
The system architecture is 3-tier client server architecture. The building commissioning involves many different parties. They include building owner, architect, engineers, contractors and sub-contractors, vendors, builders, and others such as local governing institutions. All these parties interact on either Internet or intranet through the TCP/IP, the Internet protocol.
At client site, a generic web browser interface is provided to the users through either a wired or wireless connection. The thin client simply submits check sheet generation request, fulfills the form, submits the commissioning results, and finally gets the report. The system user at the client side is usually the commissioner who is in charge of doing the commissioning.
The middle-tier workstation is the server, which is capable of serving requests about a particular building or some particular specification. It performs three main tasks. The first task is to generate a check sheet intelligently. The second task the server does is to verify that the building construction fulfills the general codes and particular contract codes. The third task is to generate a report to commissioner.
At the back end of this architecture, a local relational database can be accessed to the server. The database stores some simple relations among the commissioning rules and provides the location of the commission documents for either servers or clients to access.
Multiple users work cooperatively and use file servers to provide document resources needed for commissioning. These resources could be in various formats and located in a
20 distributed environment. Still these files could be retrieved on the basis of their URL. The client and server could access these resources by HTTP protocol through Internet or intranet. The overall system architecture is shown in Figure 4.1.
Sub-Contractors Engineer's Drawing and Architecture's Design Drawing and Design Contractors Builders
Vendors Owner's CheckList Internet
Standard Commissioning Code
Wired Clients
Relational Database Wireless Clients Web Server
Figure 4.1 Commissioning System Architecture
Through this architecture, a variety of interactions take place. The major phases of
interaction in the proposed system consist of the following:
• Wired or wireless clients submit commission query to the web server through net cloud
• The system at the server retrieves related commission rules for the query from local relational
database
21 • The system analyzes the rules and obtains the URL of desired sources
• The system returns the commissioning guidelines and checklist (including URL or
documents) to clients
• Commissioners perform the commissioning tasks according to the check sheets, record the
results, and submit the sheets back to server.
• The system analyzes the results and returns a commissioning report to clients
At the client side, the system gathers the commissioning requirements from the commissioner and sends the request to the server. On the server side the system uses Java servlets to process the query and retrieves related records from database.
In the middle layer, the server analyzes the records retrieved from database, and forms a content tree object, and then sends this object to the servlets. The java servlet converts the set of content tree objects into XML, and then applies the desired XSLT style sheet to the result XML file. Finally, it sends them back to the client side applet.
The information needed for commissioning is spread in many different sites and in many different format types. They include CAD drawings, technical specifications, and bills of quantities, contracts and notes. To allow access through Internet, this requires that the people involved in the process proactively upload their information to the system file system.
After the commissioner gets the inspection checklist, proper links are then provided for him/her to retrieve the inspection procedures based on the information provided. The commissioner goes to the designated building site, carries out the inspection tasks, collects data, fulfills the check sheet, and then submits the results to the system. The system processes the data
22 collected from the field and generates a final report to the commissioner and others. This client- server schema is illustrated in Figure 4.2.
Thin Clients
Download commission files Web Browser File Server
XML/HTML Query Internet rule
File Server Java Servlet
Retrieve set of rules and convert into XML Access Database Web Server
Figure 4.2 Client-Server Web Schemas
4.2 Developing Environment
The system is developed on the MS-Windows 2000 platform. Although this application is developed on MS-Windows-based environment, it could also be ported to other kinds of systems like Unix, Mac. This great feature is provided by the portable nature of Java and XML technology. The Java 2 SDK Standard Edition is used for program development. This package includes both XML processing and JDBC supports.
23 The Web server used is Apache Tomcat 4.0, which is the servlet container that is used in the official Reference Implementation for the Java Servlets technologies.
XML spy v.3.5 is an Integrated Development Environment (IDE) for the eXtensible
Markup Language (XML) and contains many useful functions that can simplify typical XML editing tasks. It is used to edit XML files, XSLT style sheets, DTD schema and other XML applicable files.
Microsoft Access 2000 Database is installed as the DBMS used in this application. So the system will use ODBC drivers after loading a JDBC-ODBC Bridge Driver.
4.3 Web Technology Used
Other Web application technologies used for this system include JAXB binding, data access object (DAO) and XSLT using.
JAXB binding is used to realize the transformation of XML rules and XML content object.
By using JAXB binding technique, the system extracts rules from the relational database, and converts the rules into XML files. Then through unmarshalling, the XML files are turned into a content object. The program could access the content of the XML by using automatically generated methods or customized methods of the objects. Again by marshalling, the XML files could be output to the user. This process is illustrated as Figure 4.3.
Figure 4.3 XML Rule Transformation
24 Data Access Object is used to provide access to the backend database. The goal of this
DAO design pattern is to provide a higher level of abstraction for database access. This DAO
encapsulates the complex JDBC and SQL calls. The DAO provides access to the backend
database via public methods. The DAO converts a result set to a collection of objects. The
objects model the data stored in the database. The application interaction with a DAO is shown
as Figure 4.4
Database
Figure 4.4 Data Access Object Design Pattern
By using a DAO, the implementation details of the database are hidden from the application clients. The implementation details include the database schema and database vendor. This follows closely with the design principle of encapsulation. A benefit of using the
DAO is improved application maintenance. If the database schema changes, such as a column name in the rule table being modified, developers only have to update the DAO. No modifications are required to the client programs. Also, if the developer decides to change the database implementation from one vendor to another (from Access Database to SQL server), modifications are only required to the DAO. The clients can continue to use the DAO without any modification.
XML documents need to be converted into HTML for browser display. The display formatting is done through XSLT style sheet. A customized XSLT style sheet to applied to the
XML rules to create the desired output. By using XSLT transformation, the user could have a
25 coherent and customized interface, and the XML rule could be converted into commissioning guideline in the HTML format.
HTML/XML/ Adobe/other file format Data File Server HTML/ XHTML XSLT Processor Files Output
XML Data
Database
XSLT XSLT XSLT Style Style Style sheet sheet sheet
Figure 4.5 Apply XSLT Style sheet to the output file
Figure 4.5 above shows the use of XSLT in the system. Developers could generate several kinds of XSLT style sheet for different interface needed or for different resource formats like HTML, XML or Adobe files. The resources retrieved from distributed environment are sent to the XSLT processor. The processor performs the transformation from raw source format to
HTML/XHTML output format.
4.4 Commissioning System Control Interface Design
The commissioning system provides three basic controls for commissioner to process their query submissions. One is that the user can use the system to generate commission guideline based on commission time or occupancy phase; the second is based on the different
26 cooperative fields’ responsibility; and the third is based on a specified building number. Here, it is assumed the commissioner only needs to retrieve information for one building.
This commissioning system provides following cooperative entities involved in the architect/engineer/construction/facilities management (A/E/C/FM) industry as resource selection:
Owner’s representative, Architect, Engineer, Contractor, Vendor, and local or federal governmental agencies.
And the system also provides following three major commission time as inspection level selection: Short-term, Through, and Retro-commissioning (5 years, 10 years).
In addition to these two controls the system provided, it could automatically extract all building numbers. These building numbers are used to represent the existing building information stored in the database. The commissioner can pick his desired inspection building, and the commission rule information related to this building could be retrieved after he submits the commission query.
27 Chapter 5 Implementation Details
This chapter covers the implementation details. It first presents the System WAR (Web
Application Archive) Files, and shows how it is deployed in an application. The second major
implementation detail is on modeling database in XML. The third major detail is how to create the XML object class using JAXB Binding Schema. DAO will be explained in the fourth section,
followed by the details on how to create servlets for HTTP access.
5.1 System War Files and Deployment
In the servlet model, all the necessary information for the application is contained in a
package based on a specific format, the Web Application Archive (WAR) file format. WAR files
are put into the servlet container and serve the units of deployment. Once the server is launched,
these files are deployed. WAR files enable portability across a wide range of servlet containers
regardless of the vendor. Fig. 5-1 (a) has a generic structure of such package and (b) presents a
WAR structure for the proposed commissioning applications in this thesis work.
As shown in Figure 5.1, the file structure contains both the basic directories and files for a generic WAR file and some application dependent directories and files. The generic files and directories include the index.html file and the WEB-INF directory, which contains all the necessary subdirectories, both generic and application specific ones.
The major directories/subdirectories and files are listed below:
28 Commission.war
index.html
WEB-INF
web.xml
classes
jaxb
......
drawings
Database
xml
xslt
check_code
check_procedures
lib
Figure 5.1 Web Application Files Structure
• Commission.war: The document root directory is publicly accessible and may contain
directories. Just like a normal web site. The index.html file contains the “home page” for this
war file.
• WEB-INF directory: the WEB-INF directory and all sub-directories are not directly visible to
clients (i.e., web browsers), but can be accessed from the codes.
• Web.xml: This file is the deployment descriptor, which is always placed directly in the WEB-
INF directory of the web application. It provides the servlet container with complete
configuration information about a web application.
29 • Classes directory: This classes directory is automatically added by the web server to the
CLASSPATH for this particular web application.
• jaxb directory: This subdirectory resides under the classes directory.
• Lib directory: This directory contains all JAR files and its path is also added to the
CLASSPATH.
The more application-specific directories can be included as well:
• XML directory: This directory stores the XML-based application rule files that are actively
uploaded by cooperative construction fields.
• XSLT directory: This directory stores the XSLT style sheets that are applicable to the
generated XML files.
• Database directory: Store the RuleDSN database that can be accessed with JDBC-ODBC
driver bridge.
• Drawings directory: store all the commissioning related drawings.
• Check_code directory: Store the industry standard inspection codes.
• Procedure_code directory: Store the industry standard inspection procedures
Once the information for an application is defined, it can be arranged all the files and directories into this WAR file structure format. A WAR file, e.g., commission.war, is then created with the following command from the directory that contains index.html:
jar –cvfM ../commission.war
The commission.war file is then created in the parent directory.
Although clients cannot see any of these directories and files directly, the servlet can access these resources programmatically and then deliver that content. In the deployment of the war file, a Web Application Deployment Descriptor is needed. It defines everything about the
30 application that a server needs to know. Mainly, it tells the server the mapping of the URL of a servlet and the servlet class in the servlet container. In this application, the deployment descriptor file is as follows:
31
Note that a servlet definition lists the fully qualified package name, the class name of the
servlet class, and a name for that servlet. This name can be used whenever another section in the
deployment descriptor wishes to reference this particular servlet.
In the example above, the servlet-mapping uses the servlet-name CommissionServlet in
order to associate a url-pattern with this particular servlet. This url-Pattern is the address that
users type into their web browsers when they need to access this servlet. In this example, the
URL to CommissionServlet is:
http://hostname:port/commission/commission
The hostname:port is the form that Tomcat usually defaults to. With application on the
same server system, it is typically used as localhost: 8080, although Tomcat can be configured to run on any port number.
5.2 Modeling Databases in XML
In this section, the backend database schema and its corresponding front end XML mapping are
presented. When we model a database, we provide an external representation, the schema, of the
database contents. The content of a commissioning system may consist of many commissioning
rules. Each rule may contain a variety of information, such as the rule-id, and some of the basic
information on the building and procedure for commissioning. The RuleDSN database, in
Access relational database implementation, consists of three tables: Commission_rule.mdb,
Code_table.mdb, and Procedure_table.mdb. Figures 5.2 to 5.4 show these tables.
32 Figure 5.2 shows the basic database schema for the commissioning rule. Rule_number is
the primary key to specify a piece of rule. Building_number identifies the object the rule applies
to. Rule_contributor shows the provider of this rule. Rule_level is an integer number mapping to
one inspection type. Rule_content is the most important field of a rule that stores the URL
location of the real rule document. Drawing stores the URL location of the desired drawing.
Check_code and Procedure set up the connection of this rule with the industry standard by
mapping to a code number or procedure number.
Field Name Data Type
Rule_number Text
Building_number Text
Rule_contributor Test
Rule_level Number
Rule_content Text
Drawing Text
Check_code Text
Procedure Text
Figure 5.2 Rule Database Schema: Commission_rule.mdb
Figure 5.3 shows the industry standard check code stored in the database. Code_number
is the primary key to specify the unique piece of code. At the same time, it maps to the
Check_code field of Commission_rule.mdb. Code_content specifies the URL location of the code content.
Field Name Data Type
Code_number Text
Code_name Text
Code_content Text
Figure 5.3 Check Code Database Schema: Code_table.mdb
33 Figure 5.4 shows the industry standard inspection procedure stored in the Access
relational database. Procedure_number is the primary key to specify the unique piece of
procedure. Like Code_number above, it maps to the procedure field of Commission_rule.mdb.
Procedure_content specifies the URL location of the procedure content.
Field Name Data Type
Procedure_number Text
Procedure_name Text
Procedure_content Text
Figure 5.4 Check Procedure Database Schema: Procedure_table.mdb
This RuleDSN database is accessed by DAO (Data Access Object), which will be
described later.
The information that is collected from the database to be used for commissioning is to be
represented in XML form. An example rule XML document is illustrated below. This output
XML document describes the rule property according to the records retrieved from
Commission_rule table in RuleDSN database.
XML Rule example:
34 The rule_content, drawing elements represent the URL of the source rule document that
can map to the same field in Commission_rule table. And the check_code, procedure elements
specify the code number and procedure number in the other two tables.
5.3 Creating the XML object class
A XML object class can be generated automatically by using JAXB binding technique. It
involves three major steps. Firstly, a DTD (data type description) file is created. Secondly, a
JAXB binding schema for the rule is needed. Lastly, run the JAXB schema compiler with the xjc command with both the .dtd and .xjs files to generate the Java source files based on rule schema.
Following illustrates the way it is created.
A DTD (data type description), which is used to describe the structure of a XML file format, needs to be created. Based on the structure of the commissioning rule in the XML document format, a rule schema is created as following.
Commission_rule.dtd
This schema defines elements in the commission rule and the relationship of those
elements. A commission_rule_list could contain one to multiple commission_rule elements.
Commission_rule has rule_number, building_number, rule_contributor, rule_content, rule_level,
drawing, check_code children elements. These elements are all defined as character data
elements with #PCDATA.
35 After the DTD is defined for the commission rule, a JAXB binding schema for the rule is
needed. The JAXB binding schema is an XML document that contains instructions on how to
bind a DTD to java class. Following shows the binding schema used in this system.
Commission_rule.xjs
This schema allows developers to define a conversion rule for elements. Developers can
specify that a given element should be converted to a java primitive type, such as value or class.
For example, the commission_rule_list element will be converted into a CommissionRuleList
class; the rule_level element will be converted into an integer typed private attribute in the class.
To generate the Java source files based on rule schema, both the DTD file commission_rule.dtd and the binding schema commission_rule.xjs are passed to the JAXB schema compiler with the xjc command:
java com.sun.tools.xjc.Main commission_rule.dtd commission_rule.xjs –d /jaxb
Then the following java source files are created: CommissionRuleList.java and
CommissionRule.java. The former file models the
The source code for CommissionRule.java contains private data members for the elements defined in
36 properties. Also the program can validate the object by calling the validateThis() method. This
method is generated based on the DTD. The contents of the object can be verified to adhere to
the grammar rules of the DTD by this method. The validate() method is useful if the contents of the CommissionRule object are modified using the setter method. It is also useful when the developer needs to construct a CommissionRule object from scratch. Finally, the
CommissionRule class contains methods to marshal and unmarshal the content.
5.4 Developing the Data Access Object (DAO)
The means to make connection to database is presented here. The proposed solution
utilizes the Data Access Object called RuleDAO to accomplish this. The class RuleDAO defines
a data member for a java.sql.connection object. This will serve as the connection to the database.
RuleDAO also provides a constructor, where the client program supplies the appropriate
JDBC parameters. This constructor provides flexibility and would be typically used in a
distributed computing environment. A remote server object could instantiate the DAO using
server-side parameters. The DAO would then be available remotely via a server-side proxy
interface. In this scenario, the client application would simply look up the remote object and
invoke its methods. The client object is not involved with the construction of the DAO and therefore is shielded from the implementation details of JDBC driver name, URL, and so on.
Following shows the constructor used in this RuleDAO.
public RuleDAO(String driverName, String dbUrl, String user, String pass) throws DAOException {
try { // Load the driver log("Loading driver: " + driverName); Class.forName(driverName);
// Get a connection log("Connecting to the database: " + dbUrl);
37 log("User id: " + user); myConn = DriverManager.getConnection (dbUrl, user, pass);
log("DB connection successful at " + new java.util.Date()); } catch (Exception exc) { throw new DAOException(exc); } }
Once the RuleDAO Data Access Object is constructed, the clients can retrieve data from the database by calling the getCommissionRule() method. This method queries the database and returns a collection of CommissionRule object. This method encapsulates the SQL statements.
This is an example of a piece of SQL statement executed in the system:
SELECT rule_number, rule_content, drawing, check_code FROM commission_rule WHERE building_number LIKE " + buildingnumberQuote + " AND rule_level LIKE " + rulelevelQuote + " AND rule_contributor LIKE " + rulecontributorQuote;
After SQL execution, the method processes the result set to build a collection of
CommissionRule objects. This method creates an instance of a CommissionRule object using the default constructor. It then populates the object based on information from the result set. This method actually handles the mapping between the database fields and the XML elements.
After the database access is available, various methods can be used to retrieve the data, such as GetBuildingNumberList() method is used to extract all the building numbers from database, and send to the client side web applet.
5.5 Developing a Servlet for HTTP Access
In the outmost layer of the application server side, a HTTP interface for RuleDAO is needed so that the client side web browser can interact with the system.
38 Servlet is used to handle the request to the DAO. A servlet method is called to access
DAO to get the desired result, which, in this architecture, is returned as an XML document.
Therefore, XML needs to be converted into HTML for browser display.
The servlet is also responsible for creating an instance of RuleDAO. The servlet reads
JDBC parameters from the web.xml configuration file and constructs RuleDAO accordingly.
Following shows the codes to handle the RuleDAO creation function.
String dbUrl = getInitParameter("dbUrl"); String driverName = getInitParameter("driverName"); String user = getInitParameter("user"); String pass = getInitParameter("pass");
// create an instance of the RentalPropertyDAO try { myRuleDAO = new RuleDAO(driverName, dbUrl, user, pass); } catch (Exception exc) { log(exc.toString()); throw new ServletException(exc); }
The transformation of XML to HTML is done with template. As the XSLT transformation is executed in the servlet and there is a large number of concurrent users commonly present on a shared web server, so it makes sense to use Templates whenever possible to optimize performance. The codes shown below illustrate a custom XSLT stylesheet cache that automates the mundane tasks associated with creating Templates instances and storing them in memory.
TransformerFactory tFactory = TransformerFactory.newInstance(); String curName = null; try { curName = "/WEB-INF/xslt/rulecontentstyle.xslt"; URL xsltURL = getServletContext().getResource(curName); String xsltSystemID = xsltURL.toExternalForm(); this.firstTemplates = tFactory.newTemplates(new StreamSource(xsltSystemID));
39
}catch(TransformerConfigurationException tce){ log("Unable to compile stylesheet", tce); throw new UnavailableException("Unable to compile stylesheet"); }catch(MalformedURLException mue){ log("Unable to locate XSLT file: "+ curName); throw new UnavailableException("Unable to locate XSLT file: "+ curName); }
The servlet also has to handle HTTP GET requests, so the programs have to override the doGet() method. In this method, the content type of the response is set to text/xml. This informs the client that the system is returning XML-formatted text data. Next, a servlet OutputStream is set up. Then the program can retrieve a list of Rules from RuleDAO object. The list is then analyzed and shown to the client commissioner. The following shows the retrieving process of rule lists.
response.setContentType("text/html; charset=UTF-8"); PrintWriter out = response.getWriter(); String[] tempString;
try { tempString = myRuleDAO.getBuildingNumberList();
} catch (DAOException exc) { exc.getRootCause().printStackTrace(); throw new ServletException(exc.getRootCause()); } catch (Exception exc) { log(exc.toString()); exc.printStackTrace(); throw new ServletException(exc); }
To provide the interaction between clients and server, like doGet method, the servlet also overrides the doPost() method.
40 The system get the user query requirement from request’s getParameter() method.
Following shows the retrieving of buildingnumber, rulecontributor and rulelevel parameters from user interface.
String buildingNumber = request.getParameter("buildingnumber"); String ruleContributor = request.getParameter("rulecontributor"); String ruleLevel = request.getParameter("rulelevel");
After the desired building rules are retrieved, the servlet analyzes the rule content and then generates the commissioning guidelines for the clients. The guideline is in XML file format.
So now, this guideline needs to be transformed from XML file format into HTML file format.
The following codes show the transformation processed by XSLT processor using XSLT template. try { String ruleName = theRule.getRuleContent(); URL ruleXMLURL = getServletContext().getResource(ruleName); Source rulexmlSource = new StreamSource(ruleXMLURL.openStream()); Transformer transformer = firstTemplates.newTransformer(); transformer.transform(rulexmlSource, new StreamResult(out)); } catch (Exception e) { out.write(e.getMessage()); e.printStackTrace(out); }
41 Chapter 6 Illustrative Sample Cases
In this chapter, a typical commissioning work is demonstrated with the proposed commissioning
system. Any commissioning process would include the following steps: (1) defining a
commission plan; (2) generating an overall procedure and guideline; (3) generating component check sheets for inspection; and (4) report generation. Several user interfaces screenshots of these tasks are shown to illustrate the commissioning process done with the Web-based commissioning system.
6.1 Define a Commission Plan
The commissioner defines the commission plan by selecting the building number,
inspection phase and document providers. Commissioner can select a particular commission
building out of a list of buildings by specifying the building number. The existing building list is
retrieved from database through a server. Figure 6.1 shows the building numbers obtained from
database.
Figure 6.1 Building Number Control List
Commissioner can collect the commission information from all cooperative sources
available on the Net. The major sources for building commissioning include the major 'players'
in the A/E/C/FM industries, namely, the architect, the engineers, the construction management,
42 the contractors and subcontractors, the vendors, etc. Assume that these information have pre- determined set of content providers. The relevant rules to be used in commissioning tasks are specified through the list of rule contributors. Figure 6.2 shows the rule contributor list and the commissioner selecting a source.
Figure 6.2 Rule Contributor Control List
Assume also that there is a set of inspection types that are available for commissioner to follow. Commissioner can retrieve the commission information for a specified kind of inspection type by using the following list. Figure 6.3 illustrates the commission inspection type list.
Figure 6.3 Inspection Type Control List
43 6.2 Generate Commissioning Guideline
After the commissioner defines all the commission requirements, a commission guideline, consisting mainly a general checklist item for the building and the type of inspection mode desired for the building, as shown in Figure 6.4, can be generated.
This generated check guideline can direct commissioner to interactively retrieve commission documents from file server repository located in a distributed environment. This sample guideline includes the items to be checked. At the highest level, the major systems, such as air conditioning or plumbing systems, are listed. Both the Check Code and Check Procedure, based on some predetermined standards, are available through hyperlink.
Figure 6.4 General Commission Check Sheet
44 Auxiliary set of information, such as drawings or other forms of documents can be made available through hyperlinks as well. A summary check box for the punch list such that the commissioner may input the finding is also made available.
6.3 Generate Component Check Sheet and Report
Commissioner can also directly have a commission check sheet for any particular construction element. Figure 6.5 is the checklist of Fire-protective features element.
Note that the checklist should be based on standard codes, specified by either local or federal governmental agencies. The standard code used can be further filtered based on the need of the site being inspected and incorporated accordingly into the guideline checklist.
Figure 6.5 Fire-protective Element Check Sheet
45 After the commissioner completes the commission check sheet, he/she can submit the findings. The commissioning system will collect the data and generates a commission report automatically. An instance of report is shown in Figure 6.6. In case there is any violation, it reports all the unsatisfied requirements that this building provides according to the designated commission plan.
Figure 6.6 Fire Protective Commission Report
46 Figure 6.7 is another element check sheet generated with a different XSLT stylesheet.
This specified check component is Plumbing system.
Figure 6.7 Plumbing element check sheet generated with another XSLT style sheet
47 Chapter 7 Conclusion and Future Work
A computer system to aid people in the building commissioning process has been developed and
presented. It automates the time-consuming steps of gathering the necessary information and
generating the needed guideline for commissioning. It also serves as a knowledge management
tool to capture the rules for verifying the construction in terms of specifications and standard codes. The system is a Web-based system. The technologies used for this project include Java, servlet, JDBC, XML, JAXB, and multi-tier client server architecture.
In designing the system, many considerations and trade-off have been made. For
instance, in considering a database solution, there were two kinds of database solution to store
XML file. One is using native XML support. That is store XML data in the document in its
native format. Another is using XML database mapping. That is set up a mapping between
database field and XML document.
XML XML Files Files
XML XML Files Files
Table
Access Database Access Database
Figure 7.1 Two Database Solution approaches
48 This system initially tried to adopt the first method. But the size limit of the database makes it hard to directly store all XML documents in database, also the various file formats make it hard to manage the data in the database. So the system diverts to use the second solution.
Figure 7.1 shows the difference of these two approaches.
Another consideration was on the component technology. Originally programmed element classes are used to implement those commissioning components. These classes use SAX or DOM API. This approach has a lot of deficiencies. Programmer has to create custom content handler for each XML document structure. And for complex XML documents, the development and testing processes are very cumbersome. So, JAXB method was considered.
By using JAXB binding, developer can automatically generate element java object. These object classes could be expanded in the future to provide necessary methods. Thus, XML document can be represented as java object. The program can ensure the XML document be well-formed and validated against schema. This method is similar to DOM (Document Object
Model) approach, but it provides much simpler API.Overall, the first stage of this commissioning system has undergone some basic tests and proven usefulness and potential research values. It all used the most cutting-edge technology in knowledge information system which provides the system a lot of easy-to-learn and easy-to-maintain features. However, even the system has great flexibility and research value for potential enhancement, there is much, in terms of real world implementation, remaining to be completed.
One future approach is to incorporate more standard construction object into the system using Java Binding. By doing this, the system could much better support the standard open protocol in construction industry.
49 Another enhancement could be to make the system interactively communicate with other available building software or construction systems that support standard protocols. The future construction industry would agree on the same industry standard, it provides the basis of an open standard for multiple systems in different phase of construction knowledge management systems.
Finally, the system could be expanded to communicate with other testing instruments.
They could corporately provide a common interface to the end user together.
50 Bibliography
[1] National Environmental Balancing Bureau, Procedural Standards For Building Systems
Commissioning, National Environmental Balancing Bureau, 1993.
[2] Building Commisssioning Guide, The U.S. General Services Administration's and U.S.
Department of Energy Federal Energy Management Program, 1997.
[3] Building Commissioning Attributes, Building Commissioning Association, 2002
[4] NEBB Procedural Standards for Building Systems Commissioning, National Environmental
Balancing Bureau, 2001
[5] Clay Nesler Building System Commissioning: Let Technology do the Heavy Lifting,
Johnson’s Control Inc., May, 2002.
[6] Edward H. Brzezowski, The Evolution and Future of Control System, Facility Energy
Services, Inc., 2002
[7] Caldwell, N.M.H., Rodgers, P.A. and Huxor, A.P.(1999). Web-based Knowledge
Management for Distributed Design, IEEE Intelligent Systems, September, 1999.
[8] Watson, I. (2000). A Case-Based Reasoning Application for Engineering Sales Support using
Introspective Reasoning. In Proc. IAAI 2000. Austin Texas. AAAI Press. Forthcoming.
[9] Watson & Gardingen, D. (1999). A web-based CBR system for heating ventilation and air
conditioning Systems sales support. Knowledge Based Systems Journal, Vol. 12 Nos. 5-6,
pp. 207-214
[10] Greese von Wangenheim, C. & Tautz, F. (1999). Practical Case-Based Reasoning Strategies
for Building and Maintaining Corporate memories. Online (March 2000):
www.eps.ufsc.br/~greeze/call_ws2.html
51 [11] Aha, D., Becerra-Fernandez, I., maurer, F. & MunozAvila, H. (1999). Exploring Synergies
of Knowledge Management and Case-based Reasoning. AAAI Work-shop Technical Report
WS-99-19. AAAI Press
[12] Davenport, T. (1997). Information Ecology: Mastering the Information and Knowledge
Environment: Why Technology is not enough for Success in the Information Age, Oxproject
design ford University Press, 1997
[13] Ron Schmelzer, Travis Vandersypen, Jason Bloomberg, Madhu Siddalingaiah, Sam
Hunting, Michael Qualls, Chad Darby, David Houlding, Diane Kennedy, XML and Web
Services Unleashed, 2002, Published by Sams, pp 420-432.
[14] Eric M. Burke, Java and XSLT, O’Reilly, 2001, pp2-29
[15] IFC R 2.0 (Industry Foundation Class 2.0), the International Alliance for Interoperability
(IAI), 2002
52