digital engineering standard part 2 requirements
TRANSCRIPT
Digital Engineering Standard Part 2 – Requirements
DMS-ST-207
Standard – Applicable to Infrastructure and Place
Divisional Management System
Status: Final
Version: 4.0
Branch: Technical Services
Section: Digital Engineering Services
Business unit:
Date of issue: September 2018
Review date: April 2021
Audience: Division wide
Asset classes: Heavy Rail; Light Rail; Metro; Roads; Bridges;
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 Digital Twin Integration
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 2 of 116
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
4.0 April 2021 - Update for roads assets and multi-modal Configuration Management Framework
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 3 of 116
Preface
Transport for New South Wales (TfNSW) is developing and implementing the Digital Engineering (DE) Framework to support projects as they adopt new digital ways of working. The way assets are planned, designed, constructed, operated and maintained are becoming faster and more accurate as a result of emerging technologies. The DE Framework connects these technologies across various project disciplines together with reliable, structured data.
Consistent DE processes provide TfNSW with an approach that enables digital information to become a key enabler of better project outcomes. This includes, but is not limited to; stakeholder engagement, informed decision making, improved asset knowledge, capability and capacity planning.
Applying this unified vision will accelerate the value of DE, and simplify these new ways of working for both our project teams and industry, providing valuable insights, creating efficiencies and delivering cost savings throughout the project lifecycle.
This document should be read in conjunction with all related DE Framework documentation. Any application of the DE Framework 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 to ensure best appropriate practice.
Engagement with the Digital Engineering Team
The first point of contact for the project team, implementing this DE Standard (DES) for a TfNSW project, is your project TfNSW DE Manager.
For general enquiries and assistance with the 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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 4 of 116
Table of Contents
1. Introduction ................................................................................................................... 7
1.1. The Digital Engineering Framework ........................................................................ 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
1.7. TfNSW governance and control ............................................................................ 10
2. Collaborative working requirements .......................................................................... 13
2.1. Collaboration principles ........................................................................................ 13
2.2. Collaboration activities .......................................................................................... 13
3. The TfNSW-CDE for IP Projects .................................................................................. 14
3.1. The Contractor-CDE ............................................................................................. 14
3.2. Workflow between the CDEs ................................................................................ 15
3.2.1. Information exchange process .................................................................. 15
3.2.2. Bulk uploads ............................................................................................. 16
3.3. ECM File Metadata Requirements ........................................................................ 16
3.3.1. File name .................................................................................................. 20
3.3.2. Document title ........................................................................................... 20
3.3.3. Approval States ......................................................................................... 20
3.3.4. Suitability .................................................................................................. 22
3.3.5. Review Status ........................................................................................... 23
3.3.6. Revisions and versions ............................................................................. 23
3.4. Existing data review.............................................................................................. 25
3.5. Validation of new deliverables .............................................................................. 25
3.6. Email requirements .............................................................................................. 25
3.7. Request for Information (RFI) requirements ......................................................... 25
3.8. Data security ........................................................................................................ 26
3.8.1. Data Security Protocol .............................................................................. 26
4. Project data management ........................................................................................... 28
4.1. Project data building blocks (PDBB) ..................................................................... 28
4.1.1. Project specific building blocks .................................................................. 28
4.1.2. Standard TfNSW building blocks ............................................................... 30
4.1.3. PDBB data management features ............................................................. 32
4.2. Structuring and standardisation of data ................................................................ 33
4.2.1. Asset location containers .......................................................................... 34
4.2.2. Asset function, system and type ................................................................ 37
4.2.3. Discipline classification and referencing .................................................... 41
4.2.4. Work Packages ......................................................................................... 42
5. Management Requirements ........................................................................................ 45
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 5 of 116
5.1. Submission of DE deliverables ............................................................................. 45
5.2. Digital Engineering Execution Plan (DEXP) .......................................................... 45
5.3. Management of the Project Data Schemas (PDS) ................................................ 46
5.3.1. Changes to PDS ....................................................................................... 47
5.3.2. Changes to Uniclass 2015 ........................................................................ 48
6. Technical Requirements ............................................................................................. 49
6.1. Systems engineering deliverables ........................................................................ 50
6.1.1. Structuring and standardisation of data ..................................................... 52
6.1.2. Review of existing data ............................................................................. 52
6.1.3. Verification and validation ......................................................................... 53
6.1.4. File submission format .............................................................................. 53
6.2. Survey deliverables .............................................................................................. 54
6.2.1. Structuring and standardisation of data ..................................................... 57
6.2.2. Review of existing data ............................................................................. 58
6.2.3. Validation .................................................................................................. 59
6.2.4. File submission format .............................................................................. 59
6.3. CAD deliverables .................................................................................................. 60
6.3.1. Drawing titleblock ...................................................................................... 61
6.3.2. CAD layer naming ..................................................................................... 69
6.3.3. Composite models .................................................................................... 71
6.3.4. Review of existing data ............................................................................. 71
6.3.5. Validation .................................................................................................. 71
6.3.6. File submission format .............................................................................. 71
6.4. BIM deliverables ................................................................................................... 73
6.4.1. BIM process requirements ........................................................................ 74
6.4.2. BIM Model requirements ........................................................................... 76
6.4.3. Utility information ...................................................................................... 81
6.4.4. Model federation ....................................................................................... 82
6.4.5. Clash detection ......................................................................................... 83
6.4.6. Model reviewing and validation ................................................................. 83
6.4.7. File submission format .............................................................................. 84
6.5. Visualisation ......................................................................................................... 86
6.5.1. Visualisation requirements ........................................................................ 86
6.5.2. Structuring and standardisation of data ..................................................... 87
6.5.3. Review of existing data ............................................................................. 87
6.5.4. Validation .................................................................................................. 87
6.5.5. File submission format .............................................................................. 87
6.6. GIS deliverables ................................................................................................... 88
6.6.1. GIS requirements ...................................................................................... 88
6.6.2. Structuring and standardisation of data ..................................................... 89
6.6.3. Review of existing data ............................................................................. 89
6.6.4. Validation .................................................................................................. 89
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 6 of 116
6.6.5. GIS deliverable submissions ..................................................................... 90
6.7. Time deliverables ................................................................................................. 91
6.7.1. Project schedule deliverable requirements ................................................ 91
6.7.2. 4D model deliverable requirements ........................................................... 91
6.7.3. Existing data review .................................................................................. 92
6.7.4. Validation .................................................................................................. 92
6.7.5. Time deliverable submissions ................................................................... 92
6.8. Cost deliverables .................................................................................................. 93
6.8.1. Structuring and standardisation of data ..................................................... 93
6.8.2. 5D Model deliverables ............................................................................... 94
6.8.3. Existing data review .................................................................................. 94
6.8.4. Validation .................................................................................................. 94
6.8.5. Cost deliverable submissions .................................................................... 94
6.9. Asset data deliverables ........................................................................................ 95
6.9.1. Asset register requirements ...................................................................... 95
6.9.2. Structuring and standardisation of data ................................................... 100
6.9.3. Existing data review ................................................................................ 101
6.9.4. Validation and asset handover ................................................................ 101
7. Project team responsibilities .................................................................................... 102
8. Assurance requirements ........................................................................................... 104
8.1. Quality assurance and quality control ................................................................. 104
8.2. Performance management/ continuous improvement ......................................... 104
Appendix A - Reference of standards and guidelines ................................................... 106
Appendix B –Levels of Detail indicative diagrams ........................................................ 109
B1 Bridge Structure ................................................................................................. 110
B2 Drainage ............................................................................................................. 111
B3 Road Alignment/ Pavement ................................................................................ 112
B4 Road Furniture ................................................................................................... 113
B5 Survey ................................................................................................................ 114
B6 Utilities................................................................................................................ 115
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 7 of 116
1. Introduction
1.1. The Digital Engineering Framework
This Digital Engineering Standard (DES) and supplementary templates, guidelines training, and resources form the Digital Engineering (DE) Framework. The DE Framework provides the tools and requirements to assist TfNSW projects seeking to implement DE following the first release in 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 for the implementation of the specific requirements of the DES, based on specific DE disciplines, 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 Project Contract and/or the Project 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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 8 of 116
Figure 1: Digital Engineering 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
Project Doc umen t TfNSW Guides TfNSW Template
TfNSW Procurement Templates
Supporting Documents and
Forms/Templates
Data and Information Asset Management
PolicyCP17005
Project DEXP Template & draft PDS
TfNSW Conditions of Contract
Project Scope of Works/Services
Project Specifications and Requirements
Project SpecificDEXP
Digital Engineering
Standard
Standard(mandatory)
Policy
Project Data Building Blocks
Project Data Schemas
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 9 of 116
1.2. Purpose of this document
This DES is the lead document in the DE Framework for the Contractor, providing minimum requirements for the implementation of DE. It details how the Data & Information Asset Management Policy (CP17005) 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 BIM Models 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). Providing an overview of the TfNSW operating environment and DE concepts.
2. Part 2 (this document) – TfNSW Digital Engineering Standard, Requirements (DMS-ST-207). Providing 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 Asset Management Framework and the TfNSW Configuration Management Framework and relevant Agency configuration and design management plans.
1.4. Scope of this DES
This DES is applicable for TfNSW staff and Contractors delivering Physical Transport Assets for TfNSW during the Plan-Acquire phases (ie planning, design and construction), where DE methodologies are specified for project delivery. 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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 10 of 116
Figure 2: The current application of the Digital Engineering Framework 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 include:
• 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 refers to various TfNSW and industry standards, guidelines and specifications. Sources include:
• TfNSW Safety, Environment & Regulation (SER) (previously Asset Standards Authority (ASA) and Roads & Maritime Services (RMS)) standards and procedures
• Infrastructure & Place (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.
1.7. TfNSW governance and control
This DES references the Integrated Design Reviews, as defined in the Transport Requirements for Assured Configuration Change (TRACC) Standard, to specify the submission and deliverable requirements at the different milestones. To align the legacy ASA and RMS design assurance gates, the equivalent Configuration Management Gates (CMG) and Investment Assurance Gates (IAG) are aligned with the Integrated Design Reviews as shown in Table 1. Note, the IAG are still applicable to projects in relation to financial assurance.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 11 of 116
Table 1: Integrated Design Reviews
Asset Management
Lifecycle
Configuration Management Framework
TRACC Standard
Design Process Configuration Management
Gate (legacy)
Investment Assurance Gate
Stage Phase Design Activity
Integrated Design Review
Demand / Need
Need (TRACC 1)
0 - Go / No Go (Needs justification)
Plan Network Planning (TRACC 2)
Feasibility Studies
CMG 0 (Business Requirements Specification)
1 - Strategic Options (Strategic assessment)
Delivery Planning (TRACC 3)
Concept Design
Concept Design Development (CDD)
CMG 1 (Concept Design)
2 - Business Case
Acquire Design (TRACC 4)
Systems Breakdown Review (SBR)
3 - Readiness for Market (Pre-tender)
4 - Tender Evaluation
Preliminary Design
Preliminary Design Review (PDR)
CMG 2 (Preliminary Design)
Reference Design (optional)
Detailed Design
Detailed Design Review (DDR)
Final Design Final Design Review (FDR)
CMG 3 (Detailed Design)
Approved For Construction
Implement (TRACC 5)
Construction Specification
Final Specification Review (FSR)
CMG 4 (Construct and install)
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 12 of 116
Asset Management
Lifecycle
Configuration Management Framework
TRACC Standard
Design Process Configuration Management
Gate (legacy)
Investment Assurance Gate
Stage Phase Design Activity
Integrated Design Review
As Built As Built Review (ABR)
CMG 5 (Commissioning, testing and handover)
5 - Readiness for Service (Pre-commissioning)
Close Out (TRACC 6)
Final Build 6 – Benefits Realisation
(Post-implementation)
Operate / Maintain
Operate and Maintain (TRACC 7)
CMG 6 (Asset assurance review)
Dispose / Renew
Dispose / Renew (TRACC 8)
Refer to Section 2.1 in DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles for further details.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 13 of 116
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.
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.
• How information access will be managed in accordance with TfNSW’s security requirements.
• Details of model review workshops and other collaborative working practices, for example, 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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 14 of 116
3. The TfNSW-CDE for IP Projects
The Project CDE is made up of two parts: the TfNSW-CDE and the Contractor-CDE. This section includes the requirements and process for the submission of information deliverables by contractors to the specified TfNSW systems for scheduling, document/ file management, email and progress claims during the Plan and Acquire phases.
Standardised file formats and data structures are critical to enabling automatic data validation of submissions by TfNSW.
The current TfNSW-CDE includes the software listed in Table 2. Equivalent or additional software may be included in the TfNSW-CDE based on project specific requirements and as specified in the project Contract.
Table 2: Current typical TfNSW-Common Data Environment interface applications
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 the agreed project schedule as per the Contract.
Reporting of progress against the planned program and milestone dates.
3 Virtual Plan Room (VPR) - ProjectWise
Rail networks only - Central plan room for rail model and drawing package submission, storage and archiving
Contractor to supply deliverables compliant with requirements for upload of models and drawings at Final Design Review and As-Built Review.
TfNSW is responsible for upload of approved models and drawings to the VPR (where applicable).
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.
In relation to the CDE, at a minimum the Project DEXP is to include:
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 15 of 116
• Metadata schema for tagging files uploaded to the Contractor-CDE. It is recommended that the Contractor adopt DMS-FT-533 ECM Schema and Specification 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).
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.
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 3.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 16 of 116
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 3: Information Exchange Process
3.2.2. Bulk uploads
Bulk upload of files to the ECM may be utilised 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 and Specification).
3.3. ECM File Metadata Requirements
In order for the TfNSW-CDE to accept the submission as compliant, the metadata included with files uploaded to the TfNSW-CDE must align with the requirements specified in DMS-FT-533 ECM Schema and Specification. Any project specific ECM metadata requirements are to be included in the Project DEXP. Refer to Table 3 for ECM metadata requirement provisions.
Table 3: Enterprise Content Management Requirements
Ref Requirement Description
1 Metadata spreadsheet
Where TfNSW does not require the use of an ECM system solution, metadata for each file must be provided accompanying the transmission as specified in DMS-FT-533 ECM Schema and Specification in .xls format.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 17 of 116
2 Use of ECM system solution (eg Team Binder/ InEight)
Where TfNSW specifies the use of an ECM system solution, metadata as specified in DMS-FT-533 ECM Schema and Specification must be entered upon upload of the file to the software tool.
Specific technical fields are explained in the following sections, with a summary of fields listed in Table 4 (at publication time of this Standard). Refer to DMS-FT-533 ECM Schema and Specification for the current specification and further details.
Table 4: Enterprise Content Management (ECM) Schema and Specification
Ref Field name Field Label
(TfNSW’s TeamBinder) Description
1 Document Number Document No.
Defined by Project. The unique document number required to reference the applicable document uploaded. Document number specified by the document numbering schema.
2 Document Title Title Defined by Project. The applicable title description associated with the document.
3 Program Name Program Program name defined by TfNSW.
4 Project Name Project Project name as part of a program defined by TfNSW
5 Contract Name Contract Contract reference to deliver a part of Program/Project as per the project delivery strategy. Defined by TfNSW.
6 Contracted Organisation Code
Originator The contracted organisation responsible for the production of the documents.
7 Phase Stage Code INSW Phase/TfNSW Stage
Infrastructure NSW (INSW) project governance phases and TfNSW investment assurance gates defined by TfNSW.
Visible to Document Controller only.
8 Project Milestone Code
Project Milestone Defined by TfNSW, Project specific milestone.
9 Asset Location Code (L1)
Location
Defined by Project. Refers to the top level in the asset location hierarchy to which the document refers to or belongs, e.g. Train station etc.
10 Asset Location Code (L2)
Sub-Location
Defined by Project. Refers to the second highest level in the asset location hierarchy, permitting documents to be associated with a more specific location
E.g. Station platform, etc.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 18 of 116
Ref Field name Field Label
(TfNSW’s TeamBinder) Description
11 Asset Location Code (L3)
Sub-sub-Location
Defined by Project. Refers to the third level in the asset location hierarchy, permitting documents to be associated with an even more specific location. e.g. Platform 1, Meeting Room, etc.
12 Work Zone Code (L1)
Work Zone (L1)
Defined by Project. Work Zones are where project work gets performed. Large geo-spatial areas may be sub-divided into Work Zone (L2)
13 Work Zone Code (L2)
Work Zone (L2) Work Zone (L2) is second level Work Zones and relate to a L1 Work Zone.
14 Work Zone Code (L3)
Work Zone (L3) Work Zone (L3) is second level Work Zones and relate to a L2 Work Zone.
15 Discipline Code Discipline
Defined by TfNSW. A unique identifier to identify the related Technical or Business discipline responsible for carrying out the design.
16 Sub-Discipline Code
Sub-Discipline Defined by TfNSW. A unique identifier to identify the related Technical or Business Sub-discipline responsible for the design.
17 Document Type Code
Document Type The type of information the document contains e.g. a report, drawing, etc.
18 Serial Number Serial Number
Six digit serial number which, when concatenated with the rest of the document number, results in a unique document number.
19 Document Revision Number
Revision For tagging a document with a revision reference when major changes are made.
20 Document Version Number
Version Child of Revision. Automated by system for every revisioning of the document
21 ASA VPR Discipline Code
ASA VPR Discipline Existing VPR discipline codes used by TfNSW SER (where applicable).
22 ASA EDMS ID ASA EDMS ID An allocated document identifier by TfNSW SER (where applicable).
23 ASA Amendment Number
ASA Amendment No
Document amendment number managed by TfNSW SER in relation to project milestone submissions (where applicable, refer to Section 3.3.6.1).
24 State Code State
As per ISO 19650. 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)
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 19 of 116
Ref Field name Field Label
(TfNSW’s TeamBinder) Description
25 Suitability Code Suitability
As per ISO 19650. For defining the purpose or appropriate use of the document. E.g. For Coordination, For Information, For Review and Comment.
26 Review Outcome Code
Review Status
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.
27 Work Package Group
Work Package Group
The Work Package Group is a work package classification. It includes the following: “Design”, “Construction”, “Commissioning”, “Supply” & “Management”.
It is used to group Work Packages defined by the Project.
28 Work Package Name
Work Package Name
Work Packages are governed by the project based on the scope of the project. Work Packages are classified by a Work Package Group.
29 Security Classification Code
Security Classification
Information Security Classification, Labelling & Handling Standard defined according to the Information Security Classification, Labelling & Handling Standard - Policy Number: CPSt14001.4
30 BIM Reference Link BIM Reference Optional reference to models, model objects or model views.
31 GIS Reference Link GIS Reference References to GIS managed locations related to the document if required.
32 Contractor Doc Number
Contractor Doc No For the Contractor to add the Contractor-CDE Document Number, if necessary.
33 ECM Remarks Remarks User comments.
34 Date Recorded Date Recorded
The date when the document was uploaded to the ECM.
System generated.
35 Date Released Date Released
The date when the document was promoted to the Published state.
System generated.
36 Document Revision Notes
Revision Notes User comments outlining the design content and often used to denote what has changed.
37 Required for Handover Flag
Required for Handover Optional. A Y/N flag indicating whether the deliverable is required for asset handover.
38 Handover Organisation Code
Handover Organisation Optional. The organisation that is to receive the document at asset handover.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 20 of 116
3.3.1. File name
Files uploaded to the TfNSW ECM are to be given a name that is equivalent to the Document Number with reference to file names in the Master Information Delivery Plan (MIDP), (refer to Section 5.2).
3.3.2. Document title
Document titles are required on the first or front page of each document and clearly describe their content. The same (full) title must also be captured on the transmittals and are to be included in the metadata uploaded for each document to clearly describe their content.
The document titles must include the following:
1. Begin with the project and/or location name
2. Clearly describe the content or subject matter
3. Include the type of document.
3.3.3. Approval States
The Contractor is responsible for the management of Work in Progress (WIP) and Shared information within the Contractor-CDE and uploading 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, D1, D2, D3, D4), refer to Table 6.
TfNSW or the independent certifier (if required) is responsible for the correct metadata categorisation of Review Status 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.4) is illustrated in Figure 4.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 21 of 116
Figure 4: Approval States, Suitability and Review outcome
Descriptions of the approval states and their intended uses are provided in Table 5. Intermediate checking or internal states, additional to those described in Table 5, are acceptable in the Contractor-CDE, however, all these states must be defined clearly in the Project DEXP. Where the state titles used in the Contractor-CDE differ from those specified by this DES, these must be agreed with the TfNSW DE Manager prior to use.
Table 5: Application of State within the Common Data Environment
Ref State State Description
1 Work-In-Progress (WIP)
Information not checked or approved. WIP information exists only within either the TfNSW-CDE or Contractor-CDE
2 Shared Information shared within the project team for a specific purpose (refer to Table 6)
3 Client Shared Information received and distributed to appropriate TfNSW personnel or external agent (including independent certifier or verifier) for review
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 22 of 116
Ref State State Description
4 Published Coordinated and validated information which is authorised for use on the project, for example for Construction.
5 Archived Superseded or otherwise archived information
3.3.4. Suitability
Suitability codes are applied to information that is Shared, Client Shared, Published or Archived.
The Project DEXP is to specify the Suitability Codes for use on the project. On upload (Client Shared) of information to the TfNSW-CDE or after review by TfNSW, the Contractor is responsible for ensuring the appropriate Suitability Code (refer to Table 6) is included in the information metadata.
Table 6: Application of Suitability within the Common Data Environment
Ref
State Suitability Code
Suitability Title Suitability Description
1 Work-In-Progress (WIP)
S0 Not for sharing Draft information not suitable for distribution. Can be used for ‘placeholders’ in the TfNSW-CDE.
2
Shared /
Client-Shared
S1 For coordination Information shared for coordination
3 S2 For information Information shared for information only
4 S3 For review and comment
Information shared for review and comment
5 S4 For stage approval Information shared for approval at whichever project stage applies (e.g. an Integrated Design Review)
6 S5* Principal Design Party certified
Information which has been Principal Design Party (AEO, lead designer or internal TfNSW authoriser) certified (typically at Integrated Design Reviews)
7 D1 For costing Information for costing purposes
8 D2 For tender Information for tender purposes
9 D3 For contractor design
Information for contractor design purposes (e.g. shop drawings)
10 D4 For manufacture / procurement
Information for manufacture / procurement purposes
11 L1* Legacy information Historical or archived Information
12
Published
D1 For costing Information for costing purposes
13 D2 For tender Information for tender purposes
14 D3 For contractor design
Information for contractor design purposes (e.g. shop drawings)
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 23 of 116
Ref
State Suitability Code
Suitability Title Suitability Description
23 D4 For manufacture / procurement
Information for manufacture/procurement purposes
20 A1 Note submission with no further comments
Stage completed with no further comments. TfNSW is ready to proceed to the next stage (for example, construction).
Principal Design Party (AEO, lead designer or internal TfNSW authoriser) responsibilities are unaffected by the application of this code.
21 A2 Note submission with further comments
Stage completed but with comments to address during the next stage.
Principal Design Party (AEO, lead designer or internal TfNSW authoriser) responsibilities are unaffected by the application of this code.
22 AB As-Built Information published as an As-Built record
23 Archived Any Any Any of the above suitability codes may apply to information in the Archived state.
3.3.5. Review Status
Review Status codes are applied to information in the TfNSW-CDE during the review workflow. The values shown in this table may vary between projects.
Table 7: Application of Review Status within the TfNSW-Common Data Environment
Ref Type Review Status Code
Review Status Description
1 Released REL-COM Released subject to comments
2 Released RELEASED Released (released for information only – no review required)
3 Rejected REV-RES Revise and resubmit (document not fit for release)
4 Released REV-RNC Released with no comments (no outstanding comments)
3.3.6. Revisions and versions
TfNSW requires all information within the Contractor-CDE and TfNSW-CDE to be revision and version controlled (refer to Table 8).
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 24 of 116
3.3.6.1. Revision
At each submission of a file from the Contractor-CDE to the ECM tool within the TfNSW-CDE, the ECM revision must be incremented. The first issue of design drawings must begin at ‘A’ if prior to Approved For Construction (AFC) and 00 if AFC or beyond.
Where required by SER (formerly ASA), the Contractor must control the revisions of all engineering drawings (.dgn, .dwg and .pdf) and models (refer to Section 6.4) uploaded to the VPR (at Final Design Review, Final Specification Review and As Built Review) and as required by the project CAD requirements (typically for ‘rail’ projects only). This revision numbering is known as the ASA Amendment Level Revision.
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.
Refer to Section 6.3 for DE discipline specific (BIM Model and CAD drawing) revision and version control. Any project specific requirements stated in the Project DEXP.
Table 8: Revision and version control within the TfNSW-Common Data Environment
Ref Deliverable Type File Formats
Uploaded to TfNSW-CDE
Frequency (minimum)
Revision Numbering Standard
1 All deliverables excluding Engineering drawings and models
As required by the Contract
ECM All milestones, including Integrated Design Reviews, as specified in the Contract.
IP Document Number, Titling and Revisioning Procedure
2 Engineering drawings
.dgn or .dwg and.pdf
ECM All milestones, including Integrated Design Reviews, as specified in the Contract.
Project CAD Requirements
3 Engineering models
As required by the DEXP
ECM All milestones, including Integrated Design Reviews, as specified in the Contract.
DMS-FT-532 DEXP Template
3.3.6.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 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 from the Contractor’s version number in a drawing titleblock. 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 9.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 25 of 116
Table 9: 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 must be classified in accordance with this DES, if not already compliant.
3.5. Validation of new deliverables
Deliverables (files) submitted to TfNSW 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. Where TfNSW requires the use of an ECM tool by the project, project emails to TfNSW or nominated project stakeholders are to be communicated via the nominated ECM tool.
Project specific requirements for the classification and management of email files are to be included in the Project DEXP or other appropriate project management plan. Classification of emails includes security classification based on the NSW Government Dissemination Limiting Marker (refer to the ECM Schema and Specification in the Project DEXP).
3.7. Request for Information (RFI) requirements
Where TfNSW requires the use of an ECM tool by the project, the Contractor must submit all RFIs using the ECM tool.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 26 of 116
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. Data protection, including documenting the mitigation strategies that will be implemented to protect systems and data. The eight essential mitigation strategies identified by the Australian Cyber Security Centre that are should be addressed are summarised in Table 10.
2. User access rights and permissions:
i. list all the project roles defined in this DES and the Project DEXP who will
have access to data, and
ii. For each role identified, list the specific data access rights.
Table 10: Essential Eight Strategies to Protect Data (https://www.cyber.gov.au/acsc/view-all-content/essential-eight/essential-eight-explained)
Ref Risk Applied protection measures
1 Non-approved applications
(including malicious code) may be
executed
Application control to prevent execution of
unapproved/malicious programs including .exe, DLL,
scripts (eg Windows Script Host, PowerShell, and
HTA) and installers
2 Security vulnerabilities in
applications can be used to execute
malicious code on systems
Patch Applications e.g. Flash, web browsers,
Microsoft Office, Java, and PDF viewers.
Patch/mitigate computers with ‘extreme risk’
vulnerabilities within 48 hours. Use the latest version
of applications
3 Microsoft Office macros can be used
to deliver and execute malicious
code on systems
Configure Microsoft Office macro settings to block
macros either in ‘trusted locations’ with limited write
access or digitally signed with a trusted certificate
4 Flash, ads and Java are popular
ways to deliver and execute
malicious code on systems
User application hardening. Configure web browsers
to block Flash (ideally uninstall it), ads and Java on
the internet. Disable unneeded features in Microsoft
Office (e.g. OLE), web browsers and PDF viewers
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 27 of 116
Ref Risk Applied protection measures
5 Adversaries use these administration
accounts to gain full access to
information and systems
Restrict administrative access to operating systems
and applications based on user duties. Regularly
revalidate the need for privileges. Do not use
privileged accounts for reading email and web
browsing
6 Security vulnerabilities in operating
systems can be used to further the
compromise of systems
Patch operating systems Patch/mitigate computers
(including network devices) with ‘extreme risk’
vulnerabilities within 48 hours. Use the latest operating
system version. Do not use unsupported versions
7 Stronger user authentication makes
it harder for adversaries to access
sensitive information and systems
Multi-factor authentication including for VPNs, RDP,
SSH, and other remote access, and for all users when
they perform a privileged action or access and critical
(sensitive/high-availability) data repository
8 Access to data could be lost either
through deliberate attack such as a
ransomware incident or due to
accidental damage to system
infrastructure
Daily backups of important new/changed data,
software and configuration settings, stored
disconnected, retained for at least three months. Test
restoration initially, annually and when IT infrastructure
changes
Project specific cybersecurity requirements, such as provision of a Service Organisation Control (SOC) 2 audit report, are addressed on a project by project basis and included in the project contract.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 28 of 116
4. Project data management
TfNSW requires projects to develop, implement and maintain procedures to manage data and information across the project lifecycle. TfNSW defines minimum data requirements that must be adhered to by a Project at key project milestones. These data requirements are reflected in the structure of the Project Data Building Blocks (PDBB) and associated Project Data Schemas (PDS). Contractors must comply with the data requirements specified in this Standard and the PDS.
At the conclusion of the project setup, the content of the PDS should be agreed and confirmed by TfNSW and the Contractors, ready for design to commence.
4.1. 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
• How the project scope is grouped into work packages.
The PDBB will be confirmed for the stage by TfNSW and used to generate the PDS for inclusion as an appendix in the DEXP template. This Project DEXP template may be issued to market as part of the tender documents (refer to Section 5.3).
The PDBB datasets included in DMS-FT-548 Project Data Building Blocks Template includes:
Project specific building blocks (summarised in Table 11)
Standard TfNSW building blocks (summarised in Table 12)
The PDBB contains features that provide users with functionality to assist with managing PDBB data and the publishing of PDS (summarised in Table 13).
4.1.1. Project specific building blocks
The project specific building blocks included in the PDBB Template (DMS-FT-548), that must be defined by the project team at project commencement are listed in Table 11.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 29 of 116
Table 11: Project Data Building Blocks – Project Specific Building Blocks
Ref Building block dataset
Purpose
1 Project Details Specifies the Program & Projects and, as per the project delivery strategy, the list of logical Project Contracts for each project.
Following procurement, Organisations can be associated with Project Contracts.
Able to map various IT system identifiers to Programs, Projects and Contracts as and when they are instantiated in TfNSW corporate systems.
2 Asset Locations Specifies all asset locations applicable to the project. Each location is named and classified with Uniclass 2015.
A location hierarchy is defined to reflect the asset location-to-asset location relationships.
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 (ECM) system.
3 Assets The asset list specifies all assets applicable to the project. Each asset is named and classified with Uniclass 2015.
TfNSW standard Asset Type Codes are also assigned to assets to allow for grouping of assets for the purpose of reporting & benchmarking.
An asset hierarchy is defined to reflect asset-to-asset relationships.
The Asset list provides the mapping between assets and asset locations.
The Asset list also allow for assets to be associated with work packages (defined in the Work Packages tab) are to reflect scope packaging decisions during Design, Construction and Commissioning. Assets may optionally be assigned to supply work packages if certain assets are supplied outside of the normal construction contract arrangements.
4 Work Packages Work Packages are defined as part of the project work breakdown structure (WBS) development.
Work Packages are included with the PDBB to allow for the association of Work Packages with Assets.
Logical contracts (defined in the Project Details tab) are assigned to Work Packages to reflect the delivery strategy.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 30 of 116
Ref Building block dataset
Purpose
5 Work Zones Work Zones are geo-spatial boundaries that define where project work gets performed.
Work Zones can be organised into Work Zone Groups.
A hierarchy of work zones can be defined to allow for large geo-spatial areas to be sub-divides as required.
Ownership of work zone defined can be established to allow for TfNSW to, for example, control top-level work zones and the contractor to organise more refined, delivery-focused work zones.
The PDBB is used to record the Work Zone Group and Work Zone relationships. The geo-spatial properties of Work Zones should be managed in each BIM and GIS model as spaces/containers or shape files.
6 Asset Stewards Allows for shorting listing of organisations who will play the role of asset owner, asset operator and asset maintainer.
7 Asset Locations to Work Zone Matrix
This matrix allows for Asset Locations and Work Zones to be mapped.
Mapping implies that there some geo-spatial overlap between the Work Zone and an Asset Location.
8 Work Package to Work Zone Matrix
This matrix allows for Work Packages and Work Zones to be mapped.
Mapping implies that Assets within the scope of a Work Package are associated with a Work Zone.
4.1.2. Standard TfNSW building blocks
The datasets listed in Table 12 are managed globally by TfNSW. Each project imports a specific version of these datasets and, where permitted, may modify this data by either controlling the visibility of codes (e.g. refer to Disciplines) or adding custom values (e.g. refer to Project Milestones).
TfNSW Standard Building Blocks may not be modified without permission from TfNSW.
Table 12: Project Data Building Blocks – TfNSW Standard Build Blocks
Ref Building block dataset
Purpose
1 Discipline Specifies TfNSW Business and Technical Disciplines. Disciplines are defined at two levels: discipline and sub-discipline.
Projects are permitted to edit the visibility of Disciplines on projects via the PDBB.
2 Asset Status The Asset Status is a set of SER defined codes to indicate the status of assets. An Asset Status is applied to both existing assets and planned assets by the project team.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 31 of 116
Ref Building block dataset
Purpose
3 Contract Types A Contract Type denotes the type of commercial contract.
A Contract Type is applied to each Project Contract in the PDBB.
4 Co-ordinate System
A global set of co-ordinate systems permitted by TfNSW.
5 Document Type The standard list of recognised document types.
6 Drawing Type The standard list of drawing types.
7 INSW Phase TfNSW Stage
Standard list of INSW Phases/TfNSW investment stages.
8 Originators List of originators (or Organisations) managed by TfNSW. This table also flags if an organisation is an Authorised Engineering Organisation (AEO) or an authorised design company.
9 Project Milestone
Standard list of IP Project Milestones.
Note, there are minor differences in the set of milestones used on rail and road projects. The Project Milestones master data list supports both requirements and it is up to the project to select which set to use. This is achieved by specifying “Road” or “Rail” as an attribute of the Program in the PDBB.
Custom milestones specific to a project may also be added to the Project Milestone list in the PDBB.
When Project Milestones are published via the PDS, only relevant Project Milestones are copied as per the above.
10.1 State Standard set of document State codes.
Used in the ECM to indicate the approval level and appropriate use of information.
See ISO 19650 and BS 1192:2007.
10.2 Suitability Standard set of document Suitability codes.
Used in the ECM to indicate the approval level and appropriate use of information.
See ISO 19650 and BS 1192:2007.
10.3 Review Outcome
Standard set of Review Outcome codes.
Used in the ECM to attribute documents under review.
11 Security Classification
Standard list as per 'NSW Government Information Classification, Labelling and Handling Guidelines.
12 Work Package Groups
A Work Package Group is a classification of Work Packages.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 32 of 116
Ref Building block dataset
Purpose
13 Work Type A standard list of verbs used to describe the type of work being performed. Separate lists are maintained for association with Asset Locations and Work Packages.
14 Location Classification
Holds a copy of all Uniclass 2015 codes that are used to classify asset locations. This includes codes from the following Uniclass 2015 tables: Co – Complexes, En – Entities and SL – Spaces/Locations.
Only one Uniclass version of each table is used at any time.
15 Asset Classification
Holds a copy of all Uniclass 2015 codes that are used to classify assets. This includes codes from the following Uniclass 2015 tables: Ef – Elements/Functions, Ss - Systems and Pr – Products.
Only one Uniclass version of each table is used at any time.
4.1.3. PDBB data management features
Functions and features built into the PDBB Template (DMS-FT-548) are described in Table 13.
Table 13: Project Data Building Blocks – Data Management Features
Ref Feature Purpose & Overview
1 Standard Version Control Records the versions of all Standard TfNSW building blocks.
This includes the versions, and release dates of all TfNSW master data and Uniclass 2015 tables.
The Standard Version Control information is published via the DE Project Data Schema templates to inform all recipients what version of master data is to be used on a project.
2 Data Quality Dashboard A set of data validation checks that compare PDBB data with the auto generated PDS data with the PDBB.
It can assist users with identifying if PDBB data has changed and differs from the last published set of PDS data allowing PDBB user to determine if PDS data needs to be re-distributed.
3 Update Uniclass Tables Ability to import and refresh the copy of Uniclass 2015 tables stored within the PDBB to manage the version of asset location and asset classification codes used on a project.
Automatically updates the Standard Version Control data.
4 Update TfNSW Master Data Ability to import and refresh the copy of Standard TfNSW master data from centrally managed and version-controlled source.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 33 of 116
Ref Feature Purpose & Overview
5 Update a PDS from Project Data
Ability to auto-generate & refresh a PDS dataset from the PDBB including:
Asset Register PDS
BIM PDS
CAD PDS
ECM PDS
Scheduling PDS
6 Export PDS to Schema Template
Ability to copy the relevant PDBB-managed data into the distributable DE Schema Templates.
This feature ensures that the Schema Templates only contain the latest version of the PDS data and a copy of the Standard Version Control information.
The distributable DE Schema templates are cleaned up to remove any embedded links to source documents.
The following DE Schema Templates are suppoted:
DMS-FT-333 ECM Schema and Specification
DMS-FT-516 BIM Schema and Specification
DMS-FT-520 Scheduling Schema
DMS-FT-537 Asset Register Template
DMS-FT-555 Master Information Delivery Plan Template
DMS-FT-563 CAD Schema and Specification
4.2. Structuring and standardisation of data
All deliverables (geometric and non-geometric), including drawings, models, engineering artefacts, documents and datasets must be appropriately classified in accordance with this DES, applicable Guidelines and Asset Custodian requirements. In addition, the data and information contained within deliverables, including 3D objects, CAD layers and asset information, also require classification.
For projects delivered under the DE Framework, data and information must be classified by:
• Asset location containers
• Asset function, system and type
• 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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 34 of 116
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.1. Asset location containers
Deliverables created by DE-enabled projects are required to apply standardised classification and referencing for the location container(s) to which they are associated. The specific requirements for each dataset type are specified in Section 6 and the relevant PDS. Location classification and referencing requirements are summarised in the following sections.
4.2.1.1. Asset location classification
Asset location classification 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 asset location containers/groups of assets within common locations (refer to Table 14).
Table 14: Asset location classification categories aligned with Uniclass 2015
Ref Classification Description Relevant Classifications
1 Asset Location The location of an asset or group of assets (where the asset is) For example a railway station, road carriageway or railway line.
Complexes (Co)
Entities (En)
Spaces/Locations (SL)
During the life of the project, the application of the asset location classifications increases in granularity, with minimum classification requirements aligned with the Integrated Design Review milestones. A summary of these requirements is provided in Table 15.
Table 15: Minimum Asset location classification Requirements (Uniclass 2015)
TRACC Integrated Design Review Minimum classification required
Co En SL
3 Concept Design Development Co_xx
and
En_xx
and / or
SL_xx
4 Systems Breakdown Review Co_xx_xx En_xx_xx SL_xx_xx
Preliminary Design Review Co_xx_xx En_xx_xx SL_xx_xx
Detailed Design Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx
Final Design Review
5 Final Specification Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx
As Built Review
4.2.1.2. Referencing of asset locations
A reference is a name and/or an identifier and is essential to uniquely identify each item within the information model.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 35 of 116
Each Asset Location in the asset location hierarchy must be correctly referenced.
References are to be applied by the Contractor and are to be consistent with existing naming conventions, including T MU AM 01007 TI Asset Reference Codes Register. Existing TfNSW locations, including references, are provided by TfNSW as part of the PDS.
All new location references proposed by the Contractor during project development are to be submitted to TfNSW for approval, utilising DMS-FT-374 DE Code Request Form. Upon agreement with TfNSW and documented in the Project DEXP.
The fields used for Asset Locations referencing are listed in Table 21.
Table 16: Asset Location Referencing Fields
Field Name Description
TfNSW Asset Location ID Provided by TfNSW.
Unique across TfNSW.
Project Asset Location ID A unique number that is allocated to the asset location for the duration of the contract;
This unique number enables searching for and tracking of assets and related asset data, attributes and documents and serves as the primary key for an Asset Location and hence it is mandatory.
Asset Location Code Asset Location Codes are governed by TfNSW, some at an enterprise level and some at the project level.
The Asset Location Code is a human-readable alternative primary key for an Asset Location.
The asset location breakdown is normally agreed between Contractors and TfNSW.
Each Asset Location Code must be unique across the project / program (and where appropriate across TfNSW).
For new asset locations, the Asset Location Code must be agreed with SER. Should SER deem there is no requirement to develop a centrally governed Asset Location Code, the project can create an appropriate Asset Location Code to suit the project needs.
Mandatory field.
The value is automatically derived by concatenating the Location Code Part from all locations in the location hierarchy.
The length of the Asset Location Code is therefore dependent on the hirerachy. It is a text field.
As there are no limits to the depth of the asset location hierarchy, there are no limits to the length of this code, however, it is unusual for there to be more than 6 levels in an asset location hierarchy.
Asset Location Description The Asset Location Description is a description governed by SER for the Asset Location. This description directly related to the Location Part Code for the Asset Location.
For new asset locations, the Asset Location Description must be agreed with SER. Should SER deem there is no requirement to develop a centrally governed Asset Location Description, the project can create an appropriate Asset Location Description to suit the project needs.
An Asset Location Description determined by SER will be unique within its parent location container. If the project team develop their own program/project based Asset Location Description then this description should be unique to the program/project.
A description used for the Asset Location Description for an Asset Location at level 1 (Asset Location Description (L1)) will be governed by SER.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 36 of 116
Figure 5 provides an example of location classification and referencing. Refer to TfNSW Application of Uniclass 2015 (DMS-SD-124) for further guidance.
Asset Location Classification:
SL_80_10_10 Bus stops
References (Asset Location Description):
Stand A Stand B Stand C Stand D
Asset Location Classification:
SL_80_50_24 Double-sided platforms
References (Asset Location Description):
Platform 1 Platform 2
Asset Location Classification:
SL_80_35_13 Carriageways
References (Asset Location Description)::
M1 Northbound M1 Southbound
Figure 5: Examples of Asset Location classification and referencing
4.2.1.3. Work Zones
Work Zone location containers may be used by projects to assist with project delivery (refer to DMS-ST-202, Section 6.2.2 for more information on the use of Work Zones). TfNSW requires that the projects govern Work Zone definitions. This process is led by the TfNSW project team and in collaboration with contractors. Work Zone definitions must include the both the Work Zone references, relationships and geometry information, as summarised in Table 17.
Table 17: Work Zone data
Field Name Description
Work Zone Group Name The name of the a Work Zone Group to allow for multiple sets of work zones.
Work Zone Group Code A code for the Work Zone Group.
The Work Zone Group Code must be unique on a project.
Work Zone Code The primary human-readable code for the Work Zone.
It is recommended that the Work Zone Group Code is incorporated into the Work Zone Code
Work Zone Codes should reflect the level of a work zone in a work zone hierarchy.
For example: WZG1.01.01 would be imply a level 2 work zone belonging to a Work Zone Group called WZG1
Parent Work Zone Code Use to establish a parent-child relationship between Work Zones
Work Zone Name A descriptive title for the Work Zone
Work Zone Owner Indicates who is is responsible for managing the work zone geometry.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 37 of 116
The PDBB is used to manage the Work Zone data and this data is shared across the project for use in producing deliverables via the PDS. Contractors requiring changes or additions to Work Zones must use the DMS-FT-374 DE Code Request Form to agree changes with the TfNSW project team.
Projects must define how Work Zones and their associated geometry will be governed during the project, for example, by using spaces/containers or shape files in the BIM Model or GIS. This process must be documented in the Project DEXP.
The DES recommends that top-level work zones are governed by the TfNSW project team and child work zones are managed by the Contractor.When defining child Work Zones, these must be fully contained within the geo-spatial definition of the parent Work Zone.
Figure 6: Work Zone and Sub Work Zone definition (references & geometry)
4.2.2. Asset function, system and type
Deliverables created by DE-enabled projects are required to apply standardised classification, coding and referencing for the asset function, system and type to which they are associated. The required asset classification and referenceing for each deliverable are specified in section 6 and the relevant PDS. Asset classification and referencing requirements are summarised in the following sections.
4.2.2.1. Asset classification
All asset information must be classified with a common language and structure, based on the Uniclass 2015 classification system.
The TfNSW DE Framework uses the Uniclass 2015 Elements/Functions (EF), Systems (Ss) and Products (Pr) classification tables to describe the type of a physical asset (refer to Table 18).
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 38 of 116
Table 18: Asset classification categories aligned with Uniclass 2015
Ref Classification Description Relevant Uniclass 2015 Classifications
1 Asset Element A generalised description of a main asset component or function.
For example, Vehicular paving or Rail tracks.
Elements/Functions (EF)
2 Asset System An individual or group of asset types that together perform a specific function (the purpose of the asset). For example, Stone mastic asphalt paving systems or Ballasted rail track systems.
Systems (Ss)
3 Asset Product An individual asset or component (what the asset is) For example, Stone mastic asphalt (SMA) surface courses or Bullhead rails.
Products (Pr)
During the life of the project, the application of the asset classification increases in granularity, with minimum classification aligned with the Integrated Design Review milestones (refer to Table 19).
Table 19: Minimum Asset Classification Requirements (Uniclass 2015)
TRACC Integrated Design Review
Minimum classification required
EF
Ss Pr
3 Concept Design Development EF_x
and
Ss_xx
and
As required
4 Systems Breakdown Review EF_xx_xx Ss_xx_xx As required
Preliminary Design Review EF_xx_xx Ss_xx_xx_xx Pr_xx_xx
Detailed Design Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx
Final Design Review
5 Final Specification Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx
As Built Review
The following rules must be followed to provide traceability, demonstrate relationships and asset function (refer to Figure 7 for an illustrative example):
Every asset type (Pr) identified in the Asset Register must be associated with a corresponding system (Ss), and recorded in the Project Asset Register.
Every asset system (Ss) identified in the Asset Register must be associated with a corresponding element/function (EF), and recorded in the Project Asset Register.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 39 of 116
Figure 7: Example of relational classification requirements
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 Final Design Review. 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.
Refer to the contract and Project DEXP for confirmation of project asset classification requirements over and above the minimum requirements included in this DES.
If Uniclass 2015 does not provide an appropriate 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.
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.2.2. Asset type code
As specified in Section 6 and the relevant PDS, an Asset Type Code is to be provided to compliment the asset information. The Asset Type Code is to be sourced from existing TfNSW internal data standards as appropriate to the project scope. A library of Uniclass 2015 classifications and their related Asset Type Code is provided in the Master Classification Library (DMS-FT-141).
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 40 of 116
Where further granularity is required for design or specification purposes, the project may utilise the Asset Type Configuration Code function.
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.2.3. Referencing of assets
A reference is a “name” and/or an “identifier” and is essential to uniquely identify each item within the information model.
Each Asset in the asset hierarchy must be correctly referenced. The fields used for Asset referencing are listed in Table 20
Table 20: Asset Referencing Fields
Field Name Description
TfNSW Asset ID Provided by TfNSW.
Unique across TfNSW.
Project Asset ID A unique number, usually system generated, that is allocated to the asset for the duration of the contract.
This unique number enables searching for and tracking of assets and related asset data, attributes and documents and serves as an the primary key field for an Asset and hence is mandatory.
Asset Code The Asset Code is formula-derived using a combination of the the Asset Type Code (refer to Section 4.2.2.2) and asset instance and takes into consideration the parent-child relationships within the asset hierarchy. The value can be automatically generated within the PDBB.
Note, the Asset Code is only unique within the scope of a single Assset Location. The same code could exist on other projects and at other locations which have the same assets and asset parent to child relationships. For example, two similar bridges are likely to have similar Asset Codes.
If the asset has a parent, then the Asset Code will be a concatenation of the parent's Asset Code and this asset's Asset Type Codes and Asset Identifier (if defined). The length of code is determined by the concatenation and depends on the depth of the parent and child relationship.
Asset Code naming conventions with example
Asset Type Code (of parent): “VT” (vertical transport)
Asset Type Code (of this asset): “LIFT” (passenger lift)
Asset Code (of this asset) = “VT.LIFT”
If the Asset Instance field is used, an example Asset Code will be =
“VT.LIFT_001”
Asset Description The Asset Description contains a title or short description the specific level of the asset corresponding to the Asset Code.
Where an asset description is not available within TfNSW asset standards, the Contractor should propose a description 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’).
References are to be applied by the Contractor and created in compliance with T MU AM 02001 ST Asset Information and Register Requirements and T MU AM 01006 ST Asset Location Classification. References are to be consistent with existing TfNSW naming conventions as required by the Contract, including:
T MU AM 02002 TI Asset Classification System
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 41 of 116
T MU AM 01007 TI Asset Reference Codes Register
Roads and Maritime Services Schedule of Classified Roads and Unclassified Regional Roads
ILC-GEN-TP0-901 Asset Acceptance Technical Procedure
Bridge Inspection Procedure Manual.
The Contractor is to create an asset list to control and manage a project’s full list of Elements/Functions, Systems, Products and associated data. The asset list must comply with the schema specified in the DMS-FT-537 Asset Register Template to facilitate data transfer in and out of the BIM model(s) and enagement with the O&M function. Refer to Section 6.9 for more information regarding Asset data.
4.2.3. Discipline classification and referencing
The TfNSW DE Framework mandates the classification of data and information by Discipline, a classification based on the specialism or 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 21.
Table 21: 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 engineering.
TfNSW defined (refer to Table 22)
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.
TfNSW defined (refer to Table 22)
Project information and data is to be classified with a Discipline Code, as per Table 22. Sub-discipline codes may also be utilised by the project. Confirmation of the Discipline and Sub-
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 42 of 116
discipline codes to be utilised by the project and their application will be defined by TfNSW in the PDS for consistent application across the project.
TfNSW manages the versions of Discipline and Sub-discipline Codes and the contractor will be notified via the PDS of the discipline codes relevant to the project.
Table 22: Discipline Codes (refer to the project PDS for the project-specific discipline codes)
Ref Discipline Type 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 CX Construction Management
16 CY Community
17 DV Development Management
18 EN Environment & Planning
19 OP Operation Management
20 PC Project Controls
21 PM Project Management
22 PP Property
23 SF Safety
24 SN System Engineering
25 CI Cyber Secruity
4.2.4. Work Packages
Contractors will be provided with all project defined Work Packages via the PDS.
Each project work package includes the following information:
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 43 of 116
Work Package Code
Work Package Name
Work Package Group, which refers to the work package classification
The scope of each work package, which lists all assets (and their corresponding Technical Disciplines and locations) that are relevant to the individual work package.
The Contractor must comply with the TfNSW issued Work Packages across all PDS that refer to Work Packages.
When referencing a Work Package in a project deliverable, the full scope of the Work Package must not contradict the scope associated with that Work Package in the project deliverable. 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.
The Contractor may propose changes to the scope of a Work Package. For example, if an asset was previously not identified and is being added, the definition of a Work Package changes correspondingly as illustrated in Figure 8 (note, System B is new).
Element / Function
(Asset L1)Location A
System A
Asset (L2)
Product A1
Asset (L3)
WG01.01 – Design WP 1
System B
Asset (L2)
Product A2
Asset (L3)
Figure 8: Changing the scope of Work Packages
The Contractor is free to define additional granularity to a work package hierarchy provided by TfNSW so long as the additional Work Packages always roll-up to the TfNSW issued Work Packages as illustrated in Figure 9 (Contractor adds child work packages highlighted in green).
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 44 of 116
WG01.01 – Design WP 1
WG01.01.01 – Design WP 1.1
WG01.01.02 – Design WP 1.2
Figure 9: Contractor defined "child" Work Packages
4.2.4.1. Work Package Groups
The DES defines four classifications of work packages, referred to as Work Package Groups. The purpose of Work Package Groups is to identify and group work packages used on projects at different phases of the project lifecycle. Table 23 lists all Work Package Groups
Table 23: Work Package Groups
Work Package Group ID
Work Package Group
Purpose
WG01 Design To identify and group all “design” work packages together.
WG02 Supply To identify and group any “supply” work packages together.
Use of supply work packages is optional. They are needed only when there are specific supply arrangements for assets outside of the typical construction contracts.
WG03 Construction To identify and group all “construction” work packages together.
WG04 Commissioning To identify and group all “commissioning” work packages together.
Used when the project requires the commissioning of assets to be done in a manner that differs from how they are constructed.
Where required by the PDS, the contractor must maintain a record of the associated Work Package Group for a deliverable.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 45 of 116
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 Integrated Design Reviews, refer to Section 1.7 for further details. 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 the required information and making the submissions in accordance with the Contract.
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 will provide the Contractor with a Project DEXP template, based on DMS-FT-532 DEXP Template, which includes the MIDP Template (DMS-FT-555).
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 24.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 46 of 116
Table 24: Digital Engineering ExecutionPlan submissions
TRACC Integrated Design Review
Document Type
Description/Purpose Minimum Requirement
3 CDD 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
4 SBR DEXP Updated for the subsequent Preliminary Design stage.
PDS relevant to the project developed to reflect and provide cross-reference and/or integration with the project System Requirements Specification (SRS) breakdown.
As per the project specific DEXP Template, based on DMS-FT-532 DEXP Template
PDR DEXP Updated for the subsequent Detailed Design stage.
PDS updated to reflect and provide cross-reference and/or integration with the project System Requirements Specification (SRS) breakdown and sub-system breakdown.
As per the project specific DEXP Template, based on DMS-FT-532 DEXP Template
DDR N/A - -
FDR DEXP Updated for the Construction stage, as required.
As per the project specific DEXP Template, based on DMS-FT-532 DEXP Template
5 FSR N/A - -
ABR N/A - -
It is important that the Project DEXP is updated to include any approved changes to the PDS.
TfNSW will provide PDS with the project specific DEXP template (based on 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 and templates that make up the PDS is provided in Table 25.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 47 of 116
Table 25: 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
3 Surveys Project specific requirements are to be
specified in the project contract and/or
Project DEXP. Refer to the Digital
Survey Guide for project guidance.
Utility Schema and Specification
DMS-SD-142
DMS-FT-493
4 CAD drawings CAD Schema and Specification DMS-FT-562
5 BIM Models BIM Schema and Specification DMS-FT-516
6 Visualisation Project specific requirements are to be
specified in the project contract and/or
Project DEXP. Refer to the Visualisation
Requirements Guide for project
guidance.
Visualisation utilising the BIM Model as
a basis, is to comply with the BIM
Schema and Specification.
DMS-SD-130
DMS-FT-516
7 GIS QA Specification G75 Geographic
Information Systems (GIS)
GIS Schema
IC-QA-G75
DMS-FT-580
8 Time Scheduling Schema DMS-FT-520
9 Cost estimating Specified by project - schema currently
outside the scope of DES Release 4.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 the values available for a field are defined by TfNSW in the PDS, 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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 48 of 116
by the project team and TfNSW DE Manager and submitted to the TfNSW DE Team for approval.
When 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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 49 of 116
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 DE Framework:
Table 26: Release coverage of Digital Engineering disciplines
DE discipline Release 1 Release 2 Release 3 Release 4 Future Releases
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 the best appropriate practice established by our DE-enabled Projects.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 50 of 116
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 DES defines the linkage between a requirements management system and structured data (defined in the PDBB and PDS) 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
Requirements Management deliverables.
DE-enabled projects delivering Systems Engineering outcomes, as specified in 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 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.
Systems Engineering deliverables for DE-enabled projects, aligned with the Integrated Design Reviews, are specified in Table 27.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 51 of 116
Table 27: Systems Engineering Deliverables for Digital Engineering projects
TRACC Integrated Design Review
Deliverable DE Requirement
3 CDD Operation Concept Definition
Maintenance Concept Definition
Business Requirements Specification (BRS)
Operation and maintenance requirements are allocated to an appropriate:
system or asset (Uniclass 2015 EF, Ss or Pr code) and/or
asset location (Uniclass 2015 Co, En or SL code).
OCD and MCD requirements and associated classification and coding reflected in the BRS, developed utilising DMS-SD-563 Requirements Schema and Specification, and as specified by T MU AM 06006 ST Systems Engineering Standard.
4 SBR System Requirements Specification (SRS)
System and sub-system breakdown defined based on OCD, MCD and typical System Breakdown Structure (refer to DMS-SD-141 Master Classification Library).
SRS developed utilising DMS-SD-563 Requirements Schema and Specification, and as specified by T MU AM 06006 ST Systems Engineering Standard.
Identified systems allocated into design/work packages in collaboration with development of the commercial and procurement strategy development.
Defined Asset Locations, Systems/Assets, design/work packages and work zones are documented in the PDDB and PDS.
PDR SRS developed
Verification and Validation
Additional systems and/or sub-systems identified during design process documented in the SRS, PDBB and PDS.
Traceability of design elements to business and system requirements demonstrated utilising DMS-SD-563 Requirements Schema and Specification, and as specified by T MU AM 06006 ST Systems Engineering Standard.
DDR SRS developed
Verification and Validation
Additional systems and/or sub-systems identified during design process documented in the SRS, PDBB and PDS.
Traceability of design elements to business and system requirements demonstrated utilising DMS-SD-563 Requirements Schema and Specification, and as specified by T MU AM 06006 ST Systems Engineering Standard.
FDR
5 FSR Verification and Validation
Traceability of design elements to business and system requirements demonstrated utilising DMS-SD-563 Requirements Schema and Specification, and as specified by T MU AM 06006 ST Systems Engineering Standard.
ABR
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 52 of 116
6.1.1. Structuring and standardisation of data
Each requirement documented in accordance with DMS-SD-563 Requirements Schema and Specification, must be classified using Uniclass 2015 codes to the levels specified in Table 28 and Table 29, as a minimum and aligned with the PDS.
Table 28: Minimum Location Classification Requirements (Uniclass 2015)
TRACC Integrated Design Review Co En SL
3 Concept Design Development Co_xx
and
En_xx
and / or
SL_xx
4 Systems Breakdown Review Co_xx_xx En_xx_xx SL_xx_xx
Preliminary Design Review Co_xx_xx En_xx_xx SL_xx_xx
Detailed Design Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx
Final Design Review
5 Final Specification Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx
As Built Review
Table 29: Minimum Asset Classification Requirements (Uniclass 2015)
TRACC Integrated Design Review EF Ss Pr
3 Concept Design Development EF_xx
and
Ss_xx
and
As required
4 Systems Breakdown Review EF_xx_xx Ss_xx_xx As required
Preliminary Design Review EF_xx_xx Ss_xx_xx_xx Pr_xx_xx
Detailed Design Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx
Final Design Review
5 Final Specification Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx
As Built Review
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, must 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 must be discussed and a resolution agreed with the TfNSW DE Manager before being used on TfNSW projects.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 53 of 116
6.1.3. Verification and validation
Prior to submission to Integrated Design Reviews, TfNSW will 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 must 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 the 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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 54 of 116
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, including:
o Topographical surveys, which measures existing features and the elevation of points on an area of land
o Cadastral surveys, which establishes, or re-establishes, the boundaries of an area of land using a legal description
o Engineering surveys, which establishes the existence, physical condition and structural stability of an area, including surveys of structures, buildings, utilities and the environment, capturing either surface or sub-surface features, or both
• 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, including construction verification and change detection
• Measured surveys – surveys to document existing assets, capturing both graphical and non-graphical information
• 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 10 shows the typical application of different types of surveys across the TfNSW asset lifecycle phases.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 55 of 116
Figure 10: 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 30 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 30: 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)
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 56 of 116
Type Description
Guidance Specifications, guides and manuals informing survey requirements, including:
DMS-FT-493 Utility Schema and Specification
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 (3.2. CADD Manual Surveying)
TfNSW Geospatial Datum Modernisation Policy (CP20001)
TfNSW Geospatial Modernisation Guiding Principles
Technical Direction Surveying – Implementation of revised Geocentric Datum of Australia (GDA) GDA2020 (SVTD 2019/01 / RMS.19.1346)
GDA94 Technical Manual GDA2020 Technical Manual
TfNSW has adopted GDA2020 as the standard datum for all spatially referenced data from 1 January 2020. For further information on adoption of GDA2020 consult the guidance documents referenced in Table 30.
Deliverables must comply with the existing domain specific survey standards, which must be defined in the contract 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 CAD – survey results can be supplied as 2D CAD files or 2D string model, which from a DE perspective may limit the usability of the information supplied, but are useful for traditional mapping activities
• 3D CAD – survey results can be delivered as 3D CAD files or 3D string model. 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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 57 of 116
• 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
• 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 31 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 31: 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 CAD Y Y Y Y Y Y Y Y Y
3D CAD 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.
6.2.1. Structuring and standardisation of data
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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 58 of 116
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 the 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 must 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 must comply with DMS-FT-493 Utility Schema and Specification and AS 5488:2019 - Classification of Subsurface Utility Information (SUI), as well as discipline classification as outlined in Section 4.2.3
Surveys of roads including road-bridges must comply with the classification requirements outlined in QA Specification G73 – Detail Survey
Survey strings must 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 a conflict between different standards and requirements due to the multi-mode nature of the project the Rail standard requirements take precedence, unless otherwise agreed with TfNSW.
6.2.2. Review of existing data
Existing survey data and information provided is to be reviewed for relevancy to the project. Where existing survey information is to be utilised as a part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant. Projects must also confirm relevancy and applicability of existing survey data with the appropriate TfNSW surveyor.
When reviewing existing data note that all infrastructure projects currently underway are to maintain the previously set construction datum (i.e. GDA94 or ISG 66 for certain rail alignment projects), unless it is cost effective to convert them to GDA2020. For all infrastructure projects currently underway but with future stages about to commence design, GDA2020 should be used for the future stage, unless the future stage designs must be spatially integrated with an earlier project stage. For further information consult the GDA2020 guidance documents referenced in Table 30.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 59 of 116
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.
6.2.4. File submission format
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 is provided in DMS-SD-142 Digital Engineering Survey Requirements Guide. TfNSW project teams must specify their project-specific requirements, based on the project objectives, in the contract.
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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 60 of 116
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 drawing information for projects to submit at each Integrated Design Review. The CAD standards to be adopted are as specified in the contract CAD requirements and to be read in conjunction with the Project DEXP.
To maintain the integrity of the information, as a minimum, the following process must be implemented when producing 2D CAD deliverables.
• For consistency, all 2D and 3D CAD data must be derived from the BIM Models as required by TfNSW (refer to Section 6.4).
• There must only be one drawing sheet per drawing number as a drawing file output.
• Drawings must have reference files (eg Xref) unbound (dwg or dgn) to form part of the submission in accordance with the contract CAD requirements.
• Where linear assets are represented, the native 3D model remains the source of true geometry and alignment. A LandXML or native file format of the alignment must be included as part of CAD submissions to assist in maintaining the integrity of the geometry.
• All drawings must be identified using the unique file metadata tagging as described in Table 4 for upload to the ECM.
• 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.
Where a project is delivered in compliance with this DES, at a minimum CAD deliverables must be submitted in accordance with the contract CAD requirements. Where the DE requirements specified in this DES do not comply with the TfNSW CAD standards, a concession/departure has been agreed with TfNSW stakeholders.
The CAD deliverables required are as per the project contract and in accordance with Table 32, noting the DE Specific Requirements included in Section 6.3.1. Submission of CAD deliverables is to be in accordance with the requirements of the contract and documented in the Project DEXP.
Table 32: CAD submissions
TRACC Integrated Design Review
Document Status at Submission Milestones
Description/Purpose
3 CDD Concept Design Drawing
Initiation of communicating design intent for a project.
4 SBR - -
PDR Preliminary Design Drawing
Used for capturing design intent, to assist in high level decision making and cost-estimation for tendering.
DDR Detailed Design Drawing
Completed drawings for submission to TfNSW for certification.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 61 of 116
TRACC Integrated Design Review
Document Status at Submission Milestones
Description/Purpose
FDR Approved for Construction Drawing
Certified by TfNSW for construction.
5 FSR Red-line mark-ups Used to capture any changes that have occurred during construction. Used as an interim reference prior to completion of As Built drawings.
ABR As Built Drawing A record of the completed works
6.3.1. Drawing titleblock
The requirements for the DE drawing titleblock must comply with the procedure explained in the following sections. The fields and format have been based on TfNSW CAD requirements and modified to enable digital ways of working, including alignment with both Project DEXP and ECM requirements in Section 3.3. Any variations on the drawing titleblock must be agreed with TfNSW and the project team before proceeding.
DMS-FT-549 DE Title Block Standard Format A1 H_Typical provides the approved TfNSW DE drawing sheet templates, which includes amendment of the following five components:
• drawing details box
• sign-off box
• amendment box
• cover sheet details
• drawing frame details.
Refer to Table 33, Table 35, Table 36, Table 38 and DMS-FT-562 CAD Schema and Specification for additional DE data standardisation requirements. All data entry fields in the five components are attributes included as part of ECM metadata and BIM Models.
The TfNSW attributes naming must be adopted unless otherwise agreed with the TfNSW DE Manager to suit the different authoring software platform. The additional metadata fields enable the setup of DE projects in the 3D information modelling environment and achieve consistency and alignment with TfNSW CAD requirements.
The following terms and definitions are used in this standard:
• design company as the design company responsible for carrying out the design and drawing content on the drawing
• engineering company designated the Principal Design Party (AEO, lead designer or internal TfNSW authoriser) responsible for the design on the drawing.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 62 of 116
6.3.1.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 11 shows the different fields in the drawing details box.
Figure 11: Drawing details box on a typical TfNSW Digital Engineering drawing sheet
Table 33 provides the details of the fields in the drawing details box at the time of publication of this Standard. Refer to DMS-FT-549 and DMS-FT-562 CAD Schema and Specification for the current specification and further details.
Table 33: Drawing details box – Digital Engineering attributes description
Ref Field Name Business Definition Attribute
1 Asset location description
A description of the location, governed by SER.
tbLocality
2 Corridor and kilometrage
Corridor and kilometrage reference as per T MU MD 00006 ST Engineering Drawings and CAD Requirement for rail projects, or road number and name for road projects
tbLine
3 Job description detail 1
Project description. Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbDetail1
4 Job description detail 2
Design work package name. Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbDetail2
5 Drawing type Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbDetail3
6 Drawing details/ Chainage range
Optional field used to provide extra drawings details or chainage range
tbDetail4
7 Drawing set number
Allocated drawing registeration number used by the Plan Management Centre (roads)
tbDrawingSetNo
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 63 of 116
Ref Field Name Business Definition Attribute
8 Part number The drawing Part number used to subdivide the drawing packages to support delivery phase, leave blank if not required
tbPartNo
9 Sheet number Refer T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbSheetNo
10 Total number of sheets
Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbOfSheets
11 Sheet size Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbSheetSize
12 Document purpose
Indicate the status of the drawing related to the project milestone stage
tbStatus
13 Bridge number The Bridge number used by road bridge as a reference required for O&M phase, leave blank if not required. To obtain a new Bridge number please check with the TfNSW Project Team.
tbBridgeNo
14 Design company document number
The document number include the Project Contract code, Organisation code, Location or Sub-Location code, Discipline or Sub-Discipline code, Document type and Drawing Serial number.
tbAEODrgNo
15 Project contract Code
The Project Contract Code is a key that identifies a logical contract on a project.
TfNSW_ProjectContractCode
16 Contracted organisation code
AEO or Engineering Company Code for the organisation responsible for the documents. The unique company code is provided by TfNSW document control.
TfNSW_ContractOrgCode
17 Asset location code (L1)
A sub-set of all Asset Location Codes. This sub-set if limited to all Level 1 locations as defined by the project.
TfNSW_AssetLocationCodeL1
18 Asset location code (L2)
A sub-set of all Asset Location Codes. This sub-set if limited to all Level 2 locations as defined by the project.
TfNSW_AssetLocationCodeL2
19 Asset location code (L3)
A sub-set of all Asset Location Codes. This sub-set if limited to all Level 3 locations as defined by the project.
TfNSW_AssetLocationCodeL3
20 Discipline code Technical or Business Disciplines Code that is controlled by the MDBB.
TfNSW_DisciplineCode
21 Sub-discipline code
Related Technical or Business Sub-disciplines Code that is controlled by the MDBB.
TfNSW_SubDisciplineCode
22 Document type code
A unique code for identifying a specific type of document.
TfNSW_DocumentTypeCode
23 Serial number Six digit serial number which, when concatenated with the rest of the document number, results in a unique document number.
TfNSW_SerialNo
24 Design company revision
Indicate the design company revision level related to the design company document number.
tbAEORevNo
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 64 of 116
Ref Field Name Business Definition Attribute
25 Design company version
Indicate the design company version level.
tbAEOVerNo
26 ASA VPR discipline code
A SER allocated discipline code used in the Virtual Plan Room repository.
tbVPRDisciplineCode
27 EDMS ID A SER allocated document identifier that is mapped to a project document.
tbEDMSID
28 EDMS amendment level
Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbAMDNo
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’, the information shall conform to the following principles:
• Drawing titles shall be correct, comprehensive and compliant with the formats indicated
• Abbreviations or codesshall be used in accordance with the ECM metadata or ones that are explained on the drawing using common construction abbreviations (for example, LV, HV and FE)
• The drawing title shall contain specific information about the content of the drawing. After a drawing is submitted to the SER VPR (where applicable), the drawing title shall not be modified in future amendments.
The Design company (Contractor) revision field in the drawing details box shall be in alignment with the latest revision attribute in the Amendment box and numbering as per Section 3.3.5.
As a minimum, all DE projects shall conform to the following principles:
• All drawing deliverables shall include both Design company revision and version number information when issued to TfNSW
• The revision number shown in the drawing titleblock must match the TfNSW ECM tool revision number when issued to TfNSW
• The Design company 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.
Table 34: Examples of Revision and Version number at various project phases
Contractor Virtual Plan Room
REV VER Description Submission AMD No.
A 0 ISSUED FOR CONCEPT DESIGN DEVELOPMENT
Not Req. Blank ()
A 1 ISSUED FOR COORDINATION Not Req. Blank ()
B 0 ISSUED FOR PRELIMINARY DESIGN REVIEW Not Req. Blank ()
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 65 of 116
Contractor Virtual Plan Room
REV VER Description Submission AMD No.
00 0 AFC ISSUED BY CONTRACTOR (POST FDR APPROVAL OF DETAILED DESIGN)
Required A
01 0 RE-ISSUED FOR CONSTRUCTION (MINOR DESIGN CHANGES DURING CONSTRUCTION)
Not Req. A
02 0 RE-ISSUED FOR CONSTRUCTION (POST FDR APPROVAL FOR MAJOR DESIGN CHANGES)
Required B
98 0 AS BUILT ISSUED BY CONTRACTOR (POST ABR APPROVAL)
Required C
99 0 AS BUILT ISSUED BY CONTRACTOR (POST DEFECTS LIABILITY PERIOD APPROVAL)
Not Req. C
Where required by TfNSW, all rail drawings lodged and uploaded to VPR, the VPR discipline code, EDMS ID and AMD number fields shall be filled in and information maintained throughout the required submissions. All road drawings lodged to the Plan Management Centre must including the Drawing Registeration Number (Drawing Set Number) and the metadata spreadsheet as per Section 6.3.6.
6.3.1.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 12 shows the different fields in the sign-off box.
Figure 12: Sign-off box on a typical TfNSW Digital Engineering drawing sheet
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 66 of 116
Table 35 provides the details of these fields at publication time of this Standard. 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 the current specification and further details.
Table 35: Sign-off box – Digital Engineering attributes description
Ref Field Name Business Definition Attribute
1 AEO engineering company name
The AEO engineering company name. tbAEOSuppName
2 Design company name
The Design company name is confirmed with TfNSW document control and is associated to the Design company code.
tbDesignCompName
3 Discipline description The Discipline or Subdiscipline description. tbDiscipline
4 Branch name The Branch name within TfNSW whom the drawing has been prepared for.
tbBranchName
5 Section name The Section name within TfNSW whom the drawing has been prepared for.
tbSectionName
6 Department name The Department name within TfNSW whom the drawing has been prepared for.
tbDepartmentName
7 Drawn by (Name) Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbDrwnName
8 Drawn date Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbDrwnDate
9 Designed by (Name) Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details
tbDsnName
10 Designed date Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbDsnDate
11 Drawing checked by (Name)
Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbDrgChkName
12 Drawing checked date
Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbDrgChkDate
13 Design checked by (Name)
Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbDsnChkName
14 Design checked date Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbDsnChkDate
15 Project/Design Manager (Name)
The full name of the contractor’s Project or Design Manager.
tbProjDsnMngrName
16 Project/Design Manager date
Date of sign-off by the contractor’s Project or Design Manager.
tbProjDsnMngrDate
17 Approved by (Name) Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbApprName
18 Approved date Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbApprDate
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 67 of 116
6.3.1.3. Amendment box
The amendment box records the details of all amendments made to a drawing. The amendment details include the Design company’s amendment level and description along with the initials of the designer, verifier and the approver.
The ‘REV’ column records the Design company revision levels of the drawing. Refer to Section 3.3.5 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 13 shows the different fields in the amendment box.
Figure 13: Amendment box on a typical TfNSW Digital Engineering drawing sheet
Table 36 provides the details of these fields at publication time of this Standard. All data entry fields in the amendment box are included as attributes. Refer to DMS-FT-562 CAD Schema and Specification for the current specification and further details.
Table 36: Amendment box – Digital Engineering attributes description
Ref Field Name Business Definition Attribute
1 Scale Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbScale
2 Design lot code Option field used by the contractor to support delivery phase, leave blank if not required.
tbDesignLotCode
3 Co-ordinate system
Identify the survey coordinate system being used for the project, including first Geocentric Datum of Australia (GDA) information and Map Grid of Australia (MGA).
tbCoordSys
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 68 of 116
Ref Field Name Business Definition Attribute
4 Height datum Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbHghtDatum
5 Amendment level Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbAEORevNo
6 Amendment description
Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbAMDDesc
7 Amendment designer initial and date
Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbAMDDsgnSD
8 Amendment verifier initial and date
Refer to T MU MD 00006 ST Engineering Drawings and CAD Requirement for further details.
tbAMDVerSD
9 Amendment approver initial
The initials of the person who approved the amendment.
tbAMDApprSign
10 Amendment approver date
The amendment date the drawing is approved and signed.
tbAMDApprDate
6.3.1.4. 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 37 at publication time of this Standard. Refer to DMS-FT-562 CAD Schema and Specification for current specification and further details.
Table 37: Drawing frame details – Digital Engineering attributes description
Ref Field Name Business Definition Attribute
1 Security Classification Description
As per 'NSW Government Information Classification, Labelling and Handling Guidelines'. Refer to FT-549 DE title block for position.
TfNSW_SecurityClassificationDesc
2 Model reference
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. Refer to FT-549 DE title block for position.
tbModelReference
3 Suitability description
The Suitability Description is the description of the State and Suitability Code assigned to a document when sharing. The Suitability Description value is governed by TfNSW.
TfNSW_SuitabilityDesc
6.3.1.5. 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,at publication time of this Standard, should include and not limited to the following shown in Table 28. Refer to DMS-FT-562 CAD Schema and Specification for the current specification and further details.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 69 of 116
Table 38: Cover sheet details – Digital Engineering attributes description
Ref Field Name Business Definition Attribute
1 Program name The Program Name. TfNSW_ProgramName
2 Work package code (Construction)
A unique code generated for a Construction Work Package created for the project at the Construction stage. The Construction Work Package Codes are generated within the PDBB.
TfNSW_WPConstructionCode
3 Work package name (Construction)
The Work Package Name (Construction) field is to be populated for Work Packages relating to Construction packages of work.
TfNSW_WPConstructionName
4 Work package code (Design)
A unique code generated for a Design Work Package created for the project at the Design stage. The Design Work Package Codes are generated within the PDBB.
TfNSW_WPDesignCode
5 Work package name (Design)
The Work Package Name (Design) field is to be populated for Work Packages relating to Design packages of work.
TfNSW_WPDesignName
6.3.2. 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 39.
CAD layer names = [Discipline] + [Classification] + [Presentation] + [Description]
Table 39: 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
6.3.2.1. Discipline
For 2D CAD artefacts, mapping layers are required to meet with DE-defined disciplines as denoted in the project CAD Schema and Specification (based on DMS-FT-562) and follow the principles established in Section 4.2.3 under Discipline classification and referencing.
6.3.2.2. Classification
All asset information shall be classified based on the nominated classification system as denoted in Section 4.2. The Classification field shall form part of the layer names as required at the Integrated Design Review stage, refer to Table 40. The Uniclass 2015 table for CAD
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 70 of 116
(Zz) is applicable to drawing-related items at all stages. This may vary from one Integrated Design Review to another.
Table 40: Asset Classification Requirements for CAD layers
TRACC Integrated Design Review Ss
EF
3 Concept Design Development Ss_xx
or
EF_xx
4 Systems Breakdown Review Ss_xx_xx EF_xx_xx
Preliminary Design Review Ss_xx_xx_xx EF_xx_xx
Detailed Design Review Ss_xx_xx_xx_xx EF_xx_xx
Final Design Review
5 Final Specification Review Ss_xx_xx_xx_xx EF_xx_xx
As Built Review
6.3.2.3. Presentation
The Presentation code shall be from Section 12.2 of BS1192:2007 and as per Table 41. This ensures that the information can still be re-used for a variety of presentation purposes without conflicting with re-use of information.
Table 41: Standard Codes for Presentation (PAS 1192: 2007)
Ref Code Description
1 D Dimensioning
2 H Hatching and Shading
3 M Model related elements
4 P Plot/paper related elements
5 T Text
6 X Existing
6.3.2.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 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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 71 of 116
6.3.3. Composite models
Where a project is required to deliver a ‘composite model’ or similar, compliance with this DES enables a composite model to be in the format of a Federated Model in the project deliverables.
The Federated Model should be submitted in the format specified in Section 6.4 showing the extent of the design. The files should not be password protected or have an expiry date set and all native models shall be included as part of the submission in their original file format.
6.3.4. Review of existing data
Existing data and information are to be reviewed for relevancy to the project. Where existing CAD information is to be utilised as a part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant.
6.3.5. Validation
All 2D CAD deliverables produced during the project will be validated at key milestones of the project, in alignment with the MIDP, MPDT, ECM Schema and Specification, CAD Schema and specification, and CAD layering naming table, as documented within the Project DEXP and the project CAD requirements.
6.3.6. File submission format
All 2D CAD deliverables must be submitted in the following formats with each of the native authoring software version agreed with TfNSW and documented in the Project DEXP.
1. Drawing image file
.pdf format (singular)
.pdf format (combined file adopting a 999999 serial number in the document number)
Vector
2. Drawing CAD file
Either. dgn or .dwg formats
Unbound
One drawing sheet per drawing number as a drawing file output, multiple drawings in the one file will not be accepted unless agreed with TfNSW DE manager and VPR (where applicable)
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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 72 of 116
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.3.6.1. Metadata spreadsheet
The DE drawing titleblock (refer to DMS-FT-549) includes metadata fields that support the data exchange for the ECM and TfNSW document repositories.
A metadata spreadsheet must be provided with each drawing submission, the spreadsheet can be generated from the nominated CDE or ECM tool, or extracted from the drawing to include the attribute names and values listed in Table 33, Table 35, Table 36 and Table 37 at a minimum.
For Rail projects, T MU MD 00006 F1 Metadata Spreadsheet for Engineering Drawings must be used by the Contractor for providing titleblock 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 F1 Metadata Spreadsheet for Engineering Drawings for further details.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 73 of 116
6.4. BIM deliverables
The BIM deliverables are required to be submitted for appropriate Integrated Design Reviews. The submission requirement for each Integrated Design Review is shown in Table 42.
Unless otherwise stated in the contract, each submission shall include:
String Model(s)
Individual discipline BIM Model(s)
Individual IFC Models
Federated Model(s)
A clash detection report
A Model Validation Certificate (DMS-FT-556)
A Contractor facilitated model review workshop.
These requirements are further described in the following sections.
Table 42: BIM Model Submissions
TRACC Integrated Design Review
Model Type Description/Purpose Submission Requirement
3 CDD Concept Design Model
Initiation of communicating design intent for a project in the form of BIM Models.
The frequency of model submissions during the concept design phase is specified in the project contract.
ECM tool
4 SBR NA - -
PDR Preliminary Design Model
Models used for capturing Design Intent and assist in high level decision making.
The frequency of model submissions during the preliminary design phase is specified in the project contract.
ECM tool
DDR Detailed Design Model
Models used to assist with both decision-making processes and design coordination.
The frequency of model submissions during the detailed design phase is specified in the project contract.
ECM tool
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 74 of 116
TRACC Integrated Design Review
Model Type Description/Purpose Submission Requirement
FDR Final Design Model
Approved for Construction Model
The Final Design Model is the final TfNSW agreed model produced by the project, submitted to the Sponsor.
When the Final Design Model is agreed with the Sponsor, it is marked ‘Approved For Construction’. The BIM Model(s)/ Federated Model must be submitted to TfNSW before construction can commence.
ECM tool
5 FSR Approved for Construction Model
Accepted For Construction model updated to reflect the changes of the review, unless otherwise stated in the contract.
ECM tool
Construction Model
Changes are captured progressively throughout construction and updated in the BIM Model as required by the contract.
ECM tool
ABR 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 to compliment 3D laser scan data to verify the installation of already constructed work and record the as built position.
ECM tool
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 included in the Handover Asset Register.
The O&M Model is updated based on information provided by the relevant Contractor (eg digital mark-ups, photography, or laser scans).
ECM tool
6.4.1. BIM process requirements
Terminology used in the production of BIM Models is summarised in Table 43.
Table 43: Building Information Modelling terminology
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 75 of 116
Ref Term Source Description
1 Level of Detail (LoD)
PAS 1192.2 Level of Detail is the amount of geometrical (graphical) information contained in a 3D model.
2 Level of Information (LoI)
PAS 1192.2 Level of Information is the amount of non-geometrical (non-graphical) data embedded within an Information Model or 3D model.
3 Level of Definition
PAS 1192.2 Level of Detail (LoD) together with Level of Information (LoI) is referred to collectively as Level of Definition.
4 Level of Development (LOD)
BIM Forum (2020) Level of Development (LOD) Specification
Used for reference only.
The Contractor is responsible for managing the overall cross discipline BIM collaboration process. To achieve this, each design discipline must model to a minimum Level of Definition sufficient to enable an appropriate level of coordination to take place, as per Table 44. The coordination process shall be developed along with the following principles:
• All spatial information must adopt the same standard datum as detailed in Section 6.2. A local datum can be adopted to accommodate the limitations of some software packages, however all spatial information must be projected from the local datum to the standard datum adopted. Coordinates and setting out details shall be coordinated across the project, using a master project control set out file when using a local datum.
• Information from other contributors shall be referenced directly in the Federated Model during design for clash avoidance.
• All BIM objects must be classified as per the phased requirements specified in Table 47 and Table 48.
• BIM Models must be managed and maintained, removing any superfluous or superseded data before exchanged in the file formats identified in Section 6.4.7.
• 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 must submit BIM Models to TfNSW using the ECM tool, for TfNSW review and comment. Submission must be in accordance with Table 42 and as per project milestones documented in the Project DEXP.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2020 UNCONTROLLED WHEN PRINTED Page 76 of 116
• All Contractors must submit BIM Models in accordance with the Level of Definition requirements outlined in Table 44 unless specific project requirements have been agreed in the Project DEXP.
• 2D drawing deliverables must be derived from the native or 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 must be included in the submission to the ECM.
6.4.1.1. Review of existing data
All or any existing data must 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 must 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 must be discussed and a resolution agreed with the DE Manager before being used on TfNSW projects.
6.4.2. BIM Model requirements
Requirements for geometrical information (LoD) and the non-geometrical information (LoI) inclusion in the individual discipline BIM Model(s) and Federated Model is specified in the following sections.
TfNSW and the Contractor shall agree and specify any project specific requirements, departing from the baseline requirements specified below. The Level of Definition for all technical disciplines and asset types for each project phase must be documented in the Project Model Production Delivery Table (based on DMS-FT-534 Model Production Delivery Table (MPDT) Template).
6.4.2.1. Levels of Detail (LoD)
Refer to Table 44 for examples and descriptions of LoD for each project phase. Baseline LoD requirements are given for each technical discipline and phase in Table 45. Refer to Appendix B for further examples.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 77 of 116
Table 44: Levels of Detail examples and descriptions
Integrated Design Review
CDD SBR, PDR DDR, FDR, FSR, ABR
If required by the project contract
LoD (PAS 1192.2)
2 3 4
- 5 6
LOD (BIM Forum)
LOD 100 LOD 200 LOD 300
LOD 350 LOD 400 LOD 500
Geometric Representation (Building Specific) (BIM Forum)
Geometric Representation (Infrastructure Specific) (PAS 1192_2)
Description (PAS 1192_2)
(**BIM Forum)
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.
**The Model Element is graphically represented within the Model as a specific system, object, or assembly in terms of quantity, size, shape, location, orientation, and interfaces with other building systems. Non-graphic information may also be attached to the Model Element.
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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 78 of 116
Table 45: TfNSW Baseline Levels of Detail by Technical Discipline
Model Type
Concept
Desig
n
Mode
l
Pre
limin
ary
Desig
n M
ode
l
Deta
iled
Desig
n M
ode
l
Appro
ve
d F
or
Constr
uction
Mode
l
Constr
uction
Mode
l
As-B
uilt
Mod
el
O&
M M
ode
l
Integrated Design
Review CDD PDR DDR/FDR FSR ABR
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 300 4
Communication CO 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Civil CV 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Electrical EL 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Fire FE 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Fleet Systems & Equipment
FL 100 2 200 3 300 4 300 4 300 4 300 4 300 4
General GN 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Hydraulic HY 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Mechanical ME 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Signalling & Control
SG 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Structural (no reinforcing)
ST 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Structural (with reinforcing)
ST 100 2 200 3 350 - 350 - 350 - 350 - 350 -
Technology TE 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Utilities UT 100 2 200 3 300 4 300 4 300 4 300 4 300 4
Sub-Discipline*
Geotech GE 100 2 200 3 200 3 200 3 200 3 200 3 200 3
Landscaping LA 100 2 200 3 200 3 200 3 200 3 200 3 200 3
Temporary Works TW 100 2 200 3 200 3 200 3 200 3 200 3 200 3
*where the requirement differs from the parent discipline
6.4.2.2. Levels of Information (LoI)
The contractor must ensure the BIM Model(s) is populated with the model properties requirements following, noting the required attributes to comply with the TfNSW IFC properties and property sets, as defined in the BIM Schema and Specification (DMS-FT-516). The model properties must be populated with the individual elements contained within the BIM Model(s) as object attributes (metadata).
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 79 of 116
6.4.2.3. Model properties requirements
To comply with TfNSW data requirements, the Contractor must comply with the property requirements specified in the Project DEXP and DMS-FT-516 BIM Schema and Specification. Refer to Table 46 for the FDR stage property requirements, at the time of publication of this Standard. Refer to the latest version of DMS-FT-516 BIM Schema and Specification for current requirements.
TfNSW may include project-specific requirements in the contract. The contractor may also elect to include additional attributes within the BIM Model to aid in delivery. These additional attributes should be included within a discipline or subdiscipline IFC Property Set they belong to, prefixed with TfNSW ie TfNSW_Utilities or TfNSW_Temporary_Works.
Table 46: Model Properties Requirements
Ref Model or Object
Property Data Dictionary Field Name
FDR Inclusion
IFC Property Set
Attribute Name
1 Model Project And Contract Name Mandatory TfNSW_Project TfNSW_ProjectAndContra
ctName
2 Model Project Contract Code Mandatory TfNSW_Project tbProjectContractCode
3 Model AEO Engineering Company Code Mandatory TfNSW_Project tbAEOSuppCode
4 Model AEO Engineering Company Name Mandatory TfNSW_Project tbAEOSuppName
5 Model Design Company Code Conditional TfNSW_Project tbDesignCompCode
6 Model Design Company Name Conditional TfNSW_Project tbDesignCompName
7 Model Co-ordinate System Mandatory TfNSW_Project tbCoordSys
8 Model Project Milestone Description Mandatory TfNSW_Project TfNSW_ProjectMilestoneD
esc
9 Model State Description Mandatory TfNSW_Project TfNSW_StateDesc
10 Model Suitability Description Mandatory TfNSW_Project TfNSW_SuitabilityDesc
11 Model Document Number Mandatory TfNSW_Project TfNSW_DocumentNo
12 Model Document Title Mandatory TfNSW_Project TfNSW_DocumentTitle
13 Model Discipline Code Mandatory TfNSW_Project tbAEODisciplineCode
14 Model Sub-discipline Code Conditional TfNSW_Project tbAEOSubDiscCode
15 Object TfNSW Asset Location ID Optional TfNSW_Location TfNSW_AssetLocationID
16 Object TfNSW Parent Asset Location ID Conditional TfNSW_Location TfNSW_ParentAssetLocati
onID
17 Object Project Asset Location ID Mandatory TfNSW_Location TfNSW_ProjectAssetLocati
onID
18 Object Parent Project Asset Location ID Conditional TfNSW_Location TfNSW_ParentProjectAsse
tLocationID
19 Object Asset Location Code Mandatory TfNSW_Location TfNSW_AssetLocationCod
e
20 Object Parent Asset Location Code Conditional TfNSW_Location TfNSW_ParentAssetLocati
onCode
21 Object Asset Location Description Mandatory TfNSW_Location TfNSW_AssetLocationDes
c
22 Object Uniclass 2015 Asset Location Code Mandatory TfNSW_Location TfNSW_UniclassAssetLoc
ationCode
23 Object Uniclass 2015 Asset Location Title Mandatory TfNSW_Location TfNSW_UniclassAssetLoc
ationTitle
24 Object Work Zone Code Optional TfNSW_Location TfNSW_WorkZoneCode
25 Object Work Zone Name Optional TfNSW_Location TfNSW_WorkZoneName
26 Object Uniclass 2015 Asset Location Code (Complex)
Optional TfNSW_Location Uniclass_CoCode
27 Object Uniclass 2015 Asset Location Title (Complex)
Optional TfNSW_Location Uniclass_CoTitle
28 Object Uniclass 2015 Asset Location Code (Entity)
Optional TfNSW_Location Uniclass_EnCode
29 Object Uniclass 2015 Asset Location Title (Entity)
Optional TfNSW_Location Uniclass_EnTitle
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 80 of 116
Ref Model or Object
Property Data Dictionary Field Name
FDR Inclusion
IFC Property Set
Attribute Name
30 Object Uniclass 2015 Asset Location Code (Space)
Optional TfNSW_Location Uniclass_SLCode
31 Object Uniclass 2015 Asset Location Title (Space)
Optional TfNSW_Location Uniclass_SLTitle
32 Object TfNSW Asset ID Optional TfNSW_Asset TfNSW_AssetID
33 Object TfNSW Parent Asset ID Conditional TfNSW_Asset TfNSW_ParentAssetID
34 Object Project Asset ID Mandatory TfNSW_Asset TfNSW_ProjectAssetID
35 Object Parent Project Asset ID Conditional TfNSW_Asset TfNSW_ParentProjectAsse
tID
36 Object Asset Data Standard Mandatory TfNSW_Asset TfNSW_AssetDataStandar
d
37 Object Asset Type Code Mandatory TfNSW_Asset TfNSW_AssetTypeCode
38 Object Asset Instance Mandatory TfNSW_Asset TfNSW_AssetInstance
39 Object Asset Code Mandatory TfNSW_Asset TfNSW_AssetCode
40 Object Parent Asset Code Conditional TfNSW_Asset TfNSW_ParentAssetCode
41 Object Asset Description Mandatory TfNSW_Asset TfNSW_AssetDescription
42 Object Asset Label Mandatory TfNSW_Asset TfNSW_AssetLabel
43 Object Uniclass 2015 Asset Code Mandatory TfNSW_Asset TfNSW_UniclassAssetCod
e
44 Object Uniclass 2015 Asset Title Mandatory TfNSW_Asset TfNSW_UniclassAssetTitle
45 Object Asset Type Configuration Code Optional TfNSW_Asset TfNSW_AssetTypeConfig
Code
46 Object Asset Type Configuration Description Optional TfNSW_Asset TfNSW_AssetTypeConfig
Desc
47 Object Discipline Code (Object) Mandatory TfNSW_Asset TfNSW_DisciplineCode
48 Object Sub-discipline Code (Object) Conditional TfNSW_Asset TfNSW_SubDisciplineCod
e
49 Object Work Package Code (Design) Mandatory TfNSW_Asset TfNSW_WPDesignCode
50 Object Work Package Code (Supply) Optional TfNSW_Asset TfNSW_WPSupplyCode
51 Object Work Package Code (Construction) Optional TfNSW_Asset TfNSW_WPConstructionC
ode
52 Object Work Package Code (Commissioning) Optional TfNSW_Asset TfNSW_WPCommissionin
gCode
53 Object Asset Status Code Mandatory TfNSW_Asset TfNSW_AssetStatusCode
54 Object Asset Owner Organisation Name Mandatory TfNSW_Asset TfNSW_AssetOwnerOrgN
ame
55 Object Asset Operator Organisation Name Optional TfNSW_Asset TfNSW_AssetOperatorOrg
Name
56 Object Asset Maintainer Organisation Name Optional TfNSW_Asset TfNSW_AssetMaintainerOr
gName
57 Object Start km Mandatory TfNSW_Asset TfNSW_StartKm
58 Object End km Conditional TfNSW_Asset TfNSW_EndKm
59 Object GPS Coordinates Conditional TfNSW_Asset TfNSW_GPSCoordinates
60 Object Uniclass 2015 Asset Code (Element Function)
Optional TfNSW_Asset Uniclass_EFCode
61 Object Uniclass 2015 Asset Title (Element Function)
Optional TfNSW_Asset Uniclass_EFTitle
62 Object Uniclass 2015 Asset Code (System) Optional TfNSW_Asset Uniclass_SsCode
63 Object Uniclass 2015 Asset Title (System) Optional TfNSW_Asset Uniclass_SsTitle
64 Object Uniclass 2015 Asset Code (Product) Optional TfNSW_Asset Uniclass_PrCode
65 Object Uniclass 2015 Asset Title (Product) Optional TfNSW_Asset Uniclass_PrTitle
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 81 of 116
6.4.2.4. 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 47 and Table 48.
Table 47: Minimum Location Classification Requirements (Uniclass 2015)
TRACC Integrated Design Review Co En SL
3 Concept Design Development Co_xx
and
En_xx
and / or
SL_xx
4 Systems Breakdown Review Co_xx_xx En_xx SL_xx
Preliminary Design Review Co_xx_xx En_xx_xx SL_xx_xx
Detailed Design Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx
Final Design Review
5 Final Specification Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx
As Built Review
Table 48: Minimum Asset Classification Requirements (Uniclass 2015)
TRACC Integrated Design Review EF Ss Pr
3 Concept Design Development EF_xx
and
Ss_xx
and
As required
4 Systems Breakdown Review EF_xx_xx Ss_xx_xx As required
Preliminary Design Review EF_xx_xx Ss_xx_xx_xx Pr_xx_xx
Detailed Design Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx
Final Design Review
5 Final Specification Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx
As Built Review
TfNSW requires that, minimally, one location classification and one asset classification must be attributed to each modelled object, to the System level for CDD and SBR and to the Product level from PDR to ABR.
6.4.3. Utility information
6.4.3.1. Utility validations
The contractor must review, update and validate any existing utility information provided to them, including geometrical and non-geometrical information using DBYD, surveyed ground features, electromagnetic survey, potholing and other relevant information to ascertain the quality of the utility information provided for use during the design. The contractor must advise TfNSW of any additional utility survey required to complete the design.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 82 of 116
6.4.3.2. Utility model
In addition to Section 6.4.2.1, the Contractor must create a BIM Model of all existing and proposed subsurface and surface utility model based on the survey, Dial Before You Dig (DBYD) and other relevant information. The utility model must be geometrically accurate in terms of quantity, size, shape, location and orientation, and to the Level of Definition defined within this specification.
6.4.3.3. Utility attributes & accuracy
The Contractor must apply attributes to all existing and proposed subsurface and surface utilities including owner, type, size, status, material, configuration, quality level etc as per the DMS-FT-516 Utility Schema and Specification and AS 5488.2:2019 Part 2: Subsurface Utility Engineering Requirements. These attributes should supplement the LoI requirements in Section 6.4.2.2 and must be included in the Federated Model for ease of reference and to support clash detection analysis and 4D construction simulation (if applicable).
The utility attributes must be included in an IFC Property Set named TfNSW_Utilities with the attribute names and values aligned with the Utility Schema and Specification.
Where the quality level of a utility is unknown then it must be labelled Quality Level D. If there is no accompanying metadata with the utility information, then Quality Level “D” must be assumed for that utility. Refer to Appendix A of AS 5488.1:2019 Part 1: Subsurface Utility Information for the quality level definitions. Quality Level D information should not be draped to the surface and assumed or typical depths applied to create the 3D model.
6.4.3.4. Utility Investigation Information
The Contractor must spatially provide utility investigation information in the Federated Model and identified by a symbol or flag and labelled with the utility pothole or trench reference number and its type as per the Utility Schema and Specification (ie “C” for Communications, “E” for electricity, “W” for Water etc).
6.4.4. Model federation
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 BIM 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 must be defined, implemented and documented within the Project DEXP.
• All BIM Model reviewing software and procedures must be defined, implemented and documented in the Project DEXP.
• A model coordination strategy must be implemented by the Contractor and documented within the Project DEXP.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 83 of 116
• Information exchange procedures must be implemented by the Contractor and documented in the Project DEXP.
• A procedure for recording and communicating changes to BIM Models must be implemented by the Contractor and documented in the Project DEXP.
6.4.5. Clash detection
The Contractor must use the Federated Model to complete clash detection and to ensure the model is clash free. The contractor is required to document their rules based clash detection procedure to be adopted by the project in the Project DEXP for agreement with TfNSW, including how clashes will be managed and prioritised.
The contractor must provide a clash matrix as part of the Project DEXP that includes existing, temporary and design elements to be clash checked and assign priority based on time, cost and impact to resolve the clash. Refer to Section 4 and Appendix D of AS 5488.2:2019 Part 2: Subsurface Utility Engineering Requirements for further guidance on the clash detection process and an example clash matrix for utilities, the same principles can be applied to other elements within the model(s).
Clash detection must consider interference clashes and clearances between objects to meet standard authority requirements and construction methodology, including temporary works, excavation zone of influence and space allocation to safely construct the works. Adopting a hard clashes procedure across the project is not sufficient to ensure the model(s) are clash free and fully coordinated.
The rules based clash detection process, consistent with the agreed clash matrix must be included as part of the Federated Model, with a clash detection report exported from the automated clash detection platform and included with each submission of the Federated Model. All identified clashes should be numbered, with similar clashes within the model(s) grouped, with commentary added to identify how each clash should be addressed and assigned an owner to resolve, clashes that are not ‘real’ must be resolved before submitting the clash report at each submission.
6.4.6. Model reviewing and validation
All BIM data produced shall be validated at key milestones of the project. Data within models must be audited against the information contained within the Project Model Production Delivery Table (MPDT) and the requirements of the BIM Schema and Specification (DMS-FT-516). Any specific model review workflows and processes must 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 Certificate (DMS-FT-556) must be included with model submissions and provided as confirmation that the Contractor has completed an appropriate quality assurance review of the model prior to submission, including confirmation that:
• The BIM Models have the required properties and data as summarised in the Model Property Check (DMS-FT-454).
• The Level of Definition for model elements/disciplines is as agreed with TfNSW
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 84 of 116
• Federation of BIM Models has been appropriately achieved
• Clash detection has been completed
• The models are coordinated
• The model is appropriate for use during the next phase of the project and/or asset lifecycle
• The model data is consistent with the Asset Register data (refer to Section 6.9.1)
• The comments in the project comments register have been addressed
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 must be documented in the Project DEXP, and taking into consideration:
• 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 must produce design review comments which are placed into a comment register in accordance with TfNSW requirements (refer to the project contract). The file format of the register, its location, and structuring of design comments will be at the discretion of TfNSW and agreed with TfNSW DE Manager before being used on TfNSW projects.
6.4.7. File submission format
This section defines mandatory file format requirements. Refer to the Project DEXP for specific BIM Model file formats required by TfNSW.
• 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, 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.
• All BIM Models (IFC and native) and Federated Model(s) must include the model property requirements, as per section 6.4.2.3.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 85 of 116
• String-based models must be submitted in a LandXML format 1.2 or higher to retain true geometry.
• The maximum file-size limit must not exceed 500MB for the individual BIM Models, 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 must be identified using the file naming convention described in Section 3.3 for upload to the ECM tool.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 86 of 116
6.5. Visualisation
TfNSW has 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.
6.5.1. Visualisation requirements
The type of visualisation specified by the project and the requirements for visualisation deliverables are determined based on the project’s scope, DE strategy and opportunities for reuse.
The Visualisation Requirements Guide (DMS-SD-130) may be referred to by the TfNSW project team to assist with the specification of visualisation and utilisation of DE methodology in the Contract and Project DEXP. Visualisation types include but are not limited to:
Proposal communication
Photorealistic artistic impression
Photorealistic photomontage.
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 49.
Table 49: Visualisation deliverables
Ref Required deliverable
Description
1 Visualisation deliverable
The Contractor must provide the visualisation deliverable in a digital file format appropriate to its intended usage and audience, as specified in the Contract and/or 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 must 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 must 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 must 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 must be provided to TfNSW as part of the submitted deliverable. An example of this type of content is image files rendered out of a visualisation package that would then be ‘stitched’ together to form an output animation.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 87 of 116
Ref Required deliverable
Description
6 Material map Where material texture files are used in the visualisation process these must 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 as people, vegetation and vehicles. Where licencing allows this content must be provided to TfNSW as part of the submitted deliverable.
6.5.2. Structuring and standardisation of data
The classification of visualisation data is linked to the intended use as well as the primary domain (rail, roads, maritime, etc. assets) of the project. 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.
6.5.3. Review of existing data
Existing visualisation data and information provided is to be reviewed for relevancy to the project. Where existing visualisation information is to be utilised as a part of the project, this data is to be validated and verified in accordance with this DES, if not already compliant. Projects must also confirm relevancy and applicability of existing visualisation data with the TfNSW project team.
6.5.4. 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.
6.5.5. File submission format
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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 88 of 116
6.6. GIS deliverables
TfNSW is standardising the approach to GIS systems and data management for delivery of projects to drive consistency of the outputs that are delivered and to ensure that all information produced or used in the creation of GIS outputs is handed over for reuse.
GIS has broad application in the Transport environment capable of supporting a range of activities that span the whole asset lifecycle, including:
Capturing existing conditions, including environmental conditions, demographic information, topology, etc.
Supporting site analysis and modelling, including environmental impact assessments, flood modelling, etc.
Enabling design integration, including embedding and evaluating 3D design models within existing condition GIS models
Supporting design reviews, for example through federation of 3D design models with other GIS datasets
Collating and reporting sensor data, for example providing live monitoring of air quality and noise levels through streaming of sensor data into a spatially enabled GIS model
Collating As Built models and information, which can then be made available to other Transport stakeholders, e.g. Operations & Maintenance.
Depending on specific project requirements Contractors may be required to provide GIS data deliverables as well as access to the Contractor’s GIS Application.
6.6.1. GIS requirements
The TfNSW QA Specification G75 – Geographic Information Systems (GIS), outlines the requirements for undertaking GIS work, including:
General requirements, such as identification of key GIS personnel and management of third-party software licencing arrangements
Technical requirements, which covers file formats, naming conventions, metadata and dataset level schema requirements. The specification also identifies requirements for cartographic products, data types, and the coordinate reference systems to be used for GIS
GIS application requirements, which is dependent on whether TfNSW requires access to a Contractor’s GIS application environment
Delivery requirements, including the need for a GIS Management Plan, as well as and requirements for meetings, reporting and submission of GIS deliverables.
QA Specification G75 is structured to align with other requirements of the DES and uses the DE templates DMS-FT-580 – GIS Schema and DMS-FT-581 – GIS Management Plan to facilitate alignment and enable integration with the DES. QA Specification G75 does not define the project scope of GIS activities and deliverables, and these must be defined and agreed with the relevant Contractor. Note that QA Specification G75 may also be used for non-DE GIS projects or activities.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 89 of 116
6.6.2. Structuring and standardisation of data
GIS data, as a minimum, is to be structured and standardised in accordance with:
QA Specification G75 – Geographic Information Systems
DMS-FT-580 – GIS Schema.
Depending on the scope of the project the Contractor may also identify and adopt alignment with other elements of the PDS for the GIS work.
Complying with these requirements will assist project teams to ensure that:
All GIS information, where possible, 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 maintain the relationship between the CAD coordinate system, the map coordinate system and Australian Height Datum (AHD);
The GIS information contains sufficient metadata so that it can be assessed for its fitness for the intended purpose, or its appropriateness for another purpose; and
The GIS information is of a consistent format and can be combined with other GIS information stored in the Transport enterprise systems or the project GIS.
Compliance with G75 will facilitate spatial consistency between different project data sets across TfNSW.
6.6.3. Review of existing data
Existing GIS data and information provided to, or sourced by, a project team is to be reviewed for relevancy to the project. Where existing GIS information is to be utilised as a part of the project, this data is to be validated and verified in accordance with this DES. Contractors must also confirm relevancy and applicability of existing GIS data with the TfNSW project team.
6.6.4. Validation
All GIS deliverables produced during the project will be data validated at key milestones of the project. Validation will be for compliance with:
The requirements of QA Specification G75 – Geographic Information System
The Contractor’s GIS Schema (DMS-FT-580), which is to be submitted with any formal GIS data submission (data drop) to TfNSW
The Contractor’s PDS
The Contractor’s GIS Management Plan (DMS-FT-581), when required
Other contract requirements.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 90 of 116
6.6.5. GIS deliverable submissions
GIS 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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 91 of 116
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 contract or Project 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
(ii) The construction methodology logic and durations are accurate and can be practically delivered.
This DES requires that Contractor’s group activities in their schedules (Work Breakdown Structure (WBS)) 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 (WBS) must be coded with the relevant Work Package Code provided by TfNSW
(refer section 4.2.4 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
the 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. This may
be achieved through manual association or via attribution within the Primavera P6 schedule.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 92 of 116
Both methods of working require alignment of the schedule data with the BIM model attributes,
utilising the project defined Work Packages.
The schedule activities and dates must integrate with the 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 an agreed format, such as
Autodesk Navisworks, Bentley Navigator or Bentley Synchro.
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 contract for details on whether 4D GIS or 4D BIM is required and the
frequency of submissions.
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 a 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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 93 of 116
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 a future 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
contract. This may include DMS-ST-173 Cost Estimating for Infrastructure and Place Projects
and T MU AM 01001 ST Life Cycle Costing.
6.8.1. Structuring and standardisation of data
6.8.1.1. Project cost estimates
The Cost Estimating requirements for DE is currently in development. All parties are required
to conform to existing TfNSW standards and requirements related to project costs, including
the requirement to align the Cost Breakdown Schedule with the WBS (refer to section 6.7).
Requirements may include DMS-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 may align the CBS within the tender/contract payment schedule to the Work Package
Codes in the PDS. Where aligned, 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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 94 of 116
The contract payment schedule must be controlled to align with any changes to the Work
Package Codes agreed with TfNSW, as described in Section 4.2.4. 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 variations 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.
6.8.3. Existing data review
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 DMS-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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 95 of 116
6.9. Asset data deliverables
Asset data deliverables are focused around the structured asset data that is created or captured during a project. This information assists with design development and verification and includes data and information specified by the Asset Information Requirements (AIR), including the O&M asset register (Handover Asset Register). Asset register data may be captured during the project phase within the BIM Model(s) or in the Asset Register template itself (refer to Figure 14).
Handover Asset Register+Asset Information
Asset list and otherasset information
BIM model
Current scope of DE
Is it an MMI?
Yes
Figure 14: Asset Data Development
Asset information, additional to the asset register (asset data), including manuals, certificates, warranties and procedures etc, is specified in the Contract and managed as for other project information, utilising the MIDP. Requirements specific to asset information handover are to be documented in the handover plan, as required by T MU AM 01014 ST Asset Information Handover Requirements and must consider the O&M’s information requirements (AIR), for example as specified in:
Sydney Trains Asset Information Delivery Plan (heavy rail assets)
ILC-GEN-TP0-901 Asset Acceptance Technical Procedure (road and maritime assets)
Bridge Inspection Procedure Manual (road-bridge assets).
To enable the asset information to be linked requires the use of a unique Project Asset ID that is common in the Asset Register, the BIM Model, and other data sets.
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 Integrated Design Reviews. The minimum requirements for the submission of asset information in the form of an asset register are provided in Table 50.
The Level of Information (LoI) to be provided in the Asset Register submission at Integrated Design Reviews is specified in Table 51. The Asset List (AR PDS) attributes must be generated from the BIM Model with additional assets and/or attributes, as specified by TfNSW or the
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 96 of 116
Asset Custodian (eg the asset maintainer), appended and populated to generate the Handover Asset Register (refer to Figure 15).
Key TfNSW Project Team ContractorMaintainer
(eg Sydney Trains)
Project Data
Building Blocks
(PDBB)
BIM Schema
(includes Asset
Register PDS)
Develop the
BIM model(s)
Export the
developed Asset
List as per
DMS-FT-537
Maintainer confirms MMI
and additional attributes
required for the assets
Asset Register
updated with
additional attributes
(appended to Asset
List)
Asset attributes
populated at
optimum time in
the project
Handover to
Maintainer
Figure 15: Handover Asset Register creation (simplified process)
During the Plan-Acquire phases, an Asset Register must be submitted at Integrated Design Reviews as specified in Table 50 and Table 51. The Level of Information (LoI) required in the Asset Register becomes more detailed and defined as the design develops. The submitted Asset Register is utilised by TfNSW during design development for validation, verification and traceability. It also contributes to communicating design intent.
At the point of handover of the physical assets to the maintenance and/or operations phase, an extract from the Asset Register is taken to form the Handover Asset Register. This Handover Asset Register must represent those assets as-built and include a record for all assets to the MMI and as required by T MU AM 02001 ST Asset Information and Register Requirements, Section 7.1 Creation of assets in the asset register and as required by T MU AM 02006 TI Asset Register and Data Dictionary (Note: T MU AM 02006 TI Asset Register and Data Dictionary details the asset register data to be provided in lieu of the O&M providing their own TfNSW compliant asset register template, e.g. RAMS, BIS, Equip etc).
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 97 of 116
Table 50: Asset register submissions
TRACC Integrated Design Review
Register Name
Description Minimum Requirement
3 CDD N/A - -
4 SBR System Breakdown Structure
Location list and asset list populated to reflect the System Requirements Specification (SRS) (refer to section 6.1).
Register completed as per DMS-FT-537 Asset Register Template.
Additional asset data as per contract requirements.
PDR Preliminary Design Asset Register
Complexes, entities, spaces/locations, elements and systems identified in the Asset List.
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 DMS-FT-537 Asset Register Template.
Additional asset data as per contract requirements.
DDR Detailed Design Asset Register
Complexes, entities, spaces, elements, systems and products identified in the Asset List.
The assets included in the Asset Register reflect the objects in the Federated Model, including parent EF and Ss relationships.
Register completed as per DMS-FT-537 Asset Register Template.
Additional asset data as per contract requirements.
FDR AFC Asset Register
Complexes, entities, spaces, elements, systems and products identified in the Asset List.
The assets included in the Asset Register reflect the objects in the Federated Model, including parent EF and Ss relationships.
Register completed as per DMS-FT-537 Asset Register Template.
Additional asset data as per contract requirements.
5 FSR N/A - -
ABR As-built Asset Register
Complexes, entities, spaces, elements, systems and products identified in the Asset List.
The assets included in the Asset Register reflect the objects in the Federated Model, including parent EF and Ss relationships.
Register completed as per DMS-FT-537 Asset Register Template.
Additional asset data as per contract requirements.
Handover Asset Register
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.
Assets identified as being MMI must have the additional information, as required by T MU AM 02006 TI Asset Register and Data Dictionary, appended to the Asset List or as per the O&M requirements.
Register completed as per DMS-FT-537 Asset Register Template.
Additional asset data as per contract requirements.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 98 of 116
Refer to Table 51 for the ABR stage asset register requirements, at the time of publication of this Standard. Refer to the latest version of DMS-FT-537 Asset Register Template for current requirements.
Table 51: Information required for inclusion in the ABR Asset Register
Ref. Field Name Attribute Name ABR inclusion
1. Asset List (AR PDS – Asset)
1.1 TfNSW Asset ID TfNSW_AssetID Optional
1.2 TfNSW Parent Asset ID TfNSW_ParentAssetID Conditional
1.3 Asset Location Code TfNSW_AssetLocationCode Mandatory
1.4 Asset Location Description TfNSW_AssetLocationDesc Mandatory
1.5 Asset Location Description Hierarchy TfNSW_AssetLocationDescHrchy Optional
1.6 Uniclass 2015 Asset Location Code TfNSW_UniclassAssetLocationCode Mandatory
1.7 Uniclass 2015 Asset Location Title TfNSW_UniclassAssetLocationTitle Mandatory
1.8 Parent Asset Location Code TfNSW_ParentAssetLocationCode Conditional
1.9 Project Asset ID TfNSW_ProjectAssetID Mandatory
1.10 Parent Project Asset ID TfNSW_ParentProjectAssetID Conditional
1.11 Asset Data Standard TfNSW_AssetDataStandard Mandatory
1.12 Asset Type Code TfNSW_AssetTypeCode Mandatory
1.13 Asset Instance TfNSW_AssetInstance Mandatory
1.14 Asset Code TfNSW_AssetCode Mandatory
1.15 Parent Asset Code TfNSW_ParentAssetCode Conditional
1.16 Asset Description TfNSW_AssetDescription Mandatory
1.17 Uniclass 2015 Asset Code TfNSW_UniclassAssetCode Mandatory
1.18 Uniclass 2015 Asset Title TfNSW_UniclassAssetTitle Mandatory
1.19 Top Level System Uniclass 2015 Code Uniclass_SsCode Optional
1.20 Top Level System Uniclass 2015 Title Uniclass_SsTitle Optional
1.21 Asset Label TfNSW_AssetLabel Mandatory
1.22 Asset Label Description Hierarchy TfNSW_AssetLabelDescHrchy Optional
1.23 Asset Type Configuration Code TfNSW_AssetTypeConfigCode Optional
1.24 Asset Type Configuration Description TfNSW_AssetTypeConfigDesc Optional
1.25 Discipline Code TfNSW_DisciplineCode Mandatory
1.26 Discipline Description TfNSW_DisciplineDesc Mandatory
1.27 Sub-discipline Code TfNSW_SubDisciplineCode Conditional
1.28 Sub-discipline Description TfNSW_SubDisciplineDesc Conditional
1.29 Asset Status Description TfNSW_AssetStatusDesc Mandatory
1.30 Asset Owner Organisation Name TfNSW_AssetOwnerOrgName Mandatory
1.31 Asset Maintainer Organisation Name TfNSW_AssetMaintainerOrgName Optional
1.32 Asset Operator Organisation Name TfNSW_AssetOperatorOrgName Optional
1.33 Work Package Name (Design) TfNSW_WPDesignName Mandatory
1.34 Work Package Code (Design) TfNSW_WPDesignCode Mandatory
1.35 Work Package Name (Supply) TfNSW_WPSupplyName Mandatory
1.36 Work Package Code (Supply) TfNSW_WPSupplyCode Mandatory
1.37 Work Package Name (Construction) TfNSW_WPConstructionName Optional
1.38 Work Package Code (Construction) TfNSW_WPConstructionCode Optional
1.39 Work Package Name (Commissioning) TfNSW_WPCommissioningName Optional
1.40 Work Package Code (Commissioning) TfNSW_WPCommissioningCode Optional
1.41 Project Contract Code (Design) TfNSW_ContractCodeDesign Mandatory
1.42 Contracted Organisation Name (Design) TfNSW_ContractOrgNameDesign Mandatory
1.43 Contract Name (Design) TfNSW_ContractNameDesign Mandatory
1.44 Project Contract Code (Supply) TfNSW_ContractCodeSupply Mandatory
1.45 Contracted Organisation Name (Supply) TfNSW_ContractOrgNameSupply Mandatory
1.46 Contract Name (Supply) TfNSW_ContractNameSupply Mandatory
1.47 Project Contract Code (Construction) TfNSW_ContractCodeConstruction Optional
1.48 Contracted Organisation Name (Construction)
TfNSW_ContractOrgNameConstruction Optional
1.49 Contract Name (Construction) TfNSW_ContractNameConstruction Optional
1.50 Project Contract Code (Commissioning) TfNSW_ContractCodeCommissioning Optional
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 99 of 116
Ref. Field Name Attribute Name ABR inclusion
1.51 Contracted Organisation Name (Commissioning)
TfNSW_ContractOrgNameCommissioning
Optional
1.52 Contract Name (Commissioning) TfNSW_ContractNameCommissioning Optional
1.53 Start km TfNSW_StartKm Mandatory
1.54 End km TfNSW_EndKm Conditional
1.55 GPS Coordinates TfNSW_GPSCoordinates Conditional
1.56 Maintenance Managed Item Flag TfNSW_MMIFlag Mandatory
1.57 Modelled Asset Flag TfNSW_ModelledAssetFlag Conditional
1.58 Source Model TfNSW_SourceModel Conditional
1.59 GUID GUID Conditional
1.60… For MMI, other attributes required by project contract requirements, for example:
T MU AM 02006 TI Asset Register and Data Dictionary
Sydney Trains Master Data Management (MDM) Templates
ILC GEN TP0 901 Asset Acceptance Technical Procedure
Bridge Inspection Procedure Manual
Conditional
2. Location List (AR PDS – Asset Location)
2.1 TfNSW Asset Location ID TfNSW_AssetLocationID Conditional
2.2 TfNSW Parent Asset Location ID TfNSW_ParentAssetLocationID Conditional
2.3 Project Asset Location ID TfNSW_ProjectAssetLocationID Mandatory
2.4 Parent Project Asset Location ID TfNSW_ParentProjectAssetLocationID Conditional
2.5 Asset Location Code TfNSW_AssetLocationCode Mandatory
2.6 Parent Asset Location Code TfNSW_ParentAssetLocationCode Conditional
2.7 Location Code Part TfNSW_LocationCodePart Mandatory
2.8 Asset Location Description TfNSW_AssetLocationDesc Mandatory
2.9 Work Type (Location) TfNSW_LocationWorkType Optional
2.10 Asset Location Description Hierarchy TfNSW_AssetLocationDescHrchy Optional
2.11 Uniclass 2015 Asset Location Code TfNSW_UniclassAssetLocationCode Mandatory
2.12 Uniclass 2015 Asset Location Title TfNSW_UniclassAssetLocationTitle Mandatory
2.13 Corridor TfNSW_Corridor Mandatory
2.14 Australian State TfNSW_AusState Mandatory
2.15 Suburb TfNSW_Suburb Mandatory
2.16 ASA Location TfNSW_ASALocation Mandatory
2.17 GPS Coordinates TfNSW_GPSCoordinates Conditional
2.18 Start km TfNSW_StartKm Mandotory
2.19 End km TfNSW_EndKm Conditional
Key requirements for the Asset Register submissions are:
• All objects in the submitted Federated Model must be represented in the Asset List (AR PDS – Asset) of all Asset Register submissions with the exception of the Asset Handover Register.
• All products (Pr) must be associated with a parent system (Ss). All systems (Ss) must be associated with a parent element or function (EF).
• At Asset Handover, the LoI included must be to the level of the MMI as per Section 7.1 in T MU AM 02001 ST Asset Information and Register Requirements.
• All MMIs must be identified by Final Design Review, in consultation with the Asset Custodian and O&M parties.
• Linear assets require both a Start Km and End Km. Non-linear assets (point assets) only require a Start Km.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 100 of 116
• The Asset Type Code field must utilise the codes in DMS-FT-141 Master Classification Library, unless agreed with TfNSW and documented in the Project DEXP.
• All line-items in the Asset List must be associated with an Asset Location Code from the Location List (AR PDS – Location). An Asset Location Code can be associated with multiple Project Asset IDs.
• The Asset Location Code and Asset Location Description fields must utilise the codes in T MU AM 01007 TI Asset Reference Codes Register, unless agreed with TfNSW and documented in the Project DEXP.
• Asset Locations must be classified with Uniclass 2015 to the LoI specified in Table 52.
6.9.2. Structuring and standardisation of data
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 52.
Table 52: Minimum Location Classification Requirements (Uniclass 2015)
TRACC Integrated Design Review Co En SL
3 Concept Design Development Co_xx
and
En_xx
and / or
SL_xx
4 Systems Breakdown Review Co_xx_xx En_xx SL_xx
Preliminary Design Review Co_xx_xx En_xx_xx SL_xx_xx
Detailed Design Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx
Final Design Review
5 Final Specification Review Co_xx_xx_xx En_xx_xx_xx SL_xx_xx_xx
As Built Review
Table 53: Minimum Asset Classification Requirements (Uniclass 2015)
TRACC Integrated Design Review EF Ss Pr
3 Concept Design Development EF_xx
and
Ss_xx
and
As required
4 Systems Breakdown Review EF_xx_xx Ss_xx_xx As required
Preliminary Design Review EF_xx_xx Ss_xx_xx_xx Pr_xx_xx
Detailed Design Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx
Final Design Review
5 Final Specification Review EF_xx_xx Ss_xx_xx_xx_xx Pr_xx_xx_xx
As Built Review
Compliance with the data classification and coding requirements (NB classification and coding is discrete from referencing as required in Section 6.9.1) within T MU AM 02002 TI Asset Classification System is not required during the Plan/Acquire phase of IP projects.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 101 of 116
Upon Contractor submission of the Asset Registers to TfNSW, TfNSW will assign the SER asset and location classification codes. This is done to reduce complexity and enable the use of Uniclass 2015 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 local councils are currently outside of the scope of this document. Refer to the Contract for these and other asset owner data requirements.
6.9.3. Existing data review
For brownfield sites, where the existing asset register(s) is 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 Asset Register data 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 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 (based on DMS-FT-537) provided in .xls format.
Other documents and files must be validated in accordance with Section 3.3.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 102 of 116
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 54 to help develop an appropriate working culture to facilitate successful DE.
Table 54: Digital Engineering 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 55 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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 103 of 116
Table 55: Digital Engineering 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 and/or TfNSW*
Responsible for managing the overall production for the project’s GIS data layer to be jointly agreed and Contractor and TfNSW are responsible for managing their own 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 SER and Industry Standards
Contractor Responsible for the day-to-day implementation of document control processes and system support
*to be agreed with TfNSW and documented in the Project DEXP or GIS Management Plan.
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.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 104 of 116
8. Assurance requirements
The Contractor must comply with the general assurance requirements for the project.
8.1. Quality assurance and quality control
Contractors must ensure all information deliverables for a project are structured in alignment with the TfNSW Project Data Schemas (refer to Table 25).
At each Submission TfNSW will review the data submitted to verify that all asset and other project data is complete, up-to-date and accurate.
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. These processes and procedures must be documented in the Project DEXP.
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 the KPIS listed in Table 56.
Table 56: Digital Engineering project Key Performance Indicators
KPI Area Benefit KPI
Communication Improved Design Clarity
Minimise administration overhead associated with responding to RFIs, through improved design clarity using BIM
No. RFIs
No. Business Days to Respond to RFIs
Design Reduced Rework
Minimise rework during construction, by improving the quality of the design through clash detection and construction sequencing
No. Design Changes (during construction)
No. Resubmitted design packages
Design Review Improved Design Review
Issues with designs identified and resolved faster, using BIM to review design and ECM to optimise collaboration and communication
No. Business Days to review design submissions
No. Business Days to close-out comments
Cost Reduced Commercial Risk
Minimise unexpected cost of variations during construction, by improving quality of design
No. Variations
% Cost Variance – Actual vs Baseline Cost
Time Improved Construction Durations
Minimise construction times and public disruption, by optimising the schedule
% Activities completed on time
% Time Variance - Actual vs Baseline Duration
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 105 of 116
KPI Area Benefit KPI
Quality Improved data accuracy
Ensure handover information for O&M is appropriate, complete and accurate, by more effective assurance of project deliverables.
Number of asset data errors at Integrated Design Reviews
Safety Improve Safety
Improve site inductions and safety training, using 4D BIM to support virtual construction and work simulation
Number of site inductions using visualisation tools
Number of incidents on site (lost time injury frequency rate)
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 design phase.
The Contractor is required to detail in the DEXP appropriate performance indicators and analysis to demonstrate level of DE performance.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 106 of 116
Appendix A - Reference of standards and guidelines
To successfully implement DE, Contractors are required to correctly apply relevant standards and best practice guidelines from Safety, Environement and Regulation (SER) (previously 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 57: TfNSW Digital Engineering – applicable existing standards and guidance
Applicable standards and guidance documents
Publication title
Guid
ance
Engin
eerin
g
Info
rma
tio
n
ma
nagem
ent /
CD
E
Asset
Info
rma
tio
n
Level of
Def/
Dev
Costin
g
Infrastructure & Place
DMS-ST-202 TfNSW DE Standard, Part 1 – Concepts and principles
DMS-ST-207 TfNSW DE Standard, Part 2 – Requirements
G73 Detail Survey
G75 Geographic Information Systems (GIS)
DMS-ST-173 Cost Estimating for Infrastructure and Place Projects
TfNSW SER -
TfNSW Asset Management Framework
- TfNSW Configuration Management Framework
- Transport Requirements for Assured Configuration Change (TRACC) Standard (DRAFT)
T MU AM 01001 ST
Life Cycle Costing
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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 107 of 116
Applicable standards and guidance documents
Publication title
Guid
ance
Engin
eerin
g
Info
rma
tio
n
ma
nagem
ent /
CD
E
Asset
Info
rma
tio
n
Level of
Def/
Dev
Costin
g
T MU AM 02004 ST
Management of Asset Information
T MU AM 02006 TI
Asset Register and Data Dictionary
T MU AM 06004 ST
Requirements Schema
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
T MU MD 00006 F1
Metadata Spreadsheet for Engineering Drawings
T MU MD 00014 GU
Multi-Discipline Rail Infrastructure Design Management
Mode specific requirements -
Roads and Maritime Services Schedule of Classified Roads and Unclassified Regional Roads
ILC-GEN-TP0-901
Asset Acceptance Technical Procedure
- Bridge Inspection Procedure Manual
- Sydney Trains Asset Information Delivery Plan
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
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 108 of 116
Applicable standards and guidance documents
Publication title
Guid
ance
Engin
eerin
g
Info
rma
tio
n
ma
nagem
ent /
CD
E
Asset
Info
rma
tio
n
Level of
Def/
Dev
Costin
g
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
AS 5488:2019 Classification of Subsurface Utility Information (SUI)
ISO 12006-2:2015
Building construction – Organization of information about construction works – Part 2: Framework for classification
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).
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207
DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 109 of 116
Appendix B –Levels of Detail indicative diagrams
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 110 of 116
B1 Bridge Structure
LoD 200 300 350 400
Bridge beam example
Element modelling to include
Type of structural concrete system
Approximate geometry (eg depth, length and width) of structural elements
Specific sizes and locations of main concrete structural members modelled per defined structural grid with the correct orientation
All sloping surfaces included in model element except elements affected by manufacturer selection
Reinforcing post-tension profiles and strand locations
Reinforcement modelled in congested/ interface locations or as a representative sample for each unique structural element
Chamfer
Pour joints and sequences to help identify reinforcing lap splice locations, scheduling, etc.
Lifting devices
Embeds and anchor rods
Penetrations for items such as drainage
Any permanent forming or shoring components
All reinforcement including post-tension elements detailed and modelled
Finishes
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 111 of 116
B2 Drainage
LOD 100 200 300 350
Drainage network example
Element modelling to include
Diagrammatic or schematic string model of drainage elements with placeholders
3D solid based model of elements with approximate size, shape and location of drainage pipes, pits and other drainage features
3D solid based model as design specified size, shape, spacing, location and grade of drainage pipes, pits, headwalls and other drainage features
Actual location of pits/ headwalls modelled based on setout details (not the centre of pit)
Actual location of pipe connections to pits/ headwalls modelled (centre of pit wall)
Hydraulic Grade Line (HGL) included based on minimum ARI for piped systems.
3D solid based model as actual construction elements
Actual size, shape, spacing, location, connections and slope of individual pipe lengths modelled
Actual size, shape, spacing, location, connections of pit and headwalls
Actual features attached to pits/ headwalls including grates, lids, lintels, step irons, railings etc.
Actual pit and headwall penetration modelled
Actual drainage trench depth and width modelled.
Hydraulic Grade Line (HGL) included based on minimum ARI for piped systems.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 112 of 116
B3 Road Alignment/ Pavement
LOD 100 200 300 350
Road alignment/ Pavement Example
Element modelling to include
Simple planar surface generated from design tin, either split into individual surfaces for pavement, verges, earthworks etc. or a single design surface
3D solid based model with individual elements split by type with approximate size, shape and location of lanes, shoulders, pavement, earthworks, verges, medians, footways kerbs, etc.
3D solid based model as design specified size, shape, spacing, location of lanes, shoulders, pavement, verges, medians, footways, kerbs pram ramps etc.
Individual pavement layers modelled from top of wearing surface to the bottom of SMZ
Pavement edge details shown as a nominal box out including subsoil drainage trench.
Cut and fill embankments modelled as planar surface including any benches, berms, table/ catch drains.
Earthworks foundations treatments modelled as nominal box out.
3D solid based model as actual construction elements
Actual size, shape, spacing, location, of lanes, shoulders, pavement, earthworks, verges, medians, footways kerbs, etc
Pavement edge details modelled actual construction elements including benching/ stepping individual pavement layers, daylighting pavement and subsoil drainage trench and pipe.
Kerbs as actual construction elements including based details and interfaces with pavement edge details and drainage pit inlets modelled.
Cut and fill embankments as 3D solid based model including benches, berms, table/ catch drains with any batter/ cutting treatments or linings modelled.
Earthworks foundations treatments modelled as specified including bridging layers, working platforms, drainage blanket, cut/ fill transition zones
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 113 of 116
B4 Road Furniture
LOD 100 200 300 350
Road furniture Example
Element modelling to include
Diagrammatic or schematic string model of road furniture elements, safety barriers, fences and line marking as string elements and signs, street lighting etc. as symbols
3D solid based model, individual elements represent approximate quantity, size, shape, location and orientation including signs & sign face, safety barriers, fences, line marking, street lighting and other road furniture elements.
Foundations for signs, barriers, fences and street lighting is approximate, with a strip footing applied for safety barriers and fence to allow for alternative post spacing during construction.
3D solid based model as design specified quantity, size, shape, location and orientation including signs, safety barriers, fences, line marking, street lighting and other road furniture elements.
Sign faces are sizes and positioned as designed to allow clearance and visibility checks.
Foundations for signs and street lighting is as designed/ specified allowing for ground conditions and location.
Strip footing provided for safety barriers and fences to allow for alternative post spacing during construction.
3D solid based model as actual construction elements
Actual quantity, size, shape, location and orientation including signs, safety barriers, fences, line marking, street lighting and other road furniture elements.
Safety barrier and fence posts modelled actual construction spacing.
Safety barrier terminals and crash cushions modelled as constructed elements.
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 114 of 116
B5 Survey
LOD 100 200 300 350
Site Survey
Example
Element modelling to include
A simple topographic surface shown as a plane
Surface generated from 3D scanning information
A generic surface shown as a plane interpolation between the different elements including existing road pavement, kerbs, drainage features, slopes, retaining walls, buildings and other existing features
Surface generated from detailed design survey and supplemented by 3D scanning information
3D contours shown to define the surface within the model
Complete and accurate surface defined between the different elements including existing road pavement, kerbs, drainage features, slopes, retaining walls, buildings and other existing features
Surface generated from detailed survey and supplemented by 3D scanning information
3D contours shown to define the surface within the model
Complete and accurate surface defined between the different elements
Existing features defined as separate elements within the survey model including existing road pavement, kerbs, signs, safety barriers, lighting, drainage features, slopes, retaining walls, bridges, buildings and other existing features
Surface generated from detailed survey and supplemented by 3D scanning information
3D contours shown to define the surface within the model
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 115 of 116
B6 Utilities
LOD 100 200 300 350
Drainage network example
Element modelling to include
Diagrammatic or schematic string model of utility elements, pipes, conduits and cables as string elements and pits, valves, hydrants, posts etc. as symbols
Utility data generated from topographical survey, tracing surface features (Quality level C) and supplemented with DBYD records (Quality Level D).
3D solid based model of elements with approximate size, shape and location of pipes, conduits, cables, pits, jointing bays, thrust blocks, hydrants, scour valves, poles and other utility features
Pipes, conduits, cables etc. sizes based on utility survey or DBYD records.
Pits, jointing bays, thrust blocks, hydrants, scour valves etc. size based on typical details from utility owner.
Conduits banks can be modelled as a single box rather than individual conduits.
Subsurface utility data generated from utility survey (Quality level B), topographical survey, tracing surface features (Quality level C) and supplemented with DBYD records (Quality Level D).
Surface utility data generated from topographical survey and typical pole
3D solid based model as surveyed size, shape, spacing, location and grade of pipes, conduits, cables, pits, jointing bays, thrust blocks, hydrants, scour valves, poles and other utility features
Pipes, conduits, cables etc. sizes based on utility survey
Pits, jointing bays, thrust blocks, hydrants, scour valves etc. size based on utility survey and pit reports.
Conduits banks can be modelled as a single box rather than individual conduits.
Subsurface utility data generated from utility survey, potholing and pits report (Quality level A & B) and topographical survey, tracing surface features (Quality level C).
Surface utility data generated from topographical survey including surveyed pole/ arm heights and catenary survey for wires.
3D solid based model as surveyed size, shape, spacing, location and grade of pipes, conduits, cables, pits, jointing bays, thrust blocks, hydrants, scour valves, poles and other utility features
Pipes, conduits, cables etc. sizes based on utility survey
Pits, jointing bays, thrust blocks, hydrants, scour valves etc. size based on utility survey and pit reports.
Actual size, shape, spacing, location, and connections of pipes/ conduits modelled
Individual conduits modelled.
Actual features attached to pits including grates, lids, step irons etc. modelled
Subsurface utility data generated from utility survey, potholing and pits report (Quality level A & B) and topographical survey, tracing surface features (Quality level C).
Digital Engineering Standard Part 2 – Requirements
Technical Services : Digital Engineering Services :
Project type: For all project types
DE STANDARD - PART 2 - REQUIREMENTS – DMS-ST-207 DIVISIONAL MANAGEMENT SYSTEM DMS-ST-207
© TfNSW 2019 UNCONTROLLED WHEN PRINTED Page 116 of 116
LOD 100 200 300 350
heights, tracing cables between poles (Quality level C).
Surface utility data generated from topographical survey including surveyed pole/ arm heights and catenary survey for wires.