Would the design and construction process benefit from generating the Building Owners manual / Operations and Maintenance Manuals using the building asset data? If this is possible then would it also work for the Building Log book, Health and Safety file?
Please don’t think this is a magic bullet the axiom “rubbish in rubbish out” still holds truth. You can’t report on data that isn’t there, what you can do is quickly highlight what is missing and fix it.
To accomplish this the reader will have to accept that the O&M Manuals are reports of the data. Swaths of narratives have to be treated as being part of the data set. If there are any efficiencies to be gained then this will come from a process that relies on data sources being created once and then used in different reports many times. The alternative is for individuals to capture information and author a document or series of documents which will have to be manually updated to maintain consistancy.
A big problem for the design/construction team in delievering asset data for the building owner to run and operate the facility is knowing what is created is actually of any value. The standard for this delievery of data is in the BuildingSMART schema called COBie. Typically delievered as a spread sheet which means it can be viewed, appended or amended using a spreadsheet application. Generating more than just the specific needs of the operations and maintenance systems goes beyond the purpose of COBie requirements as content. However the Building owner can ask for any information to deleivered as they will know what is important to them.
Putting aside any referential integrity issues how would we know the data has any value? The answer is we don’t until someone tries to use it.
COBie is seen as a requirement of the client to feed the Operations and Maintenance applications, the only way of testing data is if the client has provided an Asset Information Requirement specification or defaults to the COBie standard requirement developed for design and construction see checkers below.
In our work populating PPM systems specific requirements have to be defined so that fields are of the right type and length. Mapping cobie schema fields may lead to problems where the data type is wrong or length is exceeded. AIR’s become critial to the process as they should identify exactly what is required.
This AIR specification provided as a document has to be translated into a form of digital rule checking. However checking narrative content by machine would require AI technology like those available as services in IBM’s Watson or Microsoft’s Luis. It occured to me that one of the best ways to check content was to put it into a form that is easy to read, a document.
Technical submissions, submittals, Product Data sheeets would be a good example of using the data. The benefit over manual authoring is that anyone can generate it and it would always be to the same standard. The methodology I used was to look at what I wanted in the document and then work out where it would come from in the cobie schema.
What are the primary data sources?
Building Information Modeling, BIM, promises to achieve efficiencies in the design and construction of facilities. Co-ordination, consistent documentation and informative information with connected data. The deliverable digital data sets for the building owner are defined as:
- A Co-ordination model will typically be some sort of 3 dimensional geometry model required in either the native format or the open standard buildingSMART IFC.
- A Handover model will be the Asset information in a data format that can be read by the building owners systems. This is partly derived from the coordination model and may be in either a specified data format or the open standard buildingSMART COBie.
A Co-ordination model is used to great effect within the construction process but the Handover model seems evoking a call for extra fees.
Why are O&M’s required?
The UK building regulations require that projects provide a Building Log book and the CDM regulations require a Health and Safety file. Typically the contents of the building log book draw on the contents of O&M’s.
For the building operator they represent a source of data needed for warranties, understand the maintenance processes including health and safety, obtain replacements parts and interpret the information into data for populating FM systems.
The Handover model was designed to eliminate the additional work the building owner had to do by extracting the data from the manuals. However the manuals are still required if only as a record of what was built, by whom and with what.
In the UK the installation contractor has the responsibility for the production of the manuals. The structure and content of the manuals will vary dependant on the nature of the works and is specification is included in tender documentation.
The criticism commonly voiced by the building owner about the quality of the manuals are:
- The scope of works narrative is vague.
- Names and addresses of products suppliers are incomplete or inaccurate.
- Schedules of products used do not have the correct model numbers.
- Where the products used are either vague or refer to others documents/drawings.
- Warranties for products are not defined or hidden in related documents.
- Certificates are missing or not clear to which products they relate.
- Large sections of an O&M template are left blank because the authors do not know what is required.
- Not all installation contractors will employ a 3rd party to author their O&M’s because:
- They have not budgeted for an O&M.
- Low margins mean they cut corners.
- There is no quality control of the contents.
Specialist contractors for Lifts, Generators and Air Handling Units tend to be more prepared with their O&M, however they are structured to the their company formats and there maybe resistance to complying with any Building Owner template. They don’t have a problem with supplying data.
Generating something as comprehensive as a System O&M requires solid data.
The AIR determines what must be provided and it should specify a default and then the specifics of important component types. Most AIR’s are manually created and then have to be interpriated into rule sets for model checkers. At activePLAN we created an AIR application to generated a comprehensive AIR document and digitalAIR which is in the COBie Schema format. It can be created by hand or other applications for importing into other applications. This effectivley is the rule set and saves having to manually create or collate rules in a checker.
The next requirement is to make sure the data source is valid. COBie in a spread sheet can be edited by hand and the referential integrity of the data can be easily broken. Validation tools like the orginal CobieQCReporter, will check a Cobie spreadsheet as to what has been provided against 2 options, design and construction, not all sheets are checked for example Cobie.Coordinate. You will need to be competent in XML to alter either of these settings. Some CDM applications have built into their offering COBie validation and activePLAN have an online service call cobie-validator, currently in beta, which has a free to use functions covering the same QCReporter checks. It also has user and paid for features which allow multiple configurations.
Lastly putting aside the more complex Electrical and Mechanical Systems the basic contents of an any O&M would be:
- Title Cover sheet
- Installation Contractor (Cobie.Contact)
- Project (Cobie.Facility + Cobie.Attribute)
- Document Control (detailing version changes)
- System Details (Cobie.System)
- Suppliers (Cobie.System > Cobie.Component > Cobie.Space > Cobie.Type > Cobie.Contact )
- Schedule of products by Supplier
- Data sheet (Cobie.Type)
- Warranty (Cobie.Type > Cobie.Contact)
- Maintenance (Cobie.Type > Cobie.Job)
- Properties (as required by the AIR) (Cobie.Attribute)
- Location of where the product is used (Cobie.System > Cobie.Component> Cobie.Space)
- Health and Safety Issues (Cobie.Type > Cobie.Issue / Cobie.Component > Cobie.Issue )
- Spares (Cobie.Type > Cobie.Spare)
- Documents (as required by the AIR) (Cobie.Type > Cobie.Document)
- Product Data Sheet
- Installation instructions
- Maintenance instructions
- Parts (Cobie.Type > Cobie.Assembly)
- Health and Safety Issues of the system (Cobie.System > Cobie.Issue)
- Schedule of Documents (drawings) (Cobie.System > Cobie.Document)
Importance of Product Libraries
At activePLAN we designed a product library, which is now the foundation of BRE’s databook. Our product library is where we put all the data for a product. We can import the digital AIR into it’s built in Project section. In the application our users can add products to a project. Once this is done the application reports against the product data for compliance and give as a percentage compliance score which when clicked on will show the user what is missing.
Our COBieAIM application is where we federate the COBie data. We can import the same digital AIR and when we pull / update the product type from the product library the same check is then done and if we got it right up stream then down stream we have compliance. The methodology we are using here is called “unit testing”. It is used in software development and process manufacturing.
We don’t need to be the one creating the data to get results. I demonstrated how easily this is to generate with a desktop application on Dan Rossiters, of BRE, BIM-Blog house Cobie data to test our program which you can view the whole generation on our youtube channel.
We don’t know the real cost to the industry of current production methods. O&M’s companies typically charge between £10k to £15k for a project. To get the true cost we would need to add in the management. I suspect it is at least double. I think that the current data procurment process is flawed in that it tasks Installation contractors with the job of providing the O&M’s and asset data. When most of the data has already been digitally gathered through specifications and models.