Approaches, Challenges, and Solutions for PTC … Challenges, and Solutions for PTC Systems Management Kevin Nichter Lilee Systems [email protected] 502-438-6950 Number

Approaches, Challenges, and Solutions for PTC Systems Management

Kevin Nichter

Lilee Systems

[email protected]

502-438-6950

Number of Words: 4354

Abstract

The freight and commuter railroads continue to focus on the development, testing, and deployment of

Positive Train Control. These systems will introduce hundreds of thousands of new assets onto the

railways, each of which include specific configurations, software versions, alarming criteria, and other

variables which need to be monitored and managed accordingly. Furthermore, requirements for

interoperability necessitated standardization of the protocols and standards which would enable systems

management to become interoperable across host and tenant railroads.

The concept of systems management as it related to PTC assets evolved with the standards of PTC itself.

Within the rail industry there is some precedent for PTC systems management, using benchmarks such

as existing network management systems already in place to monitor systems such as the status of

wayside microprocessor-based controllers or the locomotive fuel usage and sensor information. It should

be noted that the scale of PTC systems management is expected to be much larger than any other

management systems for wayside and locomotive assets currently in place.

The approaches to systems management vary across the railroads, and are highly dependent on the

types of assets deployed, the communications transports that are available, the availability of internal

resources to support implementation, and the operational processes the railroad desires to implement.

Furthermore, the railroads have recognized the need for systems management to encompass not only

traditional network management functions, but also to serve as a platform for comprehensive analytics

and root cause analysis of the PTC system itself.

© AREMA 2016® 1183

mailto:[email protected]

This paper will detail some of the approaches the railroads have taken to implement PTC systems

management, the challenges that they encountered, and how they envision the systems will be used to

support operations once PTC is fully deployed. Topics such as security, interoperability, change

management, project timelines, and other considerations will also be addressed.

Technology Context

In support of the development of interoperable standards for the deployment of interoperable PTC in the

United States, four Class I railroads formed the Interoperable Train Control committee, or the ITC. These

interoperable standards extended to cover the area of systems management among other areas of need

for an interoperable train control system. Meteorcomm, LLC (“MCC”) was subsequently hired by the four

Class I railroads to implement the standards as defined by the ITC. The manifestation of this work is the

architecture known as Interoperable Train Control Communications, or simply as “ITCC.”

There are three major components of an ITC communications network for PTC:

• A data radio network (provided by ITCR, or Interoperable Train Control Radio)

• The messaging system (provided by ITCM, or Interoperable Train Control Messaging)

• A systems management system.

The data radio network is comprised of both narrow band and broadband networks. In the case of the

narrow band network, an interoperable radio link is provided through a radio operating in the 220 MHz

spectrum based on an MCC reference design. Broadband networks (such 802.11 Wi-Fi, satellite, fiber,

copper, and cellular / LTE) are also utilized within PTC for functions such as distributing large data

downloads needed for train initialization and providing image and firmware updates to components on the

network. Other wireless communications mediums may be utilized as alternate paths for redundant

communications, to augment coverage issues, or optimize large file transfers. In addition to the 220 MHz

spectrum owned by the railroads, individual railroads also own spectrum in the 160 MHz, 450 MHz, and

900 MHz bands for use with both voice and data. As a result, railroads have used radios operating on

some of these licensed bands to provide additional coverage for the PTC system and to utilize the

existing infrastructure.

The ITCM is a suite of software that is deployed in both the back office and remote environments

(typically wayside and locomotive areas). ITCM is a store-and-forward system which utilizes no

guaranteed method of delivery. This allows the system to operate more efficiently, but places an onus on

the sender and receiver to detect lost messages and take appropriate actions to retransmit automatically.

ITCM is designed to run on SBCs (single board computers) currently based on x86 architectures. These

SBCs are coupled with other devices (such as Ethernet switches) within a ruggedized enclosure to

operate as a WMS (Wayside Messaging Server) operating at PTC-equipped wayside locations. In the

1184 © AREMA 2016®

locomotive, an LMS (Locomotive Messaging Server) performs a similar function as the WMS – both the

WMS and LMS are responsible for running the ITCM at their respective locations.

The locomotive and wayside installations of ITCM, also known as Remote Areas, connect to the back

office using ITCM through any available transport (such as the 220 MHz radio, satellite, fiber, copper,

cellular, or Wi-Fi paths). These Remote Areas connect to the back office through an ITCM Application

Gateway.

The third component of an ITC communications network is ITCSM, which is designed to pass information

concerning asset health, configuration, alarms, and other data over the network. ITCSM also enables

remote log retrieval and over-the-air software update capability. ITCSM provides the necessary

framework for over-the-air software downloads, remote command execution, and kits.

ITCSM can be broken down into two additional sub-components. The first is the ITC SMG (Systems

Management Gateway), which provides services such as orchestration authorization, and security for the

railroad back office applications as well as ITC SMGs located on other railways. ITCSM uses the ITCM for

transport across the network and utilizes a standard protocol known as ISMP, or Interoperable Systems

Management Protocol. ISMP is embedded within an Edge Message Protocol (EMP) message, enabling it

to be transported across the ITCM in the same manner as other PTC messages.

The second sub component is the SMA, or Systems Management Agents, which are software modules

installed in back office locations or directly on assets. SMAs enable wayside and locomotive devices to

utilize ITCSM infrastructure to report health status and other information about the asset to interfaces and

users in a centralized location such as a back office. An asset may be any device the railroad desires to

manage – a WIU, TMC, or WMS for example. Each asset to be managed via ITCSM has a respective

SMA. These agents take the form of either an embedded or remote agent and are utilized depending in

part of the architecture deployed for PTC as well as the hardware that is utilized in the field. In the case of

an embedded agent, the asset will provide support for communicating directly with ITCSM via API calls

embedded in the asset’s software without the need for external software. This external software would

have been necessary to provide protocol conversion support to the ITCSM-required format of ISMP. Such

remote agents provide translation services to remote assets which support a non-ISMP form of

management such as SNMP.

Evaluations of Current Technologies and Interoperability

For decades, commercial off-the-shelf NMS (Network Management Systems) have been in use across

the industry for general purpose management of devices in the railroad back office. For example, routers

and servers which conform to SNMP version 2 can be supported using any NMS that conforms to the

same specification which is publicly available. Prior to PTC connectivity to wayside locations (i.e.

intermediate signal locations and control points) was constrained by the limited bandwidth available

© AREMA 2016® 1185

through the ATCS 900 MHz radio unless the railroad had IP connectivity or some alternate wide band

connection to the location. This 900 MHz radio supported the non-vital train code line traffic, which offered

limited capacity for functionality such as over-the-air management. In the event that a broadband

connection was available to the wayside location, it could be utilized as an alternate path for train control

traffic or for providing adequate bandwidth to access wayside assets for tasks such as log retrieval and

event notification from the local devices. Various proprietary solutions were also implemented in the event

that protocols for accessing individual vendor’s equipment was not made publicly available. This further

created difficulties in approaching systems management in a comprehensive manner.

In the context of a truly interoperable PTC system, the need that systems management would also need

to be interoperable was one catalyst for the ITC to evaluate the various network management protocols in

use today. As one of the standard NMS protocols available and one which is well defined within an IETF

RFC and has proven elements of interoperability, SNMP was evaluated as a potential solution for

systems management. However, SNMP offers essentially only three functions: retrieve a value (“GET”),

set a value (“SET”), and generate an unsolicited event or alarm message (known as a “TRAP”). However,

one of the constraints that diminished SNMP’s attractiveness was the usability of the protocol when

coupled with the relatively limited bandwidth offered by the 220 MHz ITC radios. Moreover, there was a

need for enhanced encryption and authentication and delivering data or software to many remotes areas

with a single command. Therefore, ISMP has become a standard for railroads and equipment

manufacturers to develop an interoperable method of systems management.

As defined, an ITCSM Gateway would need be present in every railroad engaging in interoperable PTC

operations to provide the secure interface between railroads for the following purposes:

1.) Obtaining OPK (HMAC) cryptographic keys from other railroads for their trains or locomotives

operating on their own track.

2.) Providing the OPK (HMAC) cryptographic keys for trains and locomotives operating on a foreign

railroad’s track

3.) Allowing access for monitoring purposes to other roads that share the use of asset (such as a

radio base station) that operate on a host railroad

4.) Allowing access to other road’s assets that are shared for monitoring purposes

Security

ITCSM has accommodations for security through public and private keys in conjunction with X.509

security certificates. Interoperable PTC uses what are referred to as Operational Private Keys (OPK) or

just “keys” for authentication of messages sent from one place in the network to another, most importantly

from the wayside to the locomotive onboard computer. These keys are 20 byte binary keys, and are used

with the Hashed Message Authentication Code (HMAC) algorithm to authenticate each message. The

sender of a message uses the OPK and the HMAC algorithm to calculate a hash value over the content

1186 © AREMA 2016®

of a message. This calculated value is then placed at the end of the message. The receiver must know

the same OPK, and uses it to verify that the content of the message is correct. OPKs are used with all of

the basic operational messages in PTC: from the wayside to the locomotive, locomotive to wayside, and

back office server to locomotive.

In PTC, “certificates” are conventional X.509 certificates similar to those used in the datacenter and on

desktop and laptop computers in use. An X.509 certificate contains identification information as well as

key material. X.509 certificates are used in PTC to implement public/private key encryption in order to

protect sensitive systems management messages used for downloading software or configuration,

uploading logs or current parameters, and even to replace existing OPKs with new ones at remote sites.

Certificates are used primarily for communication between the systems management server in the back

office and remote devices on the locomotive and at the wayside, or for communication between the SMG

of one railroad with the SMG of another railroad for interoperability.

For example, in order to send a “reboot” command requested by the back office, the command is

encrypted with the “public” key of the remote device to be rebooted, and signed for authentication using

the private key of the SMG. The receiving device uses its private key to decrypt the message, and the

public key of the SMG to check the signature to make sure the received message is authentic.

The ITC Systems Management Specification directs that the private keys of each remote device be

maintained in an “asset repository” in the back office, and defines messages to be used by the SMG to

communicate with that repository. A key server implements this asset repository in order to maintain the

security of these private keys, although using it can be implemented in other ways depending on the

railroad.

PTC is governed by 49 CFR Part 236, Subpart I – Positive Train Control Systems. Security requirements

for PTC are described in section 236.1033 in that regulation entitled “Communications and Security

requirements”. This regulation prescribes requirements for communication security using keys and

requirements for generating, distributing, and storing these keys. Each railroad must describe in its PTC

Safety Plan the methods it will use to meet these requirements. The ITC has created specifications

designed to meet or exceed these requirements.

Key Management (which is inclusive of both OPKs and X.509 certificates used for communication with

remote PTC devices) is important because keys and certificates are used extensively throughout the PTC

system – from the back office through the base radios and other communication paths to the remote

assets. They are used to authenticate messages and encrypt and decrypt messages used for both the

basic functions of the system and management of the operation of the system. It is for this reason that

key management must be considered in every phase of PTC including:

• Interoperability

• Design of wayside signaling

© AREMA 2016® 1187

• Wayside construction

• Track database/subdivision file preparation and maintenance

• Commissioning of locomotives and wayside

• Operational and FRA required testing of locomotives and waysides

• Operational monitoring of locomotives and waysides

• Maintenance of locomotives and waysides

• Execution of security related procedures such as key installation and periodic key refresh (or

“rolling”) of keys and certificates.

Challenges While a great deal of time and effort has been expended to develop the standards for interoperable PTC,

several challenges remain to fully deliver an interoperable systems management solution.

First and foremost, interoperable PTC has no precedent. While the industry as a whole has worked to

leverage commercially available solutions and standards wherever possible to achieve their respective

goals, a significant number of specifications and requirements not only needed to be defined by the

industry committees and other stakeholders, but conforming solutions must also built, tested, delivered,

and evaluated. The testing and the evaluation of the success metrics may be more complex because

requirements may be implemented differently, and discrepancies must be worked out and potentially

refined with the various industry bodies involved with the implementation of PTC. Moreover, it is possible

that the specifications will evolve over time to accommodate for “lessons learned” and other

advancements by the underlying technology in PTC as it is deployed. This implies that standards bodies

will have a continuing role to play in the evolution of PTC as it becomes part of the railroads’ daily

operations.

Another issue that potentially impacts the incorporation of systems management in the broader

discussion of delivery of a PTC system that is compliant with ITC specifications – and in particular, for

those commuter railways who rely on systems integrators – is the method for managing the potentially

evolutionary aspects of PTC. In other words, when a specific scope of work is committed by a third party

to deliver an interoperable PTC solution, and it is understood that many aspects of systems management

(and PTC in general) may evolve over time, and therefore, the potential impact to schedules and budgets

must also be accounted for as well.

Processing capabilities of the software and technologies applied for systems management also may

present constraints. For example, a railroad may wish to access and report signal aspect information from

their wayside locations for trending or other diagnostic purposes. Wayside status messages (WSM) may

be transmitted from each wayside location at a rate of approximately once every three seconds. For a

railroad with 1000 wayside locations, and WSMs being delivered asynchronously, it would be expected to

1188 © AREMA 2016®

receive 500 or more messages from the field at any given second. However, a single wayside may be

heard by more than one base radio, and base radios may hear other base radios as well. This generates

duplicate messages which can be filtered in the back office before processing and forwarding but this still

diverts processing capability and takes time. Assuming a multiple of five due to this duplication, such an

application may need to process up to 2500 messages per second. While modern computing is capable

of meeting this level of processing capability, this assessment is also based on estimated loads which

should be reevaluated as more railroads extend their PTC deployments.

There are also technological limitations which may present unique challenges to deployment of systems

management. The wired and wireless mediums used to access locomotive and wayside areas may

present constraints as to the amount of information that the railroads may be able to access without

overloading the network. In the event that a narrow band 220 MHz radio is the sole connection to a

remote asset, the amount of systems management traffic that can be supported is partly a function of the

amount of train control traffic which takes priority over all other traffic. Retransmissions of missed data,

duplicated data received from other base stations, and other events further limit the amount of bandwidth

available for other purposes.

A final challenge involves the decision to implement remote or embedded agents into the hardware

necessary for PTC. As stated above, ITCM is designed to run on SBCs based on x86 architectures. In the

ITC architecture, the WMS and LMS are designated to run the ITCM in the wayside and locomotive

environments, respectively. For a variety of technology reasons, other devices on the PTC system may

not offer a readily available ITCSM agent (ITCSM can be implemented on any processor).

For a railroad looking to leverage the information available from devices that do not support an ITCSM

embedded agent, a remote agent running on an x86 device is utilized to function as a protocol converter

between ISMP and the other chosen protocol (e.g. SNMP). In an IP connected wayside environment, the

remote agent could be implemented on a server located in the back office or elsewhere on the network.

For wayside installations which include a WMS, the remote agent can be implemented directly on the

WMS itself. This offers the additional benefit of hosting remote agents for other devices – especially

COTS devices - that may have information useful for management purposes.

Approaches and Recommendations

As interoperable PTC has not yet been fully achieved across all railroads in the United States, it is

important to characterize systems management as a process rather than a simply a product or solution.

Regardless of whether standards continue to evolve, the railroads will look to harvest the immense

amount of information made available to them. Railroads will continue their work to optimize their

operations once the PTC overlay is installed. With embedded and remote agents in place, new data

© AREMA 2016® 1189

variables will be made accessible to provide information on PTC-enforced braking events, initialization

failures, and other events that railroads desire to track, diagnose, and report. Remote agents in particular

offer the railway a method to incorporate non-ISMP enabled devices into ITCSM infrastructure, which in

turn allows the railroad to leverage a great deal of their existing infrastructure in the broader scope of

systems management.

While ITCSM has been primarily discussed in the context of PTC systems management, the industry may

look to consolidate the data provided through the ITCC infrastructure with other existing management

systems and databases in use today. The eventual analysis of this “big data” will potentially lead to new

ways to evaluate and streamline railway operations using some of the techniques employed by other

users of ITCSM:

1.) Identify and refine the amount of information that can be useful. In light of the limited bandwidth

that may be available, work to reduce the amount of information reported from agents to reduce

complexity and “data overload.” For example, pre-processing and optimization performed by

software agents deployed in the field will reduce the amount of traffic distributed over-the-air, as

compared to processing all data in the back office.

2.) Consolidate the data provided by ITCSM with other network management systems and

databases which can provide supporting information. For example, data provided by crash

hardened memory modules (CHMM), logs from the CTC system, and WIU logging information

may also provide useful clues when analyzing the root cause of a PTC braking event due to a lost

WSM.

3.) Identify the proper technologies and tools that may be useful for mining large sets of data

composed of information compiled from numerous and disparate sources. This is one of the

characteristics of the “big data.”

4.) Recognize the trends and potential contributors that may be associated with a potential failure

scenario in the field that is desired to resolve. Even with a large set of data available, the proper

algorithms and logic must be concise so as to provide the railroad with the capability to perform

root cause analysis. Complicating this approach, however, is that PTC is still a relatively new

technology and it is difficult to envision all of the potential ways in which problems can occur. For

example, the identification of the cause of a braking event may involve analysis of the entire

message flow between the locomotive and one or more wayside locations. This could potentially

involve data acquisition from dozens of devices. Yet there may not be enough “tribal knowledge”

regarding all of the ways in which messages could unintentionally flow. In other words, the user

may not yet fully understand all the ways in which the system can fail which complicates the

approach to creating a method to identify the cause of the problem in the first place.

5.) Categorize how consumers will use the data provided by systems management. The “Help Desk”

or a general support team for PTC is understood to be a likely consumer, but others may benefit

from the information provided as well. For example, equipment vendors could use the information

1190 © AREMA 2016®

to assist the railroads with troubleshooting issues in the field, while railroads could also have

useful metrics for objectively assessing the quality of the equipment they have installed in the

field. This is especially important for the railroads to be able to calculate and demonstrate they

can meet reliability benchmarks for the overall PTC system.

6.) Understand how the information that can be provided by PTC assets can be used in new ways to

reduce the costs of maintenance (specifically, dispatching of personnel for on-site diagnostic

tasks and local software upgrades).

7.) Consider the investment in out-of-band solutions to augment the bandwidth available solely

through the 220 MHz radio. This will be especially important in areas of where there will be a high

level of expected RF activity such as major metropolitan areas. The large files sizes associated

with image and firmware updates further increases this need.

While the scope of systems management should now be understood in the context of delivering an

interoperable and compliant PTC system, it should also be noted that there is a potential role for it to play

in configuration management as well. With PTC as the catalyst, equipment manufacturers have continued

to increase the amount of information that can be retrieved from their hardware using agents.

Manufacturers have included the ability to retrieve hardware and software versions from their equipment

using standard software calls. Having the ability to retrieve this information automatically – without the

need for a site visit – enables the railroad to be notified of changes to the configuration of assets

instantaneously. For example, a railroad could receive an automatic event notification that a software

CRC has changed on a WIU in the field. This event could then trigger a comparison exercise with a

software configuration management database, and if a discrepancy is detected the proper personnel can

be notified to take action. This information could potentially be of significant use to assist the railroads in

their efforts to comply with configuration management requirements in their Railroad Safety Program Plan

(RSPP).

Recommendations for Further Review

The following recommendations have been made in consideration of the input received when discussing

this paper and related topics in industry forums:

1.) Several standards and specifications related to PTC have not yet been published by the AAR.

Once these standards have been formally published, it could be useful to revisit the subject

matter discussed in this paper to assess the impact of the challenges noted herein.

2.) It may be of interest to explore the use cases associated with the use of ITCSM in an operational

PTC environment, especially one which integrates PTC systems management into a broader

network management paradigm.

© AREMA 2016® 1191

3.) A final recommendation would be to review an actual scenario in which data provided by ITCSM

infrastructure was utilized to identify a root-cause failure associated with a train initialization

failure, braking event, or other occurrence that may be associated with the operation of PTC.

List of Acronyms

AAR American Association of Railroads

ATCS Advanced Train Control System

CFR Code of Federal Regulations

CHMM Crash Hardened Memory Module

COTS Commercial Off the Shelf

CRC Cyclical Redundancy Check

CTC Centralized Traffic Control

EMP Edge Messaging Protocol

HMAC Hashed Message Authentication Code

IETF Internet Engineering Task Force

ISMP Interoperable Systems Management Protocol

ITC Interoperable Train Control

ITCC Interoperable Train Control Communications

ITCM Interoperable Train Control Messaging

ITCR Interoperable Train Control Radio

LMS Locomotive Messaging Server

MCC Meteorcomm Communications

NMS Network Management System

OPK Operational Private Keys

RFC Request for Comment

RSPP Railroad Safety Program Plan

SBC Single Board Computer

SMG Systems Management Gateway

1192 © AREMA 2016®

SNMP Simple Network Management Protocol

TMC Train Management Computer

WIU Wayside Interface Unit

WMS Wayside Messaging Server

WSM Wayside Status Messages

Acknowledgements

The author wishes to thank members of AREMA for their feedback as well as input on the next steps.

References

1.) "ITCC Overview." ITCC Overview. Federal Railroad Administration, 6 July 2012. Web. 27 May

2016. <https://www.fra.dot.gov/Elib/Document/2218>.

2.) “Communications and Security Requirements” 49 CFR 236.1033.2012

3.) “Railroad Safety Program Plan (RSPP)” 49 CFR 236.905.2012

4.) Hartong, Mark, Rajni Goel, and Duminda Wijesekera. "Positive Train Control (PTC) Failure

Modes *." Positive Train Control (PTC) Failure Modes. N.p., 25 Dec. 2010. Web. 27 May 2016.

<http://www.sciencedirect.com/science/article/pii/S1018364710001588>.

5.) “Mackenzie, Kevin. Lilee Systems. Key and Certificate Management and Key Server. San Jose,

CA: Lilee Systems, 2016. Print.”

© AREMA 2016® 1193

AR

EM

A 2

01

6 A

nn

ual

Con

fere

nce

& E

xp

osi

tion

Ap

pro

ach

es, C

hal

len

ges

, an

d

Solu

tion

s fo

r PT

C S

yst

ems

Man

agem

ent

K

evin

Nic

hte

r

1194

© A

REM

A 2

016®

AREMA 2016 Annual Conference & Exposition

Agenda

• Technology context and components • ITC Systems Management • ITC SMG and SMA • Evaluation of current technology • Security • Challenges • Approaches and recommendations • Further consideration


Technology Context and Ecosystem

Initially four Class I railroads Development of interoperable standards for PTC

Interoperable Train Control Committees

Owned by four Class I railroads Hired to implement the standards from the ITC

Meteorcomm, LLC. Consumers of

specification Implement into hardware and software

Railroads and Vendors

Data Radio Network

Messaging System

Systems Management

System

ITC Communications Network


Medium Types Bandwidth

Data Radio Network

Narrowband

220 MHz

Non-Interoperable

Broadband

Wi-Fi

4G . LTE

802.11

Satellite

Data Radio Network (Component #1)

• Narrow band radio based on Meteorcomm reference design

• Broadband utilized for large data downloads (train initialization and software updates to assets)

• Alternate paths for redundant communications and to augment coverage issues


ITCM (Component #2)

• Suite of software that is deployed in both the back office and remote environments

• Store-and-forward system which utilizes no guaranteed method of delivery

Back Office Systems

Onboard Systems

Wayside Systems

Systems Management

Messaging System

EMP

EMP

EMP

EMP

Cell, Wi-Fi, Satellite ITC Radio

IP

220 M

Hz


ITCM (Component #2)

• Runs on SBCs currently based on x86 architectures

• WMS and LMS perform a similar function.

• These Remote Areas, connect to the back office using ITCM through any available transport

• Remote Areas connect to the back office through an ITCM Application Gateway

Wayside Messaging Server

Locomotive Messaging Server

Back Office Deployment

EXTENSIONS of the messaging system


Locomotive and Wayside Messaging Server

Hardware

X86 Application

Engine

Ethernet Switch IP Router

Software

Red Hat 6.X ITC Messaging Systems Management Agents (SMA)

ITC Radio SMA WIU SMA WMS SMA SNMP SMA

TC aging Systemstestemstemeeteeeees

ITC R diImplementations of software are different across railroads

ITCM (Component #3)

© AREMA 2016®1195


ITCSM (Component #3)

• Passes information about asset health, configuration, alarms, and other data

• Provides framework for over-the-air software downloads, remote command execution, and kits.

• Subcomponents

– ITC SMG (Systems Management Gateway)

– SMA (Systems Management Agents)

-

ITC

SM

ITC SMG

SMA


Systems Management Gateway

ITC SMG • Orchestration

• Security Services

Transport

Back Office Systems / Applications

Transport

ITC Assets (Messaging System, WIUs, TMCs, ITCR, etc.)

ITC Messaging

Other Railroads


Systems Management Agents

ITC SMG

Systems Management Operational Console / GUI

ITCM

Remote Agent

ITC Asset

Embedded Agent (Asset

API)

ITC Asset

IP


ISMP

• Interoperable Systems Management Protocol

• Uses similar format as PTC status messages for identical transport

• Efficient for transport over narrowband links (220 MHz)

• Proxy via SNMP and EMP (remote agent)


Evaluations of Current Technology

• Commercial NMS systems using standard protocols are plentiful! – Already utilized by railroad IT departments

– Standardized IETF protocols

– Asset agnostic

• Vendor-specific management systems already in use by railroads – Crossing monitoring and management

– Defect detectors and HBDs

– Radio code management


Evaluations of Current Technology

• Narrowband radio code networks had limited capacity for network management functions

• Evaluation of SNMP – Right-sized for narrowband

– Limited protocol (GET / SET / TRAP)

– Desire for enhanced encryption and authentication

– Optimize for functions such as delivering software to many remote areas via a single command

1196© AREMA 2016®


Security - OPKs

• ITCSM accommodates for security through public and private keys in conjunction with X.509 security certificates

• Operational Private Keys (OPK) are used for authentication of messages sent across network

• Keys are 20 byte binary keys, and are used with the Hashed Message Authentication Code (HMAC) algorithm to authenticate each message

• Sender of a message uses the OPK and the HMAC algorithm to calculate a hash value over the content of a message

• Receiver must know the same OPK, and uses it to verify that the content of the message is correct


X.509 Certificates

• In PTC, X.509 certificates are similar to those used in datacenters and computers

• Contains identification information and key material

• Implements public/private key encryption in order to protect sensitive systems management messages

• Used for communication between the systems management server and remote devices, or for communication between the different railroads’ SMGs


Railroad A

Security

Railroad B

X.509 Certificates

Private Key

Public Key


Key Server and Management

• Key Management is inclusive of both OPKs and X.509 certificates

• Used to authenticate messages and encrypt and decrypt messages used for both the basic functions of the system and management of the operation of the system

• Security of the private keys for each remote device can be maintained in an asset repository (key server) located in the back office

• Key server generates OPKs for remote assets


Challenges

Specifications had to be created Solutions have to be developed, tested, and implemented Specifications may evolve (“lessons learned”) Scale of deployment – issues may not be prevalent on smaller deployment

No Precedence

ISMP optimization Bandwidth limitations of 220 MHz Relative priority of systems management traffic Effect of retransmissions and duplicates

Prioritization

Organizational structures Identifying stakeholders of systems management

Handling

Particularly on large, systems integrator projects Scope of network management often incomplete in specification

“Scope creep”


Approaches and Recommendations

• Understand that systems management is a PROCESS

• Further the evolution of agents to automate root cause analysis

• Leverage the investment in the PTC systems management infrastructure to integrate non-standard edge devices

• Optimize the railroad operation once PTC is installed

© AREMA 2016®1197


Analytics and Correlation

• Identify and refine data

• Consolidate the data with existing NMS

• Recognize the trends and potential contributors

• Categorize the consumers

• Understand how the information can be valued

• Consider the investment in out-of-band solutions to augment the bandwidth available solely through a narrowband 220 MHz radio

Positive Train

Control Current

Operating Environment


Configuration Management

• Manufacturers have continued to increase the amount of information that can be retrieved from their hardware agents

• Hardware and software versions retrieved using standard software calls

• This ability enables the railroad to be notified of changes to the configuration of assets instantaneously

• Potentially of significant use to assist the railroads in their efforts to comply with configuration management requirements


For Further Consideration

• Once the AAR standards have been formally published, revisit the subject matter to assess the impact of the challenges

• Explore the use cases associated with ITCSM in an operational PTC environment, especially one which integrates PTC systems management into a broader network management paradigm

• Review an actual scenario in which data provided by ITCSM infrastructure was utilized to identify a root-cause failure associated with a train initialization failure, braking event, or other occurrence that may be associated with the operation of PTC


Thank You!

Kevin Nichter [email protected]

1198© AREMA 2016®

Documents

Approaches, Challenges, and Solutions for PTC … Challenges, and Solutions for PTC Systems Management Kevin Nichter Lilee Systems [email protected] 502-438-6950 Number