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 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).

BIMe Initiative Product Development Diagram (Updated Jan 21, 2018 | full 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.

BIMe Initiative Knowledge Structure (full size image)

This model represents the Knowledge Structure which the BIMe Initiative (BIMexcellence.org) is reliant upon to deliver interconnected software applications, guides, conceptual structures and learning materials. The Knowledge Structure is composed of five complementary Knowledge Sets:

• KS1 Knowledge Foundations represents all the research supporting the BIMe Initiative;
• KS2 Knowledge Blocks represents the modular language developed/used by the BIMe Initiative to define inputs, processes and outputs;
• KS3 Knowledge Tools represents all the digital and analogue tools/templates used to conduct knowledge acquisition, engineering and sharing;
• KS4 Knowledge Workflows represents all repeatable procedures for knowledge acquisition and service delivery; and
• KS5 Knowledge Views identifies the varied ways the BIMe Initiative activities and deliverables can be represented and communicated.

The Knowledge Sets and their subsets form the bases for all BIMe Initiative Projects (refer to 103in); organise the activities of the BIMe Initiative Network (refer to 104in); and allow the development of an expansive Knowledge Object Library.

Updated Feb 20, 2020, to align with Paper A11 - original June 20, 2016 (download), modified Nov 29 and Jun 20, 2019.

The Information Taxonomy (previously Project Information Taxonomy) extends the Modular Requirements Clarification Language first introduced in Paper A10. The taxonomy currently includes concepts/terms to be used in defining information requirements within mission-critical documentation (e.g. within an Employer’s Information Requirements (EIR), a BIM Management Plan (BMP) or similar).

The term ‘information’ – here used to describe Digital Assets - can be subdivided into three Information Representation Types or ‘digital artefacts’- documents, models, and data:

• Document: A medium (e.g. an email, web page, or a PDF document) carrying a variety of information including text, metadata, or embedded 3D models. A document refers to “information and its supporting medium” [i.e. when the information is placed within a medium, it becomes a document] ….“the medium can be paper, magnetic, electronic or optical computer disc, photograph or master sample, or a combination thereof” (ISO, 2009, Item 4.5), adapted from ISO (2015, Item 3.7.2). In this study, the term Document will refer to a digital medium or an analogue medium to be digitised in preparation for management and utilisation. When referring to non-digital documents, the term will be qualified (as in paper document). Examples of Documents include a Master Plan Drawing, a Performance Certificate, and an Audit Report;
• Model: A “representation of a system that allows for investigation of the properties of the system” (ISO, 2016). As a term, it may refer to digital models (e.g. shell/boundary or solid geometry graphical models); physical models (e.g. a sandcastle, LEGO model, or 3D printed shapes); or financial, mathematical, and conceptual models. In this study, unless qualified, the term Model will refer to a three-dimensional digital medium carrying a variety of information and – potentially - embedding or referencing both Documents and Data sets. A Model can represent a discipline/specialty (e.g. architectural model), a state (e.g. record model), or a base technology (e.g. object-based model); and
• Data: A digital sequence of symbols – typically letters and numbers - that can be collected and parsed/ interpreted by an actor. Data may be statically embedded within Documents and Models or drive their dynamic generation/ modification - adapted from ISO/IEC (2015). Data can be captured through sensors, actuators, and scanners (Gubbi, Buyya, Marusic, & Palaniswami, 2013); derived from connected data sources; or generated through machine learning. The term Data may be coupled with other terms preceding it (e.g. structured, unstructured, or meta-Data) or following it (e.g. Data cloud, object, routine, script, set, or table) to indicate either functional groupings, relationship structures, internal cohesion, semantic inferences, coded computer instructions, or ‘as a variety of charts and diagrams’ (Sowa & Zachman, 1992). In this study, and unless qualified, the term Data will refer to digital computable data. Data sourced from analogue devices (e.g. liquid thermometers and legacy imaging equipment) need to be digitised before it can be utilised and managed.

This representational subdivision is utilitarian and is intended for practical purposes: allow more accurate identification of targeted digital deliverables and – as illustrated in the Information Taxonomy below – provide flexibility in specifying information delivery uses, views, view definitions, viewers, and environments

Information Taxonomy - Table v2.0

More info

This post is part of the BIMe Initiative Integrated Information Platform project and contributes to the ongoing effort to clarify the language used (or to be used) in defining project requirements within Noteworthy BIM Publications. Some of the concepts introduced above are still being refined, connected and reconnected to multiple models, taxonomies and classifications. For an up-to-date description of these concepts and their relations, please refer to respective terms within the BIM Dictionary.

Endnotes

[1] A document refers to “information and its supporting medium” [i.e. when the information is placed on a medium, it becomes a document] … “The medium can be paper, magnetic, electronic or optical computer disc, photograph or master sample, or a combination thereof” – [SOURCE: ISO 14050:2009, 4.5 - adapted from ISO 9000:2005, 3.7.2]

[2] Another definition is a “representation of a system that allows for investigation of the properties of the system” [SOURCE: ISO 29481-1:2016(en) Building information models — Information delivery manual — Part 1: Methodology and format]

[3] “a reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or communication, or processing” [SOURCE: ISO/IEC 2382-1:1993, Information technology — Vocabulary — Part 1: Fundamental terms.01.01.02]

[4] Note: Documented Project Information should not be confused with Documented Information which is defined in ISO 9001:2015 as meaningful data that is required to be controlled and maintained by the organization and the medium on which it is contained (Source: ABP Consultant)