Transcription
Business Aligned IT Strategy System OperatorData Architecture ReferenceModelV1.01
Executive SummarySystem Operator exists to plan changes to the GB railway ‘system’ to balance the needsof passengers and freight customers and support economic growth. Its vision is tobecome the recognised expert; trusted by decision makers to plan the GB railway, and itsprimary output is the national timetable.It is not realistic to expect industry timetable planners to produce robust and resilienttimetables in the timescales set out in the network code using the same manualtechniques applied today e.g. manual data entry, visually reviewing train graphs, crossreferencing against paper-based reference documents, manual validation of junctionsusing sectional appendix/unstructured TPR datasets/unstructured WON etc., manual stockand crew diagrams.It has been observed that the level of data maturity is low. There is not a commonindustry data platform, taxonomy or full industry data standard in place. Governedsharing of and access to data is too inconsistent to enable systemisation, and automationof activities associated with timetable production. Furthermore, there is no mandatoryexchange format of the data between NR and TOC/FOCs to ensure it is aligned.There are many cultural, process and application issues that account for the currentsituation but at the root of all of these is the use and quality of the data that underpinsall our activities. This data architecture reference model sets out our understanding of thecurrent and future data needs, culminating in the Problem Statements and Target Statesections which provide a series of options to consider and a forward view of change acrossCP6. The problem statements are extensive, but have been summarised under thefollowing themes:The Culture of Data: A transformational change in how data is managed and governedrequires a culture shift within the industry. Addressing quality issues on the core datasetsthat the industry use requires a clear vision, committed leadership and the right level ofresourcing to succeed.Doing Things Differently: Throughout the timetable development process, there areopportunities to change to better support the sharing and exchange of information at apeople and system level. Without changing the way we do things; improved data qualitywill only deliver some of the potential benefits.Embracing Data Ownership: Data ownership is currently very immature. Linked closelywith the change in culture, a shift is needed to make people take data governanceseriously. If our data is key to developing the timetable, then we must put as much effortinto managing it through its full lifecycle as we do the timetable itself.Better Data, Better Timetable: Data quality issues exist throughout our data landscape.Much of this is managed through skilled teams manually correcting or interpreting poordata sets to make sense of them. Addressing the underlying quality issues is fundamentalto improving the quality of the timetable.Unifying Data Platform: Investing in data governance and improving data quality willhave a great impact, however the full benefit will only become apparent when it is2
accessible by all parties across the industry. A key output of any data improvementprogramme will be to put in place an industry data sharing platform that meets the needof all parties to access trusted, assured and version-controlled data sets.3
Document PurposeThis document focusses on the data that underpins the core timetable planning processesthat are used when developing a new working timetable, managing timetable variations,and the transitional activities required to operate the daily timetable.This document provides a line of sight from our current data architecture through to aseries of proposals for data improvement activities that, if implemented will directlyimprove the quality of the published timetable. These proposals will then be used as aframework to develop the mandate of the Data Improvement CP6 Programme.This document starts with the principal timetable planning Process Elaboration andidentifies the data that underpins them. These data sets are then documented in a DataEntity As-Is Capture to understand their content, structure and key characteristics.Through interviews with internal and external planning teams, personal statements andby looking at available external reports an assessment of the Data Quality Assessmentsof the data is made. Finally, this is all brought together in a set of Problem Statementswhich describe each identified issue, its impact and potential options. The documentconcludes with a Target State view that describes an outline for change across the CP6timeframe.The audience for this document is primarily the timetable planning community and assuch the document uses many terms that are specific to the processes used by thiscommunity. Whilst the document expands the commonly used acronyms and attempts todescribe the environment and processes in terms that will generally be understood, it doesnot attempt to provide a glossary of all terms used.4
Current Data ArchitectureTo examine the current data architecture the core processes that are involved in thetimetable development process have been examined and their data needs assessed. Toensure alignment with other architectural views across Network Rail the data will beexamined at both the logical and physical levels and will make use of corporate levelmodels where available.The following timetable planning process area have been examined: Working Timetable Process - Long Term PlanningCovers the processes involved with the initial creation of the new workingtimetable and the processing of operator bids up till the publication of theprincipal or subsidiary working timetable (WTT)Timetable Variations - Short Term Planning and Rolling Spot BidsCovers the processes involved when dealing with the rolling short term planningchanges which amend the working timetable plan and culminates with the dailypublication of the CIF timetable files.Planning Rules ManagementCovers the management and ongoing maintenance of the timetable planningrules that are used to underpin the development of the timetable.Timetable Geography ManagementCovers the management and maintenance of the base geography model thatresides within the timetable planning tools.The subsequent sections provide a high-level view of these planning areas in terms oftheir key business processes. Where more detailed process descriptions exist, they will beidentified and referenced. Each process is then looked at in terms of the data thatunderpins it, which forms the basis for the subsequent data analysis. For readersunfamiliar with process diagrams, the following key describes the shapes that are usedwithin the process diagrams.5
The following diagram provides an overview of the process areas that have been assessed and uses three distinct notations for itstimelines as follows: D-N : Used to describe a fixed week offset from the publication date of the principal or subsidiary timetable. As such these arefixed calendar dates and set out in the planning calendar published at D-73 (i.e. 73 weeks before the publication date of the NewWTT). TWN : Used to specify a weekly offset from any given day. As such this notation is used to describe the repeating activities thattake place in the run up to the daily timetable being published. When using this notation, it is assumed that the week start on aMonday. T-N : Used in the final phases of the daily timetable publication to describe the days offset prior to the publication date which isconsidered T-0. Note that positive numbers can also be used to indicate days after publication.6
New Working Timetable Process – Long Term PlanningOverviewThis process area covers the steps involved with the creation of a new principal orsubsidiary timetable. This process area starts with the receipt of the Route NetworkChange documents and completes with the publication of the New Working Timetable(WTT).Process ElaborationThe following processes are simplified versions of the formal WTT planning process asdescribed within the “WTT Process” (Ref NR5) and are aligned to the Long Term Planningprocess as produced within the WSM – Industry Planning Alignment project (Ref NR13) .The following processes have been assessed: New Working Timetable – Prior Working Timetable ProductionThis process starts with the setting out of the timetable calendar of events at D-67and examines the activities and data needed to generate the Prior WorkingTimetable (PWTT) and Strategic capacity statement (SCS) at D-45 based on arollover of the previous year’s primary or subsidiary timetable, plus considerationof any significant infrastructure or service changes.New Working Timetable – Risk AssessmentThis process starts at D-40 and covers the activities required to identify significantrisks associated with new/amended timetable requirements.New Working Timetable – Resource PlanningCovering the period between D-59 and D-39 this process deals with the resourceplanning needs of the capacity planning department to accurately assess and planfor the timetable planning activities.New Working Timetable - Process Access Requests (Priority Date NotificationStatements)Following the publication of the Prior Working Timetable, timetable stakeholderscan submit Access Requests for new, changed or unrequired paths. Access requests(PDNSs) received prior to the Priority Date D-40 are given priority in thedevelopment of the New Working Timetable.New Working Timetable – Appeals ProcessCovers the process by which objections to the proposed working timetable areraised and resolved.New Working Timetable – Publish TimetableCovers the activities followed to formally publish the newly developed workingtimetable.Note that the processes include activities undertaken by the Timetable Participants as it iscritical to this exercise to understand the whole planning systems data needs. In order toaccommodate the different approaches used by train operator planning teams theseactivities present a generic view and may not hold true for all train operators.7
New Working Timetable – Prior Working Timetable Production8
The following data underpins or is manipulated by this process.Data Entity ocess ChangesModelTimetableOptionsCollate InfChangesAssessNOSC234567Bulk RRCU9Indicative rule, timing loadsand candidate paths changesare identified at this stage.The collective set of NetworkChange Notices received uptill this point.Modelling timetable extractsare developed at this stage.For this analysis the NOSC isconsidered as an indicativeTimetable Bid.Operator may develop theirown PWTT to allow earlydevelopment of PDNSsubmissions.
Data Entity anningRulesNetworkGeographyTimetableProcess y, the PWTT week isthe last week of the precedingWTT, however the route ortimetable participant canrequest that another week isselected.Includes an intensive manualactivity to re-date pathswhich can only be done inblocks of matching 'days run'patterns. Typically done overthe weekend using multipleTPS workstations.A governance activity toensure that new TPRs,Geography and Rolled Overpaths are all in place.Creation of the PWTT andSCSOperator needs to comparethe NR PWTT with any localworking version and identifychanges to any pre-preparedPDNS submission packs.
New Working Timetable – Rollover Data Checks11
The following data underpins or is manipulated by this rrectLTPsConfirmRolloverCompleteData Entity (Create/Read/Update/Delete)TimetableTimetable NetworkPlanning GeographyRulesNotesR--R--Documents any known issues with the PWTT thatcould not be readily addressed.RRRMinimal checks undertaken against the newPWTT to remove TPS 'red flag' errors. Reality isthat some Timetable Participants will simplyignore the PWTT and re-bid a full timetable at D40. No requirement on Timetable Participants touse the PWTT as a baseline plan. Network Railwould though like operators to take the PWTT anduse this as the basis for their bids at D-40.U-----12
New Working Timetable – Risk Assessment13
The following data underpins or is manipulated by this process.Data Entity(Create/Read/Update/Delete)PDNSTimetable DNSReviewSignificantTT onsR-R--CCUD-R-CRUDCRUDNotesThe remaining steps within this process involve thecapturing and tracking of significant risks. This data ismanaged within meeting minutes and spreadsheets andhas no formal definition.14
New Working Timetable – Resource Planning15
The following data underpins or is manipulated by this process.Data Entity(Create/Read/Update/Delete)NOSCPDNSStaffing PlanProcess Process step#0Start1CompleteNOSC2Assess NOSC3Optioneering45678Pre TCRAGPrioritisationStaffing PlanReviewPDNSStaffing PlanC--RR------RCU--UNotesFor significant anticipatedtimetabling change a degree ofoptioneering/modelling may berequired to better understandthe new timetabled servicesand scale of change that willneed to be managed.These process steps allcontribute to the developmentof the forward staffing plan.The plan as such is maintainedthrough a combination ofdocument and spreadsheetbased records and has noformal definition.16
New Working Timetable – Appeals17
The following data underpins or is manipulated by this process.Data AppealC-C-RC-R-R-CNotesThe Appeals and Decisionentity are free formatdocument based whichneed to provide theevidence for the appealand decision process.Given the nature of theseentities they will not bemodelled in thesubsequent sections of thisdocument.18
New Working Timetable – Process Access Requests19
The following data underpins or is manipulated by this process.Data Entity onProcess ualPDNSPDNS UIDDataChecksResolveUID ErrorsPDNS TPSData essUpdatesSection is is a compliance check against thetimetable process rather than a check of thetimetable itself.--RR-C---Feeds into Timetable Planning Rule U-234a4b5a5b67aPDNS PEX files do not go through the DSEAprocess. Loaded into TPS for initial view of 'redcross' validation errors.For electronic imports these checks occurwithin the TPS product in parallel to other ‘redcross’ TPS Data checks.Note that this is done against the EAS ratherthan from TPS data.20
7b89RevisionsProcessUpdatesTrainValidationPublish OfferR--U-------RRR--R---------CNew Working Timetable – Publish Timetable21Manual checks undertaken by planners usingTPS and TPR. Some route planning teams alsouse ATTUne.
22
The following data underpins or is manipulated by this process.Process#Process step01StartAmendPublication ListsRefreshOfferPublishTimetable23Data Entity (Create/Read/Update/Delete)TimetableWorking Path Offer TimetableDistribution PathListCRUD----RCU-RR-CNotesCovers the formal publication of theNRT and WTT timetables.23
Timetable Variation – Short Term PlanningOverviewThis process area covers all changes to the working timetable after it has been publishedfrom the Long Term Timetable process. Timetable variations can be instigated byNetwork Rail because of infrastructure maintenance restrictions being required, or froman operator if they need to make operational changes to their services.Process ElaborationThe following processes are simplified versions of the Timetable Variation processes asdescribed within the “Network Rail Variation Requests TW12” (Ref NR6) and “STPPlanning” (Ref NR7).The following processes have been assessed: Working Timetable – Operator VariationOperator variations (or spot bids as they are commonly called) for the principal orsubsidiary timetable can be received at any time following its publication. Typicalreasons for operators to raise timetable variations are:o Changes to cater for major sporting events,o Delivery of driver training,o Late planned stock moves,o Late planned stock/crew changesDriven by the pressures on operators to utilise their resources as efficiently aspossible, operators regularly finalise their plan stock and crew plans within the TW4/TW-3 window prior to the train service operating. As such it is not uncommon foroperators to submit between 1000 and 2000 timetable variations a week. It wasalso noted that most operators plan their changes locally on the Monday/Tuesdayand submit their changes to Network Rail from Wednesday onwards which createsa significant workload in the latter part of the week.The timetable amendment teams have strict timeframes within which they mustrespond to the timetable participant (Operator) with a decision to accept or rejectthe variation request. Working Timetable – Network Rail VariationFollowing the publication of the working timetable, changes may be required toaccommodate maintenance access requests to the network. This process takes theaccess requests, determines the impact to the timetable and engages thetimetable participants to determine a revised train service. This can result inbetween 5,000 to 10,000 path changes for a high-volume Timetable Participant. Working Timetable – Weekly Operational Handover ChecksTo ensure that the timetable can be operated reliably on the network theamended schedule planning teams undertake some additional route specificactivities which have been examined.o Automated Route Setting (ARS). For those ARS systems that Network Railplanners have access to compatibility checks are undertaken to ensure that24
they have an up to date and accurate view of the timetable and relatedtimetabling reference data.o Platform occupation checks to ensure that the timetable matches theplanned platform occupancy for high value stations.25
Working Timetable – Operator Variation26
The following data underpins or is manipulated by this process.Process#Process stepBidPathCandidatePathData Entity (Create/Read/Update/Delete)UIDTimetable otesTimetableOffer0Start-------1aImportManual itiseWorkUID DataChecksTPS DataChecksSection -R-RCRUD-3456Train Operator Variation Request (Paperor PEX file)DB cargo are the largest operator thatstill sends paper-based bids, althoughother Freight operators still use them.Operators using electronic bids utilise thePEX file format which is loaded throughthe DSEA service. Noted that there is noalternative process for bids with no timingimpacts.Varies by route based on known criticalstations, junctions or capacity issues.When overloaded, less critical paths willnot be validated.Verified against the Periodic OperatingNotices rather than from TPS.For the purposes of this simplified processthe transition from a candidate path to aworking path is considered to take placeonce the last validation activities havebeen undertaken.27
Process#Process stepBidPathCandidatePathData Entity (Create/Read/Update/Delete)UIDTimetable otesTimetableOffer7aPublishPaper he publication of the Path Offer is basedon the new working paths followingvalidation activities.Operators using Voyager Plan are notable to consume electronic offers so needto manually import them.28
Working Timetable – Network Rail Variation29
The following data underpins or is manipulated by this StartDistributeRestrictionNoticeData Entity (Create/Read/Update/Delete)Bid PathNetworkTimetable Offer PathGeographPlanningyRulesC-AssessNotify ifRevisedAccess isRequiredRe-planServicesRR-RAccept --CRR---R--R--R--R------CCovered in this document by the Scheduled Accessdata entity but may not be recorded yet in thepossessions planning systems.Important that operator’s planning system’s viewof the world matches Network Rail’s. Mostoperators use electronic PEX files to send inchanges but some smaller ones still using paperbids (e.g. Tyne and Weir Metro, Sheffield SuperTram)Dependent upon time frame it may not be possibleto re-visit the offer back out to the operator.He TW-12 timetable is a critical milestone as itforms the basis of the informed traveller processand is the timetable used by the ticketing systems.30
Working Timetable – Operational Handover31
The following data underpins or is manipulated by this S TTChecksData Entity metableGeographPathWorking(Applicablye erredAssociationsR---C23NotesSystem Operator can only access some ARSsystems (e.g. no access to Hitachi) so these checksare not done everywhere. Note that in times ofwork overload some of these checks may not getmade.Where access to an ARS system is available andtime permits, System Operator can correct the ARSview to match the timetable.Only undertaken at this late stage for a few criticalstation locations (e.g. Waterloo). ACWN receivedon a Thursday for Saturday/Sunday operationsshort term bids.Station Working reports are produced daily for 8complex stations. Note that the format of eachreport varies but the contents is largely the same.The daily TT published by 22:00 forms the basis forthe performance regime.WACI and POINTA are to such inference systems.System Operator maintain the data for WACI butPOINTA has no current business owner and ismaintained by the supplier for the route.32
lSystems8Deconflict-Data Entity metableGeographPathWorking(Applicablye TT)---RUNotesIECC, ARS, TRUST and TOPS are principal currentsystems. New TMS solutions such as Luminate(Western), Aramis (Romford, Cardiff), Hitachi(Thameslink) and Siemens (Crossrail) are also used.Local changes to timings will be determined withinthe operational systems to allow for best use of thenetwork.33
Planning Rules ManagementOverviewThis process area covers the maintenance of the timetable planning rules that are usedduring the development of the timetable. Timetable planning rules cover the followingdistinct data areas: Electrificationo Electrification Limitso Electrification Supply RestrictionsRolling Stock Restrictionso Locomotive Route Availabilityo Passenger Stock Restrictionso Freight Wagon Restrictionso Freight Train Load Limitso Freight Train Length Limitso Engineer’s Train RestrictionsRunning Times, Margins and Allowanceso Sectional Running Timeso Headwayso Junction Marginso Station Planning Ruleso Platform Lengthso Timing AllowancesProcess ElaborationThe planning rules management process area covers the activities that are required ofCapacity Planning to produce and publish the formal Timetable Planning Rules (TPRs)publication in line with Network Code part D requirements, and are described in detailwithin the “Timetable Planning Rules Production and Publication Process” document (RefNR1)The following specific processes have been considered and will be elaborated below: Timetable Planning Rules publicationVersion 1 and Version 2 of the TPRs apply to timetable year commencing atPrincipal Timetable change (December Timetable) and may contain majorchanges to the Rules. Version 1 of the TPR’s is published as the 'Draft Rules', at D59. Version 2 -incorporate operator feedback of the ‘Draft Rules’ and is publishedas the 'Final Rules' at D-44.Version 3 and Version 4 of the TPRs apply to Subsidiary Timetable change (MayTimetable). Version 3 and Version 4 of the TPRs may only contain minor changesand changes that were not foreseeable during the production of Version 1 andVersion 2 of TPRs.34
Timetable Planning Rules alterationsNetwork rail may adjust the TPR between D-44 and D-26 where it considersnecessary to optimise the Timetable. PublicationsPublications in this context covers the following specific artefacts:- The National Sectional Appendix (NESA) which contains a detailed view ofthe operational network and contains subsets of the timetable planningrules as described within the Timetable Planning Rules publication. NESA iscontinually updated to reflect the current engineering view of the networkand is available on the external Network Rail website as route-based PDFs.Alternatively, people may register for access to the National Electronicsectional Appendix system (NESA), which requires a Network Rail portalsign-on.- The Periodic Operating Notice (PON) which provides a periodic snapshotview of any planned access restrictions (for example possessions and speedrestrictions) that will impact operational services.- The weekly operating notice (WON) provides a weekly snapshot view of anyplanned access restrictions (for example possessions and speed restrictions)that will impact operational services.These documents are widely distributed and accessible and provide the TimetableParticipants, with their view of our network, its capabilities and planned accessrestrictions. Freight Data Load Book publicationThe freight data load books contain detailed information about freight load andclearance limits and constitute a subset of the Timetable planning rules asdescribed within the Timetable Planning Rules publication.35
Timetable Planning Rules Publication36
The following data underpins or is manipulated by this ate3456789101112CRTPRLogCData Entity (Create/Read/Update/Delete)SRTTiming Headway Junction RRRRRRRRRRRRRRRRRRCUD-CUDCUDCUDCUDIt is noted that the TPR Log is notconsistently used.TPR Publication V1 follows this.TPR Publication V2Changes are reflected within officialrepositories (BPLAN, ADB)37
Timetable Planning Rules Alteration38
The following data underpins or is manipulated by this TPRLogData Entity (Create/Read/Update/Delete)SRTTiming Headway RRRRRRRRURRRRRRUURRRRRRR-CUD-CUDCUDCUDCUDIt is noted that the TPR Log is not consistentlyused.Updates recorded in draft form for finalagreement.Changes are reflected within official repositories(BPLAN, ADB)39
Publications40
The following data underpins or is manipulated by this process.Network ChangeData Entity (Create/Read/Update/Delete)Scheduled AccessElectrification RouteRouteSupplyAvailability ClearanceRestrictionsNotesLine ofRoutePlatformLimitsProcess#0Process stepStart------1MaintenancePlanningDraft WONReviewFinal WONReviewPublish RCUDRRRCRCUDRRRCRCUDRRR23456741Note that there isalso a PeriodicOperating Noticewhich is publishevery 4 weeks topresent the upcoming 4 weeksplanned work.WON PublishedNESA Published
Freight Data Load Book publicationWhilst the Freight Data Load Books are formal Network Rail artefacts our initial investigation has found that these are maintained bythe routes and there is no defined process in place that is followed. These books (spreadsheets) are not publicly available and access tothem is provided on a request basis. An initial assessment of these books has found that some routes have maintained them whilstothers are several years old. The snapshot image below provides the last modified dates as of 09/01/2019 and as it can be seen themost out of data instance (Kent, Sussex and Wessex) has not updated its books since Jan 2013.The following data underpins or is manipulated within these artefacts.Data Entity(Create/Read/Update/Delete)Freight Train Load Freight TrainLimitsLength 2
Timetable Geography ManagementOverviewThis process area covers the maintenance of the supporting data needed to utilise thetimetable planning tooling used by the System Operator. This process area covers thefollowing specific data areas: Train identifiersTimetable geographyo Station identifierso Timing point identifierso Network Linkso Route Codes,o Trains Service Codes,o Track Codes,o Timing LoadsInfrastructure geography changeso TPS edge/section network model,o Nodes,o Blocks,o Signals,o Tracks,o Platform,o Network Features (Level Crossings, Bridges, Tunnels etc)These areas will be broken down further under that process elabora
Embracing Data Ownership: Data ownership is currently very immature. Linked closely with the change in culture, a shift is needed to make people take data governance seriously. If our data is key to developing the timetable, then we must put as much effort into managing it through its full lifecycle as we do the timetable itself.
