Self-Optimized Scheduling of Software Updates in Positive...

24
Self-Optimized Scheduling of Software Updates in Positive Train Control Wayside Interface Units Matthew Jablonski George Mason University [email protected] December 7, 2015 Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 1 / 24

Transcript of Self-Optimized Scheduling of Software Updates in Positive...

Self-Optimized Scheduling of Software Updates inPositive Train Control Wayside Interface Units

Matthew Jablonski

George Mason University

[email protected]

December 7, 2015

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 1 / 24

Overview

1 Introduction to Positive Train Control (PTC) and Wayside InterfaceUnits (WIUs)

2 Model Predictive Control (MPC) Approach

3 Supporting Future Communication Protocols

4 ImplementationControllerWIU Internal CM Component

5 Future Work towards Implementation and Simulation

6 Conclusion

7 References

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 2 / 24

Contributions of This Paper

The goal is to determine an efficient and automated software updateprocess for WIUs, while remaining always available when needed bypassing locomotives

Identification of ”safe” time windows for update utilizing Model Predictive Control,while remaining always available to communicate with passing locomotives

Support for future communication protocols that the WIU may not have yetinstalled, but passing locomotives require

Identify the components required for a back office controller and internal to the

WIU

Minimization of time required for updating software components

Discussion of Future Work required for Building and Simulation

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 3 / 24

Background on PTC

Source: http://www.cisco.com/web/strategy/docs/trans/transportation-smart-solution-solution-overview.pdf

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 4 / 24

Background on WIUs in PTC

Interface with Train ManagementComputer (TMC):

As train approaches, TMC broadcasts

the following messages:

BeaconOnGetWIUStatus

WIU responds to each per spec, andconfigures signaling equipment

Interface with SignalingEquipment:

WIU interfaces with a set of signalingequipment, to include signal lamps,switches, and hazard detectors

Onboard Train ManagementComputer (TMC) communicatesanticipated time of crossing

WIU acts on anticipated schedule byinterfacing with connected signalingequipment

Interface with Back Office:Back office keeps locomotiveposition using GPS, can provide thisinformation

Controller used to manage WIUswith a number of knobs and settings

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 5 / 24

Real-World Complexity

One WIUs may support a signal lamp on a set of two-way tracks,surrounded by miles of openness.

Source: https://en.wikipedia.org/wiki/North American railroad signals

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 6 / 24

Real-World Complexity

Dozens of WIUs supporting signaling lamps and switching in a large railyard.

Source: https://en.wikipedia.org/wiki/Railroad switch

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 7 / 24

Approach to Identifying Scheduling Model

Focus is prevention of Timing Faults bypreventing service interruption:

WIUs are not redundant

Background downloading andprocessing of information occursOOB - does not impact service

Classification of system states:operational states, mishap states,harzardous states

High level solution:

Identify time windows that WIUmust be available to support passinglocomotives

Identify potential time windows forsoftware upgrade

Make coordinated decision as blockof geographically similar WIUs toconduct software update

Autonomic Computing Self-OptimizationMethod from [Maggio, 2012]:

Define a system model that representsthe different operational states

Determine the best approach for making

decisions; Potential approaches include:

Heuristic solutions: designed for computationalperformance or simplicityStandard control-based solutions:discrete-time linear models or discrete eventsystemsAdvanced control-based solutions: requirecomplex model that is estimated online toprovide adaptive controlModel-based machine learning solutions:define framework to learn system behavior andadjust tuning onlineModel-free machine learning solutions: doesnot require a model of the system

Provide an evaluation of the approach

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 8 / 24

Model Predictive Control (MPC)

A model of the system is available and control system keeps modelupdated

The controller selects the next actions based on the predictive controlof future system reactions

At each step, the controller chooses the next action to perform sothat the discrepency between the desired behavior and the forecastbehavior is minimized

A loose hypothesis on the model accuracy at each step are enough toensure the iterative process converges and drives the system to thedesired behavior

Provides performance guarantees and reaction to unseen

Requires a model and does not have a low overhead

Widely used for industrial plant operations and transportation

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 9 / 24

Approach to MPC for Update Scheduling

1 Each WIU predicts arrival of passing locomotive using GPS data provided fromback office to solve for the model

2 If update available, the WIU checks each future update slot for each possible

connection made by a train at a WIU in that time slot

1 If there are no possible connections in that time slot, the controller polls eachWIU in an area to vote for the time slot to conduct a software update

1 Each WIU waits until the time slot is within the required Beaconinginterval, and then votes based on whether or not it must be servicingBeacons during that slot

2 If the vote is unanimous, the back office controller schedules the update

2 If we have exceeded the prediction horizon and have not found a time slot toupdate, we reduce the size of the WIU set constrained to a smallergeographic area and return to step 2

3 When the update is complete, the success or failure is communicated to thecontroller and its database is updated

Note: Software updates are thoroughly and rigorously tested prior to selection. We assume theupdate time slot provides time for fault detection and recovery.

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 10 / 24

MPC for Rail Network

Part of a railway network from [De Schutter, 2001].

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 11 / 24

Railroad Notation and Start of Model

T : period of time schedule

tupdate : time update is available

tcomplete : time all WIUs are updated

n: number of tracks in block

W block : set of WIUs in a block

Wj : WIU at beginning of track j

(virtual) train j : physical train on track j

k: kth train to pass WIUj

xj (k): time instant train j departs WIUj

for the kth time

dj (k): scheduled departure time for train j

yj (k): earliest time instant train j could

depart WIUj for the kth time

aij (k): travel time from WIUi to WIUj foreach i ∈ Cj (k)

tminij (k) = connection time for train i to

stop at WIUi before proceeding to WIUj ;can equal 0 if no stop

Cblock : set of trains in a block

Cj (k): set of trains to which the kth

train on track j gives a connection

Chardj (k): set of trains with hard

connections, where the train on tracki and on track j are physically thesame train or if it is a very importantconnection that should beguaranteed at all costs

C softj (k): set of trains with soft

connections, represents local trainsto which the train j should giveconnection but if local traini ∈ C soft

j (k) has too large a delay,then we wait

Chardj (k) ∩ C soft

j (k) = ∅

Chardj (k) ∪ C soft

j (k) = Cj (k)

Notation adapted from [De Schutter, 2001].

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 12 / 24

Constraints (Adapted from [De Schutter, 2001])

The time schedule constraint:

xj(k) ≥ dj(k) ≥ yj(k)

Hard synchronization constraint:

xj(k), yj(k) ≥ xi (k − 1∗ij) + aij(k) + tmin

ij (k)

for each i ∈ C hardj (k)

Soft synchronization constraint:If the connection takes place,

xj(k), yj(k) ≥ xi (k − 1∗ij) + aij(k) + tmin

ij (k)

If the connection does not take place,

xj(k), yj(k) < xi (k − 1∗ij) + aij(k) + tmin

ij (k)

Note: some control variable uij(k) could be used to collapse these functions intoone:

xj(k), yj(k) ≥ xi (k − 1∗ij) + aij(k) + tmin

ij (k)− uij(k)

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 13 / 24

Predicting Arrival Time (Adapted from [De Schutter, 2001])

Early arrival time:

yj(k) = min(dj(k),

maxi∈Chard

j (k)(xi (k − 1∗ij ) + aij(k) + tmin

ij (k)),

maxi∈C soft

j (k)xi (k − 1∗ij ) + aij(k) + tmin

ij (k)− uij(k))

(1)

Worst arrival time:

xj(k) = max(dj(k),

maxi∈Chard

j (k)(xi (k − 1∗ij ) + aij(k) + tmin

ij (k)),

maxi∈C soft

j (k)xi (k − 1∗ij ) + aij(k) + tmin

ij (k)− uij(k))

(2)

Both approaches converge on actual as we get closer to present.High-level definition of an optimization problem for finding a time slot for polling (needsrefinement):

min (tcomplete − tupdate)wrt yij(k + l) (1), xij(k + l) (2), GetUpdateTime(W1−n, t, t + 1)

for all i , j , l = 0, ...,Np − 1, and t = 0, ...,Nt − 1

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 14 / 24

Controller Algorithms

Algorithm 1: GetUpdateTimeInput: Set Cblock of trains in block

Input: Set Wblock of WIUs in block

Input: tstart time update is postedInput: Nt time prediction horizonInput: Np connection prediction horizon

1 slot ← −1;

2 for t ∈ tstart to tstart + Nt − 1 do

3 if IsUpdateOK(Cblock (k+l), Wblock , Np , t, t+1)== 1

and PollWIUs(Wblock , t) == size(Wblock ) then4 slot ← t;5 break;6 end7 end8 if slot 6= −1 then

9 return (Wblock , slot);10 end

11 return GetUpdateTime (Cblock , Wblocki∈{1,size(Wblock )/2−1}

) +

GetUpdateTime (Cblock , Wblocki∈{size(Wblock )/2,n}

);

Algorithm 2: IsUpdateOKInput: Set C block of trains in blockInput: Set W block of WIUs in blockInput: Np connection prediction horizonInput: tstart time of proposed update startInput: tend time of proposed update end

1 updateWIUOK ← 0; //tally for guaranteed available slot2 updateTrainOK ← 0; //all trains verified for WIU3 for l ∈ 0 to Np − 1 do4 updateWIUOK ← 0;5 for j ∈ W block do6 updateTrainOK ← 0;7 for i ∈ C block

jdo

8 if i.yj (k + l) 6= −1 and i.xj (k + l) 6= −1 then9 y ← i.yj (k + l);

10 x ← i.xj (k + l);11 if ((y < tstart ) and (x < tstart )) or ((y > tend )

and (x > tend )) then12 updateTrainOK ← updateTrainOK + 1;13 else14 break;15 end16 end17 end18 if updateTrainOK == size(C block ) then19 updateWIUOK ← updateWIUOK + 1;20 else21 break;22 end23 end24 if updateWIUOK 6= size(W block ) then25 return 0;26 end27 end28 return 1;

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 15 / 24

WIU Voting Algorithms

Controller Algorithm:

Algorithm 3: PollWIUs

Input: Set W block of WIUs in blockInput: tstart time of proposed update

start1 tally ← 0;

2 for j ∈W block do3 tally ← tally + j .WIUVote(tstart);4 end5 return tally ;

WIU Algorithm:

Algorithm 4: WIUVoteInput: tstart time of proposed update start

1 tnow ← time();2 while tstart − tnow <BeaconEndTime do3 sleep(1sec);4 tnow ← time();

5 end6 while tstart − tnow ≥ 0 do7 if BeaconEndTime > tstart then8 return 0;9 else if BeaconTTL == 0 and

UpdateReady == 1 then10 return 1;11 end12 sleep(1sec);13 tnow ← time();

14 end15 return 0;

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 16 / 24

Comm. Protocol Versioning Problem and Solution

Additional Problem: If finding an update window takes too long oroccurs too quickly for the WIUs, and a locomotive traverses the rail usinga different PTC communications protocol, communications in thesecircumstances must be handledSolution: Ajmani, Liskov, and Shrira describe Simulation Objects in[Ajmani, 2003]

From [Ajmani, 2003].

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 17 / 24

Simulation Objects (SOs)

SOs support communication protocols in both direc-tions (past and future) that can be chained togetherto support multiple versions in both directions

SOs are wrappers - they delegate most of their behaviorto other objects

SOs are slower to implement than full versions, as theyare simulations

When Oi is updated to Oi+1, a mapping function MFi+1 maps the abstract state of Oi toOi+1 and some functionality or data may be lost

The MFi+1 separates Oi ’s functionality into an independent part Ii and a dependent partDi

The MFi+1 transition ignores Ii , but transitions Di to Di+1

Calls to SO i+1f that modify Di+1 must be implemented by calling methods of Oi

Calls to SO i+1f that use Di+1 but cannot be implemented by calling methods of Oi must

fail

[Ajmani, 2003] also describes necessary failure states and formal correctness criteria forthis method

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 18 / 24

Back Office Controller

Components Include:

Administrative WebInterface

Back EndSoftware UpdateManagement

Update AdvertisementTime Slot Search

Train Tracking EngineTrain Modeling EnginePolling Engine

Database Requirements:

Train Location DatabaseWIU Software VersioningDatabase

From Kephart, Jeffrey and Chess, David. The Vision ofAutonomic Computing. IEEE Computing Society. 2003

High-level update server design from [Ajmani, 2003].

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 19 / 24

WIU Internal Update Component

From [Ajmani, 2003].

Figure shows relationship between controller and WIUs

WIU Upgrade Manager includes:Software Update DownloadAccess to PTC beaconing statusAbility to conduct WIUVoteFault Identification and Recovery (further research needed)

WIU internal execution environment should be designed so that component

updates are minimalized and piecemealReal-time system design best practicesFurther research needed to minimalize update timeFurther research needed for Fault Detection and Correction

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 20 / 24

MPC Optimization and Future Work Needed

Obvious: the algorithms presented in the MPC discussion need to befurther refined into the model

The controller algorithm represents a ”brute force” search, so we needto refine the search methodology to optimize the cost

Determine if it is possible to use our update controller to manage thecontrol variable for the soft synchronization constraint

Refine and define a cost function based on tcomplete and varianceswhen the scheduled departure times slip

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 21 / 24

Additional Discussion on Future Work

Address the issues discussed wrt. the MPC approach

Refine the optimization problem

Determine a more efficient way to search for tcomplete − tupdateObtain simulation softwareWithin the simulation, implement the Controller and WIUfunctionality

Evaluate the search method with voting against the search methodwithout voting, and randomized time slot selection with votingDetermine if one approach is significantly betterDetermine at what point the system is too saturated to support WIUsoftware updates and generate a model

Within the simulation, add different protocol versions for the WIUsand trains

Evaluate the ability to support future and past comm. protocols

Identify method for minimalizing updated software components tolimit downtime

Identify method for fault detection and recovery

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 22 / 24

Conclusion

We believe automated software update scheduling of WIUs is aproblem that is novel in research.

We presented an approach to upgrade WIUs that:

Provides a ”starter” model to allow the software update controller toanticipate the hard and soft time constraint associated with a passinglocomotiveProvides a centralized voting method to ensure that locomotives arenot geographically nearby during the proposed software update timeslotIncludes a model for upgrading the WIU’s communications protocol tosupport short-term requirements prior to an identified upgrade windowIncludes a design for a back-office software update controller andinternal WIU controllerProvides next steps for future research and simulation

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 23 / 24

References

Maggio, M. et. al. (2012)Comparison of Decision Making Strategies for Self-Optimization in Autonomic ComputingSystemsACM Trans. Auton. Adapt. Syst..

Sha, Lui and Rajkumar, R. and Gagliardi, M. (1996)Evolving Dependable Real-Time SystemsProceedings of the 1996 IEEE Aerospace Applications Conference.

De Schutter, B. and van den Boom, T. (2001)Model Predictive Control for Railway NetworksProceedings of the 2001 IEEE/ASME International Conference on Advanced IntelligentMechatronics (AIM’01).

Ajmani, Sameer and Liskov, Barbara and Shrira, Liuba. (2003)Scheduling and Simulation: How to Upgrade Distributed SystemsProceedings of the 9th Conference on Hot Topics in Operating Systems - Volume 9).

Association of American Railroads. (2003)Interoperable Train Control Wayside Interface Unit RequirementsRailway Electronics AAR S-9220-0200.

Matthew Jablonski (GMU) Scheduling WIU Software Updates December 7, 2015 24 / 24