Digital Engineering Standard Part 2 Requirements · 2019-11-12 · DMS-ST-207 Standard –...

Digital Engineering Standard Part 2 – Requirements

DMS-ST-207

Standard – Applicable to Infrastructure and Place

Divisional Management System

Status: Final

Version: 3.0

Branch: Program Management Office

Section: Digital Engineering

Business unit:

Date of issue: September 2018

Review date: October 2019

Audience: Division wide

Asset classes: Heavy Rail; Light Rail; Multi Sites;

Systems; Fleets

Project delivery model: Not applicable

Project type: For all project types

Project lifecycle: Feasibility; Scoping; Definition;

Construction readiness; Implementation;

Finalisation; Not applicable

Process owner: Director


Program Management Office : Digital Engineering :


DMS-ST-207 DE STANDARD - PART 2_V3.0

DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207

© TfNSW 2019 UNCONTROLLED WHEN PRINTED of 90

Document History

Version Date of approval Doc. control no. Summary of change

1.0 September 2018 - Interim Approach Issue

1.1 - Minor updates

2.0 April 2019 - Project Data Building Blocks, minor updates

Separation of Part 1 and Part 2

3.0 October 2019 - Clarification on usage of ‘packages’ of work, systems engineering and visualisation requirements added, minor updates







Preface

Transport for New South Wales (TfNSW) is developing the Digital Engineering (DE) Framework to facilitate time, cost and quality improvements to the way that projects are planned, designed, constructed, operated and maintained throughout their lifecycle. The current release of the DE Framework provides an Interim Approach, with continuous improvement towards best practice and a Transport cluster-wide fully implemented DE Framework.

DE processes included in the DE Framework provide TfNSW with an approach that creates digital information in an accessible format that will support and enhance stakeholder engagement, decision making, asset management, capability and capacity planning.

Implementing and adhering to this vision will enable individuals, who are responsible for the delivery and management of TfNSW’s assets, to make more informed decisions.

This document should be read in conjunction with all related DE Framework Interim Approach documentation. Any application of the DE Framework Interim Approach or any of its parts must be considered in a project-specific context. Adoption of the DE Framework should be undertaken in consultation with the DE Team ([email protected]) to ensure best appropriate practice.

Engagement with the Digital Engineering Team

The first point of contact for the project team, implementing this DES for a TfNSW project, is your project TfNSW DE Manager.

For general enquiries and assistance with application of this DES and associated guidelines, education, training, or planning and commencing a digital engineering project, please contact the Digital Engineering Team at [email protected].

The DE Framework embraces a culture of continuous improvement. Suggestions, comments and feedback are welcomed and encouraged.

https://www.transport.nsw.gov.au/digitalengineering

mailto:[email protected]

https://www.transport.nsw.gov.au/digitalengineering







Table of Contents

1. Introduction ................................................................................................................... 7

1.1. The Interim Approach ............................................................................................. 7

1.2. Purpose of this document ....................................................................................... 9

1.3. Structure of this document ...................................................................................... 9

1.4. Scope of this DES .................................................................................................. 9

1.5. Terms and definitions ........................................................................................... 10

1.6. References ........................................................................................................... 10

2. Collaborative working requirements .......................................................................... 11

2.1. Collaboration principles ........................................................................................ 11

2.2. Collaboration activities .......................................................................................... 11

3. The TfNSW-CDE for IP Projects .................................................................................. 12

3.1. The Contractor-CDE ............................................................................................. 13

3.2. Workflow between the CDEs ................................................................................ 14

3.2.1. Information exchange process .................................................................. 14

3.2.2. Bulk uploads ............................................................................................. 15

3.3. ECM File Metadata Requirements ........................................................................ 15

3.3.1. Title (file naming) ...................................................................................... 17

3.3.2. Approval States ......................................................................................... 17

3.3.3. Suitability .................................................................................................. 19

3.3.4. Review Outcome ....................................................................................... 20

3.3.5. Revisions and versions ............................................................................. 20

3.4. Existing data review.............................................................................................. 22

3.5. Validation of new deliverables .............................................................................. 22

3.6. Email requirements .............................................................................................. 22

3.7. Request for Information (RFI) requirements ......................................................... 22

3.8. Data security ........................................................................................................ 22

3.8.1. Data Security Protocol .............................................................................. 23

3.9. Information management governance .................................................................. 23

4. Project data building blocks (PDBB) .......................................................................... 25

4.1. Structuring and standardisation of data ................................................................ 26

4.2. Project Location classifications and referencing ................................................... 27

4.2.1. Referencing for location classification ....................................................... 28

4.2.2. Multi-owner projects .................................................................................. 28

4.2.3. The Asset Location ................................................................................... 28

4.3. Asset classification for projects ............................................................................. 28

4.3.1. Asset type classification ............................................................................ 29

4.3.2. System Classification ................................................................................ 30

4.3.3. Referencing for asset classifications ......................................................... 31

4.4. Discipline classification and referencing ............................................................... 31

4.5. Work Packages .................................................................................................... 32







4.5.1. Work Package Classification ..................................................................... 32

4.5.2. Project Work Packages ............................................................................. 33

5. Management Requirements ........................................................................................ 34

5.1. Submission of DE deliverables ............................................................................. 34

5.2. Digital Engineering Execution Plan (DEXP) .......................................................... 34

5.3. Management of the Project Data Schemas (PDS) ................................................ 35

5.3.1. Changes to PDS ....................................................................................... 36

5.3.2. Changes to Uniclass 2015 ........................................................................ 37

6. Technical Requirements ............................................................................................. 38

6.1. Systems engineering deliverables ........................................................................ 39

6.1.1. Structuring and standardisation of data ..................................................... 39

6.1.2. Review of existing data ............................................................................. 40

6.1.3. Verification and validation ......................................................................... 40

6.1.4. File submission format .............................................................................. 40

6.2. Survey deliverables .............................................................................................. 41



6.2.3. Validation .................................................................................................. 45


6.3. CAD deliverables .................................................................................................. 46

6.3.1. ASA Concession ....................................................................................... 47

6.3.2. Smart Tags and metadata spreadsheet .................................................... 47

6.3.3. Drawing title block ..................................................................................... 48

6.3.4. CAD layer naming ..................................................................................... 55

6.3.5. Composite models .................................................................................... 57


6.3.7. Validation .................................................................................................. 57


6.4. BIM deliverables ................................................................................................... 59

6.4.1. BIM requirements ...................................................................................... 60

6.4.2. Model classification requirements ............................................................. 62

6.4.3. Model properties requirements .................................................................. 63


6.4.5. Model collaboration procedures, federation and sharing ........................... 64

6.4.6. Model reviewing and validation ................................................................. 65


6.5. Visualisation ......................................................................................................... 68



6.5.3. Validation .................................................................................................. 69


6.6. GIS deliverables ................................................................................................... 70








6.7. Time deliverables ................................................................................................. 71

6.7.1. Project schedule deliverable requirements ................................................ 71

6.7.2. 4D model deliverable requirements ........................................................... 71

6.7.3. Existing data review .................................................................................. 72

6.7.4. Validation .................................................................................................. 72

6.7.5. Time deliverable submissions ................................................................... 72

6.8. Cost deliverables .................................................................................................. 73


6.8.2. 5D Model deliverables ............................................................................... 74


6.8.4. Validation .................................................................................................. 74

6.8.5. Cost deliverable submissions .................................................................... 74

6.9. Asset data deliverables ........................................................................................ 75

6.9.1. Asset register requirements ...................................................................... 75



6.9.4. Validation and asset handover .................................................................. 80

6.9.5. Asset data submission format ................................................................... 80

7. Project team (responsibilities) .................................................................................... 81

8. Assurance requirements ............................................................................................. 83

8.1. Quality assurance and quality control ................................................................... 83

8.2. Performance management/continuous improvement ............................................ 83

Appendix A - Reference of standards and guidelines ..................................................... 85

Appendix B – Digital Engineering Execution Plan (DEXP) Template (DMS-FT-532) ...... 88

Appendix C – IFC ................................................................................................................ 89







1. Introduction

1.1. The Interim Approach

This Digital Engineering Standard (DES) and supplementary templates and guidelines, form the Interim Approach that provides the tools and requirements to assist TfNSW projects seeking to implement DE post September 2018. These tools will continue to be developed over time, with incremental updates and new releases of the DE Framework documents provided.

The documents available as part of the DE Framework, are illustrated in Figure 1. DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles provides further details.

The DE Framework documents include:

1. The TfNSW Digital Engineering Standard and supporting guides:

a. The TfNSW DE project set-up, commercial and procurement guidelines and project management tools are for use by TfNSW staff implementing DE on a project and provide guidance, contract templates and DE tools and templates.

b. The Supporting Technical Guides provide practitioner-level guidance on the implementation of the specific requirements of the DES, based on DE discipline, and provide worked examples.

2. Tender Documents provide guidance on the adaptation of standard TfNSW contract templates for use on DE enabled projects. These templates reference the DES, with project-specific DE requirements included in the DE Execution Plan (DEXP) template. The completed DE contract documentation, Project DEXP template and DES are then provided to the Contractor.

3. The Contractor Documents, specific to DE. This includes the project specific DEXP (Project DEXP), completed and approved for implementation by TfNSW.

Note, for complex projects where the work is to be completed as separate stages or by various subcontractors, multiple Project DEXPs may be required. Where multiple plans are required, these must be aligned with a lead DEXP.







Figure 1: DE Framework Document Hierarchy

TfN

SW

Do

cum

en

tsT

end

er

Do

cum

ents

Pro

ject

Do

cum

en

ts

Intern al TfNSW Do cument

Co ntrac tor Do cument

TfNSW Guides TfNSW Template

TfNSW DE Procurement and

Project Management Guides

Supporting Technical Guides

Data and Information Asset Management

PolicyCP17005

Project DEXP Template

Project Deed TfNSW Standard

RequirementsProject Services/

Works Brief

Project SpecificDEXP

Digital Engineering

Standard

Standard(mandatory)

Policy

Project Data Building Blocks

Project Data Schemas







1.2. Purpose of this document

The This DES is the lead document in the DE Framework for the Contractor, providing minimum requirements for implementation of DE. It details how the Data & Information Asset Management Policy is to be implemented through the application of the DE Framework.

This DES describes the language and approach to be adopted when implementing DE for TfNSW projects.

Specifically, this DES provides requirements and guidance on:

• The structure of the DE Framework, including DE’s influence on the achievement of organisational and asset management objectives

• The structure and information workflow within a project team’s Common Data Environment (CDE)

• The requirements for Project Data Building Blocks (PDBB) and Project Data Schemas (PDS), which is a common language and structure for all project information and data

• The implementation of 3D modelling and the expectations of how project teams should integrate 3D into project delivery

1.3. Structure of this document

This document is provided in two parts:

1. Part 1 – TfNSW Digital Engineering Standard, Concepts and Principles (DMS-ST-202) - An overview of the TfNSW operating environment and DE concepts.

2. Part 2 (this document) – TfNSW Digital Engineering Standard, Requirements (DMS-ST-207) - The management requirements and technical outputs (deliverables/submissions) that are required during the delivery of a TfNSW DE-enabled project.

This document is to be read in conjunction with the TfNSW Configuration Management Plan (T MU AM 04001 PL) and relevant Agency configuration management plans.

1.4. Scope of this DES

This DES is applicable for Infrastructure & Place (IP) staff and Contractors delivering TfNSW DE-enabled projects during the Plan-Acquire phases (ie planning, design and construction). The Demand/Need, Operate/Maintain and Dispose phases of the asset lifecycle are not currently within the scope of the DE Framework. Refer to Figure 2.







Current scope of DE

Figure 2: The current application of DE within the asset lifecycle

When implementing DE for TfNSW projects, this DES should be read in conjunction with all related requirements set out in the contract documents.

DE activities currently excluded from the scope of the DE Framework are:

• BIM for operation and maintenance

• Advanced building materials

• Pre-fabrication and modular construction

• 3D printing and additive manufacturing

• Autonomous construction

• Augmented reality

• Big data and predictive analysis

• Wireless monitoring and connected equipment

• Cloud and real time collaboration

It is expected these items will be covered in later releases of the DE Framework.

1.5. Terms and definitions

The terms and abbreviations used in this document have the meaning/definitions provided in DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles, Appendix B.

1.6. References

This DES makes reference to various TfNSW and industry standards and guidelines. Sources include:

• TfNSW Asset Standard Authority (ASA)

• IP standards and procedures

• ISO, Publicly Available Specifications (PAS) and industry standards and guidelines.

A list of references and relevant standards and guidelines is provided in Appendix A.







2. Collaborative working requirements

A key outcome of DE is to support collaborative working. This section defines how, where and when project information will be shared. The processes and procedures for how collaborative working will be enabled and achieved by the project are to be documented in the Project DEXP, including the collaboration principles and activities.

2.1. Collaboration principles

The Contractor must document in the Project DEXP details of the collaboration processes to be adopted, sufficient to demonstrate appropriate timing and types of collaboration to achieve the project objectives.

2.2. Collaboration activities

The Project DEXP will, at minimum, include details of relevant collaboration activities, including:

• Frequency and format of milestone information exchanges.

• Proposals to manage restrictions around the sharing of data and information in line with TfNSW’s security requirements.

• How non-geometric data and information will be appropriately associated with the BIM model and visibility of this data and information will be maintained throughout the project.

• Details of model review workshops and other collaborative working practices eg use of model federation and coordination at design and/or site meetings (refer to Section 6.4).

• The proposed frequency and methods for Contractor and TfNSW project stakeholders to conduct reviews using federated model / data.

• How the handover of asset information from the Contractor-CDE to the TfNSW-CDE at the required data exchange points will be managed and recorded throughout the project.

• Quality management procedures, for example clash detection, to ensure deliverables are assured and error free prior to submission to TfNSW.







3. The TfNSW-CDE for IP Projects

The Project CDE is made up of two parts: the TfNSW-CDE and the Contractor-CDE. The current requirements for the CDEs are provided in the following sections.

This Interim Approach DES is only applicable to the Plan-Acquire-phase. This includes the process for the upload of required information deliverables to the specified TfNSW systems for scheduling, document/file management, email and progress claims.

Figure 3 provides a high-level conceptual illustration of the interfaces between the TfNSW and Contractor CDEs.

TfN

SW

-CD

EC

on

tra

cto

r-C

DE

Inte

rfa

ce

so

ftw

are

ECM(InEight)

Scheduling tool(Primavera P6)

ECM toolScheduling

tool

Internal email tool

GIS tool CAD tool

BIM tool

BIM toolGIS tool

(ESRI)

Internal emailtool (Outlook)

CAD tool

Risk mngmnt tool

(CURA)

Accounting tool(SAP/PMWeb)

TfNSW software

Contractor software

TfNSW owned/Contractor interface

Central Planroom

(VPR - ProjectWise)

Incident mngmnt tool

(INX)

Community engmnt

(Consult. Manager)

Reporting tool(Tableau)

Requirements managemnt

tool(DOORS)

Forecasting tool(PIMS)

Cost estimating tool

(CostX)

Figure 3: Current Contractor-TfNSW CDE Interfaces

Standardised file formats and data structures are critical to enable automatic data validation of submissions by TfNSW.

The current TfNSW-CDE includes the software listed in Table 1. Additional software may be included in the TfNSW-CDE based on project-specific requirements.







Table 1: Current TfNSW-CDE

Ref System Purpose Contractor Usage

1 InEight Document

(formerly TeamBinder)

Enterprise Content Management (ECM) tool

Document transmittal and management

Project communication control and governance

Transmittal of submissions and deliverables to TfNSW.

Project email and correspondence with TfNSW and Stakeholders.

2 Primavera P6 Project scheduling and construction sequencing

Upload of agreed project schedule as per the Contract.

Reporting of progress against planned program and milestone dates.

3 Virtual Plan Room (VPR) - ProjectWise

Central plan room for model and drawing transmittal, storage and archiving

Contractor to supply deliverables compliant with requirements for upload of models and drawings at Configuration Management Gate (CMG) 3 and CMG5.

TfNSW is responsible for upload of approved models and drawings to the VPR.

4 INX To record, manage and report on incidents, reliability issues and defects

Incidents, hazards and risks identified on the project are to be recorded directly in the INX system.

3.1. The Contractor-CDE

The Contractor-CDE, utilised by the Contractor's project team, is not limited by TfNSW's DE requirements. Any appropriate IT solution may be adopted by the Contractor that produces outputs that comply with the minimum requirements set out in this DES, including open data exchange formats and standardised project data structures specified in the PDS, to enable federation and Submission.

The use (workflows), control, permissions and governance of the Contractor-CDE is to be documented in the Project DEXP to ensure that all project team members are aware of how to use and interface with the Contractor-CDE.

In relation to the CDE, at a minimum the Project DEXP is to include:

• Metadata schema for tagging files uploaded to the Contractor-CDE. It is recommended that the Contractor adopt DMS-FT-533 ECM Schema Template requirements to standardise the metadata tags used within the project.

• Data and information review and validation process/workflow.

• Personnel responsible for document control (validating, uploading, tagging).

• Interface with the TfNSW-CDE, including control and governance of this interface.







• Project-specific CDE requirements, including the interface between the systems (manual or automated), are also to be specified in the Project DEXP.

3.2. Workflow between the CDEs

This section explains the information requirements for all file deliverables (including documents, spreadsheets, drawings, models) exchanged from the Contractor-CDE to the TfNSW-CDE. The Contract contains the complete list of deliverables and files required to be submitted for each discipline.

3.2.1. Information exchange process

With each information exchange there are a number of steps required by the Contractor and TfNSW to ensure that the DE data and information is correct. These steps are summarised in Figure 4.

TfN

SW

-CD

EC

on

tra

cto

r-C

DE

Inte

rfa

ce

Validate data complies

with required

structures and is in

the correct format

Contractor uploads and transmits the submission

to the TfNSW receiver

Information and data

review

(metadata and schema)

Update the

comments

register

Update

submission and

respond to

comments

Are any

changes

required?

YES

NOSubmission

accepted

Technical review

START

TfNSW provide comments to

contractor via ECM interface

Figure 4: Information Exchange Process







3.2.2. Bulk uploads

Bulk upload of files to the ECM may be enabled by the Contractor. Where the metadata from the model and/or product sheet is correctly aligned with the ECM metadata requirements (refer to Section 3.3). A template for TfNSW’s ECM tool is available to facilitate this process (DMS-FT-533 ECM Schema Template).

3.3. ECM File Metadata Requirements

The minimum metadata included with files uploaded to the TfNSW-CDE must align with the requirements specified in DMS-FT-533 ECM Schema Template, in order for the TfNSW-CDE to accept the submission as compliant. Any project specific ECM metadata requirements are to be included in the Project DEXP.

Specific technical fields explained in the following sections, with a summary of all fields is included in Table 2. Refer to DMS-FT-533 ECM Schema Template, for further details.

Table 2: ECM Schema

Ref ECM Field name Description of use

1 Document No

Defined by Project. The unique document number required to reference the applicable document uploaded following the document numbering schema.

2 Title Defined by Project. The applicable title description associated with the document.

3 Revision For tagging a document with a revision reference when major changes updated.

4 TfNSW Version Child of Revision used for tagging a document when minor changes are updated.

5 Amendment Description User comments outlining the changes made in the document.

6 State For tagging a document with its CDE state. E.g. Client Shared (for documents submitted to TfNSW) or Published (when authorised for use, e.g. AFC)

7 Suitability For defining the purpose or appropriate use of the document. E.g. For Coordination, For Information, For Review and Comment.

8 Review Outcome This field is not populated on upload to the TfNSW ECM but is managed automatically by the ECM tool as part of the review workflow.

9 Security Classification Information Security Classification, Labelling & Handling Standard defined according to the “NSW Government Recordkeeping Manual Guidance in Brief 58”

10 Program Program name defined by TfNSW.

11 Project Project name as part of a program defined by TfNSW

12 Contract Contract reference to deliver a part of Program/Project as per the project delivery strategy defined by TfNSW.








13 Originator Contracted organisation responsible for the production of the documents.

14 INSW Phase/TfNSW Stage

Infrastructure NSW (INSW) project governance phases and TfNSW investment assurance gates defined by TfNSW.

Some projects do not use this field.

15 Project Milestone Defined by TfNSW, Project specific milestone.

16 Discipline

Defined by TfNSW. A unique identifier to identify the organization responsible for carrying out the design.

Sourced from the Project Data Building Blocks – provided to the Contractor by TfNSW.

17 Sub-Discipline

Proposed by TfNSW. A unique identifier to identify the organization responsible for the design.

Sourced from the Project Data Building Blocks.

18 Location

Defined by Project. Refers to the location in the system to which the document refers to or belongs. E.g. Station, building, etc


19 Sub-Location

Defined by Project. Refers to the sub-location in the system to which the document refers to or belongs. E.g. Station, building, etc.


20 Sub-sub-Location

Defined by Project. Refers to the second level of sub-location in the system to which the document refers to or belongs. E.g. Platform 1, Meeting Room, etc.


21 Document Type The type of information the document contains. E.g. A report, drawing, etc.

22 Serial Number A sequential number used in reference to the document within one of a series not distinguished by any other of the fields defined.

23 BIM Reference Optional reference to models, model objects or model views.

24 GIS Reference References to GIS managed locations related to the document, if required.

25 Design [Work] Package

Proposed by Project. Refers to a suite of documentation that makes up the work package. E.g. Design Work Package, Construction Work Package, Commissioning Work Package, etc. Note: Design Package currently being used synonymously for all work packages.

26 Contractor Doc No For the Contractor to add the Contractor-CDE Document Number, if necessary.

27 Remarks User comments.

28 Date Recorded The date when the document was uploaded to the ECM.

29 Date Released The date when the document was promoted to the Published state.

30 Required for Handover A Y/N flag indicating whether the deliverable is required for asset handover.








31 Asset Owner The name of the organisation that is to receive the document at asset handover.

32 ASA VPR Discipline Existing VPR discipline codes used by TfNSW ASA.

33 ASA EDMS ID Set of allocated document identifier by TfNSW ASA.

34 ASA Amendment No Document amendment number managed by TfNSW ASA in relation to project milestone submissions.

TfNSW recommends, but does not mandate, that the Contractor metadata structures in the Contractor-CDE is a mirror of the TfNSW-CDE metadata structures.

3.3.1. Title (file naming)

Files uploaded to the TfNSW ECM are to be given a name that is appropriate to the content and provides a level of understanding to the project team utilising the file. The Contractor is to document any specific project file naming conventions in the Project DEXP and referenced in the MIDP.

3.3.2. Approval States

The Contractor is responsible for the management of Work in Progress (WIP) and Shared information within the Contractor-CDE and for the upload of files to the ECM tool. All files uploaded to the ECM tool are to be tagged with the correct metadata categorisation of Client-Shared information with State (Client-Shared) and Suitability (S1, S2, S3, S4), refer to Table 4.

TfNSW or the independent certifier (if required) is responsible for the correct metadata categorisation of Review Outcome information within the TfNSW-CDE.

At any stage in the workflow, the information may be rejected and returned to a WIP state for further development. The approval process with corresponding states and suitability (refer to Section 3.3.3) is illustrated in Figure 5.







Figure 5: Approval States, Suitability and Review outcome

Descriptions of the approval states and their intended uses are provided in Table 3. Intermediate checking or internal states, additional to those described in Table 3, are acceptable in the Contractor-CDE, however all these states must be defined clearly in the Project DEXP. Where state names used in the Contractor-CDE differ from those specified by this DES, these shall be agreed with the TfNSW DE Manager prior to use.

Table 3: Application of State within the CDE

Ref State State Description

1 Work-In-Progress (WIP) Information not checked or approved. WIP information exists only within the Contractor-CDE

2 Shared Information shared within the project team for a specific purpose (refer to Table 4)

3 Client Shared Information received and distributed to appropriate TfNSW personnel or external agent (including independent certifier or verifier) for review







Ref State State Description

4 Published Coordinated and validated information which is authorised for use on the project, for example for Construction.

9 Archived Superseded or otherwise archived information

3.3.3. Suitability

Suitability codes are applied to information that is Shared, Client Shared, Published or Archived.

On upload (Client-Sharing) of information to the TfNSW-CDE or after review by TfNSW, the Contractor is responsible for ensuring the appropriate Suitability Code (refer to Table 4) is included in the information metadata.

Table 4: Application of Suitability within the CDE

Ref State Suitability Code Suitability Title Suitability Description

1

Shared

S1 For coordination Information shared within the Contractor-CDE for coordination

2 S2 For information Information shared with project team for information only

3 S3 For review and comment

Information shared with project team for review and comment

4 S4 For stage approval

Information shared with project team for stage approval (typically at Configuration Management Gates)

5 L1 Legacy Information

Existing or archived Information shared with project team

6

Client-Shared

S1 For coordination Information shared with TfNSW for coordination

7 S2 For information Information shared with TfNSW for information only

8 S3 For review and comment

Information shared with TfNSW for review and comment

9 S4 For stage approval

Information shared with TfNSW for stage approval (typically at Configuration Management Gates)

6

Published

D1 For costing Information published for costing purposes

7 D2 For tender Information published for tender purposes

8 D3 For Contractor design

Information published for construction design purposes

9 D4 For manufacture / procurement

Information published for manufacture/procurement purposes







Ref State Suitability Code Suitability Title Suitability Description

10 A1 With no comments

Information published with no comments

11 A2 With comments Information published with comments

12 AB As-Built Information published as an As-Built record

13 Archived Any Any Any Suitability

3.3.4. Review Outcome

Review Outcome codes are applied to information in the TfNSW-CDE during the review workflow. The values shown in this table may vary between projects.

Table 5: Application of Review Outcome within the TfNSW-CDE

Ref Review Outcome Code

Review Outcome Title Review Outcome Description

1 R1 Under Review Information shared with TfNSW currently under review

2 R2 Rejected Information shared with TfNSW being rejected post review

3 R3 Not Rejected Information shared with TfNSW not rejected post review

4 R4 IC Certified Information shared with TfNSW to be Independently Certified

3.3.5. Revisions and versions

TfNSW requires all information within the Contractor-CDE and TfNSW-CDE to be revision and version controlled, refer to Table 6.

3.3.5.1. Revision

At each submission of a file from the Contractor-CDE to the ECM tool within the TfNSW-CDE, the ECM revision shall be incremented. The first issue shall be ‘A’ if pre-AFC and 00 if AFC or beyond (T MU AM 01012 ST Engineering Document Requirements).

For engineering drawings (.dgn and/or .dwg and.pdf) and models (refer to Section 6.4) to be uploaded to the VPR (at CMG3, CMG4 and CMG5), the Contractor must control the revisions of design artefacts as required by T MU MD 00006 ST Engineering Drawings and CAD Requirements, with any project specific requirements stated in the Project DEXP. This revision numbering is known as the ASA Amendment Level Revision. Refer to Section 6.3 for DE discipline specific (BIM model and CAD drawing) revision and version control.







Note, the Contractor is not required to upload directly to the VPR, but is required to provide TfNSW with information compliant with the file formats, file naming and metadata required for VPR upload.

Table 6: Revision and version control within the TfNSW-CDE

Ref Deliverable Type File Formats Uploaded to TfNSW-CDE

Revision Numbering Standard

1 All deliverables excluding Engineering drawings and models

As required by the Contract

ECM (all CMG) T MU AM 01012 ST Engineering Document Requirements

2 Engineering drawings

.dgn and/or .dwg and.pdf

ECM (all CMG) VPR (CMG3, CMG4 and CMG5)

T MU MD 00006 ST Engineering Drawings and CAD Requirements

3 Engineering models As required by the DEXP

ECM (all CMG) VPR (CMG3, CMG4 and CMG5)

DMS-FT-532 DEXP Template

3.3.5.2. ECM Version

The TfNSW ECM tool governs the ECM Version property automatically: when a new revision is added to the TfNSW ECM tool, its version is set to ‘0’. On the rare occasions that a file is replaced or adjusted without a new revision being assigned, the version number is incremented automatically.

The ECM Version is a TfNSW ECM property, and is different to the Contractor’s version number in a drawing title block. The version shown on a drawing is not required to match the ECM Version in the TfNSW ECM. Refer to Section 6.3 for details. An example of the progression of revision and version numbering through the project life is provided in Table 7.

Table 7: Example Document Revision Progression

ECM State ECM Suitability ECM Revision (Contractor revision)

ECM Version

(TfNSW version)

ASA Drawing Rev (VPR AMD)

Submission 1 S3 A 0

TfNSW Returned with Comments

A 1

Submission 2 S3 B 0

Endorsed by TfNSW B 1

Published (AFC) D3 00 0 A

AFC updated during construction

D3 01 0 B

As-built AB 01 1 C







The application of this revision numbering for a project is to be clearly articulated for the project team in the Project DEXP.

3.4. Existing data review

Existing data and information is to be reviewed for relevancy to the project. Where existing data is to be re-used as part of a new deliverable, this data is to be classified in accordance with this DES, if not already compliant.

3.5. Validation of new deliverables

Deliverables (files) submitted to the ECM tool will be verified to ensure compliance with the ECM metadata schema specified in the Project DEXP. Submissions that do not comply with these requirements will be returned to the Contractor for correction.

3.6. Email requirements

Communication by email is used within a project for both informal and formal correspondence. Project related email communications are to be maintained as part of the project record. Project emails to TfNSW or nominated project stakeholders are to be communicated via the nominated ECM tool or other project nominated tool.

Project specific requirements for the classification and management of email files are to be included in the Project DEXP. Classification of emails includes security classification based on the NSW Government Dissemination Limiting Marker (refer to the ECM Schema in the Project DEXP).

3.7. Request for Information (RFI) requirements

The Contractor must submit all RFIs using the forms function within the ECM tool.

3.8. Data security

TfNSW DE projects must balance the project-specific needs of confidentiality, integrity and accessibility with the consequences of any loss or unauthorised release of the information, whether of a personal or business nature.

For all built assets, specific security measures related to information exchange will be identified by TfNSW on a project-by-project basis and communicated to the Contractor and its supply chain accordingly.







3.8.1. Data Security Protocol

The Contractor is required to comply with all relevant TfNSW security standards and obligations (Refer to T MU AM 02004 ST Management of Asset Information).

The Project DEXP must demonstrate how the Contractor will manage and monitor compliance against these security requirements. At a minimum, the Contractor will provide a Data Security Protocol (DSP) in the Project DEXP that outlines security protocols to be implemented for the project. The DSP will address:

1. User access rights and permissions, outlining the various roles and degrees of access to the data. Roles are to correlate to those defined in this DES and the Project DEXP. The DSP also will identify any additional user access required;

2. Data protection, including documenting how the data will be protected from:

i. Accidental loss,

ii. File Corruption (malware, viruses),

iii. Misuse/negligence,

iv. Unauthorized conveyance, and

v. Deliberate attack (internal or external);

3. Data process and handling protocol procedures for:

i. Data Exchange: How and with what frequency data will be exchanged. The DSP is to align with other requirements in the Project DEXP and provide more detail specific to data exchange;

ii. Data Maintenance: Describe the maintenance plan for all data sources, transmission devices, and storage devices used for the project;

iii. Data Backup: Describe in detail the backup scheme implemented by the Project DE Team, including frequency and retention of backups; and

iv. Data Archiving: Describe the storage, retrieval, and retention system to be used by the Project DE Team.

Where applicable, in the case of sensitive asset data as identified by TfNSW, the Project DEXP must define how the security requirements will be achieved in respect of software platforms, their configuration, operation and maintenance.

Project specific cybersecurity requirements, such as provision of an SOC 2 audit report, are addressed on a project by project basis and included in the project contract.

3.9. Information management governance

TfNSW requires Contractors to develop, implement and maintain procedures to manage Digital Engineering information. Procedures must be documented in the DEXP and address as a minimum:







• Data exchange

• Data backup, including a minimum frequency of weekly back-ups, and retention of backups

• Data archiving

Information uploaded to the TfNSW-CDE must be clearly categorised within the TfNSW-CDE metadata, including approval state and suitability, using the codes and definitions defined in Section 3.3.

Security classification and confidentiality implications shall be considered in managing the provision and receipt of asset information. Refer to T MU AM 02004 ST Management of Asset Information.







4. Project data building blocks (PDBB)

At the commencement of each project phase, the TfNSW project team will establish the PDBB, utilising DMS-FT-548 Project Data Building Blocks Template. Control and governance of the PDBB during the life of the project remains with TfNSW. The PDBB are periodically updated by TfNSW based on the scope of the project, development of the design and the increasing level of understanding, including improved understanding of:

• the optimal location breakdown;

• asset systems and types incorporated in the design and delivery;

• the parties engaged in the execution of the project, and;

• how the scope is grouped into work packages.

The PDBB will be finalised by TfNSW and used to generate the PDS for inclusion as an appendix in the DEXP Template that is issued to market as part of the tender documents (refer to Section 5.2 for more information).

The PDBB datasets included in DMS-FT-548 PDBB Template are summarised in Table 8.

Table 8: Project Data Building Block groupings

Ref Building block type

Building block dataset Purpose

1 Project specific building blocks

Project Details Specifies the Program / Project list and, as per the project delivery strategy, the list of Project Contracts. Following procurement, Organisations can be listed and associated with Project Contracts Codes.

2 Location List Specifies all asset locations applicable to the project. Each location is named and classified with Uniclass 2015.

A location hierarchy is defined to reflect location-to-location relationship. This hierarchy may include the full enterprise context; however, projects can indicate which three levels of locations are applicable for referencing documents in an enterprise contentment management system.

3 Asset List The Asset List specifies all assets applicable to the project. Each asset is named and classified with Uniclass 2015. An asset hierarchy is defined to reflect asset-to-asset relationships.

The Asset List provides mapping between assets and locations.

The Asset List is also used in project Scope Management. Work Packages (defined in the Work Package List) are assigned to Assets to reflect scope packaging decisions related to Design, Construction and Commissioning.







Ref Building block type

Building block dataset Purpose

4 Work Package List The Work Package List is used to organise project scope.

Work Packages are related to Work Package Groups and Types to standardise the structure of projects and cost estimates.

Logical contracts (defined in the Project Details tab) are assigned to Work Packages to reflect the delivery strategy.

5 Standard TfNSW building blocks

Standard Version Control

Version control of standard building blocks. For example, specifies which version of Uniclass 2015 tables are in use to support classification of Locations and Assets.

6 Discipline Specifies TfNSW Business and Technical Disciplines.

7 ECM State & Suitability

Enterprise Content Management System (ECM) Document State & Suitability. These two fields determine the approval level and appropriate use for information. See ISO 19650 or BS 1192:2007. Review Outcome - Provides information for document under review.

8 Project Milestone Standard list of IP Project Milestones.

9 INSW Phase TfNSW Stage

Standard list of INSW Phases/TfNSW investment stages

10 Document Type Standard list of document types.

11 Security Classification Standard list as per 'NSW Government Information Classification, Labelling and Handling Guidelines.

TfNSW uses the PDBB to generate the PDS issued to the Contractor as part of the Project DEXP template (refer section 5.3).

4.1. Structuring and standardisation of data

All deliverables (geometric and non-geometric), including drawings, models, engineering artefacts, documents and datasets are to be appropriately classified in accordance with this DES, applicable Guidelines and asset owner Standards. In addition, the data and information contained within deliverables, including 3D objects, CAD layers and asset information, also requires classification.

For projects delivered under the DE Framework, data and information is to be classified by:

• Project location







• Asset

• Work Package (Design, Supply, Construction, Commissioning)

• Discipline

The general application of each of these classification types is provided in the sections following. The specific classification requirements for deliverables are provided in Section 5. The application of classification and referencing for the project is to be managed through a change control process using DMS-FT-548 PDBB Template and propagation of changes to the Contractor via reissuing of PDS.

Refer to DMS-SD-124 Application of Uniclass 2015 for Transport for further guidance and examples demonstrating the application of classifications in a project context.

4.2. Project Location classifications and referencing

Project Location is used during the acquire phase, for project delivery. The TfNSW DE Framework mandates the use of the Uniclass 2015 Complexes (Co), Entities (En) and Spaces/Locations (SL) classification tables to describe the various project location containers/groups of assets within common locations (refer to Table 9).

Table 9: Project Location classification categories aligned with Uniclass 2015

Ref Classification Description Relevant Classifications

1 Project Location The location of an asset or group of assets (where the asset is) For example railway station or railway corridors and sidings.

Complexes (Co)

Entities (En)

Spaces/Locations (SL)

During the life of the project, the application of the Project Location classifications increases in granularity, in line with the LoD requirements. A summary of this requirement is provided in Table 10.

Table 10: Project Location Minimum Classification Requirements (Uniclass 2015)

CM Gate Minimum classification required

Co En SL

CMG0 Co_xx As required As required

CMG1 Co_xx En_xx SL_xx

CMG2 Co_xx_xx En_xx SL_xx_xx

CMG3 Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx









4.2.1. Referencing for location classification

Referencing must be applied to each level of the asset location classification (Complexes, Entities and Spaces/Locations) to give it uniqueness in case there are multiples in the same parent location. For example, Up Main Line and Up Suburban Line, with ‘line’ being the classification and ‘Up Main’ or ‘Up Suburban’ being the unique reference.

References are to be applied by the Contractor and are to be consistent with existing naming conventions, including ASA’s T MU AM 02002 TI Asset Classification System and T MU AM 01007 TI Asset Reference Codes Register. Existing Project Locations, including references, are provided by TfNSW as part of the PDS.

All references proposed by the Contractor are to be submitted to TfNSW for approval, usually as part of a deliverable.

Alternative Project Locations, including references, may be suggested by the Contractor to align with changes to the design or construction methodology. These new or revised codes are to be requested via DMS-FT-374 DE Code Request Form, agreed with TfNSW and documented in the Project DEXP.

4.2.2. Multi-owner projects

For projects where assets are owned by multiple parties, additional or variations to the Uniclass 2015 classifications may be required to accommodate contracting strategies or construction sequencing (Quality Assurance Lots). For example, where an Earthworks or Paving work package spans multiple complexes and owners. When required, these custom Project Locations are to be agreed with the TfNSW DE Manager and clearly documented in the Project DEXP.

Prior to handover of asset information to the multiple O&M parties, TfNSW will work with the Contractor to ensure assets are appropriately split and allocated to the relevant party in individual Handover Asset Registers.

4.2.3. The Asset Location

During the project plan/acquire phases, the location is known as the Project Location. When the information is transferred from PIM to AIM, the location is adopted or revised/mapped to T MU AM 02002 TI Asset Classification System and T MU AM 01007 TI Asset Reference Codes Register, and becomes the Asset Location. For the Interim Approach, TfNSW, not the Contractor, will be responsible for reviewing Project Locations and assigning appropriate Asset Locations within the Handover Asset Register(s) for the AIM for O&M purposes. This is to ensure that there is a consistent approach to asset location for O&M.

4.3. Asset classification for projects

All asset information shall be classified with a common language and structure, based on the Uniclass 2015 classification system.







4.3.1. Asset type classification

The TfNSW DE Framework uses the Uniclass 2015 Element/Functions (EF) and/or Products (Pr) classification tables to describe the type of a physical asset (refer to Table 11).

Table 11: Asset Type classification categories aligned with Uniclass 2015

Ref Classification Description Relevant Uniclass 2015 Classifications

1 Asset Type An individual asset or component (what the asset is) For example, walls or low voltage cables.

Elements/Functions (EF)

Products (Pr)

During the life of the project, the application of the EF and Pr type classifications increases in granularity, in line with the Level of Definition requirements specific to the project phase and classification type (refer to Table 12).

The assets must be defined to the level of the Maintenance Managed Item (MMI, the lowest

level of the asset hierarchy where an asset is to be included in the Handover Asset Register) by CMG3. To determine the MMI, refer to the rules for the inclusion of assets in the asset register as specified in T MU AM 02001 ST Asset Information and Register Requirements, section 7.1 Rules for creation of assets in the asset register.

Table 12: Element/Function Classification Requirements

CM Gate Minimum classification required

EF Pr

CMG0 n/a n/a

CMG1 EF_xx n/a

CMG2 EF_xx Pr_xx_xx

CMG3 EF_xx_xx Pr_xx_xx_xx



Refer to the Model Production Delivery Table (MPDT) in the Project DEXP for confirmation of asset classification requirements.

If Uniclass 2015 does not provide an appropriate EF or Pr classification, the Contractor is to request a new code via DMS-FT-374 DE Code Request Form. TfNSW will facilitate the creation of new codes from NBS (the custodian of Uniclass 2015), as required.








4.3.2. System Classification

The TfNSW DE Framework uses the Uniclass 2015 Systems (Ss) classification to define the engineering system that the asset is a component of (refer to Table 13).

Table 13: Asset System classification categories aligned with Uniclass 2015

Ref Classification Description Relevant Uniclass 2015 Classifications

1 Asset System

An individual or group of asset types that together perform a specific function (the purpose of the asset). For example communications systems or track systems.

Systems (Ss)

Every asset type (EF or Pr) identified in the Asset Register must be associated with a corresponding system (Ss) by Configuration Management Gate 3 as a minimum, and recorded in the Project Asset Register.

During the life of the project, the application of the Systems (Ss) classifications increases in detail, in line with the Level of Definition requirements, specific to the project phase and classification type (refer to Table 14).

The assets must be defined to the level of the Maintenance Managed Item (MMI) by CMG3. To determine the MMI, refer to the rules for the inclusion of assets in the asset register as specified in T MU AM 02001 ST Asset Information and Register Requirements, section 7.1 Rules for creation of assets in the asset register.

Table 14: Systems (Ss) Classification Requirements (Uniclass 2015)

CM Gate Minimum classification required Ss

CMG0 As required

CMG1 Ss_xx

CMG2 Ss_xx_xx

CMG3 Ss_xx_xx_xx_xx

CMG4 Ss_xx_xx_xx_xx

CMG5 Ss_xx_xx_xx_xx








4.3.3. Referencing for asset classifications

Referencing must be applied to individual elements/functions, products and systems to give them a unique reference and to distinguish between multiples of the same assets in the same location. These references are to be recorded in the Project Asset Register.

References are to be applied by the Contractor and created in compliance with the requirements of T MU AM 02001 ST Asset Information and Register Requirements. References are to be consistent with existing naming conventions, including ASA’s T MU AM 02002 TI Asset Classification System and T MU AM 01007 TI Asset Reference Codes Register. Where a reference is not available within these Standards, the Contractor should propose an asset reference for review and approval by TfNSW. If similar/duplicate assets are used within one project location, a unique identifier is to be included in the reference (for example ‘Bicycle Rack 1’ and ‘Bicycle Rack 2’).

The Contractor is to create an asset register to control and manage a project’s full list of Elements/Functions, Products, Systems and References. The asset register is to utilise the schema specified in the DMS-FT-537 Asset Register Template to facilitate data transfer to the O&M function. Refer to Section 6.9 for more information regarding the Asset Register.

4.4. Discipline classification and referencing

The TfNSW DE Framework mandates the classification of data and information by Discipline, a classification based on the organisational unit/team associated with a task, activity, information or asset. Discipline classification must be categorised as either Business Discipline or Technical Discipline, as described in Table 15.

Table 15: Project Discipline classification categories

Ref Classification Description Relevant Classifications

1 Technical Discipline

A functional grouping that provides asset specific classification of tasks, activities, deliverables or data, based on the engineering unit responsible.

For example, Civil or Electrical drawings.

TfNSW defined (refer to Table 16)

2 Business Discipline

A functional grouping that provides system-wide (not asset specific) classification of tasks, activities, deliverables or data, based on the business unit responsible.

For example, Sustainability, Scheduling, Contracts Administration, etc.

TfNSW defined (refer to Table 16)







Project information and data is to be classified by as a minimum the Level 1 Discipline Code, as per Table 16.

Table 16: Level 1 Discipline Codes

Ref Discipline Type Level 1 Discipline Code Description

1 Technical AR Architectural

2 CO Communication

3 CV Civil

4 EL Electrical

5 FE Fire

6 FL Fleet Systems & Equipment

7 GN General

8 HY Hydraulic

9 ME Mechanical

10 SG Signalling & Control

11 ST Structural

12 TE Technology

13 UT Utilities

14 Business CM Commercial Management

15 CY Community

16 EN Environmental

17 OP Operations Management

18 PC Project Controls

19 PM Project Management

20 PP Property

21 SF Safety

During the life of the project, the discipline code associated with a task, activity or information deliverable may change due to a sub-discipline (Level 2) code being used to provide more detail. In these cases, the required Level 2 Discipline Codes will be defined by TfNSW in the PDS for consistent application across the project.

4.5. Work Packages

4.5.1. Work Package Classification

The Contractor shall be provided with the TfNSW Work Package classification tables, including Work Package Groups and Work Package Types. These classification tables provide TfNSW’s preferred way of organising project scope. Contractors should refer to FT-







520 Scheduling Schema for the official list of work package classification tables. Table 17 lists Work Package Groups for illustrative purposes only.

Table 17 – Work Package Groups

Work Package Group ID

Work Package Groups

WG01 Project Management

WG02 Site Investigations (initial)

WG03 Design

WG04 Property

WG05 Environmental Assessment

WG06 Preliminaries

WG07 Supply

WG08 Construction

WG09 Commissioning & Handover

WG10 Finalisation

4.5.2. Project Work Packages

Contractors will be provided with all project defined Work Packages via the Scheduling PDS (FT-520 Scheduling Schema).

Each project work package includes the following information:

Work Package Code

Work Package Name

Work Package Type, which refers to the work package classification, and

the scope of each work package, which lists all assets (& their corresponding Technical Disciplines and locations) that are relevant to individual work package.

The Contractor must comply with the TfNSW issued Work Packages across all project disciplines that refer to Work Packages.

When associating a Work Package in a project deliverable, the full scope of the Work Package must be considered. For example, in a project Schedule, a schedule activity that references a Work Package must only include assets referred to in the Work Package definition.

If required, the Contractor may propose changes to the scope of a Work Package. For example, if assets (at a system level) are missing from the definition of a Work Package.

The Contractor is free to add additional granularity to the work package hierarchy provided by TfNSW so long as the additional Work Packages always roll-up to the TfNSW issued Work Packages.







5. Management Requirements

Management requirements are specified to assist the project team in implementing appropriate control, coordination and governance during the DE process. Management tools include the DEXP, PDS, communications and document control. The full suite of project-specific management requirements are included in the Project DEXP.

5.1. Submission of DE deliverables

Information can be formally submitted to TfNSW at any time during the course of a project phase, with contractual Shared and Published Submissions (refer to Section 3.3) usually aligned to the Configuration Management Gates (CMG) or Investment Assurance Gates (refer to DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles). These submissions inform whether the design meets the business and system requirements or justifies the decision to invest in the next phase.

The frequency of Submissions will be defined within the Contract, which is to be reflected in the Project DEXP and project schedule.

Based on the requirements of the Contract, the project schedule will document the agreed dates for the upload of submissions based on contract deliverable dates. The Contractor will be responsible for collecting and collating required information and making the submissions in accordance with the Contract.

Note: This DES is an Interim Approach. In its current status, some aspects of DE delivery are still in development. Application of deliverables yet to be defined within the DE Framework remains at the discretion of the TfNSW Project Manager and TfNSW DE Manager.

A summary of submission requirements is provided in DMS-SD-140 Project Deliverables Requirements Guide to be used as a checklist to facilitate compliance with this DES. It is to be noted that additional project specific requirements may be included in the project contract or Project DEXP.

5.2. Digital Engineering Execution Plan (DEXP)

The primary tool for the management of DE during the project is the Project DEXP. Requirements defined by TfNSW in the DE Standard and contract documents are reflected by the Contractor in the Project DEXP. Deliverables planned to fulfil the scope are detailed by the Contractor in the Master Information Delivery Plan (MIDP).

The TfNSW project team may choose to modify the DEXP Template (DMS-FT-532) and/or the MIDP Template (DMS-FT-555) for provision to the Contractor.

The Project DEXP and the MIDP are to be actively managed and updated throughout the course of the project to ensure that they align with the project scope, DE strategy, contract structure and available resources (tools/IT systems and personnel). The Project DEXP is to be submitted for TfNSW review and approval at the minimum project milestones as stated in Table 18.







Table 18: DEXP submissions

CM Gate

Document Type

Description/Purpose Minimum Requirement

CMG0 DEXP High level execution plan tailored to the Contractor’s scope of work.

As per the project-specific DEXP Template, based on DMS-FT-532 DEXP Template

CMG1 DEXP TfNSW approved document detailing the Contractors methodology, controls and governance of the DE process.

As per the project-specific DEXP Template, based on DMS-FT-532 DEXP Template

CMG2 DEXP Updated for Detailed Design As per the project-specific DEXP Template, based on DMS-FT-532 DEXP Template

CMG3 DEXP Updated for Construction as required As per the project-specific DEXP Template, based on DMS-FT-532 DEXP Template

CMG4 N/A - -

CMG5 N/A - -

It is important that the Project DEXP is updated to include any approved changes to the PDS.

TfNSW will provide project data schemas with the project specific DEXP template (modified DMS-FT-532 DEXP Template). Refer to Section 5.3 for requirements for management of the PDS.

5.3. Management of the Project Data Schemas (PDS)

The PDS is a collective term given to all schemas, specifications and templates that are required to standardise data across each DE discipline. TfNSW uses the PDBB to generate the PDS issued to the Contractor as part of the Project DEXP template.

During the life of the project, strict governance and change control of the PDS must be implemented. A list of the current DE schemas & templates that make up the PDS are provided in Table 19.

Table 19: DE Project Data Schemas

Ref DE Discipline Project Data Schema or Guide Document

Number

1 Documents (all files transmitted

to TfNSW via the ECM tool) and

correspondence

ECM Schema and Specification DMS-FT-533

2 Systems engineering Requirements Schema and

Specification

DMS-FT-563







Ref DE Discipline Project Data Schema or Guide Document

Number

3 Surveys Specified by project - schema currently

outside of scope of Interim DES Release

3.0. Digital Survey Guide provided for

project reference.

DMS-SD-142

4 CAD drawings CAD Schema and Specification DMS-FT-562

5 BIM models BIM Schema and Specification DMS-FT-516

6 Visualisation Specified by project - schema currently


3.0. Visualisation Requirements Guide

provided for project reference.

DMS-SD-130

7 GIS Specified by project – schema currently


3.0.

Pending

8 Time Scheduling Schema DMS-FT-520

9 Cost estimating Specified by project - schema currently


3.0.

Pending

10 Asset data Asset Register Template DMS-FT-537

Each schema above defines the specific metadata or data structures that the Contractor must comply with when submitting a deliverable related to that DE discipline.

5.3.1. Changes to PDS

During the project the Contractor is encouraged to collaborate with TfNSW to ensure that the PDS remains practical. Particularly that the locations and work packages remain aligned with the Contractor’s actual design and construction methodologies as closely as practicable.

Where a field is identified in the PDS as ‘provided by TfNSW’, Contractor proposed changes, modifications or additions are to be developed in collaboration with the project’s TfNSW DE Manager. Once finalised, DMS-FT-374 DE Code Request Form is to be completed by the project team and TfNSW DE Manager and submitted to the TfNSW DE Team for approval.

Once agreed, the project’s TfNSW DE Manager will then update the PDBB and reissue the impacted PDS. On receipt of a new or updated code from TfNSW, the Contractor is required to update all affected data to ensure it remains aligned and reflected in all subsequent deliverables.

TfNSW will endeavour to accommodate any code requests, however, proposed changes will be evaluated against impacts to all interfacing datasets and systems across TfNSW, including the OIM, PIM, AIM and benchmarking.







5.3.2. Changes to Uniclass 2015

If a project identifies the need for a new Uniclass 2015 code, the project’s TfNSW DE Manager is to complete DMS-FT-374 DE Code Request Form and submit this to the TfNSW DE Team. The TfNSW DE Team will liaise with NBS (the custodian of Uniclass 2015) on behalf of the project to discuss changes to Uniclass 2015 table(s). Changes agreed by NBS will be provided to the project team.







6. Technical Requirements

Provided in the following sections are the required deliverables aligned with the DE disciplines, noting that several are placeholders for future releases of the Interim Approach:

Table 20: Release coverage of DE disciplines

DE discipline Release 1 Release 2 Release 3 Future Release

Systems engineering

Survey

CAD

BIM (3D)

Visualisation

GIS

Time (including 4D)

Cost (including 5D)

Asset data (including 6D)

Note: the scope of coverage for each discipline will be incrementally addressed as the DE Framework is developed and best appropriate practice established by our Pilot Projects.







6.1. Systems engineering deliverables

Within the Systems Engineering discipline, ‘a system is a combination of hardware, software, people, processes, and support arrangements that meet customer needs as a product or services. A system can include data, facilities, materials and naturally occurring features’ (T MU AM 06006 ST Systems Engineering Standard).

This standard defines the linkage between a requirements management system and the PDBBs for the delivery of physical infrastructure assets. As such, the current scope of Systems Engineering for DE-enabled projects, as defined by this Standard, is limited to:

the acquisition of physical infrastructure assets, and

Requirements Management deliverables.

DE-enabled projects delivering Systems Engineering outcomes, as required by T MU AM 06006 ST Systems Engineering Standard, are required to align the project requirement definition, where appropriate, with DMS-SD-563 Requirements Schema and Specification.

DMS-SD-563 Requirements Schema and Specification has been developed in compliance with T MU AM 06004 ST Requirements Schema to include cross-reference to appropriate PDBB, to meet DE project specific requirements management needs. The inclusion of additional data is as permitted by the standard (T MU AM 06004 ST Requirements Schema, 6.2 Requirements management information).

The linkage of requirements management artefacts with the PDS, assists the project team by:

Providing a standard framework to define and communicate the physical project scope which is scalable, repeatable and auditable.

Utilising common coding, including standard work package structures and Uniclass 2015 classification, within the Business Requirements Specification (BRS)/System Requirements Specification (SRS) and other Systems Engineering deliverables, so that traceability and verification/validation of physical asset requirements is facilitated.

6.1.1. Structuring and standardisation of data

Each requirement documented in accordance with DMS-SD-563 Requirements Schema and Specification, shall be classified using Uniclass 2015 codes to the levels specified in Table 43, as a minimum and aligned with the PDS.

Table 21: Minimum Classification Requirements (Uniclass 2015)

CM Gate Co En SL EF Ss Pr

0 Co_xx As required As required As required As required As required

1 Co_xx En_xx SL_xx EF_xx Ss_xx As required

2 Co_xx_xx En_xx SL_xx_xx EF_xx Ss_xx_xx Pr_xx_xx







CM Gate Co En SL EF Ss Pr

3

Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx 4

5

6.1.2. Review of existing data

Any existing data is to be reviewed for accuracy and degree of useability and relevance to the project. Where existing data is to be re-used as part of a new deliverable, this data is to be classified in accordance with this DES, if not already compliant.

Existing and/or legacy data available to the project, shall be verified against the existing conditions for any discrepancies and assessment of accuracy. Depending on the outcomes, a decision will be made on the reliance of any existing Systems Engineering deliverables for further use on the project.

All major discrepancies with existing information shall be discussed and resolution agreed with the TfNSW DE Manager before being used on TfNSW projects.

6.1.3. Verification and validation

Prior to submission to Configuration Management Gates, TfNSW shall assess Systems Engineering data for compliance with the classification requirements and DMS-SD-563 Requirements Schema and specification, as agreed and documented in the Project DEXP.

Verification and validation for the project shall be in accordance with the requirements of T MU AM 06006 ST Systems Engineering Standard. Where possible, the Contractor is to utilise the BIM model and the structured ECM to demonstrate and link requirements to verification or validation evidence.

6.1.4. File submission format

Systems Engineering deliverables and any project specific processes or tools to be utilised in development and delivery of the submissions are to be documented in the Project DEXP.

DE projects are required to structure system engineering requirements data in accordance with DMS-SD-563 Requirements Schema and Specification.

Systems Engineering deliverables are to be provided in both native (eg ReqIF) and .xls format and uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3. Alternatively, where provided by the project, Systems Engineering deliverables may be authored directly in the TfNSW’s DOORS database.

Systems Engineering deliverables uploaded to the TfNSW ECM tool are to be named in accordance with the ECM tool requirements specified in Section 3.3, with any departures or qualifications to these requirements documented in the Project DEXP.







6.2. Survey deliverables

TfNSW relies on surveys to support the development and use of infrastructure and facilities. Surveys provide a range of critical information to inform planning and development of infrastructure projects, including detail information on existing conditions, verification of as-built assets, and documenting existing assets through measured surveys. It is critical for DE projects to receive survey deliverables in suitable formats to support the DE development and delivery process. Note that the information provided in this section apply to surveys supporting DE enabled projects, but can also be used for non-DE projects.

The types of surveys typically required across the asset lifecycle include:

• Existing condition surveys – surveys that capture existing conditions, with the aim to provide input into the evaluation of, design, and construction of projects;

• Construction surveys – surveys which set out the reference points and markers that guide the construction of new structures and buildings;

• As-Built surveys – surveys which document the location and condition of recently constructed elements of a project;

• Measured surveys – surveys to document existing assets, capturing both graphical and non-graphical information; and

• Control surveys – surveys to establish reference points (control networks) for other surveys connected to either the TfNSW survey control network (e.g. inside the heavy rail corridor) or with the NSW state survey control network.

Figure 6 shows the typical application of different types of surveys across the TfNSW asset lifecycle phases.

Figure 6: Types of surveys across the asset life cycle

Projects must work closely with the relevant TfNSW surveyors on the appropriate standards, requirements and guidelines to use for a survey project. More information on relevant points







of contact for TfNSW surveyors are provided in DMS-SD-142 Digital Engineering Survey Requirements Guide.

Table 22 provides an overview of the regulatory requirements for surveys relevant to NSW, and also lists other standards, requirements and general guidance to be considered when conducting surveys.

Table 22: Acts, Regulations, Standards and Guidance

Type Description

Acts and Regulations Relevant acts and regulations for New South Wales include:

NSW Surveying and Spatial Information Act 2002

NSW Surveying and Spatial Information Regulation 2017

NSW Surveyor General’s Directions

NSW Conveyancing Act and Regulations

NSW Registrar General’s Directions

Standards Key standards related to surveying for TfNSW, include:

HR Railway Surveying – T HR TR ST 13000

AS 7634:2017 Railway Infrastructure – Surveying

AS 5488-2019 Classification of Subsurface Utility Information (SUI)

The Australian Survey Control Network (SP1)

Australian Map and Spatial Data Horizontal Accuracy Standard (2009)

Specifications Specifications informing survey requirements, including:

HR Engineering Drawings and CAD Requirements - T MU MD 00006 ST

Sydney Metro Survey Technical Guide

QA Specification G71 – Construction Surveys

QA Specification G73 – Detail Survey

CADD Manual (32. CADD Manual Surveying)

GDA94 Technical Manual

GDA2020 Technical Manual

Deliverables must comply with the existing domain specific survey standards, which must be defined in the relevant Works or Services Brief on a project-by-project basis. Depending on the project’s specific surveying needs the deliverables may include delivery of:

• Point Cloud Data – a data set produced from a laser scan survey, which captures existing conditions to a high level of detail. Point clouds are a deliverable in their own right and may be supplemented with videos and photographs;

• 2D Drawings – survey results can be supplied as 2D CAD files, which from a DE perspective may limit the usability of the information supplied, but are useful for traditional mapping activities;

• 3D Drawings – survey results can be delivered as 3D CAD files. 3D PDFs may also be required to eliminate the need for specialist CAD or other viewing software;

• Digital Elevation Models (DEM) – includes Digital Terrain Models (DTM) and Digital Surface Models (DSM) where DTM represents the elevation of the bare ground of a







terrain, while DSM represents the elevation of a terrain including vegetation (e.g. trees) and man-made features (e.g. buildings);

• 3D Models – based on point cloud data converted to 3D Object Models, which may incorporate information from other sources such as existing 2D drawings, photos, videos, etc.;

• Imagery – images increase the quality of information captured during a survey and can be used to identify and extract features, and support 3D model development;

• Survey Control Points – represents the project control network used for the survey and must be integrated with existing rail control or state control network;

• Survey Validation – confirms the quality of the survey points, including that the survey has achieved the expected levels of accuracy;

• Metadata Statement – a metadata statement must be provided with the main survey deliverables to support interpretation and re-use of the survey deliverables; and

• Reports – standard survey deliverables must be accompanied by the relevant reports providing information on data collection, data processing, geo-referencing, and outcomes from the survey.

Table 23 outlines the typical deliverables required for each of the survey types, with deliverables marked as “Y” to be included, “O” as optional, and “-“ not required.

Table 23: Survey deliverables matrix

Type of Survey

Existing Conditions As-Built

Deliverables

To

po

gra

ph

ical

Cad

astr

al

En

gin

ee

rin

g -

Su

rfac

e

En

gin

ee

rin

g -

Su

bsu

rfa

ce

Co

nstr

ucti

on

(set-

ou

t)

Co

nstr

ucti

on

Veri

ficati

on

Ch

an

ge

Dete

cti

on

Measu

red

Co

ntr

ol

Point Cloud Y - Y - - Y Y Y -

2D Drawings Y Y Y Y Y Y Y Y Y

3D Drawings Y Y Y Y Y Y Y Y Y

Mesh Models Y - O - - O O O -

3D BIM Models - - Y Y - Y Y Y -

Imagery O O Y Y Y Y Y Y -

Survey Control Points

Y Y Y Y Y Y Y Y Y

Survey Validation

Y Y Y Y - Y Y Y Y

Metadata Statement

Y Y Y Y - - - - Y







The deliverables include control network information and survey metadata, to enable the re-use of the survey data and results by TfNSW and Contractors. More information on survey deliverables are provided in DMS-SD-142 Digital Engineering Survey Requirements Guide.


The classification of survey data is linked to the intended use as well as the primary domain (rail, roads, maritime, etc. assets) the project is conducted in. Appropriate classification of surveyed and 3D modelled data (scan to 3D models) is key to the ongoing effective use of the survey deliverables.

Laser scan survey data points (point cloud data) are typically initially classified based on the type of objects scanned, e.g. bare ground, building, vegetation, etc. This initial classification serves as basis for identification of the features captured in the point cloud data set. Depending on the intended use the point cloud data is then processed to identify strings, planes (surfaces) and objects.

Surveys that are to be used as input for data modelling (scan to 3D models) to modelled data require classification of both surface and underground features. For these survey deliverables the following classifications are to be used:

Surveys of surface features, in particular those that support the development of a 3D object based model (i.e. scan to 3D model), adopt the data classification (location, asset and discipline) and referencing as outlined in Section 4;

Surveys of utility services inside the metropolitan rail area shall comply with the Detailed Site Survey (DSS) requirements listed in Engineering Drawings and CAD Requirements - T MU MD 00006 ST, which defines the standard codes representing services and their installation type within the rail corridor;

Surveys of all other underground utility surveys utility services outside the metropolitan rail area shall comply with AS 5488:2019 - Classification of Subsurface Utility Information (SUI), as well as discipline classification as outlined in Section 4.4;

Surveys of roads and bridges must comply with the classification requirements outlined in QA Specification G73 – Detail Survey; and

Survey strings shall be in accordance with the relevant domain standards and / or requirements.

Classifying surveys correctly, in particular 3D objects and models extracted from surveys, enables the project team to use this information for planning, design, construction and operations & maintenance in a consistent manner.

Where there is conflict between different standards and requirements due to the multi-mode nature of the project the Rail standard requirements shall take precedence, unless otherwise agreed with TfNSW.


Existing survey data and information provided is to be reviewed for relevancy to the project. Where existing survey information is to be utilised as part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant. Projects shall







also confirm relevancy and applicability of existing survey data with the appropriate TfNSW surveyor.

6.2.3. Validation

All survey deliverables produced during the project will be data validated at key milestones of the project. Validation will be for compliance with the relevant domain survey standards, alignment with the PDS, and compliance with the Contractor’s Survey Management Plan and / or Project DEXP.


The type and format of survey deliverables must align with the existing file format requirements of the relevant transport or asset owner domain. Guidance on preferred file formats for survey deliverables are provided in DMS-SD-142 Digital Engineering Survey Requirements Guide.

Survey deliverables are to be submitted to TfNSW in agreed formats and identified within the Project DEXP and uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3. Large files are to be managed in accordance with DMS-SD-146 Large File Storage Guide, unless alternate storage methods are agreed with TfNSW.







6.3. CAD deliverables

As part of TfNSW’s DE Framework, the 2D CAD drawings will remain as one of the primary deliverables of exchanging design drawn information for projects to submit at each Configuration Management Gate. The CAD standards to be adopted shall be in accordance with the TfNSW ASA CAD Requirements and to be read in conjunction with the DMS-FT-532 DEXP Template and with acknowledgement on the concession approved by ASA (contact the DE Team for more information).

In order to maintain the integrity of the information, as a minimum, the following process shall be implemented when producing 2D CAD deliverables. For submission format details refer to Section 6.3.8.

• For the purposes of consistency, all 2D and 3D CAD data information shall be populated from the BIM models as required by TfNSW (refer to Section 6.4).

• There shall only be one drawing sheet per each drawing number as a drawing file output.

• Drawings shall have reference files (eg Xref) unbound (dwg or dgn) to form part of the submission in accordance with the TfNSW ASA CAD Requirements.

• Where linear assets are represented, the native 3D model remains the source for true geometry and alignment. A LandXML or native file format of the alignment is to be included as part of CAD submissions to assist in maintaining the integrity of the geometry.

• All drawings produced for TfNSW shall be identified using the unique file metadata tagging as described in Table 2 for upload to the ECM. For drawings required to be part of the VPR submission package, the file naming convention shall be in accordance with the TfNSW ASA CAD Requirements.

• If legacy CAD backgrounds are used to produce plan layouts, it is essential they are only used as a guide and not traced or embedded inside models.

Submission of CAD deliverables is required in accordance with Table 24, noting the DE Specific Requirements included in Table 25. Submission of CAD deliverables is required to be in accordance with the requirements of T MU MD 00006 ST Engineering Drawings and CAD Requirements and DMS-FT-532 DEXP Template.

Table 24: CAD submissions

CM Gate Document Status Description/Purpose

CMG0 Options Design Drawing Used to assist with optioneering through illustrating potential design concepts.

CMG1 Feasibility Design Drawing Initiation of communicating design intent for a project.

CMG2 Preliminary Design Drawing Used for capturing design intent, to assist in high level decision making and cost-estimation for tendering.

CMG3 Detailed Design Drawing Completed drawings for submission to TfNSW for certification

Approved for Construction Drawing

Certified by TfNSW for construction







CM Gate Document Status Description/Purpose

CMG4 Red-line mark-ups Used to capture any changes that have occurred during construction. Used as an interim reference prior to completion of Work-As-Executed (WAE) drawings.

CMG5 WAE/As-Built Drawing A record of the completed works

6.3.1. ASA Concession

Note: Projects must be specifically identified and included in the ASA Concession. Contact the DE Team to discuss listing of your project.

Where a project is delivered in compliance with this DES, CAD deliverables shall be submitted in accordance with T MU MD 00006 ST Engineering Drawings and CAD Requirements, with the exception of:

• smart tags

• drawing title block

• layer naming

• composite models

For these components of CAD drawings, a general concession to ASA requirements has been granted. The DE Specific Requirements are mandated in Table 25 and explained in the following sections.

Table 25: DE Specific Requirements

Ref Concession Application DE Requirement

1 Smart tags BIM model exported CAD deliverables

A completed Metadata spreadsheet will be submitted in accordance to T MU MD 00006 FI Metadata Spreadsheet for Engineering Drawings v2.0.

2 Drawing Title block

BIM model setup for CAD deliverables

Title block is to comply with the proposed typical DE title block. Refer to DMS-FT-549 DE CAD Title Block Standard Format.

3 Layer naming BIM model exported CAD deliverables

Layer naming is to comply with DE Discipline classification. Refer to DMS-FT-562 CAD Schema and Specification.

4 Composite models

BIM model exported CAD deliverables

Refer to Section 6.3.5 and Project DEXP.

6.3.2. Smart Tags and metadata spreadsheet

The concession granted by ASA means that Contractors do not have to comply with the requirements for the smart tag function.







The DE drawing title block (refer to DMS-FT-549) shall be attached to the drawing sheet from the BIM models, which includes metadata fields that support the data exchange for both the CDE and VPR.

T MU MD 00006 F1 Metadata Spreadsheet for Engineering Drawings version 2.0 shall be used by the Contractor for providing title block information. Completion of the metadata spreadsheet links all the field data entries exported from BIM models with VPR metadata. Refer to T MU MD 00006 FI Metadata Spreadsheet for Engineering Drawings for further details.

6.3.3. Drawing title block

The requirements for the DE drawing title block shall comply with the procedure explained in the following sections. The fields and format have been based on ASA CAD standards and modified to align to both Project DEXP and ECM requirements in Section 3.3. Any variations on the drawing title block such as Signal or Fleet drawings should be agreed with ASA, DE and project team before proceeding.

DMS-FT-549 DE CAD Title Block Standard Format provides an example of a typical TfNSW DE drawing sheet template, which consists of updates on the following five components:

• drawing details box

• sign-off box

• amendment box

• cover sheet details

• drawing frame details

Refer to Table 26, Table 28, Table 29, Table 30, Table 31 and DMS-FT-562 CAD Schema and Specification for additional DE requirements. All data entry fields in the five components are attributes included as part of ECM metadata and BIM Models. Furthermore, this should be read in conjunction with the latest ASA standard T MU MD 00006 FI Metadata Spreadsheet for Engineering Drawings for all added field requirements.

The attributes naming recommended by TfNSW shall be adopted or as otherwise agreed by the TfNSW DE Manager to suit the different authoring software platform. The adjustments and added tag/attributes to the Metadata fields enables the setup of DE projects in the 3D information modelling environment and achieves consistency and alignment with ASA requirements.

The following terms and definitions shall also be applied in this standard:

• design company as the design company responsible for carrying out the design and drawing content on the drawing

• engineering company as the AEO responsible for the design on the drawing

6.3.3.1. Drawing details box

The drawing details box provides details of the drawing subject matter and contains information about the drawing title and revision.







Figure 7 shows the different fields in the drawing details box.

Figure 7: Drawing details box on a typical TfNSW DE drawing sheet

Table 26 provides the details of the fields in the drawing details box. Refer to DMS-FT-549 DE CAD Title Block Standard Format and DMS-FT-562 CAD Schema and Specification for further details.

Table 26: Drawing details box – DE attributes description

Ref Field Name Tag/Attribute DE Requirements

1 Location tbLocality Indicate the Project Location. Refer to DMS-FT-562 CAD Schema and Specification for details.

2 Corridor and kilometrage tbLine Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirements for details.

3 Job description detail 1 tbDetail1 Include the Project Description. Refer to DMS-FT-562 CAD Schema and Specification for details.

4 Job description detail 2 tbDetail2 Include the Design work package name. Refer to DMS-FT-562 CAD Schema and Specification for details.

5 Drawing type tbDetail3 Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirements for details.

6 File number tbFileNo

7 Document status tbStatus Indicate the status of the drawing related to the project milestone. Refer to DMS-FT-562 CAD Schema and Specification for details.

8 Sheet number tbSheetNo Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirements for details.

9 Total number of sheets tbOfSheets








10 EDMS number tbDrawingNo Indicate the EDMS number (include both VPR discipline code and EDMS ID) submitted to TfNSW by the Contractors (in consultation with the Central Planroom (VPR)) and is unique for each drawing. Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirements for details.

11 EDMS amendment level (revision associated with EDMS number)

tbAMDNo Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirements for details.

12 Sheet size tbSheetSize

13 Design company document number

tbAEODrgNo Indicate the document number include the Project Contract code, Originator code, Sub-Location code, Engineering Discipline/Sub-discipline code, Document type and Drawing Serial number. Refer to DMS-FT-562 CAD Schema and Specification for details.

14 Design company revision level

tbAEORevNo Indicate the Design company revision level related to the Design company document number.

15 Design company version level

tbAEOVerNo Indicate the Design company version level.

The fields in the drawing details box are a combination of either text field or number attributes with a pre-defined list in ECM tool and DMS-FT-562 CAD Schema and Specification.

For fields with ‘text field’, information shall conform to the following principles:

• Drawing titles shall be correct, comprehensive and compliant with the formats indicated.

• Abbreviations shall be used in accordance to the ECM metadata or ones that are explained on the drawing using common construction abbreviations (for example, LV, HV and FE).

• The drawing title is made up of five lines (location, line and kilometrage, job description detail 1, job description detail 2 and drawing type) and shall contain specific information about the content of the drawing. After a drawing is submitted to the VPR, the drawing title shall not be modified in future amendments.

The Contractor revision field in the drawing details box shall be in alignment with the revision attribute in the Amendment box and numbering as per Section 3.3.4.

As a minimum, all DE projects shall conform to the following principles:

• All drawing deliverables including CMG submissions shall include both Contractor revision and version level information when issued to TfNSW.







• The revision number shown in the drawing title block must match the TfNSW ECM tool revision number when issued to TfNSW.

• The Contractor’s version number shown on a drawing is not required to match the ECM Version in the TfNSW ECM tool. The ECM Version is a different property for TfNSW and will default to zero for each new revision. Refer to Section 3.3.for ECM requirements. All drawings lodged and uploaded to VPR, both EDMS No. and AMD No. fields shall be filled in and information maintained throughout the required submissions.

Table 27: Examples of Revision & Version number at various project phases

Contractor VPR

REV VER Description AMD No.

A 0 ISSUED FOR SFR DESIGN REVIEW Blank ()

A 1 ISSUED FOR COORDINATION Blank ()

B 0 ISSUED FOR SDR DESIGN REVIEW Blank ()

00 0 AFC ISSUED BY CONTRACTOR (POST CMG3 APPROVAL OF CDR)

A

01 0 RE-ISSUED FOR CONSTRUCTION (MINOR DESIGN CHANGES DURING CONTRUCTION)

A

02 0 RE-ISSUED FOR CONSTRUCTION (POST CMG3 APPROVAL FOR MAJOR DESIGN CHANGES)

B

98 0 AS BUILT ISSUED BY CONTRACTOR (POST CMG5 APPROVAL)

C

99 0 AS BUILT ISSUED BY CONTRACTOR (POST DEFECTS LIABILITY PERIOD APPROVAL)

C

6.3.3.2. Sign-off box

The sign-off box shall contain the full names of the persons who have performed the design, design check, drawing, drawing check and approval of the document at the time of final preliminary design, approved for construction or subsequent design change. These fields shall not be updated for drawing amendments when there is no design change.

Note: Where the first name of a person is too long to fit within the space provided in the sign-off box, the first initial and last name of the person is acceptable.

Figure 8 shows the different fields in the sign-off box.







Figure 8: Sign-off box on a typical TfNSW DE drawing sheet

Table 28 provides the details of these fields. All data entry fields in the sign-off box should be populated as attributes and included as part of the ECM metadata. Refer to DMS-FT-562 CAD Schema and Specification for details.

Table 28: Sign-off box – DE attributes description


1 Drawn by (Name) tbDrwnName

Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details

2 Drawn date tbDrwnDate

3 Designed by (Name) tbDsnName

4 Designed date tbDsnDate

5 Drawing checked by (Name)

tbDrgChkName

6 Drawing checked date tbDrgChkDate

7 Design checked by (Name)

tbDsnChkName

8 Design checked date tbDsnChkDate

9 Approver (Name) tbApprName

10 Approved date tbApprDate

11 Engineering discipline description

tbAEODisciplineDesc Include the Engineering discipline description to which the drawing relates.

12 Design company name tbDesignCompName Include the name of the design company.

13 Engineering company

name

tbAEOSuppName Include the name of the AEO Engineering company.







6.3.3.3. Amendment box

The amendment box records the details of all amendments made to a drawing. The amendment details include the Design Company’s revision level, amendment description along with the initials of the designer, verifier and the approver.

The ‘REV’ column records the Design Company revision level of the drawing. Refer to Section 3.3.4 for details.

A brief but informative description of the changes made to the drawing shall be added to the 'DESCRIPTION' column. The initials of the designer, verifier and approver shall be placed in the amendment box for each drawing issue.

Where possible, at least three letters for the initials are required to minimise the possibility of misidentification of approvers with common first initial and last initial.

The oldest amendment entries shall be displayed at the bottom of the list. The amendment history items should be removed only when all available lines have been used. In this case, the oldest amendment information is removed, and the rest of the entries are moved down to create room for the new amendment at the top of the list.

Figure 9 shows the different fields in the amendment box.

Figure 9: Amendment box on a typical TfNSW DE drawing sheet

Table 29 provides the details of these fields. All data entry fields in the amendment box are included as attributes. Refer to DMS-FT-562 CAD Schema and Specification for details.

Table 29: Amendment box – DE attributes description


1 Co-ordinate system tbCoordSys Indicate the survey coordinates system including both Geocentric Datum of Australia (GDA) information and Map Grid of Australia (MGA).

2 Height datum tbHghtDatum Refer to T MU MD 00006 ST Engineering








3 Scale tbScale Drawings and CAD Requirements for further details

4 Design company

revision level

tbAEORevNo

Indicate the amendment level of current revision by the Design company.

5 Amendment description tbAMDDesc Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirements for further details

6 Amendment

designer initial and date

tbAMDDsgnSD Include the initials of the person who designed the amendment and the date of signature.

7 Amendment

verifier initial and date

tbAMDVerSD Include the initials of the person who verified the amendment and the date of signature.

8 Amendment approver initial

tbAMDApprSign Include the initials of the person who approved the amendment.

9 Amendment approver date

tbAMDApprDate Include the amendment date the drawing is approved and approver signature being signed. The information should align with the “EDMS amendment Date” in T MU MD 00006 FI Metadata Spreadsheet for Engineering Drawings

6.3.3.4. Cover sheet details

The cover sheet details provide the minimum project information relevant to each of the CAD deliverables being submitted at project milestones. The typical details of the fields should include and not limited to the following shown in Table 28. Refer to DMS-FT-562 CAD Schema and Specification for details.

Table 30: Cover sheet details – DE attributes description


1 Program Description TfNSW_Program_Description

Indicate the title of the project.

2 Project Location tbLocality Indicate the Project Location.

3 Project Description tbDetail1 Include the Project Description.

4 Design Work Package Code

TfNSW_WpackageDesignCode

Indicate the code of a design work package identified by the project. Refer to DMS-FT-562 CAD Schema and Specification for details.

5 Design Work Package Name

TfNSW_WpackageDesignName

Indicate the name of a design work package identified by the project. Refer to DMS-FT-562 CAD Schema and Specification for details.








6 Construction Work Package Code

TfNSW_WpackageConCode

Indicate the code of a construction work package identified by the project when applicable. Refer to DMS-FT-562 CAD Schema and Specification for details.

7 Construction Work Package Name

TfNSWW_WpackageConName

Indicate the name of a construction work package identified by the project when applicable. Refer to DMS-FT-562 CAD Schema and Specification for details.

6.3.3.5. Drawing frame details

The drawing frame details provide additional information relevant to the production of each drawing sheet from the model and to be submitted at project milestones. The details of each required attribute are shown in Table 29. Refer to DMS-FT-562 CAD Schema and Specification for details.

Table 31: Drawing frame details – DE attributes description


1 Security Classification tbSecurity As per 'NSW Government Information Classification, Labelling and Handling Guidelines'.

2 Model reference tbModelReference Reference to model document number(s) and revision(s), for cases where it is important to display which model(s) or revisions(s) are showing on the drawing.

6.3.4. CAD layer naming

All information (geometric or non-geometric) related to an object or asset type shall be named with a common language and structure as required by the project in the format below and as shown in Table 32.

CAD layer names = [Discipline] + [Classification] + [Presentation] + [Description]

Table 32: CAD Layer naming examples

Discipline Code

Uniclass 2015 Classification Code

Presentation Code

Layer Description

AR - Ss_25_10_20 - M _ CurtainWallSystem

CV - EF_20_50 - M _ BridgeAbutment

GN - Zz_20_10_90 - T _ Text1.0mm







To ensure the conversion process is consistent with the DE requirements, all CAD drawings shall use the DE defined technical discipline codes in the layer names. Refer to the Project CAD Schema and Specification (based on, DMS-FT-562) for the project’s full list of Technical Disciplines and Sub-Disciplines, if required.

It is important to note the Field Survey, Track design, Geotechnical, Signal and Fleet CAD drawings as interim approach do not need to comply with the full DE CAD layer naming process, however they are still required to comply with the DE defined discipline codes and ASA standards. Refer also to Section 6.2 under Survey deliverables for further details.

6.3.4.1. Discipline

For 2D CAD artefacts, mapping layers are required to meet with DE-defined technical disciplines as denoted in the Project CAD Schema and Specification (DMS-FT-562) and follow the principles established in Section 4.4 under Discipline classification and referencing.

6.3.4.2. Classification

All asset information shall be classified based on the nominated classification system as denoted in Section 4.3. The Classification field shall form part of the layer names in reference only to the MMI (refer to Section 6.9). The Uniclass 2015 table for CAD (Zz) is applicable to drawing-related items at all stages. This may vary from one CMG to another.

The assets must be defined to the level of the MMI by CMG3. To determine the MMI, refer to the rules for the inclusion of assets in the asset register as specified in T MU AM 02001 ST Asset Information and Register Requirements, section 7.1 Rules for creation of assets in the asset register.

Table 33: Classification Requirements for CAD layers

CM Gate En EF Ss Pr Zz

CMG0 As required As required As required As required As required

CMG1 En_xx EF_xx Ss_xx As required As required

CMG2 En_xx EF_xx Ss_xx_xx Pr_xx_xx As required

CMG3

En_xx_xx_xx EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx As required CMG4

CMG5

6.3.4.3. Presentation

The Presentation field shall be from the fixed list in referenced in Section 12.2 of BS1192:2007. This ensures that the information can still be re-used for a variety of presentation purposes without conflicting with re-use of information.

Table 34: Standard Codes for Presentation (PAS 1192: 2007)

Ref Code Description

1 D Dimensioning

2 H Hatching and Shading







Ref Code Description

3 M Model related elements

4 P Plot/paper related elements

5 T Text

6 X Existing

6.3.4.4. Description

The description should give a clear and concise explanation of the Uniclass 2015 code, in particular when it is necessary to distinguish between different types of configurations of items that fall under the same classification code. Further guidance on one or more options of conventions for appending the description will be defined in the DE Framework Supporting Documents.

For example, considering a detailed breakdown of a concrete wall types listed in logical groupings using DE conventions:

ST-Ss_25_11_16-M_ConcreteWallCore

ST-Ss_25_11_16-M_ConcreteWallExternal

ST-Ss_25_11_16-M_ConcreteWallInternal

6.3.5. Composite models

Where a project is required to deliver a ‘composite model’, as described in T MU MD 00006 ST Engineering Drawings and CAD Requirements, compliance with this DES enables a composite model to be in the format of a BIM model in the project deliverables. The composite or federated model shall be used instead of a 2D or 3D CAD model.

The BIM model should be submitted in the format specified in Section 6.4 showing the extent of design. The files should not be password protected or have an expiry data set and all native models shall be included as part of the submission in their original file format.


Existing data and information are to be reviewed for relevancy to the project. Where existing CAD information is to be utilised as part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant.

6.3.7. Validation

All 2D CAD deliverables produced during the project will be data validated at key milestones of the project, in alignment with the MIDP, MPDT, ECM Schema, CAD Schema and specification, and CAD layering naming table, as documented within the Project DEXP and ASA CAD standard T MU MD 00006 ST Engineering Drawings and CAD Requirements.








All 2D CAD deliverables must be submitted in the following formats with each of the native authoring software version identified and agreed in the Project DEXP.

1. Drawing image file

.pdf format

Vector-based

Each drawing submitted in its own file unless agreed with TfNSW DE manager and VPR on a special document package

2. Drawing CAD file

Either. dgn or .dwg formats

Unbound

Each drawing submitted in its own file unless agreed with TfNSW DE manager and VPR on a special document package

3. Zipped drawing with reference files

.zip format

Contains .dgn or .dwg drawing file plus all relevant reference files

All reference files to be linked via relative paths

One drawing per zip file

4. The drawing authoring software’s native file format, if this is something other than .dgn or .dwg

Submission formats to be agreed appropriate to the software used

For example: If drawings are produced in Revit, the .rvt file which forms part of a milestone submission must include the sheets.







6.4. BIM deliverables

The submission of BIM deliverables is required in order to pass each TfNSW Configuration Management Gate after CMG0. The submission requirement for each Configuration Management Gate is shown in Table 35.

Table 35: BIM Model Submissions

CMG Model Type Description/Purpose Submission Requirement

CMG0 N/A N/A N/A

CMG1 Options / Feasibility Design Model

Initiation of communicating design intent for a project in the form of BIM models.

ECM tool

CMG2 Preliminary Design Model

This model is used for capturing Design Intent and assist in high level decision making.

ECM tool

CMG3 Detailed Design Model

This model is used to assist with both decision-making processes and design coordination.

ECM tool

Approved for Construction Model

These BIM models are used as a baseline. All changes during construction are incorporated as required to be recorded against the original AFC design. The approved model is a contract document for submission to TfNSW and is required for construction to commence.

ECM tool

VPR mandated

CMG4 Construction Model

Minor changes are captured in redline mark-ups as per CAD requirements. Major changes require model updates.

ECM tool

Major changes: VPR mandated

CMG5 As-Built Model The As-Built Model is a model (or models) that capture exact conditions at the completion of construction.

This model may have complimenting 3D laser scan data to verify the installation of already constructed work, and record the “as-installed” position of work as executed.

ECM tool

VPR mandated

O&M Model The O&M Model is a model that represents a record of what was constructed, installed, and tested prior to handover. The O&M Model may be used for operations and maintenance.

The O&M Model will contain accurate attribute data for maintainable equipment and systems used asset management, as specified in section 7.1 of the Creation of assets in the asset register, T MU AM 02001 ST Asset Information and Register Requirements.

The O&M Model is updated based on information provided by the relevant Contractor (eg digital mark-ups, photography, or laser scans).

ECM tool

VPR







6.4.1. BIM requirements

The Contractor is responsible for managing the overall cross discipline BIM collaboration process. To achieve this, each design discipline must model to a level of definition sufficient to enable an appropriate level of coordination to take place. The coordination process shall be developed along the following principles:

a. Coordinates and setting out details shall be coordinated across the project, using a master project control set out file.

b. Information from other contributors shall be referenced directly in BIM during design for clash avoidance.

c. BIM objects shall be classified as per the phased requirements specified in Table 33. BIM files in native format shall be ‘Shared’ on a frequent basis for coordination and information.

d. BIM models shall be diligently managed and maintained, removing any internal discipline working views before exchanged in the file formats identified in Section 6.4.7.

e. Regular model coordination sessions are to be implemented appropriate to the project scope, as specified in the Project DEXP.

The federated GIS and/or BIM environment shall be used as the focus for resolution and progress of design using a virtual design/construction review process.

In addition to the above principles, the Contractor is required to adhere to the following requirements for the submission of BIM models and related information:

• All Contractors shall submit BIM models into the ECM tool for review and comment, according to Table 35 and as per project milestones documented in the Project DEXP.

• All Contractors shall submit BIM models in accordance with the Level of Definition requirements outlined in Table 36 unless specific project requirements have been agreed in the Project DEXP.

• 2D drawing deliverables shall be derived from the BIM model, and created in accordance with the requirements outlined in Section 6.3.

• Any other supporting information which is relevant to the BIM model shall be included in the submission to the ECM.

6.4.1.1. Levels of Definition

Refer to Table 36 for the baseline Levels of Definition for each project phase. Baseline Level of Definition requirements are given for each technical discipline and phase in Table 37.

TfNSW and the Contractor shall agree and specify any project-specific requirements for Level of Definition for all technical disciplines and asset types for each project phase in the Project Model Production Delivery Table (DMS-FT-534 Model Production Delivery Table (MPDT) Template).




DMS-ST-207 DE STANDARD - PART 2_V3.0 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207


Table 36: TfNSW Minimum Levels of model definition

Design Reviews

System Feasibility Review (SFR)

System Concept Review (SCR), Preliminary Design Review (PDR)

CDR, AFC, As-Built

CM Gate 1 2 3, 4 and 5 If required If required

LoD (PAS 1192.2)

2 3 4

5 6

LOD (BIM Forum)

LOD 100 LOD 200 LOD 300

LOD 400 LOD 500

Geometric Representation (Building Specific) (PAS 1192.2)

Geometric Representation (Infrastructure Specific) (PAS 1192_2)

Description (PAS 1192_2)

Models which communicate the initial response to the brief, aesthetic intent and outline performance requirements. The model can be used for early design development, analysis and co-ordination. Model content is not fixed and may be subject to further design development.

A dimensionally correct and co-ordinated model which communicates the response to the brief, aesthetic intent and some performance information that can be used for analysis, and early Contractor engagement.

A dimensionally correct and coordinated model that can be used to verify compliance with regulatory requirements. The model can be used as the start point for the incorporation of specialist Contractor design models and can include co-ordination, sequencing estimating purposes.

An accurate model of the asset before and during construction incorporating co-ordinated specialist subcontract design models and associated model attributes. The model can be used for sequencing of installation and capture of as installed information.

An accurate record of the asset as constructed at handover, including all information required for operation and maintenance.







Table 37: TfNSW Minimum Levels of Definition by Technical Discipline

Project Phase

Feasib

ility

Desig

n

Pre

limin

ary

Desig

n

Deta

iled

Desig

n

Appro

ve

d F

or

Constr

uction

Com

mis

sio

nin

g

and T

esting

As-B

uilt

O&

M

Configuration Gates 1 2 3 4 5

Technical Discipline

Code

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

LO

D

Lo

D

Architectural AR 100 2 200 3 300 4 300 4 - - 300 4 300 4

Civil CV 100 2 200 3 300 4 300 4 - - 300 4 300 4

Electrical EL 100 2 200 3 300 4 300 4 - - 300 4 300 4

Signalling & Control

SG 100 2 200 3 300 4 300 4 - - 300 4 300 4

Technology TE 100 2 200 3 300 4 300 4 - - 300 4 300 4

Fire FE 100 2 200 3 300 4 300 4 - - 300 4 300 4

General GN 100 2 200 3 300 4 300 4 - - 300 4 300 4

Structural ST 100 2 200 3 300 4 300 4 - - 300 4 300 4

Fleet Systems & Equipment

FL 100 2 200 3 300 4 300 4 - - 300 4 300 4

Communication CO 100 2 200 3 300 4 300 4 - - 300 4 300 4

Hydraulic HY 100 2 200 3 300 4 300 4 - - 300 4 300 4

Mechanical ME 100 2 200 3 300 4 300 4 - - 300 4 300 4

Utilities UT 100 2 200 3 300 4 300 4 - - 300 4 300 4

6.4.2. Model classification requirements

The level of granularity required for classification of model objects develops progressively over the life of the project, as presented in Table 38.


CM

Gate Co En SL EF Ss Pr

0 Co_xx As required As required As

required

As required As required



3


5







6.4.3. Model properties requirements

To comply with TfNSW data requirements, the minimum properties in Table 39 must be populated in applicable model objects at the phase defined in DMS-FT-516 BIM Schema and Specification.

Table 39: Model Properties Requirements

Ref Field Name Description Requirement TfNSW IFC Property (refer to Appendix B)

1 Project Description

Provided by TfNSW

Mandatory tbDetail1

2 Project Contract Code Mandatory tbProjectContractCode

3 AEO company code Mandatory tbAEOSuppCode

4 AEO company name Defined by Contractor Mandatory tbAEOSuppName

5 Design company code Provided by TfNSW Optional tbDesignCompCode

6 Design company name Defined by Contractor Optional tbDesignCompName

7 Co-ordinate system Provided by TfNSW Mandatory tbCoordSys

8 GUID Global Unique Identifier Auto-generated by software

Mandatory ***IfcRoot GlobalId Attribute

9 TfNSW Location ID

Provided by TfNSW

Optional TfNSW_Location_ID

10 TfNSW Parent Location ID

Optional TfNSW_Parent_Location_ID

11 Project Location Code Provided by TfNSW

Mandatory TfNSW_Project_LocationCode

12 Project Parent Location Code

Defined by Contractor

Conditional TfNSW_Project_Parent_LocationCode

13 Project Location Description

Mandatory TfNSW_Project_LocationDescription

14 Uniclass 2015 Location Code

Pre-defined Uniclass 2015 Classification (Complex, Entity, Space/Location code) populated by Contractor

Mandatory TfNSW_Uniclass_LocationCode

15 TfNSW Asset ID

Provided by TfNSW

Optional TfNSW_Asset_ID

16 TfNSW Parent Asset ID

Optional TfNSW_Parent_Asset_ID

17 Project Asset ID


Optional TfNSW_Project_Asset_ID

18 Project Parent Asset ID

Optional TfNSW_Project_Parent_Asset_ID

19 Project Asset Code


Mandatory TfNSW_Project_AssetCode

20 Project Parent Asset Code

Conditional TfNSW_Project_Parent_AssetCode







Ref Field Name Description Requirement TfNSW IFC Property (refer to Appendix B)

21 Asset Description Defined by Contractor

Mandatory TfNSW_Asset_Description

22 Uniclass 2015 Asset Code

Pre-defined Uniclass 2015 Classification (Element, System or Product code) populated by Contractor

Mandatory Uniclass_Classification_Code

23 Discipline Code Provided by TfNSW

Mandatory tbAEODisciplineCode

24 Sub-Discipline Code Conditional tbAEOSubDiscCode

25 Design Work Package Code

Provided by TfNSW

Optional TfNSW_WpackageDesignCode

26 Construction Work Package Code

Mandatory TfNSW_WpackageConCode

27 Commissioning Work Package Code

Optional TfNSW_WpackageCommCode

28 Asset Status Provided by TfNSW Mandatory TfNSW_Asset_Status

29 Asset Owner

Provided by TfNSW

Mandatory TfNSW_Asset_Owner

30 Asset Operator Optional TfNSW_Asset_Operator

31 Asset Maintainer Optional TfNSW_Asset_Maintainer

32 Start km


Conditional TfNSW_Start_Km

33 End km Conditional TfNSW_End_Km

34 GPS Coordinates Conditional TfNSW_GPS_Coord

Refer to DMS-FT-516 BIM Schema and Specification for the full specification.


All or any existing data is to be reviewed for accuracy and degree of useability and relevance to the project. Where existing data is to be re-used as part of a new deliverable, this data is to be classified in accordance with this DES, if not already compliant.

Existing site information and/or legacy data available to the project shall be verified against the existing conditions for any discrepancies and assessment of accuracy. Depending on the outcomes, a decision will be made on the reliance of any existing BIM models for further use on the project.

All major discrepancies with existing site information shall be discussed and resolution agreed with the DE Manager before being used on TfNSW projects.

6.4.5. Model collaboration procedures, federation and sharing

A federated model is a compilation of individual models combined into one single application for coordination and interrogation. Refer to the terms and definitions outlined in DMS-ST-202







TfNSW DE Standard, Part 1 – Concepts and principles for details. BS1192 refers to the federated model as “Combined”.

It is the responsibility of the Contractor to compile all individual discipline models to create the federated model and ensure consistent processes for model sharing and coordination are in place. Contractors must address the following requirements:

• All BIM model authoring software and procedures shall be agreed, implemented and documented within the Project DEXP.

• All BIM model reviewing software and procedures shall be agreed, implemented and documented in the Project DEXP.

• A model coordination strategy must be implemented by the Contractor and documented within the Project DEXP.

• A strategy for ongoing model coordination meetings and meeting frequencies must be implemented by the Contractor and outlined in the Project DEXP.

• Information exchange procedures are to be implemented by the Contractor and documented in the Project DEXP.

• Clash detection procedures are to be implemented by the Contractor and documented in the Project DEXP.

• A procedure for recording and communicating changes to individual models must be implemented by the Contractor and documented in the Project DEXP.

6.4.6. Model reviewing and validation

All BIM data produced shall be validated at key milestones of the project. Data within models shall be audited against the information contained within the Project Model Production Delivery Table (MPDT). Any specific model review workflows and processes shall be documented in the Project DEXP, in particular the following:

• Contractor’s internal model review process

• Contractor’s internal data validation process

A Model Validation Report shall be included with model submissions and provided as proof of evident with the Model Validation Certificate. This report shall confirm that the Contractor has completed an appropriate quality assurance review of the model prior to submission, including confirmation that:

• The Level of Definition for model elements/disciplines is as required by the agreed Project MPDT

• Federation of discipline models has been appropriately achieved

• Clash detection has been completed appropriate to the project phase

• The models are coordinated to a degree appropriate to the project phase

• The model is appropriate for use during the next phase of the project and/or asset lifecycle.







• Items for further definition in the next project phase are identified

• The comments in the project comments register have been appropriately closed out

A strategy for quality assurance is to be documented in the Project DEXP and adopted by all collaborating parties.

6.4.6.1. Timing of model reviews and workshops

The timing of model reviews shall be documented in the Project DEXP, and taking into consideration on:

• Critical project milestones

• Contractor internal processes

• Key interfaces or other points raised by TfNSW

Model review workshops are to be appropriately scheduled to provide adequate collaboration and review between modelling parties.

6.4.6.2. Addressing design comments

All Contractors shall produce design review comments which are placed into a comment register in accordance with TfNSW requirements. The file format of the register, its location, and structuring of design comments will be at the discretion of TfNSW and agreed with DE Manager before being used on TfNSW projects.


This section defines mandatory file format requirements. Refer to the Project DEXP for specific BIM model file formats required by TfNSW. In addition, refer to T MU MD 00006 ST Engineering Drawings and CAD Requirements.

• All BIM models must be submitted to TfNSW in their original native file format.

• All BIM models must be submitted as a Navisworks Cache (NWC) (individually), Navisworks Document (NWD) (federated), or other collaboration file format agreed in the Project DEXP.

• All BIM models must be submitted in the Industry Foundation Class (IFC) format 2x3 or higher, as individual files to form part of the federated file. These submissions will be required at key project milestones. Newer versions of IFC format may be submitted if approved by the TfNSW DE Manager.

• String-based models must be submitted as a LandXML format 1.2 or higher to retain true geometry

• Maximum file-size limit shall not exceed 500MB, though the software, file format and contents should be taken into account and others (for example point clouds) may be larger. Large files should be discussed with the TfNSW DE Manager and monitored for performance. If file size is deemed to be diminishing project performance in any way, the issue must be addressed by subdividing the models or purging unnecessary contents.







BIM model files, and any derived information including 2D drawings, produced for TfNSW shall be identified using the file naming convention described in Section 3.3 for upload to the ECM tool.







6.5. Visualisation

TfNSW have standardised visualisation types to drive consistency of the outputs that are delivered and ensure that all information produced or used in the creation of the visualisation is also handed over for reuse.

Requirements for visualisation deliverables are determined based on the projects scope, DE strategy and opportunities for reuse. The Contract and Project DEXP is to define any project specific requirements for visualisation deliverables. Unless specified otherwise in the Contract or Project DEXP, visualisation submissions must meet the deliverable requirements listed in Table 40.

Table 40: Visualisation deliverables

Ref Required deliverable Description

1 Visualisation deliverable The Contractor is to provide the visualisation deliverable in a digital file format appropriate to its intended usage and audience, as specified in the Project DEXP.

2 Visualisation software native file

The native file formats for the specialist visualisation software package or packages that have been used in the process of creating the visualisations are to be provided to TfNSW as part of the submitted deliverable.

3 Visualisation software open source file

An open source file produced from the visualisation software that will include the information contained within the native file, including; 3D geometry; colour, material and texture maps, camera locations and settings, lighting and relative positioning. The FBX file format, although classed as a proprietary format is seen as an industry exchange solution and is to be provided to TfNSW as part of the submitted deliverable.

4 Post-production software file Should any post-production work be undertaken as a part of the visualisation process the native files for these software applications are to be provided to TfNSW as part of the submitted deliverable.

5 Supporting content files Files that have been created as an output from the BIM authoring or visualisation software and then further enhanced or compressed in post-production software are to be provided to TfNSW as part of the submitted deliverable. An example of this type of content are image files rendered out of a visualisation package that would then be ‘stitched’ together to form an output animation.

6 Material map Where material texture files are used in the visualisation process these are to be provided to TfNSW as part of the submitted deliverable. This is appropriate for where the materials are not embedded in the native authoring or visualisation software.

7 Additional artefacts Specialist plugins may be used to add additional content into the visualisation for realism purposes such at people, vegetation and vehicles. Where licencing allows this content should must also be provided to TfNSW as part of the submitted deliverable.








The classification of visualisation data is linked to the intended use as well as the primary domain (rail, roads, maritime, etc. assets) the project is conducted in. Appropriate classification of visualisation data is key to the ongoing effective use of the visualisation deliverables.

Where BIM models are utilised as the foundation of the visualisation, existing classification data within the model, as described in section 6.4, is to be maintained.

Additional classification requirements are to be specified in the Project DEXP, dependent on the intended usage and reuse requirements.


Existing visualisation data and information provided is to be reviewed for relevancy to the project. Where existing visualisation information is to be utilised as part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant. Projects shall also confirm relevancy and applicability of existing visualisation data with the TfNSW project team.

6.5.3. Validation

All visualisation deliverables produced during the project will be data validated at key milestones of the project. Validation will be for compliance with the relevant domain visualisation standards, alignment with the PDS, and compliance with the Contractor’s Project DEXP.


Visualisation deliverables are to be submitted to TfNSW in agreed formats and uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3. Large files are to be managed in accordance with DMS-SD-146 Large File Storage Guide, unless alternate storage methods are agreed with TfNSW.







6.6. GIS deliverables

The GIS Guide for DE is currently in development. Pending the release of this Guideline, all parties are required to conform to existing TfNSW Standards and requirements.


All information, where possible, should represent geographically referenced locations, or x,y,z co-ordinates representative of real world positioning.

All GIS models having a relationship with the mapping grid or relative levels must be drawn maintaining the relationship between the CAD coordinate system, the map coordinate system and Australian Height Datum (AHD).

Coordinates may be associated with a project wide shape file, the midpoint of a zone or the midpoint of an individual object in the BIM model.







6.7. Time deliverables

Requirements for time deliverables in this DES are currently limited to scheduling and 4D models. Additional requirements for time-related deliverables, such as detailed construction sequencing, are to be documented further in the Project brief or DEXP, as appropriate.

Scheduling (also known as programming) provides projects with the ability to plan, evaluate, communicate and better understand complex delivery methodologies prior to actual execution using a Gantt chart. Traditionally, the key challenges have been to ensure that;

(i) the full scope of the project is reflected in the schedule and,

(ii) that the construction methodology logic and durations are accurate and can be practically delivered.

This DES requires that Contractor’s group activities in their schedules using Work Package Codes. This approach improves traceability, ensures that time data can be easily associated with the BIM model, and that the construction methodology can be easily visualised in time-sequenced 3D models (also referred to as 4D). Project teams can effectively prototype the delivery of assets in a virtual environment first and, provide rapid feedback on design options as well as constructability. This is beneficial for planning work in a safe and systematic way that maximises efficiency on site.

DE enabled schedules also enhance the ability to quantify the impact of variations by ensuring alignment between the original baseline and current baseline schedules, as well as cost estimates and progress claims. This enables variations to be compared visually, dramatically reducing creation and assessment times. It also automates compliance with TfNSW’s Earned Value requirements and monthly project performance reporting.

Note: the DE scheduling requirements detailed in this DES must be read in conjunction with any project specific scheduling requirements within IP Scheduling Standard (DMS-ST-123) or specified in the Contract.

6.7.1. Project schedule deliverable requirements

For DE projects that require scheduling deliverables, all activities in the Contractor’s

Primavera P6 schedule must be coded with the relevant “Work Package Code” provided by

TfNSW (refer section 4.5 for more information on Work Packages). The list of Work

Packages will be prepopulated in the project activity codes titled “Work Package Code” within

the TfNSW Primavera P6 environment. All activity codes are provided to the Contractor for

reference via the Project DEXP Template (based on DMS-FT-520 Scheduling Schema).

For this DES release, only Work Package Codes relating to Design, Supply, Construction,

and Commissioning activities must be assigned to all relevant P6 activities. This is to assist

with automated association of schedule activities and BIM objects.

6.7.2. 4D model deliverable requirements

For DE projects that require 4D model deliverables, the Contractor must provide a time

sequenced model (4D) for each submission milestone or as requested by TfNSW, with the

Primavera P6 schedule activities and dates integrated in a federated model in a software

format agreed with the TfNSW. The 4D model can be provided as either:







1. 4D GIS – compatible with TfNSW systems environment or viewable as a video.

2. 4D BIM – compatible with TfNSW CDE and provided in agreed format, such as

Autodesk Navisworks or Bentley Navigator.

The BIM objects within the 4D Model deliverables must comply with the BIM Deliverable

requirements in Section 6.4. The schedule or time related data must comply with the

requirements of this Section 6.7.

Refer to the project Brief for details on whether 4D GIS or 4D BIM is required and the

frequency of submissions. A more comprehensive Scheduling Guide for DE is currently in

development.

6.7.3. Existing data review

Existing time data and information are to be reviewed for relevancy to the project. Where existing time data, e.g. a Work Package hierarchy, is to be utilised as part of the project, this data is to be classified in accordance with this DES, if not already compliant.

6.7.4. Validation

All scheduling deliverables produced and updated during the project will be data validated

monthly and/or at key milestones of the project from within the TfNSW Primavera P6

environment. Validation will be for compliance with the agreed Project Scheduling Schema

(based on DMS-FT-520), the agreed Contractor’s Project DEXP and other Contract

requirements.

All 4D Model deliverables will be validated upon submission for compliance with the

scheduling classification, BIM classification and other Contract requirements.

6.7.5. Time deliverable submissions

Scheduling deliverables and updates are to be provided to TfNSW in accordance with DMS-ST-123 IP Scheduling Standard. Any schedules required to be submitted as a pdf file for monthly reporting, etc. or 4D Model deliverables are to be uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3.







6.8. Cost deliverables

Cost deliverables are broken into three main categories; (i) cost estimates (including

contingency), (ii) contract payment schedules (i.e.; progress claims) and, (iii) variation

estimates (post-contract award). This DES only details the contract payment schedule

information requirements, with cost estimating and contingency coding structures to be

included in the next release.

Structuring cost estimate, progress claim and variation data consistently allow the project to

accurately track budget, forecast, and actual spend over the course of the project. It also

allows the project to compare different design and construction scenarios/options and

variation requests efficiently to inform value-based decisions.

By aligning the cost data structures with BIM and time data, cost estimates and progress

claims can be automatically associated with the BIM model and schedule/program so that

the impact of progress can be easily visualised. The cost information can also enhance the

TfNSW Earned Value creation and simplify the monthly project performance reporting.

Separately, by standardising the way cost is structured across the business, TfNSW can

automate program and portfolio level cost reporting and finance. It also enables a consistent

cost benchmarking dataset to be built up for each location and asset type that can then be

reliably compared against future project estimates developed using the same data structure.

For all projects requiring Cost deliverables, the requirements in this DES must be read in

conjunction with any project specific cost requirements or amendments as specified in the

project Brief. This includes 4TP-ST-173 Cost Estimating for Infrastructure and Place Projects

and T MU AM 01001 ST Life Cycle Costing.


6.8.1.1. Project cost estimates

The Cost Estimating requirements for DE are currently in development. Pending this release, all parties are required to conform to existing TfNSW Standards and requirements related to project costs. These include 4TP-ST-173 Cost Estimating for Infrastructure and Place Projects and T MU AM 01001 ST Life Cycle Costing.

It is recommended that project costs are estimated and captured in a Cost Breakdown Structure (CBS) that aligns Work Package Codes used for scheduling deliverables, and any other suitable coding systems within the PDS. This integration of data coding will enable and allow effective reuse, sharing and analysis of cost data.

6.8.1.2. Contract payment schedule

TfNSW will align the CBS within the tender/contract payment schedule to the Work Package Codes in the PDS. This will enable cost information to be associated with groups of BIM objects, schedule activities and agreed project milestones. Alignment of schedule and costs will also enable automatic generation of earned value, if required.

The contract payment schedule must be controlled to align with any changes to the Work Package Codes agreed with TfNSW, as explained in Section 4.5, Work Packaging. This is







required so that the total cost of a Work Package at the end of the project can be easily quantified by TfNSW for the purposes of asset capitalisation and benchmarking.

6.8.1.3. Project progress claims

All progress claims must be in the same format as the Contract Payment Schedule. It is recommended that the Contractor’s internal CBS used for tracking costs is aligned with and rolls up to the contract payment schedule structure provided by TfNSW to simplify reporting.

6.8.1.4. Variation costs

All variation must be estimated in the same CBS and Work Package Codes as the Contract Payment Schedule. This is required so that the total cost of a Work Package at the end of the project can be easily quantified by TfNSW for the purposes of asset capitalisation and benchmarking.

6.8.2. 5D Model deliverables

For projects where 5D Cost deliverables are required refer to the specific cost requirements or amendments as outlined in the project Contract. The 5D Cost requirements for DE are currently under development. Pending this release, all parties are required to conform to all cost and BIM requirements within this DES, along with all existing TfNSW Standards and requirements related to project costs.


Existing cost data and information are to be reviewed for relevancy to the project. Where existing cost and estimating data are to be utilised as part of the project, this data is to be classified in accordance with this DES, if not already compliant.

6.8.4. Validation

Cost Estimates, Contract Payment Schedule code changes, progress claims, and variation estimates will be validated for compliance with the DE Work Package Codes, the Contractor’s Project DEXP, and all other TfNSW cost estimating requirements. These include 4TP-ST-173 Cost Estimating for Infrastructure and Place Projects and T MU AM 01001 ST Life Cycle Costing.

All 5D Model deliverables will be validated upon submission for compliance with the cost classification, BIM classification and other Contract requirements.

6.8.5. Cost deliverable submissions

Cost estimate and 5D model deliverables are to be uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3. Progress Claim and Variation related submissions must be submitted in accordance with the requirements in the Contract.







6.9. Asset data deliverables

Asset data deliverables are focused around the structured asset data that is created or captured during a project, as required by T MU AM 02006 TI Asset Register and Data Dictionary, and contributes to the Handover Asset Register. This information may be captured within the BIM model or in the Asset Register itself (refer to Figure 10).

Asset data deliverables require the inclusion of information to support asset management and operation. This data typically includes information on the manufacturer of a component, its installation date, required maintenance and details of how the item should be configured, operated for optimal performance, and whole of life and decommissioning data. Capturing this information during design also enables decisions during the design phase that impact whole of life management costs.

To enable the asset information to be linked requires the use of a unique project asset ID that is common in the Asset Register and the BIM model, or other data sources.

Handover Asset Register

Asset register and other asset information

BIM model

Current scope of DE

Is it an MMI?

Yes

Figure 10: Asset Data Development

TfNSW requires that the mandatory Asset Register attributes, outlined in Table 39, are generated from the 3D Model.

6.9.1. Asset register requirements

Asset data, documented in accordance with DMS-FT-537 Asset Register Template, is to be provided to TfNSW as part of a staged process, aligned with the Configuration Management Gates. The minimum information to be provided at CMG 2, 3 and 5 is specified in Table 42.

Project specific requirements for asset data and information, additional to the Asset Register, are specified in the Contract and as per T MU AM 02001 ST Asset Information and Register Requirements.

Projects working under the DE Framework are required to comply with the classification and referencing requirements specified in this Standard (refer to Section 4).







Projects complying with this Standard are not required to comply with the classification requirements referred to in the ASA Standard T MU AM 02001 ST Asset Information and Register Requirements (Section 9 Asset classification system framework). TfNSW will be responsible for ensuring compliance with ASA asset and location classification, where required.

At the point of transition of the physical assets into a maintenance phase or an operations and maintenance phase (CMG5), an extract from the Asset Register is taken to form the Handover Asset Register. This Handover Asset Register must represent those assets as constructed and include a record for all assets to the MMI and as specified by T MU AM 02001 ST Asset Information and Register Requirements, Section 7.1 Creation of assets in the asset register.

The minimum requirements for the submission of asset information in the form of an asset register are provided in Table 41.

Table 41: Asset register submissions

CM Gates

Register Name Description/Purpose Minimum Requirement

CMG0 N/A - -

CMG1 N/A - -

CMG2 Preliminary Design Asset Register

Complexes, entities, spaces, elements and systems identified.

Information requirements for specified asset types to be included in the Asset Handover Plan, with consultation from the nominated O&M party.

Register completed as per Table 42.

Additional information requirements as per T MU AM 02001 ST Asset Information and Register Requirements

CMG3 Detailed Design Asset Register

Complexes, entities, spaces, elements, systems and key products identified.

The minimal assets to be included in the register are to be determined as per T MU AM 02001 ST Asset Information and Register Requirements.



AFC Asset Register

Complexes, entities, spaces, elements, systems and key products identified.

The minimal assets to be included in the register are to be determined as per T MU AM 02001 ST Asset Information and Register Requirements.



CMG4 N/A - Red-line drawings and Construction Evidence only.








CM Gates

Register Name Description/Purpose Minimum Requirement

CMG5 As-built/ Handover Asset Register

Complexes, entities, spaces, elements, systems and products identified.



Table 42 provides the minimum information to be provided as part of the Asset Register at the relevant configuration management gates.

Guide to Table 42:

• ‘P’ indicates where the Contractor is to provide proposed or draft information, which is to be later confirmed (‘C’)

• ‘C’ indicates that the information has been confirmed, usually as part of the Detailed Design process or upon construction/installation.

• ‘*’ indicates that the field is applicable to specific asset classes only (eg Start Km is required for corridor based assets, and interchange and facility precinct assets located along a corridor), refer to T MU AM 02006 TI Asset Register and Data Dictionary for further information.

Table 42: Data required for inclusion in the Asset Register

Ref Field Name Requirement

When completed (P = Proposed, C = Confirmed) *as required

CMG2 CMG3 CMG5

1 Asset Register tab

1.1 TfNSW Asset ID Conditional If provided by TfNSW

1.2 TfNSW Parent Asset ID Conditional If provided by TfNSW

1.3 Project Asset ID Optional P C C

1.4 Project Parent Asset ID Optional P* P* C*

1.5 Project Asset Code Mandatory P C C

1.6 Project Parent Asset Code Mandatory P* P* C*

1.7 Asset Description Mandatory P C C

1.8 Uniclass 2015 Asset Code Mandatory P* C* C

1.9 Project Location Code Mandatory - C C

1.10 Discipline Code Mandatory P* P* C

1.11 Sub-discipline Code Conditional P P C*

1.12 Work Package (Design) Optional C C C

1.13 Work Package (Construction) Optional P C C

1.14 Work Package (Commissioning) Optional P P C







Ref Field Name Requirement

When completed (P = Proposed, C = Confirmed) *as required

CMG2 CMG3 CMG5

1.15 Start Km Conditional - P* C*

1.16 End Km Conditional - P* C*

1.17 GPS (Lat, Long) Mandatory - - C*

1.18 Asset Status Mandatory C C C

1.19 Asset Owner Mandatory C C C

1.20 Asset Operator Mandatory P P C

1.21 Asset Maintainer Mandatory P P C

1.22 Maintenance Managed Item Mandatory - P C

1.23 Modelled Asset Mandatory P C C

1.24 Source Model Conditional P C C

1.25 Model Object Global Unique ID Conditional - C C

… Other attributes required by T MU AM 02006 TI Asset Register and Data Dictionary

- - C*

2 Project Location tab

2.1 TfNSW Location ID Conditional If provided by TfNSW

2.2 TfNSW Parent Location ID Conditional If provided by TfNSW

2.3 Project Location Code Mandatory P C C

2.4 Project Parent Location Code Mandatory P* P* C*

2.5 Project Location Description Mandatory P P C

2.6 Uniclass 2015 Location Code Mandatory P C C

2.7 Corridor Conditional P C C

2.8 State Conditional C C C

2.9 Suburb Conditional P C C

2.10 ASA Location Conditional P C C

2.11 GPS Coordinates Mandatory - P C

2.12 Start km Conditional - P C

2.13 End km Conditional - P C

Key requirements for the Handover Asset Register are:

• There must be one Project Asset ID for each ‘Asset Owner’.

• The MMI as per Section 7.1 in T MU AM 02001 ST Asset Information and Register Requirements.

• All MMIs must be identified by CMG 3.







• Non-linear assets only require a Start Km, linear assets require both a Start Km and End Km.

• Asset descriptions must be aligned with the ASA T MU AM 02002 TI Asset Classification System, unless agreed with TfNSW and documented in the Project DEXP.

• Project Location names/descriptions must be aligned with T MU AM 01007 TI Asset Reference Codes Register, unless agreed with TfNSW and documented in the Project DEXP.

• A Project Location ID can be associated with multiple Asset IDs.

• The Project Location classification must be Uniclass 2015 unless agreed with TfNSW and documented in the Project DEXP (usually required for Earthworks, Paving, etc).


The asset data required to operate and maintain the assets is to be delivered as an Asset Register (based on DMS-FT-537), with classification provided in accordance with Uniclass 2015 to the levels specified in Table 43.

The assets must be defined to the MMI level by CMG3. To determine the MMI, refer to the rules for the inclusion of assets in the asset register as specified in T MU AM 02001 ST Asset Information and Register Requirements, section 7.1 Rules for creation of assets in the asset register. It is recommended that this process is undertaken in consultation with the operator/maintainer.


CM Gate

Co En SL EF Ss Pr

0 Co_xx As required As required As required As required As required



3


5

Compliance with the data classification and coding requirements (NB classification and coding is discrete from descriptions or naming as required in Section 6.9.1) within T MU AM 02002 TI Asset Classification System and T MU AM 01007 TI Asset Reference Codes Register is not required during the Plan/Acquire phase of IP projects. Upon Contractor submission of the Handover Asset Register to TfNSW, TfNSW will assign the ASA asset and location classification codes prior to providing to the register to the Operator & Maintainer. This is done to reduce complexity and enable the use of Uniclass2015 during Plan/Acquire phases for the Contractor, eliminating the need for duplicated effort in coding.

It must be noted that other asset owner standards, such as Roads and Maritime Services (RMS) and local councils are currently outside of the scope of this document. Refer to the Contract for these and other asset owner data requirements.








For brownfield sites, the existing asset register(s) are to be provided by TfNSW to the Contractor project team at project commencement. The existing data and information are to be reviewed for relevancy to the project. Where existing data is to be re-used as part of a new deliverable, including the assets listed in the Asset Register, this data is to be classified in accordance with this DES, if not already compliant.

6.9.4. Validation and asset handover

At the completion of the Acquire phase, the Contractor must validate the Handover Asset Register and ensure compliance with the classification requirements and PDS.

The Handover Asset Register data collection process must consider the following:

• Validate all project data to ensure it is accurate and consistent with DE requirements.

• Submit via the TfNSW ECM a complete copy of all PIM information.

• Identify and include the MMI in the Handover Asset Register, as per T MU AM 02001 ST Asset Information and Register Requirements, Section 7.1, Rules for creation of assets in the asset register.

• Identify any additional project data that is required to be handed over for the O&M phase.

• Submit via the TfNSW ECM a complete set of handover data as agreed with the O&M party, including the Handover Asset Register.

Other documents and files must be validated in accordance with Section 3.3.

6.9.5. Asset data submission format

The Asset Register (based on DMS-FT-537) is to be provided in .xls format and uploaded to the TfNSW ECM tool in accordance with the ECM tool requirements specified in Section 3.3.







7. Project team (responsibilities)

All personnel in organisations delivering and managing assets for TfNSW play an important role in the production of reliable, consistent information. All project personnel must adopt the behaviours listed in Table 44 to help develop an appropriate working culture to facilitate successful DE.

Table 44: DE Team Behaviours

Ref Project Behaviour Description

1 Share, collaborate, deliver

All personnel have a responsibility to share information, and where required, coordinate and collaborate to deliver TfNSW’s required Digital Engineering outcomes.

2 Use common language

Use a common language so people can effectively exchange information.

3 Auditable assurance pathway

Resolve issues collaboratively, manage risks and track decisions to provide a traceable and auditable pathway through design development up until asset disposal.

4 Digital tools to support decision making

Implement effective tools and provide training so personnel are empowered to make decisions using the best available information.

5 A platform to support innovation

Use Digital Engineering tools and processes to drive innovation in the way projects are delivered.

Roles, responsibilities and levels of authority for the management, control and execution of DE activities and deliverables must be assigned to identified personnel within the project team, on both TfNSW and the Contractor sides, as agreed by the TfNSW DE Manager and the Contractor.

TfNSW will establish the following roles, with both general and specific DE responsibilities:

a. TfNSW Project Manager (PM), with DE management accountabilities

b. TfNSW DE Manager responsible for DE

The Contractor will confirm the party(ies) and named person(s) who will be responsible for information modelling and DE management for the project in the Project DEXP, describing what activities will be performed and what authorities will be held by each individual. This includes overall responsibility and scope of appointments for both TfNSW and Contractor personnel, as appropriate to the project structure.

Allocations may change depending on project scope and complexity, and all engaged personnel must be able to demonstrate the required and appropriate experience, training and competencies.

The responsibilities listed in Table 45 may be performed by individuals or teams in larger projects, while functions may be combined for smaller projects or be combined with other project roles.







Table 45: DE Project Responsibilities

Organisation Key Responsibilities

TfNSW Manages and coordinates project execution and DE to meet procurement strategy and cost containment

TfNSW Responsible for overall project DE strategy, procurement and implementation

Contractor Responsible for overall project DE strategy and implementation by the Contract Project Team

Contractor Responsible for the setup and delivery of the project from a DE perspective. This includes creation and management of the PIM and AIM in line with the project deliverables and this DES.

Contractor Responsible for managing the overall production for the project’s federated BIM model and associated data sets, including CAD

Contractor Responsible for managing the overall production for the project’s GIS data layer and associated platforms

Contractor Responsible for initiation, agreement and implementation of information sub-plans, for control and governance of separate design packages (disciplines) and/or sub-contractor works

Contractor Ensures compliance for information management in accordance with the Contract, legislation and relevant ASA and Industry Standards

Contractor Responsible for the day-to-day implementation of document control processes and system support

On projects that require integrated scheduling, cost and/or asset information, the Contractor must identify the roles and responsibilities of personnel that will be responsible for the production, control, assurance and federation of this information.







8. Assurance requirements

The Contractor must comply with the general assurance requirements for the project as part of AEO accreditation. DE requires data assurance from Contractors, including that all information deliverables for a project are structured in alignment with the TfNSW Project Data Schema (refer to 5.3).

The Contractor is required to validate all project deliverables prior to submission to TfNSW against the DE requirements. As part of the DE Validation process TfNSW will use each Submission to validate, including but not limited to, the following:

1. The development, completeness and validity of the all asset and other project data, including BIM models, as specified in this DES and the Contract.

2. The currency of the information in the BIM model and deliverable data, and that all parties are working to the latest information.

3. Compliance with DE performance requirements set out in the contract.

Compliance with DE assurance requirements is to be included in monthly project reporting to the TfNSW Representative, including providing detail of relevant mitigation actions, including timeframes, to address non-compliances.

8.1. Quality assurance and quality control

Without limiting the quality assurance and quality control measures required elsewhere in Contract documentation, TfNSW requires Contractors to establish, implement and maintain quality assurance and quality control processes, procedures and protocols for Digital Engineering.

TfNSW requires Contractors to include, as part of their Audit Management program, compliance checks with Digital Engineering requirements included in the contract. As per the audit requirements Contractors are to report on the results of internal Digital Engineering audits and resolve any issues or process improvements identified.

8.2. Performance management/continuous improvement

TfNSW requires Contractors to manage and monitor performance throughout the planning, design and construction phases of the project.

The Contractor is to facilitate a Digital Engineering KPIs definition workshop within 4 weeks of Contract award. The KPIs must be agreed with TfNSW to inform the project delivery, as well as the TfNSW Digital Engineering Framework (DE Framework), including, but not limited to:

1. Number of design clashes/issues detected during project life cycle

2. Number of RFI’s received

3. Average number of business days required to close out an RFI

4. Number of business days to review each Design Package

5. Number of business days to close out design comments







6. Number of business days to achieve project milestones vs the original project baseline milestone.

7. Number and the amount of variations during design/construction

8. Number of errors in asset data register submission when passing through the each Configuration Management Gate (CMG).

The Contractor will undertake a KPI review and lessons learned workshop regarding the execution of DE within the project as part of the regular project reporting as required by the Contract. As a minimum, a KPI review and lessons learned workshop must be held at the end of each CMG.

The Contractor is required to detail in the DEXP appropriate performance indicators and analysis to demonstrate level of DE performance.







Appendix A - Reference of standards and guidelines

To successfully implement DE, Contractors are required to correctly apply relevant standards and best practice guidelines from Asset Standards Authority (ASA), Operating Agencies, utility providers and industry. Table 40 provides a list of applicable standards and guidelines that Contractors must consider when implementing DE for TfNSW projects.

Table 46: TfNSW Digital Engineering – applicable existing standards and guidance

Applicable standards and guidance documents

Publication title

Gu

ida

nce

En

gin

eeri

ng

Info

rmati

on

m

an

ag

em

en

t /

CD

E

Asset

Info

rmati

on

Level

of

Def/

Dev

Co

sti

ng

Infrastructure & Place

- Integrated Assurance Framework

TfNSW ASA T MU AM 01005 ST

Asset Handover Requirements

T MU AM 01006 ST

Asset Reference Codes

T MU AM 01006 F1

Asset Location Classification Code Form

T MU AM 01007 TI

Asset Reference Codes Register

T MU AM 01008 ST

Technical Maintenance Plans and Coding System

T MU AM 01012 ST

Engineering Document Requirements

T MU AM 01012 F1

Metadata Spreadsheet for Engineering Documents

T MU AM 02001 ST

Asset Information and Register Requirements

T MU AM 02002 TI

Asset Classification System

T MU AM 02004 ST

Management of Asset Information

T MU AM 02006 TI

Asset Register and Data Dictionary

T MU AM 04001 PL

TfNSW Configuration Management Plan

T MU AM 06006 ST

Systems Engineering Standard

T MU AM 06006 GU

Systems Engineering Guideline

T MU MD 00006 ST

Engineering Drawings and CAD Requirements

T MU MD 00006 TI

Technical Information for CAD and Engineering Drawings







Applicable standards and guidance documents

Publication title

Gu

ida

nce

En

gin

eeri

ng

Info

rmati

on

m

an

ag

em

en

t /

CD

E

Asset

Info

rmati

on

Level

of

Def/

Dev

Co

sti

ng

T MU MD 00006 F1

Metadata Spreadsheet for Engineering Drawings

T MU MD 00014 GU

Multi-Discipline Rail Infrastructure Design Management

International and Industry

ISO 19650-1

Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) – Information management using building information modelling

Part 1: Concepts and principles

ISO 19650-2

Organization and digitization of information about buildings and civil engineering works, including building information modelling -- Information management using building information modelling: Delivery phase of the assets

BS1192:2007

Collaborative production of architectural, engineering and construction information. Code of practice

PAS1192-

2:2013

Specification for information management for the capital/delivery phase of construction projects using building information modelling

PAS1192-3:2014

Specification for information management for the operational phase of assets using building information modelling (BIM)

BS1192-4:2014

Collaborative production of information. Fulfilling employer's information exchange requirements using COBie. Code of practice

PAS1192-5:2015

Specification for security-minded building information modelling, digital built environments and smart asset management

BS 8536-2:2016

Design and construction : Code of practice for asset management (Linear and geographical infrastructure)

BIM Forum LOD 2018

LOD Specification 2018

NBS - Uniclass 2015

Unified Classification System for the Construction Industry







Standards and guidance developed by other authorities such as local authorities and utilities providers should be considered on a case-by-case basis. TfNSW also encourages Contractors to apply industry best practices, while meeting TfNSW’s minimum requirements.

Guidance from other relevant authorities and sources should be used to inform the development of the Contractor’s project specific DE Execution Plan (DEXP).







Appendix B – Digital Engineering Execution Plan (DEXP) Template (DMS-FT-532)







Appendix C – IFC




DMS-ST-207 DE STANDARD - PART 2_V3.0 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207


Digital Engineering Standard Part 2 Requirements · 2019-11-12 · DMS-ST-207 Standard –...

Documents

Transcript of Digital Engineering Standard Part 2 Requirements · 2019-11-12 · DMS-ST-207 Standard –...