ENGINEERING STANDARDS DEVELOPMENT PROCEDURE

Size: px
Start display at page:

Download "ENGINEERING STANDARDS DEVELOPMENT PROCEDURE"

Transcription

1 Approval Amendment Record Approval Date Version Description 21/12/ Initial Release of MTM Engineering Standards Development Procedure PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 1 of 16

2 Table of Contents 1. Purpose Scope Acronyms and Definitions Acronyms... 3 Definitions References and Legislation Background Objectives for Engineering Standards Development Governance Document Hierarchy Process ES Initiation... 9 ES Draft and Development Phase Risk Assessment ES Internal Stakeholder Peer Review ES External Stakeholder Peer Review ES Final Collation & Approval Release and Publication Document Maintenance Appendices Appendix 1 Engineering Standard Development Process Appendix 2 Engineering Standard Development Recommendations List of Tables Table 1 Engineering Standards Governance... 7 List of Figures Figure 1- MTM Engineering Documentation Hierarchy... 8 Figure 2 - Engineering Standards Development Process Flow... 9 PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 2 of 16

3 1. Purpose The purpose of this procedure is to specify the governance, roles and responsibilities, and process required for the Metro Franchise to amend or develop new Engineering Standards (ES). 2. Scope The procedure applies to the development and update of all Engineering Standards to be incorporated into the Metro Trains Melbourne (MTM) Safety Management System. 3. Acronyms and Definitions The Glossary of Terms, Abbreviations and Acronyms contains terms that are specific to the development of the Engineering Standards by MTM. 3.1 Acronyms Acronym DPN ES ESC EWG FOR LXRA MMRA MoC MRN MTM PTV SME Description Design Practice Note Engineering Standards Engineering Standards Committee Engineering Working Group Final Operational Requirements Level Crossing Removal Authority Melbourne Metro Rail Authority Management of Change Melbourne Metropolitan Rail Network Metro Trains Melbourne Public Transport Victoria Subject Matter Expert PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 3 of 16

4 3.2 Definitions Term Accredited Rail Transport Operator Configuration Management Engineering Standards Engineering Specification Design Practice Note Engineering Standards Committee Engineering Working Group Melbourne Metro Rail Authority Level Crossing Removal Authority Management of Change Melbourne Metropolitan Rail Network Definition A rail operator that under the National Rail Safety Law (2012) must ensure the safe construction, operation and maintenance of all of the railway infrastructure and assets. A systems engineering process for establishing and maintaining the consistency of a product/service/network s performance, functional and physical attributes with its requirements, design and operational information throughout its lifecycle. Standards that define the technical, functional and performance related requirements to ensure assets and/or products delivered are safe, functional, maintainable, reliable and perform as intended. A document that is an explicit set of acceptance requirements to be satisfied by a product, service or process suitable for use in the MRN. Their purpose is to document the characteristics of the product/service that meet the requirements of one or more standards. Design Practice Notes within MTM is a form of technical note that is used to clarify a technical issue surrounding a standard, specification or design practice. DPNs generally have a defined life and should aim to be incorporated into ES updates. An engineering committee comprising key representatives of MTM engineering and internal business stakeholders as well as invited guests including MMRA, LXRA, PTV, VicTrack and VLine. Engineering Working Groups for the various disciplines comprising key representatives of MTM and impacted stakeholder (e.g. MMRA, LXRA, PTV, VicTrack and VLine) MMRA is the Victorian Government body responsible for delivery of the Metro Tunnel Project. MMRA is an administrative office established within the Department of Economic Development, Jobs, Transport and Resources. LXRA is the Victorian Government body responsible for delivery of the Level Crossing Removal Program. LXRA is an administrative office established within the Department of Economic Development, Jobs, Transport and Resources. Ensures that changes that may affect the safety of railway operations within MTM are identified and associated risks are managed So Far As Is Reasonably Practicable The rail network that MTM currently operate and maintain as defined under the franchise agreement. PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 4 of 16

5 Metro Trains Melbourne Public Transport Victoria Safety Management System A current Franchisee Operator of the MRN PTV as the network authority for the Melbourne public transport network, is accountable for the development of policy and defining acceptable practice for assuring the integrity of assets used on the MRN MTM s system that demonstrates the legislative and Franchise requirements for safely operating and maintaining the railway and the associated assets. 4. References and Legislation L0-SQE-MAN-002 MTM Safety Management System Manual L1-CHE-GDL-005 Chief Engineer Guideline Engineering Standards Listing L1-SQE-PRO-003 Legislative and Standards / Codes Compliance L2-CHE-TOR-002 Engineering Standards Committee Terms of Reference L1-SQE-PRO-001 Management of Change (MoC) Procedure L1-CHE-INF-006 Engineering Information Sheet Technical Document Types [Internally Controlled] Metro Master Engineering Standards Register PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 5 of 16

6 5. Background MTM is an Accredited Rail Transport Operator and under the National Rail Safety Law (2012) must ensure the safe construction, operation and maintenance of all railway assets under its accreditation. In addition, as a franchisee, MTM must comply with the terms and conditions of the Franchise Agreement under its contract with Public Transport Victoria (PTV). As part of MTM s Safety Management System, MTM are required to approve the application of and manage Engineering Standards for any new assets or changes to existing assets. 6. Objectives for Engineering Standards Development The objective of this procedure is to ensure that a rigorous and consultative process is implemented, from which new, and changes to existing Engineering Standards can be produced. The outcome sought through procedure is: That the standards are sufficiently detailed to allow MTM, contractors and suppliers to design and/or construct the assets to the standard expected and that the returned assets are safe, functional, maintainable, reliable and perform as expected. To assist management of design, construction, operation and maintenance of the Melbourne Metropolitan Rail Network (MRN) through formal engineering standards. To document the franchisee requirements for new or modified assets, products, services and systems within MRN. To regulate compliance with the Franchise Agreement as the MRN operator to meet the obligation of maintaining and operating the railway, by defining the acceptance criteria of new and modified assets. To provide a platform for governance and delivery of MTM engineering compliance with PTV customer and network requirements. Providing a listing of Engineering Standard to be complied with by all stakeholders working within the MRN. PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 6 of 16

7 7. Governance The MTM ES development process is governed by Engineering Standards Committee (ESC), with discipline Engineering Working Groups (EWG) reporting up to this committee. Any non-conformance to standards is governed by the Waiver Review Committee. Table 1 below provides a summary of each of these committees or groups. Table 1 Engineering Standards Governance Role Description Responsibilities Engineering Standards Committee (ESC) Refer to MTM document No. L2-CHE-TOR-002 Terms of Reference for details of the MTM ESC. Waiver Review Committee Engineering Working Groups (EWG) An Engineering Committee comprising key representatives of MTM Engineering and key stakeholders. An engineering committee comprising key representatives from MTM Engineering. Engineering Working Groups for the various disciplines comprising key representatives of MTM, project authorities and PTV. Provides oversight, coordination, governance and strategic direction for ES development Approves the development of a new ES & amendments to an existing ES Endorsing and approving noncompliances to MTM developed or adopted standards Reporting to the ESC any patterns in non-compliance that should be considered for update to ES Provides subject matter expertise input for ES review & development PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 7 of 16

8 8. Document Hierarchy The hierarchy of engineering documentation managed by Metro Trains Melbourne is illustrated in Error! Reference source not found.. Rail Safety National Law / Legislation / PTV Network Requirements Requirements under law or contractual obligations Satisfies Policy Enterprise wide policy/objective Aligned to Satisfies Strategy Division/Group strategic direction Delivers Aligned to Required by Practise How strategy, plan and procedures interoperate Plan (TMP) Group/Local delivery plan Standard The minimum functional/design requirements for an asset(s) Delivers part of Procedure Formal def'n of a business process Aligned to Describes part of Adjusts Specification Detailed requirements for an asset(s) or component Aligned to Work Instr. Formal steps for a specific job Used by Design Practice Note Change/Clarification to Standard or Specification Adjusts Form Information fields to be captured Facilitates Manual/ Guideline Handbook relevant to an asset Figure 1- MTM Engineering Documentation Hierarchy PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 8 of 16

9 9. Process Figure 3 below depicts the functional workflow lifecycle for the development of an Engineering Standard within MTM. 9.1 ES Initiation 9.2 Draft and Develop 9.3 Risk Assessment 9.4 ES (EWG) Internal Review 9.5 ES (EWG) External Review 9.6 ES Final Collation & Approval 9.7 Release & Publication 9.8 Document Maintenance Figure 2 - Engineering Standards Development Process Flow Note: The following sections detail the actions and responsibilities expected for each of the steps illustrated in Figure 2. For a detailed process flow for the development of a new/updated ES refer to Appendix ES Initiation Identifying the Need for an ES Responsibility: A proposal for a new or updated ES may originate from within MTM or from an external party (e.g. Melbourne Metro Rail Authority (MMRA), Level Crossing Removal Authority (LXRA) or PTV). The need for developing a new ES or updating an existing ES may eventuate through a variety of reasons including: Compliance with new/existing Government Legislation/Regulations Compliance with new/existing PTV network requirements Update of internal standards or specifications Update to external reference standard Incorporation of Design Practice Notes New requirements driven through industry developments or technological advancements Note: All ES development proposals are to be communicated to the ESC via the meeting secretary and recorded/tracked within an Engineering Standards Master Register Consult the Master Engineering Standards Register A review of the ES documentation currently endorsed and/or in work should be completed prior to the proposal of a new/or amendment ES Develop Scoping Paper (Engineering Standard Proposal) The need for developing a new or updating an existing ES will be conducted through the following steps: Detail the scope of the ES to be updated/developed Conduct a Gap Analysis to determine what gaps currently exist in the MTM Engineering Standards PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 9 of 16

10 Produce a brief proposal discussion paper for the applicable discipline MTM Head(s) of Engineering as outlined below. All proposals discussion paper to the MTM Head(s) of Engineering shall include the following: Background context Objectives of the new or amended ES General scope in the ES (gaps identified) Process that will be followed Where the ES sits within the standards hierarchy Identify other documentation impacted by new/updated ES Approval to proceed & produce ES (Engineering Standard Committee) Responsibility: Applicable Head(s) of Engineering and ESC All ES development proposals are reviewed and endorsed by the relevant MTM Head(s) of Engineering prior to proposal being presented to the ESC for discussion and authorisation to proceed. The ESC will determine whether the new or updated ES should be developed based on the endorsed discussion paper produced under section The ESC will either approve, approve with comments, or reject the proposal (pending re-work if necessary). The ESC will allocate a document author and/or EWG lead for the development of the ES. 9.2 ES Draft and Development Phase Responsibility: Document Author, EWG and Subject Matter Experts (SMEs) The drafting of the ES will be a collaborative process led by the Document Author, with key input from the applicable SMEs through the EWG, as required. The following actions should be followed: a) Kick-off meeting with the EWG associated with the specific ES to explain scope, program, responsibilities, process for drafting and review, and discuss and agree the key inputs and potential risks and issues b) Draft amended or new standard clauses c) Develop change tracking sheet detailing changes from existing standards and rationale behind these decisions. d) Utilise the SMEs for specific areas of the ES that requires their input e) Manage the risk register and populate to demonstrate where the ES development has actioned specific risks. f) Continue to meet with the EWG to discuss and agree on new and amended clauses g) Agree with EWG on a final draft version for submission to the applicable Head(s) of Engineering at MTM identified stakeholders h) The appropriate funding should be agreed upon at ESC level (if necessary). PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 10 of 16

11 9.3 Risk Assessment Responsibility: Document Author and EWG shall ensure risk assessment is undertaken. The risk assessment is mandatory and should cover safety, operational, maintenance and technical risks identified and controlled through the development of the new/amended ES Updates to ES Responsibility: Document Author, EWG and SMEs The document author will collate the risk assessment outcomes, and review them in consultation with the EWG and SMEs, and create a revised draft standard for stakeholder submission. 9.4 ES Internal Stakeholder Peer Review Internal Review Responsibility: Document Author, EWG and Stakeholders The document author and/or EWG lead will submit the draft ES documents for review to the relevant internal stakeholders for a defined review period (number of days/weeks to be determined by the relevant stakeholders). The internal stakeholders will provide comments back to the document author and/or EWG lead for consideration Update to ES Responsibility: Document Author, EWG and SMEs The document author will collate the internal peer review comments, reviewing them in consultation with the EWG, and either incorporate the comments or providing response as to the reason that the comment has not been incorporated. Changes that are not agreed to be made will be added to an issues register by the document author or EWG lead for reference of the ESC and document signatories Approval for submission to External Peer Review Responsibility: MTM Head(s) of Engineering Upon receipt of the updated draft ES from the document author, the MTM Head(s) of Engineering will be responsible for endorsing the submission of the draft ES and associated documents for external stakeholder review. PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 11 of 16

12 9.5 ES External Stakeholder Peer Review External Review Responsibility: Document Author, EWG and Stakeholders The document author and/or EWG lead will submit the draft ES documents for review to the relevant external stakeholders for a defined review period (number of days/weeks to be determined by the relevant stakeholders). The external stakeholders will provide comments back to the document author and/or EWG lead for consideration Update to ES Responsibility: Document Author, EWG and SMEs The document author will collate the internal peer review comments, reviewing them in consultation with the EWG, and either incorporate the comments or providing response as to the reason that the comment has not been incorporated. Changes that are not agreed to be made will be added to an issues register by the document author or EWG lead for reference of the ESC and document signatories. 9.6 ES Final Collation & Approval ES Final Collation Responsibility: Document Author and EWG The document author and EWG lead will submit the final ES documents to the relevant signatories to actively seek their approval (number of days/weeks to be determined by the relevant stakeholders). Issues that cannot be resolved will be elevated to the ESC for discussion, with the MTM Chief Engineer having ultimate authority if the ESC cannot resolve the issue ES Final Endorsement & Approval Responsibility: MTM Head(s) of Engineering, MTM Stakeholder and MTM Chief Engineer The final version of the new or amended ES along with demonstrated stakeholder consultation review and approval will be issued to the applicable signatories for their review and endorsement. Final authority for approval of MTM Engineering Standards lies with the MTM Chief Engineer. 9.7 Release and Publication Formal Document Number Responsibility: MTM Document Controller A document number for a new ES will need to be requested by the document author from the MTM Document Controller in accordance with the MTM Document Control Procedure (L0-SQE-PRO-001). PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 12 of 16

13 9.7.2 Publication of the Standard Responsibility: MTM Configuration Management Specialist and Document Controller Upon receipt of the approved ES, MTM will publish the revised or new ES on the MTM internal and external document systems. 9.8 Document Maintenance Responsibility: MTM Configuration Management Specialist, MTM Document Controller and ESC The revised or new Engineering Standard may require periodical updates to reflect ongoing improvements to safety, performance and reliability of returned assets. The updates may be: 1. Requested from internal or external stakeholders 2. Periodical review updates in-line with quality requirements defined in the Document Control Procedure (L0-SQE-PRO-001) 3. As directed by the ESC 4. All updates to ES will follow the steps laid out in this procedure. Note: Minor administration updates to a document are exempt from point Out of Course Standards Updates Where a change is deemed to be of a minor nature with no change to the intent of the standard this update can be completed outside of this process, as agreed by the appropriate Head(s) of Engineering or Chief Engineer. Any out of course update will be noted at the next ESC meeting. 11. Appendices Appendix 1 Engineering Standard Development Process Appendix 2 Engineering Standard Development Recommendations PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 13 of 16

14 11.1 Appendix 1 Engineering Standard Development Process Approving Manager: Chief Engineer Approval Date: 21/12/2016 Next Review Date:21/06/2017 PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 14 of 16

15 11.2 Appendix 2 Engineering Standard Development Recommendations In developing a standard the following aspects should be considered: Safety (OH&S) / Rail Safety Requirements Safety (OH&S) / Rail Safety Requirements include the requirements concerned with preventing or minimising unintended hazards to public, personnel, property, and the physical environment. Examples include safety of public on our trains and network, working around high voltage electricity, working around moving trains, restricting the use of dangerous materials; classifying explosives for purposes of shipping, handling, and storing; abort/escape provisions from enclosures; grounding of electrical systems; and decontamination. Quality Requirements Quality Requirements include certification/accreditation to ISO 9001 requirements. Examples include test certificate, compliance certificate, etc, for the product. Environmental Requirements Environmental Requirements include the requirements regarding the environment in which the system must operate. Examples include the environmental conditions that the system must withstand during transportation, storage, and operation, such as conditions in the natural environment (wind, rain, temperature). Functional, Technical & Performance Requirements For each Capability/Object/Major Function of the system the standard shall include 1. Functional Requirements, 2. Technical Requirements; and 3. Performance requirements. The requirements should take into account whether the system is required to operate in more than one state or mode having requirements distinct from other states or modes, this paragraph shall identify and define each state and mode. Examples of states and modes include: idle, ready, active, post-use analysis, degraded, emergency and backup. If no states or modes are required, this paragraph shall so state, without the need to create artificial distinctions. For the System Capability requirements shall specify required behaviour of the system and shall include applicable parameters, such as response times, throughput times, other timing constraints, sequencing, accuracy, capacities (how much/how many), priorities, continuous operation requirements, and allowable deviations based on operating conditions. System Interface Requirements Internal Interface Requirements The Internal Interface Requirements include the requirements imposed on interfaces internal to the system. External Interface Requirements External Interface Requirements shall include the requirements detailing the system s external interfaces. This may include references to one or more Interface Requirements Specifications or other documents containing these requirements. PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 15 of 16

16 Design and Implementation Constraints The Design and Implementation Constraints includes the requirements detailing any constraints to the design and/or construction of the system. Examples include requirements concerning: Use of particular design or construction standards; workmanship requirements and production techniques; Physical characteristics of the system (such as weight limits, dimensional limits, colour, protective coatings); interchangeability of parts; ability to be transported from one location to another; ability to be carried or set up by one, or a given number of, persons; Materials that can and cannot be used; requirements on the handling of toxic materials; limits on the electromagnetic radiation that the system is permitted to generate; Use of nameplates, part marking, serial and lot number marking, and other identifying markings Security and Privacy Requirements This Security and Privacy Requirement shall include the environment in which the system must operate, the type and degree of security or privacy, the criteria that must be met for security or privacy certification/accreditation. HFE Requirements The Human Factors Engineering requirements detail the considerations for the capabilities and limitations of humans; foreseeable human errors under both normal and extreme conditions; and specific areas where the effects of human error would be particularly serious. Examples include requirements for adjustable-height work stations, colour and duration of error messages, physical placement of critical indicators or keys, and use of auditory signals. Installation Requirements The Installation requirements detail any specific installation requirements for the system. This may include installation limitations and constraints. Logistic and Support Requirements The Logistic and Support requirements detail any logistics considerations including system maintenance, software support, system transportation modes, supply-system requirements such as spare parts, special tools, impact on existing facilities, and impact on existing equipment. This will include all documentation that is required to be provided to support these requirements. Training Requirements The Training Requirements detail paragraph shall specify the system requirements pertaining to training. This may include training devices and training materials to be included in the system. Whole of Life Whole of Life refers to the total cost of ownership of over the life of the asset. In developing a standard this should be taken into account the entire lifecycle of the asset ensuring the best balance between Capital and Operating Expenditure. PRINTOUT MAY NOT BE UP-TO-DATE; REFER TO METRO INTRANET FOR THE LATEST VERSION Page 16 of 16