/

Systems Engineering for

Infrastructure Projects

Jon Shaw CEng, MBA, MSc(Eng), BEng (Hons), FIET, FIRSE

Engineering Director, Network Rail

18-Apr-16 1

/18-Apr-16

Presentation Title: Insert > Header & Footer

2

/18-Apr-16 3

Systems Engineering Approach

• Poor Scope Definition

• Working in Discipline Silo’s

• Poor Sharing of Lessons Learned and Best Practice

/

Example of Systems Learning Need

418-Apr-16

BT Competence:

Onboard Train Control

Activities INCOSE Competence BT Competence:

Entrance Systems

Ve

hic

le E

ng

ine

erin

gS

ys

tem

s In

teg

ratio

n

Ca

b &

Sa

loo

n S

ys

tem

s/ M

ec

ha

nic

al

Sy

ste

ms

Requirements

Analysis

Perform Functional

Analyses

Functional Trade

Studies and

assessments

Requirements

Baseline

Functional

Architecture/

Requirements

Systems Thinking: Systems Concepts

Systems Thinking: Super System Capability Issues

Systems Thinking: Enterprise and Technology

Environment

Holistic Lifecycle View: Determining and Managing

Stakeholder Requirements

Holistic Lifecycle View: Systems Design – Interface

Management

Holistic Lifecycle View: Systems Design – Select

Preferred Solution

Holistic Lifecycle View: System Design: System

Robustness

Holistic Lifecycle View: Systems Design –

Architectural Design

Holistic Lifecycle View: Systems Integration and

Verification

Holistic Lifecycle View – Validation

Holistic Lifecycle View: Systems Design - Maintain

Design Integrity

Holistic Lifecycle View: Systems Design – Modelling

and Simulation

Holistic Lifecycle View: Systems Design – Functional

Analysis

Holistic Lifecycle View: Systems Design – Concept

Generation

4S_12

Exterior Door

Systems

Vehicle Integration

Doors

(Heath Caddy)

Total System Integration

Requirements Management

Total System Integration

(Kevin Bowry)

Requirements Management

(Kevin Bowry)

Functional Engineering

(Mark Lowther)

PEDs/PSDs

1C_06 Operability

(Kevin Bowry)

2F_09 Train Control

(Mark Lowther)

2F_10 TCMS

(Mark Lowther)

2F_14 Exterior Doors & Step Systems

(Heath Caddy)

2F_12 Train to Wayside Comms

(Mark Lowther)

4S_09

Onboard Train

Control

Vehicle Integration

ATC/ATP Integration

(Kevin Bowry)

Total System Integration

Requirements Management

Total System Integration

(Kevin Bowry)

Requirements Management

(Kevin Bowry)

Functional Engineering

(Mark Lowther)

Conventional Train

Control

(Mark Lowther)

1C_06 Operability

(Kevin Bowry)

2F_09 Train Control

(Mark Lowther)

2F_10 TCMS

(Mark Lowther)

2F_12 Train to Wayside Comms

(Mark Lowther)

Allocate to

Subsystems

Requirements Trade

Studies and

assessments

Design Trade

Studies and

assessments

TRD’s/

DSD’s

Product

Knowledge

1C_06 Operability 1C_06 OperabilityHolistic Lifecycle View: Determining and Managing

Stakeholder Requirements

Holistic Lifecycle View: Systems Design – Interface

Management

Holistic Lifecycle View: Systems Design – Modelling

and Simulation

Holistic Lifecycle View: Systems Design – Select

Preferred Solution

/

Systems Engineering Capability

Systems Engineering for Infrastructure Projects

518-Apr-16

Single Integrated Engineering Competency Framework

Specialist

Professional

Discipline

Competencies

e.g. Civil

Engineering,

Signalling,

Telecoms,

Track, Traction

Power, Eng

Programme

Delivery

Systems

Engineering

Competencies

(INCOSE

Framework)

Behavioural

Competencies

e.g. Drive for

Results,

Initiative,

Teamwork,

Making

Decisions,

Continuous

Improvement

Cognitive &

Enterprise

Competencies

e.g. Safety,

Ethics, Problem

Solving,

Innovation

/

Scope Definition

• New Requirements Management Policy Issued

• Mandates use of DOORS

• Training of 270 trainers complete, c3000 by end 2016

• Piloted on ECML & Thameslink

• Risk Assessment Process for Requirements Maturity

618-Apr-16

Categorised = Object in DOORS identified as Requirement / Deliverable / Information – simple first step

Consolidated = Requirement written, reviewed and complete

Satisfied = Requirement has satisfaction arguments and linked, decomposed requirements

Linking OK = Requirement is flowed down to FRS, SRD as appropriate

Allocated = Requirement has been accepted and approved by FRS / SRD engineer

/

Engineering Lifecycle Developed

Systems Engineering for Infrastructure Projects

718-Apr-16

/

Technical Stage Gate Reviews

Systems Engineering for Infrastructure Projects

• Engineering Assurance Function

• Risk Based Approach

• Expert Peer Review from Across NR &

External where Needed (inc. Suppliers,

Maintenance, etc.)

• Technical Stage Gates identified in

Engineering Lifecycle

• Supporting Checklists & Guidance

• Risk Assessment of Checklist Items not

Fully Closed

• Piloted on Crossrail West & Heathrow

ETCS

818-Apr-16

Has an asset condition report

been completed issued with

an a l lowance made in the

programme for a l l specia l

working arrangements

identi fied?

Asset Condition Assessment Report (SICA): The purpose of

this product is to record the existing condition of the assets

w hich w ill be involved in the investment scheme.

Asset Condition Report (Alterability): The purpose of this

product is to record the existing condition of the assets w hich

w ill be involved in the investment scheme for alterability

(Including but not limited to Pow er Supplies, Existing

Transmission Systems, Data).

Have a l l Correlation

Requirements been

cons idered and programmed?

The purpose of the Correlation report is to confirm the status

of the existing infrastructure, highlighting any deficiencies that

may also need addressing.

Has an IDC process been

agreed between a l l

s takeholders?

The purpose of the IDC/IDR is to integrate all the

multidisciplinary elements of design. Form B/Forms 2 & 3 -

Final design: To certify the design in accordance w ith all

statutory safety standards requirements. Form Bs (Forms 2&3

for Civils) are required to be integrated under IDC and IDR.

Geotechnical Survey to reduce the risk of unexpected ground

conditions increasing the cost of structural foundations and

other w ork associated w ith signals and locations.

Has an agreed Des ign

Interface Schedule or

equiva lent been agreed

between a l l discipl ines and

populated to ensure timely

avai labi l i ty of engineering

A Design Interface Schedule (DIS) or Give / Get Dates are

defined so that all engineering disciplines are aw are of the

requirements of the interfacing designers and are then able to

undertake design integration activities correctly i.e. IDC / IDR.

/

Interface Management

• Project Engineering Handbook to Provide Guidance

• Requirements Flowed Down from System to Sub-system

to Component / Data

• Interface Matrices

• Interface Control Documents

• Interdisciplinary Design Reviews

• Interface Schedules

• Adopted on Thameslink Project

918-Apr-1618-Apr-16 9

/18-Apr-16 10

New Product ReliabilityRoute-Level Reliability

Apportionment to Product

Single Point Failure

Analysis

Product Sub-System Level FMEA

Identify Core Sub-

System Building Blocks

(PBS) – (Note: Will

include Sub-system

FMEAs)

Component 1 –

Standard Module:

Demonstrate

Proven Service

History

Component 2 –

New Module: Tech

Readiness Level

Risks

Identify all

sub-system

Interfaces

Component 3 – New

Software Code: Tech

Readiness Level Risks

Combined Supplier-NR Reliability

Risk & Op Register

Integrated V&V Plan

(Supplier & NR) inc.

Testing

Integrated Software

Programme +

Diagnostic

Service

Performance &

LCC

Governance Prognostics /

Condition Based

Maintenance

Team Member 6

D6dPermanent Corrective Action Control Measure(s) Implemented Validation: Validate the Permanent Corrective action control measure (s)

by noting the permanent corrective actions on a Pareto Chart. If the failure mode reoccurs, then the Root Cause was not properly identified and/or eliminated,

or a second Root Cause exists and still needs to be identified and corrected.

D7Preventative Action(s): Review the applicability of the corrective actions to similar products and process and recommend similar actions where

appropriate. Note all the recomendations on the Action Plan Summary. After Management Reviews, determine which recomendations to pursue. Record only

the approved preventative actions in D7, along with their corresponding Project (i.e. Prevention Log) and Tracking Number.

D8Obtain Closure From Customer: Champion and Team Leader. Once approved, remove Containment and/or Interim Actions. Recognise and

congratulate the Team and Individual efforts.

D6bPermanent Corrective Action(s) Implemented Validation: Validate the Permanent Corrective action(s) by noting the permanent corrective

actions on a Pareto Chart. If the failure mode reoccurs, then the Root Cause was not properly identified and/or eliminated, or a second Root Cause exists and

still needs to be identified and corrected.

D6c

Permanent Corrective Action Control Measure (s) Implemented: Implement Permanent Corrective action control measuress as per the

Action Plan Summary to permanently eliminate the problem from getting to the customer (Escape Root Cause path). Identify the system, practices,

procedures and standards that allowed the problem to Occur. Up-date all pertinent documentation (Process flows, FMEA's, Control Plans, Work Instructions,

Visual Aids, Specifications, Standards, Inspection Instructions etc..) based on the corrective actions taken and lessons learned.

D6aPermanent Corrective Action(s) Implemented: Implement Permanent Corrective actions as per the Action Plan Summary. Identify the system,

practices, procedures and standards that allowed the problem to Occur. Up-date all pertinent documentation (Process flows, FMEA's, Control Plans, Work

Instructions, Visual Aids, Specifications, Standards, Inspection Instructions etc..) based on the corrective actions taken and lessons learned.

D5bPermanent Corrective Action Control Measure (s) Chosen: Analyse corrective action alternatives and select the "Best" based on Impact and

Risk. The corrective actions control measure chosen should permanently eliminate the problem from getting to the customer (Escape Root Cause path).

Verification: Verify that the chosen Corrective Action(s) eliminates the Escape Root Cause & does not create another adverse effect.

D3a Interim Containment Action(s) Selected: Identify and immediately implement containment action(s) on vehicles to protect the customer from using

a non-conforming vehicle.

Why is this?

Why is this?

D3f

Fish Bone

Analysis

As a Team, analyse all the possible issues that could have caused the none conformance. Do not start asking Why at this point! Start the process by

highlighting the Problem Description and then recording all suggestions put forward, no matter how significant.

Why Does?

D5aPermanent Corrective Action(s) Chosen: Analyse corrective action alternatives and select the "Best" based on Impact and Risk. The corrective

Actions chosen should permanently eliminate the Root Cause path identified in D4a.

Verification: Verify that the chosen Corrective Action(s) eliminates the Occurance Root Cause & does not create another adverse effect.

Why is this?

Interim Corrective Action(s) Validation: Validate that the Corrective Action(s) Selected in D3d has / have been Successful.

Why is this?

D3dInterim Corrective Action(s) Selected: Identify and Implement Interim Corrective Actions that will protect the customer from any repeat issue until

the root cause has been eliminated.

D3eInterim Corrective Action(s) Verification: Verify that the Interim Corrective Action(s) Selected in D3d has / have been Implemented.

D3c

Because:

Root Cause 3 Root Cause 4

Interim Containment Validation: Validate that the Containment Action Selected in D3a has been Successful.

Because:

Why is this?

Team Member 5

Because:

Because:

Why is this?

Why is this?

Why is this?

Why is this?

Because:

Why Does?

What:

Where:

When:

How Big:

Root Cause 4

Root Cause 1

Why Does? Why Does?

D4bInvestigate why existing control measures allow the Occurance to happen: Why did the Non-Conformance Escape to the Customer?

Again challenge conclusions with Why did/can the non-conformance by-pass current controls.

Why is this?

D1

Team Member 2

Team Role

Champion

Team Leader

Team Member 1

Contact Number e-mail addressName Function / Title

Customer Contact

Team Member 3

Team Member 4

D2Problem Description: Start the Problem Description using the same words as used in the 8D Log to facilitate tracking. Answer the following to precisely

define the problem. Once a Problem Statement has been developed and Fish Bone Analysis completed, continue to ask Why? Until you reach a level that can

be acted upon. Initiate an Action Plan Summary. Continue to up-date the Action Plan Summary throughout each step of the problem solving process, to

support and track all activity required to contain and eliminate the problem (i.e. Actions, Timings & Responsibility.

Identify the Team Members: Customer Contact, Champion. Check for cross-functional team representation and expertise. The Champion should

typically be the process owner / area manager of where the problem appears to have originated.

Because:

Why is this?

Because:

Because:

Root Cause 2Root Cause 1 Root Cause 2

5 Why

Analysis

As a Team, analyse the top 4 possible root causes from the Fish Bone Analysis that the Team Believes would eliminate the non-conformance. Keep on

Asking Why until the 5th Why if possible.

Because:

Because:

Because:

Because: Because:

Why is this?

Why is this?

Why is this? Root Cause 3 Why is this?

Because:

Why is this?

D4aInvestigate The Root Cause of the Occurance & Verify: Review the Problem Description to identify potential Root Cause(s). Verify the root

cause e.g If the root cause was not present, would the occurance still happen.

Because: Because:

D3bInterim Containment Action(s) Verification: Verify that the Containment Action(s) Selected in D3a has / have been Implemented.

Machine

Method

Environment

Material

Man

Problem:

/

Summary

1118-Apr-16

• Network Rail is Adopting a Systems Engineering Approach to Project Delivery

• New Engineering Lifecycle Developed

• ‘Hard’ Technical Stage Gates with Risk Assessment

• New Requirements Management Policy

• Interface Management Guidance Created

• New Competency Framework including INCOSE