ERDC/CERL CR-08-1 [DRAFT], COBIE Data Import/Export ... · COBIE Data Import/Export...

ERD

C/CE

RL

CR-0

8-1

[DR

AFT]

Installation Technology Transfer Program

COBIE Data Import/Export Interoperability With the MAXIMO Computerized Maintenance Management System

Nicholas Nisbet November 2008

Con

stru

ctio

n E

ngi

nee

rin

g R

esea

rch

Lab

orat

ory

Approved for public release; distribution is unlimited.

Installation Technology Transfer Program ERDC/CERL CR-08-1 [DRAFT] November 2008

COBIE Data Import/Export Interoperability With the MAXIMO Computerized Maintenance Management System

Nicholas Nisbet

AEC 3, Ltd. 30 Northfield Road Thatcham Berkshire RG 18 3ES United Kingdom

Final report

Approved for public release; distribution is unlimited.

Prepared for U.S. Army Corps of Engineers Washington, DC 20314-1000

Under Contract W9132T-08-P-0027

Monitored by Construction Engineering Research Laboratory U.S. Army Engineer Research and Development Center 2902 Newmark Drive, Champaign, IL 61822

ERDC/CERL CR-08-1 [DRAFT] ii

Abstract: The Construction Operations Building Information Exchange (COBIE) specification denotes how information may be captured during design and construction and provided to facility operators. COBIE elimi-nates the current process of transferring massive amounts of paper docu-ments to facility operators after construction has been completed. COBIE eliminates the need for post-hoc as-built data capture and helps to reduce operational costs. This contract report addresses technical issues pertain-ing to establishing effective COBIE data interoperability with MAXIMO, a computerized maintenance management system that is the standard tool for maintenance scheduling and tracking used by U.S. Army installation Directorates of Public Works.

DISCLAIMER: The contents of this report are not to be used for advertising, publication, or promotional purposes. Citation of trade names does not constitute an official endorsement or approval of the use of such commercial products. All product names and trademarks cited are the property of their respective owners. The findings of this report are not to be construed as an official Department of the Army position unless so designated by other authorized documents. DESTROY THIS REPORT WHEN NO LONGER NEEDED. DO NOT RETURN IT TO THE ORIGINATOR.

ERDC/CERL CR-08-1 [DRAFT] iii

Preface

This study was conducted for the Assistant Chief of Staff for Installation Management (ACSIM) under the U.S. Army Installation Technology Transfer Program (ITTP); Contract W9132T-08-P-0027 Task 1-8, “Con-struction Operations Building Information Exchange Computerized Main-tenance Management System Data Import/Export. The ITTP technical monitor for ACSIM was Kelly M. Dilks, CEERD-CF-N.

The work was performed by AEC 3 Ltd., Thatcham, UK, for the Engineer-ing Processes Branch (CF-N) of the Facilities Division (CF), U.S. Army En-gineer Research and Development Center – Construction Engineering Re-search Laboratory (ERDC-CERL). The ERDC-CERL project manager was Dr. E. William East, CEERD-CF-N. At the time of publication, Donald K. Hicks was Chief, CEERD-CF-N; L. Michael Golish was Chief, CEERD-CF; and Martin J. Savoie was the Technical Director for Installations. The Deputy Director of ERDC-CERL was Dr. Kirankumar Topudurti and the Director was Dr. Ilker Adiguzel.

COL Gary E. Johnston was the Commander and Executive Director of ERDC, and Dr. James R. Houston was the Director.

ERDC/CERL CR-08-1 [DRAFT] iv

Client name : ERDC-CERL

Full title of the existing Project : ifcMAXIMO Project version: v2008.09.23 Coordinating person : Nicholas Nisbet Coordinator Telephone number : +44 (1494) 714933 Coordinator email : [email protected] Coordinator fax : +44 (1635) 860673

MAXIMO Interoperability

CONSTRUCTION OPERATIONS BUILDING INFORMATION EXCHANGE COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEM

DATA IMPORT/EXPORT

Reference: W9132T-08-P-0027 Task 1-8

ERDC/CERL CR-08-1 [DRAFT] Page vi

ERDC/CERL CR-08-1 [DRAFT] Page vii

Contents

Introduction ...............................................................................................................1

Background ...............................................................................................................1

Strategy......................................................................................................................1 Database access vs Business-object interfaces............................................................. 1

Previous work: ifc-mbOMB..................................................................................................2 Previous work: ifcCOBIE .....................................................................................................3

Strategic review .............................................................................................................. 5 Review............................................................................................................................ 6

Maximo, Maximo Enterprise Adapter and Maximo Integration Objects ..............................6

Task 1: Maximo Interoperability...............................................................................9 Maximo Business Integration Objects ............................................................................ 9 Maximo Properties........................................................................................................ 10 Maximo Locations......................................................................................................... 11 Maximo Assets ............................................................................................................. 12 Object Mapping............................................................................................................. 13 Attribute Mapping.......................................................................................................... 14 Classification................................................................................................................. 15 Definition of an Asset.................................................................................................... 16 Asset definition ............................................................................................................. 16 Implementation ............................................................................................................. 18 Deliverables .................................................................................................................. 19 Validation and demonstration ....................................................................................... 20

Task 2: Asset Survey Work Order..........................................................................21 Implementation of 'Asset Survey Work Order’ forms................................................... 21 Export of Equipment Survey Order............................................................................... 21 Generation of field form and results.............................................................................. 22 Upload of asset survey results into Maximo ................................................................. 23

Summary and Conclusions ....................................................................................25

Acknowledgments...................................................................................................26

Appendices:.............................................................................................................27 Appendix 1: Sample batch file: ifcMaximo.bat <project> .............................................. 27

XSLT processing ...............................................................................................................27 Appendix 2: File list....................................................................................................... 28

Toolkit: ...............................................................................................................................28 Samples:............................................................................................................................28 Maximo MIO files*: ............................................................................................................28 Asset Survey Work Order:.................................................................................................28

ERDC/CERL CR-08-1 [DRAFT] Page viii

Appendix 3: Examples .................................................................................................. 29 Door / Asset .......................................................................................................................29 Item / Type.........................................................................................................................31 Location / Space................................................................................................................32 Vendor / Contact................................................................................................................34

ERDC/CERL CR-08-1 [DRAFT] Page 1

Introduction MAXIMO 6.2 is a CMMS product provided by IBM and used at U.S. Army Fort Lewis. It is supplied with Maximo Enterprise Adapter, which handles all import and export processes. IFC is the data schema and format for Asset information developed by buildingSMART. COBIE spreadsheet is a schema and format for Asset information developed by USACE ERDC CERL for the manual gathering of handover information. In order to manage these alternate Asset representations, the ifcMAXIMO project examined methods for the efficient and generic mapping between these two systems. This anticipated that the project might result in a specific application, or a set of configuration steps and files to be introduced to an existing Maximo installation.

Background

The U.S. Army Engineer Research and Development Center-Construction Engineering Research Laboratory (ERDC-CERL) has, in conjunction with the National Building Information Model Standard (NBIMS) project, developed an information exchange standard to assist in the electronic transfer of construction documents and information to facility operators. The standard, "Construction Operations Building Information Exchange (COBIE)", has been developed based on the Industry Foundation Class (IFC) model. To facilitate the use of the standard for small maintenance and renovation projects the model needed to be extended to support the import and export of data from Computerized Maintenance Management Systems (CMMS).

Strategy Interfacing to a CMMS such as Maximo could be achieved by two paths

(a) Accessing the underlying proprietary database (b) Using the provided business-object interfaces.

Both strategies were used in the ifc-mbOMB project, and the following factors remained relevant when choosing between the two strategies: Database access vs Businessobject interfaces Accessing the underlying proprietary database offered substantial flexibility, but only by accessing and updating one table at a time.

(a) Might have proved dependant on the proprietary database implementation (SqlServer/Oracle)

(b) Might have proved dependant on release versions and local configurations of the CMMS (c) Might have destabilized the existing installation with incomplete or erroneous fields (d) Might not have proved acceptable to facility CMMS managers


Using the provided business-object interfaces, with existing or new business objects, could have implied some loss of flexibility but was seen to offer

(a) Comprehensive security and transaction management (b) Automatic validation and checking of data (c) Detailed logs and reports (d) Simplified updates to multiple tables.

Previous work: ifcmbOMB The consultants had provided technical coordination and development for a demonstration project in 2003-2005 in the UK called ifc-mbOMB - ifc-model based Operations and Maintenance of buildings. This project re-enacted the whole design process of a tertiary college and particularly the auditorium, including room-briefing, layout, detailing, environmental analysis, air-flow requirements, grille layout, ductwork layout and finally product selection and substitution. The purpose was to show how using an IFC and a model server could accelerate the process and could capture more of the information needed for Asset management. The final demonstration showed all the information captured being transformed into Maximo version 5. The consultants developed an IFC to Maximo translation in 2003/4 . This was part of the UK IFC model based Operation and Maintenance of Buildings (ifc-mbOMB) project which was a Government/Industry jointly funded investigation into the impact of the IFC model held on a model server. It was used to orchestrate the briefing, architectural, energy analysis, systems engineering and product selection processes. The partners included Taylor Woodrow Construction ( a major UK contractor), AEC3, several design software developers, and MRO Maximo (now IBM Maximo). The final demonstration included populating Maximo with ALL the information associated to the site, building, storeys, and assets, including the design specifications and their actual characteristics and operational steps - in five minutes. This was achieved by mapping the IFC model to the Maximo data structure in the most generic way possible. While an actual implementation might want to consider filtering the data, it was significant that the Taylor Woodrow FM representatives were most animated when they realized that they would be receiving detailed information about the design intent - such as the peak summer time temperature for a space, which was then available to guide them to check if a system truly was under-performing or not. In the ifc-mbOMB project, the business object interfaces were used for seven of the eight transactions: the SQL script was used where there was no business object interface possible.


Previous work: ifcCOBIE The consultants had provided technical coordination and development for a command line tool that mapped between the COBIE spreadsheet and buildignSMART IFC asset representations. This application generates ifcXML as an intermediate format that can be further transformed if required. The ifcXML schema and samples are available at http://www.iai-tech.org/ifcXML/IFC2x3/FINAL and there is an implementers guide available. ifcXML is an exact derivation of the IFC Express schema, and the major toolkits can read or write both IFC STEP and ifcXML. Of the BIM vendors Nemecheck and ArchiCAD read and write ifcXML, and Autodesk and Bentley are being encouraged to follow suit. IFC STEP remains the preferred format for whole building models, but ifcXML is more acceptable for smaller data-sets and for interfacing with other systems such as Maximo.

http://www.iai-tech.org/ifcXML/IFC2x3/FINAL�

http://www.iai-tech.org/ifcXML/IFC2x3/FINAL�


Strategic review A project meeting was held in February 2008, with the following attendees:

• Bill East ERDC • Beth Brucker ERDC • Lyle Fogg Ft. Lewis, WA • Oliver Kipf IBM, Germany (by telephone) • Nick Nisbet AEC3, UK

The project objectives were represented as a diagram and the two components for solution identified.

This initial diagram was the created at the initial intense consensus building meeting between the project owner, the DWP team from Fort Lewis and the application consultants. It took into account the need to create a solution which

• Could be used out-of-the-box at any Maximo installation. • Could potentially be applied to other CMMS solutions apart from Maximo • Could be integrated alongside existing workflows using Syclo and Maximo at Fort

Lewis. • Could be integrated with standard hand-held devices.


The initial diagram was revised to reflect the priorities identified and the division of the project into two distinct tasks.

• Firstly it was necessary to take COBIE and/or buildingSMART data and ensure this

could be loaded into Maximo. ifcXML was taken as the common available form of both asset representations.

• Secondly, hand-held devices could use ‘active’ Adobe Acrobat PDF forms to acquire structured updates. Such forms could be generated from work orders generated by Maximo, by transformation.

Review Maximo, Maximo Enterprise Adapter and Maximo Integration Objects In order to make the solutions applicable to the widest range of Maximo installations, the project implementation plan called for the use of the out-of-the-box facilities offered by Maximo 6.2 including Maximo Enterprise Adapter (MEA) . This facility offers the potential for continuous and on-demand upload and/or download of Maximo data by means of well controlled Maximo


Integration Objects (MIO). The Maximo Integration Objects are defined as XML schemas and implemented as XML data files. Sevices associated to the MEA allowed pre-transformation of incoming data and post-transformation of out-going data. Queue services handle access-rights and error issues. Published material relating to MEA and the Maximo Integration Objects (MIO) was reviewed, and where possible material was extracted to anticipate the configuration of the MEA. Throughout the project it remained an issue that the documentation of the out-of-the-box MEA facilities was not accessible to potential users except through direct liaison with the solution provider, which was initially conditional on being a licence holder. Some support was given towards the end. A comparison diagram of the COBIE, buildingSMART and Maximo object models was prepared. This illustrates that while there is a simple relationship between most COBIE, buildingSMART and Maximo objects, there are areas where the alignment created the potential for implementation issues.

Firstly, COBIE’s concept of REGISTER spans item types and other requests. Between COBIE and buildingSMART, the Register contained many required submittals, of which one kind was ‘Product data’. Only this ‘product data’ submittal requirement corresponded to the existence


within buildingSMART of named types. This had been addressed in the separate development of IFC COBIE mappings and the ifcCOBIE application. Secondly IFC’s concept of the instance spanned Maximo’s two concepts of LOCATION as the spatial location and ASSET as the physical asset that may (potentially) be rotated with other spare assets.


Task 1: Maximo Interoperability

Maximo Business Integration Objects Mappings between IFC objects and Maximo MIO were developed. The following table shows three Maximo business objects and their derivation from IFC.

• Maximo ITEMS correspond to IFC Type Objects and COBIE Registered ‘Product Data’ Submittal Requirements.

• Maximo OPERLOCS correspond to the IFC project, site, building, storey and spaces, but also to the locations of instances that have a type definition.

• Maximo ASSETS correspond to the physical occurrences of instances that have a type definition.

• A fourth business object was used to relate the occasional naming of suppliers in IFC

with their formal registration as COMPANIES within Maximo.


Maximo Properties Mappings between IFC attributes and Maximo MIO fields have developed. The following table shows several Maximo fields and their derivation from IFC.

LOCATIONS and ASSETS require a unique identifier. These are used in the interface for identifying assets and locations and internally for creating the linkage between them. In conventional usage, MAXIMO has been populated ‘by hand’ and these identifiers have been hand-crafted to satisfy this dual use. Data generated from IFC or COBIE is not subject to this manual review and the tension between these two purposes and the balance of priorities was ultimately irresolvable without a specific project. For example U.S. Army standards may mandate shorter 5 character codes by the ‘RPER’ standard for use elsewhere.

Issue: The recommendation remains that the best choice where data reuse is required is to use the unique 22 character Global Identifier provided by IFC. If the data transfer is a one-off transfer, then other identifiers may be used, such as the shorter locally unique identifier provided by XSLT transformation engines.


Maximo Locations

The set of MIO files needed to include creation of Maximo objects representing the ‘operational location’, which is a spatial and instance hierarchy going back to the root ‘project’ location. Of the many optional properties available on the LOCATION record, only those highlighted in solid red were likely to be available. The warranty expiration date (highlighted in dashed red) was disregarded, as this information was mapped to the ASSET


Maximo Assets

A second MIO represents the assets currently occurring at the location. For example a Door may be located on a specific Floor, and that Door location contains a Door Asset. The mandatory properties are highlighted in solid red, and the significant asset properties in dashed red.


Object Mapping The COBIE / Maximo mappings were reviewed and agreed. The IFC mappings were adopted unchanged from the ifcCOBIE project. COBIE Worksheets Maximo Tables

1 Contact Company Design

2 Facility Locations 3 Floor Locations 4 Space Locations 5 System System 6 Register Item 7 Component Asset 8 Attribute Specification template (not in scope) 9 Coordinate Locations (not in scope)

Submittal 10 Schedule n/a 11 Document attached documents 12 Transmit n/a 13 Approve n/a

Installation 14 Installation Asset 15 Manual attached documents 16 Warranty Asset 17 Spare Inventory

Commissioning 18 Instruction attached documents 19 Test attached documents 20 Certification attached documents

Job Plan Resource 21 Material Job plans / Inventory 22 Tool Job plans / Tools 23 Training ???

Job Plan Task 24 PM Preventive maintenance 25 Safety Safety plans 26 Trouble Job plans 27 Start-Up Job plans 28 Shut-Down Job plans 29 Emergency Job plans


The minimal attributes required to be associated to an Asset or a Location are limited, and can be generated directly from the buildingSMART data. Most importantly, every location and asset will be keyed on the buildingSMART globally unique identifier. It was also necessary to enforce the use of common standard keys:

o ASSET.LOCATION must match a LOCATIONS.LOCATION o ASSET.ITEMNUM must match an ITEM.ITEMNUM o ASSET.MANUFACTURER must match a COMPANIES.COMPANY

Attribute Mapping There was no requirement to transmit arbitrary properties from COBIE or from IFC data, as these are open-ended until controlled by the definition of specification templates, which in turn as dependant on the Maximo classification structure. Other attributes can only be associated to an asset if they occur in a template relevant to the classification of that asset. This would require a pre-configuration of one large template (associated to the top-level classification) or a pre-configuration of many templates, each associated to a classification such as ‘Door’. As an example, such a template would include ‘OverallHeight’ and ‘OverallWidth’ which are always defined for a ‘Door’ instance, but might also include ‘FireRating’ which may be discovered to have been used. Mappings of attributes and properties was restricted to those explicitly defined as asset fields in Maximo and confirmed as being required by the client team. An asset has optional five attributes which are directly relevant to a handover process and were obtained by querying the relevant buildingSMART object :

• Serial Number • Manufacturer • Warranty Expiration Date • Acquisition Date • Replacement Cost

The following table shows these five Maximo asset attributes and their derivation from IFC. Values may be found on either on the instance or on the defining type.


Classification

The initial intention was to support the transmission of classification information from COBIE and IFC. However issues arose that made this impractical and outside of the agreed scope.

• Issue: Classification references were not included in the out-of-the-box Maximo Integration Objects for ASSETS, LOCATIONS nor ITEMS. The out-of-the-box Maximo Integration Objects for CLASSSTRUCTURE was insufficient to allow the uploading of classification tables. A second table of CLASSIFICATION data was also strongly interrelated with the other file and was not available as a Maximo Integration Object. Due to the intererelation of these tables, special repetitive parsing was required to load classification data.

It is recommended that the pre-population of Maximo with industry standard classification systems such as the Omniclass tables should pursued as a separate industry initiative. Much of the information content currently likely to be assigned to the classification system is in any case transferred to the ITEM table which represents the unique kind of part used .


Definition of an Asset The mappings that were to be created need to implicitly answer the question as to a working definition of an asset, irrespective of site-specific policies. Any site-specific policies could if necessary be implemented within a revised transformation or afterward. In the context of Maximo, it is anything entered in the ASSET table. In the context of COBIE, it is anything referencing the Register table for “Product Data” and occurring in the Components and Installation tables. In the context of IFC, it is any instance defined by a type object

It may be equally useful to declare the implication of these working policies for what is not an asset. In the context of Maximo, any empty operational location or spares. In the context of COBIE, it is any facility, floor, system or space or spare parts. In the context of IFC it is any element defined only by material, classification or reference code.

The delivered tool implements a generic test to determine if an instance is an asset worthy of representation within Maximo: It must be a physical object, excluding for example spaces. It must be located within the spatial hierarchy excluding for example virtual boundaries, or constituents of an assembly. It must be defined by a named type-object, for example from a simple buildingSMART model this extracts as assets:

• Door defined by a Door Style • Window defined by a Window Style • Flow Terminal defined by a Light Fixture Type or other type.

Similarly the tool implements a generic test to determine if an instance is a location worth representing within Maximo: It may be an asset location (see above), it may be the overall Project, or it may be a disaggregation of the Project into

• Site, • Building, • Floor, • Space.

Effects of Asset Definition The following illustrates the effect of using the working asset definition on an asset model: The following are not considered assets, as they have no type definition:

• SLAB • WALL • BUILDING ELEMENT PROXY

The following are considered assets, with type definitions as shown:

• DOOR DOOR STYLE o D1 o D3 Sliding

• WINDOW WINDOW STYLE o W Double Hung


• FLOW CONTROLLER DAMPER TYPE o DM2001 Zinc plated irisdamper 80 mm L=100 o DM2012 Zinc plated smokedamper 80 mm L=100

• FLOW FITTING DUCT FITTING TYPE o GTYPE BE2000 Circular zinc plated bend 90° o BE2000 Rectangular zinc plated bend 90° o BE2001 Circular zinc plated bend 90° o CH2000 Circular transition zinc plated > 800 o LI2000 Stop End circular zinc plated 1250mm o LI2000 Stop End rectangular zinc plated o TA2000 Transition - rectangular to rectangular 200x100 o TP2001 Circular outlet 63 mm o TP2004 Circular tee-part 63 mm o TP2004 Rectangular tee-part 200x100 o VenEndDuct

• FLOW MOVING DEVICE FAN TYPE o GF2500 Copy of Free self-defined AHU box (parametric) 4x2x2 m

• FLOW SEGMENT DUCT SEGMENT TYPE o SS0001 Circular duct zinc plated 63 mm o SS0001 Circular duct zinc plated 80 mm o SS0001 Circular duct zinc plated 100 mm o SS0001 Circular duct zinc plated 160 mm o SS0001 Circular duct zinc plated 200 mm o SS0001 Circular duct zinc plated 500 mm o SS0002 Rectangular duct zinc plated 500x400 o SS0002 Rectangular duct zinc plated free dim

• FLOW TERMINAL AIR TERMINAL TYPE o GV2251 Supply Air Terminal rectangular w. rect. plenum 125 mm o GV2351 Evacuation Air Terminal circular w. circ. Plenum 125 mm o GV2351 Supply Air Terminal circular w. circ. plenum 125 mm

• FLOW TREATMENT DEVICE FILTER TYPE o FL2001 Air filter zinc plated


Implementation Following on the example of AEC3’s ifc-mbOMB project (2004), it remained the case that a COBIE spreadsheet or buildingSMART IFC file cannot be represented by just one MIO file for upload to the MEA.

• Pre-configuration may be required. • COMPANIES and ITEMS must be pre-loaded • OPERLOC and ASSETS must be loaded separately in sequence.

Maximo MEA ‘out-of-the-box’ supports the MIO needed:

• MXVENDOR accepts company names • MXITEMS accepts an item hierarchy. • MXOPERLOC accepts the spatial and instance hierarchy. • MXASSET accepts the instance collection.

The set of MIO files may need to include pre-configuration of Maximo with data that is determined by the specific buildingSMART model being imported.

• Any COMPANIES referenced by O&M data on the buildingSMART instances found

must exist or be created. • Abstract part ‘ITEM’ lists must be created based on the buildingSMART instances found,

for example “Door Style D-1” is part type for some instances of “Door” in a specific facility.

• Allocation of assets to systems also requires the pre-configuration of the system hierarchy. In the absence of any system allocation, assets can be assigned to the ‘PRIMARY’ root system, provided by Maximo.


Deliverables The deliverables were defined as a result of the technical strategy and fall into two sections: firstly the pre-requisites, and secondly the required transformation tools. The pre-requisites for interoperability are:

• The availability of four standard MIOs: o MXVENDOR o MXITEMS o MXOPERLOC o MXASSETS

• Some Pre-configuration: o Fields used to hold the unique identifier will need to be typed to accept 22

character alphanumeric, not 12 character upper-case: ASSET.ASSETNUM LOCATIONS.LOCATION

o This impacts other keys and indexes. See Maximo Technical Reference 6

Version 2 Table 1 and search on the two fields named. However the change can be effected through the system administrators’ interface. See Maximo System Administrators Guide version 6.2 chapter 4 page 4-12

o The transformation makes six assumptions at the head of the definition which

can be edited but which are believed to be reasonable within a generic Maximo installation:

siteid BEDFORD userid MAXIMO orgid EAGLENA vendorid V systemid PRIMARY setid SET1

The transformation tools can be summarized:

• It is assumed that ifcCOBIE has been used to generate the ifcXML representation. o ifcCOBIE <project>.ifc (from buildingSMART IFC STEP) o ifcCOBIE <project>.xml (from COBIE spreadsheet)

• A batch file to provide the file names and the ‘pass’ parameter to a selected XSLT engine.

o ifcMAXIMO <project> • The parameterised XML transformation (XSL) authored to generate four MIO files. The

one parameter ‘pass’ controls which MIO file is generated. This query is controlled by the batch file and can therefore rapidly test proposed solutions on smaller models.


Validation and Demonstration At the COBIE interoperability demonstration held at the National Academy of Sciences in July 2008 the Maximo interoperability tools were demonstrated to an audience of Federal facility clients and industry experts. The demonstration covered both Spatial Compliance and Constreuction Operations and Building Information Exchanges. Further development including responding to some lessons learned were implemented after this event, but a comprehensive transfer was achieved. Maximo SCIE and COBIE upload via IFC Software Name: Maximo Software Version: 6.2 Optional configuration(s): MEA Support information: Contact Maximo Files imported See file summary in appendix Objects read: 0-Vendor • Manufacturer (as needed) (COBIE 01-Contacts)

1-Item • Type Object (COBIE 06-Submittals)

2-Operloc • Project (SCIE 02-Facility) • Site (SCIE 02-Facility) • Building (SCIE 02-Facility) • Building Storey (SCIE 03-Floor) • Space (SCIE 04-Space) • Building Elements (having Type Objects) (SCIE 07-

Components, 06-Submittals) 3-Asset • Building Elements (having Type Objects) (COBIE 07-

Components) • SERIAL NUM • MANUFACTURER • REPLACE COST • INSTALL DATE • WARRANTY EXP DATE

Additional Comments: The sample file submitted included architecture spaces, equipment and serviced terminals.


Task 2: Asset Survey Work Order Implementation of 'Asset Survey Work Order’ forms. During the Feb 2008 meeting in Chicago it was determined that an export from MAXIMO would be created that contains the existing information relating to an asset. This exported file would be created to allow it to be read as Adobe Smart Form that could be updated as the work order is being completed. Once completed the form would be submitted, using a generic XML format, to MAXIMO to update the equipment data.

Export of Equipment Survey Order The first step envisaged the export of an extended MIO for Equipment Survey Order for specific equipment items. This should be a comprehensive export for one asset:

• with Location information • with Item type information • with Asset information • with five key asset attributes

No such export from Maximo was been generated by the Maximo support team nor the Fort Lewis DWP team. Assurances have been received that this is possible using MEA.


Generation of field form and results Given the work order in MEA MIO form, it can be transformed into xml representation of Active PDF form and then compiled. It would be issued attached to a conventional electronic work order and used by the operative to confirm the description and numeric values associated.


Upload of asset survey results into Maximo On completion of the work order, the operative would send the resulting data electronically to the MEA server. The data would be recognized as ifcXML and transformed to create the update MIO objects necessary. Typically this would be an ASSET update.

The main page lists the editable descriptive and asset properties in bold. The names and types are not editable as these are sued to relate the changes to the CMMS existing records.


A second page offers guidance and support for the operative .


Summary and Conclusions It has been shown that COBIE, IFC and Maximo asset representations can be made interoperable. This means that any asset documented in IFC or COBIE can be loaded into a CMMS system before or at the time of handover. The effectiveness of using ifcXML as the common representation when routing between systems has been shown. XSLT has been shown to be an easily maintained and efficient tool for transforming flavours of XML, even where complex data structures are being used. Issues raised by this work include whether interoperability can remain the domain of vendor specialists when the requirement is for generic, cost-effective solutions. In particular the tradition of hand-crafted one-off solutions has been to focus on the minimal acceptable volume of data transfer with the acceptance of user-selected names. If whole buildings models are to be used to populate and then interact with CMMS solutions then more attention is needed to the implications for users of absorbing large volumes of free but valuable data. In particular, industry classifications (such as Omniclass) must become ubiquitous and easily preloaded where needed. This project focused on the primary tables, namely vendors, items, assets and locations. As COBIE and IFC become more prevalent, the scope of asset documentation and handover will improve and more objects may need to be mapped, for example maintenance procedures and prerequisite parts and skills. The interoperability tools used are open and further capability can be added as required. Nicholas Nisbet London September 2008


Acknowledgments The following made significant contributions to the project and are thanked.

• Bill East ERDC • Beth Brucker ERDC • Lyle Fogg Ft. Lewis, WA • Scott Gregory Ft. Lewis, WA • Nick Nisbet AEC3, UK • Oliver Kipf IBM, Germany • Terrence D Nicholson IBM, US • Ron Lanzo IBM, US


Appendices:

Appendix 1: Sample batch file: ifcMaximo.bat <project> ifcMaximo takes the name of the project (without extension) as its only argument. echo off set f1=%1 set t1=ifcMaximo set s0=%f1%_0_vendor set s1=%f1%_1_item set s2=%f1%_2_operloc set s3=%f1%_3_asset set ex= java -jar ./saxon9.jar -novw dir "%f1%.ifx" /b echo Processing %f1 %ex% -s:%f1%.ifx -xsl:%t1%.xsl -o:%s0%.xml pass=0 %ex% -s:%f1%.ifx -xsl:%t1%.xsl -o:%s1%.xml pass=1 %ex% -s:%f1%.ifx -xsl:%t1%.xsl -o:%s2%.xml pass=2 %ex% -s:%f1%.ifx -xsl:%t1%.xsl -o:%s3%.xml pass=3 dir "%f1%_*.xml" /b echo Completed processing %f1

XSLT processing saxon9.jar (used in the script above) is one of many freely available XSLT 1.0 processors. They vary in how they expect the command line arguments to be offered, but all accept an input file, a transformation file, an output file and the passing-in of parameters. A fully configured Maximo installation has its own facilities for transforming files as part of the MEA pipeline.


Appendix 2: File list

Toolkit: ifcMaximo.bat sample batch script ifcMaximo.xslt ifc to Maximo transformation

Samples: bce3.ifc the original building model for the building in the STEP form of IFC. bce3.ifx the original building model for the building in the XML form of IFC. bce3.pdf a PDF interactive representation of the building. bce3.log a non-graphic report on the model. bce3.xml the building model transformed into COBIE

Sheets 01-09, 14, 16 and 17 contain data.

Maximo MIO files*: bce3_0_Vendor.xml bce3_1_Item.xml bce3_2_Location.xml bce3_3_Asset.xml * the number indicates the recommended sequence for loading. Asset Survey Work Order: aswo.pdf Sample distributable form aswo.lpx Sample form definition aswo_data.xml Sample data submission


Appendix 3: Examples

Door / Asset

COBIE: 07-Component

IFC: IfcProduct <IfcDoor id="i55787">

<GlobalId>0FyzQQz1f5KhmT8Kk5EpbU</GlobalId> <OwnerHistory> <IfcOwnerHistory xsi:nil="true" ref="i29"/> </OwnerHistory> <Name>D18</Name> <ObjectPlacement> <IfcLocalPlacement xsi:nil="true" ref="i24638"/> </ObjectPlacement> <OverallHeight>2032.</OverallHeight> <OverallWidth>609.6</OverallWidth>

</IfcDoor>

Maximo: ASSET

<MXASSET> <ASSET> <ASSETNUM>d1e251821</ASSETNUM> <SERIALNUM>S1212</SERIALNUM> <LOCATION>BCE3/S2501/BCE3/L0/d1e251821</LOCATION> <DESCRIPTION>Door DoorStyle D1</DESCRIPTION> <MANUFACTURER>Duxford Doors Inc</MANUFACTURER> <REPLACECOST>103.00</REPLACECOST> <INSTALLDATE>2008-08-10T12:34:56Z</INSTALLDATE> <WARRANTYEXPDATE>2012-08-09T12:34:56Z</WARRANTYEXPDATE> <ITEMNUM>DoorStyle , D1</ITEMNUM> <SITEID>BEDFORD</SITEID> <DESCRIPTION_LONGDESCRIPTION>

Door DoorStyle D1 </DESCRIPTION_LONGDESCRIPTION>

<ASSETTYPE>Door</ASSETTYPE> </ASSET>

</MXASSET>

Commentary:

• ASSETNUM uniquely identifies the ASSET in IFC, COBIE and Maximo • SERIALNUM identifies the manufacturers plate mark of the asset • LOCATION points to an entry in the location hierarchy of spaces, floors,

facilities etc • DESCRIPTION describes the ASSET in abstract terms. • MANUFACTURER points to an entry in the list of a companies • REPLACECOST puts a value on the asset • INSTALLDATE puts a start date on the object • WARRANTYEXPDATE puts an end date on the warranty • ITEMNUM points to an entry in the list of abstact typeobject/register/item types • SITEID points to an entry in the list of managed site centers


• DESCRIPTION_LONGDESCRIPTION gives a description of the specific instance.

• ASSETTYPE gives a quick search term .


Item / Type

COBIE: 06-Register

IFC: IfcTypeProduct

<IfcDoorStyle id="i56750"> <GlobalId>2spT5MN6P06uAgWmhIy0kb</GlobalId> <OwnerHistory> <IfcOwnerHistory xsi:nil="true" ref="i29"/> </OwnerHistory> <Name>D1</Name> <HasPropertySets ex:cType="set"> <IfcDoorLiningProperties pos="0" xsi:nil="true" ref="i56662"/> <IfcDoorPanelProperties pos="1" xsi:nil="true" ref="i56706"/> <IfcPropertySet pos="2" xsi:nil="true" ref="i53135"/> </HasPropertySets> <OperationType>single_swing_left</OperationType> <ConstructionType>notdefined</ConstructionType> <ParameterTakesPrecedence>true</ParameterTakesPrecedence> <Sizeable>false</Sizeable>

</IfcDoorStyle>

Maximo: Item <MXITEM>

<ITEM> <ITEMNUM>DoorStyle , D1</ITEMNUM> <DESCRIPTION>Door DoorStyle D1</DESCRIPTION> <ROTATING>1</ROTATING> <LOTTYPE>NOLOT</LOTTYPE> <ITEMSETID>SET1</ITEMSETID> <DESCRIPTION_LONGDESCRIPTION>

Door DoorStyle D1 </DESCRIPTION_LONGDESCRIPTION>

<CONDITIONENABLED>0</CONDITIONENABLED> <ITEMTYPE>ITEM</ITEMTYPE> <TRANS_LANGCODE>EN</TRANS_LANGCODE> </ITEM> </MXITEM>

Commentary:

• ITEMNUM uniquely identifies the type in IFC, COBIE and Maximo • DESCRIPTION gives a description of the type • ITEMS are automatically discovered for the specific facility, such as: • Door DoorStyle D1. • Correction: PARENT is not a field for ITEM


Location / Space COBIE: 04-Space

IFC: IfcSpatialStructureElement <IfcBuildingStorey id="i25221"> <GlobalId>3wfOgHmvr0Jg$WeC$fmevh</GlobalId> <OwnerHistory> <IfcOwnerHistory xsi:nil="true" ref="i29"/> </OwnerHistory> <Name>Roof</Name> <ObjectPlacement> <IfcLocalPlacement xsi:nil="true" ref="i24758"/> </ObjectPlacement> <CompositionType>element</CompositionType> <Elevation>3352.8</Elevation>

</IfcBuildingStorey>

Maximo: OPERLOC

<MXOPERLOC> <LOCATIONS> <LOCATION>BCE3/S2501/BCE3/Roof</LOCATION> <DESCRIPTION>

Project BCE3 Immune Building Project Site S2501 Facility 2501 Building BCE3 Immune Building BuildingStorey Roof Roof level </DESCRIPTION>

<TYPE>OPERATING</TYPE> <CHANGEBY>MAXIMO</CHANGEBY> <CHANGEDATE>

2008-08-18T12:34:56Z </CHANGEDATE>

<DISABLED>0</DISABLED> <SITEID>BEDFORD</SITEID> <ISDEFAULT>0</ISDEFAULT> <DESCRIPTION_LONGDESCRIPTION>

Project BCE3 Immune Building Project Site S2501 Facility 2501 Building BCE3 Immune Building BuildingStorey Roof Roof level 3wfOgHmvr0Jg$WeC$fmevh </DESCRIPTION_LONGDESCRIPTION>

<PARENT>BCE3/S2501/BCE3</PARENT> <STATUS>OPERATING</STATUS> <SYSTEMID>PRIMARY</SYSTEMID> <HASPARENT>1</HASPARENT> <TRANS_LANGCODE>EN</TRANS_LANGCODE> </LOCATIONS>

</MXOPERLOC>

Commentary: • LOCATION uniquely identifies the location in IFC, COBIE and Maximo. • DESCRIPTION on locations should be specific to the instance. • TYPE is fixed as OPERATING • SITEID points to an entry in the list of managed site centers • PARENT points to an entry in the list of locations • ITEMNUM points to an entry in the list of abstract type object/register/item types • SYSTEMID points to an entry in the list of systems. • The hierarchy of LOCATIONS is created automatically, such as

o Project Building


• Floor o Space

Asset location


Vendor / Contact COBIE: 01-Contact

IFC: IfcPropertySingleValue

<IfcPropertySingleValue id="i51247"> <Name>Manufacturer</Name> <Description>

The organization that manufactured and/or assembled the item. </Description> <NominalValue> <IfcLabel>Brighton Metal</IfcLabel> </NominalValue>

</IfcPropertySingleValue>

Maximo: VENDOR <MXVENDOR> <COMPANIES> <COMPANY>Brighton Metal</COMPANY> <TYPE>V</TYPE> <ORGID>EAGLENA</ORGID> </COMPANIES> </MXVENDOR>

Commentary: • TYPE classifies the vendor as a vendor. • ORGID points to an entry in the list of organizations

Concluded.

ERDC/CERL CR-08-1 [DRAFT], COBIE Data Import/Export ... · COBIE Data Import/Export...

Documents

Transcript of ERDC/CERL CR-08-1 [DRAFT], COBIE Data Import/Export ... · COBIE Data Import/Export...