Unpublished

44. Information Management Cycle

Information-Management-Cycle

Information Management Cycle v0.3 (Full-size Image)

This high-level conceptual model describes the Information Management Cycles that Structured Project Information pass through [1]. Each Cycle includes three Information Management States, separated by varied Information Management Activities conducted by specialised Information Management Actors:

Information Management States

The three states describe how Structured Project Information can be experienced as either:

[A] Information Requirements: project specifications, protocols or similar that identify what needs to be generated by project stakeholders. Information Requirements can be represented as a set of Document Uses, Model Uses and Data Uses.

[B] Digital Deliverables: digital simulations of physical objects and how/when they’ll be constructed or fabricated. Digital Deliverables can either be documents (in digital format -e.g. CAD drawings or a PDF furniture lists), models and/or data sets.

[C] Physical Assets: information embodied within real world objects similar to whole facilities, a building, mechanical system, heating unit, or a single pump.

Information Management Activities

The transitions between these Information Management States are represented as either forward or reverse activities. Forward Cycle Activities refer to the actions executed to cross from one state to the next; while Reverse Cycle Activities refer to the measurements made to examine one state against its preceding one. Sample activities [2] are provided below:

  • Forward Execution Activities from [A] to [B]: the activities typically conducted during a project’s Design Phase which includes the planning and specifications sub-phases (e.g. drafting, drawing, detailing, and modelling); and
  • Reverse Measurement Activities from [B] to [A]: the activities necessary to verify or validate digital deliverables against information requirements (e.g. checking floor areas in a BIModel against a client’s spatial requirements).
  • Forward Execution Activities from [B] to [C]: all the activities typically conducted during the Construction Phase which includes construction planning and commissioning (e.g. laying floors, mounting ceilings, and painting walls); and
  • Reverse Measurement Activities from [C] to [B]: the activities necessary to test and confirm physical outputs against digital deliverables (e.g. checking the placement of duct hangers on site against relevant models or mechanical shop drawings).
  • Forward Execution Activities from [C] to [A]: all the activities typically conducted during the Operation Phase which includes management, maintenance and decommissioning (e.g. cleaning rooms, repairing down-pipes, replacing roof tiles); and
  • Reverse Measurement Activities from [A] to [C]: the activities necessary to capture data pertaining to a physical asset or to monitor the performance of a physical system (e.g. data capture through laser scanning and data monitoring through sensors).

Information Management Actors

The Information Management Activities separating Information Management States are conducted by actors which are either humans and/or computers. There are three main actors who operate throughout the Information Management Cycle:

  • Design Information Management Actors: executing the transition from Information Requirements to Digital Deliverables and measuring (e.g. verifying or validating) how well Digital Deliverables match with Information Requirements;
  • Construction Information Management Actors: executing the transition from Digital Deliverables to Physical Assets and measuring (e.g. testing or confirming) how well Physical Assets match with Digital Deliverables; and
  • Operation Information Management Actors: executing actions applied to Physical Assets (e.g. operating, maintaining and decommissioning). Also these actors can either (a) measure - e.g. capture or monitor - how well a Physical Asset matches with the Information Requirements covering the asset (within the same Information Management Cycle), or (b) measure one or more Physical Assets in order to generate new Information Requirements within a new Information Management Cycle.

Actors may overlap and replace each other. Depending on the current state of technologies, processes and policies within a market, two or even one Information Management Actor may be able to complete all execution and measurement activities across an Information Management Cycle [3].

 


Acknowledgements

The following colleagues have provided improvement suggestions to an earlier version of this model: AProf. Sheryl Staub-French, AProf. Julie Jupp, Ms. Marzia Bolpagni, and Mr. Victor Roig Segura. Thank you to all.

 


Endnotes

[1] Each Information Management 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). However, it is possible and even probable that the same information would persist over a number of Cycles (e.g. through iterative renovation of the same physical asset).

[2] Activities are a subset of ‘Relations’ within the Conceptual BIM Ontology.

[3] This model is part of the BIMe Initiative Integrated Information Platform project


43. Product Development Diagram

BIMe-Initiative-Product-Development-DiagramBIMe Initiative Product Development Diagram (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.


40. Project Information Taxonomy

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

Project Information includes both Unstructured Project Information and Structured Project Information:

  • Unstructured Project Information refers to non-computable data, undocumented, and temporary project information (e.g. hand sketches and casual phone chats); and
  • Structured Project Information refers to information organised and formatted for particular purposes or use cases.

Project information can be represented, stored or exchanged as either Documents, Models or Data. These three Information Representation Types can be mapped against a number of new Information Management concepts – including: Information Delivery Format, Information Uses, Information Views, Information View Definitions, Information Viewers and Common Information Environments.

This is clarified in the below table, a ‘flat’ representation of the Project Information Taxonomy (slightly updated Nov 29, 2016):

Project Information Taxonomy - Table

INFORMATION REPRESENTATION TYPE How information is represented

Document

A physical or digital medium (e.g. a paper or an email) carrying a variety of Information including text, Data (e.g. hexadecimal code) and embedded Models (e.g. a 3D PDF document) [Partially adapted from ISO 14050:2009 and ISO 9000:2005][1]

Model

A digital three-dimensional representation of Information. A 3D Model may embed or reference both Data and Documents. The term ‘Model’ refers to both digital and physical models (e.g. a 3D printed shape) but does not refer to financial, mathematical or conceptual models…Also refer to BIModel[2]

Data

A reinterpretable representation of Information which can be collected/parsed with or without the human actor. Data is either statically embedded within Documents and Models or drive their dynamic generation/modification [Adapted from ISO/IEC 2382-1:1993][3]

INFORMATION DELIVERY FORMAT How information is - or need to be - delivered on a project

Documented Project Information[4]

Project information collated within Documents for functional purposes. Documented Project Information are captured and exchanged either manually or through digital means, and are intended for use by the human actor (e.g. drawings, maps and reports)

Modelled Project Information

Project information collated within Models for functional purposes. Modelled Project Information are generated by the human actor or driven by machine-captured data (e.g. structural analysis and asset tracking)

Structured Project Data

Granular project information collated within Documents and Models, or driving the generation of Documents and Models; Structured Project Data are captured through sensors and scanners; derived from connected data sources; or generated through machine learning

INFORMATION USE The intended uses/applications of project information

Document Use

The intended or expected project deliverables from developing and exchanging information through Documents.

Examples: Master Plan Drawing or Minutes of Meeting.

Model Use

The intended or expected project deliverables from generating, collaborating-on and linking Models to external databases.

Example: model-based Urban Planning or Lighting Analysis.

Data Use

The intended or expected project deliverables from generating, exchanging and manipulating Data.

Example: Fabrication Scripting, using code to drive cutting, milling or sintering equipment.

INFORMATION VIEW How project information is represented to enable its use

Document View

A view representing one or more Document Uses. A Document View can be a drawing, schedule, report, an instruction memo or a set of specifications. A Document View may be analogue or digital, developed manually or derived automatically from a Model or Data source.

Example: A Room Data Sheet

Model View

A view representing one or more Model Uses. A Model View can be a static 3D view, an animation, a holograph or a 3D print. A Model View follows the specifications within its corresponding Model View Definition or reflects unique project requirements

Example: A Model View showing only Mechanical and Structural elements

Data View

A view representing one or more Data Uses. A Data View can be a code snippet, a Computer Numerical Control (CNC) file, an XML file or similar information not primarily intended for the human actor.

Example: An If This Then That (IFTTT) recipe or a visual script in Autodesk Dynamo

INFORMATION VIEW DEFINITION How Information Views are defined to enable the consistent use of Structured Project Information

Document View Definition

A specification which identifies the contents, attributes and formats of Document Views. Document View Definitions are typically generated by authorities and large clients.

Model View Definition (MVD)

A specification which identifies the properties and specifies the exchange requirements of Model Views. A 'standardised' Model view Definition (MVD) can be a subset of an established schema (e.g. the Industry Foundation Classes) and is typically intended for software developers (not end users) to implement into their BIM Software Tools.

Example: the IFC4 Design Transfer View by buildingSMART International

Data View Definition

A specification which identifies the properties and specifies the exchange requirements of Data Views. Data View Definitions are generated by Project Participants to formalise their data exchange scenarios

INFORMATION VIEWER The software allowing access to Structured Project Information by a solitary user

Document Viewer

A software application allowing users to inspect and manipulate of Structured Project Information according to pre-set Document Views.

Example: A PDF reader or a 2D CAD viewer

Model Viewer

A software application allowing users to inspect and navigate Modelled Information according to ad-hoc or standard Model View Definitions. As opposed to Model Servers, Models accessed by a Model Viewer are read-only and cannot be modified.

Example: Autodesk Navisworks or Solibri Model Checker

Data Viewer

A software application allowing users to inspect and manipulate data according to pre-set Data View Definitions. An example of a Data Viewer is an online project dashboard merging data from several sources

Example: Google Flux or Autodesk Forge Viewer

COMMON INFORMATION ENVIRONMENT The digital environment  allowing access to Structured Project Information by multiple concurrent users

Shared Document Environment

A central source for Documented Project Information. A Shared Document Environment is not necessarily a single software tool but a combination of several software solutions – including: a Document Management System, a Document Viewer, a Model Viewer, and a Project Management software. A Shared Document Environment may connect several software tools and desperate data sources through middleware and plugins

Federated Modelling Environment

A central source for Modelled Project Information used to collect, store and allow controlled access to model-based information by project/asset stakeholders. A Federated Modelling Environment differs from a Shared Document Environment by allowing the isolation of Structured Project Information by Model View

Integrated Data Environment

A central or distributed repository of Integrated Data feeding from multiple data sources and information systems across disciplines and domains. An Integrated Data Environment allows manipulation of data by multiple stakeholders according to access rights and agreed Data View Definitions

 

More info

This post is part of the of an 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 update-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)


30. Asset Hierarchy

Asset Hierarchy Across 3 Scales

 

This conceptual model (unpublished) is a taxonomic subdivision between three overlapping domains -  Building Information Modelling (BIM), Geographic Information Systems (GIS) and Product Lifecycle Management (PLM). The subdivision is based on four criteria (classes):

  • Asset Scale -  e.g. Built Environment or Building
  • Industry - e.g. Geospatial or Manufacturing
  • Applicable Acronym – e.g. BIM or PLM
  • Typical Unit of Measurement – e.g. Meters or Millimetres

Other criteria can be added to differentiate, qualify or compare the three domains