This paper explains what COINS is, and what COBie is and recommends how each can be used for a large highways organisation (Highways England).
Construction Objects and the Integration of processes and Systems - COINS - is a software methodology to manage the storage, transmittal and update of BIM data throughout a supply chain. This data could be the physical assets and their attributes, such as are held in traditional asset databases. But its definitions can also be far wider, for example physical and spatial relationships, functional requirements, and hierarchical composition from the whole network down to nuts and bolts if necessary. For a broader view of the scope of COINS see http://www.coinsweb.nl/wiki/index.php/Information_transfer.
COINS is based entirely on open standards and protocols. Those parts of it that have been specifically developed for the Dutch BIM community have been published by the Dutch government Standardisation Forum as open resources.
The technical specification for COINS in English: http://www.coinsweb.nl/wiki/index.php/Hoofdpagina
File formats used in COINS
The COINS container file (extension .ccr) is a standard zip file with a defined internal structure. It must contain the COINS definition document in the \bim folder, and any referenced files in the \doc folder. These could include 2D and 3D content in open (eg IFC) and proprietary (eg Autocad, Microstation, or ESRI Shapefile) formats, and pdf files, spreadsheets, Word etc.
The COINS definition file has the extension .owl denoting Web Ontology Language. This is xml (intelligent text) applied to the properties, relationships etc of the objects described. Owl declares “triples” of subject-predicate-object that are held in an appropriate database (which can be mapped into standard SQL). This can be queried not only for explicit information, but also for inferences. COINS uses a defined set of terms that limits owl to matters appropriate to infrastructure BIM.
Each object is assigned a GUID (globally unique ID) on creation. Because information flow is two-way, a subset of data is given to a supplier, whose updates can add, delete or change specific objects. The returned data is merged with the client’s database, using the GUIDs to match with the affected objects. The same process takes place between a supplier and its subcontractors.
Another owl file, the Object Type Library, performs both the definition and the validation of assets, ensuring that they have the specified graphical and non-graphical attributes with correct type and range.
Advantages of COINS
- COINS is already working throughout the supply chain of a national highway authority
- Its scope covers the whole lifecycle from inception to demolition
- It can handle any level of detail, including queries that were not planned from the outset
Disadvantages of COINS
- Although most of the documentation is available in English, all the expertise in COINS is currently in the Netherlands. A suitable training programme would be needed – including in-depth knowledge for future support.
- All the supply chain of any COINS project would need to buy in to the hardware and software to host their contribution, and the necessary training.
Opportunities / Threats for COINS
COINS could be used to handle only the non-graphic data currently held in HE asset databases; but that would ignore most of its potential and lose most of its benefits. If adopted fully, the COINS database would import and replace IAMIS and all Highways England asset databases. Subsets of it (with additional detailed data) would be the mainstay of HE maintaining agents. ADMM would become an owl Object Type Library. The project EIR and PLQ would be specified in COINS form. All PCF products would be specified and received by COINS exchanges. This change in approach would be fundamental, but give huge versatility.
Introduction to COBie
COBIE stands for Construction to Operations Building Information Exchange. Here's a brief explanatory video. COBie is a 20-sheet spreadsheet-xml file format originally developed as a digital data handover for the non-graphic data of buildings. The spatial hierarchy reflects this:
Facility > Floor > Space > Component
(although these sheets may be aliased with geographic names under COBie for UK). All of the entries (rows) must have unique names within the file, which can hold only one Facility. Components are instances of Type, and may be parts of Systems. Spaces may be parts of Zones, which may be non-contiguous. A COBie file would accompany any related documents and drawings, which should be referenced within it on the Documents sheet. The properties of individual Components, Types and Documents are assigned on the Attributes sheet. By convention, columns are coloured to indicate required, lookup, optional and software-supplied values. These indicators should change through the project as more detailed information becomes required.
The intention for the software-supplied columns is to link to the geometric data in the documents by populating columns with the relevant document name and unique identifier within it. If these identifiers were unique across the whole network and read/write enabled (not intrinsic properties of the software package), then there would be potential for two-way transfer and update within the supply chain. Currently no highways-related commercial software has implemented COBie, and there is no proposal for HE to issue asset-level COBie with unique IDs for the supply chain to update.
Highways context for COBie
The ADMM asset types (4-char codes) map best to COBie Type, making instances of them as COBie Components. Space / Location could map to XSP, so that each lane, verge, NMU path, earthworks slope etc. would be identifiable (and similar types collected in Zones). Floor could then be a carriageway section, and Facility could be project / link / interchange. Alternatively, Facility could be a larger unit, such as a maintenance area or the whole network; Region and Location would need to fit intermediate groupings that add value in asset management terms.
A wide range of linear referencing methods has been added to COBie for UK infrastructure. But recent thinking within HE on whole life data needs is moving towards OS coordinates as the primary location reference for all assets. In the absence of adequate software management of unique IDs, it would be possible to identify individual assets by their type and XY coordinates – though this is more open to errors.
Document-level COBie is a workable short-term solution in which all document transmittals are performed by a COBie file. It lists the bounding box of the geographic extent of each file’s contents – giving a crude location mechanism beyond the file name alone. Currently it can be populated only manually.
Advantages of COBie
- COBie is endorsed by UK BIM Task Group and enshrined as BS1192-4 Collaborative production of information Part 4: Fulfilling employers information exchange requirements using COBie (see here for a good explanation of this).
Disadvantages of COBie
- COBie’s fixed number of levels of hierarchy is insufficient for a logical match at all levels of the Highways England network. It is designed purely as a transfer format with relatively local scope.
- COBie Type Attributes are fixed values applicable to all instances. There seems to be no mechanism to define the Component Attribute requirements for each Type, making verification difficult.
- No commercial software for any discipline relevant to highways is configured to read or write COBie files. But the files are too complex and repetitive for manual authoring on a real project at anything beyond whole document level.
Recommendations regarding use of COINS and COBie in Highways England
- In the short term, document-level COBie should be mandated for transmittals of project files to the Highways England CDE. Bounding-box coordinates for each file’s contents should be consistently given in OS grid to facilitate meaningful GIS searching.
- The supply chain and software vendors should be encouraged to make means to supply the geometric content in the open-standards IFC format, together with the original proprietary formats as permitted by IAN184. At minimum, the resulting structure must be able to hold the bounding shape and the unique ID for each asset (tools such as Navisworks already convert 3D solids to BREP equivalents of their surface – so this is not a major software challenge). Ideally far more intelligence would remain in the data structure including the alignment geometry. Adopting open formats is a key part of BIM Level 3 and is relevant to any transfer mechanism.
- The main recommendation is that COBie, designed for single buildings, does not scale well to the national road network. The greatest potential for network-wide specification and management of Highways England’s asset portfolio would be through the adoption of COINS. But this would also involve realigning initiatives across the company. Considerable support and training would be needed from Rijkswaterstaat and its suppliers and consultants.
- Trial COINS on a pilot project for construction. This would involve creation of an Object Type Library holding at minimum the asset types needed by the project. All members of the supply chain (Highways England, designer, contractor, sub-contractors, suppliers) would need to have hardware and software to receive, update and return COINS files (though some minor transactions could be simulated).
- Extend the pilot to the relevant maintenance area.
- Run a second (simultaneous) pilot of a far earlier project stage to trial the specification aspects as a digital form of EIR and PLQ. The Departures process would logically be handled by COINS submissions that set out the case and contain all supporting materials.
- Assuming that the pilots are successful, adopt COINS as one of the key tools for Highways England to manage its assets and its projects.
This was originally written by Atkins for Highways England (August 2015) and has been kindly shared with permission.