CRN Man PDM 002 Design Management Manual

Country Regional Network
Design Management Manual

Sponsor: James Zeaiter
Document Number: CRN-MAN-PDM-002
Version: 3.0
Published Date: 25/07/2019
Table of contents
1 DESIGN MANAGEMENT MANUAL ........................................................................................................ 8
1.1 Design Management Documentation System................................................................................ 8
1.2 Application ...................................................................................................................................... 8
1.3 Review and Update of Procedures ................................................................................................ 8
1.4 Referenced Documents ................................................................................................................. 8
2 REQUIREMENTS..................................................................................................................................... 9
2.1 Classification and Referral ............................................................................................................. 9
2.2 Scope of Design Work ................................................................................................................. 10
2.3 Key Requirements ........................................................................................................................ 10
2.4 Client Requirements ..................................................................................................................... 12
2.5 Design Inputs ............................................................................................................................... 12
2.6 Functional Specification Meeting / System Definition Review .....................................................14
2.7 Functional Specification Report ................................................................................................... 14
2.8 Concept Design development ...................................................................................................... 14
2.9 Design Review and Approval ....................................................................................................... 17
2.10 Design Stages .............................................................................................................................. 19
2.11 Other Design Outputs .................................................................................................................. 23
2.12 As-Built Design records ................................................................................................................ 24
Appendix A Definitions and Terms ............................................................................................................ 27
Appendix B Roles and Responsibilities .................................................................................................... 33
Appendix C Engineering Specifications.................................................................................................... 35
C-1 Types of Specifications ................................................................................................................ 35
C-2 Specification Hierarchy ................................................................................................................ 36
C-3 Design Tasks to be Specified....................................................................................................... 37
C-4 General Characteristics of JHR CRN Developed Specifications .................................................37
C-5 Precedence of Standards ............................................................................................................. 38
C-6 Client Specifications ..................................................................................................................... 38
C-7 JHR CRN Standards and Specifications ...................................................................................... 39
C-8 Interface Specifications ................................................................................................................ 39
C-9 Format and Identification .............................................................................................................. 40
C-10 Maintenance of Specifications ..................................................................................................... 40
Appendix D Requirements Analysis, Allocation and Traceability ..........................................................41
D-1 Process Application ...................................................................................................................... 41
D-2 Requirements vs. Solutions ......................................................................................................... 41
D-3 Requirements Analysis ................................................................................................................ 42
D-4 Requirements Allocation .............................................................................................................. 44
D-5 Documentation of Requirements — Traceability ......................................................................... 45
Design Management Manual |2
Appendix E Design Standards ................................................................................................................... 46
E-1 Approved Standards .................................................................................................................... 46
E-2 Selection and Use of Australian and International Standards .....................................................46
E-3 JHR CRN Standards .................................................................................................................... 46
Appendix F Interface Definition and Management ................................................................................... 48
F-1 General Requirements ................................................................................................................. 48
F-2 Physical and Functional Interfaces .............................................................................................. 49
F-3 Standard or Common Interfaces .................................................................................................. 49
F-4 Operational Conditions of Use ..................................................................................................... 50
F-5 Operations Control and Safeworking ........................................................................................... 50
F-6 External Service Providers ........................................................................................................... 50
F-7 Physical Interfaces with Other Property Owners ......................................................................... 51
F-8 Management Systems Interfaces................................................................................................. 51
F-9 Regulatory Agencies .................................................................................................................... 51
F-10 Verification/Validation of Interfaces .............................................................................................. 52
Appendix G Hazard and Risk Analysis ...................................................................................................... 53
G-1 Requirements ............................................................................................................................... 53
G-2 Identify Primary Hazard Sources ................................................................................................. 54
G-3 Application within New Projects ................................................................................................... 55
Appendix H Reliability Maintainability and Availability ........................................................................... 60
H-1 Scope ........................................................................................................................................... 60
H-2 Definitions and Terms .................................................................................................................. 60
H-3 Reliability and Maintainability to be Performance Requirements .................................................61
H-4 Reliability and Maintainability in Design ....................................................................................... 61
H-5 Reliability ...................................................................................................................................... 61
H-6 Reliability Modelling ..................................................................................................................... 61
H-7 Failure Modes, Effects and Criticality Analysis ............................................................................ 62
H-8 Reliability Improvement during Design ........................................................................................ 63
H-9 Maintainability............................................................................................................................... 63
H-10 Relationship to Safety .................................................................................................................. 63
H-11 Specifying Reliability, Maintainability & Availability ...................................................................... 64
H-12 Reliability Design Targets ............................................................................................................ 64
H-13 Maintainability Design Requirements. .......................................................................................... 64
H-14 Availability Requirements ............................................................................................................. 64
H-15 Tendering ..................................................................................................................................... 65
H-16 Monitoring During Design and Development ............................................................................... 65
Appendix I Design Approvals ................................................................................................................... 66
I-1 Design Work to be Approved ....................................................................................................... 66
I-2 Scope of Design Approval............................................................................................................ 66
I-3 Method of Approval ...................................................................................................................... 66

I-4 Authority to Approve Designs....................................................................................................... 67
I-5 Design Work Requiring Approval ................................................................................................. 67
I-6 Approval of Changes during Construction ................................................................................... 68
I-7 Temporary Approval ..................................................................................................................... 68
I-8 Final Approval .............................................................................................................................. 68
Appendix J Design Verification ................................................................................................................. 69
J-1 Design Verification and Validation Processes ............................................................................. 69
J-2 Design Verification ....................................................................................................................... 70
J-3 Verification Methods ..................................................................................................................... 71
J-4 Technical Reviews ....................................................................................................................... 71
J-5 Design Checking .......................................................................................................................... 71
J-6 Independent Design Checks ........................................................................................................ 72
J-7 Development Tests, Simulation and Modelling ............................................................................ 72
J-8 Use of Verification Records for Design Validation ....................................................................... 72
Appendix K Design Validation .................................................................................................................... 73
K-1 Key Requirements ........................................................................................................................ 73
K-2 Validation Methods ....................................................................................................................... 73
K-3 Nil (No validation required) ........................................................................................................... 74
K-4 Similarity ....................................................................................................................................... 74
K-5 Demonstration or Inspection. ....................................................................................................... 74
K-6 Analysis ........................................................................................................................................ 75
K-7 Testing .......................................................................................................................................... 75
K-8 Commissioning ............................................................................................................................. 76
Appendix L Technical Design Reviews ..................................................................................................... 78
L-1 Technical Reviews to be Specified for Design Projects ............................................................... 78
L-2 Technical Review Process ........................................................................................................... 78
L-3 Technical Reviews - General Requirements ................................................................................ 79
L-4 System Concept Review .............................................................................................................. 80
L-5 System Definition Review ............................................................................................................ 80
L-6 Preliminary Design Review .......................................................................................................... 81
L-7 PDR for Minor Projects ................................................................................................................ 81
L-8 PDR for Major Projects or Sub-contracts ..................................................................................... 81
L-9 Critical Design Review ................................................................................................................. 82
L-10 CDR for Minor Projects. ............................................................................................................... 82
L-11 CDR for Major Projects or Sub-contracts ..................................................................................... 82
L-12 Technical Reviews Associated with Construction ........................................................................ 82
L-13 System Verification Review.......................................................................................................... 82
L-14 Physical Configuration Audit ........................................................................................................ 83
Appendix M Design Change Management................................................................................................. 84
M-1 Design Responsibility ................................................................................................................... 84

M-2 Projects Designed Using JHR CRN Resources ........................................................................... 84
M-3 Projects Developed under Contract ............................................................................................. 84
M-4 When to raise a DCN ................................................................................................................... 84
M-5 Before Approval of Design “For Construction”. ............................................................................ 84
M-6 After Approval of design “For Construction” ................................................................................. 85
M-7 Categorisation of Changes ........................................................................................................... 85
M-8 Major Changes ............................................................................................................................. 85
M-9 Minor Changes ............................................................................................................................. 86
M-10 Processing and Approval of Changes .......................................................................................... 86
Appendix N Design Documentation and Records .................................................................................... 90
N-1 Key Requirements ........................................................................................................................ 90
N-2 Documentation Standards ............................................................................................................ 90
N-3 Contractor Drawings and Documentation .................................................................................... 90
N-4 Documentation Control ................................................................................................................ 91
N-5 Design Files and Records ............................................................................................................ 92
N-6 Documentation for Unapproved Projects ..................................................................................... 92
N-7 Superseded Documents ............................................................................................................... 92
N-8 Retention Periods ......................................................................................................................... 92
Appendix O Integrated Support Requirements......................................................................................... 93
O-1 Integrated Support Analysis – General Requirements ................................................................ 93
O-2 Responsibility for Integrated Support Analysis ............................................................................ 94
O-3 Timing of Support Analyses ......................................................................................................... 94
O-4 Approval of Integrated Support Requirements ............................................................................. 94
O-5 Maintenance Requirements ......................................................................................................... 95
O-6 Level of Repair Analysis ............................................................................................................... 95
O-7 Spares Support Requirements ..................................................................................................... 95
O-8 Facilities and Tools ...................................................................................................................... 96
O-9 Training ........................................................................................................................................ 96
O-10 Documentation and Manuals ....................................................................................................... 96
O-11 Integrated Support Database ....................................................................................................... 97
Appendix P Maintenance Requirements Analysis ................................................................................... 98
P-1 When to Review Maintenance Requirements .............................................................................. 98
P-2 Maintenance Requirements Analysis Process ............................................................................. 99
P-3 Identify the Item ............................................................................................................................ 99
P-4 Establish the Function ................................................................................................................ 100
P-5 Establish Failure Modes and Effects .......................................................................................... 100
P-6 Failure Recognition .................................................................................................................... 100
P-7 Effect of Failure/Criticality .......................................................................................................... 100
P-8 Maintenance Task Options ........................................................................................................ 101
P-9 Task Frequency.......................................................................................................................... 101

P-10 Assembling the Program ............................................................................................................ 101
P-11 Documenting Maintenance Requirements ................................................................................. 101
P-12 Approval of Changes to Maintenance Requirements ................................................................ 101

CRN-MAN-PDM-002
Version: 0.2
Date of Issue: 20/12/2016
CDRL Line Number: N/A
Document Control
This is a controlled document.
Printed versions are uncontrolled.
Full document version history and draft iterations are available through viewing server properties on
the JHR IMS where this document is stored.
Version History
Version No Date Prepared By Reviewed By Approved By
1.0 20/12/2016 Iain Murray Stewart Rendell James Zeaiter
David Mackney
Description of Changes
– Initial version – compilation of extant procedures into one manual
Description of Changes
–
Disclaimer. This document was prepared for use on the CRN Network only. John Holland Rail Pty Ltd (JHRPL) makes
no warranties, express or implied, that compliance with the contents of this document shall be sufficient to ensure safe
systems or work or operation. It is the document user’s sole responsibility to ensure that the copy of the document it is
viewing is the current version of the document as in use by JHRPL. JHRPL accepts no liability whatsoever in relation to
the use of this document by any party, and JHRPL excludes any liability which arises in any manner by the use of this
document.
Copyright. The information in this document is protected by Copyright and no part of this document may be reproduced,
altered, stored or transmitted by any person without the prior consent of JHRPL.

1 DESIGN MANAGEMENT MANUAL
1.1 Design Management Documentation System
This Engineering Design Management Manual establishes the processes to be implemented for all JHR CRN design tasks
and are applicable for provision of Engineering Services.
The manual incorporates key statutory and management requirements as shown in Figure 1. Specific requirements are
included in individual appendices of this document.
Australian & Management Australian &

International policies & quality International
standards policy standards
Engineering
management
procedures
Design standards, Infrastructure

instructions & design data & Infrastructure
manuals (each configuration support data
discipline) records
Figure 1: Design management documentation structure
1.2 Application
This Manual sets out general policy and requirements for the Engineering Design Management
System to be implemented on JHR CRN designs.
The requirements of this manual shall apply to all design work performed by or for JHR CRN, as
defined within Section 2 of this Manual. The Principal Discipline Engineer/s or the Manager
Engineering Services may modify the requirements of this manual to suit the design task based on
an assessment of the complexity, number of interfaces, technology and safety criticality of the
asset/system.
1.3 Review and Update of Procedures

The processes defined within the JHR CRN Engineering Management System have been developed
to comply with Legislation and Regulations that are current at the time of issue. The structure of this
Manual conforms to the requirements for a quality management system within AS/NZS ISO 9001.
The appendices of this Manual reflect high-level policies, processes and requirements for the
management of design and integrated support tasks within a systems engineering context and
should provide a stable basis for JHR CRN business processes.
The Manual shall be reviewed as regularly as required to incorporate changes in governing
Legislation, Regulations and Standards and to reflect changes and improvements in JHR CRN
management processes.
1.4 Referenced Documents

– AS/NZS ISO 9001 Quality Management Systems-Requirements
– Rail Safety National Law, Rail Safety National Law, National Regulations
– Workplace Health and Safety Act & regulations
– AS/NZS ISO 4801 Occupational Health and Safety Management Systems
– AS/NZS ISO 14001 Environmental Management Systems
– ISO/IEC 15288 Systems & Software Engineering
– AS/NZS ISO 31000 Risk Management
– IEEE 1220 Standard for Application and Management of the Systems Engineering Process
2 REQUIREMENTS
2.1 Classification and Referral
For the purposes of defining the significance of a design task and the volume of work required to
deliver that task, the following definitions have been developed to allow classification and facilitate
resource allocation.
Minor Task — a minor task is one that can be completed in less than 40 hours of design effort and
can either be completed entirely within one discipline or requires only minor inputs from other
disciplines. Telephone inquiries and processing of simple design changes or repair schemes are
examples.
Minor Project — Minor Projects are those where:
– The expected design completion time is assessed as between 40 and 150 hours of design effort,
and/or
– A significant level of design input is required by two or more disciplines,
Major Project — Major projects are those where:
– The expected design completion time is estimated to exceed 150 hours of design effort, and/or
– A substantial level of input is required by two or more disciplines, and/or
– A safety critical system is involved or new/novel technology is being applied to a safety critical
system and/or
– The complexity of the project e.g. New Train communication system is assessed as requiring
major project planning and reporting disciplines and visibility.
Task requests shall be referred to the Manager Engineering Services who shall arrange for an initial
assessment and determination of the likely classification of each request. This will set out the level
of detail required and the appropriate steps to follow from this manual. The default minimum steps
in this process are development of a) concept design, b) preliminary design and c) detailed design
although this can be varied so long as there is visibility and justification to do so. Where there is a
potential change to the functionality of the CRN the proposal must be approved for development by
the Configuration Control Board.
If the request requires a Project Manager, the Manager Engineering Services and Infrastructure
Manager will confer and appoint one.

2.2 Scope of Design Work
Design work performed by JHR CRN or for JHR CRN, is not confined to major projects. It includes
all tasks that may alter the physical configuration, functional performance or the conditions of use of
any asset or item of infrastructure, including hardware and software elements of such items. Design
tasks include, but are not limited to:
– Development of new designs for assets or infrastructure items (both hardware and software
elements) through minor or major tasks and projects,
– Modification or alteration of existing designs (both hardware and software elements), through
planned upgrading or to correct identified deficiencies.
– Development of repair methods for any item, particularly where the repair would alter strength,
durability or functional performance or limitations.
– Identification, development and type testing/approval of new standard designs and equipment for
use in specified applications, including standard repairs.
– Review and approval of changes in the conditions of use for any item, including definition of
restrictions or additional inspection requirements where the proposed usage would result in the
item being used outside of its original design basis. These include changes to usage parameters
such as speed, loading, operating and environmental conditions.
– Local development and/or modification of tools, test equipment, workshop aids or other plant and
equipment.
– Review and approval of substitute or replacement spares for any hardware item.
Requests for design support/services from the Client (CRC/TfNSW) or third party organisations may
be received via the Configuration Control Board, Infrastructure Manager, Strategic Asset Manager,
Property group or in the form of Technical Advice requests from CRN Field Staff.
Internal projects, such as the development or type approval of a new standard design or item may
be initiated by Principal Discipline Engineers or the Manager Engineering Services. Unless such
tasks qualify for classification as a Minor Task, they shall be processed and registered in accordance
with the requirements of Section 2.1. above.
2.3 Key Requirements

The following key requirements shall apply for all design work performed within or for JHR CRN.
Specific requirements are defined in detail in the individual appendices of this manual.
2.3.1 Design Process Model

JHR CRN has adopted the Systems Engineering methodology as the basis for management of the
design process (IEEE Standard 1220). This model, which is consistent with the process of design
described in AS/NZS ISO 9001, establishes a systematic methodology for ensuring that Client
requirements are fully identified and achieved within the final design.
Application of the JHR CRN model will also meet the requirements of Workplace Health & Safety
Act and Regulations for actions by an employer in respect of Plant Design, as well as the
requirements of the Rail Safety National Law. The top level model adopted by JHR CRN is shown
in Figure 2.
Design Management Manual | 10

Customer / Client or
end user specification Traceability
(2.4.1)
Engineering Design
Regulations & Requirements
Legislation (2.5.2) Functional Specification (2.5.1)
Meeting – System
Definition Review (SDR) CRN Standards and
(2.6) Specifications (2.5.1)
Additional Design Inputs
(2.5.3)
Functional Specification Hazard & Risk Analysis

Traceability Report (2.7) (2.8.2)
Concept Options System Concept Review Stakeholder and

Identification (SCR) (2.8.4) CRN Engineering
Design Verification (2.9.1)
Hold Point Requirements
Design Validation (2.9.2)

(2.8.5)
Changes to Configuration
Design Interfaces
Design Brief Develop Concept design (2.8.1)
(2.8.6) (2.10.1)
Concept Options Appraisal Integrated Support

(COA) (2.10.2) provisions (2.8.3)
Hold Point
Develop Develop Preliminary design Design and

Temporary Works (2.10.3) Configuration
design documents (2.11.1)
(2.10.9)
Preliminary Design Review
(PDR) (2.10.4)
Hold Point
Maintenance
Develop Detailed Design Analysis (2.11.2)
(2.10.5)
Critical Design Review

(CDR) (2.10.6)
System Verification Review

Design Approval
(SVR) and Validation (2.10.7)
(IFC Drawings)
Hold Point
(2.10.8)
Use and
Construction
Maintain
Configuration
Management As-built Design
records (2.11.1) Records (2.12)
Figure 2: JHR CRN Design process model.

2.3.2 Key Business rules
The following key business rules shall apply for the management of all design tasks and projects
undertaken by JHR CRN Engineering staff. Each aspect is covered in more detail within this Manual.
– All design tasks, except for those classified as minor tasks, shall be managed as projects.
– The Project Manager shall register each request as a proposal in the Design Projects Register
(DPR) on receipt and then proceed to establish whether the scope of the project is adequately
defined. Engineering Services shall maintain a projects register (DPR), to be used for registering
all Minor and Major projects.
– Lead Engineers within design disciplines retain responsibility for approval of their respective
design elements within a project.
– Project Managers are responsible for Engineering (Project) Approval of the overall project task.
(See Appendix I for definition of approval levels).
– Principal Discipline Engineers (or Engineers with delegated authority to do so) shall be
responsible for assigning staff to minor tasks within their area of responsibility.
– Engineers assigned responsibility for minor tasks shall be responsible for planning these tasks
and for maintaining records of resource allocation and task status.
2.3.3 Registration
The Project Manager shall register each request as a proposal in the Design Projects Register (DPR)
on receipt and then proceed to:
– Establish whether the scope of the project is adequately defined, and
– Prepare an offer of service
The Manager – Engineering Services shall maintain a project register (DPR), to be used for
registering all Minor and Major projects.
2.4 Client Requirements

2.4.1 Customer, Client or end-user requirements
Every JHR CRN design task will have a designated Client. This may be an organisation external to
JHR CRN or an internal Section within JHR CRN.
The responsible Project Manager assigned to the task shall ensure that the Client’s requirements
are specified in sufficient detail to establish clear output requirements for the task. Wherever
possible this should be in the form of a Performance Engineering Specification prepared by the Client
that can be agreed before the task begins.
2.5 Design Inputs

2.5.1 Engineering Design Requirements
The Project Manager, in conjunction with the appropriate JHR CRN Principal Discipline Engineers,
shall be responsible for ensuring that design output requirements are fully specified, in accordance
with the general requirements of Appendix C.
This includes both Engineering Specifications for products and management requirements for design
tasks, as follows.

– Hazards and risk analysis plans and reports as defined in Appendix G.
– Reliability program plans and reliability predictions as defined in Appendix H.
– Integrated Support Plan, including maintenance analysis and Technical Maintenance Plan
requirements. Refer to Appendix P for additional information.
All specifications must include safety, environmental and supportability requirements as part of the
design criteria for the task. The specification shall also include specific requirements for verification
and validation, in accordance with the general requirements of Appendix J and Appendix K.
2.5.2 Regulations, Legislation and Standards

The Client Specification or agreed Design brief forms the major design input. However, design tasks
are also governed by statutory requirements, particularly those relating to the design of plant within
the Workplace Health & Safety Act and Regulations and Environmental Legislation. These statutory
requirements must be taken into account in establishing design inputs, irrespective of whether they
are specified by the Client or not.
The design process will determine a list of the standards, specifications and codes of practice to be
used in the design. The hierarchy for application of standards and specifications is as follows:
– Standards required by Workplace Health & Safety Act and Regulations or other relevant
Legislation shall prevail over all other requirements, to the extent that they are applicable to the
product or application covered by the specification
– JHR CRN Standards, where the use of a JHR CRN Standard is appropriate for the application.
– Standards specified by the Client (such as Australian or International Railway Standards), where
these are appropriate for the application
2.5.3 Additional Inputs

Determining the full suite of design inputs, and agreeing these with the Client, represents an
essential step for management of the design process and for commercial arrangements relating to
the task. They provide a clear statement of the design output required as well as the basis for
determining changes in scope and cost/payment, whether the task is being performed as part of a
formal commercial contract or under an internal agreement. Typical additional inputs into this
process include:
– Initial concept sketches
– Tender statement of works
– Scope of works
– Site condition inspection report
– Property review report
The design inputs are utilised in the development of the Functional Specification report which forms
the basis for verification/validation of design output i.e. for determining whether the final design has
met the Clients requirements.
2.5.4 Configuration Management Requirements

Any proposed change to the configuration of CRN assets or systems resulting in a change to the
functional baseline or risk profile of the network will be managed via the Configuration Change
Management Process documented in CRN-PLN-ASM-003 Configuration Management Plan. This

includes Design only projects where the construction phase may be completed the following financial
year.
Depending on the nature of the project activity, configuration change requests (CCRs) will be
classified as either ‘Major’ or ‘Minor’- a decision process documented in CRN-PLN-ASM-003 and
made by the Principal Engineer and Strategic Asset Manager prior to final approval of the AWP.
Major Configuration Changes for Design projects are to be presented to Configuration Control Board
(CCB) before the design is issued for construction. The project manager is required to present the
preferred option to the board and seek approval.
For information on Configuration Change requests (CCRs), approvals and the role of the CCB in this
process refer to CRN-PLN-ASM-003 Configuration Management Plan.
2.6 Functional Specification Meeting / System Definition Review

The System Definition Review (SDR) (or Functional Specification Review) is completed to ensure
that there is a clear and common understanding of the design requirements for the task. This review
forms the basis of the Functional Specification Report
2.7 Functional Specification Report

For Major projects, the Functional Specification Report will be developed by the Project Manager as
an output of functional specification meetings to determine both the Functional Specification and the
design scope. This will involve engagement of all stakeholders and include a review of initial design
options and preparation of an options analysis brief CRN-FRM-PDM-021 and a Scope of Works.
The functional specification outputs should include:
– Site configuration and constraints
– Operational / functional objectives and requirements
– Stakeholder requirements
– Engineering requirements
Stakeholder review of the Functional Specification Report is required prior to moving to the Concept
options appraisal - this is substantive Hold Point in the design process.
2.8 Concept Design development

2.8.1 Design Interfaces
JHR has developed, recorded and implemented appropriate control measures to manage the risks
identified to ensure that the interface and access safety requirements are satisfied. The risk to safety
due to the existence of network interfaces are captured in CRN-REG-RCM-003 Enterprise Barrier
Register and the relevant BowTies model(s) applicable to network interface.
The following eight operational risks must be managed as part of developing design concepts in the
design and construction process:
– Operational, Management and Safe working procedures
– Physical & Functional interfaces within the same system
– Physical and functional interfaces with external suppliers e.g. telecoms, power
– Physical Interfaces with Installations on CRN property owned by other agencies

– Management System interfaces e.g. Ramsys, Maximo, GIS
– Interfaces with Regulatory agencies e.g. ONRSR
– Physical and Functional Interfaces with other CRN systems e.g. Track, Signaling,
Communications.
– Operational Conditions of use e.g. speed, axle loads, vehicle configuration
Uncontrolled changes to any type of interface can create significant problems and the types of
interfaces are considered to be of equal significance within the design management environment.
All types of interfaces must be considered during the design of all changes to the configuration of
JHR CRN assets or infrastructure.
The Project Manager must assess and populate the Workplace Risk Assessment with identified
design interface risks.
Refer to Appendix F ‘Interface definition and management’ for more Information.
2.8.2 Hazard and Risk Analysis – (Safety in Design)

JHR CRN, in common with all other employers, has a standing obligation under the Workplace
Health & Safety Act & Regulations to ensure that hazards are identified and that risks are either
eliminated or controlled within the workplace and to comply with Environmental Legislation. This
obligation extends to the design of plant and equipment for use within JHR CRN or completed for a
third party, as well as to the specification and acquisition of “standard” equipment from commercial
suppliers.
In addition, JHR CRN must demonstrate the capability and capacity to safely construct operate and
maintain assets and infrastructure under the provisions of the Rail Safety National Law.
Hazard and risk analysis shall be completed as an integral part of all design work, to ensure
compliance with relevant legislative requirements. The results of this analysis shall be documented
and maintained as part of the design record. The complexity of the analysis shall be appropriate to
the design stage being completed (i.e. concept design = concept level risk assessment).
Appendix G sets out principles and requirements for hazard and risk analysis, including the
requirement for documenting the results and risk in accordance with JHR CRN Risk Management
Framework and AS/NZS ISO 31000: Risk management – Principles and guidelines. Also refer to
CRN-MPR-RCM-003 Implementation of the Management of Change Exemption Request (MoCER),
Management of Change Risk Assessment (MoCRA), CRN RM 005 Rolling Stock/Plant Configuration
Change Process and Safety Documentation for additional information on this topic.
2.8.3 Integrated Support Provisions

Supportability is an essential consideration in all design work. Plant and equipment designed by or
for JHR CRN must be able to be managed and maintained safely and efficiently by JHR CRN staff,
or a third party, as appropriate.
Integrated support requirements shall be considered as part of each design task, including design
changes made as a result of CCR action. Integrated support requirements to be considered as part
of each task shall include the following aspects, as defined in Workplace Health & Safety Act &
Regulations:
– Documentation and manuals including the purpose for which the plant is designed, installation,
commissioning, operation, maintenance, inspection, cleaning, transport, storage and, if the plant
is capable of being dismantled, dismantling of the plant

– Maintenance requirements, including testing or inspections to be carried out on the plant,
– Systems of work necessary for the safe use of the plant,
– Knowledge, training or skill necessary for persons operating or undertaking inspection and testing
of the plant,
– Spares support requirements,
– Emergency procedures.
Consideration of integrated support aspects as part of a design task includes:
– Incorporation of specific provisions within the design to enhance maintainability and
supportability, such as ease of access, inspection provisions, emergency operation and safety
aspects such as isolation and guarding, and
– Ensuring that the necessary documentation and support provisions are properly assessed and
introduced before the newly designed equipment enters service.
Specific requirements for the inclusion of Integrated Support provisions in all design tasks are
included in Appendix O.
2.8.4 System Concept Review

The System Concept Review (SCR) is normally only applicable for large scale Major Projects, such
as a new large piece of rail plant, new line or major rearrangement of existing infrastructure. The
review is normally to be carried out during the concept development phase, after the preparation of
a detailed engineering specification but prior to release of a Request for Tender (RFT) for the project.
The primary purpose of the review is to ensure that the project specification is complete, accurately
represents client and statutory design requirements and that the RFT covers all requirements for
effective management of the design development or acquisition contract.
2.8.5 Concept Options Identification and Appraisal

A review of the functional specification report will be carried out at this stage by the stakeholders to
determine the options to be carried forward to Concept Design. This will involve a value
management appraisal of the Stakeholder and Engineering requirements. All options require a basis
for their consideration (Pro’s and Con’s) and approval from the appropriate Business Unit Manager
in order to progress to the concept design stage.
A comments register (CRN-FRM-PDM-003) will be developed by the PM to capture all stakeholder
correspondence. As part of the verification process, these comments will be actioned with the
agreement of all stakeholders before moving to the next stage. For further information on
management of comments refer to the guidance notes contained in CRN-FRM-PDM-003 Comments
Register.
2.8.6 Design Brief

Prior to developing the Concept design, where the Client has not provided a detailed Engineering
Specification, the Project Manager responsible for the task shall develop a Design Brief for
agreement with the Client. Project Managers are responsible for coordinating inputs where more
than one discipline is involved.
The Design Brief should be prepared to reflect the JHR CRN understanding of the requirements of
the intended design. The brief must include all Standards and requirements called out in applicable

Legislation and Government Regulations, as well as all key design parameters necessary to execute
the task. These include the intended conditions and limitations of use, for approval by the Client.
As a minimum, the Design brief must include:
– Performance requirements for the item to which the task applies,
– Intended use, including maximum loads or operating condition, duty cycle, operating environment
and required design life.
– Interfaces with existing equipment,
– Reliability and availability specification and maintainability requirements (these should ensure the
future proofing of the new asset).
– Any other special requirements including alternative design standards (where these differ from
JHR CRN Standards) or other Regulatory requirements.
Full definition of the proposed design requirements is essential for compliance with the
responsibilities of a designer under relevant Rail Safety and OH&S Regulations. In addition, JHR
CRN has a general responsibility to produce designs that are “fit for purpose” for the intended use
and design staff must clearly establish and document planned performance and usage requirements
in order to meet this obligation.
2.9 Design Review and Approval

Each design project shall include requirements for verification and validation of design output, to the
extent applicable to the task. This should include:
– Specific characteristics/parameters to be validated during the design process
– Validation methods, including independent design checks and simulation or modelling
requirements, such as Finite Element Analysis of structural elements
– Information related to the use of components or materials that have been type tested and
approved, either by JHR CRN or by an independent testing agency, including requirements for
inclusion of type test data in the final design package.
Some contracts may require the development and delivery of test and commissioning plans as part
of the design task. In such cases, the requirements for the plan shall be specified as part of the
deliverable documentation under the contract. Test and commissioning plans should include
sufficient detail for use within a subsequent construction phase, including test parameters and
pass/fail criteria for each parameter.
Appendix J and Appendix K include further information concerning the verification and validation
processes, respectively.
2.9.1 Design Verification

Verification of design output shall be accomplished through review and approval of the
documentation by an authorised engineer or engineers, as appropriate. Verification may take place
either at the completion of each design stage for major projects, or at the completion of the design
task for minor projects or CCRs, or a combination dependent on the scale of the task.
Where design verification is completed following each stage the primary purpose shall be to ensure
that the output of that stage (e.g. the concept design) conforms to the design input requirements for
that stage, or that any changes are identified and verified.
More detailed requirements for design verification are set out in Appendix J.

Technical Reviews
Each major design contract shall include a requirement for formal technical reviews, which may be
defined as hold points within the design development task.
The scope and purpose of technical reviews is outlined in Appendix L. Requirements for the reviews
to be included in each contract should be aligned to the needs of the contract, but may include:
– System Concept review (SCR)
– Concept Option Appraisal (COA)
– Preliminary Design Review (PDR)
– Critical Design Review (CDR)
– System Verification Review (SVR)
The main objectives of technical reviews is risk reduction and to ensure compliance to standards, to
ensure that any departures from the intent of the design task are recognised and reviewed as early
as possible in the design process and to enable corrective actions to be implemented with minimal
schedule and cost impacts.
The Project Manager is responsible for ensuring that Technical Review requirements are included
in contract requirements and that reviews are:
– Conducted at appropriate points during the project
– Fully supported by relevant JHR CRN staff.
2.9.2 Design Validation

Design validation is the process of ensuring that the final product conforms to defined user (client)
needs and/or requirements (Functional Specification).
The Validation process may be accomplished through a variety of methods as defined in Appendix
K. The most common methods are developed to demonstrate the ability of the final design to meet
the range of operating conditions included in the specification or design brief.
General validation requirements and methods shall be determined and approved for all new design
tasks before commencement of the task, and progressively defined and refined as the task proceeds.
Validation results shall form part of the design record for the item or system concerned, and shall be
filed as part of the design data for the item.
More detailed requirements for design validation are set out in Appendix K.
2.9.3 Changes in Scope

Project Managers and team members responsible for projects shall ensure that significant changes
in scope or project requirements are identified and documented. The Project Manager is to be
promptly advised of potential changes in scope.
Some minor changes in scope can be expected within design projects and can often be
accommodated by offsets in other areas of the project. However, the Project Manager must submit
a variation to the client for significant changes in either the technical scope or the inclusion of
additional responsibilities that were not covered by the agreed scope and Offer of Service.
Assessment of scope changes must take account of both additional tasks and the need to
review/change completed work and, in some cases, will involve consideration of whether the extent
of the change should lead to the task being considered as a new project. Scope changes may need

to trigger a review and approval of the Configuration Committee if it impacts the basis of their original
decision. Appendix M contains a detailed explanation of Design Change management.
2.10 Design Stages

Each stage may include a number of identifiable sub-stages, particularly in major projects where the
development of individual sub-systems and configuration items may proceed as separately identified
work packages. In other cases, such as processing of a minor Configuration Change Request, the
stages may be combined.
Detailed requirements for completion of the actual design work within each design stage are covered
by JHR CRN Standards, Instructions and Manuals applicable to each discipline. All design work is
to be carried out in accordance with the applicable guidelines. Appendix E provides additional
details.
All design work shall be executed in accordance with the agreed functional specification or design
brief. This is particularly important where the task is being carried out under commercial
arrangements, to avoid rework costs resulting from non-compliance with specified requirements.
Design tasks shall only proceed after detailed analysis of specification and/or design brief
requirements. Where necessary this shall be documented in the form of a traceability record, that
permits traceability from the specification/design brief, to the verification and validation records for
the final design. Appendix D establishes specific requirements for requirements analysis and
traceability.
The design stages shown in the model normally represent development of the design concept,
preliminary design and detailed design respectively. These three major stages are applicable to
most design tasks, whether they are undertaken as part of a major project (the most complex case),
or involve changes to in-service equipment.
2.10.1 Concept Design

The Concept design will identify design options, limitations, constraints and potential non-
compliances. It will also identify assumptions, unknown risks and the estimated project costs and
schedules.
Typical inputs:
– Identified operational / functional objectives
– Identified stakeholder inputs
– Confirmed existing asset configuration
– Desktop survey, geotechnical, environmental, property and services assessments,
– Concept engineering
– Existing operational interfaces
– Comments log
Outputs
– Concept design Options report
– Identification of all (typically 2-6) potential options
– Identification of pros and cons for each option
– Comparison of options – scope, configuration, operation, hazards, risks etc.
– Concept design drawings - Schematics, concept sketches for each option
– Project schedule estimate (for each option if required) to a +/- 50% accuracy, including all design,
procurement and construction works
– Project cost estimate (for each option if required) to a +/- 50% accuracy, including all design,
2.10.2 Concept Options Appraisal (COA)

A review of the Concept Design will be carried out at this stage by the stakeholders to determine the
options to be carried forward to Concept Design. This will involve a value management appraisal
of the Stakeholder and Engineering requirements. Stakeholder review and approval of the Concept
design options is required prior to moving to the preliminary design stage - this is substantive Hold
Point in the design verification process.
2.10.3 Preliminary Design

The preliminary design progresses the concept designs and will include more detailed deliverables
and develop design for the preferred options. This should address limitations, constraints and non-
compliances while also developing estimated project costs and schedules.
Inputs:
– Outputs / deliverables from Concept Design Stage
– Confirm Functional Specification objectives and requirements
– Dilapidation / condition investigation of existing assets
– Site geotechnical investigation
– Site environmental and contamination investigation – develop REF if required
– Site survey – assets, topographic, cadastral
– Site services investigation
– Property investigation
– Hazard / risk review
– Preliminary engineering input
– Comments log
Outputs:
– Preliminary design report
– Development of preferred (typically 1-2) options
– Development of pro’s and con’s for each option
– Comparison of options – scope, configuration, operation, hazards, risks, etc.
– Recommendations of a single preferred option
– Asset configuration and condition report / details
– Geotechnical report
– Environmental and contamination report – REF if required
– Services report / details
– Property report / details
– Preliminary design drawings - Schematics, general arrangements, typical sections and details for
each option
– Safety in design report / details
– Project schedule estimate (for each option if required) to a +/- 30% accuracy, including all design,
– Identification of wavers and concessions required
– Project cost estimate (for each option if required) to a +/- 30% accuracy, including all design,
– Configuration documentation
A reduced number of Options may be presented at this stage. The submissions should demonstrate
the proposed solution is consistent with the functional and performance requirements of the
Engineering Specification.
2.10.4 Preliminary Design Review (PDR) / Concept Design Review

The Preliminary Design Review is held when the preliminary design has been established, to ensure
that the proposed solution is consistent with specified requirements. Stakeholder review of the
Preliminary design is required prior to moving to the detailed design phase - this is a substantive
Hold Point in the design verification process.
2.10.5 Detailed Design

The Detailed design develops the Preliminary design to the final construction phase. Development
of this design for the selected options requires the following.
Inputs
– Outputs / deliverables from Preliminary Design Stage
– Re-confirm Functional Specification objectives and requirements
– Confirm hazard / risk review
– Comments log
– Detailed engineering
– Civil
– Track
– Hydrology / Drainage
– Signalling
Outputs -
– Detailed Design report.
– Finalisation of the selected (typically only 1) option

– Asset configuration and condition report / details
– Geotechnical report
– Environmental and contamination report – REF if required
– Services report / details
– Property report / details
– Construction specifications
– Safety in design report / details
– Project schedule estimate to a +/- 10% accuracy, including all design, procurement and
construction works
– Project cost estimate to a +/- 10% accuracy, including all design, procurement and construction
works
– Approved waiver or concession
– Maintenance analysis
2.10.6 Critical Design Review (CDR) / Detailed Design Review

The CDR is held at or close to the completion of the detail design stage to ensure that the design is
suitable for construction and meets the requirements of the design brief, specification and
client/customer requirements.
2.10.7 System Verification Review (SVR)

On Major Projects, a System Verification Review will be conducted on completion of the CDR by the
Project Manager with the Stakeholders to ensure that all verification and validation requirements of
the contract have been met (including testing where appropriate), to the extent that it is appropriate
to the contract task and appropriate to proceed to Design Approval and Acceptance. Stakeholder
review of the SVR is required prior to moving to design verification and approval - this is a substantive
Hold Point in the design verification process.
2.10.8 Design Approval and Acceptance

The nominated JHR CRN Project Manager will be responsible for final acceptance of the design and,
where appropriate, the subcontract task. Key requirements for acceptance of the project shall
include, but are not limited to:
– Availability of a completed and approved design that has been accepted by the appropriate
Principal Discipline Engineers
– Delivery of the required documentation in the formats specified within the contract
– Delivery and/or performance of all other requirements of the contract to the satisfaction of the
Project Manager.
Engineers holding an appropriate delegation of Engineering Authority shall be responsible for design
approval of all project design tasks within their area of responsibility, in accordance with the
requirements of Appendix I.
Project Managers shall be responsible for engineering (project) approval of minor projects, in
accordance with the scope defined in Appendix I. This approval follows design approval by
engineers holding an appropriate delegation of engineering authority and shall constitute JHR CRN

sign-off of the completed task prior to release of the design to the client for
construction/implementation.
Requirements for Engineering Approval of Major Projects shall be determined jointly by the Principal
Discipline Engineers, on a case-by-case basis.
Under normal circumstances, responsibility for design approval will be delegated to the senior
designer(s) in the Company responsible for the task. The Contract shall ensure that specific
processes for delegation of design authority to named individuals within the Contractors
organisation, in accordance with the general requirements of Appendix I.
Contracts shall also include a requirement for approval and certification of design output delivered
in satisfaction of contract requirements.
2.10.9 Temporary works Design

Where planned works involve any Temporary works construction, this work must be designed in
accordance with John Holland procedure JH-APP-DES-003-02 Pre-contracts – Temporary works
planning and design. This document sets out the requirements for development and management
of the temporary works design process. This includes scoping, design briefs, establishing project
temporary works registers, design verification and SQE requirements.
In advance of final design reviews, the construction planning personnel will review the tender concept
designs to determine temporary works design requirements. Temporary works design requirements
will evolve as the concept design emerges. It is integral with the design and construction review
processes.
Where external design consultants carry out the temporary works design, the project manager must
coordinate with the planning personnel, and prepare a Design Brief of temporary works design
requirements ensuring clear definition of the scope of work. The design consultants shall review the
brief and provide draft designs for review. The PM will convene meetings with design consultants
and construction planning, and cost planning personnel to review options and select the most
appropriate temporary works methodology and design, this shall be incorporated into the tender
documentation as applicable.
2.11 Other Design Outputs

2.11.1 Configuration Management
Other design output includes specifications, drawings, plans, calculations, test data and results,
which in combination fully describe the final design. Additional outputs include Configuration
Documents and Design Records, as further explained in CRN-PLN-ASM-003 Configuration
Management Plan. Preparation and delivery of appropriate levels of design documentation is
mandatory for all design sub-contracts. Specific requirements are defined in Appendix N
All design output shall be approved by an Engineer who has been granted Engineering Authority for
the scope of work performed, before the design is presented to the Principal Engineer for review and
acceptance. Refer to Appendix I for further information.
Configuration documents shall be incorporated in the configuration record for the asset item, system
or infrastructure installation. This will normally include documentation that defines the “for
construction” standard as well as “as-built” documentation that describes the design of the equipment
actually fielded. Design records that provide traceability of design decisions shall be maintained for
all design tasks.
All design tasks shall include configuration management requirements to ensure that:
– Design documentation delivered fully and accurately defines the asset, infrastructure item or
system, at “For-construction” standard.
– The documentation can be directly incorporated into JHR CRN configuration documentation. This
shall be accomplished by defining the scope, format and numbering requirements for the
documentation in accordance with the general requirements as detailed in full in Appendix N.
– Change control requirements provide the basis for managing all proposed departures from
specified requirements. Appendix N covers requirements for management of design changes
during new infrastructure projects.
– CRN-PLN-ASM-003 Configuration Management Plan sets out general requirements for
configuration management of JHR CRN infrastructure.
– CRN RM 005 covers the Rolling Stock/Plant Configuration Change Process
2.11.2 Maintenance Analysis

Design tasks should include a requirement for the Contractor to complete an analysis of maintenance
requirements and to provide a recommended set of maintenance tasks and inspections. Where a
TMP exists and there are no new components, the requirement can be waivered by the Principal
Discipline Engineer.
Maintenance analyses should be based on Reliability Centred Maintenance (RCM) methodology
and should be supported by a Failure Modes, Effects and Criticality Analysis (FMECA). A full
description of this process is included in Appendix H – Reliability, Maintainability and Availability
Maintenance requirements, task lists and supporting analyses should be delivered as part of the
documentation for the project and reviewed by the Principle Engineer for the discipline concerned.
Unless it is not cost effective to do so, the maintenance analysis should be presented in a format
that is compatible with the software application maintained within Engineering Services, to enable
the information to be added to the JHR CRN database. Appendix P includes further information
about maintenance required.
2.12 As-Built Design records

“As-built” configuration documentation shall be created and maintained for all design work. This
provides the basis for all subsequent changes and is essential for determining supportability
requirements, such as operating instructions and manuals as well as maintenance requirements,
spares and training needs.
Where IFC designs are utilised during construction, a package of approved As-built records will be
provided by the authorised designer as per the requirements of the Sub-contract - where external
resources are to be engaged to deliver design documentation.
Red line mark-ups and As-built drawings will be delivered by the Project Manager as part of the
project completion documentation to document the as-built configuration of the IFC design.
Red Line Mark-ups
– Redline mark ups are a short-term temporary solution until final As-Built drawings are developed.
– Are used to record the changes that occurred during construction, these can be hand drawn or
electronically annotated over IFC drawings
– Should include details of any RFI’s or sketches provided by designers to project engineers during
construction for clarifications

– Workshop drawings provided by suppliers for elements of the construction should be added to
the back of the set of As-Built drawings – no need to redraw these in CRN format
As Built Drawings
– The official record drawings that document what has been constructed.
– Are required for all construction projects, particularly where a detailed design or standard design
has been utilised for new, upgraded or modified discrete assets (bridges, culverts, level crossings,
retaining walls, drainage, platforms, buildings etc.)
 For continuous assets such as track, as built drawings may not be required provided as built
survey information is captured
 Some projects a simple survey detail will suffice as an as-built – (i.e. road works, pipe laying,
drainage etc.)
– Should be completed within 2 months of practical completion.
– The as built changes (red lines) should be notated on the drawings via a cloud bubble or other
method to highlight the change from IFC
– Where standards drawings are used, details of the site need to be added to the as built such as
locality, KM, line, asset ID etc.
– All IFC drawings in the set should be updated to As Built status to the next revision irrespective
of any changes (red lines) to individual sheets
– An ‘As Built’ status box is to be added next to the Design Accepted box, with Name, Title and
Date of Project Manager – signature in script font
– The Design accepted box will need to be updated to signature in script font – moving away from
hand signatures
– The as built drawings and CAD files are then to be added to the civil drawing register
The requirement to supply As-built documentation should be listed as a deliverable in the scope of
works. All Redline mark-ups and As-Built drawings will be submitted in the same format as the
original design and in a format that meets the requirements of JHR CRNs CAD procedure.

Appendix A
Definitions and Terms
Appendix B
Roles and Responsibilities
Appendix C
Engineering Specifications
Appendix D
Requirements Analysis,
allocation & Traceability
Appendix E
Design Standards
Appendix F
Interface Definition and
Management
Appendix G
Hazard and Risk Analysis
CRN-MAN-ENG-001 Appendix H
Design Management Reliability, Maintainability &
Manual Availability
Appendix I
Design Approval
Appendix J
Design Verification
Appendix K
Design Validation
Appendix L
Technical Design Reviews
Appendix M
Design Change Management
Appendix N
Design Documentation &
Records
Appendix O
Integrated Support
Requirements
Appendix P
Maintenance Requirements
Analysis
Figure 3

Appendix A Definitions and Terms
This Appendix includes a list of Acronyms and Abbreviations used within the Manuals. Terms having
specific importance within this Manual are reproduced below.
Acronym & Abbreviation Definitions
Activity Method Statement (AMS) Linked to the WRA. The AMS considers risks and
controls at an activity level. It is a component of the
JHR SQE RM process
Administrative Controls Means controls, which use systems of work to

eliminate or reduce risks to health or safety and do not
involve engineering controls or the use of personal
protective equipment.
Asset In the context of this document, an asset shall be taken

to mean a piece of equipment or plant, which has value
and requires management of its design, acquisition,
maintenance, configuration change and disposal.
Availability Availability is the measure of the percentage of time that
an item or system is available to perform its designated
function.
Customer, Client or end user requirements The responsible Project Manager assigned to the task
shall ensure that the Client’s requirements are
specified in sufficient detail to establish clear output
requirements for the task. Wherever possible this
should be in the form of an Engineering Specification
prepared by the Client that can be agreed before the
task begins.
Design (verb) Is defined as “the process of defining, synthesising,

selecting, and describing solutions to requirements in
terms of products and processes”.
Design (noun) is defined as “the product of the process of designing
that describes the solution (either conceptual,
preliminary or detailed) of the system, system elements
or system end items”.
Design Approval is the process whereby an authorised person certifies
that design outputs have been verified as meeting
design input specifications and requirements and that
the design has been completed in accordance with
relevant Regulations and Standards, prior to the
release of the design for construction or use. All
design output shall be approved prior to release by a
suitably qualified and authorised engineer acting under
delegation from the Principal Discipline Engineer.
Design and Configuration Records A record shall be maintained for all design output, to
show the current approved configuration of all
assets/infrastructure and the design basis for this
configuration.

Design Change Request/Notice A Design Change Request/Notice (DCN) refers to the

form used for processing and approval of design
changes during project development. A DCN is used
during design and development of projects and is
functionally equivalent to a Configuration Change
Request (CCR) submitted to change the approved
configuration of existing infrastructure. (See Appendix
M).
Design Brief A Design Brief is functionally equivalent to a Client
Specification and, once agreed by the client, will have
the same status as a Client Specification. The Design
Brief should be prepared to reflect the JHR CRN
understanding of the requirements of the intended
design. It must include all Standards and
requirements called out in applicable Legislation and
Government Regulations, as well as all key design
parameters necessary to execute the task. These
include the intended conditions and limitations of use,
for approval by the Client. As a minimum, the Design
brief must include:
– Performance requirements for the item to which the
task applies,
– Intended use, including maximum loads or
operating condition, duty cycle, operating
environment and required design life.
– Interfaces with existing equipment,
– Reliability and availability specification and
maintainability requirements.
– Any other special requirements including alternative
design standards (where these differ from JHR
CRN Standards) or other Regulatory requirements.
Design Standards All design work shall be performed to the relevant
Federal and State Legislation and Regulations or to
Standards approved by JHR CRN. Federal and State
Legislation and Regulations shall have precedence
over all other requirements. See Appendix C.
Documentation All design outputs shall be fully and properly
documented.
Engineering Approval The term “engineering approval” is used within these

Procedures to describe the process of approval of a
broad range of engineering decisions and
documentation including maintenance, support and
related decisions. Design approval is a subset of
engineering approval.
Engineering Authority Is the authority to make and approve engineering
decisions. The scope of engineering authority may
extend to the preparation and approval of
specifications, detail design proposals, construction
and maintenance processes and standards, as well as
products and systems used within the engineering
support task.

Engineering Controls Means controls, which use engineering measures to

change the physical characteristics of plant to eliminate
or reduce risk.
Engineering Design Requirements Design output requirements must be fully specified, in

accordance with the general requirements of Appendix
C.
This includes both Engineering Specifications for
products and management requirements for design
tasks, as follows.
– Hazards and risk analysis plans and reports as
defined in Appendix G.
– Reliability program plans and reliability predictions
as defined in Appendix H
– Integrated Support Plan, including maintenance
analysis and Technical Maintenance Plan
requirements. Refer Appendix P.
Engineering Specifications Specifications can generally be divided into two major
types
– Performance (Functional) Specifications: focus on
the functions and performance requirements to be
met by the final design. Performance specifications
do not include a high level of information covering
the detail design requirements for the item i.e. they
do not specify “how to” carry out the design task.
– Detail Specifications: generally used for developed
items, systems, processes or products and provide
a detailed description of the design solution.
In accordance with the general requirements of
Appendix C, specifications must include safety,
environmental and supportability requirements as part
of the design criteria for the task. The specification
shall also include specific requirements for verification
and validation, in accordance with the general
requirements of Appendix J and Appendix K.
ETA Event Tree Analysis
FMECA Failure Modes, Effects and Criticality Analysis
FTA Fault Tree Analysis
Hazard Source or situation with a potential for harm in terms of
human injury or ill-health, damage to property, damage
to the environment, or a combination of these.
Hazard Log A log of Hazards identified as associated with the life
cycle of the asset, which is used as input into the Risk
Analysis. The Project Risk Register and Subsidiary
Risk Registers are used as sources of hazards and
existing controls which are then further developed.
Hazardous Event Event which can cause harm.
Hazard Identification Process of recognising that a hazard exists and

defining its characteristics.

Integrated Support Integrated support requirements shall be considered

both as part of the detail design effort and prior to the
release of new or modified equipment to the field.
JHR SQE RM The risk management processes structured to ensure

all risks to safety, quality and environment, at strategic,
operational and team and individual levels, are
effectively identified, documented, assessed, controlled
and monitored. These are defined in the procedure
CRN-MPR-SQE-001 Managing SQE Risks
Maintainability Maintainability is a characteristic of design and is
essentially a measure of the ease with which the item
can be maintained. A more formal definition is
Maintainability is a characteristic of design and
installation, expressed as the probability that an item
will be restored to operating condition, within a given
period of time, using prescribed procedures and
resources.’
The most commonly used measure of maintainability is
the Mean Time to Repair (MTTR).
Minor Task A minor task is one that can be completed in less than
40 hours of design effort and can either be completed
entirely within one discipline or requires only minor
inputs from other disciplines. Telephone inquiries and
processing of simple design changes or repair
schemes are examples.
Minor Project Minor Projects are those where: The expected design
completion time is assessed as between 40 and 150
hours of design effort, and/or a significant level of
design input is required by two or more disciplines
Major Project Major projects are those where:
The expected design completion time is estimated to
exceed 150 hours of design effort, and/or a substantial
level of input is required by two or more disciplines,
and/or a safety critical system is involved, or new/novel
technology is being applied to a safety critical system
and/or the complexity of the project e.g. New Train
communication system is assessed as requiring major
project planning and reporting disciplines and visibility.
MIMIR FMECA software package allowing optimal
management of all likely failure modes of a given
system or asset.
Process Control Plan Instructions for performing a specific job or task so as
to prevent harm to individuals, plant and the
environment through control of identified hazards.
Principal Risk Register (PRR) A register of the high level hazards, contributing factors
and controls applying to the operation of the JHR CRN.
The PRR is used as a source document to identify
hazards and controls.

Plant Plant includes rolling stock, any machinery, equipment

(including scaffolding), appliance, implement or tool
and any component or fitting thereof or accessory
thereto
Railway Infrastructure Infrastructure of a railway is defined within the NSW
Rail Safety Act 2008, as consisting of those facilities
that are necessary to enable a railway to operate
safely and includes, but is not limited to, railway track,
associated track structures; service roads, signalling
systems, communication systems, rolling stock control
systems and data management systems; notices and
signs; buildings, workshops, depots and yards; plant,
machinery and equipment.
Reliability Reliability is a characteristic of design. It is defined as
the ‘probability that a specified item will perform a
specified function within a defined environment, for a
specified length of time’. For complex systems the
reliability requirement is normally specified in terms of
the Mean Time Between Failures (MTBF) or as a
failure rate, e.g. failures per million operating hours.
Reliability Centered Maintenance (RCM) Involves the application of the principles of reliability
theory within a structured process designed to identify
effective maintenance and inspection tasks that will
detect or delay failures of the equipment.
Risk Combination of the frequency or probability of

occurrence and the consequence of a specified
hazardous event.
Risk Analysis Systematic use of available information to identify
hazards and to estimate the risk to individuals or
general public, property or the environment.
Risk Control Process of decision making for managing and/or
reducing risk: its implementation, enforcement and re-
evaluation from time to time, using the results of risk
assessment as one input.
Specification Performance requirements and standards shall be
specified for all design tasks. JHR CRN has adopted
the following definition
“A document that fully describes a design element or
its interfaces in terms of requirements (functional,
performance, constraints, and design characteristics)
and the qualification conditions and procedures for
each system element.”
Start Card A formatted check list completed by all staff and
contractors prior to commencement which acts as a
last check that the task can be undertaken safely.

Task Risk Assessment A step in the SQE RM process where the tasks to be
undertaken are reviewed in the field by staff
undertaking the task to check that hazards have been
properly identified and assessed and that the proposed
controls are effective. The TRA is used to capture any
modifications required due to site constraints
subsequently identified and form a component of the
site briefing.
Validation Design validation is the process of ensuring that the
final product conforms to defined user (client) needs
and/or requirements. (AS/NZS ISO 9001: 2008).
Variance A Variance (alternative terms are Deviation, Waiver,
and Concession) is used to approve a departure from
the approved “For-Construction” design baseline.
Variances are normally approved for a specific number
of items or for a limited period. If a Variance is to be
permanent it must be processed as a DCN.
Verification The verification process is carried out to ensure that
the output of a design stage (or stages) meets the
design stage input requirements. (AS/NZS ISO 9001:
2008).
Workplace Risk Assessment (WRA) A high level assessment of hazards, risks, and controls
associated with a scope of works. It is a component of
the JHR SQE RM process.

Appendix B Roles and Responsibilities
All JHR CRN staff and contractors performing or managing engineering design work, including
integrated support analyses in support of design, are responsible for completing their tasks in
accordance with this Manual and related appendices within this Engineering Management Manual.
All Persons holding Engineering Authority to carry out or approve design tasks for JHR CRN are
responsible for managing, completing and approving design tasks in accordance with this Manual
and related appendices within this Engineering Management Manual.
– Manager Engineering Services
The Manager Engineering Services is responsible for the overall implementation of the
engineering management system and for improvement of the system to meet JHR CRN
obligations.
– Project Managers & Discipline Design Leads
Project Managers & Discipline Design Leads shall be responsible for:
Ensuring that policies and processes defined within this Engineering Management Manual are
fully implemented within their area of responsibility.
The implementation of policies set out in this Manual.
Project Managers have an overall responsibility for the delivery of projects to meet client
requirements, on time and within budget. Responsibilities include the following specific tasks, in
accordance with the detailed requirements of this Manual:
 Establishing an agreed scope for projects, in consultation with the client and with the Principal
Discipline Engineers involved
 Ensuring the proposal has had Configuration Committee Approval and conditions imposed by
the Configuration Committee are met and closed out
 Preparing a WBS for Minor and Major Projects
 Establishing Work Orders for the project
 Arranging for the preparation and submission of an Offer of Service, including the coordination
of engineering input
 Arranging for resources after approval of the Offer of Service
 Acting as the primary point of contact with the client
 Identifying and arranging for the preparation and execution of variations to take account of
changes in scope
 Project monitoring and reporting
 Project approval and sign–off for Minor Projects, including stakeholder approvals
 Project closure and handover.
 The requirements identified in this Manual are incorporated into all design contracts, to the
extent applicable to the task covered by the contract
 Contract deliverables are provided when due and that they are of an appropriate standard
 JHR CRN staff support design management processes identified in each contract, such as
technical reviews

 Design documentation provided under the contract is accepted by the appropriate JHR CRN
Principal Discipline Engineers, prior to final acceptance of the project task.
– Business Unit Managers
Will generally be senior managers who will be or will represent the client and have a business based
understanding of the proposal. They will monitor the progress of the proposal and assist in liaison
and communication with the CRN Senior Management Team, Clients and Project Manager.
– Technical Advisors / Subject matter Experts (SME)
JHG CRN Engineers and or consultant engineers with delegated authority from Principal Discipline
Engineer - responsible for the review and approval of scopes, specifications, comments logs,
technical queries and management of Design changes throughout the design development process.
– Other Managers and Engineers
Responsibilities for other Managers and members of design teams are defined within the body of
this Manual.
– Contract Designers
Contract Designers are responsible for complying with the requirements of the Manuals and the
requirements contained within the Design Agreement
– JHR CRN Principal Discipline Engineers
JHR CRN Principal Discipline Engineers are responsible for acceptance of designs on behalf of JHR
CRN and issue and management of Engineering Authority for Designers, technical advisors and
other Subject Matter experts.

Appendix C Engineering Specifications
C-1 Types of Specifications
Specifications can generally be divided into two major types:
– Performance (Functional) Specifications: focus on the functions and performance requirements
to be met by the final design. Performance specifications do not include a high level of information
covering the detail design requirements for the item i.e. they do not specify “how to” carry out the
design task.
– Detail Specifications: generally used for developed items, systems, processes or products and
provide a detailed description of the design solution.
Performance specifications provide a degree of flexibility to the designer on how the Clients’
requirement will be met. This provides the opportunity for the designer to adopt new methods and
technologies to meet the Clients requirements which are expressed in terms of the outcomes to be
achieved, rather than the detailed method to be adopted.
Detail specifications limit the options available to the designer in meeting Client or project
requirements. They are typically used where there is a requirement to replicate a specific design
that has been previously been developed and proven for the specific application for which it is
to be used, e.g. to acquire replacement items or for standardisation.
The use of detailed specifications, including JHR CRN Standards (specifications or designs), is often
not appropriate for new design tasks (unless used for sub systems or components to be incorporated
into the design solution). While the design principles may remain valid for the new application the
design basis must be verified against Client or project requirements in every case, before a decision
is taken to adopt previously developed solutions.
All specifications include some specific requirements, irrespective of whether they are of the
Performance or Detail type. However, the primary difference between the two types is the level of
prescription placed on the designer by the Client, where a detail specification is effectively a
“solution” to a set of functional requirements. This essential difference can be illustrated by the
comparison at Table 1.
Table 1: Comparison between performance and detail specification requirements
Characteristic Performance Specification Detail Specification
Corrosion The item shall be capable of operation The item shall be constructed of 18-8
Resistance in corrosive environments (specify). grade stainless steel.
Reliability The system shall achieve an MTBF of The system shall incorporate redundant
24000 Hours when operated within the widgets in all circuits.
specified environment.
Environmental The item shall withstand temperatures The item shall be fitted with thermal
Design Criteria ranging from –20°C to + 60°C without insulating blankets and a fan capable of
damage (specific output).

C-2 Specification Hierarchy
Some tasks will require more than one specification to fully define design input requirements and/or
as part of the documentation that describes the final design.
A typical hierarchy of specifications is shown in figure 4 below. This includes specifications of
different types that collectively define the performance requirements and characteristics of the
design.
Performance
specification
Software Interface
Detail technical
development specifications or
specifications
specifications drawings
Product or
Software product
process
specifications
specifications
Figure 4: Specification hierarchy
The following table provides a summary description of the types of specification and potential uses
within JHR CRN.
Table 2: Types and uses of specifications
Specification Primary Characteristics and Use Primary Examples

Type
Performance Used to define the operating performance and Establish key operating
Specifications characteristics of complete systems, sub-systems parameters for new
or items. Generally used for development of a new infrastructure.
system, sub-system or item.
Detail Used to define the detailed technical requirements Development specifications
Specifications / of sub-systems or items. Generally used for new for inclusion in an RFT.
Software development of an item or sub-system. Specifications for
Development development of a new JHR
Specifications CRN standard item.
Product Used to define detailed technical characteristics of JHR CRN Standards
Specifications developed items, processes or materials. Particular Specifications
Generally used for further procurement of
Material Specifications.
equivalent items or to define specific requirements
or characteristics within a Functional or Detail Specifications or Drawings for
Specification. Standard Designs

Specification Primary Characteristics and Use Primary Examples
Type
Interface Used to define physical or functional requirements Wheel-Rail Interface

Specifications for one system, sub-system, or item to operate with Hardware-Software Interface
or to attach to another. Generally used where a definition
new item is to be developed and is to be integrated
with the existing system. May be a formal
specification or a drawing.
C-3 Design Tasks to be Specified

A specification statement shall be established for all design tasks performed within or for JHR CRN.
Confirmation that the task has been adequately specified is required before the task is accepted, in
accordance with the requirements of this Manual.
The specification may be documented in one of several forms:
– A formal specification provided by the Client
– An internal JHR CRN Specification, for use when developing new standard designs or to
document the characteristics of standard items, materials or processes to be used or acquired by
JHR CRN
– A design brief prepared by JHR CRN Project Manager for Client tasks, where no formal
specification has been provided
– A design Statement of Intent, for use when completing minor design tasks resulting from a CCR,
or similar
– Each category may include Interface specifications.
C-4 General Characteristics of JHR CRN Developed Specifications

All specifications prepared for JHR CRN shall include, or shall take account of, the following general
requirements. All specifications must:
– Provide a clear and concise statement of the purpose of the system or item to be designed or
procured.
– Incorporate mandatory design standards required under Workplace Health & Safety Act &
Regulations.
– Incorporate the requirements of JHR CRN design standards, except where these are in conflict
with Workplace Health & Safety Act & Regulations. See Para 3.3.5 for the order of precedence
between standards.
– Include information on tests or other methods for validation of the design. See Appendix J.
– Include requirements for pre-delivery and acceptance testing of individual items or batches, where
applicable.
– Include requirements for production records and other documentation to be delivered with each
item / batch, to facilitate receipt inspection and acceptance of the product.
– Include requirements for identification and marking, where appropriate.
– Include a Type-Approved Products List (where appropriate).
Engineering Specifications should be confined to engineering requirements. These include test and
documentation for product validation and traceability purposes. Engineering Specifications should
not normally include commercial terms and conditions, such as price, delivery, warranty or other
contract performance requirements, such as project reporting, contract variations and so on.
Commercial conditions may vary over time and between suppliers and do not form part of the
permanent design record. They should be included in the purchase order or contract used for the
design task or procurement.
C-5 Precedence of Standards

The following precedence shall apply within Engineering Specifications prepared by JHR CRN and
/or within the design task:
– Standards required by Workplace Health & Safety Act & Regulations or other relevant Legislation
shall prevail over all other requirements, to the extent that they are applicable to the product or
application covered by the specification.
– JHR CRN Standards, where the use of a JHR CRN Standard is appropriate for the application.
JHR CRN Standards will normally be used for design projects performed for internal Clients, but
the use of JHR CRN Standard designs or Items must be verified in every case, in accordance
with the requirements of Appendix E.
– Standards specified by the Client (such as Australian or International Railway Standards), where
these are appropriate for the application,
Australian or International Standards may be substituted for those listed at sub-paragraph 2, above
provided that:
– The Australian/International Standard is at least equivalent to the JHR/CRN standard, and
– Principal Engineer approval is obtained for the substitution.
C-6 Client Specifications

Client specifications will normally be provided at the time that a design task is requested. The
Specification may contain either a functional or detail set of requirements and should normally be
accompanied by a clear statement of the scope of the design task ie including specific deliverables,
documentation requirements, reviews and so on.
Client Specifications represent a statement of what the Client wants and expects within the final
design. Additionally, they form the basis for an agreed price or cost budget for the task.
JHR CRN Project Managers and designers are to carry out a detailed review of Client specified
requirements before the commencement of all design tasks, in accordance with the general
requirements of Section 2 of this Manual. This is to include a review of all mandatory requirements
imposed by Government Legislation & Regulations, as well as a review to determine whether all
essential information has been provided, to establish an adequate basis for the design task e.g.
environmental design requirements.
Requirements of Client specifications shall only be varied after formal approval by the Client (in the
form of an Approved Design Change and/or Contract Change).
Proposals for change shall be raised where:
– Mandatory Legislative or Regulatory requirements have been omitted
– Key design parameters have not been defined
 There is a conflict in requirements that must be resolved before the task can proceed or be
completed.
Proposals for change may be raised by design staff where a more cost effective approach has been
identified. Examples of this include the use of existing design solutions (standard designs or qualified
standard items) where the alternative is assessed as meeting the Client requirement at lower cost,
or where a slight variation in specified performance may yield significant savings and/or
improvements in performance.
Processing and approval of Design Change Requests forming part of a contract task is covered by
Appendix N.
C-7 JHR CRN Standards and Specifications

a. Specifications for JHR CRN Standard items
Formal Specifications shall be prepared, approved, issued and maintained for all JHR CRN
Standard Items and Designs.
Specifications for JHR CRN Standard Items and Designs shall include the general
requirements covered by Section 3.3.4.
Specifications for JHR CRN Standard Items and Designs shall be approved by the appropriate
Principal Discipline Engineer prior to release.
All JHR CRN Standard Items and Designs shall be subject to comprehensive type testing and
validation, as defined in Appendix J. The Specification shall be formally revised to reflect
intended permanent changes in physical or functional performance requirements, including
permanent changes arising from type testing.
b. HR CRN Statement of Design Intent
A Statement of Design Intent is typically used to define the purpose of minor design changes,
such as those arising from a CCR.
The Statement of Design Intent may be recorded within the design files for the CCR but in all
cases must provide a clear engineering definition of what the change is intended to achieve.
Engineering definition of the purpose of a change is different to the problem statement or
general purpose of the request submitted by the Client or user of the equipment. Preparation
of the Statement of Design Intent will generally only be possible after initial evaluation of the
CCR and selection of a probable strategy for correcting or improving the reported condition.
However, it represents an important element within the design record for the equipment and
provides the basis for assessing the effectiveness of the change following implementation.
C-8 Interface Specifications

Interface specifications shall be prepared to define the physical and functional connection between
systems, sub-systems and items. The specifications may be:
– Documented within a formal, separate specification
– Specified on a drawing, either as a separate drawing or by the inclusion of interface details on
another drawing
– Included in a Specification or drawing, where the item concerned must interface with existing
infrastructure installations.
Interface specifications shall be incorporated in the configuration documentation for the item or
system concerned and shall be maintained up to date to reflect changes in the design of items or
systems to which the interface specification relates.

The requirement for interface specifications also extends to information systems that are used to
record essential data for managing the design integrity of JHR CRN assets.
Additional requirements for definition and management of interfaces are contained in Appendix F.
C-9 Format and Identification

c. Format
No specific format has been mandated for project specifications developed by JHR CRN.
Identification and Control
All JHR CRN Engineering Specifications shall be assigned a unique Reference Number to be
assigned from a Register maintained within the Document Management System. Each
Specification shall be identified by:
˃ The Reference Number
˃ Issue, Revision Number and Date
˃ Title.
Each Revision shall be treated as a formal Engineering Change and shall be endorsed by the
responsible Principal Discipline Engineer and approved by the CRN Standards Configuration
Committee prior to release. Superseded versions shall be maintained as part of the design
record, in either hardcopy or electronic format.
C-10 Maintenance of Specifications

Specifications shall form part of the permanent design record for an item and are to be maintained
as part of the current approved configuration documentation for the item or system, in accordance
with the general requirements of CRN-PLN-ASM-003 Configuration Management Plan.
Specifications should only be changed or amended where there is a permanent change intended in
the design requirements for the item, e.g. a change in operating temperature range. In such cases
the effectivity of the change must also be included e.g. to all equipment manufactured or purchased
after a specific date or with Serial Numbers greater than “XX”.
Temporary variations from specification requirements e.g. where a specific batch or design does not
meet the one or more requirements of the specification but is assessed as acceptable for the
intended use, should be documented as a Variation (Deviation or Waiver).

Appendix D Requirements Analysis, Allocation and
Traceability
D-1 Process Application
The primary purposes of the requirements analysis, allocation and traceability process to be applied
for JHR CRN design tasks are to ensure that:
– Design requirements are clearly identified before the task commences
– Each requirement is allocated to one or more systems and sub-systems to establish specific
requirements for each system and to ensure that all functions and performance requirements
have been taken into account
– A framework is established for validation of the final design solution
– Traceable records are provided that can be used to demonstrate that all requirements have been
considered during the design process and that the final solution has been validated.
The process is normally applied in three distinct but continuous stages. The scope, level and
complexity of each stage varies considerably between major and minor projects. However, the
principles set out in this section apply equally to all design work and must be applied for all design
tasks, to the extent described under individual headings.
Requirements analysis normally begins during the assessment of a design/development task to
assist in preparing an estimate or quotation or as part of a task to develop a concept design for an
internal JHR CRN Client e.g. an operating section. It involves a detailed review of the specification(s)
to identify all operating and performance characteristics to be met by the final design as well as initial
assessment of ways of meeting the requirement and the risks associated with compliance. The
process is completed as the first design activity following acceptance of a design task within JHR
CRN, or the award of a design contract to an external company, when final requirements have been
established.
Requirements allocation represents the first stage of design synthesis and is generally completed
in conjunction with initial planning of the system architecture within either the concept or preliminary
design phases. It involves an assessment of the functions, physical/performance characteristics and
outputs that must be delivered by individual systems, sub-systems and items to meet the
requirements of the specification (design inputs). The end result is determination of “how” each
individual requirement of the specification will be met within the final design and allocation of each
requirement to one or more systems and items. The process must continue until all relevant
requirements have been identified and allocated.
Traceability records provide the link between specification requirements and the results of tests or
other methods used to validate the final design. Creation of a traceability record from the outset of
the design process provides the basis for system validation (test and commissioning plans) and
provides the main documentation to support the Systems Verification Review conducted at the
completion of major projects.
Each aspect of the requirements analysis, allocation and traceability process is described in more
detail in the following paragraphs.
D-2 Requirements vs. Solutions

Clear differentiation between requirements and solutions is a key consideration in the requirements
identification process.

Requirements establish specific outputs (level of performance or characteristics) to be achieved by
the new design or design change to meet the intended purpose. Examples of requirements are:
– “Track components shall be designed for a speed of 115 km/h”
– “Safety Factor for supplementary conductors & other wires shall be 2.5 (Min.)”
– ‘Design life of the bridge shall be 100 years”
– “Improve reliability of Item X to achieve an MTBF of 25,000 hours”
– “All structures shall be galvanised to Specification “XXX”.
Requirements are typically (but not consistently) identified in specifications by use of the term “shall”.
Other terms, such as “should” or “may” indicate that the specification statement is desirable but not
mandatory.
Solutions define the method by which the objective will be achieved. In many cases there will be
more than one way to achieve the requirement, possibly at different costs and with different levels
of effectiveness.
The requirements identification and allocation processes must focus on requirements, so that design
staff has a clear understanding of the outputs to be achieved by the design and able to assess
alternatives and to understand and assess the implications of the change.
Relevant
Customer / user standards & other
specification compliance
Requirements analysis
requirements
Functional &
Validation
performance
requirements &
requirements
methods
to be met by
design output
Allocate functions
Traceability
and requirements
to systems, sub-
systems &
Requirements allocation
configuration
Establish
items
additional
(derived)
requirements &
characteristics of
design solution Establish
design &
validation
requirements
database
Figure 5: Requirements analysis, allocation and traceability
D-3 Requirements Analysis

All design work performed for JHR CRN shall be carried out to meet Client requirements. To ensure
that this is achieved the first stage in any design task shall be to analyse the specification for the
task and to document specific operating and performance requirements for individual elements of
the design.

The initial requirements analysis process should also be used to establish validation requirements
and methods, where these are specifically identified within the specification and where it is possible
to do so.
Major Design Projects
Requirements analysis for major projects must be undertaken using a top-down approach,
particularly where the project involves the design and integration of multiple infrastructure systems.
This is necessary because some specifications include general sections that apply to the system as
a whole i.e. are not related to individual items or elements of the design, which must be “flowed
down” to individual systems and sub-systems. Examples of this are:
– Overall system performance requirements such as transit times and maximum design speed
– Reliability and maintainability requirements that are grouped in other than system terms
– Design life
– Environmental design criteria. Environmental design criteria generally relate to either the natural
or the built environment and include aspects such as the operating temperature range, exposure
to ultra-violet radiation, wind, rain, vibration, humidity, EMI/EMC under which the item or system
is designed to operate.
The requirements analysis may be performed manually or with the aid of Computer Aided Systems
Engineering (CASE) tools (if available). Whichever method is adopted the essential outcome is to
ensure that design requirements are clearly identified and documented, for the project being
undertaken.
This is necessary even when the proposed design concept and approach is based on the application
of “standard” designs and the use of type approved equipment to the maximum possible extent.
The use of standard designs represents the preferred approach, where it is appropriate and cost
effective to do so. However, all design staff have an obligation to ensure that the use of a “standard”
design approach:
– Is consistent with the functional and performance requirements specified by the Client/user, and
– Represents a cost effective solution. In particular, it is essential to ensure that the use of standard
designs does not result in solutions that are substantially in excess of user requirements and
which will lead to both increased initial construction costs or to increased support costs.
Responsibility for requirements analysis may be approached in different ways within different
projects. However, it is essential for each design discipline to review the entire specification,
including general sections, to establish the full set of requirements that are applicable to a particular
system or item within each discipline.
Requirements should be grouped by individual systems and, where appropriate, sub-systems to
ensure that all requirements applicable to each system/sub-system are taken into account in
developing the design.
Interface requirements shall also be considered and documented as part of the requirements
analysis process. These interfaces may be between systems or sub-systems within the same
discipline, between systems managed by different disciplines, or with systems/requirements
managed by external agencies. Each identified interface represents one or more design
requirements to be taken into account within the final design solution and will often represent a
constraint on the solution adopted. Management of interfaces is further covered in Appendix F.

Discipline Design Leads and Engineers responsible for completing or supervising design shall
ensure that this review is carried out for design tasks that are within the responsibility of the discipline
concerned. Ignorance of a specification requirement, or failure to review all applicable requirements,
does not absolve design staff of the responsibility for compliance and validation of the design to the
full set of requirements.
Requirements Analysis – Minor Design Projects
Developing a clear understanding of design requirements and objectives is equally essential for
minor design tasks as it is for major projects. In many cases it will be even more critical, particularly
if a Configuration Change Request (CCR) is expressed in terms of a solution rather than as a
requirement.
In most cases, the process for minor projects and design changes will be limited to identifying those
specific characteristics of the design that are to be affected by the proposed change. This includes
potential changes to specific items and the effect on internal or external interfaces within the existing
design, in order to meet altered performance requirements and objectives for the change.
Requirements for minor changes must also include new validation or re-validation requirements for
items affected by the change. This will be necessary in every case where the performance envelope
or conditions of use are to be changed (or where the performance envelope for the section of the
infrastructure affected by the change is not properly documented or is uncertain).
Proper evaluation of requirements for minor projects and CCRs represents an essential step in
creating/maintaining accurate configuration management and design records for the infrastructure
system. Recording the purpose of each change or addition to the system, as well as the detail
changes made to the approved design configuration, is not only essential for documenting the
current approved configuration but for assessing the impact of future changes. CRN-PLN-ASM-003
Configuration Management Plan sets out more detailed requirements for Configuration
Management.
D-4 Requirements Allocation

The flow down of requirements from the specification to individual systems, sub-systems and items
is illustrated in the simplified diagram in Figure 6 below.
Allocation of requirements to individual systems, sub-systems and items is a continuation of the
requirements identification process. The primary objective is to ensure that all specific and common
requirements, including interface definitions, are established for each sub-system and item as
appropriate.
The diagram in figure 7 shows only the first level of allocation. Functions to be met at the sub-system
level will clearly need to be met by one or more items comprising that system or sub-system. The
allocation process may need to be extended by one or more levels to provide a comprehensive
picture of the requirements to be met by the design of each item.
Requirements allocation must take account of the application of “common” requirements to individual
systems and items and may lead to the identification of “derived” requirements and corresponding
changes in system architecture during concept development. For example, a requirement for the
system to continue operation for a period following mains power failure may lead to the requirement
for a UPS as well as appropriate sensing and switching functions in one or more hardware/software
elements.

Product
specification
Sub-system 1A Item 1A-1
Item 1A-2
Item 1-1
Item 1A-3
Requirement 1
Item 1-2
System 1
Requirement 2 Item 1-3
Item 1-4
Requirement 3
Interface
Requirement 4 requirements Sub-system 2A Item 2A-1
Requirement 5 Item 2A-2

Item 2-1
Item 2A-3
Requirement 6
Item 2-2
System 2
Requirement “X” Item 2-3
Item 2-4
Figure 6: Requirements Allocation
D-5 Documentation of Requirements — Traceability

Documentation of requirements and the allocation of each requirement to one or more systems, sub-
systems or items shall be carried out progressively as the analysis is performed.
The scope of the documentation required will be a function of the complexity of the project, the
number of major systems/disciplines involved and the number of requirements. Similarly,
documentation methods will be influenced by the tools in use within a major project, e.g. the possible
use of CASE tools.
Where CASE tools are not being used, a relatively simple spreadsheet may be used to establish
traceability records for both major and minor design tasks. The spreadsheet provides a permanent
record of the set of requirements to be met, the allocation of these requirements to individual
systems/sub-systems as well as a basis for tracking the status of validation requirements.
A matrix in this form shall be prepared for all but very simple changes, e.g. where the design action
can be recorded on the CCR documentation raised for the item.
The completed matrix is to be maintained and filed as part of the design record for the item or system
concerned.

Appendix E Design Standards
E-1 Approved Standards
All design work performed by JHR CRN shall conform to approved standards.
Standards to be used for JHR CRN design work shall be:
– JHR CRN Standards
– Australian Standards
– Equivalent National or International Standards for railway infrastructure.
E-2 Selection and Use of Australian and International Standards

The Project Manager shall consult with the JHR CRN Principal Discipline Engineer who will confirm
the selection and use of the appropriate Australian and/or International standards for individual
design tasks, taking account of:
– The requirements of an Engineering Specification provided by the Client
– Requirements for compliance with NSW State and Federal Legislation and Regulations, including
Workplace Health & Safety Act and Regulations, Environmental Legislation and Regulations,
Electricity Legislation and Regulations
– Additional requirements included in JHR CRN Standards that limit or otherwise amplify the use
of other standards for JHR CRN applications.
Discipline Design Leads shall review and confirm that the Standards are appropriate to the context
of the design.
E-3 JHR CRN Standards

Types of JHR CRN Standards
The JHR CRN has developed a series of internal Standards for use within the design of rail
infrastructure.
The set of JHR CRN Standards applicable to design tasks comprises four general types of
documents, as follows:
– Standards: These generally cover physical and functional performance requirements,
configuration, wear limits and failure conditions. They are developed as series for the various rail
disciplines and cover design, maintenance & construction.
– Manuals: These relate to the Standards but contain methodology for undertaking the
maintenance and construction tasks.
– Specifications: Cover the physical and performance characteristics required of materials, parts,
of components of Rail Infrastructure.
– Standards Designs/Drawings: These generally cover type approved designs that have been
developed for use in appropriate applications within the JHR CRN infrastructure. Standard
designs are typically documented in drawings (and specifications) and define the configuration of
items or installations that meet JHR CRN requirements for specific applications. Examples of
standard designs include certain types of bridges, turnouts. Standard designs may include
standard repairs and serviceability criteria for the relevant installation.

JHR CRN Standards are primary configuration documents within the JHR CRN system and the
master copy is maintained in the Document Management System. Current Approved versions will
be available through the JHR CRN Intranet & Extranet but are annotated as uncontrolled when
printed. The designer shall regularly check for updates and ensure that changes are tracked and
managed in the design process.
E-3-1 Preparation and Revision of JHR CRN Standards

The preparation, revision and management of JHR CRN Standards are detailed in CRN GM 002
Engineering Standards Development Manual.
Issues with Standards or suggested improvements shall be directed to the Principal Discipline
Engineers for consideration.
E-3-2 Verification and Validation of JHR CRN Standards

Verification and Validation requirements defined in Appendix J and Appendix K shall be applied in
every case for standard products and designs covered by JHR CRN Standards. This includes Type
Approval of new products and designs before the Standard is approved for use.
Verification and Validation records shall be maintained as part of the design record in support of the
Standard. Design records shall be maintained within the responsible design Section.
E-3-3 Approval of JHR CRN Standards

JHR CRN Standards shall be subject to the approval process detailed in CRN GM-001: Engineering
Standards System manual
E-3-4 Selection and Use of JHR CRN Standards

The existence of a JHR CRN standard does not mean that the item(s) covered by the standard has
been approved for universal application within the JHR CRN system.
Selection of items or designs that conform to either a JHR CRN Standard Specification or a Standard
design for incorporation in an infrastructure installation is itself a design decision. The decision must
take account of the suitability of the standard item or design for the intended application, including
the specific usage parameters and environment for the application.
Similarly, replacement of one type of Standard item with another, e.g. replacement of timber sleepers
with concrete, represents a change to the approved configuration. Changes of this type must be
processed as a configuration change to existing infrastructure, in accordance with the requirements
of Appendix M.
Design engineers and supervisors have a general responsibility to ensure that JHR CRN Standard
items and designs are selected for use in new and altered designs on the basis that:
– They represent an appropriate solution having regard to the safety, performance, reliability and
environmental design requirements of the Engineering Specification
– Except in cases where there is a defined requirement for standardisation, they represent the most
cost-effective solution for the requirement, and
– They are the most current approved version.

Appendix F Interface Definition and Management
F-1 General Requirements
Interface management shall be treated as a high priority requirement within all design tasks
undertaken by JHR CRN.
The most obvious of these are the physical and functional interfaces that exist between infrastructure
systems, e.g. track and signalling. However, several other types of interfaces can affect or be
affected by new or changed infrastructure designs.
Uncontrolled or unintentional changes to any of these interfaces have the potential to cause major
problems with the operation, integrity or supportability of JHR CRN infrastructure, or to the safety
and operability of the NSW Rail System. Failure to recognise interfaces can also lead to
unnecessary damage, delays and costs during construction.
Eight categories of interfaces are identified within this Manual. These are illustrated in Figure 7 and
are further explained in the following paragraphs.
The order in which the different types of interfaces are presented does not infer any precedence or
relative level of importance. Uncontrolled changes to any type of interface can create significant
problems and the types of interfaces are considered to be of equal significance within the design
management environment. All types of interfaces must be considered during the design of all
changes to the configuration of JHR CRN infrastructure.
Operational,
Management &
Safeworking
Procedures
Physical &
Operational Functional Interfaces
Conditions of Use eg. within the same system
Speed Axle, Loading [may be Hardware,
Vehicle Configuration, Software, Electrical,
Traffic Density Data]
Physical & Functional Physical & Functional

System to be modified or
Interfaces with other CRN Interfaces with External
for which a design task is
Systems eg. Track Signals, Suppliers eg. Telecom,
required
Comms, Drainage Electrial, Power
Phyiscal
Interfaces with
Interfaces Installations on CRN
with Regulatory Agencies property owned by other
eg. ITSR Electrical Agencies eg.
Pipelines, Private
Management Systems Crossings, Roads
Interfaces eg. Ramsys,
PCR, GIS, Maximo
Figure 7: Types of Interfaces within JHR CRN Infrastructure

F-2 Physical and Functional Interfaces
Physical and functional interface requirements shall be defined where:
– The input to one item or system from another must meet specific criteria or where specific
limitations exist on input conditions within the design of the system receiving the input. Examples
are Minimum/Maximum Voltage, Data formats, Maximum/Minimum pressure/flow and situations
where there is a specific human interface with the system or item being considered.
– Outputs from a system provide inputs to another system and must meet specific input criteria.
Note that this is the “other side” of a common interface in the preceding requirement.
– Items must conform to specific space/weight or mounting requirements for attachment or
installation in standard designs.
– Equipment installed in or using the infrastructure must be designed to operate within a specific
physical space e.g. conformance with the Kinematic Envelope or within a defined space or
envelope within a tunnel.
– A design includes both hardware and software elements or there is a requirement for a new
software design to interface with existing hardware or software.
Interface requirements can be defined in one of several ways. Methods include:
– As separate interface specifications — this approach should be considered where systems or
sub-systems are to be designed by different organizations e.g. under separate sub-contracts. In
this case the interface requirements are defined in a separate document (specification or drawing)
and form mandatory design input requirements for both design groups.
– Within a drawing — Interfaces may be defined as part of any other drawing (detail or assembly)
or as separate interface drawings where appropriate. Interface requirements shown on “concept”
drawings provided as part of a design brief must be specified as a contractual/design interface
within the Engineering Specification. Drawings provided “For Reference” are exactly that, and
have no necessary legal or binding effect.
– Within specifications — the requirement for the design of a system item to meet a specific
interface must be included in the Engineering Specification for the system. This may be by
reference to a separate drawing or specification, or by inclusion of detailed interface requirements
within the specification.
– Irrespective of the method adopted interfaces must be clearly specified and be capable of ready
identification from the configuration documentation. The preferred method is for any applicable
interface documents to be identified on the relevant drawing or plan, to minimize the possibility of
it being overlooked during configuration change action.
F-3 Standard or Common Interfaces

Several interfaces exist throughout the JHR CRN infrastructure that are standard or common to the
complete system and may not be defined by specific interface documentation. These include Transit
Space Standards, wheel/rail, track/drainage, Signal/Train Control interfaces which are defined within
JHR CRN Standards and which must be taken into account in all design tasks.
Designers are responsible for verifying whether a section of the infrastructure affected by a proposed
change conforms to standard interface definitions or is governed by a specific definition e.g. a special
drainage design applying only to that application.

F-4 Operational Conditions of Use
Operational conditions of use are normally contained in Access Agreements between JHR CRN and
the Operator concerned. These cover details such as the type of rolling stock to be used, maximum
loading and usage factors such as numbers of trains and gross loading as well as the standard of
the infrastructure to be provided by JHR CRN. The Train Operating Conditions Manual is a derived
document (i.e. not a primary configuration document) that includes details of the operational
conditions of use.
Proposed changes to the operational conditions of use may originate from the Operator, to vary the
conditions of access, or JHR CRN, if the standard of the infrastructure is varied from that contained
in the agreement.
The operational conditions of use form a primary input to any new design or proposal to change the
configuration of existing infrastructure. Current requirements and any proposed changes to these
requirements, together with any limitations and constraints imposed by the relevant access
agreements should be established before any change is developed and approved.
The change Sponsor is responsible for identifying any proposed changes and for processing these
as Configuration Change Requests (CCRs) under the requirements of CRN-PLN-ASM-003
Configuration Management Plan and the processes detailed in Appendix M .
Designers who are responsible for the development of any configuration change that may have an
impact on any operational conditions of use shall ensure that the effect of a change is clearly
identified and referred to all relevant stakeholders before proceeding.
F-5 Operations Control and Safeworking

Many interfaces exist between the design of the infrastructure, operational and train control systems
and the Safeworking rules in use within the NSW rail system. The interfaces are particularly
important for signalling and communications systems, but have the potential to affect the design of
all infrastructure.
Close coordination is necessary between Designers and the JHR CRN Network Operations section
responsible for operational control and Safeworking systems. This can be of critical importance
when changes are to be made to either the infrastructure design or the design of other systems that
have an interface with the infrastructure.
This should be accomplished through the configuration control process defined in CRN-PLN-ASM-
003 Configuration Management Plan, with the responsible section being required to submit a CCR
for consideration of the impacts by all stakeholders when an interface is affected. Significant
changes would be considered and approved by the JHR CRN Configuration Control Board.
Design staff shall monitor changes in operational control systems or Safeworking rules to identify
changes that are likely to impact on infrastructure design and to initiate action to resolve any issues
that arise.
F-6 External Service Providers

Interfaces with service providers (such as Electricity suppliers) should be defined in service
agreements. These covers both the commercial terms and the nominal specification for the supply,
which does not normally impose any specific interface limitations or constraints on JHR CRN
designs.
The physical/functional characteristics of connections between JHR CRN infrastructure and service
provider installations shall be clearly specified within new JHR CRN configuration documents in a
form that meets the requirements of JHR CRN, the service provider and any relevant Legislation and
Regulations.
F-7 Physical Interfaces with Other Property Owners

Numerous physical interfaces exist between JHR CRN infrastructure and equipment/installations
owned by other individuals or agencies. Equipment or installations in this category may be located
within the rail corridor or may adjoin the corridor. Examples include road crossings (including private
crossings), installations such as pipelines laid within the corridor, shared poles, private sidings and
bridges.
Interfaces in this category shall be clearly defined within JHR CRN asset configuration
documentation and the impact of any changes on other stakeholders shall be assessed as part of
any configuration change action that may affect other property owners.
F-8 Management Systems Interfaces

Management systems interfaces may need to be considered under two types of circumstances within
infrastructure design.
The first covers situations where changes to the design of a system or subsystem can affect data
collection for input to systems designed for management or monitoring of the infrastructure
concerned. The operation or range of information collected within SCADA systems is a prime
example. However, similar circumstances can arise with interfaces between signaling and
operational control systems, or where changes in infrastructure design affects the collection of data
by equipment designed to monitor condition e.g. the use of the track recording car.
The second case involves interfaces between management systems, where one or both systems
are used to monitor asset condition or integrity. This is particularly important where the monitoring
involves parameters that are needed to monitor safe life, or that otherwise contributes to monitoring
the safety or integrity of infrastructure assets.
Management of such interfaces can only be achieved through cooperation between all responsible
Sections and stakeholders. JHR CRN Engineering Services staff shall ensure that any proposed
changes within their area of responsibility are properly managed to preserve the integrity of
management systems data
F-9 Regulatory Agencies

Interfaces with regulatory agencies include several different types of arrangements.
The interface with the Office of the National Rail Safety Regulator (ONRSR) is effectively a
management interface where ONRSR has a responsibility to ensure that configuration changes
introduced by JHR CRN do not impact on the terms of the JHR CRN accreditation as an
infrastructure owner and operator.
For design tasks this interface is managed by provision of information on proposed and actual
changes to the ONRSR, in accordance with the general requirements of CRN-PLN-ASM-003
Configuration Management Plan and with reference to the Management of Change Risk Assessment
(MOCRA) process & JHR CRN Safety, Environment and Quality Manager. Any follow up action will
then occur through established management processes.
Other, more specific interfaces exist with a number of agencies whereby specific permits and/or
licenses are required prior to the implementation of certain configuration changes. These include
Environmental Authorities, the NSW Transport Agencies, and the relevant Water Authorities.

Prior consultation is often necessary or advisable before proceeding with the development of a
change, e.g. with the relevant Water Authority to establish flood and drainage levels and impacts
prior to the construction or alteration of a bridge.
Confirmation that the relevant Regulatory Agencies have been consulted and that necessary
Licenses and Permits have been obtained is required as part of the verification for design tasks.
(These requirements may also be captured in an initial WRA as a means of identifying Approval
tasks required prior to construction activity). Refer to Appendix J.
F-10 Verification/Validation of Interfaces

Verification and Validation of interfaces shall be included as a mandatory element for all new or
altered designs.
Interfaces should be verified as early as possible in the design process through integration testing
or analysis where this is possible. Early verification assists in avoiding last minute problems during
construction and/or commissioning.
All type testing programs shall include test or demonstration requirements to ensure that all interface
requirements have been validated.

Appendix G Hazard and Risk Analysis
G-1 Requirements
Hazards and Risks to be Identified
Figure 8 shows the lifecycle for Hazard and Risk Management and the interfaces with the design
process.
PRR and
Impact assessed
Asset need Subsidiary Risk
Infrastucture Management
Start Scope developed and hazards

arises Register
documented
Configuration
Brainstorm
Management
Assists with the
planning Initial WRA
process
Y Is Project N
End
viable?
Engineering Procedures
Transfer N
Close Out
hazards?
Engineer design
cycle (Fig 2)
Informs Interactive Y
process through
design
Transfer hazards
and mitigation
Infrastructure
Management
Transfer Y Maintain
Informs Delivery
hazards? and operate
N
SQERM ARM
AMS TRA
Close Out
Figure 8: Lifecycle for Hazard and Risk Management
The process map in shows the progressive identification and analysis of hazards and risks aligned
to each major stage of design, as well as the primary processes and support tools to be used. The
process map represents the most complex case, that of a major project, but less complex design
tasks shall incorporate one or more of the major steps, as defined within this Manual.

IDENTIFY PRIMARY
HAZARD SOURCES
OBTAIN
SPECIFICATION &
REQUIREMENTS
ESTABLISH NO YES OBTAIN

NEED MORE
A SOUND BASIS FOR ADDITIONAL
INFORMATION?
THE DESIGN TASK INFORMATION
NO
YES
CARRY OUT
END PRELIMINARY
FMECA
PREPARE
CONCEPT &
PRELIMINARY
DESIGN
CARRY OUT
PRELIMINARY
HAZARD
ANALYSIS
REVIEW
OBTAIN
CONCEPT &
ADDITIONAL
PRELIMINARY
INFORMATION PROJECT RISK
DESIGN
REGISTER
YES CARRY OUT

DETAILED
DECIDE TO NO NEED MORE HAZARD
PROCEED INFORMATION? ANALYSIS
Analysis
YES NO
Software
CARRY OUT
END
FMECA
PREPARE
DETAILED
DESIGN CARRY OUT
MAINTENANCE
REQUIREMENTS
ANALYSIS
CRITICALLY
REVIEW THE
DETAILED
DESIGN
FORMULATE FORMULATE
PROCEDURES, SCHEDULED
CONTROLS & MAINTENANCE
TRAINING PROGRAM
Figure 9: Hazard and Risk Identification Process
G-2 Identify Primary Hazard Sources

Identification of primary hazard sources is a key step in the development of an engineering
specification and/or in assessing a Client specification, to verify that the specification includes all
necessary information to establish a sound basis for the design task. (See Appendix C).
The CRN Project Risk Register and subsidiary risk registers should be consulted to identify key risks
and hazards from the CRN environment. Additionally, the proposal and impact documentation from
submissions to the Configuration Change Board should be reviewed to provide context to the risks
and capture additional hazards.
The objective in doing this is to ensure that the specification includes a set of requirements that
properly address the need to design for both the operating environment and other hazards and risks
that may either:
– Have an impact on the design solution, or

– Be introduced because of the design solution.
The diagram in Figure shows these general relationships and covers the major categories of hazards
and risks that shall be considered when preparing a specification and within the final design solution.
HAZARD SOURCES
FROM FROM FROM

NORMAL EQUIPMENT IMPROPER USE OR
OPERATION FAILURE MAINTENANCE
FROM FROM
FROM THE
DANGEROUS HAZARDOUS
ENVIRONMENT
GOODS SUBSTANCES
RISK AND HAZARD ANALYSIS
RISKS
TO TO
TO THE
MAINTENANCE CONSTRUCTION
PUBLIC
STAFF STAFF
TO
TO TO THE
OTHER
OPERATORS ENVIRONMENT
EQUIPMENT
08 Sources of Risks and Hazards V2 28 February 2003
Figure 10: Primary Sources of Risks and Hazards
The set of potential hazards and risks shown in Figure 10 form the basis for analysis and action
during the design phases. For major new projects this will involve progressive identification and
refinement as the design evolves. Assessing changes to an existing design involves the same range
of considerations but may be accomplished by review of existing data and limiting the analysis to
take account of the effect of the changes.
The scope of the processes to be applied in each set of circumstances is set out in the following
paragraphs.
G-3 Application within New Projects

G-3-1 Preliminary Hazard Analysis
A Preliminary Hazard Log will normally be prepared when a proposal is put before the Asset
Configuration Control Board. When the proposal is approved and referred for design, the Hazard
Log will accompany the initial brief and be developed through the design process in accordance with
this Manual. These may be reviewed using existing Logs (in the case of similar design tasks or work
programs) as starting points, but must also be reviewed to ensure project and location specific
hazards and risks are correctly identified.

This should be carried out as soon as possible after the design concept has been established and
the preliminary design has been defined in sufficient detail to permit an assessment of potential
hazards. The Hazard Log and Analysis must be completed before Preliminary Design Review(s)
(PDR) are conducted for the project or individual system/item, as applicable. Appendix L provides
details of the Technical Review process.
The Hazard Analysis should be carried out in conjunction with a preliminary Failure Modes, Effects
and Criticality Analysis (FMECA), covering both an analysis of individual item failures as well as
processes which focus on the interface between operator or maintenance staff and the infrastructure.
Some of the failure modes identified within the FMECA will create hazards and will provide inputs to
the Hazard Analysis. More detailed requirements for performing the FMECA are contained in
Appendix H.
Design engineers have a primary responsibility to ensure that Hazard and Risk analyses are
completed as part of each design task and Engineers responsible for verification of design outputs
must ensure that the analyses have been completed, in accordance with the requirements of
Appendix J. Specialist resources provided by Engineering Services are responsible for supporting
both the Hazard Analysis and FMECA, based on the following information to be provided by design
engineers:
– Details of systems and equipment selected within the concept/preliminary design
– Specifications, drawings and other preliminary data to permit the analysts to properly understand
the operating environment, limitations and interfaces
– Advice and available information to support the analysis, including advice on the assessment of
risk levels.
A Hazard Log and Analysis will be developed.
This process may be completed internally by Engineering Services or delivered by specialist
consultants. The MIMIR FMECA system is available to be utilised if/when required.
The analysis shall consider the effect of potential hazards and risks in all phases of the asset life
cycle, with specific emphasis on:
– Construction, including any temporary works required as part of the project
– Maintenance
– Operation which, for the purpose of this Manual, includes de-commissioning and disposal.
The results of the Hazard Analysis shall be recorded in the approved document format, linked to the
asset identification number in Maximo and recorded in the Document Management System. Each
updated document will have version control and release date to provide a record of development.
The Hazard Analysis, must include, but should not be limited to:
– Details of the scope of the analysis
– Hazards considered
– Potential risks within each phase of the asset life cycle
– Possible mitigation measures, for consideration in the design process
– Legislative requirements and standards referenced
– Links to Hazards and controls contained in the PRR and Subsidiary Risk Registers.

The Hazard Analysis shall be included as part of the design documentation for the project or task.
Preliminary FMECA results are recorded separately.
G-3-2 Detailed Hazard and Risk Analysis

Detailed hazard and risk analysis shall be carried out in conjunction with the detailed design phases
of projects for major new Infrastructure and equipment, or as part of a combined Workplace Risk
Assessment (WRA under the SQE RM Process) and detailed analysis for minor projects.
The detailed analysis is an evolution of the information collected as part of the WRA, refined and
extended to cover all elements of the final design.
Detailed hazard and risk analysis shall be carried out progressively during the detailed design phase
or phases of the project or task, to permit recommendations arising from the analysis to be
incorporated into design solutions. The detailed analysis shall follow the same general structure and
shall utilise the same tools as employed for the WRA, except that the analysis shall be performed at
greater depth and, in its final form, shall reflect the final design to be constructed and commissioned.
The detailed analysis is a responsibility of design engineers, supported by specialists sourced from
external consultants. These shall be supplemented as necessary by techniques such as Fault Tree
Analysis (FTA) and Event Tree Analysis (ETA) and by analyses of software safety.
The detailed analysis and report shall be substantially complete before Critical Design Reviews are
conducted for systems, items, or for the system as a whole and shall be updated to reflect any
changes which take place to the design through the test and commissioning.
G-3-3 Functional Safety Analysis of Software/Electrical/Electronic Systems

Infrastructure applications that incorporate software and/or electrical/electronic systems for control
of safety functions (such as signaling or electrical system switching /isolation) shall be subject to
additional controls within the JHR-CRN design environment. Specific requirements for Signaling
Systems are contained within the JHR CRN Signaling Standards. Similar requirements shall be
implemented where the proper operation of a safety system depends on a human interface.
Australian Standards AS 61508.1 to 61508.7 provide detailed guidance for establishing
requirements for analysis of safety related systems, including the identification of hazards and risks
associated with the systems.
Requirements for functional safety analysis of such systems will vary between applications and as a
function of the nature, complexity and criticality of the system. The methods to be applied for
functional safety analysis involve the use of specialised techniques and may utilise specialised
software and other tools for analysis of code.
Discipline Design Leads shall determine the level of functional safety analysis required for control of
safety functions in accordance with the requirements of AS 61508.1 to 61508.7 for all new design
development tasks, and for regression analysis whenever there is a requirement to implement design
changes. Requirements and techniques shall be determined on a case by case basis, including the
need for independent assessment and verification of the design in accordance with Appendix J.
The results of functional safety analysis for software and/or electrical/electronic shall be documented
in a specific report and shall be maintained as part of the design record for the system or equipment.
G-3-4 Application as part of Configuration Change Action

Hazards and risks shall be reviewed and validated or, if necessary, updated as part any configuration
change action.

The asset requirement/proposal will normally be considered by the CCB and approved prior to a
design solution being sought. The CCB may require reviews and updates of the Hazard and Risk
profile as the design progresses. Particularly if a major change in risk profile occurs.
Action to be taken as part of the configuration change process shall normally take the form of a
review of documented hazard and risk information for the system or equipment to establish whether
the proposed change will:
– Introduce new hazards or alter the nature of existing hazards associated with the operation,
maintenance (including storage & handling) and construction of the system or equipment
– Affect existing conditions of use
– Affect existing documentation and instructions, including Process Control Plans.
Design engineers are responsible for ensuring that the analysis is completed, with support from
Integrated Support Unit specialists. The analysis shall be performed as soon as possible after the
scope of the proposed change has been established in sufficient detail to enable the hazard and risk
assessment to proceed.
Traceability to the updated hazard and risk analysis shall be via the design validation checklist (See
Appendix J) and supplemented by controlled data within MIMIR database or manual records, as
applicable. Where the change is extensive, or where it involves the introduction of a new type of
equipment, the design engineer in conjunction with Integrated Support Unit staff shall take action to
include the new equipment in the database and must consider the need to update detailed hazard
and risk reports that have previously been prepared for the equipment.
G-3-5 Transfer of Risks and Ownership

The intent is that controls and mitigations developed through the design development which impact
the construction, maintenance, operation or disposal of an asset will be transmitted and accepted by
the appropriate owner as the asset is created and moves through its life cycle. The transmittal of the
hazard logs, analysis and risk mitigations will be formally transferred and recorded in the DMS.
Subsidiary Risk Registers and the PRR will be updated with new and hazards, contributing factors,
controls and control owners.
Milestones for these actions will be at:
– the handover of approved design for construction
– commissioning and acceptance of the asset into operation
– decommissioning and disposal of the asset.
G-3-6 Control of Hazards and Risks

A primary objective of the hazard and risk analysis process is to ensure that hazards and risks are
progressively identified and addressed during the design process and measures introduced to
eliminate or mitigate the effect of the hazard wherever possible.
Risk control measures shall be implemented in the following order of preference:
– Elimination of hazard
– Reduction of the hazard through the use of less hazardous equipment, material and/or processes
– Reduction of the risk through engineering controls (e.g. guarding, modification)

– Reduction of the risk through administrative controls (e.g. safe work Manuals, signs, training to
improve the awareness of hazards and personal judgment regarding actions to reduce the
associated risks etc)
– Reduction of the risk through the use of Personal Protective Equipment (PPE).
In many cases it will be necessary to implement a combination of measures to reduce the risk to a
level that is So Far As Is Reasonably Practical (SFAIRP) levels. This is further explained in the
CRN-SQE-SMS-FRA-0013 Risk Management Framework.
Design engineers and specialist staff performing hazard and risk analyses are responsible for
identifying and implementing control measures as part of the design task and for providing and/or
updating the relevant documentation before the new or altered equipment is introduced into service.
Support documentation shall, as a minimum, comprise:
– Operating Manuals and instructions
– Process Control Plans, setting out specific procedures and precautions for performance of
maintenance and construction tasks. These will include details of the conditions under which
tasks can be safely performed e.g. isolation, possession, as well as PPE, tools and other
equipment to be used and specialist training/competency requirements.
Operational Interface
In some cases, the implementation of effective controls will involve measures that are outside of the
direct control of the JHR CRN.
Implementation of controls in this category should be managed through interface management
processes, as described in Appendix F.

Appendix H Reliability Maintainability and Availability
H-1 Scope
This appendix provides guidance for:
– Inclusion of reliability and maintainability requirements during design tasks, including general
guidelines for estimation of reliability during the design phase
– Inclusion of reliability, maintainability and availability requirements in detailed specifications, and
the contract statement of work, where applicable.
H-2 Definitions and Terms

Terms used within this Appendix are in accordance with the Glossary included in Appendix A. Terms
having specific importance within this Procedure are reproduced below.
Reliability: Reliability is a characteristic of design. It is defined as the ‘probability that a specified
item will perform a specified function within a defined environment, for a specified length of time’.
For complex systems the reliability requirement is normally specified in terms of the Mean Time
Between Failures (MTBF) or as a failure rate, e.g. failures per million operating hours.
Maintainability: Maintainability is a characteristic of design and is essentially a measure of the ease
with which the item can be maintained. A more formal definition is:
‘Maintainability is a characteristic of design and installation, expressed as the probability that an item
will be restored to operating condition, within a given period of time, using prescribed procedures
and resources.’
The most commonly used measure of maintainability is the Mean Time to Repair (MTTR).
Availability: Availability is the measure of the percentage of time that an item or system is available
to perform its designated function. The simplest expression for calculating Availability is:
Availability (A t) = Uptime
Total Time
for a continuously operating system.
This can also be expressed as:

(A t) = Total Time - Downtime (Scheduled + Unscheduled)
Total Time
OR, in terms of Reliability (MTBF) and Maintainability (MTTR) measures, as:
(A t) = MTBF
MTBF+ MTTR

H-3 Reliability and Maintainability to be Performance Requirements
Reliability and maintainability shall be treated as key performance requirements in all new design
work carried out by JHR CRN design staff. Specific reliability and maintainability design criteria
should be included in Engineering Specifications developed for new equipment to the level and detail
required by the Principal Discipline Engineer/s for the asset/system concerned.
The levels of reliability and maintainability that are built in to the initial design not only govern the
level of availability that can be achieved in service but also have a major influence on the cost of
maintenance over the life of the asset. For this reason, it is essential that all infrastructure equipment
that is designed by JHR CRN, or is specified either for procurement as a standard item or for design
by a third party, should incorporate the best possible levels of reliability and maintainability,
commensurate with the acceptable cost for the item.
H-4 Reliability and Maintainability in Design

Ensuring that new designs meet reliability and maintainability targets requires careful selection of
equipment, materials and design architecture combined with progressive estimation and verification
of the predicted performance during the design phase. It is not enough to finalise and build the
design and then to operate or test to establish the level of reliability or maintainability that has been
achieved. This “after the event” approach is unlikely to achieve the desired result.
H-5 Reliability
Designing for reliability is essentially an iterative process. It involves several key steps that are
applicable for all minor and major projects, as follows:
• Determine the targets or level of performance to be achieved. This should normally be
included in the engineering specification, and is typically specified at major system or installation
level e.g. Track, signaling, or Tunnel Ventilation system
– Establish a mathematical model (or models) to represent the architecture selected for the design.
This will be used to test the predicted performance of selected equipment against target levels
– Allocate targets to progressively lower levels within the design architecture. The ultimate
requirement is to establish the predicted level of reliability or maintainability characteristic for each
major item (or groups of items, such as OHW section insulators). Targets established for
systems, sub-systems and individual items are commonly referred to as reliability budgets
– Select equipment based on established targets
– Test the predicted level of performance against targets. Identify shortfalls
– Introduce improvements to the design or to the proposed architecture to meet the required target.
H-6 Reliability Modelling

Reliability modelling and estimation techniques are applicable to all but simple design tasks, where
reliability improvement may not be a primary objective. This must be accomplished progressively
during the preliminary and detail design stages, to provide the opportunity to identify shortfalls
against reliability targets and to take corrective action.
Reliability modelling is a specialised field and a detailed explanation of the available techniques is
outside of the scope of this Manual. The modelling process may range in complexity from manual
calculations using block diagrams to complex computer models but will involve preparation of one
or more reliability block diagrams, to serve as a basis for modelling and prediction. Figure 11
illustrates a simple reliability block diagram.
ITEM C
R (t) = 0.95
ITEM A
R (t) = 0.9
ITEM B ITEM C
R (t) = 0.99 R (t) = 0.95
ITEM A
R (t) = 0.9
ITEM C
09 Simple Reliability Block Diagram V1.0 18 Nov 2002
R (t) = 0.95
Figure 11: Simple Reliability Block Diagram
Primary responsibility for the reliability performance of designs rests with the designer. Support from
Subject matter experts must be a highly interactive process, with continuous input from designers to
ensure that:
– The mathematical reliability model is representative of the actual design of the infrastructure
– Selection of equipment and other relevant changes in the design architecture is promptly advised
to the ISU
– Failure rate data to be used in the model is derived from the best available source and is
consistent with the intended environment in which the item is to be used. Data may either be
from manufacturer’s predictions for new equipment, or from the failure data available for CRN
equipment, or a combination of the two
– Data used in the modelling and estimation process is representative for the intended use of the
equipment. Estimates obtained from manufacturers for new equipment, or data for existing items
that are to be used in a more severe environment, may need to be factored or de-rating factors
applied to ensure that it is representative.
Reliability reports and models developed as part of the design process shall be maintained as part
of the design record for the equipment.
H-7 Failure Modes, Effects and Criticality Analysis

Failure Modes, Effects and Criticality Analysis (FMECA) is described in more detail in Appendix P,
where it forms an integral part of the process of determining scheduled maintenance requirements.
However, FMECA also provides a direct means of verifying failure data and assumptions used in
reliability modelling and should normally be carried out in conjunction with the modelling task.
While FMECA carried out as part of the design process varies from that carried out as part of
maintenance requirements analysis, mainly in terms of the scope and level of detail at which failures
are considered, failure rates are common to both FMECA assessment and the reliability model. In
addition, FMECA provides a means of verifying that all relevant failure modes have been considered
during the modelling process.
An extensive database of failure information has been assembled by Sydney Trains which is
maintained within their MIMIR system. This system is available to JHR CRN and should be used to
the maximum possible extent in support of design tasks.

H-8 Reliability Improvement during Design
Corrective actions may be required in cases where the predicted reliability falls short of the required
level of performance, or where FMECA or hazard analysis reveals the existence of critical failure
modes. Potential sources of improvement include:
– Replacing the item initially selected as part of the design with a different item having better
reliability characteristics.
– Changing the design to reduce the reliance on items that have relatively low levels of reliability if
an improved item is not available or would lead to an unacceptable increase in cost.
– Introducing redundancy in critical applications, where it is possible to do so.
– Selection of potential methods of improving reliability is a direct responsibility of design engineers.
Integrated Support Unit staff should be called on to assist in developing revised estimates of the
level of improvement that can be achieved by different options and to assist in selecting the most
cost effective method of achieving the required result.
H-9 Maintainability
Maintainability requirements may also be included in the specification, either directly in the form of
MTTR targets for specific equipment or in general terms, such as a requirement to perform all
scheduled maintenance during access windows, which may directly influence characteristics of the
design. These may include tolerance to failures, through the incorporation of redundant features
(which also affect reliability performance) and/or fault diagnosis methods and accessibility features,
to permit rapid isolation and correction of problems.
Maintainability characteristics are typically assessed through a systematic review of the design, to
assess infrastructure support requirements including fault finding, scheduled maintenance and
repair/replacement and to identify areas that do not meet the general criteria included in Appendix
G. The key consideration in each case is to assess how a task may be accomplished and the safety
and efficiency with which it may be performed.
Estimates of maintainability (i.e. MTTRs) are also used in conjunction with reliability predictions to
assess the likely availability of the system. Clear definition of the rules for measuring MTTR are
essential where the parameter is used for this purpose, or in any situation where achievement of
specific MTTR values forms part of the design validation process.
The most appropriate definition of MTTR for validation purposes is that it includes only the time taken
for direct fault finding and repair of faults. Administrative components of total downtime, such as the
delay in attending a fault or time awaiting spares or other resources, are generally outside of the
control of designers and are normally excluded from the estimates of MTTR.
H-10 Relationship to Safety

Reliability and maintainability are each closely linked to safety. This linkage is illustrated through
the use of FMECA, which represents a key input for both reliability/maintenance requirements
analysis and hazard and risk analysis processes.
FMECA involves the systematic identification of potential failures. Each type of failure is then
evaluated for its effect on infrastructure operation, safety and the environment. Failures that involve
an unacceptable level of risk to people, other infrastructure or the environment must be corrected or
improved so that the chance of failure and the consequences if one occurs are within acceptable
levels. This may require the introduction of a reliability improvement change.

Process FMECA is intended to examine the interface between operator or maintenance staff and
the infrastructure, to identify hazardous operations. Corrective action will be required where the
design of the infrastructure creates or contributes to a hazard for any employee or contractor.
Appendix G addresses hazard and risk analysis as part of the design process.
H-11 Specifying Reliability, Maintainability & Availability

JHR CRN staff may be required to develop reliability, maintainability and availability requirements
for inclusion in engineering specifications under two main sets of circumstances:
– Where an internal specification is being prepared for commercially available equipment to meet
a specific purpose or for type testing and approval, or
– A specification is being prepared for another, external organisation to complete a design task,
generally through a Request for Tender.
– Two different approaches can be taken for specifying reliability, maintainability and availability
requirements for new equipment, as follows:
– Specific reliability and maintainability requirements may be included within the specification, or
– An availability target may be specified, which can be met by different combinations of reliability
and maintainability.
Design targets must be included in the specification and then monitored throughout the design
stages of the project with either approach, if the required outcomes are to be achieved in the final
design. The following sections provide an outline of key points.
H-12 Reliability Design Targets

Reliability targets will have a major influence on the type and quality of items selected as part of the
design. It is important to ensure that the specified level of performance is not excessive and to avoid
conflict between reliability requirements and other specification requirements. This is particularly true
if specific equipment is nominated which cannot meet the required level of reliability.
The approach taken is dependent on the type of equipment involved. The form of specification for
functional equipment is not generally appropriate for fixed mechanical structures.
H-13 Maintainability Design Requirements.

Maintainability design requirements are included in the specification to establish the type of features
to be incorporated within the design to ensure that the infrastructure can be maintained safely and
efficiently. Some examples of aspects for consideration in developing the specification are given in
Appendix 1.
Note that maintainability is not the same as scheduled maintenance requirements, which cover
specific tasks designed to maintain the infrastructure in good condition. Maintainability
characteristics are an integral part of the design and govern the ease and safety and economy with
which maintenance tasks (scheduled and unscheduled) can be performed. Development of
maintenance tasks and Technical Maintenance Plans should be covered separately within the
Statement of Work (contract scope) for the task.
H-14 Availability Requirements

Availability provides the single measure of utility for an infrastructure item or system, assuming that
the operating performance is satisfactory, i.e. it produces the required output or performs the

required functions. It provides a target for the amount of time that the system is to be ‘available’ for
operational use.
In order to specify an availability requirement, it is necessary to:
– Specify the percentage availability required
– Establish the duty cycle for the equipment i.e. the number of hours per day it is needed for use, if
available
– Define the conditions under which the system will be assessed as being ‘available’ and
‘unavailable’ respectively.
Availability targets may be used as an alternative to specifying separate reliability and maintainability
targets, although a requirement to incorporate general maintainability features can be included in
addition to availability targets.
H-15 Tendering
Equipment reliability or availability is to be used as a selection criterion for new equipment wherever
possible. This typically forms part of the Life Cycle Cost assessment carried out in the tender
selection phase, to establish the alternative which will provide the lowest cost of ownership over the
expected life of the infrastructure.
Tender specifications typically include an Engineering Specification (see Appendix C) and a contract
Statement of Work. The following requirements should be considered for inclusion in the tender
documentation in support of the reliability program:
– A requirement for the design Contractor to develop reliability models for nominated sections of
the design, and to report on the predicted reliability for the infrastructure in advance of technical
reviews, or
– A requirement for the Tenderer to provide specific reliability information for the product offered in
response to the JHR CRN specification
– A requirement for the Contractor to complete and deliver a FMECA, which will be used to validate
reliability models, to support Safety and Hazard Analysis and as a basis for establishing
programmed maintenance requirements
– An availability model that takes account of predicted reliability and maintainability characteristics
(reactive repair times as well as completion times for scheduled maintenance inspections).
Additional information must be requested as part of the tendering process to provide a basis for
comparative assessment of bids received.
H-16 Monitoring During Design and Development

Monitoring of reliability predictions during design and development projects is an integral part of the
design verification process. This may involve preparation of reports, review of modelling results and
in some cases the planning of demonstrations to verify that maintainability requirements can be
achieved. Appendix J includes specific requirements for design verification.

Appendix I Design Approvals
I-1 Design Work to be Approved
All design work performed by or for JHR CRN shall be approved by a competent and properly
authorised person.
The requirements for Engineering Authority are covered under CRN GM 001 Engineering Standards
System Manual.
The Project Manager is required to provide overall Engineering (Project) Approval for projects, to
verify that all necessary work has been completed, and that design approvals have been provided
and that all system and that interface issues have been resolved, in accordance with the
requirements of section 3.9.4 of this appendix.
The timing of design and engineering approvals prior to construction means that some actions that
are common to the verification and validation processes may not be complete at the time that the
approval is given. This is accepted as a necessary condition of the approval, and final approvals
shall be required after all validation actions are complete and the infrastructure covered by the design
is released for normal use.
I-2 Scope of Design Approval

Design approval is separate and distinct from design checking. It incorporates the checking and
verification process described in Appendix J and is a certification by a suitably qualified and
authorised Engineer that:
– The design has been completed and verified in accordance with the appropriate Manuals and
standards
– The design has taken account of all applicable aspects listed in the design verification and
approval checklist and complementary checklists for individual disciplines
– All test and verification action appropriate to the stage of the design has been successfully
completed or is planned for completion
– Supporting assumptions, calculations and decisions have been independently checked for critical
systems
– The requisite approvals have been obtained from regulatory authorities
– The design has been properly documented.
Design approval shall be required prior to the release of design documentation for construction or
alteration of the asset.
NOTE: Design approvals may be provided progressively, where it is necessary to release design
information for construction prior to completion of all aspects of the design.
I-3 Method of Approval

Evidence of Design Approval shall be provided by the authorised engineer signing either the
documentation covered by the approval, or a summary approval form such as that included with
Appendix J, in the appropriate block.
Design documentation shall be treated as “unapproved” and shall not be used for construction or
other purposes other than during the design development process where:
– It does not bear evidence of approval by an authorised engineer, or
– In the case of a multi-part document (such as a book of plans) it does not include a list of
documents by Issue and Revision number on the signature page such that the approval status of
individual plans may be positively determined.
I-4 Authority to Approve Designs

Within this framework a designated person within JHR CRN (normally the Manager Engineering
Services) will delegate Engineering Authority to named individuals within the organisation to approve
specific types of design work. Design delegations are issued to individuals and not to positions
within the organisation.
Separate delegations will also be made for related aspects of JHR CRN responsibilities (e.g.
maintenance, construction and commissioning) and for external service providers where
appropriate.
Each delegation will be documented and will clearly state the scope and limitations of the delegation.
A consolidated record of engineering authority delegations for design work will be maintained.
Only those staff having a specific and current design delegation shall be permitted to approve
infrastructure design work.
All approvals shall be made within the scope of the delegation for the individual concerned.
I-5 Design Work Requiring Approval

Design tasks requiring specific design approval shall include, but are not limited to:
– Development of new designs for infrastructure items (both hardware and software elements)
through Minor or Major projects
– Modification or alteration of existing designs (both hardware and software elements), through
planned upgrading or to correct identified deficiencies through Configuration Change Request
(CCR) action. This includes revalidation of design elements to take account of changes in
interfaces or conditions of use affecting infrastructure items
– Development of repair methods for any item, particularly where the repair would alter strength,
durability or functional performance or limitations
– Identification, development and type testing/approval of new standard equipment or designs
– Review and approval of changes in the conditions of use for any item, including definition of
restrictions or additional inspection requirements where the proposed usage would result in the
item being used outside of its original design basis. These include changes to usage parameters
such as speed, loading, operating and environmental conditions
– Local development and/or modification of tools, test equipment, workshop aids or other plant and
equipment
– Review and approval of substitute or replacement spares for any hardware item, except where
this is strictly on a “like-for-like” basis
Changes that become necessary during construction work, including that performed as part of Major
Periodic Maintenance (MPM) activity.
Approval of derived documentation, such as Maintenance Plans and Maintenance Procedures is
covered by Appendix O and Appendix P.

I-6 Approval of Changes during Construction
In some cases, it will be necessary to deviate from the approved design documentation during the
construction phase, to take account of unforeseen conditions encountered during construction work
or to correct deficiencies in the approved design data.
Any change that would result in a departure from the approved design documentation shall be
documented. Every change shall be managed and approved in accordance with the following
process.
I-7 Temporary Approval

Where time is of the essence, e.g. for work being completed under possession, the change may be
initially authorised by the appropriate engineer on site (or who may be called to the site) to allow
work to proceed, provided that:
– The engineer possesses the necessary competence and authority to authorise the change
– The authorisation covers any restrictions or limitations on the use of the infrastructure considered
necessary by the responsible engineer
– The change is documented using a Request for Variance (Deviation or Waiver) or other approved
method and is submitted for final approval within 7 days, in accordance with the requirements of
this Manual and Appendix N.
I-8 Final Approval

The Engineer raising the Request for Variance shall submit the change to the appropriate Principal
Discipline Engineer for review and approval under the terms of this Manual.

Appendix J Design Verification
J-1 Design Verification and Validation Processes
The design verification and validation processes are separately described in this Manual and
Appendix K (Design Validation). While this is convenient for the purpose of establishing requirements
and responsibilities, the two processes are essentially continuous. Each contributes to an
assessment of the integrity of the final design solution and its compliance with design input
requirements, leading to a final decision to release the asset for normal use.
The situation is also complicated by lack of consistency in usage of the terms between different
Standards and other reference material covering the systems engineering process.
JHR CRN has adopted the following convention for defining the two processes which is consistent
with the definitions in AS/NZS 3905.12 and HB 90.3. The essential difference between the two
processes is that:
– Design Verification: is focused on ensuring that the output from an individual design stage meets
or is likely to meet the verified inputs to that stage. Design verification is part of the process
whereby design outputs (including staged outputs where applicable) are progressively checked
and approved before the design is released for construction.
– Design Validation: is the process of ensuring that the final design and installation conforms to
defined user (customer) needs and/or requirements. It represents the final stage in the process
of ensuring that new designs are fit for the intended purpose, before release of the item or system
for use.
Some checks and tests that are likely to be carried out as part of the verification process may also
contribute to validation of the final design. However, this is dependent to a large extent on the actual
configuration of the design at the time the verification check was performed. Only the results of
tests or checks that are carried out on documentation or equipment that is representative of
the final design are acceptable evidence for validation purposes. Appendix K provides
additional information on this aspect.
Both processes also serve as risk reduction measures during the design process. They provide a
means of progressively checking that the proposed design solution is consistent with design input
requirements and is likely to meet the requirements of the user specification.
Figure 12 provides a schematic representation of the verification and validation processes. It shows
the relationship between the processes and typical design stages for a major design project or task.
The requirements in Paragraph 3.10.5 establish criteria under which the processes may be simplified
for minor projects.
The process model in figure 12 also shows design approval points. Appendix I sets out specific
requirements for approval of design tasks.

Project
specification
Requirements
analysis &
allocation
Verification of
stage output
Design stage
Verification of
stage output
Design stage
Verification of
stage output
Design
Design stage
approval
Verification of
stage output
“For-construction
baseline” Design output Validation
Project or Changes during

task construction/
engineering commissioning
approval
“As-built” baseline
Final design
Figure 12: Design verification and validation process model
J-2 Design Verification

Verification of the final design shall be required for every design task, before the documentation is
released for manufacture or construction, to ensure that the:
– Design output conforms to specified requirements, and
– Design has been completed in accordance with the appropriate Manuals and standards, and
– Design has taken account of all applicable aspects listed in the CCR, design checklists or the
proceedings of a Technical Review, including test results where appropriate, and
– Supporting calculations and decisions for defined critical systems have been independently
checked and verified, and
– Requisite approvals have been obtained from regulatory authorities, and

– Design has been properly documented.
For major projects, or on other occasions determined by the Manager of the responsible design
entity, the final verification may be nominated as being through completion of a Physical
Configuration Audit (PCA), as defined in CRN-PLN-ASM-003 Configuration Management Plan and
section 3.12.14 of this document.
J-3 Verification Methods

Several different methods may be used as part of the process of verifying design output. These
include:
– Technical reviews for major projects
– Checking and approval by Engineers who are properly authorised, under the requirements of
Appendix I
– Independent design checks performed in accordance with the requirements of 3.10.5
– Development tests
– Modelling and simulation.
J-4 Technical Reviews

Technical reviews provide the means of assessing progress toward achievement of operating,
engineering and support objectives, progressively throughout the life of a design project. Each
review provides the means to assess aspects appropriate to a specific stage of the task. This in turn
provides opportunities to identify and to correct deviations from the specified requirement and to
highlight potential problems and risks in meeting project objectives.
Technical Reviews serve as a top-level review of the design approach and progress and do not
normally involve detailed consideration of calculations and other data in support of design decisions
for individual elements of the design. However, they are particularly useful in providing the means
to review key assumptions, integration, interface and system design issues (such as compliance of
all elements with environmental design criteria). In addition, they provide the means to review the
contribution of individual design elements to overall performance requirements, such as system
reliability and safety.
Technical Reviews do not replace the requirement for detailed checking and approval of design data.
The starting assumption for each review is that the detailed checking has, or will, take place and that
detailed design information will be subject to design verification and approval processes detailed in
this appendix and Appendix I.
Appendix L provides more detailed information about Technical Reviews including detailed
guidelines and checklists for the conduct of reviews.
J-5 Design Checking

Design checking is the systematic review of design assumptions, calculations, methodology, use of
standards and compliance with mandatory requirements as part of the design process by a
designated person who:
– Holds the necessary qualifications to check design work for the discipline concerned
– Is properly authorised under the provisions of Appendix I
– Has not been directly responsible for producing the design.

Design checks will normally be performed by the design engineer supervising the design tasks
performed by members of that team, but can be performed by any competent and properly
authorised engineer meeting the foregoing criteria.
Design checks shall be carried out progressively for major projects. Formal checks will normally be
aligned with identified design stages for the specific contact involved and must be completed before
release of drawings, specifications and reports for each stage. For example, a formal design check
will be required before release of drawings and other documentation for the concept design and
again at the preliminary design stage. These checks would normally be completed in preparation
for formal review of the design through Technical Review or other means.
A final design check shall be carried out prior to approval and release of design documents “For-
construction”. For minor projects this may be the only formal check carried out, other than those
checks which may be necessary as part of the normal supervision process. The verification checklist
has been designed to provide a suitable basis for authorised engineers to determine whether the
design is of a suitable standard for approval.
J-6 Independent Design Checks

Independent design checks are similar in scope and purpose to design checks except that they are
performed by suitably qualified and authorised engineers who have had no involvement in
developing the design. Thus, the design engineer or supervisor of a team responsible for developing
a design cannot perform an Independent design check, but a competent and properly authorised
engineer from another team may do so.
Independent checks shall be carried out for all critical or safety related systems and elements of the
design, including primary structure, interfaces and software. Checks shall include but are not limited
to key design assumptions and calculations (including modelling results where applicable) for critical
or safety related systems, but may be employed for any element of the design designated by the
Design Discipline Leads.
J-7 Development Tests, Simulation and Modelling

The results of development tests, simulation or modelling may be used as a means of verifying
aspects of the design provided that the test, simulation or model is representative of the specified
design basis.
Where this approach is adopted the scope of the test, and/or details of the models and simulation
programs used must be fully documented. Results shall be documented and included as part of the
design record.
J-8 Use of Verification Records for Design Validation

Under some circumstances tests, checks or other action carried out as part of the design verification
process may be admissible for validation purposes.
This will be appropriate where:
The test or check is carried out on documentation, hardware or software that is representative of the
intended final design configuration
The test or check covers the full scope of action that would be necessary for validation purposes
(See Appendix K)
Documentation requirements for validation checks are observed. (See Appendix K).

Appendix K Design Validation
K-1 Key Requirements
Validation requirements shall be specified for all design tasks performed by or for JHR CRN. This
is necessary not only to ensure that the system or item covered by the design meets defined
Customer needs and is fit for the intended purpose but also to provide the level of assurance required
under the Rail Safety National Law, Rail Safety National Law, National Regulations and the
Workplace Health and Safety Act & regulations.
The following general principles shall be followed for all design validation activities:
– The range and scope of each validation method to be employed, including specific parameters to
be examined or tested and the required outcomes, must be defined in advance of the validation
process. This includes establishment of clear “pass/fail” criteria derived from the specification for
the item.
– The validation shall be carried out using test items or detailed design data that are representative
of the intended final design. In some cases this will involve testing of a production prototype,
sometimes referred to as a “first article”.
– Any differences between physical items offered for validation and the intended final design shall
be analysed and the differences recorded. Any differences shall be reconciled in reviewing the
results of the analysis or test as part of the validation process.
– Changes to validated designs shall be subject to revalidation (including, where appropriate,
regression testing or analysis using one or more of the methods defined in this Manual), to ensure
that the change meets the specified intent and does not introduce any unintended consequences.
Where there is any doubt about the validity of the results for the changed configuration some or
all of the validation process must be repeated for the altered design.
– Validation testing or analysis shall demonstrate the satisfactory operation of the item or system
under conditions which are representative of the specified design envelope e.g. at elevated
temperature, speed, full design loads, vibration, software stress testing.
– Validation records shall form part of the design record for the system or item and shall be retained
for the service life of the equipment.
In some cases, it is not feasible to test the full system or the final design under representative
conditions. For example, it is not feasible to test a complete signaling installation or a bridge under
limit conditions. In such cases the final validation shall comprise the set of results covering the tests
and analyses performed, including full system tests carried out as part of the Commissioning
process. These results are reviewed at a System Verification Review described in Appendix L.
K-2 Validation Methods

The following set of validation methods shall be used for selection of appropriate validation
requirements for all design tasks.
Not all methods are applicable to all tasks and, where possible, the validation methods should be
included in the Engineering Specification and agreed with the Client at the commencement of the
task. For internal tasks, including the development or type-approval of new items or standard
designs, validation requirements shall be determined by person responsible for the task and
approved by the Principle Discipline Engineer.

A period of operation under ambient conditions e.g. laboratory operation, shall not be acceptable as
evidence of validation except where this is directly equivalent to the environment under which the
equipment shall be used.
K-3 Nil (No validation required)

Clauses within an Engineering Specification that do not represent requirements, i.e. are included for
information only, does not require any form of validation.
K-4 Similarity
Some designs for items or systems may be validated by comparison with similar equipment
performing an equivalent purpose and operating in an equivalent environment. This method is
particularly relevant for validation of configuration changes for existing infrastructure, or where type-
approved items or standard designs are to be incorporated in a new system or application.
Similarity may be employed as a validation method provided that the following specific conditions
are met:
– The item used for comparison has already been type-approved by JHR CRN or by a test facility
accredited by NATA or equivalent authority, and
– The intended conditions of use for the equipment can be shown to be equivalent to the conditions
under which previous validation tests were carried out, and
– Evidence of the results of previous tests or other validation method is available. This shall be in
the form of actual test results or certificates issued by an accredited test facility, demonstrating
that the requirements, performance indices, physical characteristics, constraints or functions of
the equipment tested have been met, or
– There is detailed information available to demonstrate the performance of the item within the
CRN/ARTC/Sydney Trains system when operated for an equivalent purpose under equivalent
conditions. Such information shall be compiled and incorporated as part of the validation record
for the equipment.
The use of similarity as a validation method shall be justified and documented in each and every
case and supporting evidence incorporated in the validation record for the equipment or system. An
existing type-approval does not automatically qualify the item for use within a new design, particularly
where the operating environment or conditions of use are different. The use of existing type approved
equipment or designs must be re-validated for the intended application in every case.
K-5 Demonstration or Inspection.

Demonstration and/or inspection may be used to validate requirements, performance indices,
physical characteristics, constraints or functions which either cannot or do not need to be quantified,
or for which a yes/no result can be obtained directly by means of a physical inspection. This includes
abstract parameters that cannot be quantified, such as aesthetics or appearance, ease of operation
and accessibility, physical attributes such as color and shape, and performance aspects such as
maintainability characteristics.
Physical Configuration Audits (described in CRN-PLN-ASM-003 Configuration Management Plan)
contribute to the validation process in that they provide direct evidence that the item or installation
has been constructed in accordance with the approved design.

K-6 Analysis
Analysis may be used as a validation method where it is not either possible or feasible to
demonstrate the performance of the item or system over the operating envelope by physical test or
demonstration. Analysis includes techniques such as mathematical modelling, finite-element
analysis and computer-based simulation, as well as the use of physical simulators that attempt to
recreate part or all of the functionality of the deliverable system, including its interaction with the
environment and other external systems.
Validation by analysis may include the use of Independent verification of design assumptions,
calculations and the results of tests and analysis of compliance with lower-level requirements, or by
the achievement of other (related) performance objectives. Independent design checks are covered
within Appendix J.
Mathematical or simulation models used for validation purposes (or for any purpose during the
design process) must be carefully assessed to ensure that they provide an accurate representation
of the characteristic or performance to be validated. Data used in models must also be rigorously
assessed to ensure that it is relevant and representative for the intended application.
Models must be separately validated by comparison of physical test results at selected points over
the operating range with the predictions of the model. This is necessary to demonstrate that the
model provides an accurate representation of actual operating performance and that the results
obtained can be safely extrapolated to cover the full operating envelope.
Validation of models shall be required in all cases where a model is prepared for a specific project
or design task. Results of the validation shall be incorporated and retained as part of the design
record.
The requirement for validation of a simulation or model may only be waived where the model has
previously been developed and validated for the application, such as E-Train, M-Train or
commercially developed applications such as Simu++, or software analysis tools. In these cases,
the appropriate Principle Discipline Engineer is to assess whether the previous validation covers the
conditions of use and operating parameters for the intended application and the extent to which the
model requires revalidation for the current application.
K-7 Testing
K-7-1 General Requirements
Testing is the preferred method of design validation, either stand alone or in combination with
analysis techniques where it is not possible or feasible to test over the entire operating spectrum.
Testing is applicable to both hardware and software products and to integrated hardware and
software designs.
Tests shall be designed to validate performance characteristics of the design against specification
requirements. Testing may be carried out on discrete items or on systems/installations during
integration or commissioning, dependent on the scope and purpose of the test. Examples of test
activities include functional tests, physical tests, testing of materials to establish performance in
corrosive environments and environmental tests.
Validation testing shall be designed to demonstrate the performance of the item over the full set of
operating conditions covered by the specification. This includes tests designed to demonstrate the
ability of the item to operate satisfactorily over the specified design life, such as the use of tests at
elevated levels of temperature and/or vibration to simulate accelerated life conditions.

The range of tests to be performed and the pass/fail criteria for each test or test parameter shall be
determined and documented in advance of the test being performed.
K-7-2 Type Testing

Type testing is a form of validation test that is normally conducted to validate the performance and
suitability of specific items and/or standard designs for use in CRN Infrastructure. In many cases
type testing will be carried out on a number of alternative items from different manufacturers, to
demonstrate their ability to meet specified functional and performance requirements within the
specified CRN operating environment.
The following specific requirements shall apply to all type-testing and approvals;
– Performance requirements for the item must be established and documented in a specification or
equivalent design documentation. This includes all operating performance parameters as well as
full definition of environmental design criteria
– The range of tests to be performed must be determined in advance and pass–fail criteria
established for each test parameter
– Results of the tests must be documented and maintained as part of the design record for the
equipment.
Items or standard designs that successfully complete type testing are classified as “type-approved”
items. Type approval applies only to the specific Manufacturers Part or Model number that has
successfully met type-testing requirements. Superseding or alternative items from the same
manufacturer or family of products shall be re-validated using one of the methods set out in this
Manual.
Specific types of items that have been type approved for a particular application are to be included
in a Type Approved Products List. This list is to be included in the specification and/or drawing
covering the requirements of JHR CRN Standard items or designs, and are to be updated to include
new items, as additional type approvals are granted.
K-7-3 Test Plans

Test Plans shall be prepared and documented for all validation test activities. This requirement may
be met by inclusion of validation requirements in a System Test Plan, produced to document the full
set of testing activity within a specific project, or by individual plans.
Test Plans are to be used to provide a consolidated statement and record of all validation test
requirements. Plans shall include detailed test procedures or reference to such procedures, to
specify individual performance parameters, pass/fail criteria and test results.
Test Plans and results shall form part of the design record for all new or altered infrastructure
designs.
K-8 Commissioning
Commissioning may contribute to the total validation process but is not itself a form of validation.
The purpose of commissioning as part of the validation process shall be to ensure that:
– Elements of the design e.g. individual components & equipment, have been separately validated
through one or more of the methods defined in Appendix C and that detailed results are available

– The connection and operation of system elements and interfaces which can only be checked
within be final installation are verified / validated during the Commissioning process. This will
include testing under maximum load or usage conditions where applicable
– All necessary action has been taken to ensure that installation is in accordance with the approved
design and that the new or altered infrastructure is suitable in all respects to be used for normal
services.
Commissioning requirements shall be documented in a Commissioning Plan that is defined and
approved before commencing the commissioning process. Commissioning Plans may be required
for part of a System Test Plan for Major Projects. Pass/fail criteria shall be documented for each
parameter or function to be tested and the results of each test or inspection shall be recorded.
Commissioning records shall form part of the design record and shall be incorporated in configuration
documentation for the infrastructure system.

Appendix L Technical Design Reviews
L-1 Technical Reviews to be Specified for Design Projects
The requirement for formal Technical Reviews shall be included the Project Plan for all Major and
selected Minor projects undertaken by design staff.
The scope of the review process must be aligned to the nature and complexity of the project task, to
maintain the benefits of the process without “overloading” minor projects with excessively complex
requirements.
L-2 Technical Review Process

The Technical Review process comprises a series of reviews carried out at designated points in the
development of a project.
Develop project
concept & define
Develop & refine functional baseline
requirements
Develop
engineering System concept
specification & review (major
RFT (where project only)
applicable)
Call & evaluate

tenders (where Award contract (if
required) applicable)
Initiate project
Requirements
System definition
Establish development baseline
analysis & initial

review(s)
design synthesis
Develop Preliminary design

preliminary design review(s)
construction baseline
Develop detailed Critical design

design review(s)
Establish For-
Construct and/ or System verification

develop review(s)
prototypes
Verify and test Physical
Commissioning configuration audit
Production (As-built)
baseline
Project enters
service
Figure 13: Complete technical review process for JHN CRN application

Several specific types of reviews have been adopted by JHR CRN as a basis for project planning.
However, the scope of each is flexible. The overall process exists to support the need for progressive
evaluation of the directions and progress of the design team (either JHR CRN or subcontractor)
toward meeting the design output requirements for the project.
The complete set of Technical Reviews that may be applicable to JHR CRN projects is shown in
figure 13. The diagram depicts the potential application in the most complex case, i.e. for a Major
design and construct project and, while the principles are relevant to all projects, the diagram is not
intended as a model for application in every case.
Each review is shown on the diagram as taking place as a single event. While this is appropriate for
smaller projects it will often be more effective for major projects to hold each review as a progressive
series of events and to examine individual sub-systems or items separately. However, a final system
level review should be completed where the reviews are held progressively, to ensure that all
interface and integration issues have been addressed.
L-3 Technical Reviews - General Requirements

Technical Reviews should normally be conducted as formal meetings, involving the appropriate
design staff and other stakeholders. This is essential to gain the widest possible range of inputs and
to ensure that all relevant considerations have been taken into account.
The purpose of Technical Reviews cannot be met effectively by simply assigning one or more design
engineers to review the drawings produced for the project. This will generally be required as part of
the wider design verification process described in Appendix J and may contribute to the outcomes
of a Technical Review. However, the verification process does not create the opportunity for
stakeholders to assess, and where necessary challenge, the fundamental assumptions and
proposed methods of meeting the specified requirement.
It is critical that the evaluation of assumptions and approach be carried out with reference to the
requirements specified for the project. Technical Reviews must not be used as a forum for reviewers
to pursue personal preferences or prejudices in assessing proposed design solutions.
As part of the risk analysis process, the Hazard Log and Analysis must be completed before
Preliminary Design Review(s) are conducted for the project or individual system or item as applicable
in accordance with Appendix G: Hazard and Risk Analysis.
The design must be evaluated on the basis of conformity with specified requirements. Any proposal
to alter the specification requirement shall be introduced by formal design change or contract change
action, should the Review indicate that these are not consistent with current user requirements.
Requirements for Technical Reviews shall be included in all sub-contracts let by JHR CRN for design
services. The outcomes of each Technical Review, including actions arising from the review, are to
be documented and will form part of the design record for the project.
Table 3 summarizes the types of Technical Review that may be conducted for JHR CRN design
projects. The following paragraphs provide an outline of the purpose and application of individual
reviews.

Table 3: Summary of Technical Review Processes
REVIEW NAME PROJECT PHASE APPLICATION PRIMARY PURPOSE
System Concept Before Engineering Major projects only. Ensure that the specification and
Review (SCR). Specification and RFT contract SOW are complete and
are finalised properly represent client
requirements
System Early in preliminary Major and Minor Ensure that Specification
Definition Design Phase Projects. requirements are complete and
Review (SDR) unambiguous.
Preliminary Completion of Major projects. Verify that preliminary approach
Design Review Preliminary Design May be combined with is consistent with specified
(PDR) CDR for Minor projects. requirements.
Critical Design Completion of Detail Major Projects. Verify that detail design appears
Review (CDR) Design The requirement may to meet design intent for the
be met by a simplified project.
process for Minor Provides a major input for final
Projects acceptance of sub-contract
design projects.
System Construction Major and Minor Verify that all testing and
Verification Projects verification action is complete
Review (SVR) prior to final commissioning and
project acceptance.
Physical Construction / Major and Minor Comparison of “as-built”
Configuration Commissioning Projects configuration with design
Audit (PCA) documents.
L-4 System Concept Review

The System Concept Review (SCR) is normally only applicable for large scale Major Projects, such
as a new line or major rearrangement of existing infrastructure. The review is normally to be carried
out during the concept development phase, after the preparation of a detailed engineering
specification but prior to release of a Request for Tender (RFT) for the project.
The primary purpose of the review is to ensure that the project specification is complete, accurately
represents client and statutory design requirements and that the RFT covers all requirements for
effective management of the design development or acquisition contract.
The review will be carried out between JHR CRN Engineering and other representatives and
stakeholders, for the purpose of ensuring that all client requirements have been incorporated into
specification and contract documentation and to resolve any omissions and inconsistencies between
the client requirement and the documentation.
L-5 System Definition Review

A System Definition Review (SDR) should be carried out as early as possible after the start of Major
and Minor design projects. The main purpose is to ensure that the Engineering Specification fully
defines the requirements for the task and that any inconsistencies or omissions are identified and
resolved.
The SDR should take place after the specification has been reviewed in detail by all applicable
discipline groups and following initial requirements analysis and allocation. Refer to Appendix D for
additional details. The SDR is to be convened by the designated JHR CRN Project Manager.

SDRs for Major projects are to be attended by representatives of each design discipline involved in
the project and, where possible, by client representatives and other stakeholders. For Minor projects
the SDR may take the form of a review of the task between the engineer responsible for the task
and the Project Manager, with involvement of the Design Discipline Lead where appropriate.
System Definition Reviews for sub-contract design tasks shall be attended by representatives of the
sub-contractors’ design staff, the JHR CRN Project Manager and representatives from JHR CRN
appropriate to the scope of the task. The Project Manager will be responsible for chairing all such
reviews
L-6 Preliminary Design Review

The purpose of Preliminary Design Reviews (PDR) is to assess whether the proposed approach for
the design is consistent with the functional and performance requirements of the Engineering
Specification.
PDRs should take place when the preliminary design has progressed to a level of detail that will
allow the intended approach to be assessed for compliance with the design intent of the specification.
The PDR may be conducted in one session or in several sessions to consider individual parts of the
design.
L-7 PDR for Minor Projects

A separate PDR is not normally required for minor projects. The Project Manager may schedule a
review to cover the intent of the PDR where two or more disciplines are involved and it is necessary
to verify interfaces or other common design requirements before proceeding to detail design.
L-8 PDR for Major Projects or Sub-contracts

Separate PDR(s) should normally be scheduled for Major projects completed internally within JHR
CRN and are required for all sub-contract design tasks.
The Project Manager is responsible for convening each PDR stage
PDRs for projects undertaken within JHR CRN should be attended by design and integrated support
staff having a responsibility for the project as well as operations and maintenance staff from the area
owning the project.
PDRs conducted with sub-contractors should be attended by the Project Manager and the Design
Discipline Head or the engineer responsible for the task from each discipline involved. JHR CRN
staff nominated to attend PDRs should have reviewed information delivered by the Contractor prior
to the meeting.
Minimum levels of information necessary to conduct an effective review include:
– Preliminary design and layouts drawings, including interface definitions
– A summary of key assumptions made by the designer
– Initial selection of major components and materials
– Functional flow diagrams or equivalent for software
– The results of preliminary risk and hazard analysis
– Preliminary reliability models and predictions available.
Design reports and calculations may be required in support of the review process but are not
normally delivered in advance of the review.
L-9 Critical Design Review
The Critical Design Review (CDR) takes place at or close to the completion of the detailed design
phase. The primary purpose is to ensure that the design appears to be suitable in all respects to
proceed with construction/fabrication of hardware items or coding of software.
In cases where the project is limited to design i.e. separate design and construct contracts are
involved, the CDR will form a major input for determining whether the requirements of the design
contract have been met.
L-10 CDR for Minor Projects.

The intent of the CDR may be met for Minor projects by a joint review of the verification checklists
completed by the responsible engineers from each discipline. Refer to Appendix J.
Design and integrated support staff having a responsibility for the project, as well as operations and
maintenance staff from the region owning the project should attend CDRs for Minor projects.
L-11 CDR for Major Projects or Sub-contracts

The scope of the CDR is similar to the PDR, but addresses the proposed design in more detail. This
includes detailed drawings and supporting design information, safety and hazard analysis and final
reliability models and predictions for the design.
The Project Manager is responsible for convening each CDR stage.
L-12 Technical Reviews Associated with Construction

The following reviews are applicable to the construction phase of projects and will not normally be
within the scope of JHR CRN design tasks. However, the scope of design tasks may include the
preparation of documentation to support these reviews, such as Test and Commissioning Plans or
Operating and Maintenance Manuals, and design staff may be required to support the processes
during the construction phase.
L-13 System Verification Review

The System Verification Review (SVR) covers a review of the scope and results of all tests carried
out as part of the contract. The primary purpose of the SVR is to verify that performance and other
requirements included in the specification have been achieved and that the project is ready for final
commissioning.
The SVR takes place when all testing and validation required under the contract has been completed
and results are available. It will usually include the results of pre-commissioning tests where
applicable. This may not occur until very late in the project, since the hardware or software to be
tested must be fully representative of the final product.
The SVR does not involve actual testing. This will have taken place beforehand and in most cases
the results will have been reviewed progressively, in advance of the formal SVR. The review process
may include the adequacy of delivered design documents and support documents including
operating and maintenance manuals.
The SVR includes review of any aspects of performance which have not been met and to establish
the requirements for and timing of corrective action necessary for final acceptance of the project or
product.

L-14 Physical Configuration Audit
Physical Configuration Audit (PCA) is a part of the Configuration Management process. It involves
a comparison of the “as built” configuration of the infrastructure with the design documentation.
PCAs provide the formal means of ensuring that the physical installation conforms to the approved
design and thus the basis for formal acceptance of the project. The PCA also provides the means of
formally reviewing the documentation for the design, to ensure that it is an accurate and complete
record of the “as-built” configuration.
PCA may be carried out progressively but must be completed in time to enable the “as-built”
documentation to be verified prior to project commissioning and closure.

Appendix M Design Change Management
M-1 Design Responsibility
Design responsibility for projects will either rest with the JHR CRN project team or will be part of the
sub-contract (or sub-contracts) let for the project. The process and responsibility for managing
design changes varies slightly between the two cases, as follows:
M-2 Projects Designed Using JHR CRN Resources

For design projects undertaken by JHR CRN design staff the Project Manager is responsible for:
– Ensuring that the final design conforms to the customer specification, as outlined in Section 2 and
Appendix J.
– Raising and processing Design Change Requests/Notices (DCN) under the circumstances
specified in this appendix in conjunction with the responsible design engineer.
M-3 Projects Developed under Contract

For projects undertaken under a sub-contract arrangement the JHR CRN Project Manager is
responsible for:
– Inclusion of design change management procedures that meet the requirements of this Manual
in the Contract
– Ensuring that the Contractor raises design changes under the circumstances specified in Section
3.13.4, for approval by the appropriate JHR CRN Design Discipline Head(s), or by the JHR CRN
Client as applicable.
– Approving or managing the approval process for changes proposed by the sub-contractor, in
conjunction with the responsible design engineer.
M-4 When to raise a DCN

A Design Change Request is to be raised for changes proposed during new projects under the
following circumstances.
M-5 Before Approval of Design “For Construction”.

A DCN is to be raised for a change proposed at any time after the Engineering Specification has
been approved and/or a contract awarded which would:
– Result in a non-compliance with a functional or performance requirement of the design basis
established by the specification
– Vary the scope of the design task such that the approved budget will be exceeded
– Alter or affect an interface between the infrastructure/item modified by the change and another
item or system.
All other changes introduced during the preliminary and detailed design stages are considered to be
part of the normal design evolution process and are approved by the responsible engineer within
normal project procedures.

M-6 After Approval of design “For Construction”
A DCN is to be raised for any change proposed after the design has been approved “For-
construction” and the design is frozen. Changes in this category will normally be raised in the form
of a Variance Request (sometimes described as Deviation or Waiver).
Changes which would lead to the approved budget being exceeded will require additional financial
approval, in accordance with existing procedures.
The logic for deciding whether a DCN is required is shown in Figure 14
Potential Change Identified

During Design or
Construction
DESIGN TEAM ACTION
YES
Major Change?
See Paragraph 5.3
Submit Change to Delivery NO

Manager for Action
YES
Design Approved
“for Construction”?
NO
Submit Change to Delivery
Manager for Action
No DCN
Required
Figure 14: Determining requirement for a DCN
M-7 Categorisation of Changes

DCNs are to be categorised as Major or Minor.
M-8 Major Changes

Design changes proposed at any stage in a project (i.e. before successful final commissioning) are
to be classified as “Major” if the change would:
– Result in a non-compliance with any functional or performance requirement of the specification
– Affect any interface. Interface management is further described in Appendix F but interfaces that
may be affected include:

– Physical and functional interfaces between JHR CRN elements of infrastructure
– Interfaces with externally controlled installations or equipment, including rolling stock
– Operational and procedural interfaces, including any other Safeworking practices.
– Lead to a change in the design approved “For-construction” which would:
– Alter the operation and function of the approved design i.e. the introduction of the change will lead
to a change in operating functions or limitations, and/or
– Reduce any design factor of safety or plant durability, and/or
– Alter material specifications or characteristics
– Affect safety or environmental compliance.
– Affect the design parameters of any Programmable Electronic System (PES) or software
installation. Any change which affects the format or content of reports or displays produced for
the purpose of warning users or operators of a hazardous or unusual condition, is to be classed
as Major
– Lead to an increase in the cost of the project, such that the approved budget is exceeded or the
contingency would be significantly reduced by acceptance of the change.
M-9 Minor Changes

All other changes proposed following approval of the design “For-construction” which do not meet
the criteria for Major changes are to be classified as Minor.
M-10 Processing and Approval of Changes

The general process for raising and processing DCNs is shown in Figure 15. Requirements for
raising and approving Minor and Major changes and Variances shall be included in all contracts
which include a design responsibility and are to be described in more detail in Configuration
Management Plans for each Region, Major Project or the Engineering Division.

Figure 15: Processing and approval of DCNs and variances

A DCN form, in the general format shown in Attachment 1, is to be used for processing DCNs (Minor
and Major) and Variance requests.
The use of a common form for DCNs and Variances avoids the need to prepare additional
documentation where a request for Variance is assessed as requiring a permanent change, with a
consequent need to make changes to the approved design documentation. Approval of a Variance
does not require a change to configuration documentation, but a copy of the approved Variance shall
be filed with design files and records for the project and recorded in the appropriate database for
tracking corrective action.
Changes are to be processed for approval in accordance with the general steps shown in the
flowchart in Figure 15. Key requirements are as follows:
– Major changes are to be reviewed by the Project Manager in the first instance, with specialist
design /engineering input to assess the acceptability of the proposed change.
– If the proposal is acceptable from a design perspective the proposed change is to be forwarded
to the Customer for acceptance of operational and cost implications.
– All DCNs and Variances shall be processed for design approval, in accordance with the
requirements of Appendix I.
– Major changes involving an increase in project cost may form part of a Contract Variation and/or
final approval may depend on the approval of supplementary funds. Changes that will extend
the completion date for the project will require a contract change, irrespective of the impact on
the design.
– No action is to be taken to implement the change or to advise the Contractor of approval until
financial approval has been obtained. Management of changes during construction periods,
particularly where work is being carried out under possession is covered by Appendix I.
– Approved DCNs are to be filed with the design record for the project. Refer to Appendix O for
additional details.
JHR CRN Design Change Request/Notice (New Projects) Template attached below.

JOHN HOLLAND RAIL
CRN DESIGN CHANGE REQUEST/NOTICE OR VARIANCE (NEW PROJECTS)
DCN NUMBER. PROJECT ID. DCN? or VARIANCE

ITEM AFFECTED DWG OR SPEC. REF.
HARDWARE? SOFTWARE / PES? INTERFACE?

DESCRIBE PROPOSED CHANGE /VARIANCE (Attach notes / sketches if necessary):
REASON SAFETY RELIABILITY: MAINTENANCE: PERFORMANCE/DURABILITY:

FOR
CHANGE:
OTHER (Describe):
DOES CHANGE AFFECT: COST? SCHEDULE? BOTH?
ORIGINATED BY: POSITION:
COMPANY: PHONE: DATE:
JHR CRN DESIGN ASSESSMENT AND DETAILS (Attach notes / sketches /Drawings as necessary)
CLASS. MAJOR MINOR VARIANCE RECOMMENDED: YES/NO (Major DCN only)

HAZARD REVIEW? SPARES? MAINTENANCE/TMP? TRAINING? PROCEDURES?
DRAWING UPDATE? (Attach full list)

Design Approval Name & Position: Date:
RECOMMENDED: YES / NO CONTRACT CHANGE? ADDITIONAL FINANCIAL APPROVAL?

(Major DCN only) YES NO YES NO
JHR CRN PROJECT MANAGER DATE:
CUSTOMER APPROVAL/COMMENTS:
APPROVED FOR IMPLEMENTATION: YES / NO
Name & Signature Date:

Appendix N Design Documentation and Records
N-1 Key Requirements
Design related configuration documentation and design records for CRN infrastructure shall be
prepared and maintained in accordance with the following criteria: (refer: CRN GM Series and
Document Management Procedure)
– All new documentation is prepared to a consistent standard and format for common document
types
– Each document shall bear a reference that uniquely identifies it within the set
– Each document shall be properly registered and controlled within the defined area of
responsibility.
N-2 Documentation Standards

a. Approved Documentation Types
Many different types of documents have been prepared to describe the design of the NSW rail
system over the life of the system. Some of these have been partially or wholly superseded by
other types of documents or records, but the original documentation is retained and is
occasionally referenced or used within current design documentation.
The JHR CRN Engineering section maintains a current list of approved document types for use
by all design Sections/Units in documenting new designs. These approved document types will
be listed in the Engineering Standards System manual JHR CRN GM 001.
b. Drafting Standards
JHR CRN will adopt Australian Standard AS 1100 for Technical Drawing and the current ASA
CAD Manual published on the ASA website T MU MD 00006 ST Engineering Drawings and CAD
Requirements
JHR CRN will also adopt ASA CAD Resource Files listed at the ASA website
In adopting the ASA CAD Manual and Resources the following modifications apply:
 References to ASA will be replaced with JHR CRN
 Titles and Title Blocks ASA will be replaced by JHR – CRN and the Transport NSW logo will
be replaced by the JHR – CRN logo.
N-3 Contractor Drawings and Documentation

Design documentation to be delivered within the scope of design contracts shall include, but not be
limited to:
– Configuration documentation, including approved specifications, drawings, plans and other
documentation that fully defines the design to a level of detail that would permit it to be
constructed, i.e. a “For-construction” Baseline,
– Design records, including calculations, copies of simulation models developed as part of the
contract task (or precise definition of commercially available or proprietary modelling tools used)
together with simulation/modelling results, FMECA, design reports and other supporting

information necessary to permit changes to the design by JHR CRN or a third party after the
conclusion of the design contract,
– Verification and validation records, including independent design checks where applicable,
– Construction Methodology and temporary works design,
– Test plans and procedures where appropriate,
– Developed Risk Analyses compatible with JHR SQE RM process.
Design documentation prepared by the contractor shall be incorporated directly into the JHR CRN
configuration documentation (i.e. without re-drawing) unless compelling reasons exist for an
alternative solution. This is the most cost effective method of acquiring the necessary design data,
provided that the documentation can be supported within the JHR CRN system.
The following provisions must be included in all design sub-contracts, to ensure that the
documentation supplied can be readily integrated into the JHR CRN master configuration record and
modified and maintained during the life of the asset:
– A block of JHR CRN drawing numbers are to be assigned to the project, for inclusion on each
drawing. Contractors shall be required to either use the JHR CRN numbers as the primary
reference or to include a dual numbering system on the drawings (i.e. both JHR CRN and
Contractor Numbers). The latter approach is the preferred method, since it provides traceability
of a drawing in both the Contractors and JHR CRN systems.
– CAD drawings and files should be in a format compatible with a nominated CAD system in use
within the JHR CRN. Detailed requirements for delivery of CAD drawings and files will be in
accordance with the requirements of the ASA CAD Manual as described above. CAD files shall
be capable of being modified and updated by JHR CRN to reflect “As-built” and subsequent
changes to asset configuration.
– Provision for JHR CRN asset numbering is required in the Title Block.
– All drawings and other design documents shall bear an Issue/Revision Number, date, sheet
number (where applicable) and other data needed to provide unique identification.
– All design documents shall include evidence of approval by a Contractors representative holding
a delegation approved by the Manager Engineering Services or delegation issued in accordance
with a system approved by the Manager Engineering Services or Principal Discipline Engineer.
– Details of drawings and other relevant documents shall be listed in the “For-construction” Baseline
for the project.
N-4 Documentation Control

N-4-1 Configuration Documentation
CRN-PLN-ASM-003 Configuration Management Plan establishes the requirement for a master
record of approved configuration documentation to be maintained for CRN infrastructure. The
purpose of this requirement is to ensure that a single, authoritative record exists for the approved
configuration of any segment of the infrastructure at any time.
This requirement does not necessarily infer that all documentation is to be retained in one location.
However, it is essential that the source of master configuration data e.g. survey and geotechnical
data for a specific site be clearly identified and controlled.
Master configuration documentation and data covering any characteristic of any element of the
infrastructure must be derived from a single, defined source. Any subsidiary records must be clearly
identified as “copies” and verified for accuracy before use for any design task. Master copies of all
configuration documentation shall be lodged with the JHR CRN Document Controller following
approval of the design “For-construction” and following update of the documentation to ‘As-built’
standard. “For-construction” documentation may be released in stages where appropriate.
N-5 Design Files and Records

Design files, records shall be complete for the task or project to which they relate.
Design Leaders will ensure that a copy of the records plus any databases, spreadsheets, survey
data, geotechnical data, are registered and retained within their document management system and
electronic copies lodged with JHR CRN Document Controller for registration and storage in
accordance with JHR CRN Document Management Procedures.
N-6 Documentation for Unapproved Projects

Design documentation that has been approved “For-Construction” but which is not subsequently
implemented, i.e. the project is cancelled or suspended prior to construction, shall be treated as
design records under the requirements in Paragraph 3.14.7.
N-7 Superseded Documents

Superseded documents shall be:
– Clearly marked as superseded
– Segregated from current documentation
– Retained for the period required under NSW statutes or for such other period as is required to
preserve the design history and traceability for the infrastructure.
N-8 Retention Periods

Design records shall be retained for the operating life of the asset or for such other period as required
by NSW Legislation. Australian Standard AS ISO 15489 Records Management shall be used as a
guide for development of records management strategies.

Appendix O Integrated Support Requirements
O-1 Integrated Support Analysis – General Requirements
The term integrated support analysis is used to describe the process for identifying support
requirements for new or modified rail system assets and for ensuring that appropriate action is
initiated when assets are superseded and removed from the CRN Asset Register or material
inventory.
Integrated support analysis is an ongoing process that can be initiated at any time during the life
cycle of an asset. This Manual focuses on the application of analysis techniques in conjunction with
other design action, in support of a change to the configuration of infrastructure assets.
Analysis of integrated support requirements shall be carried out as an integral part of all JHR CRN
design projects. Section 3.10.5, Design Checking in Appendix J includes the key integrated support
requirements to be considered as part of the design validation process before a new or altered design
is approved. Integrated support documentation and support provisions must accurately reflect the
approved configuration of infrastructure assets.
The main elements of integrated support activity and the main supporting system tools are shown
on the diagram in Figure 16. This simplified diagram does not show all relationships, and additional
tools are identified both within this Manual and in supporting procedures maintained by Engineering
Services (ES).
Configuration change
management (see ED
0015)
Reliability & maintainability

Hazard & risk analysis
assessment (see ED
(see ED 0008)
0009)
PRR & Subsidiary

risk registers
New or altered
Change approved infrastructure
“For construction” design
Analysis
software
Change in Change in
facilities or training
tools? requirements?
Maintenance
requirements &
TMP? (see ED
Change in 0019)
Change in
operating or
spares support
maintenance
required?
procedures?
Integrated Support
analysis
Figure 16: Integrated support analysis as part of configuration change action

O-2 Responsibility for Integrated Support Analysis
Many of the inputs to the integrated support analysis process flow directly from design decisions.
Design engineers and managers have a primary responsibility to ensure that integrated support
requirements are taken into account when developing new designs or introducing changes to
existing infrastructure. Satisfactory definition of revised support requirements is a condition of design
approval in accordance with Appendix I.
Application of the analysis processes and techniques requires specialised skills and knowledge and
the JHR CRN Engineering Services has been established as a center of expertise for both the
development and application of these techniques. In addition, JHR CRN will have access to a wide
range of analysis data. This can be used to support future analyses, serve as a corporate record of
standard tasks and requirements, and reduce the time taken for analysis of new equipment and
infrastructure.
Development of integrated support provisions for new or altered designs shall be a joint process
within the JHR CRN Engineering Services organisation.
Design Engineers are responsible for providing data on proposed changes to Engineering Services
staff and are to seek assistance from Engineering Services staff to complete detailed analyses.
Engineering Services staff are responsible for assisting with the completion of detailed analyses
and for providing designers with recommendations arising from the analysis. These may either
impact on design decisions or be implemented following approval of the configuration change. They
will be recorded in the Engineering Services databases and related documentation.
O-3 Timing of Support Analyses

Integrated support analyses must be completed in conjunction with the development of changes to
the design. However, implementation of changes to support documentation and provisions cannot
be implemented until the change has been approved and the work is proceeding.
Release of updated integrated support provisions shall be managed to ensure that the information
is available at the time that new or altered infrastructure is commissioned for use.
O-4 Approval of Integrated Support Requirements

All changes to integrated support provisions for CRN infrastructure shall be managed and approved
under a rigorous process that is equivalent to the design approval process established in Appendix
I. Key requirements are that:
– All proposed changes shall be documented and registered
– Detailed records shall be maintained covering the basis for all changes to integrated support
requirements. These shall be managed in the same way as other design records
– New requirements, or changes to existing requirements shall be approved by a person who has
been delegated to do so within the terms of the JHR CRN Engineering Authority Policy.
The Manager Engineering Services shall ensure that detailed instructions are developed and
maintained for the review and approval of new and changed integrated support provisions for CRN
infrastructure.

O-5 Maintenance Requirements
Maintenance requirements for any infrastructure item are defined within maintenance policies for the
equipment which specify:
– What tasks are to be performed
– When they are to be carried out
– How (i.e. the method by which) they are to be completed, which includes safety procedures as
well as tools and equipment required for completion
– The organisation responsible for completion
– The necessary competency and accreditation to complete the task.
Determination of the task content and the task interval are the key decisions. These requirements
provide the means of preserving the safety and integrity of all infrastructure and provide the basis
for determining other elements of the complete maintenance policy, as well as related support
requirements.
JHR CRN shall use Reliability Centered Maintenance (RCM) techniques to determine task content
and intervals. The RCM methodology is based on analysis and application of the reliability
characteristics of equipment to determine maintenance needs. This process is further described in
Appendix H.
The method by which the task is to be performed, and the skills needed for the task, is determined
through task analysis. This includes hazard and risk analysis as well as considerations of the
detailed physical characteristics of the equipment and the maintenance actions to be performed.
Organisational responsibility for each task shall be determined through the Level of Repair Analysis
(LORA) process. This process is outlined below.
Maintenance requirements for JHR CRN infrastructure shall be documented in Technical
Maintenance Plans (TMPs) and associated service schedules. JHR CRN Principal Engineers shall
be responsible for issue and updating of TMPs and Service Schedules.
O-6 Level of Repair Analysis

Level of Repair Analysis (LORA) is a technique for reviewing and analysing the economic
considerations of repair decisions and for determining whether items of a particular type should be
recovered through maintenance or discarded. The end result of the LORA process is to determine
“if” failed or partially failed equipment is to be repaired or overhauled and, if so, at what level of repair
facility.
The ILS Manager shall be responsible for developing and documenting LORA techniques for use in
the development and amendment of TMPs.
O-7 Spares Support Requirements

Maintaining the safety, integrity and reliability of infrastructure assets requires that replacement
spares meet the standard specified in the approved design. Spares of the correct standard must be
held in sufficient quantity to achieve the required levels of availability and reliability.
These requirements, in combination with the approved maintenance policy for individual items of
infrastructure, provide the basis for determining spares holdings and distribution for CRN
infrastructure, taking into consideration available funding and other economic factors.

Changes to asset configuration have clear potential to alter spares support requirements, and it is
essential that the impact on both the range and quantity of spare items be assessed as part of all
configuration change action.
In the case of new infrastructure, the process must lead to a determination of new items that should
be added to the inventory. For changes to existing infrastructure the process must determine
whether changes are necessary to the range and quantity of existing stockholdings and/or the need
to remove superseded items from the inventory. In all cases the spares assessment process must
document procurement standards for replacement spares that directly reflect the requirements of
the approved design.
The ILS Manager shall document and implement a spares assessment methodology based on
recognised spares assessment principles. This should include appropriate probability analysis and
techniques, to determine the quantity of spare items needed to support specified infrastructure
availability requirements and to perform availability–cost tradeoffs.
Spares assessments shall be reviewed for all configuration changes. Recommended changes to
spares support strategies are to be included in the integrated support documentation for all relevant
changes especially where the spares holding requirements have changed.
O-8 Facilities and Tools

Changes to requirements for facilities and tools shall be considered as part of the task analysis
completed in accordance with Section 3.16.8 of Appendix P and the results incorporated in Work
Management and Process Control Plans.
O-9 Training
The introduction of new assets, or changes to the design of existing infrastructure, may create the
need to train operators and/or maintenance staff on the use and maintenance/repair of the
equipment.
The ILS Manager, in conjunction with the design engineers responsible for a task or project, shall
carry out a preliminary assessment of the change, to determine whether the scope of the change
warrants additional or different staff competencies from those currently specified.
Assistance shall be sought from the Manager Organisational Development to conduct detailed
training needs analysis to determine the best option to acquire the required competencies. The
needs of existing field staff and the training of new employees are to be considered in making this
assessment, to ensure that training requirements are maintained in line with the approved
infrastructure configuration.
In conjunction with Manager Organisational Development, Engineering Services staff shall develop
guidelines and instructions for On-the-Job Training where this will adequately meet the need.
Requirements for training are to be included in the incorporation instructions for any approved
configuration change or for projects introducing new equipment.
O-10 Documentation and Manuals

JHR CRN design staff are to identify the need for update of operating, maintenance and other
manuals as part of the configuration change action.
Principal Discipline Engineers shall be responsible for developing changes to affected manuals,
based on inputs from design engineers. Design staff are responsible for specifying technical content
for operation and maintenance of equipment, including limits and tolerances for tests, approved

repair methods and limits. Principal Discipline Engineers’ staff will incorporate additional information
covering task performance, including Process Control Plans where applicable.
Specific controls for review and validation of manual content, as well as controls for release of new
manuals ore revisions, will be in accordance with JHR CRN Instructions for document development
and management.
O-11 Integrated Support Database

Manager ILS shall progressively establish and document an integrated support database for CRN
infrastructure and equipment. The purpose of the database is to provide a consolidated record of
integrated support requirements for CRN infrastructure.
The database should be maintained in the appropriate section of the JHR CRN IMS and, if possible,
be available directly to both Engineering Services and field staff to ensure that a common and up to
date record is available to support all design and maintenance activity.

Appendix P Maintenance Requirements Analysis
P-1 When to Review Maintenance Requirements
Review of maintenance requirements is an ongoing process that may be initiated from several
sources. These include requests from field users, reviews resulting from regular assessment of
maintenance performance carried out by users or Engineering Services Staff, or as a result of
changes to the configuration of infrastructure assets.
Maintenance requirements shall be reviewed in conjunction with the design process for:
– All configuration changes to existing infrastructure that are assessed as “Major” in accordance
with the definitions outlined in CRN-PLN-ASM-003 Configuration Management Plan
– All new assets introduced onto the CRN where a Maintenance Request does not exist.
Specific triggers for initiating a review of maintenance requirements include, but are not limited to:
– Changes to the physical configuration of the asset, particularly where a part has been replaced
with another of higher (or lower) reliability.
– Changes in use which may come about through operational factors, e.g. an increase in traffic
density or loading, or may be due to changes in procedures that increase or decrease the number
of times that an item is operated. Use of the same type of item within a different environment e.g.
within a tunnel rather than being exposed to the full range of climatic change, may also lead to a
need to review maintenance requirements.
– Changes in item or system functions, particularly where the function is critical to safety or
operational availability.
– Unsatisfactory levels of in-service reliability. In this case the analysis serves to establish whether
existing maintenance tasks are effective and whether additional tasks or design change action
may need to be considered.
– Introduction of new technology that improves the performance and serviceability of the asset or
its components, e.g. replacement of incandescent light bulbs with LED technology.
Although review of maintenance requirements is mandatory in conjunction with configuration
changes the set of maintenance requirements do not form part of the approved configuration (with
some limited exceptions described in the following paragraph).
Maintenance requirements are determined to reflect the physical and functional characteristics of
the asset but may also be governed by economic considerations for non-critical applications, i.e. a
potentially effective task may not be included in the program because it is not cost effective to do the
task. This means that maintenance requirements can be changed with no impact on the approved
configuration and cannot, therefore, be considered to be part of the configuration.
The exception occurs where an inspection or replacement at specified intervals is a condition of use
for the infrastructure. This typically occurs for structural components where the design is based on
“safe life’ or “safety by inspection” rather than full redundancy. Failure to complete the inspection or
to make the replacement will automatically lead to withdrawal of the asset from service.
Certification that maintenance requirements have been reviewed is required as part of the design
verification process defined in Appendix J and is a pre-requisite for design approval in accordance
with Appendix I .

P-2 Maintenance Requirements Analysis Process
Contemporary maintenance requirements analysis methods are based on a methodology known as
Reliability Centered Maintenance (RCM). RCM involves the application of the principles of reliability
theory within a structured process designed to identify effective maintenance and inspection tasks
that will detect or delay failures of the equipment. Detailed explanation of Reliability, maintainability
and Availability are contained in Appendix H
Key elements of the RCM analysis process are shown in Figure 17 below.
During the initial design of new equipment, the focus is at the individual component level, to identify
ways in which the unreliability of a component can affect outputs of the major item and the effects
on other components. FMECA performed for existing equipment or to assess changes in asset
configuration tends to focus at a higher level, with the emphasis being on the types of failures that
may have an impact on system operation and which may be significant for establishing maintenance
tasks.
Identify the item to be

analysed
Establish function (What

does it do?)
Maximo
Fail mode & effects

(How does it fail?)
TMP & Service
schedule
Failure recognition (how

can you tell?)
Task requirements
Effect of failure/
criticality
(What happens if it
does?)
Maintenance task
list
Maintenance task
options
(What can be done?)
Effective task No effective task
Task frequency Design change

(how often?) required?
Figure 17: Key elements of RCM logic process
P-3 Identify the Item

Items to be analysed must be precisely identified in terms of Model Type/Part Number and
Manufacturer, TMC and location within the system, so that the physical and functional characteristics
of the item can be determined.

Maintenance requirements for different types of items serving the same general purpose e.g. point
machines, turnouts, can vary considerably between types and it is important to ensure that the
analysis reflects the actual configuration of the asset being considered. Similarly, the actual location
and conditions of use are a primary determinant for maintenance requirements. Identical items used
in different locations may require different tasks and/or maintenance at different intervals.
P-4 Establish the Function

The function of the item, in the specific application to be covered by the analysis, is a key input to
the process, because it provides the basis to assess the effects of a failure on the system and to
establish the criticality of a failure to system performance. The function(s) of the item must be defined
in terms of system outputs. This is necessary to establish the consequences (or criticality) of a
failure later in the analysis.
P-5 Establish Failure Modes and Effects

Assessment of failure modes is based on the effect by which a failure is observed in a system
component. This step in the FMECA process covers identification and assessment of the principal
ways in which failure of an item may be observed (the failure mode), the cause(s) of failure and the
rate at which failures are likely to occur.
This will normally involve identification and consideration of cause and effect relationships, with the
effect of failure assessed on the basis of the impact on system performance. The latter assessment
also provides the basis for determining the criticality of the failure. The diagram in Figure 18 shows
the basic relationships.
Lack of lubrication
Machine binds or
jams Bearing failure No output
Misalignment EFFECT OF
FAILURE MODE FAILURE
CAUSE OF FAILURE
Figure 18: Failure modes and effects
P-6 Failure Recognition

The question “how can you tell” relates to ways in which the existence of a full or partial failure can
be recognized. For most functional failures the signs of failure will be self evident i.e. the operator
will observe that the system or item does not operate correctly, or this will show up as a fault on a
SCADA or other monitoring system. However, in other cases there may be no immediately
recognizable signs of failure, e.g. where the item is part of an emergency or backup system or where
the failure takes place progressively over some period, such as cracks in rail or structure.
The means by which failures can be recognised is important because it provides one indication of
the need for a maintenance task.
P-7 Effect of Failure/Criticality

The preliminary assessment of failure effects is covered in Section 3.16.5. This is essentially
concerned with the impact of the failure on system performance, and hence the criticality of the

failure to safety, system operation or related effects such as the potential damage to other system
components.
Assessment of criticality, in conjunction with the potential frequency of failures, provides the basis
for consideration of maintenance tasks or for the need to change the design of the item if there is no
effective maintenance task.
P-8 Maintenance Task Options

This element of the assessment involves consideration of the availability of maintenance tasks that
are potentially effective in detecting or delaying failures. For a task to be considered effective it must:
– Be capable of detecting the failure mode and/or likely cause of failure
– Be able to be performed at a frequency that will enable incipient or developing failures to be
detected before they reach critical proportions, or
– In some cases, such as operation of emergency systems, to verify that the function is performing
normally at a frequency that will provide a high level of assurance that the function will operate
on demand.
If a task cannot be judged to be effective using these general criteria then there is no purpose to be
served by it’s inclusion in a maintenance program. This then leads to a judgment of whether it is
acceptable (on either operational or economic grounds) to rely on corrective maintenance as the
only form of intervention, or whether a change to the design is needed (for critical failures). Appendix
M covers the submission of Configuration Change Requests where a change to the design is
assessed as necessary.
P-9 Task Frequency

The interval at which tasks are performed is an essential aspect of effectiveness. Tasks that are
otherwise capable of detecting or delaying failures will not be effective if they are performed at too
long an interval, while tasks that are done too frequently will waste resources and can accelerate
failures.
Establishing maintenance intervals generally involves a balance between an assessment of the
“ideal” frequency and the economic and management considerations of performing the task.
P-10 Assembling the Program

P-11 Documenting Maintenance Requirements
MRA is to be carried out using the MIMIR software tool and the results of analyses are to be recorded
within MIMIR. This provides a traceable record of decisions as well as a database of potential failure
modes and current information on failure rates used as part of the analysis.
Maintenance task requirements shall be documented and promulgated in Technical Maintenance
Plans and Service Schedules.
Maintenance requirements analysis records shall be regarded as part of the design record for the
infrastructure, but do not form part of the configuration documentation for that equipment.
P-12 Approval of Changes to Maintenance Requirements

Technical Maintenance Plans and Service Schedules represent the approved maintenance program
for CRN assets. All changes require formal approval by a person having delegated Engineering

Authority to do so and shall be treated as being equivalent to design decisions, within the terms set
out in Appendix I .
The Manager A&ES shall ensure that detailed instructions are developed and maintained for the
review and approval of new and changed maintenance requirements for all CRN infrastructure. This
includes arranging for the delegation of Engineering Authority to nominated A&ES staff to review
and approve maintenance requirements for new equipment or changes to existing programs.
Design Engineers are responsible for ensuring that maintenance requirements are reviewed for all
Configuration Changes in accordance with Section 0. Confirmation that this has been done is a
necessary part of the design verification process leading to design approval. The scope of the review
should be sufficient to ensure that the revised maintenance requirements do properly reflect the
changes made to the design.

CRN Man PDM 002 Design Management Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CRN Man PDM 002 Design Management Manual

Uploaded by

Copyright:

Available Formats

Country Regional Network

Design Management Manual

Design Management Manual |3

Design Management Manual |4

Design Management Manual |5

Design Management Manual |6

Design Management Manual |7

Australian & Management Australian &

Design standards, Infrastructure

Figure 1: Design management documentation structure

1.3 Review and Update of Procedures

1.4 Referenced Documents

Design Management Manual |9

2.3 Key Requirements

2.3.1 Design Process Model

Design Management Manual | 10

Functional Specification Hazard & Risk Analysis

Concept Options System Concept Review Stakeholder and

Hold Point Requirements

Design Validation (2.9.2)

Concept Options Appraisal Integrated Support

Develop Develop Preliminary design Design and

Critical Design Review

System Verification Review

Figure 2: JHR CRN Design process model.

Design Management Manual | 11

2.4 Client Requirements

2.5 Design Inputs

Design Management Manual | 12

2.5.2 Regulations, Legislation and Standards

2.5.3 Additional Inputs

2.5.4 Configuration Management Requirements

Design Management Manual | 13

2.6 Functional Specification Meeting / System Definition Review

2.7 Functional Specification Report

2.8 Concept Design development

Design Management Manual | 14

2.8.2 Hazard and Risk Analysis – (Safety in Design)

2.8.3 Integrated Support Provisions

Design Management Manual | 15

2.8.4 System Concept Review

2.8.5 Concept Options Identification and Appraisal

2.8.6 Design Brief

Design Management Manual | 16

2.9 Design Review and Approval

2.9.1 Design Verification

Design Management Manual | 17

2.9.2 Design Validation

2.9.3 Changes in Scope

Design Management Manual | 18

2.10 Design Stages

2.10.1 Concept Design

2.10.2 Concept Options Appraisal (COA)

2.10.3 Preliminary Design

2.10.4 Preliminary Design Review (PDR) / Concept Design Review

2.10.5 Detailed Design

Design Management Manual | 21

2.10.6 Critical Design Review (CDR) / Detailed Design Review

2.10.7 System Verification Review (SVR)

2.10.8 Design Approval and Acceptance

Design Management Manual | 22

2.10.9 Temporary works Design

2.11 Other Design Outputs