AEO Guide to Engineering Management

(1)

AEO Guide to Engineering

Management

Management standard

Version 1.0

Issued Date: 4 June 2013

Effective Date: 6 June 2013

Important Warning

This document is one of a set of standards developed solely and specifically for use on the rail network owned or managed by the NSW Government and its agencies. It is not suitable for any other purpose. You must not use or adapt it or rely upon it in any way unless you are authorised in writing to do so by a relevant NSW Government agency.

If this document forms part of a contract with, or is a condition of approval by, a NSW Government agency, use of the document is subject to the terms of the contract or approval.

This document may not be current. Current standards are available for download from the Asset Standards Authority website at

(2)

Standard Approval

Owner: Principal Manager (Systems Engineering) Authorised by: Establishment Project Committee

Approved by: Jim Modrouvanos A/Director Asset Standards Authority

Document Control

Version Summary of Change

1.0 First issue

For queries regarding this standard

Asset Standards Authority

[email protected] www.asa.transport.nsw.gov.au

(3)

Preface

The Asset Standards Authority (ASA) sets, maintains and administers the framework for assessment, authorisation, surveillance, review and audit of organisations which provide engineering services in relation to the asset life cycle of NSW rail assets.

The ASA promotes and contributes to the development of industry capability by developing and publishing guidance material in relation to organisation-level competency frameworks, promoting sustainable development of technical and engineering capability.

This guidance document has been developed by the Asset Standards Authority team to inform prospective and acting Authorised Engineering Organisations (AEO) on the implementations of Engineering Management desired by Transport for NSW, in their engineering service provisions under the prescribed AEO authorisation requirements set.

The content of this guidance document has been developed with due reference to legacy engineering management manuals and legacy systems engineering manuals published within Transport for NSW and NSW Rail Corporation, and includes informative reference to relevant ISO/IEC standards, Australian standards and NSW acts of law.

This guidance document is a first issue, and it is issued by the ASA without cancellation or replacement of any other Transport for NSW document.

This guidance document supports the ASA published guide on AEO Authorisation Governance

Framework on engineering management and systems engineering topics, and provides a point

of reference to separate sub-guides on a suite of developed topics under the engineering management and systems engineering banner.

(4)

1. Introduction

The Asset Standards Authority (ASA) provides the engineering management principles and methods that Authorised Engineering Organisations (AEOs) should implement for the management of Transport for New South Wales (TfNSW) engineering activities over the total asset life cycle.

2. Purpose

The AEO Guide to Engineering Management establishes recommended engineering management principles and methodologies for AEOs engaged in the provision of engineering services to TfNSW. This guide identifies the applicable TfNSW standards that AEOs require to manage engineering activities under their own assurance systems.

The AEO Guide to Engineering Management provides guidance to an AEO for the development of its engineering management submission to TfNSW.

2.1 Scope

The AEO Guide to Engineering Management describes the ASA's approach to engineering management and includes a high level description of the following:

 the NSW Government's total asset management (TAM) directives

 the guiding engineering management principles adopted by the ASA

 the main engineering management methodologies that the ASA recommends that engineering organisations adopt when applying for AEO status

This guide is not mandatory, but provides general guidance for prospective AEOs, and is tailored to address high-level engineering management requirements.

Mandatory AEO minimum requirements are defined in the TfNSW standard AEO Authorisation

Requirements.

2.2 Application

The AEO Guide to Engineering Management is primarily intended for AEOs that are responsible to TfNSW for carrying out engineering activities. This guide is also to be used by TfNSW project managers, their contractors and consultants, who are responsible for managing the overall enterprise delivery of TfNSW engineering activities.

(7)

3. Reference documents

3.1 International standards

EN 50121-1:2006 Railway applications - Electromagnetic Compatibility - Part 1: General

EN 50126:1999 Railway Applications - The Specification And Demonstration Of Reliability, Availability, Maintainability And Safety (RAMS)

IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems

ISO 9000:2005 Quality management systems - Fundamentals and vocabulary

ISO 9001:2008 Quality management systems - Requirements

ISO 10007:2003 Quality management systems - Guidelines for configuration management

ISO 14001:2004 Environmental management systems - Requirements with guidance for use

ISO/IEC 15288:2008 Systems and software engineering - System life cycle processes

ISO 17020:2012 Conformity assessment - Requirements for the operation of various types of bodies performing inspection

ISO TR 19760:2003 Systems engineering - A guide for the application of ISO/IEC 15288 (System life cycle processes)

ISO 26702:2007 Systems engineering - Application and management of the systems engineering process (formerly IEEE 1220:2005)

ISO 31000:2009 Risk management - Principles and guidelines

ISO 42010 Systems and software engineering - Architecture description

PAS 55-1:2008 Asset management. Specification for the optimized management of physical assets (soon to be superseded by ISO 55000)

PAS 55-2:2008 Asset management. Guidelines for the application of PAS 55-1

3.2 Australian standards, acts and regulations

AS/NZS ISO 14001:2004 Environmental management systems - Requirements with guidance for use

NSW Work Health and Safety Act 2011 No.10

NSW Work Health and Safety Regulation

Rail Safety National Law 2012 NSW (formerly NSW Rail Safety Act 2008 No.97)

AS 7508 Railway rolling stock - Track forces and stresses

(8)

3.3 TfNSW and ASA standards and documents

1TP-ST-052 Environmental Management System Manual

4TP-ST-095 Engineering Management Manual

7TP-ST-114 Sustainable Design Guidelines

10-ST-016 Safety Management System Requirements Standard

30-ST-164 Transport Enterprise Risk Management (TERM) Standard

40-ST-003 Safety Standard Safety Assurance Standard

TSR Q1 Quality Management (TfNSW Standard Requirements)

AEO Guide to Authorisation

AEO Authorisation Governance Framework

AEO Guide to Engineering Competence Management

TfNSW Railway Asset Configuration Management Plan

Configuration Management Guide

AEO Authorisation Requirements

AEO System Safety Standard

Guide to Requirements Definition and Analysis

3.4 Other references

HB 158:2010 Handbook. Delivering assurance based on ISO 31000:2009 Risk management - Principles and guidelines

HB 327:2010 Handbook. Communicating and consulting about risk

INCOSE TP-2003-002-03.2.2 Systems Engineering Handbook. A guide for system life cycle processes and activities

ONRSR Meaning of Duty to Ensure Safety - So Far As Is Reasonably Practicable (SFAIRP) Guideline

SEBoK v1.0 Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0

tpp08-2 Total Asset Management (TAM) requirements for updating the NSW State Infrastructure Strategy (SIS)

(9)

4. Terms and definitions

The following abbreviations and definitions apply in this document:

AEO Authorised Engineering Organisation AFC approved for construction

ALARP As Low As Reasonably Practical

approved for construction documents approved for construction documentation such as

design drawings, reports, and other design documents released for the constructor to commence construction of works shown on the AFC documents

AS Australian Standard

ASA Asset Standards Authority

As Low As Reasonably Practicable for a risk to be ALARP it must be possible to demonstrate

that the cost involved in reducing the risk further would be grossly disproportionate to the benefit gained

assurance a positive declaration intended to give confidence. In engineering references, it is

the evidence that planned outcomes have been achieved, or the evidence of effective management of risk

authorisation the conferring of authority, by means of an official instruction and supported by

assessment and audit

Authorised Engineering Organisation a supplier of a defined engineering service or product

that has been assessed and granted AEO status by TfNSW

availability the measure of the percentage of time that an item or system is available to perform

its designated function

BRD business requirement document BRS business requirements specification

commissioning the systematic process of ensuring that all equipment and systems perform

interactively according to the design intent and the operational and user requirements

competencies the skills (technical and non-technical) and underpinning knowledge that enable

someone to demonstrate a certain level of competence

competent person a person identified or certified within an organisation to have sufficient skills

and knowledge to perform specified tasks

compliance the state or fact of according with, or meeting, rules or standards

design (noun) the product of the process of designing that describes the solution (conceptual,

(10)

design (verb) the process of defining, synthesising, selecting, and describing solutions to

requirements in terms of products and processes

design synthesis (verb) the systematic translation of systems and subsystem functional

requirements into a technical physical solution

EMC electromagnetic compatibility EMP engineering management plan EN European norm

engineering activities an inclusive term meaning both services for project engineering of

systems solutions, and services for asset and system support engineering collectively, as sufficient to cover all engineering parts of the total asset life cycle

FMECA failure modes, effects and criticality analysis

framework a basic structure underlying a system, concept, or text GSN goal structured notation

handover the point in time (or staged points in time) when operational responsibility for an

asset or system transfers from an AEO to the Client owner or operator

HB handbook

IEC International Electro-technical Commission IEEE Institute of Electrical and Electronic Engineers INCOSE International Council On Systems Engineering

interface a common boundary or point of connection between two or more items, persons or

systems. It may include mechanical connections, electrical or electronic connections, software to software or hardware interfaces, personnel interfaces, data transfer requirements, procedural requirements or input conditions, and constraints that exist between one system and another or between items within the same system.

ISO International Organization for Standardization ITSR Independent Transport Safety Regulator MCD maintenance concept document

maintainability the probability that an item will be restored to operating condition, within a given

period of time, using prescribed procedures and resources

NZS New Zealand Standard

OCD operational concept document

(11)

principal AEO the Authorised Engineering Organisation (AEO) that is responsible to TfNSW as

the prime contractor of engineering services, and as the systems integrator for the entire scope of work. Principal AEOs are responsible for compliance to Australian regulatory standards and to TfNSW ASA standards for the entire scope of work.

rail infrastructure the facilities that are necessary to enable a railway to operate. This includes,

railway tracks and associated structures; service roads, signalling systems, communication systems, rolling stock control systems, and data management systems; notices and signs; electrical power supply and electric traction systems; associated buildings, workshops, depots, and yards; plant, machinery, and equipment; but does not include rolling stock and any facility, or any facility of a class that is prescribed by the national regulations not to be rail infrastructure.

RAM reliability, availability and maintainability

RAMS reliability, availability, maintainability and safety

reliability the probability that a specified item will perform a specified function, within a defined

environment, for a specified length of time

responsibility a duty or obligation to satisfactorily perform or complete a task (assigned by

someone, or created by one's own promise or circumstances) that one must fulfil, and which has a consequent penalty for failure

RISSB Railway Industry Safety and Standards Board

specification a document that fully describes a design element or its interfaces in terms of

requirements (functional, performance, constraints, and design characteristics) and the qualification (validation) conditions and procedures for each requirement

SRS system requirement specification

stakeholders the persons or groups that have claims on ownership, rights, or interest in a

project or its activities in the past, present or future

supplier a supplier of engineering services or products. Defined as an 'applicant' until such time

as it has been granted AEO status, after which it is referred to as an AEO.

SysML System Modelling Language TAM total asset management

TfNSW Transport for New South Wales UML Unified Modelling Language URD user requirements document

validation the process to confirm that the final product delivers defined operations and user

(12)

verification the process to ensure that the outputs of any stage (or stages) in the project life

cycle, meets the intent of the preceding stage and/or design inputs requirements (e.g. standards and regulations). Independent verification may be by another part of the designer organisation, not involved in the design, or by a separate designer organisation.

(13)

5. NSW Government total asset management

Transport for NSW is obliged to satisfy the total asset management (TAM) directives of the New South Wales Government. TfNSW achieves this through the agencies of the TfNSW Planning and Programs Division, the TfNSW Transport Projects Division and the TfNSW Transport Services Division.

The objective of asset management is to ensure that, from system concept to system disposal, the total collection of management activities associated with the acquisition, operation and maintenance of assets will ensure that the asset integrity is maintained at a level that satisfies the original business requirements over the full asset life cycle.

5.1 AEO total asset management guidance

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirement for asset management:

"An Authorised Engineering Organisation shall have management arrangements in place that align with the requirements of PAS 55-1:2008 Asset Management, as applicable to the scope of engineering services provided"

AEOs are required to observe objectives of Total Asset Management policies and strategies that are established by TfNSW.

Specifically, an AEO that is providing engineering services to TfNSW during the early phases of the system life cycle model should take care to identify and observe TfNSW directives on Total Asset Management.

TfNSW is currently formalising release of Total Asset Management policy and strategy directives for the transport sector, in line with the NSW Treasury policy and guidelines document

tpp08-2 Total Asset Management (TAM) requirements for updating the NSW State Infrastructure Strategy (SIS). The TfNSW interpretation of tpp08-2 will be formally issued for

AEO reference in future.

Business requirements, network capability requirements that emerge from the Total Asset Management policies, and strategies, are developed in the 'Exploratory' stage of the life cycle model and then developed to maturity in the 'Concept' stage.

TfNSW Total Asset Management policies and strategies for the development, delivery and utilisation of assets and systems will include the following subjects:

 total life cycle cost (total cost of development and ownership) models

 through-life capability delivery models

 through-life system performance models

(14)

 operations and maintenance cost models

The AEO is expected to have management arrangements in place that align with the requirements of PAS 55-1:2008 Asset Management Part 1: Specification for the optimized

management of physical assets, as applicable to the scope of engineering services provided.

Guidance on the appropriate application of PAS 55-1:2008 Asset Management Part 1:

Specification for the optimized management of physical assets is provided in PAS 55-2:2008 Asset management. Guidelines for the application of PAS 55-1.

6. Engineering management principles

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirements for engineering management principles:

"An Authorised Engineering Organisation shall have arrangements for executing engineering services in a competent and systematic way"

"An Authorised Engineering Organisation shall have engineering management methodologies appropriate to its engineering services"

The objective of engineering management principles is to have systematic arrangements for managing resources, processes, systems, data, and facilities to undertake engineering activities. A robust system is required to assure that engineering designs are correct, integrated, constructible, compliant with relevant standards, and meet TfNSW requirements.

The general principles and approaches to engineering management that apply to AEOs include the following:

 total asset life cycle

 systems engineering  safety management  excellence in design  sustainability in design  engineering specifications  engineering standards  configuration management  risk management  quality management  competency management

(15)

6.1 AEO engineering management guidance

TfNSW expects AEOs to address all of the general principles of engineering management in the provision of engineering products and services. The extent to which an AEO is required to address these principles is determined by the levels of responsibility and the complexity of the work that an AEO is to perform, or the authorisation level that an AEO seeks.

The level of AEO engineering management 'responsibility' is determined in accordance with the role an AEO performs in providing engineering products and services to TfNSW, under the provisions of lawful acts, regulations and standards.

The level of AEO engineering management 'complexity' is determined by the role an AEO performs in providing engineering products and services to TfNSW, over the system life cycle. Engineering management 'complexity' for an AEO in its role is factored by the diversity of engineering disciplines requiring systems integration.

The level of rigour in applying engineering management practices should be commensurate with the risk of the activity. That is, the design of a safety critical component requires more rigour than the design of non-critical components.

Engineering management arrangements should typically be documented in an engineering management plan (EMP) or manual.

The EMP is typically supported by sub-plans or manuals, depending on the scope of AEO engineering services over the asset life cycle.

Typical life cycle 'phase-specific' sub-plans (depending on the AEO scope) are:

 the design management sub-plan, including design assurance

 the construction management sub-plan, including construction assurance

 the manufacturing management sub-plan, including manufacturing assurance

 the integration, test and commissioning sub-plan, including assurance

 the maintenance management sub-plan, including maintenance assurance

 the decommissioning management sub-plan, including maintenance assurance Typical whole of life cycle sub-plans (relevant to all AEOs) are:

 the systems engineering (SE) sub-plan, including specific SE activities

 the competence management sub-plan

 the configuration management sub-plan

 the engineering document management sub-plan

 the safety management sub-plan

(16)

 the quality management sub-plan

 the risk management sub-plan

Depending on the scope and complexity of the engineering services, an AEO may incorporate some or all sub-plans within a single engineering management plan (EMP). For example, a specialist supplier of geotechnical and potholing services will have a relatively simple EMP compared to a supplier of multi-discipline, multi-phase services covering systems integration.

7. Total asset life cycle

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirements for the total asset life cycle:

"An Authorised Engineering Organisation shall ensure that its engineering services map to relevant phases of the TfNSW asset life cycle model"

"An Authorised Engineering Organisation shall establish and maintain an engineering assurance process that aligns to the range of engineering services and activities which the organisation intends to provide"

The total life cycle of an asset or system starts with the identification of a need to be satisfied, and progresses through a number of phases into operations and maintenance, and subsequently to decommissioning and disposal.

The total life cycle of an asset or system comprises the following phases:

 the identification of the stakeholder and user needs

 the capability requirements and options

 feasibility studies

 the system requirements and concept

 the preliminary design

 the critical design

 fabrication and manufacture

 construction and installation

 inspection and test

 commissioning and handover

 operations and maintenance

(17)

The design life span of TfNSW railway assets and systems typically ranges between 25 and 100 years.

The development of a project, through to the point of handover into service operations, usually occurs in the first one to five years of the life cycle. However, the strategic outcome to TfNSW is the achievement of asset performance and service parameters, including safety, reliability, and availability, at a minimum cost of ownership over the total asset life cycle.

During the initial life cycle phases, up to asset handover, the engineering processes and the developed product outputs have a significant impact on the later asset utilisation stage (operations and maintenance).

The cost of asset ownership is almost completely determined during the early stages of a project managed by TfNSW and executed by the contracted AEO. The ability to influence the cost of asset ownership reduces rapidly in the later asset life cycle stages. Therefore, TfNSW and the AEO should place due emphasis on the 'total asset life cycle' requirements early in the engineering design phases, in order to develop products consistent with the NSW Government Owner and the Service Operator's TAM policy directives on minimising the whole of life costs.

7.1 AEO total asset life cycle guidelines

Owner and service operator clients require TfNSW and AEOs to deliver an asset management manual for new or altered assets. The asset management manual includes all of the information needed to manage an asset through its operating life.

AEO designs should consider the client owner's or operator's approach to asset management, so that any new works can be easily integrated into existing management systems.

AEO designers should also consider the eventual decommissioning and disposal of assets at the end of their service lives. These include assets created during the project as well as existing assets. Existing assets may include heritage items, which may need to be protected, demolished or modified as part of the project.

Issues that may need to be addressed in the asset management manual include future access requirements and special equipment. This is in addition to the safe handling and disposal of hazardous or contaminated materials.

7.2 Life cycle model

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirement for the life cycle model:

"Authorised Engineering Organisations shall have a system, framework and process for assuring its engineering services and products"

The TfNSW asset life cycle model is derived from ISO/IEC 15288:2008 Systems and software

(18)

TfNSW provides a consistent reference framework for the total asset life cycle of assets created directly or indirectly as a result of TfNSW engineering programs. TfNSW defines the total asset life cycle framework in the complimentary views of 'enterprise life cycle' and 'system life cycle'. These two sequences run concurrently in the model.

The combination of enterprise life cycle stages and the system life cycle stages with its subset of system life cycle phases is the basis of the TfNSW life cycle framework.

The 'enterprise life cycle' stages are concerned with business and project outcomes. They are defined as 'business development', 'project definition', 'project execution', and 'asset and service life'.

The 'system life cycle' stages are concerned with engineering and operational outcomes. They are defined as 'exploratory', 'concept', 'development', 'production', 'utilisation', and 'retirement'. These system life cycle stage definitions conform to the requirements of ISO/IEC 15288:2008

Systems and software engineering - System life cycle processes.

The TfNSW life cycle stages are shown in Figure 1.

Figure 1 - TfNSW life cycle stages

The TfNSW system life cycle has been further broken down into phases to support the establishment of appropriate definitions of TfNSW's system life cycle engineering processes.

Figure 2 - System life cycle breakdown

TfNSW system life cycle and engineering management definitions are based on the systems engineering 'V' model and the ISO/IEC 15288:2008 Systems and software engineering - System

life cycle processes.

(19)

(20)

The system life cycle model has been adapted from ISO standards by TfNSW and includes the total asset life cycle responsibilities of TfNSW programs. The 'inception-to-disposal' span of the total asset life cycle for TfNSW is identified against both enterprise and systems relevance.

The TfNSW model conforms to the wider enterprise model and the total life cycle model of

ISO/IEC 15288-2008 Systems and software engineering - System life cycle processes.

The systems engineering life cycle 'V' model is identified with the lead-in process activities of business planning, needs definition, and options analysis. Similarly, the systems engineering 'V' model is identified with the lead-out process activities in the operational life, through-life maintenance, decommissioning, and disposal.

The Engineering Management Process shown in Figure 4 is a simplified model of the engineering design management process for TfNSW that outlines the design stages over the complete system life cycle model. Figure 4 provides a high-level representation of the tasks that need to have been completed before moving to the next stage in the system life cycle.

(21)

STAKEHOLDER & USER REQUIREMENTS Legislations and Regulations DESIGN & PLANNING DEVELOPMENT STAGE (New or Altered Designs) FEASIBILITY & CONCEPT DESIGN INPUT Extant Interfaces Stakeholder / User Standards

DESIGN OUTPUT & APPROVAL

FABRICATION, CONSTRUCTION &

INSTALLATION

INSPECT, TEST & COMMISSION

HANDOVER

USE & MAINTAIN

Prop osed Ch ange s to Asset Config uratio n Buil d Chan ges VE RIFICA TION VA L IDA T ION DECOMMISSION & DISPOSAL “For Construction” Baseline Verification of Design Stage Output Design & Configuration Documents “As Built” Baseline Verification of Construction Validation of Integrated System D esig n Cha nges B a s e line CM Data Baseline CM Data SYSTEM REQUIREMENTS

exploratory baseline gateway

concept baseline gateway

build baseline gateway post-build baseline gateway preliminary baseline gateway

validation baseline gateway

operating baseline gateway

retirement baseline gateway

TRACEABILITY TRACEABILITY VER IF IC ATIO N Solution Constraints

CMC (or delegate) Control Gate

CMC Control Gate

CMC Control Gate Configuration Management Committee (CMC) Control Gate

Delegated (configuration) Governance Control Gate Delegated (configuration) Governance Control Gate Delegated (configuration) Governance Control Gate

CONFIGURATION MANAGEMENT

RECORDS

TRACEABILITY

Figure 4 - Engineering management process: simplified model

Related topics

Engineering management methods, section 19

7.3 AEO life cycle model guidelines

TfNSW expects AEOs to manage their delivery of engineering products and services in accordance with the system life cycle stages or phases and the defined baseline gateways identified in the TfNSW life cycle model.

(22)

The extent of an AEO's scope of contracted work across the stages or phases of the life cycle model is always to be defined by TfNSW prior to the work starting.

AEOs are to manage the progress of their engineering and systems work through adherence to the schedule of life cycle baseline gateways, established for the span of the system's life cycle.

7.4 Life cycle baseline gateways

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirement for life cycle gateways:

"An Authorised Engineering Organisation shall demonstrate engineering assurance based on progressive stage gateway reviews"

"Authorised Engineering Organisations shall apply a risk based approach to engineering assurance"

The TfNSW system life cycle model includes baseline stage gateways that are used to manage formal reviews of life cycle progress and to determine the acceptability of key activity output artefacts.

The baseline stage gateways are shown in Figure 3.

The baseline stage gateways are:

 exploratory baseline gateway

 concept baseline gateway

 preliminary baseline gateway

 build baseline gateway

 post-build baseline gateway

 validation baseline gateway

 operating baseline gateway

 retirement baseline gateway

Each gateway review identifies a key progress milestone and a 'go/no-go' decision point for the system life cycle.

Each gateway has a defined set of engineering and configuration artefacts required for presentation, review, and approval, prior to an authorisation to proceed being issued.

Related topics

(23)

7.4.1 Exploratory baseline gateway

The exploratory baseline gateway occurs at the end of the 'exploratory' stage in the system life cycle model. This aligns with the end of the 'capability requirements & options' phase.

The exploratory baseline gateway assures the following criteria:

 all activities in the 'stakeholder & user needs' and 'capability requirement & options' phases have been completed and all artefact demands have been delivered

 the proposed plans and options meet the strategic business objectives, capability needs, operational needs, and maintenance needs

 stakeholder objectives for system capabilities, system operations, system maintenance, system performance metrics, service life parameters, and system environment constraints have been identified and contained in a configured business requirements specification (BRS)

 a business requirements document (BRD) for the system's enterprise goals has been produced, to inform and support the parent BRS

 an operational concept document (OCD) for the system in service has been produced, to inform and support the parent BRS

 a maintenance concept document (MCD) for the system in service has been produced, to inform and support the parent BRS

 a clear record of accepted completeness, representative approval, and commitment to artefacts has been received from all of the system stakeholders

Related topics

Stakeholder and user needs activities, section 19.1

Requirements management, section 8.1

(24)

7.4.2 Concept baseline gateway

The concept baseline gateway occurs at the end of the 'concept' stage in the system life cycle model. This aligns with the end of the 'system requirements & concept' phase.

The concept baseline gateway assures the following criteria:

 all activities in the 'feasibility studies' and 'systems requirements & concept' phases have been completed, and are acceptable, and all artefact demands have been delivered

 a proposed reference design option has been produced that:

 meets strategic business objectives

 is technically and financially feasible to be built

 can be economically maintained for the duration of its intended operational design life

 a testing and acceptance planning document for the system and the identification of options has been completed

 safety change activities for system definition have been completed

 a configured system requirement specification (SRS) baseline has been established to represent the scope of the system requirements, and to ensure that these requirements are traceable back to the user requirements document (URD)

 the preferred option has been identified and the feasibility assessment of that option has been completed

 a basic acquisition plan for the preferred option has been planned, and the complexity appraisals of the acquisition scope of all aspects have been completed

Related topics

Feasibility studies activities, section 19.3

Requirements management, section 8.1

System requirements specification Section 13.1

7.4.3 Preliminary baseline gateway

The preliminary baseline gateway occurs part-way through the 'development' stage in the system life cycle model. This aligns with the end of the 'preliminary design' phase.

'Development' in the TfNSW context commences after the release of a 'reference design', facilitated through a successful design and construct tender process.

The preliminary baseline gateway assures the following criteria:

 all activities in the 'preliminary design' phase have been completed, and are acceptable, and all artefact demands have been delivered

(25)

 a proposed design solution has been completed. The design meets the system requirements of the system requirement specification and meets any derived subsystem specifications or other technical requirements, suitable to the 'preliminary design' baseline presentation.

 the safety change activities for the system and the preliminary design processes have been satisfactorily completed

(26)

Concept baseline gateway, section 7.4.2

Engineering specifications, section 13

Preliminary design activities, section 19.5

7.4.4 Build baseline gateway

The build baseline gateway occurs at the end of 'development' stage in the system life cycle model prior to the start of the 'production' stage. This aligns with the end of the 'critical design' phase.

The 'production' stage in the TfNSW context begins after the release of approved for construction (AFC) designs.

The build baseline gateway assures the following:

 all activities in the 'preliminary design' and 'critical design' phases have been completed and are acceptable, and all artefact demands have been delivered

 a proposed design solution has been completed and meets the system requirements of the system requirement specification. It includes any derived specifications or other technical requirements required to support the 'for construction' baseline presentation.

 the safety change activities for system, preliminary and critical (detail) design processes have been satisfactorily completed

 a design safety assurance report (SAR) has been accepted by the risk acceptance authorities on the presented 'for construction' design baseline

 a test and acceptance plan has been completed for the approved for construction (AFC) design

Related topics

Preliminary baseline gateway, section 7.4.3

Engineering specifications, section 13

Engineering standards, section 14

Critical design activities, section 19.6

Product specifications, section 13.3

7.4.5 Post-build baseline gateway

The post-build baseline gateway occurs midway through the 'production' stage in the system life cycle model, prior to the start of site integration and testing. This aligns with the end of the 'construction / installation' phase.

(27)

 all activities in the 'fabrication / manufacture' and the 'construction / installation' phases have been completed, and are acceptable, and all artefact demands have been delivered

 that the end product of the 'fabrication / manufacture' and 'construction / installation phases, at both the factory and on site, conforms to the configured 'for construction' baseline

 safety change activities applicable to the commencement of testing have been satisfactorily completed

Related topics

Build baseline gateway, section 7.4.4

Post-build baseline gateway, section 7.4.5

Inspection and test specifications, section 13.4

Engineering standards, section 14

Configuration management, section 15

(28)

Construction and installation activities, section 19.8

7.4.6 Validation

baseline

gateway

The validation baseline gateway occurs at the end of integration and test activities in the 'production' stage in the system life cycle model. This aligns with the end of the 'inspection & test' phase.

The validation baseline gateway assures the following:

 all verification activities have been completed and are acceptable

 all artefact demands have been delivered up to system integration tests within the 'inspection & test' phase

 the integrated and tested solution is verified and ready for full integration into the NSW transport network

 all of the safety change activities that relate to the system build and validation have been completed. This includes the signoff of an implementation SAR or a safety assurance statement (SAS) by the risk acceptance authorities

Related topics

Post-build baseline gateway, section 7.4.5

Configuration management, section 15

Inspection and test specifications, section 13.4

Inspection and test activities, section 19.9

7.4.7 Operating

baseline

gateway

The operating baseline gateway occurs at the end of implementation activities in the 'production' stage in the system life cycle model. This aligns with the end of the 'commissioning' phase.

The operating baseline gateway includes a formal review that occurs at the end of the defects liability period, prior to the handover for normal NSW transport network operations.

The operating baseline gateway assures the following:

 all activities in the 'commissioning' phase have been completed and all artefact demands have been delivered

 the compliance of all systems validation testing has been proven to the stakeholders' requirements, and a post implementation review has been satisfactorily completed

 the presentation of a physical configuration audit (PCA) baseline of the actual build configuration, which demonstrates that the build of the assets reflects the baseline asset data

(29)

Related topics

Validation baseline gateway, section 7.4.6

Verification and validation, section 8.7

Commissioning activities, section 19.10

7.4.8 Retirement

baseline

gateway

The retirement baseline gateway occurs at the end of the 'utilisation' stage in the system life cycle model. This aligns with the end of the 'operations & maintenance' phase.

A formal review at the retirement baseline gateway is performed at the end of the operational life of the system assets, and prior to any decommissioning or disposal works.

The retirement baseline gateway assures the following:

 the completion of a strategic 'condition' analysis relating to those elements of the system infrastructure which are approaching their 'end to system service life'. The resulting 'condition' analysis determines the fate of those distinguishable system elements.

 the identification of the system elements due for disposal

 the identification of the system elements due for strategic re-use

 the completion of a decommissioning and disposal plan

Related topics

Operating baseline gateway, section 7.4.7

Testing and commissioning, section 8.8

Operations and maintenance activities, section 19.11

7.5 Life cycle baseline gateway guidelines

AEOs manage the progress of their engineering and systems work through adherence to the schedule of life cycle baseline gateways. These are determined for the span of the system's life cycle, and undertaken in scopes of work for TfNSW.

The AEO's engineering management and assurance systems should conduct life cycle baseline gateway reviews with TfNSW participation. These AEO reviews should provide measurable, quantifiable evidence for the successful completion of AEO work packages at each completed stage or phase of the system's life cycle.

TfNSW reserves a right of veto on the progress of any AEO work packages, through to acceptance, at three of the eight baseline gateways that have been defined. The three baseline gateway points at which the TfNSW veto can be exercised are:

 the build baseline gateway (the 'AFC' baseline)

(30)

 the retirement baseline gateway

An AEO shall allow TfNSW visibility of the baselines that they present at their gateway reviews in advance of those reviews being undertaken. This provides TfNSW with the opportunity to attend the AEO review meeting and provide feedback. The requirements for such notifications and baseline information are set out under TfNSW project scopes of work.

8. Systems engineering

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirement for systems engineering:

"Authorised Engineering Organisations shall have a Systems Engineering approach to the planning and delivery of its engineering services or products"

Systems engineering is an interdisciplinary field of engineering, focusing on the design and management of complex engineering projects over the system life cycle.

The ASA recommends that AEOs follow the International Council on Systems Engineering's (INCOSE) description of systems engineering:

"Systems engineering focuses on defining customer needs and the required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs." INCOSE Systems Engineering Handbook v3.2.2.

Further information on the disciplines and practices of systems engineering can be found in the standard ISO/IEC 15288:2008 - Systems and software engineering - System life cycle

processes.

Any company, party or organisation applying to become an AEO should ensure that its engineering management documentation meets the minimum standard required for the complexity of its projects or contracts.

An AEO should ensure that the technical processes covered in its documentation include the following:

 requirements management

 interface management

(31)

 systems architecture management

 systems assurance

 reliability availability and maintainability

 verification and validation

 testing and commissioning

 electromagnetic compatibility management

 human factors integration

 engineering competency

 configuration management

Configuration management also forms part of systems engineering and is covered in section 15 Configuration management.

8.1 Requirements management

The ASA management standard, AEO Authorisation Requirements, states the following overarching mandatory requirement for requirements management:

"An Authorised Engineering Organisation shall have requirements management arrangements that set out process, responsibilities, structure, tools and deliverables for management of stakeholder requirements applicable to the scope of engineering services provided across the system life cycle"

Requirements management is an active process throughout the duration of a project or product life cycle. Requirements management involves identifying, analysing, tracing, prioritising, agreeing, and documenting client requirements and then actively managing these requirements. Requirements management processes include controlling and managing changes, communicating any requirements to the relevant stakeholders, and demonstrating compliance.

The importance of effective requirements management is not to be underestimated. The lack of discipline for thorough requirements management is the single biggest cause of risk leading to failure on rail engineering projects. This is also true for engineering projects in other industry sectors.

8.1.1 AEO requirements management guidelines

Each organisation applying for AEO approval should align its coverage of requirements management with its engineering management documentation. It should be customised relative to the complexity of the work to be undertaken.

(32)

On large scale or complex projects, requirements management is essential from the earliest stages. Project requirements are elicited, captured, and agreed. If changes to requirements are required, each change should be managed in accordance with an agreed change management process, including a full impact assessment.

At the beginning of a project, a full set of business requirements that address the needs of all stakeholders is developed and agreed. It is essential that the stakeholder business requirements are implemented using the design disciplines responsible for each of the defined design packages.

Project requirements are traced to suppliers’ specifications and design documents, to demonstrate that all requirements have been incorporated into the design.

Evidence is recorded at each project stage as the requirements are managed through the project life cycle. This ensures that the correct systems are built and provides assurance for construction and hand-over. Evidence is provided through traceability and verification to ensure that the requirements are satisfied.

Verification and validation activities are planned, to clearly demonstrate that suppliers and the project have satisfied the requirements.

A structured requirements management process is required. It should describe the manner in which an AEO manages requirements at a project-wide level. This requirements management process can range from a section in a design management plan, for single-discipline projects or products, to standalone plans for complex multidisciplinary projects, depending on the complexity of the project.

Further requirements management guidance can be found in the TfNSW Guide to

Requirements Definition and Analysis.

8.2 Interface management

The ASA management standard, AEO Authorisation Requirements, states the following overarching mandatory requirement for interface management:

"An Authorised Engineering Organisation shall have interface management arrangements that set out the process, responsibilities, structure, tools and deliverables"

Interface management ensures that key internal and external interfaces are identified, defined, and incorporated as necessary. The objective of interface management is to define a set of processes, team structures, and documentation in a timely, prioritised, cooperative, systematic, and traceable manner.

Interface management covers interfaces between the following:

 operator

(33)

 users, both passengers and the public

 other systems

 other relevant stakeholders

Interface management is active across the following work phases:

 design

 installation

 configuration

 testing

 commissioning

8.2.1 AEO interface management guidelines

Each organisation applying for AEO approval should incorporate interface management into its engineering management plan. The interface management should be tailored relative to the level of complexity of the scope of works to be undertaken.

AEOs need to identify, document, analyse, and control interfaces between systems and subsystems that may be both internal and external to the project or product. This is in order to ensure that the final system will be capable of being integrated.

A clearly defined interface management process is required for all large scale and complex projects. It should encompass a mechanism for identifying, recording and tracking all internal and external system interfaces. Interface control specification documents are required for the interfaces between some systems, especially across supplier boundaries. Inter-disciplinary checks are required for all interfaces, to provide assurance that the interfacing systems are compatible.

Further guidance details can be found in the TfNSW AEO Guide to Interface Management.

8.3 Performance modelling and analysis

The objective of performance modelling and analysis is to validate high level business and system requirements, by means of models, prior to commencing with design and construction.

Performance models are used to undertake simulations of the system, as defined by the business and system requirement set. This provides a means of analysing the effectiveness of meeting stakeholder or user needs, prior to design commitment. It mitigates the potential risk of costly rework or additional compensatory measures, to achieve the required system performance.

8.3.1 AEO performance modelling guidelines

AEOs should demonstrate performance modelling methods that set out process, responsibilities, structure, and tools.

(34)

AEOs should undertake performance modelling on assets and configured systems of high complexity, when the performance cannot be predicted by demonstrating simple compliance with accepted standards, using existing type approved products.

Performance modelling is a specialist service and may be limited to AEOs providing specialist services in the concept and design stages.

8.4 System architecture management

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirement:

"A design Authorised Engineering Organisation shall demonstrate that it has arrangements to manage the synthesis and development of system level requirements into a credible system architecture"

Systems architecture management draws together functional and performance requirements into a framework that allows a system to be viewed from functional, logical, physical, operational, or geographical perspectives. The framework architecture is then used as the basis for design decision-making, option selection, and detailed system design development.

The architectural management process is iterative and requires the participation of systems engineers and relevant specialists in the system domain. When alternative solutions present themselves, technical analyses and decisions are made as part of this process to identify a set of system elements.

The architectural management process includes the following:

 defining the architecture and the required viewpoints

 analysing and evaluating the architecture

 documenting and maintaining the architecture

8.4.1 AEO architecture management guidelines

An AEO will need to demonstrate that they have processes in place to manage the synthesis and development of the system requirements into a credible system architecture.

For complex software programmable communications and control systems, it is now accepted best practice to use the Unified Modelling Language (UML) or the System Modelling Language (SysML) to define such systems, using a range of standard architectural viewpoints and models. Notably, the use of SysML is beginning to expand into traditional electrical, mechanical and civil engineering for systems design development, whereas UML is the accepted norm in the software engineering domain.

8.5 Systems assurance

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirement for systems assurance:

(35)

"An Authorised Engineering Organisation shall have systems assurance arrangements in place that are appropriate to the engineering services it provides within the system lifecycle"

Systems assurance is the planned and systematic set of activities that demonstrate how the systems and products shall conform to requirements for safety, reliability, availability, maintainability, standards, procedures, and regulations.

The purpose of systems assurance is to provide evidence that these requirements have been met and accepted at all stages of the asset life cycle.

8.5.1 AEO systems assurance guidelines

The systems assurance process should define the providers and receivers of assurance.

Systems assurance should explain the main elements of people, process, and product, and provide an outline of how these principles are implemented in practice.

The process should specify assurance reports or submissions that are to be produced at key stages of the project life cycle.

Systems assurance should provide progressive confidence that the technical deliverables are achieved at each stage of the total asset life cycle.

8.6 Reliability availability and maintainability

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirement for reliability, availability and maintainability:

"An Authorised Engineering Organisation shall demonstrate that it has reliability, availability and maintainability (RAM) management arrangements in place, relevant to the engineering services or products provided"

Reliability, availability, and maintainability (RAM) engineering is a 'whole of system' life cycle philosophy integrated with all design, development, production, installation, operation, and maintenance phases. The correct application of RAM engineering is required to ensure the optimum system effectiveness and availability.

8.6.1 AEO reliability availability and maintainability guidelines

RAM planning and deliverables should be suitable and sufficient to provide assurance to all parties that the RAM engineering activities will satisfy high level RAM targets.

The following tasks and deliverables should be addressed:

 define systems and boundaries for the project relating to RAM work

(36)

 allocate the RAM requirements that must be satisfied to achieve a satisfactory system. This includes the top-level apportioning of RAM requirements which lead to component level requirements, or vice-versa

 integrate existing sub-system and lower level RAM requirements that contribute to the achievement of system level requirements

 undertake RAM modelling and analysis activities, including failure modes, effects, and criticality analysis (FMECA). This is to identify any potential failures and to assess whether these will have an impact on the overall safety, reliability or availability of the system

 managing a failure records analysis and corrective action system (FRACAS)

8.7 Verification and validation

The ASA management standard, AEO Authorisation Requirements, states the following mandatory requirement for verification and validation:

"An Authorised Engineering Organisation shall have verification and validation arrangements in place, relevant to the engineering services or products provided"

Verification and validation processes are designed to ensure that process outputs are correct. The development of any system is not complete without rigorous verification that the implementation is consistent with the specifications.

The verification and validation processes and outputs will form part of the evidence supplied in product and project safety cases that lead to system acceptance and certifications.

The purpose of the verification process is to confirm that the specified design requirements have been fulfilled by the realised system. This verification process provides the information required to effect remedial actions that correct non-conformances in the realised system or the processes that act on it.

The purpose of the validation process is to provide objective evidence that the services provided by a system, when in use, comply with the stakeholders' requirements and achieve their intended use in their intended operational environment. The validation process performs a comparative assessment and confirms that the stakeholders' requirements are correctly defined. Where variances are identified, they are recorded and used to guide corrective actions. System validation is ratified by the stakeholders.

(37)

8.7.1 Verification

guidelines

System verification determines whether the system, its elements, and its interfaces satisfy their respective requirements. Verification ensures conformance to those requirements. Verification provides assurance that "you designed it correctly, and you built it correctly". Verification encompasses tasks, actions, and activities performed to evaluate the progress and effectiveness of the evolving systems solutions, and to measure compliance against requirements.

The primary objective of verification is to determine whether the systems specifications, designs, processes, and products are compliant with the requirements. The continuous feedback of verification data helps to reduce risk and forces problems to be identified at the earliest stages. The goal is to completely verify a system's capability to meet all of the requirements prior to the production build and operation stages.

The basic forms of verification activities include:

 design reviews

 inspection and test completion reviews

 inspection

 analysis

 demonstration

 test

 certification

8.7.2 AEO design review guidelines

TfNSW requires that an AEO declares and follows approved design review processes and procedures to provide specification-compliant design solutions. The designs should address all relevant in-scope requirements of the SRS.

The ultimate responsibility for the safety, technical accuracy and correctness of the design resides with the AEO that produced the design.

The outcome of any TfNSW involvement in an AEO design review activity only indicates agreement for the AEO to proceed with the design submission. It does not represent approval of the design by TfNSW.

AEOs are required to submit their design review processes and procedures for assessment by the ASA, as part of the authorisation process.

AEO design review processes and procedures are expected to align with the TfNSW systems life cycle model, the simplified model of TfNSW engineering design management process, and also the 'technical processes' requirements specified in ISO/IEC 15288-2008.

(38)

8.7.3 AEO inspection and test review guidelines

TfNSW will contract certain AEOs to build, integrate and test system designs.

TfNSW requires that AEOs declare and follow approved inspection and test completion review processes and procedures. This requirement is to satisfy TfNSW that the work an AEO performs under those inspection and test processes, addresses all relevant verification requirements of the SRS, and provides specification-compliant solutions.

Ultimate responsibility for the accuracy of technical aspects and integrity of the work performed resides with the AEO that constructs and integrates the design solution.

The outcome of any TfNSW involvement in an AEO inspection and test completion review activity only indicates agreement for the AEO to proceed with the submission. It does not represent TfNSW's approval of the technical aspects of any works.

AEOs are required to submit their integration and test completion review processes and procedures to the ASA for assessment and approval. AEO integration and test completion review processes and procedures are expected to align with the systems life cycle model, the simplified model of TfNSW engineering design management process, and also the 'Technical Processes' requirements specified in ISO/IEC 15288:2008 Systems and software engineering -

System life cycle processes.

8.7.4 Validation

Validation is the assurance that the final installed system meets the stakeholder requirements that were captured in the principal requirements and user requirements documents - "are we

building the correct thing?"

Validation determines whether a system does everything it should, and that it does not do what it should not, for all defined modes of system operations. End-users and other stakeholders are usually involved in validation activities. Validation occurs as part of the system testing processes.

The project design and construction can also be validated at earlier stages of the TfNSW asset life cycle. However, this requires the use of simulation, review and site checks to obtain stakeholder acceptance at the appropriate stage, and is only performed on risk and high-novelty projects.

The validation of each principal requirement is required to be mapped and to be traceable back to the user, principal, or system requirements.

Validation may take place in the operational environment under possession control, or, in a simulated operational environment if real-world conditions are too hazardous for validation observers.

Independent third parties may be called in to perform validation.

AEO Guide to Engineering Management