30. Asset Hierarchy (updated)

Updated August 9, 2019 (Original post October 23, 2014): To enable the definition of physical deliverables (Physical Assets) in a flexible manner, the concept of Asset Unit is needed (to be covered in a separate post). An Asset Unit combines: (i) a variable Asset Scale (e.g. a component, an assembly, a building, or a whole city) derived from the Asset Hierarchy (see below), with (ii) an Asset List defined by the Demand Entity (Employer, Client, Appointing Party) within an Information Cycle (a list of assets to be designed delivered, and/or utilised), and (iii) Asset Attributes derived from the Conceptual (BIM) Ontology (e.g. Asset Function, Asset Location, and Asset Cost).

image from www.bimframework.info
Asset Hierarchy – v2.0, 2018 (full size image) - Link to older version (v1, 2011) 


The Asset Hierarchy organises Physical Deliverables/Assets by relative scale by combining taxonomies developed by OSCRE[1] and Transport for North South Wales[2]. The diagram does not differentiate between assets – Buildings as a sample scale - by their size, monetary value, location, or designated function[3] - e.g. Cultural, Transportation, or Recreation[4] but by their granularity relative to each other. The diagram includes a numbering system (scale 10-70) to establish an Asset’s relative position on the scale. The diagram also highlights how:

  • The Assets Scale bridges the semantic and informational divide between three complementary industries and their respective information domains. At the upper-end of the scale, the Geospatial Industry and its Geographic Information System (GIS) domain overlaps with the Construction Industry and its BIM domain; while at the lower-end of the scale, it overlaps with the Manufacturing Industry and its Product Lifecycle Management (PLM) domain[5].
  • An Asset can be a member of three Asset Clusters:
    • An Asset Portfolio (scale 300) is a clustering of assets for the purposes of strategic investment, operation, and management. Asset Portfolios may also be referred to as ‘asset groupings’ or ‘asset systems’[6];
    • A Modular Assembly (scale 500) is a functional clustering of assets for the purposes of Design for Manufacturing and Assembly (DfMA) and similar offsite methods. Examples of Modular Assemblies and Sub-Assemblies include prefabricated houses, pre-assembled mechanical risers, and pre-constructed wall sections[7]. Treated as a single Asset Unit, a Modular Assembly can be (a) first developed and tested in digital space; (b) prototyped, manufactured, constructed, and/or pre-assembled offsite; (c) packaged and readied for transportation; (d) transported for storage on site or delivered Just-In-Time (JIT); and (e) unpacked, erected, and/or assembled; and
    • A Temporary Package (scale 700) is a clustering of assets for the purposes of transportation and storage logistics. Examples of Temporary Packages include standardised shipping containers and logistical package[8]. Temporary Packages also include bundled materials (e.g. a sandbag, load, or palette).
  • Systems are treated as dynamic sub-scales that – depending on the Physical Asset being measured – may be more/less granular than other assets. Systems span the entire hierarchy (from scale 15 to 65) and can flexibly connect information deliverables and requirements across the BIM, GIS, and PLM domains.


Using a variable Asset Scale allows the dynamic assignment of less granular assets at the start of an information cycle. More information about how Asset Scales and Asset Units are used will be explained in future posts.



[1] Fuhrman, A. (2007). The Hybrid Taxonomy Real Estate Focus, The Open Standards Consortium for Real Estate (OSCRE).

[2] TfNSW. (2015). Systems Engineering, Transport for NSW, New South Wales Government (T MU AM 06006 GU). Retrieved from https://www.transport.nsw.gov.au/system/files/media/asa_standards/2017/t-mu-am-06006-st-v2.0.pdf Last accessed Aug 9, 2019

[3] Assets can be classified under many concepts which should not be combined in a single taxonomy. Information Actors will need to identify the number of classifications needed to manage their asset information. For example, an Information Actor may use three primary classifications to identify a Physical Asset: Asset Scale (e,g. Lighting System), Asset Function (Lighting), and Asset Location (e.g. In Room 391 or along Highway A5, Exit Ramp 17).

[4] OmniClass. (2013). OmniClass | Construction Classification System, Retrieved from http://www.omniclass.org/; and NBS. (2015). UniClass 2015 (1.7 ed.). Retrieved from https://buildig.com/uniclass-2015/ Last accessed Aug 9, 2019.

[5] Overlaps between the BIM and GIS/PLM domains are well-covered in: Song, Y., Wang, X., Tan, Y., Wu, P., Sutrisna, M., Cheng, J. C., & Hampson, K. (2017). Trends and Opportunities of BIM-GIS Integration in the Architecture, Engineering and Construction Industry: A Review from a Spatio-Temporal Statistical Perspective. ISPRS International Journal of Geo-Information, 6(12), 397; and in Jupp, J. R., & Singh, V. (2014). Similar concepts, distinct solutions, common problems: learning from PLM and BIM deployment. Paper presented at the IFIP International Conference on Product Lifecycle Management.

[6] ISO. (2014). ISO 55000:2014 Asset management - Overview, principles and terminology. Retrieved from https://www.iso.org/standard/55088.html Last accessed Aug 9, 2019

[7] BWTL. (2018). Platforms Bridging the gap between construction + manufacturing, Brydon Wood Technology Limited (BWTL) for the Centre for Digital Built Britain (CDBB), University of Cambridge. Retrieved from https://www.cdbb.cam.ac.uk/system/files/documents/2018Platforms_Bridgingthegapbetweenconstructionandmanufacturing.pdf Last accessed Aug 9, 2019

[8] Saghir, M. (2004). The concept of packaging logistics. Paper presented at the Proceedings of the Fifteenth Annual POMS Conference, Cancun, April.

44. Information Cycle

Updated Dec 6, 2020 | The Information Cycle Model (previously Information Management Cycle model) employs the three Project Lifecycle Phases – Design, Construction, and Operation (Succar, 2009) [1]– to identify Information Actors and their high-level Information Actions connecting several Information Milestones within the Lifecycle Information Transformation and Exchange (LITE) framework (Succar and Poirier, 2020) [2].

Information-Cycle-v0.7Information Cycle Model | v0.7 at OScale 8, GLevel 2 | Full Size

This high-level conceptual model – covering OScale 8 [3], shown at GLevel 2 [4] - describes the Information Cycles that Structured Information pass through. Each Cycle has a nominal start (e.g. information covering the design of a new Physical Asset) and a nominal end (e.g. information decimated through the demolition of an asset). If the same Physical Asset is iteratively renovated or reused, the information persists over many Cycles.

The Cycle connects four Information Milestones derived from the LITE framework and forming a rotating triangle (3 vertices). The first vertex [i] represents both Expected Physical Assets and Targeted Digital Deliverables (Information Milestones 3 and 4). The second vertex [ii] represents Actual Digital Deliverables (Milestone 6), and the third vertex [iii] represents the Actual Physical Assets (Milestone 7). These three vertices are connected by Information Actions conducted by Information Actors.

Information Actions

As discussed in the LITE framework, Information Actions may either be Forward Execution Actions, connecting one Information Milestone to the next one in the Information Cycle, or Reverse Measurement Actions, needed to verify the accuracy, validity, and quality of an Information Milestone against a previous one. In the model, three primary forward actions are shown - Prepare, Manage, and Use:

  • The Prepare action refers to all activities to collate, harmonise, and otherwise prepare information for management during each project lifecycle phase. Here, preparation refers to both “Anamnesis, dedicated to the survey and collection of facts about the building; and Diagnosis, dedicated to the analysis and interpretation of the collected facts to obtain the necessary understanding of the building and its performance” (Scherer & Katranuschkov, 2018, p. 55) [5];
  • The Manage action refers to all activities to generate, exchange, and otherwise manage information – whether operational, tactical, or strategic (Hosseini, Roelvink, Papadonikolaki, Edwards, & Pärn, 2018) [6]- during each project lifecycle phase; and
  • The Use action refers to all activities that benefit from managed information during each project lifecycle phase – for example: the operation, maintaining, replacing, refurbishing, renewing, upgrading, and re-purposing of Physical Assets (TfNSW, 2015) [7] during the Operation Phase.


Information Actors

This conceptual model and the overall LITE framework does not differentiate between human and machine Actors, nor between discipline and information Actors (i.e. between a design professional and the design information manager) as the separation between these Actors– due to automation and Artificial Intelligence (AI) – is progressively blurring. That is, Actors can be humans, machines (computers/robots), and their hybrids (augmented humans or humanoids/cyborgs) who are (i) acting on existing information to generate new information, (ii) transforming inputs into outputs, and (iii) delivering products and/or services. A Single Actor may be acting alone throughout the whole project/asset lifecycle (e.g. a human Actor designing, constructing, and living in their own forest cabin, or an AI-enabled machine designing, delivering, and utilising a complex mineral-extraction facility on Mars). Multiple Actors may also be acting in sync/sequence at different phases of an asset’s lifecycle to design, deliver, and utilise an asset.

The model identifies three nominal Actors operating throughout the Information Cycle:

  • Design Information Actors: executing the transition from [i] Target Deliverables (Expected Physical Deliverables & Targeted Digital Deliverables) to [ii] Actual Digital Assets and measuring (e.g. verifying or validating) how well Actual Digital Assets match with their respective Targeted Digital Deliverables;
  • Construction Information Actors: executing the transition from [ii] Actual Digital Assets to [iii] Actual Physical Assets and measuring (e.g. testing or confirming) how well Actual Physical Assets match with Actual Digital Assets; and
  • Operation Information Actors: executing actions applied to [iii] Actual Physical Assets (e.g. operating, maintaining, and decommissioning). These actors can either (a) measure - e.g. capture or monitor - how well an Actual Physical Asset matches with the Expected Physical Deliverables within the same Information Cycle, or (b) measure one or more Actual Physical Assets to identify new [i] Target Deliverables within a new Information Cycle.

Actors may overlap and replace one another. Depending on Asset Scale [8] and the diffusion of technologies, processes, and policies within a market (Succar & Kassem, 2015) [9], two or even a single Information Actor may be able to conduct all execution and measurement actions across an Information Cycle.


Versions and acknowledgements

This post includes an updated visual knowledge model (v0.7) and updated explanatory text to align with the now published LITE framework (Succar and Poirier, 2020). The original version 0.3 – Information Management Cycle model - was published through this blog on July 25, 2017 and can still be accessed as an image file from here (v0.3 was reviewed by Dr. Sheryl Staub-French, Dr. Julie Jupp, Dr. Marzia Bolpagni, and Mr. Victor Roig Segura). An updated version 0.5 was later published in Jan 21, 2018 and included important modifications – image file can be accessed from here. For a more detailed review, the updated post including the v0.5 model is available for download as a pdf file from here (148KB).



[1] Succar, B. (2009). Building information modelling framework: A research and delivery foundation for industry stakeholders. Automation in Construction, 18(3), 357-375. DOI: https://doi.org/10.1016/j.autcon.2008.10.003

[2] Succar, B., & Poirier, E. (2020). Lifecycle information transformation and exchange for delivering and managing digital and physical assets. Automation in Construction, 112, 103090. http://bit.ly/PaperA11

[3] There are 12 Organisational Scales – refer to Post 11 https://www.bimframework.info/2013/12/organizational-hierarchy.html

[4] Granularity Levels clarify the extent of informational detail within a conceptual model, matrix, tool, or document. There are five Granularity Levels (GLevels) progressing from lowest to highest: https://BIMdictionary.com/en/granularity-level/1

[5] Scherer, R. J., & Katranuschkov, P. (2018). BIMification: How to create and use BIM for retrofitting. Advanced Engineering Informatics, 38, 54-66. DOI: https://doi.org/10.1016/j.aei.2018.05.007

[6] Hosseini, M. R., Roelvink, R., Papadonikolaki, E., Edwards, D., & Pärn, E. (2018). Integrating BIM into facility management: typology matrix of information handover requirements (Vol. 36)

[7] TfNSW. (2015). Systems Engineering, Transport for NSW, New South Wales Government (T MU AM 06006 GU). Retrieved from https://www.transport.nsw.gov.au/system/files/media/asa_standards/2017/t-mu-am-06006-st-v2.0.pdf

[8] Asset Hierarchy and Asset Scale are covered in Post 30 - https://bimframework.info/2019/08/asset-hierarchy.html  

[9] Succar, B., & Kassem, M. (2015). Macro-BIM adoption: Conceptual structures. Automation in Construction, 57, 64-79. DOI: https://doi.org/10.1016/j.autcon.2015.04.018

43. Product Development Diagram


BIMe Initiative Product Development Diagram (Updated Jan 21, 2018full size image)

This diagram illustrates the process of delivering a BIMe Initiative Product (a Published Guide or a Software Application): a Top-Level Project must be first launched. Each Top-Level Project typically includes both existing components (e.g. a taxonomy or a classification) and new components. Existing components are (a) selected from the Knowledge Object Library, a public resource available through BIMexcellence.org. New components (e.g. a framework or a software module) are (b) generated by BIMe Members through Micro Projects. Once completed and validated, all components are (c) packaged into a new BIMe Product. Once tested and verified, the new product is (d) released through the Product Library (a webpage on BIMexcellence.org) and all newly generated components are (e) added to the Knowledge Object Library for future reuse. As opposed to the Knowledge Object Library and the Product Library, which are both publicly available resources, the generation of new components and end products are conducted within the Project Space (wiki pages, chat rooms and physical meetings) which are accessible to BIMe Members and invited international collaborators.

To understand Conceptual Components (also referred to as Conceptual Constructs), please review the Conceptual Hierarchy and - as an example - how components populate the Research Continuum. Also, for more information about BIMe Initiative products, projects, and how they are managed, please refer to 103in BIMe Initiative Projects.