Advanced Railway Control System (ARCS) Final Presentation

Becky Szpieg

Systems Engineering Project Johns Hopkins University Whiting School of Engineering December 15, 2015

Agenda • Biography • Project Introduction • System Overview • Requirements Analysis • Functional Analysis • Physical Design • Trade Study • System Specification • Risk Management • Forward Plan • Program Management • Lessons Learned • Conclusion

2

Biography • Personal

▫ Born and raised in southern New Jersey ▫ Currently live near Atlantic City, NJ

• Education ▫ B.S. in Computer Science, Rowan University (2004)

• Professional ▫ Lockheed Martin (2006 – Present)

Systems Engineer, Systems Integration & Test Engineer Supporting the FAA in development, test, integration,

deployment and maintenance of development and operational Enroute Air Traffic Control systems.

Focus on large enterprise level systems

• Interests ▫ Traveling ▫ Cooking ▫ Golf

3

Project Introduction • Name: Advanced Railway Control System (ARCS) • Need: Rail Safety Improvement Act (RSIA) of 2008 ▫ Mandates all rail lines operating passenger service must

implement interoperable PTC systems by Dec. 2015. ▫ Defines safety requirements which also must be met.

• PTC definition: ▫ Positive Train Control - An integrated command,

control, communications and information system for controlling train movements with safety, security, precision and efficiency.

• Needs Statement: ▫ Develop an interoperable Positive Train Control (PTC)

system that would improve safety and increase performance for High Speed Rail (HSR) systems in the US.

4

Project Introduction - Operational Objectives

5

Interoperability Meet Federal Safety Standards

Positive Train Control System

Interoperable PTC System for US High Speed Railway

Prevent Train-to-Train Collisions

Prevent Over-speed Derailments

Prevent Incursions into Work Zones

Prevent Movement Through Switch in

Wrong Position

Infrastructure Management and

Control

Railway Maintenance Management and Control

Train Management and Control

System Level Interoperability

System-of-System Level

Interoperability

Route Management and Control

System Overview • A ‘host railway’ will integrate ARCS into their existing

railway infrastructure • Designed as a universal PTC system, adapted to

function within a wide range of existing and future HSR networks

• ARCS is capable of easily interfacing with neighboring ARCS-adapted railways

• Provides the host railway with: ▫ System-wide railway management ▫ Train management and control ▫ Infrastructure management ▫ Remote Wayside Unit control ▫ Route tracking and control ▫ Management of safety operations

6

System Overview - CONOPS

7

Navigation Satellite

Location Determination

Unit (LDU)

Requirements Analysis • Requirements development

▫ Using the following inputs, a set of top-level system requirements were defined ▫ Top-level requirements analyzed and refined into lower level requirements ▫ Iterative process ▫ Limited access to SMEs/stakeholders

• Inputs – ▫ Government Agencies

Federal Railroad Administration (FRA), National Transportation Safety Board (NTSB) ▫ Federal Law

Rail Safety Improvement Act of 2008 ▫ Federal Regulations

Title 49 Code of Federal Regulations (CFR) Parts 200-299 Federal Railroad Administration, Department of Transportation

▫ European Standards European Rail Traffic Management System (ERTMS)

▫ Railway Industry Associations The American Railway Engineering and Maintenance-of-Way Association (AREMA) US High Speed Rail Association (USHSR)

▫ End-User Community National Association of Railroad Passengers (NARPRAIL)

▫ Potential Customers (Host-Users) National Railroad Passenger Corporation (AMTRAK) California High-Speed Rail Authority

8

Requirements Analysis - TLRs • Top Level Requirements

9

Reqt # Title RAR A-Spec Edits Quantitative Qualitative

REQ 1.0 System Stability Requirements 6 6 1 3 1

REQ 2.0 Support Requirements 10 10 0 0 3

REQ 3.0 Interoperability Requirements 7 7 0 2 0

REQ 4.0 Interface Requirements 7 7 0 4 2

REQ 5.0 PTC Functional Requirements 91 90 7 22 17

REQ 6.0 Safety Requirements 26 24 0 6 4

Totals: 147 144 8 37 27

Percentage: 26% 19%

Requirements Analysis - KPPs

10

• Key Performance Parameters (KPPs)

REQ ID Name Requirement Text

REQ 1.2 Capacity The system shall be capable of facilitating safe operations for at least 300 active trains within the boundaries of 1 host railway.

REQ 3.5 Interoperability Systems The system shall be capable of interfacing with up to 10 neighboring railways utilizing an ARCS system.

REQ 5.2.3 Train Locations The system shall monitor the location of all active trains operating within system bounds to +/- 2.5 meters (CEP) of accuracy.

REQ 5.2.4 Train Location Updates The system shall update the train location once per second while the train is active.

REQ 5.2.5 Train Speeds The system shall monitor the speed of all active trains operating within system bounds to +/- 2 kph.

REQ 5.2.6 Train Speed Updates The system shall update the train speed once per second while the train is active.

REQ 5.5.3 WU Status Updates The system shall update the wayside unit status once every 3 seconds while the wayside unit is active.

Requirements Analysis - Traceability

11

• Verification Requirements Traceability Matrix (VRTM) REQ ID Name Requirement Text Source Verification

Method 6.0 Safety Requirements

6.1 Safety Standards The system shall abide by federal safety standards set forth in Title 49 CFR Part 236 and 239.

49 CFR 236 49 CFR 239 I

6.2 Prevent Collision The system shall prevent train-to-train collisions. RSIA T 6.3 Prevent Over-Speed The system shall prevent over-speed derailments. RSIA T 6.4 Prevent Incursions The system shall prevent incursions of a train into an established work zone. RSIA T

6.5 Wrong Switch Position The system shall prevent the movement of a train through a switch left in the wrong position. RSIA T

6.6 Safety Normal Conditions The system shall operate safely under normal conditions as defined in AREMA MP 11.5.1. AREMA MP 11.5.1 T

6.7 Safety Adverse Conditions The system shall operate safely under adverse conditions as defined in AREMA MP 11.5.1. AREMA MP 11.5.1 T

6.8 Maintain Safe State The system shall maintain a safe state under all failure conditions. AREMA MP 17.3.1 T 6.9 Hazard Detection The system shall provide automated hazard detection. Derived T

6.10 Hazard Types Hazard detections shall include train-to-train collisions, over-speed derailments, incursions into established work zones, and incorrect switch positions.

RSIA T

6.11 Provide Warning Notifications The system shall provide warning notifications to the train crew. 49 CFR 236.1005 T

6.12 Warning Notification Timing The system shall provide warning notifications with execution times for detected hazards within a sufficient time and distance that allows the train crew to take corrective action.

Derived T

6.13 Execute Corrective Action The system shall initiate corrective action to resolve a hazard after the warning notification execution time has passed if the hazard still exists and no other action has been taken to resolve the hazard.

49 CFR 236.1005 T

6.14 Hazard Resolution The system shall provide suggested actions to resolve an identified hazard. 50 CFR 236.1005 T

6.15 Braking Warning The system shall provide warning notification when the brakes should be applied. 49 CFR 236 T

Functional Analysis • Inputs – ▫ Operational Objectives ▫ System requirements ▫ CONOPS

• Further refined Context Diagram ▫ Defined external entities and system interfaces

• Set of system level functions defined • Further refined functions into lower level subsystem

functions • Iterative approach - analyzing functions and mapping

back to system requirements ▫ Grouped functions performing similar actions together ▫ Identified overlap (duplication) ▫ Functions not mapped to system requirements (extras)

• Developed Functional Block Diagrams

12

Functional Analysis – Context Diagram

13

Navigation Satellite

Satellite Signal

Functional Analysis – Function Tree

14

FUNC 1.0 Manage Railway Operations

FUNC 4.0 Monitor Railway Safety

Operations

FUNC 2.0 Manage Train Operations

FUNC 0 Provide ARCS Services

FUNC 4.1 Monitor Safety Hazards

FUNC 4.2 Determine Hazard Resolution

FUNC 4.3 Provide Hazard Warning

Notifications

FUNC 2.2 Determine Train Location Details

FUNC 2.1 Monitor Train Status

FUNC 1.1 Monitor All Trains

FUNC 1.2 Control Train Routes

FUNC 2.3 Control Train Components

FUNC 3.0 Control Wayside Unit Operations

FUNC 1.5 Interface with Host User

FUNC 1.7 Provide System Support

Operations

FUNC 1.3 Manage Railway Infrastructure

FUNC 1.4 Control Railway Maintenance

FUNC 1.6 Interface with Neighbors

FUNC 3.1 Interface with Wayside Unit

FUNC 3.6 Perform Remote WU Command

FUNC 3.3 Interface with Train

FUNC 3.2 Interface with Host User

FUNC 3.7 Conduct WU Diagnostics

FUNC 3.4 Monitor WU Status

FUNC 3.5 Ensure Correct State

Functional Analysis – Top-Level Functional Diagram

15

Functional Analysis - Top-Level N2 Diagram

16

Host User InputIO 1.1 Train Control Data

Train Crew InputIO 1.1 Train Control Data

IO 2.1 GPS DataIO 2.3 Onboard Train Control Data

IO 3.1 WU Status

FUNC 1.0Manage Railway

OperationsIO 1.1 Train Control Data IO 1.1 Train Control Data

IO 1.1 Train Control DataIO 1.5 Infrastructure DataIO 1.6 Maintenance Data

Host User OutputIO 1.1 Train Control Data

IO 1.1 Train Control Data FUNC 2.0Manage Train Operations IO 1.1 Train Control Data IO 1.1 Train Control Data Train Crew Output

IO 1.1 Train Control Data

IO 3.1 WU Status IO 3.1 WU Status FUNC 3.0Control WU Operations IO 3.1 WU Status IO 3.2 WU Command

IO 4.1 Safety Hazard Data IO 4.1 Safety Hazard Data IO 4.1 Safety Hazard DataFUNC 4.0

Monitor Railway Safety Operations

Functional Analysis – Functional Requirements Matrix

• Provides traceability to system requirements

17

FUNC ID # Name Requirements Traceability

FUNC 0 Provide ARCS Services

REQ 1.0 System Requirements REQ 2.0 Support Requirements REQ 3.0 Interoperability Requirements REQ 4.0 Interface Requirements REQ 5.0 PTC Functional Requirements REQ 6.0 Safety Requirements

FUNC 1.0 Manage Railway Operations REQ 5.1 PTC Functionality

FUNC 2.0 Manage Train Operations REQ 5.1 PTC Functionality

FUNC 3.0 Control Wayside Unit (WU) Operations REQ 5.1 PTC Functionality REQ 5.5.1 WU Management REQ 6.5 Wrong Switch Position

FUNC 4.0 Monitor Railway Safety Operations

REQ 5.1 PTC Functionality REQ 6.1 Safety Standards REQ 6.6 Safety Normal Conditions REQ 6.7 Safety Adverse Conditions REQ 6.8 Maintain Safe State

Physical Design • Inputs – ▫ System objectives & requirements ▫ CONOPS & Context diagram ▫ Function requirements

• Outputs ▫ Physical Components Table ▫ Interface Control Document (ICD) Input/Output Items Physical Links Table

▫ Physical Architecture Diagrams ▫ Architecture Traceability Table

18

Physical Design – Physical Tree Diagram

19

PHY 1.0 Railway Management System

(RMS)

PHY4.0 Communications System (COMMS)

PHY 2.0 Onboard Train System (OTS)

PHY 0 Advanced Railway Control System

PHY 2.2 Crew Interface Unit (CIU)

PHY 2.1 Location Determination

Unit (LDU) PHY 1.1 Host

Interface Unit (HUI)

PHY 1.2 Railway Operations Unit

PHY 2.3 Train Control Unit (TCU)

PHY 3.0 Wayside Unit System (WUS)

FUNC 1.3 Support Subsystem

PHY 1.4 RMS Communications

Unit

PHY 3.1 WU Communications

Unit

PHY 3.3 WU Control Unit

PHY 3.2 WU Interface Unit

PHY 2.4 Monitor & Control Unit (MCU)

Physical Design – Top-Level Physical Block Diagram

20

Physical Design – Level 2 Physical Block Diagram

21

Physical Design – Input / Output Items

22

IO Item # Name Description Type External EntityEXT 1.0 Host RailwayEXT 2.0 TrainEXT 3.0 Train CrewEXT 6.0 ARCS NeighborsEXT 1.0 Host RailwayEXT 3.0 Train CrewEXT 6.0 ARCS Neighbors

IO 1.2 User Data User IDs, passwords and related data Input & Output EXT 1.0 Host RailwayIO 1.3 User Command User entered commands Input EXT 1.0 Host RailwayIO 1.4 User Command Response System response to user entered commands Output EXT 1.0 Host Railway

Input EXT 1.0 Host RailwayEXT 1.0 Host RailwayEXT 3.0 Train Crew

IO 1.6 Maintenance Data Collection of data required for maintenance operations Input & Output EXT 1.0 Host RailwayEXT 1.0 Host RailwayEXT 3.0 Train Crew

IO 1.8 Report Data Data required for creating system reports Output EXT 1.0 Host RailwayIO 1.9 Training Data Data required for creating and executing system training Input & Output EXT 1.0 Host RailwayIO 1.10 System Command System generated command Output EXT 2.0 Train

EXT 1.0 Host RailwayEXT 3.0 Train Crew

IO 2.1 GPS Data GPS data location received from satellite Input EXT 5.0 GPS SatelliteIO 2.3 Onboard Train Control Data System data processed onboard the train Output EXT 3.0 Train CrewIO 2.4 Train Crew Command Command entered by Train Crew Input EXT 3.0 Train CrewIO 2.5 Train Crew Command Response System response to command entered by Train Crew Output EXT 3.0 Train Crew

Input EXT 4.0 Wayside UnitEXT 1.0 Host RailwayEXT 3.0 Train Crew

IO 3.2 WU Command Command to be executed by WU Output EXT 4.0 Wayside UnitIO 3.3 WU Command Response Response to executed WU command Input EXT 4.0 Wayside Unit

EXT 1.0 Host RailwayEXT 3.0 Train Crew

IO 3.1 WU Status Details of individual Wayside UnitOutput

IO 4.1 Safety Hazard Data Safety data for identified hazards Output

IO 1.7 Display Data Data formatted for display to user Output

IO 1.11 Diagnostic Data Details of system diagnostics Output

IO 1.5 Infrastructure DataContains data for infrastructure mapping (type, location, details) Output

IO 1.1 Train Control Data Contains all pertinent data for an individual train

Input

Output

Physical Design – Physical Links Table

23

Item # Name Description Type Connection Point A Connection Point B Transfers

LINK 2.0 GPS Signal The interface between the GPS Satellite and ARCS. Data Link EXT 5.0 GPS Satellite PHY 2.1.1 GPS Antenna IO 2.1 GPS Data

LINK 2.1 Engine Data Link Physical connection between ARCS and the engine system onboard the train. Data Link EXT 2.0 Train PHY 2.3.1 Engine

Interface Unit IO 1.1.10 Train Component Status

LINK 2.2 Brake System Link Physical connection between the engine's braking system and ARCS. Data Link EXT 2.0 Train PHY 2.3.2 Brake

Interface Unit IO 1.1.10 Train Component Status

IO 1.7 Display DataIO 2.5 Train Crew Command Response

LINK 2.4 UI - Train Crew Input Physical input from train crew. User Input EXT 3.0 Train Crew PHY 2.2.2 Onboard Input Unit IO 2.4 Train Crew Command

LINK 2.5 UI - Train Crew Audio Audio that is provided to the train crew. Sound PHY 2.2.3 Onboard Audio Unit EXT 3.0 Train Crew IO 4.1 Safety Hazard Data (Alert)

IO 1.1 Train Control DataIO 1.5 Infrastructure DataIO 2.3 Onboard Train Control Data

IO 1.1 Train Control DataIO 1.11 Diagnostic DataIO 2.3 Onboard Train Control DataIO 4.1 Safety Hazard Data

IO 1.1 Train Control DataIO 1.11 Diagnostic DataIO 2.3 Onboard Train Control DataIO 4.1 Safety Hazard Data

IO 1.1 Train Control DataIO 1.5 Infrastructure DataIO 2.3 Onboard Train Control Data

IO 1.1 Train Control DataIO 1.11 Diagnostic DataIO 2.3 Onboard Train Control DataIO 4.1 Safety Hazard Data

LINK 2.10 OTS Data Link 5 Cabling connecting OTS components Data Link PHY 2.2 Crew Interface Unit

PHY 2.4 Monitor and Control Unit

LINK 2.9 OTS Data Link 4 Cabling connecting OTS components Data Link PHY 2.2 Crew Interface Unit

PHY 2.1 Location Determination Unit

LINK 2.8 OTS Data Link 3 Cabling connecting OTS components Data Link PHY 2.2 Crew Interface Unit

PHY 2.3 Train Control Unit

LINK 2.7 OTS Data Link 2 Cabling connecting OTS components Data Link PHY 2.3 Train Control Unit

PHY 2.4 Monitor and Control Unit

LINK 2.6 OTS Data Link 1 Cabling connecting OTS components Data Link PHY 2.1 Location Determination Unit

PHY 2.4 Monitor and Control Unit

LINK 2.3 UI - Train Crew Visual Display Visual display of user data to train crew. Display PHY 2.2.1 Onboard

Display Unit EXT 3.0 Train Crew

Physical Design – Architecture Traceability Matrix

24

PHY ID # Name Description Type Functional Traceability

PHY 0 Advanced Railway Control System (ARCS)

ARCS Physical Architecture System FUNC 0 Provide ARCS Services

PHY 1.0Railway Management System (RMS) Subsystem providing system operations and control to host railway. Subsystem FUNC 1 Manage Railway Operations

PHY 2.0 Onboard Train System (OTS)Subsystem physically located onboard train which monitors the train's status, provides an interface for the Train Crew and relays data to RMS and WUS.

Subsystem FUNC 2.0 Manage Train Operations

PHY 2.1 Location Determination Unit (LDU)Interfaces with GPS system and train sensors to determine current position and map it to a location on the track. Component FUNC 2.2 Determine Train Location Details

PHY 2.1.1 GPS Antenna Receives and demodulates the signal received from GPS antenna. HWCI FUNC 2.2.1 Receive GPS Data

PHY 2.1.2 GPS Receiver Decodes signals received from GPS antenna. HWCI FUNC 2.2.1 Receive GPS DataFUNC 2.2.2 Calculate Train Location

FUNC 2.2.3 Calculate Train SpeedFUNC 1.3.1 Maintain Track Data

FUNC 2.2.2 Calculate Train Location

PHY 2.2 Crew Interface Unit (CIU)Interacts with the Train Crew to provide train status, safety warnings and audio alerts. Component FUNC 2.4 Interface with Train Crew

PHY 2.3 Train Control Unit (TCU)Responsible for interfacing with and monitoring the train's onboard components. Component FUNC 2.3 Control Train Components

PHY 2.4 Monitor and Control Unit (MCU)Integrates all the inputs from the LDU, CIU and TCU and provides status to the RMS and WUS. Component FUNC 2.1 Monitor Train Status

PHY 3.0 Wayside Unit System (WUS) Subsystem which interfaces with the Wayside Unit and provides status. Subsystem FUNC 3 Control Wayside Unit (WU) Operations

FUNC 1.1.1 Interface with TrainsFUNC 3.2 WU Interface with Host UserFUNC 3.3 WU Interface with Train

SubsystemSubsystem providing system wide communication between all subsystems.Communications SystemPHY 4.0

PHY 2.1.3 Location Manager Application used to convert GPS position data to map location on track. CSCI

PHY 2.1.4 Infrastructure Database Stores the infrastructure data needed for the train's route. HWCI

Trade Study - Methodology

• Methodology ▫ Define focus of Trade Study ▫ Identify key requirements associated with the

component being evaluated ▫ Develop a set of selection criteria ▫ Research and identify possible solutions

(alternatives) ▫ Define weightings and scoring ▫ Evaluate alternatives ▫ Conduct Sensitivity Analysis ▫ Identify recommended solution

25

Trade Study - Focus • Focus – Location Determination Unit (LDU)

▫ Component of the Onboard Train System (OTS) ▫ LDU receives positioning data from satellite navigation systems and sensors

onboard the train then calculates train location, speed and direction of train ▫ Correlates this data to a location on the railway map ▫ The location data is used by the train operator, host railway and also for safety

avoidance

• Selection Criteria ▫ Position Accuracy (meters)

Measures the precision of the estimated position at a point in time as compared to the true position

▫ Maximum Update Rate (Hz) Measures the number of times the position data is update per second. (ex. 1 Hz =

update once per sec) ▫ Internal Sensors (number)

The number of internal sensors included with the component (ex. Accelerometer, odometer, power sensor, speedometer)

▫ Data Communication Interfaces (number) The number of data communication interfaces included with the component (ex.

Cellular, Ethernet, USB, Wifi) ▫ Time to First Fix (TTFF) – Cold Start (seconds)

Measures the amount of time it takes for the component to acquire the satellite signal, receive the navigation data and calculate the position.

26

Trade Study – Selection Criteria • Selection criteria mapped to requirements

27

REQ # Title DescriptionPosition Accuracy

Max Update Rate

Internal Sensors

Data Comm

TTFF

REQ 3.1 Interoperabil ity The system shall comply with the interoperabil ity standards set forth in the AREMA Manual for Railway Engineering (MRE). X X

REQ 3.3 Interoperabil ity Trains The system shall be capable of interfacing with high speed trains operating within the defined system boundaries. X X

REQ 3.6 Location Tracking Interface The system shall interface with the location tracking system. X X

REQ 3.6.1 Receive Location Data The system shall receive location data from the location tracking system for each train operating within the system bounds. X X

REQ 4.4 System Component Interface The system shall support data exchange between all system components.X X

REQ 4.5 Message SecurityThe system shall provide secure data transfer between all system components which comply with the standards set forth in Title 49 CFR 236. X

REQ 4.6 Interface Failure The system shall not allow a single message from an external interface cause a loss of service. X

REQ 5.1 PTC Functionality The system shall provide Positive Train Control (PTC) functionality for the host railway. X X

REQ 5.2.3 Train Locations The system shall monitor the location of all active trains operating within system bounds to +/- 2.5 meters (CEP) of accuracy. X X X

REQ 5.2.4 Train Location Updates The system shall update the train location once per second while the train is active. X X X

REQ 5.2.5 Train Speeds The system shall monitor the speed of all active trains operating within system bounds to +/- 2 kph. X X X

REQ 5.2.6 Train Speed Updates The system shall update the train speed once per second. X X X

REQ 5.2.16.3 Display Train Locations The system shall display the location of all active trains within the system bounds to the host railway. X

REQ 5.3.3.2 Display Nearby Trains The system shall display the location of any active train operating on connecting track within a 50 mile radius. X

REQ 5.3.3.3 Display Train Location The system shall display the location of the train to the train crew. X

REQ 5.7.4 Maintenance Location The system shall monitor the locations of all active maintenance crews and equipment. X

Trade Study - Alternatives • Railnova Railster UG

• LyconSys GPSMOD1

• Furuno GV-86

• U-blox MAX-M8

• i-Lotus RX Oncore

• Trimble BX982 GNSS Module

28

Trade Study – Weights / Raw Scores

• Weightings for selection

• Raw Scores

29

5 CriteriaPosition Accuracy

Max UpdateRate

InternalSensors

DataComm

Time toFirst Fix Product Nth Root

Normalized Weights

Position Accuracy 1.00 3.00 5.00 5.00 3.00 225.000 2.954 0.477Max Update Rate 0.33 1.00 3.00 3.00 1.00 3.000 1.246 0.201Internal Sensors 0.20 0.33 1.00 1.00 0.33 0.022 0.467 0.075Data Comm 0.20 0.33 1.00 1.00 3.00 0.200 0.725 0.117Time to First Fix 0.33 1.00 3.00 0.33 1.00 0.334 0.803 0.130

6.195 1.000

# Name Position Accuracy Max Update Rate Internal Sensors

Data Communication

Time to First Fix (Cold Start)

1 Railster UG 2.5 m CEP 1 Hz 3 4 35 s

2 GPSMOD1 2.5 m CEP 4Hz 1 1 29 s

3 GV-86 2.5 m CEP up to 10 Hz (configurable) 1 1 33 s

4 MAX-M8 2.0 m CEP up to 18 Hz (configurable) 2 3 26 s

5 RX Oncore 2.0 m CEP up to 4 Hz (configurable) 1 4 33 s

6 BX982 0.006 m CEP up to 50 Hz (configurable) 2 6 45 s

Trade Study – Utility Curves

30

Trade Study – Evaluation

• Final matrix:

31

Raw Score

Utility Value

Weighted Utility Value

Raw Score

Utility Value

Weighted Utility Value

Raw Score

Utility Value

Weighted Utility Value

Position Accuracy m 0.477 2.5 0.168 0.0799 2.5 0.168 0.0799 2.5 0.168 0.0799

Max Update Rate Hz 0.201 1 0.020 0.0040 4 0.080 0.0161 10 0.200 0.0402Internal Sensors # 0.075 3 0.375 0.0283 1 0.125 0.0094 1 0.125 0.0094Data Communication # 0.117 4 0.400 0.0468 1 0.100 0.0117 1 0.100 0.0117Time to First Fix (TTFF) Cold-Start s 0.130 35 0.581 0.0753 29 0.4814 0.0624 33 0.5478 0.0710

Operational Utility Function (Weighted Sum) 0.2343 0.1795 0.2122

Criteria Weight

Railster UG GPSMOD1 GV-86Units

Raw Score

Utility Value

Weighted Utility Value

Raw Score

Utility Value

Weighted Utility Value

Raw Score

Utility Value

Weighted Utility Value

Position Accuracy m 0.477 2 0.334 0.1593 2 0.334 0.1593 0.006 0.998 0.4759

Max Update Rate Hz 0.201 18 0.360 0.0724 4 0.080 0.0161 50 1.000 0.2011Internal Sensors # 0.075 2 0.250 0.0188 1 0.125 0.0094 2 0.250 0.0188Data Communication # 0.117 3 0.300 0.0351 4 0.400 0.0468 6 0.600 0.0702Time to First Fix (TTFF) Cold-Start s 0.130 26 0.4316 0.0559 33 0.5478 0.0710 45 0.747 0.0968

Operational Utility Function (Weighted Sum)

RX Oncore

0.3026

BX982

0.8629

Criteria WeightUnits

MAX-M8

0.3416

Risk Management

• Final summary for all identified risks • One risk in detail

32

Status Risk Item #

Type Title Risk Statement Likelihood Consequence Risk Score

Risk Level

Closed R100 Technical Interoperability Objective

Due to the number and complexity of systems ARCS must interact with, it may be difficult to provide interoperability with all interfacing systems.

0.15 75 11.25 Low

Closed R101 Technical Lack of Technical References

The lack of technical documentation and expertise in the industry may create difficulties in defining the system.

0.30 20 6 Low

Updated R102 Technical Dependence on Infrastructure Location Data

The system is highly dependent on the infrastructure location data which is provided from an outside source. Any inaccuracies from this data could cause system degradation and loss of functionality.

0.50 50 25 Medium

Closed R200 Schedule Excessive Complexity and Scope

The development of a large and complex system will prevent the project from completing within the proposed schedule and require more effort than estimated.

0.30 40 12 Low

Updated R300 Cost Costly Infrastructure Component Updates

Due to the number of variations of all railway infrastructure components, the required updates needed to these components to support ARCS may be too costly to justify the added functionality. This may result in cancellation of the program or major reduction in system functionality.

0.50 40 20 Low

Risk Management – Risk #R100

33

Forward Plan • Additional work required to tailor and adapt

ARCS for each individual host railway • ARCS developer must be involved to assist host

railway in integration and deployment of system into their railway system

• Operational use requires FRA approval of a Railroad Safety Program Plan (RSPP) which includes a T&E Plan

• Development of these plans would require the support of the ARCS developer

34

Program Management • Schedule Assessment

35

ID Task Projected Actual Delta (hrs) 1.0 Advanced Railway Control System (ARCS) 310 306.5 -3.5 2.0 Conceptual Development 70 61.5 -8.5 3.0 Requirements Analysis / Concept of Operations 50 65.5 15.5 4.0 Functional Analysis 50 56.5 6.5 5.0 Conceptual Design 50 41.5 -8.5 6.0 Trade Study 25 43.5 18.5 7.0 System Specification (A-Spec) 20 7 -13.0 8.0 Risk Management Report 15 2 -13.0 9.0 Final Report 30 29 -1.0

Lessons Learned

• Decide early which SE tool to use • Clearly define CM plan • Understand design elements WILL change • Be realistic with work estimates and time

commitments • Data storage – backup and save, save, save! • Trade Study required understanding of technical

details

36

Conclusion • Recommendations ▫ SE Program – Suggest to students early on to create a

repository of reference material to be used for final project ▫ Trade Study – Additional reference material on this phase

would be helpful. Warn students specific technical knowledge will be needed.

▫ SE Tools – Access to additional SE tools beyond CORE would be helpful.

• Value to Student ▫ Perfect opportunity to pull together what was learned in

each individual class and apply to a single project ▫ Gave me the opportunity to better understand the

engineering that occurs early in a project’s lifecycle ▫ Learned about my company’s (and current program’s )

specific systems engineering processes ▫ Immediately able to apply what I learned to my current

work

37

Comments / Questions

38