9459 67062 A IOP Ticket Logic Base Data - … · IOP Ticket Logic Base Data ... This data controls which ITSO CMDs will be accepted at a station. ... 7 or 8. FTA-FP039-9459-67062

Copyright © 2011 Department for Transport and Transport for London. All rights reserved. This information is confidential.Page 1 of 33

AFC House, Honeycrock Lane,Salfords, Surrey

RH1 5LA

Tel: +44(0) 1737 782200Fax: +44(0) 1737 789759

DfT – IOP Business Rules Phase 3

IOP Ticket Logic Base Data

Document Number: 9459-67062

Revision: A

Date: 22 Mar 2011

UNCONTROLLED PRINT Unless Release Approval Signature present below

Date of Release Release Authority Released by Document ControlECN [9459-90069]

FTA-FP039-9459-67062 REV A

Doc. No. 9459-67062 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Base Data


0. PRELIMINARIES0.1 PUBLISHED BY

Cubic Transportation Systems Limited, AFC House, Honeycrock Lane, Salfords, Surrey, RH1 5LATel: +44 (0) 1737 782200, Fax +44 (0) 1737 789759

0.2 COPYRIGHT

Copyright © 2011 Department for Transport and Transport for London. All rights reserved. This information isconfidential. You may not reproduce, adapt or disclose this information, or any part of this information, forany purpose without written permission from either the DfT or TfL. The DfT and TfL makes no warranties orrepresentations, and expressly disclaim all liability, concerning this information.

0.3 DOCUMENT HISTORY

Issued at Revision A, on 23-03-11, by R.W. Easterby under ECN 9459-90069

Refer to the applicable ECN (Engineering Change Note) for approval authorities, signatures and documentdistribution.

0.4 CHANGE MARKING

Where implemented, changes, relating to the content only, since the latest revision of this document havebeen marked by a vertical line in the left or right hand margin adjacent to the change.

0.5 EFFECTIVE PAGES

MainDocument:

33

AttachedSheets

0

TotalPages

33

0.6 BIBLIOGRAPHY

0.6.1 Referenced Documents

[1] 9459 67061 DfT - IOP Business Rules Phase 3 IOP Ticket Logic Tests

[2] 9459 11001 RSPS3002 V01-02-A ATOC ITSO in National Rail – Specification

[3] ITSO Specification V2.1.4

[4] ITSO Certification and Testing Rail POST Equipment V3

0.7 GLOSSARY

ATOC Association of Train Operating CompaniesCRC Cyclic Redundancy CheckCTSL Cubic Transportation Systems LimitedDfT Department for TransportIIN ISTO Issuer NumberIOP ITSO on PrestigeITSO An organisation that has specified a UK Smartcard standard for transport useOID (ITSO) Operator Identification numberTfL Transport for LondonTOC Train Operating Company

0.8 OUTSTANDING ITEMS

None.

FTA-FP039-9459-67062 REV A



TABLE OF CONTENTS

0. PRELIMINARIES 20.1 PUBLISHED BY 20.2 COPYRIGHT 20.3 DOCUMENT HISTORY 20.4 CHANGE MARKING 20.5 EFFECTIVE PAGES 20.6 BIBLIOGRAPHY 2

0.6.1 Referenced Documents 20.7 GLOSSARY 20.8 OUTSTANDING ITEMS 2

1. INTRODUCTION 61.1 REQUIREMENT AND SCOPE 61.2 NOTE ON NLCS 61.3 NOTE ON MAXIMUM JOURNEY TIME 61.4 UTS DATE 6

2. CMD WHITELIST 62.1 CMD 62.2 WEFDATE 72.3 WEUDATE 7

3. ITSO PRODUCT INFORMATION 73.1 IIN 73.2 OID 73.3 TYP 73.4 FORMAT REVISION 83.5 PTYP 83.6 FTOT 83.7 TIME RESTRICTIONS 83.8 PRIORITY 83.9 VALID ON DAY 93.10 TICKET FLAGS 93.11 PRODUCT TYPE 93.12 LU REPORTING 93.13 WEFDATE 103.14 WEUDATE 10

4. STATION CONFIGURATION 104.1 PASSBACK TIME/DISABLE 104.2 ZIGZAG TIME/DISABLE 104.3 STATION NLC 114.4 “HERE” ZONES 114.5 ALTERNATIVE “HERE” NLCS 114.6 “HERE” ROUTES 124.7 REJECT ROUTES 124.8 OSI PARTNERS 124.9 LOCAL OSI TIME 124.10 CONTINUATION ENTRY TIME 134.11 ENTRY RESTRICTION EASEMENT TIME 134.12 MINIMUM JOURNEY TIME 134.13 LUL STATION NUMBER 134.14 PERFORM IPE SEAL CHECK ON ENTRY 13

FTA-FP039-9459-67062 REV A



4.15 RAIL-TRAM INTERCHANGE 134.16 RAIL-TRAM CHECK IN TIME 144.17 TRAM “HERE” LOCATIONS 144.18 TRAM “HERE” ZONES 144.19 TRAM “HERE” ROUTES 14

5. ALIAS STATION CONFIGURATION 155.1 NUMBER OF ALIAS STATIONS 155.2 ALIAS NLC 155.3 ALIAS “HERE” ZONES 155.4 ALIAS ALTERNATIVE “HERE” NLCS 165.5 ALIAS “HERE” ROUTES 165.6 ALIAS OSI PARTNERS 16

6. ITSO ALIAS CONTROL 16

7. RELATIVE LOCATIONS 177.1 NLC TO LOCATION GROUP MAPPING 177.2 LOCATION GROUP DETAILS 177.3 LOCATION GROUP/ZONE ACCEPTABILITY 17

8. GLOBAL SETTINGS 188.1 ITSO END OF DAY TIME 188.2 ITSO TRAVELCARD END OF DAY TIME 188.3 INTERCHANGE STATIONS LIST 198.4 CONTINUATION EXIT TIME 198.5 ZONAL NLC TO ZONE MAPPING 198.6 BOUNDARY NLC TO ZONE MAPPING 198.7 NLC TO ZONE MAPPING 208.8 ROUTE TO ZONE MAPPING 218.9 MULTI-PRESENTATION TIME 218.10 TRAM TO RAIL INTERCHANGE TIME 218.11 RAIL TO TRAM INTERCHANGE TIME 218.12 TEST OIDS 21

9. TIME RESTRICTIONS 229.1 TIME RESTRICTIONS 22

10. ATOC RESTRICTIONS MAPPING 2310.1 ATOC RESTRICTION CODE 2310.2 TIME RESTRICTION CODE 2310.3 WEFDATE 2310.4 WEUDATE 23

11. IPE TIME RESTRICTIONS MAPPING 2311.1 TICKET VALIDITYCODE 2411.2 TIME RESTRICTION CODE 2411.3 WEFDATE 2411.4 WEUDATE 24

12. TICKET LOGIC PRIORITY CONTROL 2412.1 TICKET LOGIC PRIORITY 2412.2 WEFDATE 2512.3 WEUDATE 25

FTA-FP039-9459-67062 REV A



13. BUS/TRAM VALIDATION 2513.1 TRAM ITSO PRODUCT INFORMATION 25

13.1.1 IIN 2613.1.2 OID 2613.1.3 TYP 2613.1.4 Format Revision 2613.1.5 PTYP 2613.1.6 FTOT 2613.1.7 Time Restrictions 2713.1.8 Priority 2713.1.9 Valid On Day 2713.1.10 Ticket Flags 2813.1.11 Product type 2813.1.12 WEFDate 2813.1.13 WEUDate 28

13.2 SNCODE MAPPING 2813.3 TRAM ROUTE LOOKUP 2913.4 BUS ROUTE LOOKUP 2913.5 EMERGENCY RAIL ITSO PRODUCT INFORMATION 29

13.5.1 IIN 3013.5.2 OID 3013.5.3 TYP 3013.5.4 Format Revision 3013.5.5 PTYP 3013.5.6 FTOT 3113.5.7 Valid On Day 3113.5.8 WEFDate 3113.5.9 WEUDate 31

14. BUS CONFIGURATION 3114.1 ITSO BUS END OF DAY TIME 3214.2 PASSBACK TIME/DISABLE 3214.3 TFL ENCTS PASS RESTRICTIONS 3214.4 LOCAL AUTHORITY ENCTS PASS RESTRICTIONS 32

FTA-FP039-9459-67062 REV A



1. INTRODUCTION1.1 REQUIREMENT AND SCOPE

This document defines the base data that is required to support the business logic tests defined in [1].

ITSO and RSP certification testing will be performed according to [4].

1.2 NOTE ON NLCS

NLCs are defined in one of two formats: either 4-digit numeric, as applied to stations, or as one alphacharacter with 3 numeric digits, as might be applied to a special (e.g. Plusbus) destination. Regardless ofhow NLCs are represented on ITSO cards, the convention used to store NLCs within base data as defined inthis document is to encode NLCs as a variable 5 digit number which can be contained in a word variable.

The encoding of the NLC is performed as follows:

Numeric NLCs from 0000 to 9999: store the value of the NLC Alphanumeric NLCs from A000 to Z999: use a look-up with A=10, B=11, C=12 etc to Z=35; multiply

that number by 1,000 then add the value of the remaining digits, hence:o A001 becomes 10,001o K849 becomes 20,849o Z701 becomes 35,701

1.3 NOTE ON MAXIMUM JOURNEY TIME

In the TfL Oyster system, there is a great deal of data provided to control maximum journey times, which canbe origin, destination and route dependent, and variable by day type. This data is required to allow thesystem the best opportunity to distinguish between journeys using PAYG.

In the world of TOC point-to-point ticketing there is potentially much greater flexibility in making interchangesand breaks of journey, and therefore for the purposes of IOP Business Logic it has been deemedunnecessary to attempt to control maximum journey times to anything like the same degree as for OysterPAYG. Consequently the only maximum applied to a journey using an ITSO IPE is that the journey mustcomplete on the same Traffic Day on which it starts, and therefore no Maximum Journey |Time base data isrequired.

1.4 UTS DATE

Dates within supporting base data are encoded as a 16-bit UTS Date, which is a standard data item usedwithin TFL systems. This is an integer count of the number of days where day 0 = 1 Jan 1980, hence 15 Feb2011 is 11368.

2. CMD WHITELISTApplicability: Station Specific

This data controls which ITSO CMDs will be accepted at a station. If an ITSO card is presented which is aCMD where there is no valid record, that card will be rejected regardless of any products contained.

The data will be a whitelist, containing the following elements:

CMD (FVC) number WEFDate WEUDate

As the applicability of each record can be controlled by date, it is possible to have multiple entries for a CMD,where one expires on a particular date and another becomes valid on the day after the other entry expires,though noting that there should not be any practical reason to encode the such data in the table. Therefore itmay be necessary to scan all records to confirm a match for a given CMD on a given date.

2.1 CMD

Data structure: byte

Specifies the acceptable values of the Format Version Code (FVC) contained within the ITSO Shell,and hence the CMD type. Allowable values are 1, 2, 3, 4, 5, 7 or 8.

FTA-FP039-9459-67062 REV A



2.2 WEFDATE

Data structure: word

With Effect From Date – UTS date on and from which this record is acceptable, or zero if no limit.

2.3 WEUDATE

Data structure: word

With Effect Until Date – UTS date before and on which this record is acceptable, or zero if no limit.

3. ITSO PRODUCT INFORMATIONApplicability: Station specific (Rail),, global (Bus)

This table defines all acceptable products. If an entry is not found that matches a product read on an ITSOcard, then that product will be considered as invalid at this location.

The following fields will be present in each record:

IIN OID TYP Format Revision PTYP FTOT Time Restriction Code Priority Valid on Day Ticket Flags Product type LU reporting WEFDate WEUDate

The data will be accessed using the IIN, OID, TYP, Format Revision and PTYP read from the ITSO cardbeing processed; in the case of a TYP24 IPE, the FTOT field is also considered. If no record exists thatexactly matches this combination, then the product must be considered as invalid.

As the applicability of each record can be controlled by date, it is possible to have multiple entries for acombination of IIN, OID, TYP, Format Revision and PTYP, where one expires on a particular date andanother becomes valid on the day after the other entry expires. Therefore it may be necessary to scan allrecords to confirm a match for a given product on a given date.

3.1 IIN

Data structure: binary, 3 bytes.

IIN is the ITSO Issuer Identification Number assigned to the product issuer. A value of 0xFFFFFF isused to indicate a wildcard, i.e. where a product can be issued by multiple issuers. Hence a value of0xFFFFFF is considered as a match for any IIN read from the product.

3.2 OID


OID is the ITSO Operator Identification number assigned to the product issuer. A value of 0xFFFFFFis used to indicate a wildcard, i.e. where a product can be issued by multiple issuers. Hence a valueof 0xFFFFFF is considered as a match for any OID read from the product.

3.3 TYP

Data structure: byte.

TYP is the ITSO IPE TYP identifier of the product, which must be one of:

14 (concession pass) 16 (concession pass) 22 (area based season ticket)

FTA-FP039-9459-67062 REV A



23 (pre defined specific journey ticket) 24 (pre defined specific journey ticket, potentially with multiple operator availability)

3.4 FORMAT REVISION


Format Revision is used in conjunction with the TYP field to determine which format revisions of theIPE TYP record should be accepted. Acceptable values for this field will be determined by the ITSOspecification, e.g. for TYP 24, only Format Revision 2 is acceptable, whereas for TYP 23, FormatRevisions 1 or 2 might be acceptable, depending on the product issuer.

3.5 PTYP


PTYP is the product type allocated by the product issuer to identify the particular productcharacteristics. The range of permissible values is 0-31.

3.6 FTOT

Data structure: 3 bytes (ASCII characters).

The FTOT field is only relevant to a TYP 24 IPE, and this is ignored for other TYPs. If unused, thefield should be set to ASCII spaces.

Within a TYP and PTYP, different products may be represented by differing Fares Type of Ticket(FTOT) values. Where this distinction is required, a record for each combination of IIN, OID, TYP,Format Revision, PTYP and FTOT must be provided. If the same processing is required for all FTOTvalues for a given combination of the other factors, then only one record is required and this fieldshould be set to ASCII spaces.

3.7 TIME RESTRICTIONS


The Time Restrictions field is used to indicate that a product has restrictions, when the TYP does notdefine fields for this purpose, and provides an indicator to a separate table where the actual timerestrictions can be specified – see section 9. This Time Restrictions code is used in conjunction withdestination information and the day type to look up the actual time restrictions to be applied to theproduct.

For a TYP 24 product, the time restriction can be indicated using the 2-character ATOC Restrictionsfield. Hence for a TYP 24 product, the special value of 0xFF will be used here, indicating that theATOC Restriction Code should be used instead to determine the index to the time restrictions data(see 10).

For a TYP 22 or TYP 23 product, ATOC has defined multiple day profiles using the ValidityCode field,ref [2]. The field in this table allows a special value of 0xFE to use a separate look-up based on thecontent of this IPE field (see 11), however if this is not set then the time restriction code (if set) will beused and the ValidityCode field in the IPE will be ignored.

Permissible values:

0 – at any time 1 – 63 – valid only outside the time restrictions specified (value is used to look up time

restriction base data) 0xFE – use ValidityCode bits (where TYP is 22 or 23) 0xFF – not applicable (where TYP is 23)/use ATOC Restriction Mapping (where TYP is 24)

3.8 PRIORITY


The Priority field allows the product to be given an order of precedence that can be considered whenmaking a choice between multiple products that otherwise have similar validity. The range ofpermissible values is from 1 to 31, where 1 is the highest.

As an example, a staff pass might be set at level 1, a season as level 2, a Single as level 3 and aReturn as level 4. In this case, if all products are valid for a given journey, then the staff pass will be

FTA-FP039-9459-67062 REV A



used in preference. If there is no staff pass then the season will be used and hence the Single andReturn products will remain unused.

3.9 VALID ON DAY

Data structure: byte containing 8-bit bitmap.

Defines days of the week upon which this IPE is valid, depicted as a bitmap.

Bit 0: when set, this IPE is valid on Public Holidays Bit 1 : when set, this IPE is valid on Sundays Bit 2 : when set, this IPE is valid on Saturdays Bit 3 : when set, this IPE is valid on Fridays Bit 4 : when set, this IPE is valid on Thursdays Bit 5 : when set, this IPE is valid on Wednesdays Bit 6 : when set, this IPE is valid on Tuesdays Bit 7 : when set, this IPE is valid on Mondays

If all bits are clear for a particular record, then only the day restrictions specified within the IPE itselfwill be applied. In this case, if there are no day restrictions identified in the IPE record, then theproduct will be considered to be valid on any day.

If any of the bits are set, then the product must satisfy both this test and any restrictions specifiedwithin the IPE itself.

TYP 22 products have a separate ValidonDayCode field in the IPE TYP 23 products do not have a separate ValidonDayCode field in the IPE TYP 24 products have their own definition of validity days in the IPE TYP 14 and 16 IPEs may have a separate HalfDayofWeek field in the IPE. If the

HalfDayofWeek field is present, TYP 14 and 16 products must satisfy both the day of weektest based on the IPE setting and the day of week test according to the setting in this table. Ifthe HalfDayofWeek field is not present, TYP 14 and 16 products only have to pass the day ofweek test according to the setting in this table.

3.10 TICKET FLAGS


Defines extra controls associated with this product type, depicted as a bitmap:

Bit 0 : when set, allows passback for this product, i.e. it turns off the passback check Bit 1 : when set, turns off zigzag checking for this product Bit 2 : when set, defines that a TYP 23 product is a Return. If clear, the TYP 23 product is a

Single. Ignored when the TYP is other than 23 Bit 3 : when set, allows BOJ for a TYP 23 product. If clear, BOJ is not allowed. Ignored when

the TYP is other than 23. Bits 4 - 7 : Reserved, set to zero

3.11 PRODUCT TYPE


The product type field defines the type of business logic to be applied to the product.

Permissible values:

0 – single 1 – return 2 – season 3 – staff pass 4 – concession pass 5 – ENCTS pass 6 - travelcard

3.12 LU REPORTING

Data structure: byte containing 6-bit binary field and 2-bit binary field.

FTA-FP039-9459-67062 REV A



The LU reporting field provides data that is used to populate the pseudo-magnetic transaction that isgenerated by devices other than at LU locations.

The field consists of two parts:

Bits 0-5 contain the equivalent LU ticket type, in the range 0 to 31. Bits 7 and 8 contain the off-peak setting, in the range 0 to 3.

This field is not applicable for Bus locations and will be set to zero for this subsystem.

3.13 WEFDATE

Data structure: word.


3.14 WEUDATE



4. STATION CONFIGURATIONApplicability: Station specific (Rail), location specific (Tram)

This base data contains station-level information regarding location and times to be applied within othertests.

Passback time/disable Zigzag time/disable Station NLC “Here” Zones Alternative “Here” NLCs “Here” Routes Reject Routes OSI Partners Local OSI time Continuation Entry time Entry Restriction Easement time Minimum Journey Time LUL Station Number Perform IPE Seal Check on Entry Rail/Tram Interchange Rail-Tram Check In Time

4.1 PASSBACK TIME/DISABLE


Permissible values: 0 – 63.

This value is always used in preference to any encoded passback time limit that may be encoded onan IPE.

By default, passback checking is applied unless either (a) the value of this field is zero or (b) the datain the ITSO Product Information table (3) turns passback checking off for a particular product.

The field contains the maximum number of minutes within which (less than or equal to) passback canbe detected, hence if a passenger completes the sequence that would result in a passback detectionwithin this time a passback will be detected, otherwise not.

The same value will apply to passback checks for both entry and exit at this station.

4.2 ZIGZAG TIME/DISABLE



FTA-FP039-9459-67062 REV A



By default, zigzag checking is applied unless either (a) the value of this field is zero or (b) the data inthe product definition table turns zigzag checking off for a particular product.

The field contains the maximum number of minutes within which (less than or equal to) a zigzagsequence can be detected, hence if a passenger completes the sequence that would result in zigzagdetection within this time a zigzag will be detected, otherwise not.

The same value will apply to zigzag checks for both entry and exit at this station.

4.3 STATION NLC


This contains the NLC that is used to represent the station at which a validation was performed whenwriting to cards and generating transactions, and is also the primary “here” NLC used during validationtests.

Also used as the value to report in the NLC subfield of the FixtureIdentifier field in the ITSO 0803message.

Note that at some large stations (e.g. Waterloo) it may be necessary to have multiple NLCs in deviceconfigurations due to limitations on system architecture. The NLC in this table will always be theactual station NLC, regardless of any local configuration setting of the device in which the readerresides.

4.4 “HERE” ZONES

Data structure: word containing 16-bit bitmap.

This field is used to show which London Travelcard zone(s) are applicable at this location. Typicallythere will only be one zone set, though at boundary stations it is possible for two zones to be specified.

Bit 0 : set if this station is in Travelcard zone 1









Bits 9-15 : reserved, set to 0

Note that at the time of writing, only Travelcard zones 1 to 9 are in use. Zone “W” is handled byorigin/destination only as it only applies to Watford Junction. This field allows for potential extension ofthe London Travelcard zonal system.

4.5 ALTERNATIVE “HERE” NLCS

Data structure: byte index followed by a list of word values.

A station may need to recognise multiple locations as being “here” in addition to its own NLC, forexample a London station such as Waterloo must accept both its own NLC and the NLC thatrepresents “London Terminals” (1072).

The data structure allows up to 20 alternative NLCs to represent “here”, though noting that whenever acard is updated, the point of usage recorded will be the actual station NLC rather than any alternativefrom this list.

There is no need to include London Zonal NLCs in this data as zones are covered by separate data.

Examples:

For a station with no alternatives, the byte index will be 0 and there will be no subsequent NLClist.

FTA-FP039-9459-67062 REV A



For a station with one alternative, the byte index will be 1 and there will be a further 2 bytesrepresenting the alternative NLC.

For a station with two alternatives, the byte index will be 2 and there will be a further 4 bytesrepresenting the two alternative NLCs.

4.6 “HERE” ROUTES

Data structure: byte index followed by a list of 3 byte unsigned binary values.

A station may need a list of route codes on which it is valid, regardless of origin and destination.Route codes are specified as 5-digit numbers in the range 0 - 99,999, which can therefore berepresented in a 3 byte field.

The data structure allows up to 20 routes to represent “here”. Note that is not appropriate to includethe general 00000 “Any Permitted” in this list. There is no need to include London Zonal routes in thisdata as zones are covered by separate data.

This data may be used in addition to other data structures which may be used to establish whether astation is between a specified origin and destination. Typically, it may be used more for seasontickets, where an “Also Available At” location would be specified by a route code, or a London zoneavailability might be specified by the route code in addition to an origin and destination.

Examples:

For a station with no specific routes, the byte index will be 0 and there will be no subsequentroute code list.

For a station with two valid routes, the byte index will be 2 and there will be a further 6 bytesrepresenting the two route codes.

4.7 REJECT ROUTES

Data structure: byte index followed by a list of 3 byte unsigned binary values.

A station may need a list of route codes which are specifically rejected. Route codes are specified as5-digit numbers in the range 0 – 99,999, which can therefore be represented in a 3 byte field.

The data structure allows up to 20 routes to be rejected at this location.

Examples:

For a station with no specific reject routes, the byte index will be 0 and there will be nosubsequent route code list.

For a station with two reject routes, the byte index will be 2 and there will be a further 6 bytesrepresenting the two route codes.

4.8 OSI PARTNERS

Data structure: byte index followed by a list of records, each of which contains a word value (NLC)followed by a byte (time).

When a station is involved in an OSI with a partner station, then this list specifies the NLC(s) of anypartner station(s) associated with the OSI, and the interchange time allowed for that partner, inminutes. If the minutes field is set to zero, then no time limit will be applied for the interchange.

Up to 4 partner stations may be specified, and if the list is empty then this is not considered to be anOSI location.

Examples:

For a station which is not an OSI location, the byte index will be 0 and there will be nosubsequent NLC list.

For a station with one OSI partner, the byte index will be 1 and there will be a further 2 bytesrepresenting the partner station NLC and 1 byte representing the allowable interchange time.

4.9 LOCAL OSI TIME


FTA-FP039-9459-67062 REV A



This field specifies, where a station is set as a local OSI, the time permitted to make an interchangebetween two “sides” of the station. The value represents the number of minutes allowed. A value ofzero means that there is no time limit set for making an interchange.

Note that the application of local OSI is controlled through configuration data at the reader, whichspecifies which “side” of the station with which the reader is associated. If the reader has no OSI“side” set then it will not apply local OSI processing.

4.10 CONTINUATION ENTRY TIME


If this station is equipped with validation equipment in the paid area, for example an on-platformValidator in addition to an entry gateline, then this parameter defines the maximum number of minuteswhere a validation at the paid area equipment will be ignored following an entry validation at the samestat ion. However there is no distinction in the system that allows a Validator to “know” whether or not itis at the gateline or on-platform. Hence although the intent of this parameter and the tests controlledby it are to allow the behaviour identified above, multiple validations between (eg) a gate and aValidator mounted at a gateline would also result in the same behaviour.

If the station has no validation equipment other than at the entrance/exit, then this value is set to zero.

4.11 ENTRY RESTRICTION EASEMENT TIME


Typically, entry is permitted before the time restriction on a ticket has expired, to allow time for apassenger to make his way to the platform. An example might be where an off peak ticket does notallow travel before 09:30, however a train leaves at 09:31 and hence entry gate access is requiredfrom 09:21 so that the passenger can catch the train.

This value specifies the number of minutes by which the entry logic is relaxed, i.e. it effectively adjuststhe ticket restriction time to allow access if it would be restricted otherwise.

This parameter only applies to entry where a product is currently restricted; hence it effectivelychanges the end time of a restriction. This parameter does not affect exit processing.

4.12 MINIMUM JOURNEY TIME


This value specifies the minimum time, in minutes, in which it would be possible to make a journeyfrom this station to the next nearest station, and then return to this station. It is used to distinguishbetween an entry/exit validation at the same station when there is no intervening use recorded on thecard, to identify whether the passenger could or could not have made a journey in that time.

4.13 LUL STATION NUMBER


Value to be reported as the Station Last Used in the LUL pseudo magnetic ticket data. Range 0-511.

4.14 PERFORM IPE SEAL CHECK ON ENTRY


Flag to control whether or not an IPE used to allow an entry is to have its seal checked during thevalidation. Currently TfL wish to apply a seal check but ATOC do not, hence this flag will allow controlto be applied differently by location.

If enabled, only one product will have its seal checked, even though there might be multiplecandidates for the journey. The seal check will be applied to the first product identified duringprocessing that would allow entry, regardless of any other priority rules.

Set to 0 to disable IPE seal check during an entry validation, 0xFF to enable seal check.

4.15 RAIL-TRAM INTERCHANGE

Data structure: byte, containing bitmap flags.

Bit 0: Direct interchangeBit 1: InterchangeBit 2-7: Reserved, set to zero

FTA-FP039-9459-67062 REV A



The “Direct Intrerchange” f lag used to identify locations where it is possible to transfer directly fromtram to rail within the station, and hence where use of a Rail Validator after a previous Tram Validationis considered to be extending the journey. Where this flag is non-zero and the conditions for journeyextension are satisfied, then such a validation will be considered equivalent to a re-entry rather than aContinuation Exit.

Currently this flag is expected to be set for Wimbledon and Elmers End only, though other settingswould be at TfL/ATOC discretion.

The “Interchange” flag is set for any rail location where it is permissible to transfer from Tram to Railwithout breaking a journey, otherwise clear.

Currently this flag is expected to be set for Wimbledon, Mitcham Junction, West Croydon, EastCroydon, Elmers End, Birkbeck, Beckenham Junction

4.16 RAIL-TRAM CHECK IN TIME

Data structure: byte, number of minutes

This parameter is only used where there is a direct on-station interchange between Rail and Tram, asindicated in the data in 4.15 above. This is the maximum number of minutes after a check in at thesame location where a Tram Validator will undo the check in and perform a new journey on Tram. Ifthe time is exceeded then if the card has a check in a forced exit will be applied to complete thejourney prior to performing the Tram entry.

4.17 TRAM “HERE” LOCATIONS

Data structure: byte count of locations, followed by list of word NLC values

This structure is only required to be populated where a Rail entry device must allow access to Tram-only products, current ly only at Wimbledon and Elmers End. For all other locations the count will beset to zero.

When populated, this contains a list of valid Origin/Destination NLCs that, if encountered on a Tramproduct, will permit access for an Entry validation.

4.18 TRAM “HERE” ZONES

Data structure: word containing 16-bit bitmap.

This structure is only required to be populated where a Rail entry device must allow access to Tram-only products, currently only at Wimbledon and Elmers End. For all other locations the bits will all beset to zero.

This field is used to show which London Travelcard zone(s) for which access should be allowed for aTram-only product. If the product contains validity for any of the zones specified, then it will beallowed access.

Bit 0 : set if a product containing Travelcard zone 1 is allowed access


Bit 2 : set if a product containing Travelcard zone 3 is allowed access *








* currently products containing any individual zone within, or combination of zones, 3 4 and 5 would beallowed access.

4.19 TRAM “HERE” ROUTES

Data structure: byte count followed by a list of 3 byte unsigned binary values.

FTA-FP039-9459-67062 REV A



This structure is only required to be populated where a Rail entry device must allow access to Tram-only products, currently only at Wimbledon and Elmers End. For all other locations the count will beset to zero.

A station will need a list of route codes on which Tram-only products are valid, regardless of origin anddestination. Route codes are specified as 5-digit numbers in the range 0 - 99,999, which cantherefore be represented in a 3 byte field.


Currently, only 00901 (“Croydon Tramlink”) is expected to be present.

5. ALIAS STATION CONFIGURATIONApplicability: station specific

Certain station-specific data must be augmented when a station is involved in aliasing. The data in this tablerepresents extra NLCs and routes that will be considered as “here” when the station is aliasing for another.A separate control list will be sent to the reader to instruct it to turn aliasing on or off, and for which NLC(s) toapply aliasing.

The data in this table, when aliasing is turned on, is used in addition to the equivalent data in the “StationConfiguration” table, to determine that a product is valid “here”.

The table has entries for each potential partner station, so for each station the following data exists:

Alias “Here” Zones Alias “Here” NLCs Alias “Here” Routes Alias OSI Partners

The records are ordered as follows:

Number of Alias stations Alias NLC 1

o Alias “Here” Zones for NLC 1o Alias “Here” NLCs for NLC 1o Alias “Here” Routes for NLC 1o Alias OSI Partners for NLC 1

Alias NLC 2o Alias “Here” Zones for NLC 2o Alias “Here” NLCs for NLC 2o Alias “Here” Routes for NLC 2o Alias OSI Partners for NLC 2

Etc.

5.1 NUMBER OF ALIAS STATIONS


This represents the number of stations that could be involved in aliasing, and hence determines howmany subsequent records there are in the table. If set to zero, then this station will not be able to aliasfor any other station.

Permissible values: 0 to 10.

5.2 ALIAS NLC

Data structure: word value.

For each station where alias data is present, that station’s alias data is preceded by this field which isthe NLC of the station to be aliased.

5.3 ALIAS “HERE” ZONES

Data structure: word bitmap.

FTA-FP039-9459-67062 REV A



This field is used to show which London Travelcard zone(s) are applicable at this location. Typicallythere will only be one zone set, though at boundary stations it is possible for two zones to be specified.











Note that Watford Junction is considered to be outside the Travelcard zones.

5.4 ALIAS ALTERNATIVE “HERE” NLCS

Data structure: byte index followed by a list of word values.

The data structure allows up to 20 alternative NLCs to represent “here”, though noting that whenever acard is updated, the point of usage recorded will be the actual s tation NLC rather than any alternativefrom this list. There is no need to include London Zonal NLCs in this data as zones are covered byseparate data.

5.5 ALIAS “HERE” ROUTES

Data structure: byte index followed by a list of 3-byte binary numbers.


5.6 ALIAS OSI PARTNERS

Data structure: byte index followed by a list of records, each of which contains a word (NLC) followedby a byte (time).

When a station is involved in an OSI with a partner station as a result of aliasing, then this list specifiesthe NLC(s) of any partner station(s) associated with the OSI, and the time allowed for interchange withthat partner (minutes). If the minutes field is set to zero then no time limit will be applied to aninterchange with that partner.

Up to 4 partner stations may be specified, and if the list is empty then this is not considered to be anOSI location.

6. ITSO ALIAS CONTROLApplicability: station specific

Data structure: byte (number of stations in list) followed by a list of 0 to 10 word value entries, which arethe NLCs of the station(s) for which this location is currently aliasing.

The alias control table is station-specific, and is dynamically updated by the DGC. It is sent to station(s) asrequired to turn aliasing on or off, and to control for which other station(s) a location is aliasing.

If aliasing is turned off, the number of stations will be set to zero, and no NLCs will be present in the list.

If aliasing is turned on, the number of stations will be set to the number of stations for which this location isrequired to alias, followed by a list of their NLCs.

Note that no further information is required to be updated dynamically; the alternative location data musthave been previously defined and downloaded in the Alias Station Configuration table described in section 5above If an NLC appears in this control list but there is no equivalent data within the Alias StationConfiguration table, then this NLC will be ignored.

FTA-FP039-9459-67062 REV A



7. RELATIVE LOCATIONSApplicability: station specific

This data is used to determine whether a station is on a valid path between the origin and destinationstations when there is no specific Route code, e.g. the product is encoded with Route code 00000 “Anypermitted”.

Two tables are specified to control interchange between origin and destination; the latter table also providesa means to modify time restrictions based on destination:

NLC to Location Group Mapping Location Group Details

A further table is used to identify appropriate origin/destinations and minimum zones relative to a terminalstation:

Terminus to Location Group/Zone acceptability

7.1 NLC TO LOCATION GROUP MAPPING

Data structure: word (NLC) followed by byte (group).

Maximum size: 4000 entries.

This table is directly equivalent to the Cubic TOC ticket logic “Break of Journey Stations” table (243),allowing up to 4000 NLCs to be included.

The data comprises list of NLCs ordered in ascending NLC value – this is important as the test mustfind data by NLC in an efficient manner – and for each NLC, a value that indicates a group (up to 32)to which it is allocated.

It is permissible for zonal NLCs (e.g. 0031 “London Zone 1”) to be included in this list.

The table is scanned using the encoded origin and destination NLCs, and the group for each isestablished from the table data. The relationship between these groups is then determined byaccessing the “Location Group Details” table.

7.2 LOCATION GROUP DETAILS

Data structure: byte containing two 4-bit fields - interchange code and direction set

Size: 1024 entries.

This table is equivalent to the Cubic TOC ticket logic “Break of Journey Details” table (244). It isaccessed by calculating an index based on the origin group*32 plus the destination group, determinedby looking up the “NLC to Location Group Mapping” table. This index is used to establish aninterchange code that shows whether or not interchange at this location is allowed in the entry and/orexit direction, and a “direction set”. The latter is used to control direction-dependent time restrictions,and is therefore relevant only to the destination group. Hence all entries corresponding to a particulardestination group (0..31) should be the same. For further information on how the direction set is used,refer to section 9.

The interchange code is contained in the most significant 4 bits, the direction set is contained in theleast significant 4 bits.

The interchange code values are defined as:

0 – no access allowed here 1 – entry allowed here 2 – exit allowed here 3 – entry and exit allowed here

The permissible range of the direction set is 0-3.

7.3 LOCATION GROUP/ZONE ACCEPTABILITY

Data structure:

FTA-FP039-9459-67062 REV A



Location Groups bitmap (32 bits)

Minimum Zones 1 bitmap (16 bits)

Minimum Zones 2 bitmap (16 bits)

This table consists of a single record with three bitmaps: the first Location Groups bitmap (32 bits) isused for station to identify groups of NLCs that are appropriate to allow entry or exit when theorigin/destination is set to this station. The same groups are used as defined in 7.1 above, and thisrecord has a bit allocated to each group; bit 0 represents group 0, through to bit 31 representing group31. If the bit is set, then locations in the corresponding group are considered as invalid; if the bit isclear then locations in that group are allowed access.

Typically this is used for geographical control to or from a terminus station, though it can be applied fornon-terminus stations if required. If there are no geographic restrictions to be applied, this field is setto zero and all locations are considered acceptable.

The second and third fields – Minimum Zones 1 and 2 bitmaps - are used to identify the minimumzones that must be present on a zonally-specified product to allow access at a station. This is typicallyof value at a terminus station, where the terminus may be in zone 1 but the first station on the line is inzone 2. In this case, a zonally specified ticket must be valid for both zones 1 and 2 to be valid forentry.

Two fields are specified to cater for a situation where a station is in one zone, but stations on eitherside are in different zones. An example might be a station in zone 5, where the next stations are inzone 3 on one side or zone 6 on the other. Hence entry/exit with a zone 5 only ticket would not beallowed, however a ticket containing at least zones 3, 4 and 5 would be acceptable, as would a ticketcontaining at least zones 5 and 6. Hence the two fields are used to identify these alternatives; if thealternative is not required then it is set to zero.

Examples:

Zone 1 and 2 required: Field 1: 00000000 00000011 Field 2: 00000000 00000000

Zones 3/4/5 or 5/6: Field 1: 00000000 00011100 Field 2: 00000000 00110000

8. GLOBAL SETTINGSApplicability: global

Certain data is required at all stations to control behaviour across the system in a common manner; this iscontained in the Global Settings.

ITSO End of Day Time ITSO Travelcard End of Day Time Interchange stations list Continuation Exit time NLC to zone mapping Route to zone mapping Multi-presentation time Tram to Rail Interchange Time Rail to Tram Interchange Time Test OIDs

8.1 ITSO END OF DAY TIME


Time at which traffic days end for the purposes of Rail/Tram ITSO validations for all products exceptTravelcards (as identified by data in section 3.11), expressed as the number of minutes past midnight.For example, if a day extends from 00:00:00 up to 2:30am the next day, this is set to 1590. Note thattraffic days are always considered to start at 00:00:00.

This time is only used for ITSO validation purposes.

8.2 ITSO TRAVELCARD END OF DAY TIME


FTA-FP039-9459-67062 REV A



Time at which traffic days end for the purposes of Rail/Tram ITSO validations for Travelcard products(as identified by data in section 3.11), expressed as the number of minutes past midnight. Forexample, if a day extends from 00:00:00 up to 4:30am the next day, this is set to 1710. Note thattraffic days are always considered to start at 00:00:00.

This time is only used for ITSO validation purposes.

8.3 INTERCHANGE STATIONS LIST

Data structure: byte index followed by a list of records, each of which contains a word (NLC)

This is a list of all stations at which it is possible to encounter and use a validation device, recording anexit, even though the journey has not been completed. Generally this is due to validation devicesbeing mounted on platforms in addition to the entry/exit points of stations.

When a validation is being performed, this list is checked to see if a previous exit has been performedat one of these locations, and if so then, if appropriate, an Exit may be changed to a Continuation Exit.

The list may contain up to 255 “Interchange” locations; there is no time limit associated with eachlocation as this is system-wide data, and in any case ITSO travel does not apply any journey-specifictime restrictions other than requiring completion on the same traffic day as when the journey started.

8.4 CONTINUATION EXIT TIME

Data structure: byte containing number of minutes (0-255).

This field is used to restrict the time where a Continuation Exit will be allowed following an Exitvalidation at a location present on the Interchange Stations list. The value is specified in minutes,where 0 allows Continuation Exit at any time on the same traffic day.

8.5 ZONAL NLC TO ZONE MAPPING

Data structure: word containing NLC followed by word containing a 16-bit bitmap (zones)

This is a list of NLCs with their equivalent zone representation. This is required because ATOCencoding uses NLCs to represent single Travelcard zones or combinations of zones, and it isnecessary to translate this into actual zone data to apply zone-based checks for origin, destination andavailability at other locations for zone-based products.

Each record contains an NLC and a bitmap equivalent of the zone(s) it represents. The bits aremapped as follows:

Bit 0 : set if this NLC includes Travelcard zone 1










Examples:

0035 0000000000111111 (“London Zones 1-6”)

0036 0000000000000110 (“London Zones 2-3”)

0060 0000000000010000 (“London Zone 5”)

8.6 BOUNDARY NLC TO ZONE MAPPING


FTA-FP039-9459-67062 REV A



This is a list of NLCs with their equivalent zone representation, specifically to identify “Boundary Zone”NLCs that are used to extend Travelcard validity. This table is used when checking for contiguoustickets to match boundary NLCs to their corresponding zones.


Bit 0 : set if this NLC is Boundary Zone 1










Examples:

0041 0000000000000010 (“Boundary Zone 2”)

0044 0000000000001000 (“Boundary Zone 4”)

8.7 NLC TO ZONE MAPPING


This is a list of all station NLCs located within the London Travlecard zones with their equivalent zonerepresentation. This is used when checking for contiguous tickets, to establish whether the Origin orDestination of a point-to-point product lies within the coverage of a zonally specified product.

The table should include entries for “alias” NLCs, for example “London Terminals”, otherwise productsusing these codes will not be considered properly.


Bit 0 : set if this NLC is within Travelcard zone 1










Examples:

1445 0000000000000010 (FINCHLEY ROAD & FROGNAL, Zone 2)

0527 0000000000001100 (BOUNDS GREEN, Zones 3 & 4)

0570 0000000000000011 (ELEPHANT & CASTLE, Zones 1 & 2)

FTA-FP039-9459-67062 REV A



8.8 ROUTE TO ZONE MAPPING

Data structure: 3 byte binary followed by word containing bitmap (zones)

This is a list of Route codes with their equivalent zone representation. This is required because ATOCencoding uses Route codes to represent single Travelcard zones or combinations of zones as extraavailability, or where the origin and destination are both point locations in a season ticket. It isnecessary to translate this Route code into actual zone data to apply zone-based checks foravailability at other locations than the encoded origin and destination.

Each record contains a 5-digit Route code and a bitmap equivalent of the zone(s) it represents. Thebits are mapped as follows:

Bit 0 : set if this Route code includes Travelcard zone 1










Examples:

00926 0000000000111110 (“London Zones 2-6”)

00930 0000000000000001 (“Zone U1 Londn”)

40232 0000000111000000 (“AAA LDN Zone 7-9”)

8.9 MULTI-PRESENTATION TIME

Data format: byte.

This field specifies the number of seconds used by a Validator to avoid a repeat validation.Specifically, the test considers a card’s previous validation – if it was performed at the same,autodirectional, device, and if the current validation is within the time specified by this parameter, thenthe new validation will simply show the same displays to the customer as the original validation, butthe card will not be updated and no transactions will be generated.

8.10 TRAM TO RAIL INTERCHANGE TIME

Data format: byte

This field specifies the number of minutes that is allowed for a Tram journey. This is required for aRail validation following a Tram validation where the product used for the Tram validation has throughvalidity to Rail. If the time is exceeded, then a subsequent Rail validation will consider that a newjourney has been started, and will apply a forced exit to the current journey.

8.11 RAIL TO TRAM INTERCHANGE TIME

Data format: byte

This field specifies the number of minutes that is allowed after a Rail exit for a journey continuation onTram. This is required for a Tram validation following a Rail validation where the product used for theRail validation has through validity to Tram. If the time is exceeded, then a subsequent Tramvalidation will consider that a new journey has been started, and will apply a forced exit to the currentjourney.

8.12 TEST OIDS

Data structure: byte count of number of OIDs followed by list of 3-byte binary OIDs.

FTA-FP039-9459-67062 REV A



This list defines OIDs that should be treated as test indicators, either for individual products or for thewhole card,

9. TIME RESTRICTIONSApplicability: station specific

9.1 TIME RESTRICTIONS

Data structure: byte containing 6-bit field (time code) and 2-bit field (direction set), byte containing8-bit bitmap (day types), word containing start time of restriction, word containingend time of restriction

The Time Restrictions table contains a list of all time periods which may be applied to products at thisstation, where such restrictions are not encoded in the IPE. The list defines the start and end times ofperiods where a product will be rejected, and each contains an indicator to show the time band, asdetermined from the “ITSO Product Information” table, and a set number (“Direction set”), which isobtained by checking the destination station set. This method allows the possibility to operate differingtime restrictions depending on direction of travel.

If there are multiple restrictions for a particular product, then there will be multiple entries in this tablewith the same time band/destination set. Time bands may overlap.

At exit, the values from this table are used directly as read. At entry, the end time of the restriction isreduced by the “Off peak easement time” obtained from the Station Configuration data (see 4.11).

A non-unique key (Time Restriction Key) is constructed in this format:

Bits 0 and 1 : direction set as determined from 7.2 Bits 2-7 : Time code as determined from 3.7 or from 10.2 for a TYP24

This table is ordered by increasing values of the Time Restriction Key, and then by increasing valuesof the Start Time if there are two or more entries with the same Time Restriction Key.

This table is searched for one or more entries that match the Time Restriction Key and Day Type. Ifthere is no match in this table, then it is considered that there are no restrictions to be applied to theproduct.

Different start and end times can apply to each day or type of day (Monday-Friday, Saturday, Sundayand Bank Holiday).

An Off-peak ticket is only valid if the time of validation does not have a restriction in any the entriesthat correspond to the Time Restriction Key of the IPE.

If the whole day for a ticket is considered as restricted, this table contains a single corresponding entrywith start time = 0 and end time = 1590 for the appropriate day(s).

If the whole day for a ticket is considered as unrestricted, (e.g. If Saturday is off peak all day), there isno corresponding entry in this table.

Example:

If an off-peak ticket has Time Restriction Code of 2 (from 3.7), Destination A is in London and entry is restricted to 09:50 on Monday-Friday, and is in

Destination set 1 Destination B is near the South Coast and is entry is restricted to 09:30 on Monday-Friday,

and is in destination set 2 Time Restriction Key for this product is 00001001 (9) for destination A and 00001010 (10) for

destination B Day Type bitmap is 11111000 (248) to show a restriction on Monday-Friday 09:30 is 570 minutes past midnight 09:50 is 590 minutes past midnight Table entries required:

o 9, 248, 0, 590 (prevents use from 00:00 to 09:50)o 10, 248, 0, 570 (prevents use from 00:00 to 09:30)

FTA-FP039-9459-67062 REV A



10. ATOC RESTRICTIONS MAPPINGApplicability: global

This table is used to map ATOC 2-character restriction codes to Time Restriction Codes that can be used toaccess the time restrictions data (see 9.1), when the IPE is a TYP24..

The table allows for multiple records to control date-driven changes to the codes. Each record contains:

ATOC Restriction Code Time Restriction Code WEFDate WEUDate

10.1 ATOC RESTRICTION CODE


This field contains the 2-character ASCII ATOC Restriction Code. This will be read from a TYP24product and used as a key to find the appropriate record.

As the table allows for multiple records with differing dates, there may be more than one recordcontaining the same ATOC Restriction Code, however if so then the WEFDate and WEUDate mustspecify unambiguously which record to use on any given date.

10.2 TIME RESTRICTION CODE


The Time Restriction Code field provides an indicator to a separate Time Restrictions table where theactual time restrict ions are specified – see section 9. This Time Restriction Code is used inconjunction with destination information and the day type to look up the actual time restrictions to beapplied to the product.

Permissible values:

0 – valid at any time 1 – 63 – valid only outside the time restrictions specified (value is used to look up time

restriction base data) 0xFF – invalid at all times

10.3 WEFDATE


With Effect From Date – UTS date on and from which this mapping should be applied, or zero if nochoice.

10.4 WEUDATE


With Effect Until Date – UTS date before and on which this mapping should be applied, or zero if nochoice.

11. IPE TIME RESTRICTIONS MAPPINGApplicability: global

This table is used to map the peak/off-peak restrictions that can be indicated in the TYP 22 and TYP 23 IPEValidityCode field to Time Restriction Codes that can be used to access the time restrictions data (see 9.1).

The table allows for multiple records to control date-driven changes to the Time Restriction. Each recordcontains:

Ticket ValidityCode Time Restrictiion Code WEFDate WEUDate

This table is only used if the data in the “ITSO Product Definitions” table selects it (3.7).

FTA-FP039-9459-67062 REV A



11.1 TICKET VALIDITYCODE

Data structure: 1 byte.

This field contains the key value, which is derived from bits 1-3 of the encoded ValidityCode. This willbe read from a TYP 22/23 product and used to find the appropriate record.

As the table allows for multiple records with differing dates, there may be more than one recordcontaining the same ATOC Validity Code, however if so then the WEFDate and WEUDate mustspecify unambiguously which record to use on any given date.

The permissible values of this field are:

0 : no gradation 1 : high peak 2 : mid peak 3 : shoulder peak 4 : shoulder off-peak 5 : mid off -peak 6 : off -peak

These descriptions match those specified in [2]; there is no attempt in this document to define howthese relate to actual time restrictions.

11.2 TIME RESTRICTION CODE


The Time Restriction Code field provides an indicator to the Time Restrictions table where the actualtime restrictions are specified – see section 9. This Time Restriction Code is used in conjunction withdestination information and the day type to look up the actual time restrictions to be applied to theproduct.

Permissible values:

0 – valid at any time 1 – 63 – valid only outside the time restrictions specified (value is used to look up time

restriction base data) 0xFF – invalid at all times

11.3 WEFDATE


With Effect From Date – UTS date on and from which this mapping should be applied, or zero if nochoice.

11.4 WEUDATE


With Effect Until Date – UTS date before and on which this mapping should be applied, or zero if nochoice.

12. TICKET LOGIC PRIORITY CONTROLApplicability: station-specific

This table is used to allow ticket logic to select a candidate product when there is a multiple choice.

The table allows for multiple records to control date-driven changes to the priority. Each record contains:

Ticket Logic Priority WEFDate WEUDate

12.1 TICKET LOGIC PRIORITY

Data format: 5 bytes

FTA-FP039-9459-67062 REV A



This table is used within Ticket Logic processing, to determine the order of consideration of fourfactors which are used to select a preferred candidate product when more than one could be used toauthorise a journey.

In each record the values in each byte specify the order in which each factor is considered. Thereforethe value in each byte must be different from every other byte and must be between 0 and 5. The firstbyte in the record specifies the highest priority and the fourth specifies the lowest.

The bytes in the record are allocated to specif ic factors:

0 : Don’t care (used after other non-zero values) 1 : Ticket Priority of the product as determined in 3.8 2 : Soonest End of Validity 3 : Lowest Monetary value 4 : Concession 5 : Reject if no decision

The difference between the use of values 0 and 5 is that value 0 results in an arbitrary decision, whichis the first valid product read from the card if the preceding priority items have not resulted in a specificchoice. Value 5 results in the card being rejected in such a circumstance, forcing the product choiceto be made off -system, as required by some TOCs.

Examples:

If the sequence to be applied is Ticket Priority, Monetary Value, Concession, End of Validity,then an arbitrary choice then the record will contain 1, 3, 4, 2, 0.

If only Monetary Value then Ticket Priority is to be applied then the record will contain 3, 1, 0, 0,0.

If a TOC requires a manual check if there is no choice after considering End of Validity followedby Ticket Priority, then the record will contain 2, 1, 5, 0, 0 – note that the 0s are effectivelyredundant since the 5 will result in no further processing.

If a TOC always requires manual checks regardless of other choices, the record will contain 5,0, 0, 0, 0 – again the 0s are effectively redundant as above.

12.2 WEFDATE


With Effect From Date – UTS date on and from which this priority setting should be applied, or zero ifno choice.

12.3 WEUDATE


With Effect Until Date – UTS date before and on which this priority setting should be applied, or zero ifno choice.

13. BUS/TRAM VALIDATIONThe following data is required to support Tram and Bus validation.

13.1 TRAM ITSO PRODUCT INFORMATION

Applicability: Tram, common across all locations, and Rail, location specific.

This table defines all Tram acceptable products. If an entry is not found that matches a product readon an ITSO card, then that product will be considered as invalid.

In a Tram validation, this table is used in place of the ITSO Product Information table (3). In a Railvalidation, this table is only required to be populated if the location has a direct cross-platform Rail-Tram interchange (currently only Wimbledon and Elmers End). For all other rail locations, anull table should be loaded. Its purpose for a Rail validation is to identify a Tram-only product, wherethe Rail validation data would not allow it.


FTA-FP039-9459-67062 REV A



IIN OID TYP Format Revision PTYP FTOT Time Restriction Code Priority Valid on Day Ticket Flags Product type WEFDate WEUDate

The data will be accessed using the IIN, OID, TYP, Format Revision and PTYP read from the ITSOcard being processed; in the case of a TYP24 IPE, the FTOT field is also considered. If no recordexists that exactly matches this combination, then the product must be considered as invalid.

As the applicability of each record can be controlled by date, it is possible to have multiple entries for acombination of IIN, OID, TYP, Format Revision and PTYP, where one expires on a particular date andanother becomes valid on the day after the other entry expires. Therefore it may be necessary to scanall records to confirm a match for a given product on a given date.

13.1.1 IIN



13.1.2 OID



13.1.3 TYP



14 (concession pass) 16 (concession pass) 22 (area based season ticket) 23 (pre defined specific journey ticket) 24 (pre defined specific journey ticket, potentially with multiple operator availability)

13.1.4 Format Revision



13.1.5 PTYP



13.1.6 FTOT


FTA-FP039-9459-67062 REV A





13.1.7 Time Restrictions


The Time Restrictions field is used to indicate that a product has restrictions, when the TYP does notdefine fields for this purpose, and provides an indicator to a separate table where the actual timerestrictions can be specified – see section 9. This Time Restrictions code is used in conjunction withdestination information and the day type to look up the actual time restrictions to be applied to theproduct.

For a TYP 24 product, the time restriction can be indicated using the 2-character ATOC Restrictionsfield. Hence for a TYP 24 product, the special value of 0xFF will be used here, indicating that theATOC Restriction Code should be used instead to determine the index to the time restrictions data(see 10).

For a TYP 22 or TYP 23 product, ATOC has defined multiple day profiles using the ValidityCode field,ref [2]. The field in this table allows a special value of 0xFE to use a separate look-up based on thecontent of this IPE field (see 11), however if this is not set then the time restriction code (if set) will beused and the ValidityCode field in the IPE will be ignored.

Permissible values:

0 – at any time 1 – 63 – valid only outside the time restrictions specified (value is used to look up time

restriction base data) 0xFE – use ValidityCode bits (where TYP is 22 or 23) 0xFF – not applicable (where TYP is 23)/use ATOC Restriction Mapping (where TYP is 24)

13.1.8 Priority


The Priority field allows the product to be given an order of precedence that can be considered whenmaking a choice between multiple products that otherwise have similar validity. The range ofpermissible values is from 1 to 31, where 1 is the highest.

As an example, a staff pass might be set at level 1, a season as level 2, a Single as level 3 and aReturn as level 4. In this case, if all products are valid for a given journey, then the staff pass will beused in preference. If there is no staff pass then the season will be used and hence the Single andReturn products will remain unused.

13.1.9 Valid On Day





FTA-FP039-9459-67062 REV A






13.1.10 Ticket Flags


Defines extra controls associated with this product type, depicted as a bitmap:

Bit 0 : when set, allows passback for this product, i.e. it turns off the passback check Bit 1 : Reserved, set to zero Bit 2 : when set, defines that a TYP 23 product is a Return. If clear, the TYP 23 product is a

Single. Ignored when the TYP is other than 23 Bit 3 : Reserved, set to zero Bits 4 - 7 : Reserved, set to zero

13.1.11 Product type


The product type field defines the type of business logic to be applied to the product.

Permissible values:

0 – single 1 – return 2 – season 3 – staff pass 4 – concession pass 5 – ENCTS pass

13.1.12 WEFDate



13.1.13 WEUDate



13.2 SNCODE MAPPING

Bus and Tram validations will be recorded on the ITSO card using the ITSO LOC2 data structure, withLOCDEF 209. This structure incorporates part of the OID, with a 4-digit alphanumeric service code(SNCODE) and a byte stage indicator. As the SNCODE cannot store the full range of alphanumericcharacters, there is a need to translate the actual service ID for bus into an equivalent SNCODE.Similarly for tram, current tram stops use an NLC, but there needs to be a translation to an equivalentSNCODE and farestage.

SNCODE is used to represent a 4-digit route code, with restrictions specified in [3] part 1, reproducedhere:

SNCODE consists of four 5-bit characters; each character can represent a number or an alphacharacter. Any unused character will be loaded with 1F hex (space).

Code (hex) Character Code (hex) Character Code (hex) Character

FTA-FP039-9459-67062 REV A



0 0 A A 14 M

1 1 B B 15 N

2 2 C C 16 P

3 3 D D 17 R

4 4 E E 18 S

5 5 F F 19 T

6 6 10 G 1A V

7 7 11 H 1B W

8 8 12 K 1C X

9 9 13 L 1D Y

1E Z

1F space

13.3 TRAM ROUTE LOOKUP

The Tram Route Lookup table is used to convert the NLC of a tramstop to an equivalent route code(SNCODE) and farestage to be encoded on the ITSO card. In this context, farestage does notrepresent a true farestage, but rather is a stop indicator.

Applicability: Global

Data structure: Tramstop ID (4 bytes), SNCODE (20 bits stored as the least significant in a 3-bytebinary value, with the unused top 4 bits set to zero).

The table is global, so it allows all validation devices, whether rail, bus or tram, to identify individualtram stops. Whilst this may not be strictly necessary for initial implementation, it does not requiresignificant data storage and is therefore considered useful for potential future development.

There will be one record for each tram stop.

13.4 BUS ROUTE LOOKUP

The Bus Route Lookup table is used to convert the actual service ID of a bus to an equivalent routecode (SNCODE) for use in the ITSO environment. This is required as the ITSO encoding cannothandle all alpha characters. It is also used to identify whether a route is a nominated tram feederservice.

Applicability: Bus, Tram only (common across all Bus and Tram locations)

Data structure: Service ID (4 bytes), SNCODE (20 bits stored as the least significant in a 3-bytebinary value, with the unused top 4 bits set to zero) logically OR-d with 0x800000 ifthe service is a designated tram feeder, i.e. the top bit is set for a tram feeder orclear if not.

The table is global within the Bus and Tram domains, but is not required for Rai l validation devices.

There will be one record for each Bus Route.

13.5 EMERGENCY RAIL ITSO PRODUCT INFORMATION

Applicability: Bus, common across all Bus locations

FTA-FP039-9459-67062 REV A



This table defines all Rail acceptable products, and therefore the products which can be considered asacceptable on a Bus if it is operating in Emergency mode. If an entry is not found that matches aproduct read on an ITSO card, then that product will be considered as invalid.


IIN OID TYP Format Revision PTYP FTOT Valid on Day WEFDate WEUDate

The data will be accessed using the IIN, OID, TYP, Format Revision and PTYP read from the ITSOcard being processed; in the case of a TYP24 IPE, the FTOT field is also considered. If no recordexists that exactly matches this combination, then the product must be considered as invalid.

As the applicability of each record can be controlled by date, it is possible to have multiple entries for acombination of IIN, OID, TYP, Format Revision and PTYP, where one expires on a particular date andanother becomes valid on the day after the other entry expires. Therefore it may be necessary to scanall records to confirm a match for a given product on a given date.

This table is expected to hold entries for all products defined in the ITSO Product Information tablesacross the system (see section 3 above), although this table only holds a subset of the fields.

13.5.1 IIN



13.5.2 OID



13.5.3 TYP



14 (concession pass) 16 (concession pass) 22 (area based season ticket) 23 (pre defined specific journey ticket) 24 (pre defined specific journey ticket, potentially with multiple operator availability)

13.5.4 Format Revision



13.5.5 PTYP


FTA-FP039-9459-67062 REV A




13.5.6 FTOT




13.5.7 Valid On Day








13.5.8 WEFDate



13.5.9 WEUDate



14. BUS CONFIGURATIONApplicability: Bus subsystem (global across all buses)

This base data contains bus subsystem information regarding times to be applied within other tests.

ITSO Bus End of Day time TfL ENCTS Pass Restrictions Local Authority ENCTS Pass Restrictions

FTA-FP039-9459-67062 REV A



14.1 ITSO BUS END OF DAY TIME


Time at which traffic days end for the purposes of ITSO bus validations, expressed as the number ofminutes past midnight. For example, if a day extends from 00:00:00 up to 4:30am the next day, this isset to 1710. Note that traffic days are always considered to start at 00:00:00.

14.2 PASSBACK TIME/DISABLE



This value is always used in preference to any encoded passback time limit that may be encoded onan IPE.

By default, passback checking is applied unless either (a) the value of this field is zero or (b) the datain the ITSO Product Information table (3) turns passback checking off for a particular product.

The field contains the maximum number of minutes within which (less than or equal to) passback canbe detected, hence if a passenger completes the sequence that would result in a passback detectionwithin this time a passback will be detected, otherwise not.

14.3 TFL ENCTS PASS RESTRICTIONS

Data structure: byte (number of restrictions) followed by records of 5 bytes each, allocated as:

Day type (byte)

Restriction start time (word)

Restriction end time (word)

This data is used to control ENCTS pass acceptance within the TfL travel area, i.e. all locations wherethere is no specific Local Authority restriction time specified.

Day type allows specification of different restrictions by day, where:

0 = Weekday (Monday – Friday)

1 = Saturday

2 = Sunday

3 = Bank Holiday

The start time and end time are specified as a number of minutes past midnight, and any ENCTS passvalidation occurring between the start and end time inclusive will be rejected.

14.4 LOCAL AUTHORITY ENCTS PASS RESTRICTIONS

Data structure: word (number of restrictions), followed by records of 14 bytes each, allocated as:

Service ID (4 bytes)

Start location (word)

End location (word)

Day type (byte)

Restriction start time (word)

Restriction end time (word)

Validation result

Service ID is the ID of the current bus route, which the reader will use to establish whether there areany restrictions applicable.

Start location is the fare stage from which the restriction applies; 0 will represent the start of route,

End location is the fare stage after which the restriction no longer applies; 0 will represent the end ofroute.

Day type allows specification of different restrictions by day, where:

FTA-FP039-9459-67062 REV A



0 = Weekday (Monday – Friday)

1 = Saturday

2 = Sunday

3 = Bank Holiday

Restriction start time is specified as the number of minutes past midnight where the restriction applies.

Restriction end time is specified as the number of minutes past midnight after which the restriction nolonger applies.

Validation Result represents the outcome of the restriction; 0 means that the validation will fail, 1means that it will pass. This is required to permit a Local Authority restriction to override the TfLstandard data if necessary.

If a validation of an ENCTS pass is attempted that falls within the location, day type and time specified,then it will be rejected or accepted according to the Validation Result field..

If there is no restriction found that matches the day, time and location of the current validation, thenthe restriction is applied according to the TfL ENCTS Pass Restrictions data.

FTA-FP039-9459-67062 REV A