Probably one of the most frequently asked questions from anyone working on a BIM project is “How much information should be in my model, or how much information am I expected to provide?”
To answer the question, we first need to ask, what do you mean by “your model”?
What is meant by 'information model'?
PAS1192-2 defines the Project Information Model (PIM) and Asset Information Model (AIM) as the combination of graphical data, non-graphical data and documents related to a building or construction project, all stored and managed in a Common Data Environment (CDE).
T
he Project Information Model (PIM) starts off as the “design intent” model, then progresses to the construction information model. It provides the historical development of all the project information through the project stages during the capital delivery phase, produced between designers, contractors and their suppliers. It is very important to keep all this information for future reference, in case there is a problem or issue later.
The Asset Information Model (AIM) is based on the final, verified, “as-built” information, and is used to operate and maintain the building going forward (under PAS1192 part 3).
PAS1192-2 also defines the Level of Model Definition (LoMD), as being a combination of Level of graphical Detail (LOD), and Level of non-graphical data or Information (LOI), required at different stages of the project.
So, when you read the above definition, clearly the “Information Model” is much more than just the 3D graphical BIM, Revit or IFC model – it represents all the project information.
See also: BIM Levels of Information
See also: BIM Levels of Detail
What lists of information are required?
What type of “information” do we need to know about a building, “at the end of the day”? Typically, the following lists of information are required: (see a more detailed list at the end of this article).
- Rooms/spaces (ideally geo or spatially located)
- Zones/departments (collections of rooms/spaces/volumes)
- Systems or assemblies (groups of components)
- Components or equipment (and which system/assembly/zone/space they belong to)
- Products/materials
- Maintenance tasks, spare parts and tools/resources required to maintain and operate the building
- Contact details of companies/people involved in the project (the designers, contractors, suppliers and others)
- Documents related to the project, building, systems, products and materials
What is COBie? Is it required?
When you read the above “lists” of information, most people would agree that these are all necessary – in fact you might say it is the minimum you would expect to receive when “buying” a building. These “lists” of required information, for “managed assets” of buildings, are defined and specified by COBie (Construction Operations Building Information Exchange) in BS1192-4:2014.
“Managed Assets” are those that require maintenance, inspection, commissioning; used for Facilities Management. So when someone says they don’t need COBie for their project, are they saying they don’t need this information? Or are they simply saying they don’t need this information structured/ delivered in the way BS1192-4 requires? When a designer, contractor or supplier says “we don’t provide COBie” or “providing COBie is an additional service”, then you have to question, exactly what “information”, from the above list, do they, and don’t they provide as part of a traditional standard service? How is this information currently provided? It is important to note that COBie is not asking for any more information than is typically supplied at the end of a project - it is just asking for it in a digital and structured way.
See also: What is COBie?
What about the relationships?
What is also not often considered, recorded, or required, is information about the “relationship” between items in these lists. For example, which room is a piece of equipment in? Which system does it belong to or connected to? What materials or products make up a systems or assembly? Who was responsible for designing, supplying or installing an item? (often not the same party). This is where BIM really helps, because “objects” in the virtual building model have “context” – they are spatially located, and aware of some of these “relationships” - they are placed in rooms, connected to systems, form part of assemblies etc, making these “relationships” easy to manage and identify.
Exploring the information model
Since the “information model”, as defined in PAS1192-2, is a combination of graphical data, non-graphical data and documents, then by extension, you would expect that for every component, product, material, system that makes up the building, we would ideally need some graphical data, non-graphical data, and associated documents. Let’s consider these three categories of information:
1. Graphical data
Why do we need graphical data? Graphical data could be 2D or 3D. The advantage of a 3D “object” in the virtual building model is that it provides a visual reference, location and context, establishing relationships with rooms, spaces and other components in the virtual building model, as noted above. The physical size/ dimension of the solid object is required for computerized 3D co-ordination (clash detection), and the connection points begin to establish relationships with systems. The “object” acts as a “placeholder” or “container” for some of the Non-Graphical Data, or attribute information, and potentially provides a link to further information in other formats and locations (like a specification, or a collection of documents in a document management system). The Level of Detail (LOD) in PAS1192-2 defines how much graphical detail is required at each project stage.
2. Non-graphical data
Why do we need non-graphical data? Isn’t is sufficient if the information has been provided in some “document”, like a drawing, or a specification document, or a product manual? The problem is that buildings comprise thousands of items, systems, components, material, or products, each with hundreds of items of information. To manually search through thousands of “documents”, opening each, one at a time, and reading through them, personally, with your eyes, to find some information, is not always feasible or useful. To overcome this, people have tried well-organized folder structures, file-naming conventions and indexing systems, to make information in documents easier to find. This has helped a little, but in order to re-use the information for some other process, it still has to be manually copied, extracted or re-typed into other applications.
But with object-based virtual building models (BIM), we can now incorporate certain information as “digital attributes” within the object itself, that are easy to search, query and extract, to help give people better access to information in a much easier way. As we transition to “digital construction”, there will be an ongoing debate as to how much information should be provided as “digital attributes” within objects or the virtual building model, how much could be “data” within another searchable database (such as product manufacturers online database), and how much should simply be provided as information in static “documents”, as is the current norm. The trend however will be towards providing more “data” and less “documents” – in other words, information that is “machine readable”. As a “rule of thumb”, anything that is required to be digitally or “computationally” used for analysis, monitoring, reporting, or searching, should be a digital attribute.
The Level of Information (LOI) in PAS1192-2 defines how much non-graphical data is required to be provided at different stages of the project. A Product Data Template (PDT) is a structured spreadsheet-based digital file format, that product suppliers and manufacturers can use to provide their non-graphical data (as a Product Data Sheet) to project teams, to allow them to incorporate and re-use the information. Obviously, the “naming” of digital attributes is very important, particularly if we want computers to be able to recognise, check/cross-check these against project requirements and across many projects - this is where standardised classification systems (like Uniclass or Omniclass) become really important, as well as international “data dictionaries”, that allow common “terms” are understood in all countries. In other words, don’t just “make it up” yourself – follow international standards.
3. Documents
Why do we need documents? We are well used to producing and providing “documents” in construction. Drawings, specifications, schedules, bills of quantities, product manuals, certificates, warranties, contracts, etc While we may use lots of “digital tools” to produce these, they are typically delivered in “static” formats, like printed pages, or scanned .pdf’s, for others to use. The problem with “documents” as mentioned above, is that the only way to find information, is to manually open and read the documents, and with hundreds and thousands of documents on a typical project, this can be a very time-consuming (or near impossible) task.
In the short-term, we will still need “documents”, but as computers get more powerful and connected, we see a trend is towards more “data”, which is digital, searchable and manageable (able to be kept up-to-date, analyzed, monitored and assessed). Some forms of “information” may be difficult, or possibly not appropriate, to store as “data”, such as long text based narratives, like manuals, specifications and reports, or officially “signed” documents like contracts and certificates. Documents also provide a fixed historical “record” of the development process of buildings, not just information about the building itself.
Documents should be well-organized and indexed, and stored in an accessible system, if they are going to be of any use to anyone. People need some way of knowing that they are looking at the latest version of the correct document, or they will not trust the information. PAS1192-2 refers to the Common Data Environment (CDE) which is a well-managed central repository of information, using a clear file-naming convention, and a carefully managed approvals workflow, to make sure documents are properly controlled and easy to find.
Is this just relevant to BIM projects?
Most of what is described above, should be applicable to any project, whether using BIM or not. It is about “information” that is typically required for the successful planning, design, construction, operation and final decommissioning of almost all built infrastructure. This information is already being produced, or reviewed by people on projects, but it possibly isn’t being correctly managed and collected in a way as described in PAS1192-2. As mentioned above, semantic object-based modelling (or BIM) helps make the production, management, exchange and access to information far better and easier. Hopefully this helps to understand the definition of the “Information Model”, and also answer the common questions “How much information should be in my model, or how much information am I expected to provide?”
What types of documents and information are typically required on projects?
A non-exhaustive list might include:
- Client brief and technical requirements
- Appointments and contracts
- Bonds and insurances (including final building insurance valuation)
- Project stage reports
- Technical reports (planning, design, environmental, impact assessments, etc.)
- Analysis, assessments and calculations
- Sustainability certification - assessment, application, certificate
- Surveys (topographical survey, condition survey, etc)
- Meeting minutes
- Project file notes
- Request for information (RFI’s)
- Method statements
- Correspondence
- Media (photographs, images, presentations, video, etc)
- Regulatory application/submission certificates (planning, building control, fire safety, disability access)
- Non-statutory applications/submissions/certificates (LEED, BREEAM, etc.)
- Tendering procedures (pre-qualification, Requests for Tender, Submissions, Assessments)
- Models (3D models, 2D models, federated models, Analytical models)
- Design drawings, specifications, schedules and data sheets
- Cost plans and bills of quantities
- Payment certificates
- Contracts final accounts
- Project plans and programmes
- Technical submittals and approvals
- Construction/fabrication drawings, specifications, schedules and data sheets
- As-built drawings, specifications, schedules and data sheets
- Health and safety risk assessments and safety plans
- Design responsibility matrix
- Design requirements (Tests, certificates, samples, etc.)
- Compliance specification /certificates/opinions on compliance
- Schedules of certifiers, benchmarks, design changes, non-compliance
- Inspection plans and inspection records
- Snag lists and quality control procedures
- Systems, equipment, materials and products:
- Product specification
- Agrément certificates (NSAI, BRE, etc)
- European Technical Assessments (ETA)
- Product Declaration of Performance (DoP) and CE Marking
- Environmental Product Declaration (EPD)
- Technical data
- Product batch/ trace details
- Product installation guide
- Product maintenance/ cleaning procedures/ manual
- Product spare parts, tools and resources
- Product safety information / emergency procedures
- Inspection record
- Test certificates
- Commissioning certificate
- Equipment default “settings” (set points)
- Suppliers warranty (parts)
- Suppliers warranty (labour)
- Supplier contact details
To keep up-to-date with future articles in this topic area - why not sign up to the NBS eWeekly newsletter? Get the latest content from theNBS.com carefully crafted into a handy weekly email.
