Bim For Existing Federal Facilities

BIM for Existing Federal Facilities
WHITE PAPER

Abstract
BIM (Building Information Modeling) is fast becoming the standard for design and
construction of new facilities. Today, 83% of A&E firms are using BIM software. The
National BIM Standard (NBIMS) defines what BIM is and what the goals of a BIM are.
The challenge and question posed is, how to implement BIM concepts to existing federal
facilities and their associated information systems, in a cost effective manner. The
methodologies detailed in this paper, are a set of steps and procedures that will enable
owners to assemble current information systems into a functioning and powerful Building
Information Model. If these methodologies are followed, all facility stakeholders will
succeed. Even if an organization is not required to follow the BIM Standard, it is still an
excellent guide for achieving an Integrated System, a Data Portal, and a Decision
Support System, that improves the proficiency of facility operations and management.

Prepared by:

Roy J. Interrante, P.E.
Intergraph Corporation
Security, Government & Infrastructure (SG&I) Division

619-947-4638
roy.interrante@intergraph.com

December, 2010

Ecobuild America, National Institute of Building Sciences Page 1 of 32 December 2010


TABLE of CONTENTS

ABSTRACT.......................................................................................................................................1

BIM DEFINED...................................................................................................................................3

PREMISE..........................................................................................................................................5

INTRODUCTION ..............................................................................................................................7

THE DATA PROBLEM AND SOLUTION ................................................................................................8

STEP 1 – DIAGRAM AND DOCUMENT DATA FLOW MODEL ......................................................9

DATA EVALUATION PROCESS ........................................................................................................11

STEP 2 – STORYBOARD AND DESIGN APPLICATION .............................................................13

DATA PORTAL – USER INTERFACE .................................................................................................13

BIM PORTAL FRAMEWORK ............................................................................................................14

SECURITY MODULE .......................................................................................................................16

STEP 3 – DEVELOP ARCHITECTURE FOR INTEGRATION – THE INTEGRATION HUB .........17

DEVELOP INTEGRATION HUB ARCHITECTURE .................................................................................18

NBIMS – INTEGRATION AND INTEROPERABILITY .............................................................................20

STEP 4 – DEVELOP BIM APPLICATION ......................................................................................21

FEATURES OF THE BIM INTEGRATION APPLICATION ........................................................................22

BENEFITS AND ANALYSIS OF METHODOLOGY .......................................................................25

BENEFITS .....................................................................................................................................25

ANALYSIS – INTEGRATION PROJECTS.............................................................................................26

CMM – CAPABILITY MATURITY MODEL .....................................................................................28

CONCLUSION ................................................................................................................................32

REFERENCES ...............................................................................................................................32



BIM Defined
In the A&E world, when people speak of BIM (Building Information Modeling), they think
of and refer to the design process of using 3D software that is more than CADD, but a
sophisticated set of tools that allow all disciplines of a building design and construction
process to act in harmony. For example, when the Architect adds or changes a wall, the
plumbing, HVAC, electrical, and structural engineering systems are all interoperable and
the change in that wall is reflected in the design of the various systems. Any problems
or conflicts are also addressed in these BIM applications.
The definition of BIM, according to the NBIMS (National BIM Standard), goes beyond
this premise, especially after the design and construction phases, and extends into all
phases of the building’s life cycle. According to Dana Smith, Executive Director of the
buildingSMART alliance, and Alan Edgar, Chair of the National BIM Standard Project
Committee, “Some have identified BIM as dealing with only 3D modeling and
visualization. While important, this description is limiting. A more useful concept is that a
Model should access all pertinent graphic and non-graphic information about a facility as
an integrated resource”. [3] The information challenge, and the objective of this paper, is
to demonstrate how the NBIMS can be applied to existing facilities that are in the O&M
(Operations and Maintenance) phases of the Building’s life cycle.
BIM concepts can be used in the design of an integrated decision support system. BIM
for facilities management and operations and maintenance is being encouraged by
many federal agencies, such as NASA and the Army Corps of Engineers. There is a
misunderstanding that BIM is just 3D modeling of a structure. 3D Modeling can be part
of a BIM implementation, but the essence of BIM is just that, Building Information.
The following definitions of BIM have been extracted from the National BIM Standard
and are part of the global buildingSMART Information Delivery Initiative:
A Building Information Model (BIM) is a digital representation of physical and
functional characteristics of a facility. As such it serves as a shared knowledge
resource for information about a facility forming a reliable basis for decisions during
its life-cycle from inception onward.
A basic premise of BIM is collaboration by different stakeholders at different phases
of the life cycle of a facility to insert, extract, update or modify information in the BIM
process to support and reflect the roles of that stakeholder. The BIM is a shared
digital representation founded on open standards for interoperability.
The following figure is by courtesy of NIBS National Building Information Modeling
Standards Committee.



Geospatial Financial
Data Data

Legal
Data

Designer

BIM
Data Specifier Data

Environmentalist
Owner / Occupier Data
Data
Sustainers Data

BIM – Building Information Modeling

The above diagram from the NBIMS shows that the objective is to integrate all
information about facilities into the BIM. Information about the Building/Facility is
needed throughout the life cycle phases and it is needed by all stakeholders. According
to the National Institute for Building Sciences, “the vision of the National BIM Standard is
an improved planning, design, construction, operation, and maintenance process using
standardized machine-readable information model for each facility, new or old, which
contains all appropriate information created or gathered about that facility in a format
useable by all throughout its lifecycle” [1, pg. 6].
The large vision of BIM is to facilitate improved efficiencies at all stages of a facilities
lifecycle. It is not the objective of the Standard that one vendor provide all the tools
necessary. Per the NBIMS, “It should be stated emphatically in the introduction that we
do not envision a single database or vendor for the data repository, simply a central
location where all software packages can come to seek related BIM information. The
requirements for information storage and sharing cover three traditionally separate
facets of the industry, Computer Aided Design (CAD), Computer Aided Facility
Management (CAFM), and Geospatial Information Systems (GIS). A model view of a
BIM could incorporate information from any or all of these technologies. The greatest
cost associated with capital facilities occurs during the operational phase, owners are
expected to obtain the greatest value from having real-time, as-is BIM.” [1, pg. 59-60] This
paper is focused on establishing a BIM during the operational phase of a facility’s life
cycle.



Per the NBIMS, “the problem is all the existing facilities in the owner’s portfolio. Even
with planning, it will take many years before facility turnover results in a fully populated
BIM repository. As-is BIM often is driven by asset management functions. As more
information becomes available through BIM-based information exchanges, owners are
able to drill down into the details of each added facility or infrastructure asset for more
and more information. The BIM vision is to improve the Operations and Maintenance
process.” [1, pg. 60-61]
This paper focuses on methodologies and system design approaches for implementing
BIM concepts for existing facilities in their operational and maintenance (O&M) phases,
and specifically federal facilities.
Many BIMs in existence do not meet the NBIMS definition of a BIM, since they are really
only intelligent drawings, visualization tools, or production aides. The Standard also
describes how to rate the maturity level of a BIM via a Capability Maturity Model (CMM).
[8]
The CMM measures the degree to which a BIM implementation measures up to a
mature BIM Standard. Accordingly, a project or application cannot be called a BIM if it
does not meet the minimum level of the CMM. “We are saying that if you are not taking
into account this minimum BIM level, then you shall not call what you are doing a
building information model.” [1, pg. 71]
As an example, a recent project was independently evaluated and was rated as being
80% BIM compliant, per the CMM. The other 20% could be realized by adding 3D and
more interoperability between data systems. The BIM Capability Maturity Model and this
study will be described in more detail at the end of this paper.

Premise
Many facilities in federal Installations are fairly old, dating back to WWII and beyond, and
were originally designed and built according to obsolete specifications. These facilities
have had many owners through the decades (e.g., from the Army Air Corps, to Air
Force, to Army Corps of Engineers, to NASA, etc.). The usage and function of these
structures also changed (e.g., from barracks to warehouses to office, etc.). Numerous
modifications occurred to these facilities as needs of federal agencies changed. Building
standards and technologies also changed and were applied to these facilities (i.e. HVAC
systems, electrical and water system upgrades, computer networks, etc.).
Many federal facilities have increased their life expectancy by decades, and facilities that
were built in the 1940’s as temporary housing for troops, are still in service, 60 years
later. Some facilities have undergone extensive renovations, where wall sections and
basic architecture have been removed or added.
Numerous facilities have gone through retrofitting to comply with new health, safety, and
environmental standards, such as asbestos removal or abatement, seismic
reinforcement, fire protection, security, access control, energy saving modifications, etc.
These retrofits, modifications, and renovations sometimes use current standards and
specifications, but many times customized systems have to be built in order to work
around the existing constraints of a facility. For example, installing an HVAC system into
an existing structure may require special fabrication of duct work that does not comply to
computerized specifications. If there are hundreds or even thousands of such shop
fabrications within an existing facility, it would be extremely difficult to fit these into BIM



software. It would not be impossible, only extremely cost prohibitive to migrate a
building into a BIM system for many existing federal facilities.
As Information Technology (IT) has evolved, the Federal Government has applied
various technologies to existing facilities to improve performance and efficiencies.
These Information Technologies include CADD (Computer Aided Design and Drafting),
GIS (Geospatial Information Systems), CMMS (Computerized Maintenance
Management Systems), CAFM (Computer Aided Facility Management), UCS (Utility
Control Systems), etc. The results of these IT initiatives have spurred numerous data
system applications to manage these facilities.
The latest technological advancement to improve facilities management is BIM. The
Army Corps of Engineers, NASA, GSA, and other federal agencies have been
encouraging the BIM concept. [5] [7] [10] Even the Tri-Services GIS Center is now called
the “CAD/BIM Center”. [4] Many vendors have BIM products for new construction, but
BIM can be more than that and can be used for existing facilities that were designed,
built, and renovated before BIM software existed.
The eventual goal of BIM is to develop data standards that will allow interoperability
between vendors and applications. However, this goal has not been fully realized at this
time. Currently, many applications are needed to contain the entire knowledge base of a
facility. This knowledge base is contained in CADD, GIS, CMMS, CAFM, Space
Management, Real Property, Financials, and sometimes many more.
The foundation of this paper is derived from the NBIMS (National Building Information
Modeling Standard). This standard is being established by the Building Smart Alliance,
which is a council of the National Institute of Building Sciences (NIBS).
http://www.buildingsmartalliance.org/ . Many BIM concepts can be used for an existing
facility and its associated data and management applications that will improve
sustainability and operational performance.
The challenge of creating a BIM for Existing Facilities is that after decades of Operations
and Maintenance (O&M), numerous Information Systems have been implemented. For
many Installations, 30 to 50, and sometimes more, separate systems are used to
manage a facilities and infrastructure project. As Interoperability between software
application improve, so will the BIM. However, it is not necessary to wait for this
evolution to occur. Many BIM concepts and characteristics of the BIM Capability
Maturity Model (CMM) can be achieved today.
One can think of BIM as the umbrella of all facility information systems, with CADD, GIS,
CMMS, CAFM, etc. systems under that umbrella. And this is what was accomplished at
several federal sites. Intergraph’s strength is delivering data to customers in a
meaningful way.
It is not debatable that new construction of facilities use BIM concepts and software,
starting from Concept, to Design, to Build, in the facilities’ life cycle. The challenge and
question posed in this paper is how to implement BIM concepts to existing facilities in
the Operation phase, and do it in a cost effective manner.
The objective of this paper is to demonstrate methodologies that have
been implemented at Federal sites to obtain the primary objectives of
BIM in the facility’s current information environment.



Introduction
Per the NBIMS definition “a basic premise of BIM is collaboration by different
stakeholders”. The definition also states that “BIM serves as a shared knowledge
resource for information about a facility” and that this information is a “reliable basis for
decisions”. [1, pg. 21] The essence of Building Information Modeling is the ability to
integrate all pertinent information about a facility.
The data integration techniques and strategies discussed in this paper are the result of
more than 15 years of integrating facility information systems at various Federal
Government installations. These concepts are not theoretical, but have been tested in
the field, and have been proven to achieve the integration of data sets from many types
of complex data system environments. This integration has resulted in the dramatic
transition of work and business practices for many stakeholders. Engineers,
Technicians, and Managers no longer spend a large portion of their time searching for
data. Once this type of integration is established, they simply click a few buttons, and
report their data in various formats.
The methodologies presented ensure that reliable, authoritative data are readily
available for meaningful analysis while minimizing the redundancy in both information
and processes. Existing systems and applications are leveraged in order to eliminate
the need for additional software or licensing implications. These data integration
methodologies are not reliant on any one vendor provided applications.
The objective is to supplement any existing data reporting tools, and to provide a data
portal to pertinent information by using all means available, including leveraging off of
existing applications, to achieve the most effective data portal possible that satisfies the
customer’s requirements for data retrieval and reporting. This approach is not about
usurping other existing systems, but it is about using and leveraging them. Data
integration of enterprise data systems is a very complicated problem. Some vendors
over simplify the problem, and therefore propose simple solutions, and never solve the
problem. This integration methodology avoids this possibility because it is not reliant on
vendor provided applications.
The methodology utilized to realize an Integrated Building Information Model (BIM)
consists of four (4) major steps. These steps have been defined through the process of
integrating many enterprise data systems. These steps have proven successful and
able to solve many disparate data architecture integration issues.

Methodology for Data Integration
1. Diagram and Document Data Flow Model
2. Storyboard and Design Application – The Web Portal
3. Develop Architecture for Integration – The Integration Hub
4. Develop BIM Application

The final chapter will demonstrate how the development methodologies and approach
described in this paper produced a BIM application that is 80% compliant to the BIM
Standard, via the BIM Capability Maturity Model (CMM).



The Data Problem and Solution
Problem
At almost all federal facilities there exists many separate data sources. These data
sources are maintained by their respective organizations and serve local goals for their
organizations. Information is hard to extract from these various sources and even
harder to correlate. In addition, many of the data sources require dedicated software
licenses to access the information and require specialized knowledge and training. It is
in this environment that facility managers must administer and make decisions that
involve these data sources.

Space Mapping/GIS
Management Department

Planning Utilities
Department Department

Architecture/CAD Maintenance
Department and
Operations

Current Data Environment at many Federal Facilities

Solution
The strategic solution to solve this data problem is to implement a dynamic data
integration of the separate data sources with visual and intelligent reporting capabilities.
The objectives of this strategic plan are to provide a web interface to facilities data sets,
rapid data access, a visual portal to multiple data sets, and be integrated in such a way
that facilitates information gathering and analysis. This BIM application will make
business sense, in that it improves the efficiency and decision making capabilities of
facilities managers and all stakeholders.



Operations &
Maintenance
Assets
Financial

Utility
Data Integration Control
Real Decision Support System
Property
Data Portal
BIM
CADD
Architectural

GIS Utilities
Maps

Facilities Data Integration-Conceptual

The diagram above depicts the conceptual goals of an integration project. Many Data
Sets and Applications exist at federal facilities and some of these data sets may have
some level of integration. These Data Sets are shown as circles around the Integration
Portal. The slashed lines represent integration between different data sets. The
hatched lines represent the utilization of this existing integration within the Data Portal.
Users not only benefit from this integration, but they also are able to access many other
data sets within the Decision Support Portal.

The objective is to provide a portal to multiple data sets and be integrated in such a way
as to facilitate information gathering and analysis. It is not the objective to replace
existing data sets or applications. The goal is to bring a majority (70 to 80%) of many
data sets into an easy to use portal for rapid data access and to improve the efficiency
and decision capabilities of facilities managers.
This data integration solution utilizes existing data sets and their associated processes
and applications. Each sub-system is reviewed with the data maintenance staff and
other data users to determine the best approaches to access, report, and integrate data.
Recommendations to improve processes or data structure are also made as appropriate.
The architecture of this application is scalable, in order that new data access portals,
components, functions, and applications can be added in the future.

Step 1 – Diagram and Document Data Flow Model
The first step for developing a data integration system is to develop a Data Model and
Flow Diagram. This diagram is created using UML (Unified Modeling Language). UML
is a graphical language for visualizing and documenting complex systems. It is the blue
print or map of an information system. UML is a general purpose modeling tool for
visually and intelligently displaying object oriented software systems. Therefore it is well
suited to represent the results of the data source analysis.



Data Model Legend

The figure above depicts the diagram legend for the Data Model, and the figure below is
a partial example from a Data Model Diagram.
In carrying out this step, data surveys and user interviews are conducted. Information
about database schemas, file servers, spread sheets, processes, data owners, security,
web applications, etc. are collected. Information from these interviews and
investigations are used to develop the system diagram. These documents serve as a
tool for understanding the existing data flows and help in the design and development of
the integrated BIM application. Data patterns, duplications, data gaps, problems, etc.
are invariably discovered during the development of the Data Model. These issues are
also documented.
The objective is to create a living document that is updated as the design process
develops and as the system changes and integration occurs. It is used to determine
future data integration possibilities. The Data Model is the means to document the data
structure of complex information system environments. It can be viewed as the map of
how information is populated, transferred, and maintained throughout an enterprise.
The Data Model is built using UML software. These products have many useful tools for
building UML models and diagrams. One such tool is linkages and hyperlinks. Data
sources on the graphics model are linked to the actual data source. If the data modeler
clicks on a graphic object depicting a data source, such as a file server or database, the
actual data source opens. This is an excellent way to insure that data connectivity and
network permissions are functional. The modeler can then easily open the data source,
view the structure of the data, and analyze the data content.
The Data Model is an integral part of a data integration BIM. It must be maintained to
monitor changes to various data sets so that data connectivity is maintained in the data
integration portal application.



Master Floor Plans Component
Manager: Name

Master Floor Plans
MicroStation Files CADD
Owner: Name Mngt. PARCH
ServerShare$Path
Project Architect
Management
Data Application
Link
Referenced
Drawings
Ascii File
(data used by
PARCH
Application)

Referenced
Drawings CADD
Mngt.

Emergency
Evacuation System Drawings
MicroStation Files MicroStation Files Notes:
Owner: Name Owner: Name  Data Capture Project in
progress.
ServerShare$Path (Electric, Mechanical, Plumbing)
 Directory naming
ServerShare$Path convention is not
consistent.

Data Model and Flow Diagram – example

The Data Model is an invaluable tool for any Data Integration project. Unfortunately,
many vendors skip this step, or perform it at a very basic level (i.e. a spreadsheet with a
list of Data Sources), and therefore never get an intelligent understanding of the entire
Enterprise Data Information System.
The consequence of not developing a robust data model is that a solution will miss data
integration opportunities and maintaining data connectivity will become more difficult or
may fail. Without a detailed data model, the customer is often not aware of all the data
sources and processes available in their enterprise.

Data Evaluation Process
The methodology and processes for evaluating enterprise data sources is to view that
data as a system with interrelated parts. Information flows both into and out of various
parts of that system. Some parts are electronic and others are manual. When
evaluating the data sources a series of questions are asked of the data users, owners,
and administrators. The actual workflows and processes are observed. Data schemas,
file structures, and applications are analyzed. All this information is captured and
documented in a UML diagram.
During the evaluation process, analysis is performed to determine the most efficient
method to access various data and generate reports for users. The primary component
in the BIM solution is a sophisticated integration method called the Integration Hub. The
Integration Hub is discussed in detail under Step 3. Integration Solutions for each
individual Data Source are also addressed.



The following list includes the basic questions and analysis performed when evaluating
Data Sources for an integration solution:
Define Data Schema / Data Dictionary.
Define Data Types.
Evaluate Database Software.
o Oracle o Spreadsheets
o SQL Server o GIS
o Sybase o CADD
o Microsoft Access o Others

Define Applications that input and output data from each data source.
Define Web Applications that access each data source.
Define any custom or standard tools that exist for each data source.
Define data entry and maintenance of data source.
Define ID values, nomenclature, data field names.
Define possible correlation to other sources.
Analyze Reports for the data source.
Define any existing integration with the data source to any other data source.
Identify Owners, Data Maintainers, System Administrators, Vendors, Users, and all
persons involved with the Data Source.
Define system architecture, servers, peripheral software, security, etc.
Define any Processes involved in the Data Source. These processes can be
manual, automated or both.
Review and observe various Workflows involving the Data Source.
Define the Queries and Reports generated for the Data Source.
Follow the Flow of Data. Many Sources have multiple connections to each other.
Some data sources are independent.
Document all information on UML Data Flow Model.

The analysis performed utilizes some of the following methods to determine the best
approach to integrate data via a common tool, i.e., BIM web portal. More details
regarding these integration methodologies and algorithms are discussed throughout this
paper.
Determine applicable methods to connect to each respective Data Source. Some
data connections are simple, and only require an SQL statement into the Data
Source to return a Data Set, and other data connections are more challenging, and
require the use of various integration techniques.
Determine network, permissions, protocols, etc. in order to access the Data Source.



Review any web pages and URL variables that might be used.
Determine if data should be post processed.
Determine if an API or COM Object exists that can be used for data access.
Determine performance and reliability of the Data Source and associated
applications.
Determine if caching of data may be needed. Cached data could be stored on
servers or on client machines.
Determine if Metadata, Correlation Tables, SQL on-the-fly, or other methods of
extracting and reporting data may be needed.

Step 2 – Storyboard and Design Application
Once the Data Model diagramming begins, a Storyboard design of the application is
developed. An application storyboard is a graphical representation of the look and feel
of the final product. Many programming and development issues can be resolved during
the storyboarding process. Data users are very involved in this process, so that the BIM
application will produce the desired results. The Data Modeling process continues
throughout this task in order to determine the structure and location of necessary data
sets.

In carrying out this step, detailed layout diagrams of the application are developed.
These diagrams are used to communicate with the development team and the customer.
The diagrams are the beginning outline of the look and feel of the Data Portal. From
them, a web storyboard is developed consisting of a site layout of data windows, titles,
buttons, navigation, hyperlinks, pull-down menus, functions, tools, graphics, report
layout, etc. Web architecture design diagrams are developed consisting of web server
software, components, and configuration; and links to data sub-sets (databases,
spreadsheets, reports, etc.). The web architecture design diagrams are included as part
of the storyboard design documents. These Storyboard documents define development
phases.

This design process has been proven to greatly reduce programming time and effort.
The programming team knows what is expected, and the data integration investigation
has already been accomplished.

Some vendors skip the Storyboarding step because they have an existing Solution, and
they try to fit the customer’s requirements into this prefabricated solution. The preferred
approach is to determine the customers requirement, and build the Storyboard and
design the application around those data requirements.

Data Portal – User Interface
To ensure that the goal of providing an intuitive, functional and easy-to-use data
integration tool is deployed, the end user is actively involved in the development and
design of the storyboard. During this design phase, the end user is walked through the
proposed screen layouts, data navigation and extracting process to insure that the web
pages will be intuitive, that data extraction is easy, and that the appropriate information



is obtained. With this level of user involvement in the design phase, the BIM web portal
will look, feel, and deliver the needed information in the desired formats.
As the design is finalized, the application is analyzed to insure intuitiveness and ease of
use. As an example, the number of work-flow steps that a user will need to extract data
are reviewed:
Step 1: Open the application
Step 2: Select a Facility Number from a Pull Down List
Step 3: Push a button for the desired report, data value, map, drawing, etc.
Step 4: Data is displayed
If it appears, during the storyboard design phase, that data extraction will be too
complicated, take too many steps, or be cumbersome for the user, additional automation
is developed within the application to process the data. Many programming steps may
be taking place within the application, but the user is unaware of that, and they simply
retrieve the data they are looking for. Additional examples of how the web portal (the
user interface) can be used to facilitate easy extraction of data are provided below:
Pull down lists are generated via database queries to allow the user to easily
navigate and reduce key-ins.
Pre-built queries and reports are generated. The user does not need to know SQL.
They simply select the data or report they want, and it is generated for them.
Multiple pull downs and variables can also be provided, and the user simply selects
those variables and options and then hits a create report button. No understanding
of SQL syntax is needed.
Navigation of the web portal is maintained by using a panel design (i.e. a
dashboard). The user opens and closes panels that reveal various query tools, but
they are never directed to a point of being lost on the web page.

BIM Portal Framework
The BIM portal framework (see the Conceptual Storyboard diagram below) is very
similar to other web portals being used on the Internet (see Google Earth as an
example) and to those successfully deployed by Intergraph for similar data integration
projects. The Panels on the left, however, are not just a long tree structure of data
layers, but are separated panels that act independent from each other.
New components can be easily added to the BIM Portal Application, which would be
separate from other Components. It is a misunderstanding to view this application as a
single function when it is, in fact, multi-functional, and new components can be added
with no problem. Each of the Panels on the left side of the Portal Console act
independent from each other. They basically act as separate applications, with various
functions, that work within the overall framework of the web portal application. The
reporting data window on the bottom, also acts independently.
For example, if a user selects a real property data control panel on the left, a real
property data window would be displayed on the bottom panel. Alternatively, if the user
selects a CMMS panel, then a CMMS data window would display. Also, the architecture
of this portal is not limited to a one to one relationship, i.e. Real Property queries and



CMMS queries. A panel could have integration built into the functions, that combines
and joins these two data sources. If there were separate data in both databases, and
they were correlated by a Building ID, for example, then a Panel of CMMS to Real
Property Reports would give the user the ability to query and join these sources in one
component, and the reports would be displayed in a new data widow.
The Data window can be displayed on the bottom data widow as a summary report of
values, or buttons can be added to pop open reports in a separate browser window. All
of the actual details of the navigation, panels, functions, reports, data windows, maps,
drawings, etc. are designed with the customer, data users, and data managers in the
Storyboarding phase of the project.
It should also be noted, that sometimes a navigation and query tool can look good during
the Storyboard process. Even though everyone involved is diligent, the product may still
have issues that aren’t recognized until the preliminary development is built and tested.
This happens in the movie business all the time. A scene may look good on the paper,
but once the actors perform, the director may send the screen writers back to the
drawing board. That is why the Development Phase is divided into 3 parts: Preliminary
Development, Test and Modify, and Deployment. The testing phase is intended to catch
these types of issues.
The NBIMS recognizes that different users need and require different views and reports
of the same BIM. This design process and framework will support the fulfillment of that
requirement.

Integration
BIM - Data Portal Hub
Facilities Facilities Data
Utilities
Select Building Architectural GIS
Data Data
GIS
CMMS Real Property
Data Data
Assets CMMS

Select Asset ID Utilities Environmental
Data Architect

Energy Financial
Environ
Data Data

Project Report Data Reports Energy

Create Reports
Real Prop
View Files
Create Reports
DATA MODEL

Project Reports Spread
Sheet

Storyboard Design of BIM Application – Conceptual



Security Module
In a BIM, or any other data integration project, data access and control is a concern and
requirement. Many of the underlying data systems may have various layers of data
access control. For example, all users might have access to employee phone numbers,
but only managers will have access to payroll information. A Security Module has been
designed to control data access from the BIM application interface. Per the diagram
below, the user logs into a network and is authenticated. The User ID is compared to an
Access Control database. Only users with special permissions can view certain data
objects (red objects). All other users can only view unrestricted data objects (black
objects).
If the user is not listed in the Access Control database, they can only view unrestricted
data. This framework reduces data maintenance for the system administrator. Only
users with special data permissions are listed in the Access Control database. The
administrator does not need to list every user, which could be in the hundreds or
thousands.
Access Control Design Specifications
 Uses current User/Password. Return ID from Network Server.
 The “Access Control Database” contains only Users who have access to Restricted
Data.
 All data fields, data reports, tools, categories, map layers, etc. on the BIM web site
are named objects, and viewing this data can be controlled and restricted.
 The “Access Control Database” contains only the Data Objects that have
Restricted Access.
 Only Users in the “Access Control Database” with the Data Object field checked
yes, will have access to the Object.
 All other Users (users who are not on the Access Control Database) will have
access to a default set on objects. Default Users will not see “Restricted Objects”.



Access Control Module

Step 3 – Develop Architecture for Integration –
The Integration Hub
As the application storyboard is developed and the data structures are documented in
the Data Model, strategies to access and integrate data are developed. This system
architectural component is called the Integration Hub. The Integration Hub consists of
software and data that connects applications and functions to various data sources.
This task involves the initial architecture development and design of the integration tools
and methodologies to solve connectivity challenges.
The platform for the BIM for data collection consists of two main parts, the Web Portal
and the Integration Hub. The Web Portal is the interface that the users see and use to
query and report data. The Integration Hub is the behind-the scene mechanism used to
extract information from various data sources and deliver that information to the user.
The Web Portal and the Integration Hub are developed simultaneously, based on the
findings from the Data Modeling and Storyboarding steps. It is always the objective of
this approach to use as much of the existing systems and architecture as possible. It is
also the objective of this approach to develop applications that are easy to maintain and
to use standard web development practices.



The Web Portal is the interface that the user interacts with. This platform could be of
various configurations. Best results have been achieved when a standard web page
interface is created with standard HTML and Java Scripting. This simple platform has
resulted in the easiest web application to use and maintain. However the Web Portal
could be built on any platform the customer prefers.
The Integration Hub consists of many parts, but the main objective still applies; use
existing systems, networks, servers, platforms, etc. where possible. In general, web
development for a connection to a data source uses the following basic steps:
 The user requests information on a web page via a key-in, pull-down, button, etc.
 That request is sent to a web server.
 The web server connects to a database or file server.
 The data is retrieved and placed in the desired format on the server.
 The server then sends the information back to the user’s browser.

Develop Integration Hub Architecture

As the application storyboard is developed and the data structures are documented in
the Data Model, strategies to access and integrate data are developed. This system
architectural component is called the Integration Hub. The Integration Hub consists of
software and data that connects applications and functions to various data sources.
This task involves the initial architecture development and design of the integration tools
and methodologies to solve connectivity challenges. An example of data integration is
the creation of a single integrated report for a facility from a building spreadsheet, a
CMMS asset database in an Oracle Database, and a Real Property off-site database.
Various integration technologies, approaches, and methodologies are used to integrate
homogeneous and non-homogeneous data sets, and build the data Integration Hub.
Some of these data set integration techniques include the following:
 Direct SQL connection and query
 Data correlation by logical code via dynamically generated SQL
 Data correlation and integration by metadata
 Data integration by correlation data tables
 Data replication and warehousing methods
 XML data exchange
The Integration Hub continues to be developed as new data-sets are introduced into the
Data Portal. The level of integration performed is at a read-only echelon (versus full
transactional). Existing data entry applications and processes remain as is. However,
recommendations for data improvements are made.



Application
Database

Data Integration
BIM Application Business
Process

•Data Portal
Application
•Queries Integration
Database

•Searches Hub
•Reports Business
Process
•Functions
(Web Desktop Access)
Data Files Application

Business
Process

Integration Architecture

The above Integration Architecture diagram, is a conceptual schematic of the data
integration architecture of an enterprise data environment. The symbols on the right
represent various data sources. Each Data Source consists of 3 main parts; the data
source such as a database or file server, the application(s) that are used to maintain the
source data, and the business processes around the data source needed for data
population and maintenance. In actuality, these three parts are much more complicated
than the one displayed here. The Data Model will present all the details and
relationships relevant to these parts.
The Integration Hub is a collection of methods to query the data contained in the data
source. That method may be a simple database connection and SQL Query to the data
source that return an array of values. Alternatively, the method may be more
complicated and require a correlation matrix, post processing of the data, conversion to
XML format, and caching of data sets. The exact determination and design of the
integration method to be used, is developed during the data modeling and storyboarding
design processes. Sometimes these integration methods may require various tests to
determine the best algorithms to extract data.
The final component of the Integration Architecture on the left side of the diagram
represents the BIM Web Portal. The Web Portal is the web page application that the
user interfaces with to extract information. This Web Portal is the result of the
storyboard design. The activity in the Integration Hub is not visible to the user; the user
simple selects various querying and reporting tools on the Web Portal and the data is
displayed in the desired format.
Intergraph approaches data integration projects as a long-term partnership with
customers. The success of these types of projects is ensured when there is strong



participation by customer representatives and open communication and interactive
dialogue with all stakeholders.

NBIMS – Integration and Interoperability
According to the NIBS (National Institute of Building Sciences) the objective of the
NBIMS (National BIM Standard) is to develop open interoperability standards so that
information can be exchanged between applications. Interoperability is also one of the
areas measured in the BIM Capability Maturity Model. Per the NBIMS, “Things may not
flow as smoothly as desired today; hence, we are only requiring that ‘forced
interoperability’ occur in the minimum BIM, but some level of interoperability must occur.”
[1, pg. 6]

COBie
COBie (Construction Operations Building Information Exchange) is an initiative that is
part of the NBIMS effort. [6] [11] COBie is a data standard that supports the capture of
product information during the design and construction process, so that data can be
exchanged and integrated into existing maintenance, operations, and asset
management systems. One objective of interoperability is that data is collected only
once, and then distributed and exchanged to other systems where needed. COBie data
exchange is being endorsed by many federal agencies and software vendors.
As BIM standards mature, and COBie standards are adopted, it will become easier to
integrate and link information since schemas (i.e., table names, field names, data
values, etc.) will become normalized. Since integration and interoperability are
significant objectives of BIM, and some level of interoperability must be achieved to meet
BIM capabilities, they must be defined.
Integration vs. Interoperability
You cannot have interoperability without integration. Interoperability is a sub-set of
integration. Integration can be accomplished by associating information from one
system to another. Interoperability is the ability to exchange data from one system to
another. This process can be automated, semi-automated, or manual.
Full interoperability may be difficult to obtain in the federal facility environment due to
numerous existing building management applications, such as CMMS, Facility
Management applications, various GIS, Government Real Property databases, etc.
However, these applications can be integrated and some interoperability can be
obtained. Interoperability is sometimes hard to accomplish in a federal IT environment
due to varying security protocols. Some systems can be queried for information, but
access to manipulate or populate data is restricted. Some data sources will never have
complete interoperability due to security and policy issues. For example, the database
within a Real Property system at Head Quarters would not allow other systems to
directly modify information. Data staging, correlation, exception reporting, and other
methods can be used to achieve some interoperability between data sources.
Interoperability is basically the exchange of data values between one system and
another. For existing facilities with existing data applications, this requirement can be a
challenge. Many systems are fairly closed and are built with many rules and business
processes to maintain data integrity within the system. Modifying data from one system
to another may be extremely difficult, and in many cases may not be desired at all due to
security and maintainability issues. For example, A CMMS (Computerized Maintenance



Management System) asset management application and database schema will contain
many data management rules and users have different levels of data access. If an asset
record (a physical asset with a specific ID) needs to be added or changed, only users
with specific rights can do so. Also, the user interface may show one field to modify the
data, but underneath, inside the data schema, many processes are occurring to check,
validate, build join relationships, populate log files, etc. for the change.
Concurrently, the same asset ID may also exist in other databases, such as in a CADD,
GIS, Financial, Space Management, etc. And these separate systems could contain
very valuable data needed for the BIM. The challenge is, if data values are changed in
one system, how are these changes reflected and performed in the other system. In a
perfect IT world, all these independent systems would be completely interoperable, and
would be changed automatically. Currently, this in not the case, and in many instances,
such as security, complete interoperability is prohibited. For example, if a change is
made in the space management application, that change would also need to be applied
in a security database. However, security will not give direct access to other
departments, even though this data would be valuable in the BIM. The exchange of data
in many systems must occur though other means other than direct interoperability.
Interoperability - Alternative Solutions
Some level of Integration and Interoperability of multiple facility information systems is a
requirement of a BIM. These problems and challenges of data interoperability and data
exchange have been resolved in many ways. The question and challenge is the level of
automation necessary to achieve interoperability. The following are methods used to
achieve interoperability (data exchange) between information systems.

1. Manual Data Exchange and Correlation
2. Post Processing of Data
3. Data Staging
4. Exception Reporting
5. Other Automation for Data Integration, Correlation, and Validation

Step 4 – Develop BIM Application
The development of the BIM Application includes both the Web Portal user pages and
the Integration Hub components. Development is conducted in three (3) phases.
Preliminary Development, Test and Modify, and Deployment. The first phase,
Preliminary Development, focuses on a few features and integration from the design
documents from the previous steps (i.e., step 2 – Storyboard and design, and step 3 –
Integration Hub design). This phase insures that data connectivity is functional. Then
other functions are added according to the design specifications. Next, the second
phase, Test and Modify, are conducted. The results of the Test and Modify phase are
evaluated, and any changes to the design documents (Web Portal and Integration Hub)
are performed. Once the customer approves the final design, the final Deployment
phase is conducted.



Features of the BIM Integration Application
These following features and functions have been incorporated in various data
integration projects. These features have been developed to solve complex data
integration challenges. Many of these features are part of the Integration Hub, and are
not obvious to the user. The user simply selects the desired information from the Web
Portal.
Not all of these functions are incorporated at all integration projects, but are presented
here to demonstrate the extent of the methodologies employed to solve complex
integration issues.
Data Connectivity Redundancy
Cached Data and Redundancy Linkage to Data Sources
Error Control Processes Intuitive Design of Interface
Cached Data Sets (Server and Client) Data Retrieval Performance
Reliability Automated population of Metadata
Post Processing of Data (Server and Manage Non-Homogeneous
Client) Database
Component Architecture Data Mapping
Data Warehousing Exception Reports
Data Correlation Processes Manage Disparate Data
Metadata Control (correlation, data Correlation by logical code via
availability, access control, etc) dynamically generated SQL (SQL
on-the-fly)

The following discussion describes the significance of several of these features in terms
of a deploying a successful data integration solution.

Data Connectivity
Maintaining Data Connectivity to the BIM Portal Application is extremely important. If
connectivity is lost, then obviously the data cannot be extracted. If a Data Portal
Application does not anticipate and plan for these changes, it will eventually fail, since
changes to data systems are inevitable in our constantly improving technological world.
Large Data Enterprises consist of numerous data sources and applications, and this
data architecture is not static, it is extremely dynamic and changes are made to source
data systems constantly. If a procedure and policy to maintain data connectivity is not
developed and maintained, the application will eventually fail.
By developing and maintaining a strong and detailed data model, IT managers can
observer, plan for, and implement changes to the BIM and the Integration Hub in order
to sustain data connectivity.
For example, at NASA Marshall two main data systems were modified in the same year.
One was Maximo (an IBM application) and the other was the Space Management
System. There are over 30 different queries from the Portal Application to the Maximo
Database; and over 40 different queries from the Space Management System.



Numerous changes occurred in the database schemas, processes, applications, and
graphics. Since a strong data model existed, and the storyboards acted as
documentation of the BIM portal application; analysis, design, and implementation to
maintain data connectivity to the portal was accomplished. If these documents of the
system architecture had not exited or if changes in the data sources had not been
planned for, the application would have failed.

Cached Data and Redundancy

Cached Data on the Server and Client can be components of this development
approach. The benefit of this type of design is that it greatly increases performance and
reliability. Performance is increased since much data is pre-processed and stored on
the Server or Client machine for quick access. Reliability is increased because even if
the network fails or some data sets lose connectivity, much of the user’s application will
still function, since data sets are stored and cached at various points in the data retrieval
process.

Redundancy is built into the application and system architecture. If one part or function
or data connection fails, the entire system does not fail. (We have applied highway
bridge design for redundancy concepts to software application design).

Many integration solutions do not consider caching data or redundancy. These solutions
simply connect to the data source via an ODBC or other database connection protocol.
Using this approach is not recommended because if the data performance of the source
is slow, then the solution is slow; and if a data source gets disconnected, the entire
solution fails.

Error Control Processes

It is often assumed that the actual data in a data source is accurate and structured well.
However, years of experience with multiple data sources teaches that authoritative data
is not always available. If a data field is incorrectly populated or missing, then queries
and links will not work properly and the end user will experience an error. Many times
these errors will cause the return of a complicated RDMS (Relational Database
Management System) query error to the user. These errors can also cause the
application to fail.
Part of the design and development process is to anticipate these errors and provide
error control processes so that the application will not fail. For example, a component
was built that correlates Building IDs in a GIS database with Building IDs in an Asset
Management Database. The user simply selects a Building, and data from both data
sources is returned. However, if the Building ID information in either data source is input
incorrectly, the join query will fail, and an RDBMS error will be returned to the user. If
this error in data is not controlled, the application will fail. The simple solution is to build
an algorithm in the application that captures this error message, and returns a message
box to the user such as “Building Data does not Correlate, Please contact the GIS and
Asset Management Administrators”. More intelligence can be added to this algorithm,
and an email message could be sent to the data source administrators describing the
data correlation error.
Many integration systems do not take data source errors into consideration and it is
assumed that all data has been entered properly. The system design for data
integration must manage and control data entry errors in the underlying data sources.



Cached Data – More Details
Data is sometimes cached on the Server or on a Client Machine to improve
performance. This is done because some queries and reports required extensive joins
and are slow performing. These record sets can be cached, and retrieved by the user
when required.
Some graphic data (such as maps, floor plans, equipment location) are slow to process
on-the-fly. In these cases, pre-processed map tiles and floor plans are run via nightly
processes and stored on the web server. The files can then be quickly retrieved by the
user when needed.
Data can be cached on the client machine in order to greatly improve performance and
enhance the user’s experience. For example, for very large and detailed drawings, the
file would be cached on the client machine during the first data request. Then as the
user zooms and pans the drawing, or clicks on graphic symbols for attribution, the
application no longer sends a request back and forth to the server, but accesses the
graphics stored on the client’s local machine.
Another example of caching data on the client machine is for large arrays of list data. If
the user selected a floor plan with hundreds of occupants and equipment, the data about
all the room information would be cached on the local machine. As the user selected
rooms or equipment on their web page, the data would immediately appear since the
data is being retrieved from the users own machine, and requests are not being sent
over the network.
This list data may come from multiple data sources, but the stored list data would be
generated as a single array with all the data already correlated. For example, occupant
data could be retrieved from a personnel database and equipment data could be
retrieved from an asset database. The data, persons and equipment, are both physically
located in the same room and building. The data set lists would be blended and
correlated in a single array in memory on the client machine. The results are an
extremely fast return of information and an enjoyable experience for the user.
Reliability
Not only is performance enhanced by caching data, but reliability is also greatly
improved. If the network connection fails while operating the web portal, all is not lost.
The user still maintains much functionality since much of the data is already cached on
their local machine.
All of these background processes are not apparent to the user. The user simple selects
a pull down menu , button, hyperlink, or graphic element, and the data is retrieved and
displayed.
Post Processing
Post processing some data into various formats is used to improve performance.
Processing data into XML format (Extensible Markup Language) is the preferred type of
data transfer. XML is a textual data protocol. Currently, it is the standard for web
application data transfer. XML files are usually very small, and it is easy to perform post
processing of data into an XML file via a text scripting language such a PERL. Graphic
and map files are often post processed into XML format types such as SVG (Scalable
Vector Graphics), GML (Geography Markup Language), KML (Keyhole Markup
Language), etc.



SQL On-The-Fly
SQL on-the-fly is an integration method used to correlate data from two or more
databases that have related data values, but are in completely separate database
systems or networks. Each database is queried separately and data sets are returned to
the Server. These data set arrays are then manipulated and blended together via
scripting code. A new array of data values are collected, correlated, relayed, and
displayed on the Portal in various formats. Processing the data arrays and values can
be performed on the Sever or the Client Machine, or a combination of both. SQL on-the-
fly methods occur as the user requests data. Where possible, this method is used
instead of Data Warehousing, since data warehousing has associated maintenance
overhead.
Data Warehousing
If SQL on-the-fly or other integration methods cannot achieve integration, then
sometimes Data Warehousing can solve the problem. The basic concept of Data
Warehousing is to retrieve, analyze, extract, transform, load, and store data from
numerous data sources. It is a repository of data. For example, data may be contained
in various spreadsheets and in various formats. Processes and algorithms can be
developed that extract the data from the spreadsheets, and populate a well structured
relational database in a Data Warehouse. Then data can be simply queried from the
Data Warehouse using conventional SQL statements, and displayed on the Portal.

Benefits and Analysis of Methodology
Benefits
The benefits of implementing this methodology to data integration and BIM are multifold.
This approach will assist facility managers and stakeholders in the following areas:
 Allow for report generation in a timelier dynamic schedule
 Decrease manpower loading required to generate reports, allowing for time to be
spent on maintaining better data management
 Quicker response to data calls, therefore giving engineers and other users much
more time to attend to other issues
 Improve quality of reports generated
 Assist in making better decisions.
 Open access to correlated data sources to wider user base without the need for
specialized software or knowledge
 Ensures that reliable, authoritative data is readily available for meaningful
analysis while minimizing the redundancy in both information and processes
 Production of a detailed data model of all data accessed and used by
stakeholders improves visibility and accountability for data
 Leverages existing standard systems and applications and eliminates the need
for additional software or licensing implications
o No licenses or special software needed on the server or client desktops



o Intuitive navigation tools
o No special training
 Provides and open data integration platform where:
o Other front-end tools may be integrated. These front ends are merely
view ports into the data in the Integration Hub and provide another means
to navigate through the data.
o Other data sources may be easily linked, providing expanded data and
correlations.

Analysis – Integration Projects
The following are relevant references supporting the methodologies for data integration
of a BIM presented in this paper. Of primary relevance is Intergraph’s recent experience
with NASA Marshall Space Flight Center. Further evidence of our longevity in
supporting customer’s data integration needs is provided by a discussion of our work for
Navy Region Southwest.

NASA Marshall Space Flight Center
The approach to data integration and development of a BIM portal, detailed in this paper,
have recently been implemented for the Facilities Management Office at NASA Marshall
Space Flight Center (MSFC), Huntsville, AL.
The facilities enterprise data structure and the requirement for integration at Marshall are
very similar to the data requirements at many federal facilities. The data environment at
Marshall consists of a Maximo database for Asset Management, three GIS databases,
Space Management application including floor plans, Real Property, Security,
Equipment, Environmental, and a host of other databases, applications, and processes.
Intergraph’s involvement with the Marshall project started in 2004 and concluded in
2009. Marshall in-house staff is currently maintaining the Data Portal and Integration
Hub, a testament to the sustainability of the deployed solution.
There are 33 Data Sources that are accessed from the Marshall Portal. Approximately
one thousand (1,000) users currently utilize the BIM Portal to access and analyze data
from these various data sources. For example, a user at Marshall only has to select a
Facility Number from a pull-down list to obtain information about maintenance costs,
open Work Orders, Utilities, Photographs, Room Occupant data, Equipment information,
etc. Many of the separate Data Sources are joined on-the-fly, and the user simply
reviews reports that combine this information.
There is also a host of analytical tools available to the user. Various reports can be
generated and exported to spreadsheets, redlining capabilities, measuring tools, map
and floor plan plotting tools, etc. A detailed Data Model is maintained and tracks
changes in the overall data environment. Story Boards of every aspect of the application
were designed with the customer to insure that the end product would be exactly what
the customer needed. Numerous integration techniques were used to rapidly display
data on the user’s desktop.
The data integration project has literally transformed the working environment and
proficiency of the Facilities Management Office at Marshall. The data sources and data
maintenance process have basically remained the same, but now data is actually more



accurate, since data managers can now focus on their data, rather then constantly
having to answer numerous data calls. Managers, Engineers, Technicians and others
simply access the BIM Data Portal and retrieve their needed information.
As stated in the introduction of this document, the data integration techniques proposed
are not theoretical, but have been proven time and again to succeed. If this process is
implemented at a federal facility, it will revolutionize their data collection and business
workflows.

Cost Savings Analysis for MSFC
A cost savings analysis conducted at Marshall determined the amount of labor time and
costs that are saved since the implementation of the Data Portal.

Labor Cost Savings
Engineers, Technicians, etc. are required to collect and analyze data for various
projects. Before the implementation of the BIM Integrated Data Portal, the user would
have to obtain information such as Maximo reports, Maps, Floor Plans, etc. from various
sources for a particular project. The project might entail the rehabilitation of a facility, or
remodel, or a host of other issues. Most data had to be obtained via phone calls or
emails requesting the information. It was estimated that it could easily take at least 40
hours per project. A conservative estimate would be 1,000 projects per year for the
Facilities Department. Using an average cost per labor hour for NASA civil or contracted
workers of $110/MH, the cost for collecting data per year would be over $4 million
dollars.
Previous Costs: 40 Mh per Project X 1,000 Projects = 40,000 Mh X $110/Mh
= $4,400,000 Labor Costs for Data Collection
After the BIM Data Portal was implemented, it is estimated that it is taking users about 2
hours to collect, analyze, and report the same data.
Current Costs: 2 Mh per Project X 1,000 Projects = 2,000 Mh X $110/Mh
= $220,000 Labor Costs for Data Collection
The resulting savings in Labor Time is 38,000 Mhs per Year
The resulting savings in Labor Costs is approximately $4,180,000 per Year

Software Cost Savings
Another Cost Savings analysis was conducted to determine the savings from software
and license fees. The described methodology in this paper accesses data directly from
the underlining RDBMS (Relational Database Management Systems) and by other
means that does not require licenses for each user. Data is delivered to the user via a
web browser portal on their desktop, and a web server.
In the Marshall case, four (4) software licenses would be required to view the same data
available on the BIM Portal. The software products are Maximo, MicroStation, ArcGIS,
and TriRiga Space Management.
Costs of Software Licenses:
Maximo - $1,500 per seat
MicroStation - $800 per seat



ArcGIS - $1,500 per seat
TriRiga - $2,000 per seat
--------------------------------------
Total Cost = $5,800
Assuming the same 1,000 users, a cost savings of over $5 million results from
avoidance of software licenses.

Navy Region Southwest – Utility Department
A similar data integration and web portal project was conducted over a 6 year period for
the Utility Department of the Navy’s Southwest Region. At the time of the project, the
Navy’s Utility Department in San Diego, CA was responsible for the management of
Utility Distribution Systems for 23 Naval Bases and Housing Areas. Each of these 23
bases operated from 8 to 11 different Utility Systems. Maps of Utility systems, Buildings,
Roads, etc. were maintained by the Utility Department for all systems and their
corresponding Maximo Databases. The Data Enterprise Environment consisted of 23
separate GeoDatabases and 23 Maximo Databases. The data schemas for each base
were different depending on the Installation type.
Intergraph solved this data integration challenge by developing a Metadatabase Engine
that managed the data structure of these disparate systems. One web portal interface
was deployed that could access Maps, Facilities, Maximo, Electrical Components,
Schematics, etc of the entire Region. The user simply selected a Base from a Map or
Pull-down list, and the web page would be generated for the Base using the
Metadatabase. Data automation tools were developed to maintain the Metadatabase
and various Exception Reports and Data Correlation Tools were developed to maintain
the correlation between the GIS Databases and the various Maximo Asset Management
Databases.
The Data Modeling process, Storyboarding Methodology, and Integration Hub
Development described in this paper were used extensively for the Navy Region
Southwest Utility Department. Again, this approach and methodology were very
successful for the integration of a large and complicated data enterprise environment.

CMM – Capability Maturity Model
The Capability Maturity Model (CMM) described in National BIM Standard (NBIMS) is a
tool for BIM users to evaluate their practices and processes. The Standard also
describes how to rate the maturity level of a BIM. The CMM evaluates the degree to
which a BIM implementation measures up to a mature BIM Standard.
The CMM is a metrics with 11 area of interests, or characteristics. These areas of
interest include data richness, life-cycle views, change management, roles or disciplines,
business processes, timeliness/response, delivery method, graphical information, spatial
capability, information accuracy, and interoperability. Each area of interest is then rated
on its maturity level on a scale of 1 to 10, with 10 being the most mature.
The CMM then defines five levels of BIM Certification based on a point scale of 0 to 100.
Below 40 is considered not BIM Certified. 40 to 50 is the Minimum BIM level. 50 to 70



is a Certified BIM. 70 to 80 is considered a Silver Certified BIM. 80 to 90 is Gold, and
90 to 100 is Platinum.
To demonstrate and explain the CMM, the results from an independent evaluation of the
BIM Project at NASA MSFC (Marshall Space Flight Center) will be used. [2] This
evaluation rated the Marshall BIM as being 80% compliant (Silver Certification) to the
standard (NBIMS). In the following, each area of interest of the CMM is defined per the
NBIMS and then rated and related to the NASA MSFC BIM Application.
1. Data Richness: Having some level of expanded data collected so that the model is
a valuable source of information about a facility to a group other than the one
developing the information.
Rated 9: The BIM is used by many groups at Marshall and it contains data from over
30 sources. Valuable information about facilities and surrounding areas can be
obtained from the BIM Portal.
2. Lifecycle Views: A complete lifecycle project phasing does not need to be
implemented at this point.
Rated 6: The Marshall BIM was implemented decades after construction of most
buildings, and therefore does not contain all information of previous lifecycle phases.
3. Change Management: Note: Business process change management does not yet
need to be considered for a minimum BIM. However, it is the hope of the NBIMS
Committee that a change management process such as the Information Technology
Infrastructure Library (ITIL) program that provides a set of best practice approaches
to information management would be used. Using these business processes as your
basis will help ensure that everyone is working to converge their efforts. This will
help information flow. If it does not, there are procedures to rectify the problems.
Rated 7: The Marshall BIM is integrated to current business processes which
contain existing change management workflows. If data changes in the source
databases, that change is reflected automatically in the BIM. Also, a Configuration
Control process was established to manage changes in system configurations and
data connectivity. If source data schemas, software, or networking protocols are
changed, the BIM Portal and Integration Hub are re-configured to adjust to these
changes.
4. Roles or Disciplines: The basis for a BIM includes the sharing of information
between disciplines. A minimum level of information sharing is required between
designers such as the architect and structural engineer.
Rated 5: Information is accessed and shared between many disciplines from the
BIM application. The following are some of the many disciplines that distribute data
at Marshall: architects, mechanical engineers, maintenance, inspectors, security,
environmental, utility control, utility distribution, etc.
5. Business Process: Business process and information interoperability is the
cornerstone of BIM. The business process defines how business is accomplished. If
the data and information is gathered as part of the business process then data
gathering is a no cost requirement. If data is gathered as a separate process then
the data will likely not be accurate. The goal is to have data both collected and
maintained in a real time environment, so as physical changes are made they are
reflected for others to access in their portion of the business process. Only a


Bim For Existing Federal Facilities

Bim For Existing Federal Facilities

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (16)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Bim For Existing Federal Facilities

Ähnlich wie Bim For Existing Federal Facilities (20)

Bim For Existing Federal Facilities