Issued at Revision A, on 22-03-11, by R.W. Easterby under ECN 9459-90068
Note: Refer to the applicable ECN (Engineering Change Note) for approval authorities, signatures anddocument distribution.
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.
[3] 9459 60012 DfT Business Rules – Travelcard and Single Scenarios
[4] 9459 60013 DfT Business Rules – Return and Season Scenarios
[5] 3094 60002 DfT Business Rules – Multiple Tickets Scenarios
[6] 9459 60009 DfT Product Definitions in London
[7] 9459 11001 RSPS3002 V01-02-A ATOC ITSO in National Rail – Specification
[8] 9459 67062 DfT - IOP Business Rules Phase 3 IOP Ticket Logic Base Data
[9] ITSO Certification and Testing Rail POST Equipment V3
0.7 GLOSSARY
ATOC Association of Train Operating CompaniesCMD Customer Media Definition (ITSO)CRC Cyclic Redundancy CheckCTSL Cubic Transportation Systems LimitedDfT Department for TransportEEI Entry/Exit Indicator (ITSO)EOSI Emergency Out of Station Interchange
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
FTOT Fares Type of TicketFVC Format Version Code (ITSO)IIN Issuer Identification Number (ITSO)IOP ITSO on PrestigeIPE Integrated Product Entity (ITSO)ISSN ITSO Shell Serial NumberITSO An organisation that has specified a UK Smartcard standard for transport useOID (ITSO) Operator Identification numberOSI Out of Station InterchangePTYP IPE Sub-Type (ITSO)RFU Reserved for future useTfL Transport for LondonTOC Train Operating CompanyTT Transient Ticket (ITSO)TYP IPE Type (ITSO)VG Value Record Group – optional data associated with a specific IPE (ITSO)
0.8 OUTSTANDING ITEMS
None.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
5. CARD STATE TESTS 115.1 DETERMINE PREVIOUS USAGE TYPE 115.2 PREVIOUS USE HERE? 115.3 INSIDE SYSTEM? 115.4 LAST VALIDATION ON TRAM? 125.5 LAST VALIDATION ON BUS? 125.6 PREVIOUS USE AT AUTODIRECTIONAL DEVICE? 12
6. IPE ACCEPTABILITY TESTS 126.1 IPE TYPE TEST 126.2 IPE EXPIRY TEST 136.3 IPE STATE TEST 13
6.3.1 TYP23 136.3.2 TYP24 14
6.4 TEST/LIVE 146.4.1 TYP22 146.4.2 TYP23 146.4.3 TYP24 156.4.4 Test OID 15
6.5 BUS EMERGENCY IPE TEST 156.6 IPE SEAL TEST 15
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
6.7 ACCEPT ALL TICKETS IN? 156.8 ACCEPT ALL TICKETS OUT? 15
7. HISTORY TESTS 157.1 BUS PASSBACK DETECTED? 157.2 PASSBACK DETECTED? 167.3 ZIGZAG DETECTED? 177.4 OSI EXIT PERMITTED? 187.5 OSI RE-ENTRY PERMITTED? 187.6 EOSI EXIT PERMITTED? 197.7 EOSI RE-ENTRY PERMITTED? 207.8 INTERCHANGE EXIT PERMITTED? 207.9 INTERCHANGE RE-ENTRY PERMITTED? 207.10 BOJ EXIT PERMITTED? 217.11 BOJ RE-ENTRY PERMITTED? 217.12 CONTINUATION ENTRY PERMITTED? 217.13 CONTINUATION EXIT PERMITTED? 227.14 TRAM RE-ENTRY PERMITTED? 227.15 TRAM TO RAIL TRANSFER PERMITTED? 23
8. GEOGRAPHY TESTS 238.1 ZONE VALID HERE? 238.2 HERE=ORIGIN? 248.3 HERE=DESTINATION? 248.4 HERE ON ROUTE? 248.5 ORIGIN VALID FOR THIS EXIT? 258.6 DESTINATION VALID FOR THIS ENTRY? 258.7 CONTIGUOUS TICKETS? 258.8 MINIMUM ZONES COVERED? 268.9 NO GEOGRAPHY CHECKS 268.10 WITHIN RAIL-TRAM CHECK IN TIME? 268.11 TRAM PRODUCT VALID HERE? 26
9.4.1 Direction-specific time restriction 309.5 WITHIN MAXIMUM JOURNEY TIME? 309.6 WITHIN MINIMUM JOURNEY TIME AT SAME LOCATION? 319.7 ENCTS RESTRICTED? 319.8 WITHIN TRAM MAXIMUM JOURNEY TIME? 31
10. PRODUCT PRIORITY 3110.1 PRIORITY: DON’T CARE 3210.2 PRIORITY: TICKET PRIORITY 3210.3 PRIORITY: SOONEST END OF VALIDITY 3210.4 PRIORITY: LOWEST MONETARY VALUE 3210.5 PRIORITY: CONCESSION 3210.6 PRIORITY: REJECT IF NO DECISION 32
11. VALIDATION MODE TESTS 3211.1 TRANSPORT MODE 3311.2 VALIDATION DIRECTION 33
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
This document defines all the business logic tests that will be applied to ITSO cards read within the IOParea. The tests therefore represent the common business logic that can be applied to ITSO products thatwill be accepted within the IOP area by agreement between TfL, ATOC and the DfT.
Where TOC-specific products may be agreed to be accepted within the IOP area, these will be covered byseparate commercial agreements, and therefore may require ticket logic tests that are not defined in thisdocument. The Ticket Logic process is defined to be extensible such that additional tests can be developedand applied in such cases, however the definition of these tests is beyond the scope of this document.
Tests identified in this document will be applied in the sequence identified in [1].
This document does not concern itself with basic card data integrity checks. These should be applied asrequired for the appropriate medium, and ITSO data structure integrity should be confirmed according to theITSO specification [2].
The tests specified in this document are intended to address all scenarios identified in [3], [4] and [5], andseek to implement the business rules identified in [6]. In general, the tests identified within this document areintended to be a superset of those identified within these referenced documents.
This document provides extra detail beyond some basic premises established by ATOC for ITSO cardoperation in rail [7]. In general, the tests and processes defined within this document are intended to becompatible with [7], however there are tests and processes within this document that go beyond those in thecurrently published version of [7] and hence the documents will not match exactly.
This document seeks to define all the individual business logic tests that will be applied to ITSO products.However, the actual application of tests may vary between cards, product type, etc. If tests are known to beapplicable only to particular products or versions of those products, then this will be stated within thedescription of the test. Some tests may operate differently depending on the product being considered;again any such differences will be described under each test where relevant.
Whilst this document will define pass and fail criteria, it will not seek to define exactly what might bedisplayed to a passenger, or recorded within the system, when a failure occurs. The display may simply be ared/green indicator and/or audible warning, however there may be occasions when the system developer oroperator might find it useful to capture or display more detail regarding the actual failure. Such decisionsregarding the level of data display and capture will be left to the system developer.
The base data required to support these tests is defined in [8]. The data has been separated from the teststhemselves as this allows for optimal data structure, where data for several tests might be grouped togetherto improve efficiency.
ITSO and RSP certification testing will be performed according to [9].
1.2 ALIASING
Aliasing is a feature that allows a station to accept tickets on behalf of a neighbour station, for example whenthere is an emergency closure of a particular station. This feature requires base data to be defined that willallow the station to extend certain of its ticket logic tests to allow tickets to be used that would not normallybe valid, provided they would be valid at the station for which this station is aliasing. Validators will acceptcontrols which enable/disable aliasing, though by definition any station can only alias for a station orstation(s) for which it already holds the aliasing base data.
A station can alias for up to ten other stations, though this is unlikely to be used in practice.
This document identifies which tests can be affected by aliasing settings, however in summary the followingcan be affected:
“Here” NLCs “Here” Zones “Here” Routes OSI Partners
Note that it is possible for a station that is not normally involved in OSI to become involved as a result ofaliasing.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
The table which defines aliasing data, including potential partner stations, is the “Alias Station Configuration”table.
1.3 ITSO CARD DATA FIELDS
It is noted that the ITSO card data format results in certain data, which is highly desirable for implementationof tests, not being available depending on the product being validated. An example is the Location of LastValidation, which would ideally be available for passback and zigzag tests; however this field has only beendefined in the IPE 24 Value Group. Consequently, certain tests may work more reliably with one IPE thanwith another.
This document specifies, for the business logic tests, where the data fields on which the test relies will beused, and will identify any differences as a result of processing different IPEs.
1.4 VALID RAIL TT
The sequence of tests applied to a card will usually depend on the card state prior to the validation.Document [7] states that usage information resulting from previous validations of a card is only valid if theITSO card contains a Rail Transient Ticket, which is defined to be format revision 4 only. Hence onpresentation, the card will always be checked for a valid TT with format revision 4. If such a TT exists, itsseal will be checked; if valid then the tests described in this document will be applied to retrieve currentusage information from the TT. If there is no TT, if the format revision is less than 4, or if the seal is invalid,then processing will continue on the basis that no Rail TT is present.
The effect of this is that if no valid Rail TT is detected, then when the card is presented, it will be consideredas though it has not had any prior validations; passback and zigzag checks will not apply, and by definitionno journey can be in progress. In this case, the “inside system” test, though it normally uses data within theITSO card other than the TT, will also change to show “outside system”.
1.5 USAGE OF THE RAIL TT
ATOC/RSP has provided information regarding the availability of Rail TT fields; this is reproduced in section19.4 of this document, updated as per the following agreement. Following discussion with ATOC, it has beenagreed that the TT CIPE data group will be retained when an exit TT is written, and that two currently “RFU”flags within this data will be used to indicate status that may be required for further validation, i.e.Continuation Exit and EOSI. The information in section 19 has been updated to reflect this decision.
Note that the presence of the TT CIPE data group in an exit TT is only defined within the IOP area;validations within the IOP area must therefore allow for the condition where an exit TT is written by a non-IOP device and therefore that the TT CIPE data group may not be present. If not present, the default flagvalues will be assumed, i.e. the exit validation was not by an autodirectional device and not in emergencymode.
1.6 ITSO CARD AND IPE STRUCTURAL TESTS
This document does not specifically identify tests which are required to confirm correct structure of an ITSOcard and its various elements, for example the presence or otherwise of data groups that are indicated byflags designated in the ITSO specification for IPEs. Any such test should be applied to confirm correct datastructure as defined in the ITSO Specification [2], and any detectable structural error will result in the cardbeing rejected unless the error applies to an IPE where there is an alternative, valid, IPE available.
1.7 HOTLISTING AND ACTIONLISTING
Hotlisting and actionlisting are outside the scope of this document.
The CMD Whitelist test (see 3.1) will be applied before any hotlisting or actionlisting action.
It is assumed that any hotlisting or actionlisting required for a card will be applied before the remainder ofthe business rules described in this document are applied.
2. CARD LEVEL TESTSThe following general checks will be applied to the shell on any ITSO card that is presented:
Check that the directory is not corrupt Check that the Shell CRC is correct Check that the Shell has not expired Check that the Shell version is compatible
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Note that the IOP project does not support hotlisting and actionlisting in the live environment, therefore nochecks will be defined to restrict acceptable shell issuers or operators (IIN, OID).
2.1 DIRECTORY INTEGRITY CHECK
This is a card-level test to determine that the card directory is not corrupted. The nature of the test willdepend on the particular card medium in use, and will not be described further here.
If the directory integrity check fails, the card will be rejected without further processing.
2.2 ITSO SHELL INTEGRITY CHECK
The ITSO Shell Environment CRC (SECRC), as defined in [2] part 2, will be confirmed to ensure that theITSO Shell is valid.
If this test fails, the card will be rejected without further processing.
2.3 ITSO SHELL EXPIRY CHECK
The ITSO Shell Expiry Date, as defined in [2] part 2, will be checked against the validation device’s clockwhen the card is read. If the date is less than today’s date, then the card will be rejected without furtherprocessing. Note that it is possible for a Shell to be encoded with no expiry date, in which case this test shallbe deemed to have passed.
2.4 ITSO SHELL BLOCK CHECK
The ITSO Shell, as defined in [2] part 2, will be checked to determine whether or not the shell is blocked. Ifthe shell is blocked, then the card will be rejected without further processing.
3. CMD ACCEPTABILITY TESTSIt is not intended that CMD acceptance should allow flexible definition of the processing applicable to thatCMD. Any specific data structures, read/write rules or security that are dependent on the particular CMD willbe handled within the card reader code.
Consequently the only base-data driven test will be to confirm that a given CMD is acceptable at the currentreader’s location.
3.1 CMD WHITELIST
The first business logic test is to confirm that the CMD type is acceptable, and shall be applied before theITSO Shell is parsed. This is established by checking the Format Version Code (FVC) encoded in the ITSOShell against a list of acceptable CMDs, which will be in base data defined at station level, see [8] “CMDWhiltelist”.
The data will be a whitelist, containing the following elements:
CMD (FVC) number Date on and from which it is acceptable, or special value if no limit Date before and on which it is acceptable, or special value if no limit
Applying dates to each record allows for the possibility of controlling CMD acceptance, e.g. to permit aparticular CMD after a specified date, or to enforce expiry of a CMD by date, regardless of how the shell orproducts may be encoded. In general, it is expected that this list will not have specific limits to the dates, northat it will vary between stations, however this allows for flexibility in system control, potentially to a TOClevel.
4. VALIDATOR PRESENTATION TESTThere is one low-level test that is applicable only at a Validator – as opposed to a gate – and is appliedbefore checking any of the products on a card. This is the multi-presentation test, which depends on a timeset in global base data; the test considers the previous validation of the ITSO card.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
The test is intended to prevent accidental repeat validations, and its effect is to show the same display to thecustomer but without updating the card or generating any transactions if the previous and current uses areboth at an autodirectional device at the same station and within the time limit set in base data.
This test cannot be implemented using product or TT data on the ITSO card as the card does not store thetype of validation (i.e. “autodirectional” cannot be identified), and only the TYP24 supports guaranteedstorage of the validation location.
The test will therefore be Validator-specific; the Validator will maintain a list of ITSO cards where thevalidation resulted in an “accept”, using the ISSN read from the shell, and their times of validation. Dataretained in the list must allow the validating device to restore all its displays to the same condition that wouldhave been shown as a result of the original validation, considering both passenger-facing and staff-facing (ifpresent) elements. The list will be maintained up to the time limit set in global base data. When a card ispresented, the Validator will check against this list and if found, no further card processing will occur but an“accept” display will be provided.
If the card is not found on the list, then the card will continue to be validated as for any other card.
Note that if a card validation previously failed, it is appropriate to process the card as normal on anysubsequent validation as it is possible that a time-based restriction caused the first failure.
A side effect of this implementation is that it only applies to one Validator since the list of cards is not sharedbetween validation devices at a station.
5. CARD STATE TESTSThe sequence of tests applied to a card will usually depend on the card state prior to the validation.
This information is obtained from a combination of Rail TT, IPE VG (depending on the IPE) and data in theITSO Log directory.
5.1 DETERMINE PREVIOUS USAGE TYPE
This test considers the usage type encoded in the Rail TT. Usage of certain values originally within ITSODevelopers’ Guides has been updated by [7]. Values of relevance to ticket logic are:
Check in (11) Check out (12) Undo previous event without refund (3) Inspected (0) Break of Journey Out (8) Break of Journey In (14)
Any other values present in the TT will cause the test to return as “No Rail TT”.
Note that the original ITSO definition of the value 0 was “not specified”; it is not clear whether ATOC’s re-definition of this to mean “inspected” is valid in all cases, i.e. if so then 0 could mean that the card is in-system.
A further consideration is required to separate a Rail TT from a Bus or Tram TT. As ITSO has failed tospecify fields in the usage type which will allow this distinction, it is necessary to consider other fields in theTT; for this purpose the TTDestination field will be considered. If this field contains a LOCDEF value otherthan 203, 208 or 255 then the TT is not Rail, and distinction of the last validation type/location is determinedby tests 5.4 and 5.5. Hence if a TTDestination field is found that is not Rail, the test will also return as “NoRail TT” regardless of the recorded TT Transaction Type.
5.2 PREVIOUS USE HERE?
This can only be determined when the IPE used for the previous operation was a TYP24, since the locationof previous validation is not stored in anything other than the TYP24 Value Group. Hence, this test will onlyreturn TRUE when the IPE used for the previous validation is a TYP24 and when the location of previousvalidation read from the IPE 24 VG matches this station’s NLC.
5.3 INSIDE SYSTEM?
This will be determined by reading the EEI status in the Log directory. This may be required since the valueof “Undo Previous Event without Refund” in the TT may apply to a product that is either inside or outside thesystem.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
If EEI is 0, then the card is considered as outside the system, i.e. the last operation was an exit. If EEI is anyother value, then the card is considered as inside the system, i.e. the last operation was an entry.
Note this test is modified if no valid Rail TT is found on the ITSO card, in which case the card is consideredto be outside the system regardless of the current EEI setting.
5.4 LAST VALIDATION ON TRAM?
When a Tram validation is performed, the location is stored in the TTDestination field using LOCDEF 209,where the tram service ID is identified using an alphanumeric route code, and each tram stop is identified asa farestage. The tram service ID and tram stop are determined from a Base Data lookup that converts thetramstop NLCs to these values for card usage (the “Tram Route Lookup” table).
This test checks whether or not the last recorded validation location is LOCDEF 209 using a code that existsin the “Tram Route Lookup” table. Hence any tram route in this table will be identified.
5.5 LAST VALIDATION ON BUS?
When a Bus validation is performed, the location is stored in the TTDestination field using LOCDEF 209.The bus service ID is determined from a Base Data lookup that converts the actual service IDs to the valuesfor card usage (the “Bus Route Lookup” table).
This test checks whether the previous validation is on Bus, i.e. the TTDestination field is a LOCDEF 209, butthe SNCODE part of the field is not contained within the “Tram Route Lookup” table.
5.6 PREVIOUS USE AT AUTODIRECTIONAL DEVICE?
This test is required to enable Continuation Exit and OSI re-entry correction functions, the latter being whena first entry is recorded at a Validator which is an OSI partner of, and within the OSI time limit of, thisvalidation location.
This test relies on allocation of a flag within the ITSO TT to indicate the use of an AutoDirectional device.ATOC has confirmed that CIPEFlags bit 2 will be used for this purpose within IOP devices.
If the flag in the TT that indicates the previous usage was at an AutoDirectional Device, this test will returnTRUE, otherwise it will return FALSE.
6. IPE ACCEPTABILITY TESTSThe business rules defined later within this document concern themselves with the data contained withinIPEs, however there are some basic checks that must be performed on an IPE to confirm that it is valid forprocessing, regardless of product content.
The following checks will be applied to all IPEs considered during validation:
Check that the product has a valid TYP and PTYP Check that the product has not expired
Additionally, an IPE seal check will be considered if an IPE (or multiple IPEs at exit) is determined to beapplicable to the current validation. This seal check will always be performed if the validation is an exit, butwill be configurable for entry processing.
6.1 IPE TYPE TEST
The IPE OID, TYP and PTYP effectively define the product, and hence processing required, contained in anIPE. Base data, which is station-specific, will define a whitelist of product data that the reader can accept;this will be contained in the ITSO Product Information table (ref [8]). Data within each record will control thedate range where the particular product is acceptable, and will also specify a priority order. This priorityorder will be used when multiple products are considered acceptable for the same journey, and an algorithmwill use this priority data along with other information to determine a single candidate product (subject toconfiguration).
There will be one record in the ITSO Product Information table for each combination of IIN, OID, TYP,Format Revision and PTYP – and for TYP24, for each individual FTOT. If an IPE is read from the ITSO cardthat is not contained in this list, or if the date controls within the matching record do not cover the date onwhich the validation is performed, then it will be considered as invalid.
This is determined by creating an index based on the following:
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
IIN OID TYP Format Revision PTYP FTOT (only if IPE is TYP24)
The index is used to look up the “ITSO Product Definitions” table. If no matching entry is found, then the IPEis invalid.
If a match is found, then additional data relating to the product is read from the table:
Time Restriction Code Priority Valid on Day Ticket Flags Product type LU reporting
Some elements of this data will be used within further tests, i.e. Time Restriction Code, Priority, Valid onDay, Ticket Flags.
The Product Type is used to control the basic ticket type logic, i.e. it can identify a Single, Return, Season,Travelcard or pass, and subsequent tests may be affected by the Product Type so identified.
LU Reporting is not used within the business logic, but is required for internal data reporting purposes.
6.2 IPE EXPIRY TEST
An individual IPE will be determined to be valid “today” if all of the following are true:
The start date (if present) read from the IPE is “today” or before The end date (if present) read from the IPE is “today” or after The IPE expiry date read from the ITSO directory is “today” or after
The presence or otherwise of the fields above will depend on the particular IPE TYP being considered.
In the case of a Return ticket encoded in a TYP24 IPE, there are different fields controlling expiry of theoutward portion and the return portion. The ticket logic will determine whether the usage of the ticket is forthe outward or return leg (see 6.3.1 and 6.3.2), and will use the appropriate fields to determine the validity forthat leg (see 9.1).
Note that for certain IPEs, e.g. TYP16, there can be a null value specified for expiry – in this case the IPE isdeemed always to be valid.
6.3 IPE STATE TEST
If an IPE is treated as a Single or Return ticket, then the state of the IPE – i.e. its usage – must beconsidered.
Where IPE usage information is required, for example the number of journeys remaining, it is always storedin an associated Value Group on the ITSO card, and applies for a TYP23 or TYP24 product.
If the VG for a TYP23 is not present, then the product will be considered as invalid with no further checks. Ifthe VG for a TYP24 is not present, and if the product is a Single or Return, then the product will beconsidered as invalid with no further checks. A TYP24 season or pass product is considered acceptable –subject to any other constraints - whether or not it has a VG present.
The test outcomes – unused, Return leg – will affect certain other geography tests, as origin/destinationfields may need to be considered differently for direction of travel (see 8.2, 8.3). If the test outcome showsthat a product is fully used, it will be rejected.
6.3.1 TYP23
If the product is a TYP23, then the “CountRemainingJourneyRides” field in the VG is used to show thecurrent state, with values interpreted as follows:
2 – unused Return ticket 1 – Return ticket used on outward leg, or Single ticket (see “UsedChecked” below) 0 – ticket fully used
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
One of the “TYP23ValueFlags” is also considered: bit 1, “UsedChecked”. This flag is only of relevance whenthe “CountRemainingJourneyRides” field is set to 1; in this case, if “UsedChecked” is 0 then the product is aSingle; if the “UsedChecked” is 1 then the product is a Return on its Return leg, and hence Origin/Destinationcan be properly checked. Note that the distinction of the product being single/return should also be availablefrom data in the ITSO Product Information table.
6.3.2 TYP24
If the product is a TYP24, then the “JourneysRemaining” and “JourneyPartUsed” fields in the VG are used toshow the current state, with values interpreted as follows:
JourneysRemaining:
2 = unused Return ticket (if “ProductTypeEncoding” = 1 in main IPE) 1 = Return ticket used on outward leg (if “ProductTypeEncoding” = 1 in main IPE) 1 = Single ticket (if “ProductTypeEncoding” = 0 in main IPE) 0 = ticket fully used
JourneyPartUsed:
1 = ticket has been used, but not to its destination, i.e. exit was BOJ out or OSI exit 0 = ticket unused or last leg exit was at destination.
Note that “JourneysRemaining” must be considered against “ProductTypeEncoding” in the main IPE toestablish whether the product is a Single or a Return and which leg is currently in progress, such that Originand Destination can be properly considered.
The TYP24 VG also contains a “JourneyPartUsed” flag, which is set on any intermediate exit, i.e. OSI exit,interchange exit, EOSI exit or BOJ exit. This condition is not used during validation checks or productcandidate selection.
6.4 TEST/LIVE
IOP Business Rules require that test and live products will both behave in the same way for validationpurposes, however the reader may need to know that it is processing a test product for purposes ofaccounting and generation of usage data within the system.
For a TYP14 or TYP16 product, there is no test/live indicator and therefore these products are alwaysconsidered to be live, unless identified via the Test OID.
6.4.1 TYP22
For a TYP22 product, the test/live status is determined from the value of bits 4 and 0 in the ValidityCodefield:
Bit 4 Bit 0 Meaning
1 0 Test mode
1 1 Live mode
0 0 Undefined
0 1 Undefined
If the bit combination shows “undefined” then the product will be considered invalid for use.
6.4.2 TYP23
For a TYP23 product, the test/live status is determined from the value of bits 4 and 0 in the ValidityCodefield:
Bit 4 Bit 0 Meaning
1 0 Test mode
1 1 Live mode
0 0 Undefined
0 1 Undefined
If the bit combination shows “undefined” then the product will be considered invalid for use.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
For a TYP24 product, the test/live status is determined from the value of bit 5 in the TYP24Flags. If this isset then it is a test product, otherwise the product is live.
6.4.4 Test OID
Regardless of whether or not a product is marked as Test, if the OID of the IPE or the card is found withinthe Test OID list in the “Global Settings” table then the product, or all products on the card if the card issuerOID is matched, will be considered as test products.
6.5 BUS EMERGENCY IPE TEST
If a Bus Validator is operating in Emergency mode, then Entry will be permitted when there are no valid Busproducts, but there is a valid Rail product on the ITSO card. In this case, reduced tests will be applied to theproduct, however this test will pass if any IPE on the card matches an entry in the “Emergency Rail ITSOProduct Information” table, and if any day restrictions for that product make it valid on the date of validation.
6.6 IPE SEAL TEST
An IPE seal check will be considered if an IPE (or multiple IPEs at exit) is determined to be applicable to thecurrent validation. This seal check will always be performed if the validation is an exit, however the sealcheck may be configured not to be applied during entry processing, as this allows for a quicker customerinteraction. This setting will be configurable through base data at station level (within the “StationConfiguration” table) as different operators may take a different view as to whether entry to the systemshould be allowed without confirming whether an IPE used to grant the entry is genuine.
Note that the seal is required as part of anti-tear processing for a Type A card, and that it may therefore notbe advisable to disable this function. Disablement may also lead to difficulties in ITSO certification. Thedisablement feature will remain, however its setting will be considered by ATOC, TfL and ITSO waiver maybe pursued by ATOC and TfL.
6.7 ACCEPT ALL TICKETS IN?
This test checks for the common Oyster/ITSO mode control that will be sent to the reader by the existingmethods. When set, the effect is to override all tests for IPE validity on entry, other than a seal check. Whena product is accepted as a result of this AAT In test, no card update will be performed.
6.8 ACCEPT ALL TICKETS OUT?
This test checks for the common Oyster/ITSO mode control that will be sent to the reader by the existingmethods. When set, the effect is to override all tests for IPE validity on exit, other than a seal check. Whena product is accepted as a result of this AAT Out test, no card update will be performed.
7. HISTORY TESTSThe following tests can all be considered as being related to the history of the ticket use.
7.1 BUS PASSBACK DETECTED?
Passback checking for a Bus validation is complicated by the fact that a TT may not be created for the Busvalidation, therefore two parallel tests will be applied.
Passback detection is enabled unless the data for a specific product indicates that it should be disabled asspecified in the Ticket Flags field of the ITSO Product Information table. Passback checking can also bedisabled for all products by base data setting, i.e. if the Passback Time/Disable value in the BusConfiguration table is set to zero. If enabled, a passback is detected when two validations are attempted atthe same Bus location within a time that is specified in the global bus base data (typically 5 minutes).
The initial check will look for a TT containing a Bus validation; if the location recorded matches the currentlocations, and is within the passback time, then the validation will fail. This operation will protect againstusage between multiple validators on the same bus, but will only be possible where there is no Rail journeyin progress and hence where the bus is allowed to create a TT.
The second check will be based on the ITSO card number, obtained from the ITSO shell (ISSN). Each busValidator will record a list of all ISSNs that have been successfully validated, dropping entries from this listwhere the validation time is older than the passback time. When a new validation is attempted, the ISSN of
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
the card is checked against entries in the list, and if present then passback will be detected. This check willonly protect against multiple attempted usage on the same Validator.
7.2 PASSBACK DETECTED?
Passback is intended to identify when a passenger uses his card and then passes the card to anotherpassenger who attempts to use it again (a.k.a. “passback over”).
Passback detection is enabled unless the data for a specific product indicates that it should be disabled asspecified in the Ticket Flags field of the ITSO Product Information table. Passback checking can also bedisabled for all products by base data setting, i.e. if the Passback Time/Disable value in the StationConfiguration table is set to zero. Note that if any product that is an Entry candidate has passback disabled,this effectively disables passback for all products at Entry.
If enabled, a passback is detected when two operations of the same type are attempted at the same stationwithin a time that is specified in the station level base data (typically 15 minutes).
Hence if a card has been used for entry and another entry is attempted at the same station within thepassback time, then a passback is detected. The process is also applied for subsequent attempted exits,using the same passback time parameter.
Due to lack of data recorded in the ITSO card, this test cannot be applied using location information for allIPEs; for products other than TYP24 the test will use the TT ORGN and TT DESTN fields where available.When no location information is available, the test will be based on time and in/out of system indicators only.This approach may result in occasional incorrect detection of passback status for products other thanTYP24. The following table shows which data fields will be used for location information during passbackchecking.
TYP/Product Operation Passback field
22/Season Entry TT ORGN
22/Season Exit TT DEST
23/SGL/RTN Entry TT ORGN
23/SGL/RTN Exit TT DEST
23/SGL/RTN OSI exit TT DEST
23/SGL/RTN OSI Re-entry Not available
23/SGL/RTN BOJ exit (if allowed) Not available
23/SGL/RTN BOJ re-entry (if allowed) Not available
24 with VG/Any Any VG LocationOfLastValidation
24 no VG/Season Entry TT ORGN
24 no VG/Season Exit TT DEST
14/Pass Entry TT ORGN
14/Pass Exit TT DEST
16/Pass Entry TT ORGN
16/Pass Exit TT DEST
If there is no valid Rail TT then no passback will be detected. If there is a valid Rail TT and the last validation occurred outside the passback time then no
passback will be detected. If there is a valid Rail TT, and where the location of previous validation is available and the last
validation did not occur at the same location then no passback will be detected If there is a valid Rail TT and the last validation occurred within the passback time:
o If this operation is an entry and the card is inside the system (5.3) then passback will bedetected
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
o If this operation is an exit and the card is outside the system (5.3) then passback will bedetected
Note that this test is used for passback checking on Tram validations, as a Tram validation will always write aTT to the ITSO card, unlike a Bus validation. The potentially different Tram validation passback time (whichshould be the same as Bus, rather than rail) is handled by being specified in location-specific base data.
It is noted that ITSO certification may be affected as a result of this approach, i.e. ITSO certification requiresthe passback settings of the products to be used. ATOC and TfL have agreed that ITSO waiver will berequired to allow the stated functionality.
7.3 ZIGZAG DETECTED?
Zigzag is intended to identify when a passenger uses his card, uses it again in the opposite direction oftravel, and then passes the card to another passenger who attempts to use it again (a.k.a. “passbackthrough”).
The application of the zigzag test is controlled for a specific product by data contained in the Ticket Flagsfield of the ITSO Product Information table. Zigzag checking can also be disabled for all products by basedata setting, i.e. if the Zigzag Time/Disable value in the Station Configuration table is set to zero.
Zigzag is normally detected when a sequence of entry – exit – entry or exit – entry – exit is attempted at thesame location within the zigzag time, though noting that the zigzag time is considered only between thecurrent validation and the previous validation, i.e. it does not span all three events. It is noted that in [7],ATOC does not cover zigzag checking for the exit - entry – exit sequence, and does not propose any ITSOdata settings to support this sequence. Therefore this test under IOP will only be applied for the entry – exit– entry situation.
The location of validation is not generally available except for a TYP24 when a TYP24 VG is available torecord the location of validation, though the TT Orgn field is available for use at the first entry of the journeyregardless of product The lack of recorded last validation location means that this test will perform asexpected at the start of a journey, however it cannot be applied at re-entry after OSI, EOSI, BOJ orInterchange. The following table shows which data fields will be used for location information duringpassback checking.
TYP/Product Operation Zigzag
22/Season Entry TT ORGN
23/SGL/RTN Entry TT ORGN
23/SGL/RTN OSI exit Not available
23/SGL/RTN OSI Re-entry Not available
23/SGL/RTN BOJ exit (if allowed) Not available
23/SGL/RTN BOJ re-entry (if allowed) Not available
24 with VG/Any Any VG LocationOfLastValidation
24 no VG/Season Entry TT ORGN
14/Pass Entry TT ORGN
16/Pass Entry TT ORGN
If the current direction is Entry:
Zigzag will be detected if all the following conditions are satisfied:o TT usage = “Undo previous event without refund”o Ticket is outside systemo This validation is within zigzag time of previous validationo If a TYP24 VG is available (determined from IPE24 VG where VG DateTimeStamp matches
the Rail TT), or if the validation location is available from the TT ORGN field, this validationis at the same location as previous validation
For any other combination of data, zigzag will not be detected
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
A potential zigzag will be detected if all the following conditions are satisfied. If this is the case thisstate is marked by restoring the TT to its state prior to entry, but using the TT usage of“UndoPreviousEventWithoutRefund” (3) and setting the time of last processing to “now”:
o TT usage = “Check In” or TT usage = “Break of Journey In”o Ticket is inside systemo This validation is within zigzag time of previous validationo This validation is at the same location as previous validation determined from TT ORGN field
For any other combination of data, potential zigzag will not be detected
7.4 OSI EXIT PERMITTED?
This test is used to determine when a product is allowed exit at an OSI location, i.e. a location other than itsdefined origin or destination that is defined as having OSI partner(s), or being set as a local OSI. Althoughthere is a test defined for this purpose, if an exit is allowed as a result, there is no distinction in theprocessing of the exit, i.e. an OSI exit leaves the card in the same state as a “normal” exit.
A local OSI is configured by device-specific configuration data rather than downloaded base data; the readeris told that it is associated with an OSI “side”, which allows exit through one gateline and subsequent re-entrythrough a different gateline. A local OSI can exist in conjunction with an OSI as defined in base data. AnOSI partnership is identified by the data in the OSI Partners section of the Station Configuration table (ref[8]). An example of a local OSI is at the TOC Liverpool Street station, where it may be necessary to exit onegateline from an arriving train, then to re-enter at a different gateline to board a connecting train. Although allthe gates share the same NLC, the gatelines have different OSI “sides” and therefore such interchange ispermitted. ITSO cards cannot store the OSI side on exit, and therefore no constraint on interchangebetween sides will be applied for a local OSI.
Note that a station that is not an OSI can become part of an OSI as a result of aliasing; this cannot apply to alocal OSI.
An OSI Exit is permitted if all the following are satisfied:
this station has specified OSI partner(s) or is a local OSI there is a valid product on the card that has origin and destination other than “here” (at these points,
a normal Exit will be performed/recorded, although OSI Re-Entry is still possible after an Exit if theproduct has potential onward validity)
the product is a single or a return the product is valid “here” as a result of its encoded route code, or as a result of being determined to
be on route between its origin and destination (see 8.4).
Note that OSI Exit is not relevant for a season or pass product, and also that BOJ settings for a single orreturn product do not affect the consideration of OSI. Hence OSI can apply to a product that is not set toallow BOJ.
Note that this test can be extended or enabled as a result of aliasing, i.e. aliasing can create OSI partners fora station that is not normally an OSI, or it can add more OSI partners.
When an OSI exit is allowed, this will be recorded as a normal exit in the TT.
7.5 OSI RE-ENTRY PERMITTED?
This test is used to determine whether onward travel is permitted for a product that has been allowed exit atan OSI location, i.e. a location other than its defined origin or destination that is defined as having OSIpartner(s), or being set as a local OSI. As noted above, a card that has been allowed exit due to OSI isindistinguishable from a card with a “normal” exit at an OSI location. Therefore the potential re-entry mustlook at the product(s) on the card to determine whether onward travel is permitted, and this will be an OSI re-entry if onward travel is permitted and the previous exit was at an OSI partner or here, if here is a local OSI.
A local OSI is configured by device-specific configuration data rather than downloaded base data; the readeris told that it is associated with an OSI “side”, which allows exit through one gateline and subsequent re-entrythrough a different gateline. A local OSI can exist in conjunction with an OSI as defined in base data. AnOSI partnership is identified by the data in the OSI Partners section of the Station Configuration table (ref[8]). Note that ITSO has no way of storing the local OSI “side” through which an exit has been made, henceunder this scheme OSI re-entry at a station configured for local OSI will be permitted for a card that has
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
made an OSI exit at any “side” at the same station.Note that a station that is not an OSI can become part ofan OSI as a result of aliasing; this cannot apply to a local OSI.
An OSI Re-entry is permitted if all the following are satisfied:
this station has specified OSI partner(s) or is a local OSI the previous use was an exit at this station if a local OSI is configured, otherwise at a station
designated as an OSI partner of this station. The exit location is determined from the “Location oflast validation” in the VG for an TYP24, or otherwise the destination encoded in the Rail TT
the previous use was within the local OSI time or the partner OSI time as appropriate there is a valid product on the card that has origin and destination other than the primary NLC
(“Station NLC”) of this location the product is a single or a return the product is valid “here” as a result of its encoded route code, or as a result of being determined to
be on route between its origin and destination (see 8.4), or is valid because its origin or destinationappears in the list of alternative “here” NLCs for this station, or is valid as a result of having a zonallyspecified origin or destination (see 8.1).
the journey has not exceeded the Maximum Journey Time (see 9.5).
There is also a special case where OSI Re-entry is permitted, and the previous Check In is undone, if all thefollowing are satisfied:
this station has specified OSI partner(s) the previous use was an Entry at a station designated as an OSI partner of this station the previous use was within the partner OSI time the previous use was at an autodirectional device there is a valid product on the card that has origin and destination other than the primary NLC
(“Station NLC”) of this location the product is a single or a return the product is valid “here” as a result of its encoded route code, or as a result of being determined to
be on route between its origin and destination (see 8.4), or is valid because its origin or destinationappears in the list of alternative “here” NLCs for this station, or is valid as a result of having a zonallyspecified origin or destination (see 8.1).
the journey has not exceeded the Maximum Journey Time (see 9.5).
Note that OSI Re-entry is not relevant for a season or pass product, and also that BOJ settings for a single orreturn product do not affect the consideration of OSI. Hence OSI can apply to a product that is not set toallow BOJ.
Note that this test can be extended or enabled as a result of aliasing, i.e. aliasing can create OSI partners fora station that is not normally an OSI, or it can add more OSI partners.
The OSI test must can effectively be overridden by the equivalent Interchange test (see 7.9) as the lattermay be used to extend the OSI time, for example when the wait time between two legs of a booked journeyis greater than the normal OSI time. This distinction is achieved by recording an Interchange exit as a “BOJOut” in the TT.
7.6 EOSI EXIT PERMITTED?
This test is used to determine when a product is allowed exit at a location that has been set to operate inEmergency OSI (EOSI) mode.
An EOSI Exit is permitted if all the following are satisfied:
this station has been set to “Emergency” mode (this is not “Emergency Open”) there is a valid product on the card that has origin and destination other than “here” the product type is a single or a return the product is valid “here” as a result of its encoded route code, or as a result of being determined to
be on route between its origin and destination (see 8.4).
Note that EOSI Exit is not relevant for a season or pass product, and also that BOJ settings for a single orreturn product do not affect the consideration of EOSI. Hence EOSI can apply to a product that is not set toallow BOJ.
When an EOSI exit is allowed, this will be recorded as a normal Exit, though setting the “Emergency” bit inthe TT CIPEFlags (bit 3).
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
This test is used to determine whether onward travel is permitted for a product at a location that has been setto operate in Emergency OSI (EOSI) mode. As ITSO has failed to allocate any data to record the fact thatan exit is an EOSI exit, this test will be based on this station’s current emergency setting combined with thefact that there is a Break of Journey Out recorded on the card.
An EOSI Re-entry is permitted if all the following are satisfied:
this station has been set to “Emergency” mode (this is not “Emergency Open”) the previous use was an exit at a station in emergency mode, indicated by bit 2 of TT CIPEFlags
being set (note that if the TT CIPE data group is not present, then this is treated as not being anemergency)
there is a valid product on the card that has origin and destination other than “here”, where “here”refers to the primary NLC (“Station NLC”) of this location
the product is a single or a return the product is valid “here” as a result of its encoded route code, or as a result of being determined to
be on route between its origin and destination (see 8.4) , or is valid because its origin or destinationappears in the list of alternative “here” NLCs for this station
the journey has not exceeded the Maximum Journey Time (see 9.5).
Note that EOSI Re-entry is not relevant for a season or pass product, and also that BOJ settings for a singleor return product do not affect the consideration of EOSI. Hence EOSI can apply to a product that is not setto allow BOJ.
7.8 INTERCHANGE EXIT PERMITTED?
A TYP24 product can have specified interchange locations encoded within the IPE. These allowspecification of declared breaks of journey, and can have time limits associated. These operate in a similarmanner to OSI, and will potentially override OSI time processing if the interchange point on the IPE matchesa configured OSI. Hence it is possible to effectively create an OSI for a journey through encoding on theIPE, or to extend the interchange times for an existing OSI.
An Interchange Exit is permitted if all the following are satisfied:
there is a valid TYP24 IPE product on the card the IPE specifies this location as an interchange point
Note that Interchange Exit is not relevant for a season or pass product.
When an Interchange exit is allowed, this will be recorded as “Break of Journey Out” in the TT, even thoughit is not technically a BOJ.
7.9 INTERCHANGE RE-ENTRY PERMITTED?
A TYP24 product can have specified interchange locations encoded within the IPE. These allowspecification of declared breaks of journey, and can have time limits associated. These operate in a similarmanner to OSI, and will potentially override OSI time processing if the interchange point on the IPE matchesa configured OSI. In this case the interchange time limit is determined from the IPE data, but only if the timelimit is higher than the base data set value for the OSI; otherwise the base data value is used. Hence it ispossible to effectively create an OSI for a journey through encoding on the IPE, or to extend the interchangetimes for an existing OSI.
An Interchange Re-entry is permitted if all the following are satisfied:
there is a valid TYP24 IPE product on the card the IPE specifies this location as an interchange point the previous use was a Break of Journey Out the time since the previous use is within the value set on the IPE (if there is a time specified) the journey has not exceeded the Maximum Journey Time (see 9.5)
Note that Interchange Re-entry is not relevant for a season or pass product.
The Interchange test must be performed in preference to the equivalent OSI test (see 7.5) as the former maybe used to extend the OSI time, for example when the wait time between two legs of a booked journey isgreater than the normal OSI time. This distinction is achieved by recording an Interchange exit as a “BOJOut” in the TT.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Break of Journey (BOJ) is relevant to single and return tickets only. For a TYP24 IPE product, whether ornot a BOJ is allowed is set by fields within the IPE data, specifically the “TransferEntitlementType” must beset to 2 (ref [7]). For a TYP23 IPE product, BOJ is controlled by data within the “ITSO Product Information”table.
A BOJ Exit is permitted if all the following are satisfied:
there is a valid product on the card that has origin and destination other than “here” the product is a single or a return the product is valid “here” as a result of its encoded route code, or as a result of being determined to
be on route between its origin and destination (see 8.4) if the product is TYP23, then the ”ITSO Product Information” table specifies whether BOJ is allowed if the product is TYP24, the transfer entitlements indicate whether BOJ is permitted (ref [7])
Note that BOJ Exit is not relevant for a season or pass product.
7.11 BOJ RE-ENTRY PERMITTED?
Break of Journey (BOJ) is relevant to single and return tickets only. For a TYP24 IPE product, whether ornot a BOJ is allowed is set by fields within the IPE data, specifically the “TransferEntitlementType” must beset to 2. For a TYP23 IPE product, BOJ is controlled by data within the “ITSO Product Information” table.
A BOJ Re-entry is permitted if all the following are satisfied:
there is a valid product on the card that has origin and destination other than “here” the product is a single or a return the product is valid “here” as a result of its encoded route code, or as a result of being determined to
be on route between its origin and destination (see 8.4) if the product is TYP23, then the ”ITSO Product Information” table specifies that BOJ is allowed if the product is TYP24, the transfer entitlements indicate that BOJ is permitted (ref [7]) the previous use was a BOJ exit the journey has not exceeded the Maximum Journey Time (see 9.5)
Note that BOJ Re-entry is not relevant for a season or pass product.
7.12 CONTINUATION ENTRY PERMITTED?
Continuation Entry is controlled by station-specific base data. It is used to prevent misoperation when apassenger uses an entry gate and then encounters a platform-mounted Validator and touches the card againwhen not required. The station configuration base data includes a field that defines a time within which aValidator will confirm that an entry validation has been made at the same station and, if so, will not updatethe card again but will simply show that it is valid.
Note that although this test is intended to apply to a situation where a passenger encounters a platform-mounted Validator behind an entry gateline or Validator, the Validators are not equipped to “know” whetherthey are in a gateline position or on-platform, and hence this test will apply to any situation where a Validatoris used at the same location as another device that has performed an Entry validation.
Hence Continuation Entry should be permitted if all the following are satisfied:
the station configuration base data shows a Continuation Entry time other than zero this validation is at a Validator, as opposed to an entry or exit gate the previous validation was an entry at this station, within the time specified in the base data
As ITSO does not generally store sufficient information to know where the previous validation wasperformed, the last bullet point cannot be safely implemented for all products. Consequently, for a TYP24the tests will be performed as specified above, with the location of last validation determined from the TYP24VG. For any other TYP, the last location will be assumed to be the origin encoded in the TT, or if the TT typeis set to “Break of Journey In” then the location will be assumed to be “here”.
The above logic, where location is not considered at a “Break of Journey In”, can result in a potentialanomaly when station A is an OSI where the passenger re-enters the system, station B is close to A andstation B has platform Validators. If the Continuation Entry time at B allows the passenger to validate in at A,travel to B and touch a Validator at the station B gateline all within the Continuation Entry time, then the exitvalidation will not be recorded. It is considered that this is very unlikely in real life, however it should beborne in mind during station configuration and data definition.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Continuation Exit is controlled by global base data. A list is maintained that shows all “interchange” (LUdefinition) stations, i.e. those at which it is possible to touch a Validator device and place the card into a“checked out” state when the journey has not yet been completed. This list is checked at a subsequentvalidation to determine whether a card should be allowed to exit as a continuation of the last recordedjourney, or whether this should be considered as a separate journey.
There are no time constraints applied to a Continuation Exit test other than that the previous exit should beon the same traffic day.
A Continuation Exit is permitted if all the following are satisfied:
a product is valid “here” the product is a single or a return the product origin or destination is not “here”* the previous use was an exit on the same traffic day the previous use was at a location specified as an “Interchange” in base data (global “Interchange
Stations” list) the previous use was within the specified Maximum Continuation Exit time the previous exit was at an AutoDirectional device (CIPEFlags bit 2)
* this test applies to specific location NLCs, as opposed to zonal equivalents. This is intended to prevent acontinuation exit applying to the return leg, when a new journey should start. A continuation exit must beallowed for a zonal NLC, but it is never relevant for a point-to-point ticket where the product has been used atthe nominated exit point. There is, however, a consequence that if a ticket is specified as a zonal destinationbut the passenger is intending to end his/her destination at an interchange station, then the subsequentreturn journey entry validation will be considered as a continuation exit of the outward leg.
Note that Continuation Exit is not relevant for a season or pass product.
This test requires a flag to be defined to identify that an exit was recorded at an autodirectional device, whichwill need to be in the TT. ATOC has agreed to allocate bit 2 of the TT CIPEFlags field, within the TT CIPEdata group, to be used for this purpose.
Generally, a Continuation Exit is recorded as an exit in the TT, however there is an exception to this whenthe Continuation Exit is allowed at a Rail location following a Tram validation, if the Rail location is in the listof nominated direct Rail-Tram interchange points, as specified by the “Direct Rail-Tram Interchange”parameter within the “Station Configuration” table. In this case, the update of the card will be performed inthe same manner as for a Re-Entry, so the product concerned will not appear to be fully used, and the TTwill show a “Check In”.
7.14 TRAM RE-ENTRY PERMITTED?
When a Rail ticket includes onward travel on Tram, a Tram Validation needs to consider the previous Railvalidation to establish whether to permit re-entry. There are two considerations here: first is an interchangeat a location which does not have direct Rail-Tram cross-platform access, in which case a ticket would belikely to be checked out prior to the Tram validation, and second is at a station which does have direct Rail-Tram cross-platform access, where it is likely that the ticket would be checked in.
In either case, if the current journey is determined to be continued by the tram validation, then the card willbe updated to show the tram validation, and its state will be set to “checked out”.
Rail to Tram interchange is only anticipated at particular locations, and hence a list of allowed locations willbe specified in the “Rail to Tram Interchanges” table. It will also depend on the interchange time parameterset in the “Tram Interchange Times” table. If a tram validation is attempted where the card shows a previousRail exit, then a Tram re-entry will be permitted if all the following are true:
this location is a Tram stop the previous use was an exit at a station listed in this location’s “Rail to Tram Interchanges” table the previous use was within the Rail to Tram Interchange time there is a valid product on the card that has a zonal destination that is valid “here”, or a destination of
“Tramlink” (H673); note that this determination will be made using standard NLC look-up, i.e. allTram validators will include the Tramlink NLC as their primary location.
the product is a single or a return the journey has not exceeded the Maximum Journey Time (see 9.5).
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
If a tram validation is attempted where the card shows a previous Rail entry, then a Tram re-entry will bepermitted if all the following are true:
this location is a Tram stop there is a valid product on the card that has a zonal destination that is valid “here”, or a destination of
“Tramlink” (H673); note that this determination will be made using standard NLC look-up, i.e. allTram validators will include the Tramlink NLC as their primary location.
the product is a single or a return the journey has not exceeded the Maximum Journey Time (see 9.5).
7.15 TRAM TO RAIL TRANSFER PERMITTED?
Tickets can be issued from rail locations with a destination of “Tramlink”. If such a ticket is issued as areturn, then the return trip is expected to start with a Tram validation, and a rail entry validation at nominatedinterchange stations must permit entry. In this case, the rail validation is driven by the route informationencoded on the product, which will specify the interchange station, however the test also needs to considerthe previous validation.
Hence rail re-entry will be permitted, changing the card state to “checked in”, if the following are true:
this location’s “Rail-Tram Interchange” (see [8] Station Configuration) has the “Interchange” flag set the previous use was at a Tram Stop the previous use was within the “Tram to Rail Interchange time” (see [8] Global Settings) the product’s route code is valid “here” (see 8.4) the product is a return on its return leg (see 6.3) the journey has not exceeded the Maximum Journey Time (see 9.5).
8. GEOGRAPHY TESTSThe following tests are all related to geography, i.e. is a product valid “here”?
Note that ITSO supports the definition of products with no geographical information, i.e. the Origin,Destination and Route data fields are optional. If all of these fields are absent, then a product is accepted orrejected only on the basis of its definition in the “ITSO Product Definition” table for this location, and allgeography tests are deemed to have passed.
8.1 ZONE VALID HERE?
This test considers whether a product is valid at the validation location, considering zonal validity in origin,destination or route. The test can be applied to any type of product; by definition a zonal location specifiedas an origin or destination cannot be constrained to apply to a single station, and hence tests that rely on aspecific origin or destination, e.g. a single is not allowed entry at its destination, are not applicable whentesting a zone based origin or destination.
This test returns TRUE if any of the following are true:
Origin NLC specifies a zone or zone combination that includes any one or more of the zonesspecified for this station
Destination NLC specifies a zone or zone combination that includes any one or more of the zonesspecified for this station
Route code specifies a zone or zone combination that includes any one or more of the zonesspecified for this station
The Origin and Destination NLCs are converted to zones by look-up of the global “NLC to Zone Mapping”table. The Route code is converted to zones by look-up of the global “Route to Zone Mapping” table. Thevalidation location zone(s) are determined from the station-specific “Station Configuration” table (“Here”zones).
Note that this test can be affected as a result of aliasing. If the test passes as a result of aliasing, then this isnoted against the product concerned for potential consideration when selecting an exit candidate, as theselection of an exit candidate must prefer a product that is naturally valid “here” over one that is valid “here”due to aliasing.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
This test considers whether the validation location is the encoded origin for a particular leg of a journey,noting that the origin/destination are effectively reversed for the return leg of a return product. It is used toprevent entry at the destination, or exit at the origin, for a product which constrains direction of travel.
The test is not applicable to origins/destinations which represent zones, however this is controlled throughomission of zonal NLCs in the station configuration base data representing “here”.
The test returns TRUE in the following circumstances:
the product is a single and the encoded origin is found in the station configuration data either under“Station NLC” or in the list of “Alternative Here NLCs”
the product is a return on its outward leg and the encoded origin is found in the station configurationdata either under “Station NLC” or in the list of “Alternative Here NLCs”
the product is a return on its return leg and the encoded destination is found in the stationconfiguration data either under “Station NLC” or in the list of “Alternative Here NLCs”
Note that this test can be affected as a result of aliasing. If the test passes as a result of aliasing, then this isnoted against the product concerned for potential consideration when selecting an exit candidate, as theselection of an exit candidate must prefer a product that is naturally valid “here” over one that is valid “here”due to aliasing.
8.3 HERE=DESTINATION?
This test considers whether the validation location is the encoded destination for a particular leg of a journey,noting that the origin/destination are effectively reversed for the return leg of a return product. It is used toprevent entry at the destination, or exit at the origin, for a product which constrains direction of travel.
The test is not applicable to origins/destinations which represent zones, however this is controlled throughomission of zonal NLCs in the station configuration base data representing “here”.
The test returns TRUE in the following circumstances:
the product is a single and the encoded destination is found in the station configuration data eitherunder “Station NLC” or in the list of “Alternative Here NLCs”
the product is a return on its outward leg and the encoded destination is found in the stationconfiguration data either under “Station NLC” or in the list of “Alternative Here NLCs”
the product is a return on its return leg and the encoded origin is found in the station configurationdata either under “Station NLC” or in the list of “Alternative Here NLCs”
Note that this test can be affected as a result of aliasing. If the test passes as a result of aliasing, then this isnoted against the product concerned for potential consideration when selecting an exit candidate, as theselection of an exit candidate must prefer a product that is naturally valid “here” over one that is valid “here”due to aliasing.
8.4 HERE ON ROUTE?
This test is used to determine, for non-zonally specified products, whether the current location is between theencoded origin and destination of the product. Two factors are considered: the encoded Route code, andthe geographical relationship between “here” and the encoded origin/destination.
Firstly, the encoded Route code is checked, without regard to origin and destination. If the encoded Routecode is found in the station configuration data “Here Routes” list, then this test returns TRUE without furtherprocessing.
Secondly, the encoded Route code is checked against the station configuration data “Reject Routes” list, andif found then this test returns FALSE without further processing.
If there is no match of Route Code, then the station specific “NLC to Location Group Mapping” table isconsidered to establish a group number for the origin and destination.
If either the Origin or Destination is not found in the “NLC to Location Group” table, then the test returnsFALSE as it is not possible to determine whether the current location is on route.
The origin group and location group are then used to look up an interchange code from the “Location GroupDetails” table. This code determines whether access is permitted in Entry, Exit, both or neither direction. Ifthe code shows access is permitted for the direction of validation being considered, then the test returnsTRUE, otherwise it returns FALSE.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Note that this test can be affected as a result of aliasing. If the test passes as a result of aliasing, then this isnoted against the product concerned for potential consideration when selecting an exit candidate, as theselection of an exit candidate must prefer a product that is naturally valid “here” over one that is valid “here”due to aliasing.
8.5 ORIGIN VALID FOR THIS EXIT?
This test is typically used for a terminus station, to establish when a product defines the terminus as thedestination, whether the encoded origin is appropriate for this location, however it can be applied at anylocation. As an example, consider two products: High Wycombe to London Terminals single and Brighton toLondon Terminals single. Both are encoded using London Terminals as the destination, and bothMarylebone and Victoria stations would consider “London Terminals” as a valid destination. However, aticket from Brighton is clearly not valid at Marylebone and a ticket from High Wycombe is not valid at Victoria.
The origin is mapped to a group using the “NLC to Location Group Mapping” table, and then the “LocationGroup/Zone Acceptability” table is considered to establish if the origin is appropriate. If it is, then this testreturns TRUE, otherwise it returns FALSE.
The definition of the data in the “Location Group/Zone Acceptability” table allows for a default setting thatconsiders all locations acceptable, hence this test can be applied for every station without needing anyfurther data to control its relevancy.
8.6 DESTINATION VALID FOR THIS ENTRY?
This test is typically used for a terminus station, to establish when a product defines the terminus as theorigin, whether the encoded destination is appropriate for this location, however it can be applied at anylocation. This is simply the reverse version of test 8.5.
The destination is mapped to a group using the “NLC to Location Group Mapping” table, and then the“Terminus to Location Group/Zone Acceptability” table is considered to establish if the destination isappropriate. If it is, then this test returns TRUE, otherwise it returns FALSE.
The definition of the data in the “Terminus to Location Group/Zone Acceptability” table allows for a defaultsetting that considers all locations acceptable, hence this test can be applied for every station withoutneeding any further data to control its relevancy.
8.7 CONTIGUOUS TICKETS?
This test is used to determine whether there are contiguous tickets on the ITSO card that cover the journeymade, when there is not a direct match between entry candidates and exit candidates. The test is onlyapplied when considering an exit.
The test does not use any data other than the origin/destination fields for each valid product, though it mayconsider singles, returns and seasons in conjunction with each other. Note that the test will also consider thespecial case of Boundary Zone NLCs against equivalent zonal destinations.
For each entry candidate, or if a product has been selected for this journey (i.e. the TT CIPE group is notpresent in the TT) for the selected product, its destination is considered against each other valid product onthe card, and if there is an exact match to the origin encoded on another product, then these are consideredcontiguous. If no contiguous products are found, then the test returns FALSE.
When a product is encountered where one of Origin, Destination or Route is defined as zonal, i.e. it is foundin the “Zonal NLC to Zone Mapping” table, then there are two further checks applied for potential contiguousproducts. Firstly, if another product contains a Boundary Zone (i.e. it is found on the “Boundary NLC to ZoneMapping” table), the zone of this product is checked to see if it is adjacent to the first product. If it is, thenthese products are considered contiguous. Secondly, a point to point product can be considered ascontiguous if the zone in which its Origin or Destination lies is within the zonal validity of the first product.This overlap is checked by looking up the zone of the Origin from the “NLC to Zone Mapping” table,andchecking against the zonal validity of the first product. If there is no match, then the Destination is checked.If there is a match with either Origin or Destination, then the products are considered as contiguous.
If contiguous products are found, then if the destination of the any of the contiguous products matches theexit location, the test returns TRUE and the products involved are noted.
If there is no match to the destination, then the destination of each contiguous product as created by theprocess above is considered against the origins of any other valid product on the card, and again if there is amatch, the three products are considered contiguous. If the destinations of any of these new contiguousproducts match the exit location, then the test returns TRUE and the three products involved are noted.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
This process is repeated, either until a match is found for the journey, or until all combinations of validproducts have been checked. If there are no valid combinations that result in a match to the origin anddestination of the journey, then the test returns FALSE.
It should be noted that all products considered together to find a contiguous product that covers the currentjourney must have their IPE seals validated.
8.8 MINIMUM ZONES COVERED?
This test considers when zonal products are held on a card, whether the zones covered by the productsallow valid travel to/from the current location. The data contained in the “Location Group/Zone Acceptability”table (ref [8]) defines the minimum zones that are required to allow valid travel to/from the current location.Note that at Entry, or at Exit where there is no valid Rail TT, this test must consider all zonal products on thecard as the “Contiguous Tickets” logic is not applied, but it is possible that multiple zonal products arerequired together to allow this test to pass.
The test is only relevant where neither the origin nor the destination are specified as point locations, i.e. theyare both specified as zonal locations, or there is only one field present and it is a zonal location, or where apoint to point ticket has zonal coverage identified through use of a route code. The latter case only becomesrelevant where the origin and destination encoded do not allow interchange at the current location (see 8.4),when the zonal coverage may still allow access.
Each zonal validity – origin, destination and/or Route code – is converted to a bitmap using the “Zonal NLCto Zone mapping” and “Route to Zone mapping” tables, and the resulting bitmaps are combined using alogical OR operation. This combination is then compared to the minimum zone bitmaps contained in the“Terminus to Location Group/Zone acceptability” table to ensure that the passenger holds enough zonalcoverage to make a valid journey to or from this station. The combination is checked against the twominimum zone bitmaps, and if it matches either entry then this is considered valid. This allows for a situationwhere journeys in different directions from a given station required a different zonal combination, e.g. across-boundary station in zones 4/5, where a journey in one direction requires (at least) a zone 5 validity, buta journey in the other direction requires (at least) a zone 4 validity. Hence in this example one of theminimum zones bitmaps will show zone 4, and the other will show zone 5.
If the product(s) cover the minimum zones required, then this test returns TRUE, otherwise it returns FALSE.
8.9 NO GEOGRAPHY CHECKS
A reader control can set “No Geography Checks”; this is a common control between Oyster and ITSO, usingthe existing control mechanism. This test allows bypassing of geographical-related tests as specified above.
This test is not applicable to Tram or Bus validations.
8.10 WITHIN RAIL-TRAM CHECK IN TIME?
This test is used in Tram validations only, and is designed to cater for the special case stations where TramValidators are mounted on station platforms. In these cases (currently Wimbledon and Elmers End), it isnecessary to undo a previous check-in that has been performed at the same station within a time limit, sincethe passenger will have encountered either a gateline or a PV at the station entrance before using the TramValidator.
The “Direct Interchange” flag in the Rail-Tram Interchange field of the “Station Configuration” table(ref [8]) willspecify whether this test is valid at the particular location, and the time parameter to be applied is in the “Rail-Tram Interchange Time” field in the same table. If the test is to be applied, and if the previous validation is acheck-in at the same location within the time parameter, then the test will return TRUE. In all othercircumstances the test will return FALSE.
8.11 TRAM PRODUCT VALID HERE?
This test is used during Tram validations, or in Rail validations at direct Tram-Rail Interchanges when aTram-only product is being considered.
The test uses the Tram-specific “here” NLCs, Zones and Route as specified in the “Station Configuration”table, to determine whether or not a product is valid at this location.
9. DATE/TIME TESTSThe following tests are all related to time, date or day type.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
This test considers the encoded start date (if present) and the encoded expiry date of the IPE. If the date ofvalidation is on or after the start date (if present) and is less than or equal to the expiry date, then this testreturns TRUE; otherwise it returns FALSE. Note that this test must consider the extended traffic day, henceany time between 00:00:00 and the “ITSO End of Day time” or “ITSO Travelcard End of Day Time” asappropriate defined in global configuration data (typically 02:30 and 04:30 respectively) inclusive on the dayafter the encoded expiry day will still return TRUE. When applied as part of a Bus validation, the “ITSO BusEnd of Day Time” is used instead (typically 04:30).
Additionally, for a TYP22 product, if the usage is on the expiry date of the product then the expiry time is alsochecked. If the validation time is before the encoded expiry time then the test returns TRUE, otherwise itreturns FALSE.
For a TYP24 product, it is possible to have different validity durations for the “outward” and the “return” legsof a Return product. In this case, if the product is determined to be a Return on its Return leg (see 6.3.2),then the “RtnPortionPeriodOfValidity” and “RtnPortionValidFrom” fields are used to determine the productvalidity, otherwise the “OutPortionPeriodOfValidity” and “OutPortionValidFrom” fields are used.
9.2 VALID TODAY (DAY TYPE)?
Some products are constrained to be valid on certain days. This can be encoded on the IPE, or containedwithin the product base data within the reader. Note that if no restrictions are specified either within the IPEor within the “ITSO Product Definitions” table for this product, then the product is considered to be valid onany day. If restrictions are specified in either the IPE or the “ITSO Product Definitions” table, then both theIPE and base data restrictions must be satisfied for the product to be considered as valid.
The ITSO definition of a Special Day is taken to mean that the day is defined as a Public Holiday.
This test checks if the IPE is valid on specific days of the week, with 8 bits defining the validity of the producton Public Holidays, Sundays, Saturdays, Fridays, Thursdays, Wednesdays, Tuesdays and Mondays.
If the current date is not defined as a Public Holiday, it is treated as a standard day of the week, e.g.Monday, Tuesday etc. For a product to be accepted, it must be defined to be valid on the current day of theweek, or it must not have any day restrictions specified.
If the current date is defined as a Public Holiday, it is not also treated as a standard day of the week. Forexample, on a Bank Holiday Monday, products are accepted if they are defined to be valid on public holidays– there is no check that they are valid on a Monday in this case.
In each case, the day of the week extends from 00:00:00 (immediately after midnight) until one secondbefore the “ITSO End of Day time” or “ITSO Travelcard End of Day Time” as appropriate defined in globalconfiguration data (typically 02:30 and 04:30 respectively), both times inclusive.
For example if a non-Travelcard product is specified to be valid on Mondays, it will be valid from 00:00:00 onMonday to 02:29:59 on Tuesday morning. The period between 00:00:00 and 02:29:59, inclusive, will fall intotwo different day of the week categories - the Day of Week check will pass if the IPE satisfies at least one ofthe Day of the Week conditions.
For example:
At 01:00 on Saturday mornings, the following tickets will be valid:
A ticket specified as only being valid on Fridays A ticket specified as only being valid on Saturdays
At 02:00 on Monday mornings, the following tickets will be valid:
A ticket specified as only being valid on Sundays A ticket specified as only being valid on Mondays
At 01.30 on the Tuesday morning after Easter Monday, the following tickets will be valid:
A ticket specified as only being valid on Public Holidays A ticket specified as only being valid on Tuesdays
At 01:00 on Wednesday mornings, the following tickets will be valid:
A ticket specified as only being valid on Tuesdays A ticket specified as only being valid on Wednesdays
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
The Day of Week test applies to all products; base data can work in conjunction with IPE data to specifywhich products are available on which days of the week.
TYP22 products have a separate ValidOnDayCode field in the IPE, so TYP22 products must satisfy both theday of week test based on the IPE setting and the day of week test according to the setting in the “ITSOProduct Information” table.
TYP23 products do not have a separate ValidOnDayCode field in the IPE so will only have to pass the day ofweek test according to the setting in the “ITSO Product Information” table.
TYP24 products may have restrictions defined by the DaysTravelPermitted and DaysTravelRestricted fields,and these may be augmented through settings in the “ITSO Product Information” table. Additionally, forthese products, the time restriction may be obtained from the “ATOC Restrictions Mapping” table, dependingon the product and base data settings in the “ITSO Product Information” table.
For TYP 14 and TYP 16 products, if the HalfDayofWeek field is present, TYP 14 and TYP 16 products mustsatisfy both the day of week test based on the IPE setting and the day of week test according to the settingin the “ITSO Product Information” table. If the HalfDayofWeek field is not present, TYP 14 and TYP 16products must satisfy only the day of week test according to the setting in the “ITSO Product Information”table.
Note that for Bus validations, if the product is determined to be an ENCTS pass by means of the “ITSOProduct Information” table then a test is applied (see 9.7 below) to check for Local Authority restrictions.Only if no matching restrictions are found will this test then be applied to cater for TfL restrictions.
9.3 VALID AMPM?
No base data is used within this test, other than the ITSO End of Day time.
For TYP22 products, the TYP22Flags define the following:
The ITSO definition of a Special Day is taken to mean that the day is defined as a Public Holiday.
ValidAM means that the ticket is valid from 00:00:00 (immediately after midnight) until 11:59:59, both timesinclusive (12 hours in total).
ValidPM means that the ticket is valid from 12:00:00 (noon) until one second before the ITSO End of Daytime (typically 02:29:59 the next day), both times inclusive.
When performing this test, the test will pass if the IPE satisfies at least one of the AM or PM conditions.
The period between 00:00:00 and one second before the ITSO End of Day time (typically 02:29:59),inclusive, on Saturdays, Sundays, Mondays and the day after a public holiday will fall into two differentAM/PM categories – the AM/PM check will pass if the IPE satisfies at least one of the AM/PM conditions.
For example:
At 01:00 on Saturday mornings, the following tickets will be valid:
A ticket specified as only being valid on PM weekdays A ticket specified as only being valid on AM Saturdays
At 02:00 on Monday mornings, the following tickets will be valid:
A ticket specified as only being valid on PM Sundays A ticket specified as only being valid on AM Weekdays
At 01:30 on the Tuesday morning after Easter Monday, the following tickets will be valid:
A ticket specified as only being valid on Public Holidays A ticket specified as only being valid on AM Weekdays
At 01:00 on Wednesday mornings, the following tickets will be valid:
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
A ticket specified as only being valid on AM Weekdays A ticket specified as only being valid on PM Weekdays
There is no corresponding check for TYP23 or TYP24 products, therefore this test will always pass for theseproducts.
For TYP 14 and TYP 16 products, if present, the HalfDayofWeek field defines whether the product is valid forcertain periods of a day of the week. Section A.10 of Part 5 of [2] defines the periods as:-
Monday first period, Monday second period, Tuesday first period, Tuesday second period, Wednesday first period, Wednesday second period, Thursday first period, Thursday second period, Friday first period, Friday second period, Saturday first period, Saturday second period, Sunday first period, Sunday second period, Special day first period, Special day second period
The first period is taken to have the same definition as that of ValidAM defined for TYP22 above. Similarly,second period is taken to have the same definition as that of ValidPM defined for TYP22 above. Also,Special day is taken to have the same definition as that of Public Holiday above.
Note that for Bus validations, if the product is determined to be an ENCTS pass by means of the “ITSOProduct Information” table then a test is applied (see 9.7 below) to check for Local Authority restrictions.Only if no matching restrictions are found will this test then be applied to cater for TfL restrictions.
9.4 TIME RESTRICTED?
A ticket’s validity needs to be considered when it has any time restrictions present, i.e. it is not a peak /“Anytime” ticket. Time restrictions may be specified within the IPE itself, or may be specified within the “ITSOProduct Information” table.
On entry, a time restriction may be adjusted by the station-specific “Entry Restriction Easement Time”parameter in the Station Configuration table (ref [8]) .
If the time restrictions are contained in the product itself, there will be no attempt to modify the timerestrictions based on direction of travel. If the restrictions are specified by base data, then the timerestrictions can be modified according to the direction of travel (see 9.4.1 below).
The time restrictions check tests if the current time is outside all the restricted (peak) times defined forWeekdays, Saturdays, Sundays and Public Holidays that are applicable to the IPE.
In each case, the day extends from 00:00:00 (immediately after midnight) until one second before thespecified “ITSO End of Day time” or “ITSO Travelcard End of Day Time” as appropriate defined in globalconfiguration data (typically 02:30 and 04:30 respectively), both times inclusive. . For example if a non-Travelcard product is specified to be valid on Mondays, it will be valid from 00:00:00 on Monday to 02:29:59on Tuesday morning.
When performing this test, the test will pass if the time of validation (adjusted according to the EntryEasement time and destination if applicable) falls outside all restriction times.
The period between 00:00:00 and one second before the “ITSO End of Day time” or “ITSO Travelcard End ofDay Time” as appropriate (typically 02:29:59 and 04:30 respectively), inclusive, on Saturdays, Sundays,Mondays and the day after a public holiday will fall into two categories.
For example:
At 01:00 on Saturday mornings, a restricted (off-peak) ticket will be valid if:
25:00 hrs on Weekdays is not defined as a restricted (peak) time and
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
01:00 hrs on Saturdays is not defined as a restricted (peak) time
At 02:00 on Monday mornings, a restricted (off-peak) ticket will be valid if:
26:00 hrs on Sundays is not defined as a restricted (peak) time and 02:00 hrs on Mondays is not defined as a restricted (peak) time
At 01:30 on the Tuesday morning after Easter Monday, a restricted (off-peak) ticket will be valid if:
25:30 hrs on Public Holidays is not defined as a restricted (peak) time and 01:30 hrs on Tuesdays is not defined as a restricted (peak) time
At 01:00 on Wednesday mornings, a restricted (off-peak) ticket will be valid if:
25:00 hrs on Tuesdays is not defined as a restricted (peak) time and 01:00 hrs on Wednesdays is not defined as a restricted (peak) time
Base data specifies the peak times for the different days of the week, different day types and potentially fordifferent directions of travel.
TYP22 products are specified as being peak or off-peak tickets by use of the OffPeakOnly bit in theTYP22Flags of the IPE. The Time Restriction code to apply will be set by the “ITSO Product Information”table.
TYP23 product time restrictions will be specified by the “ITSO Product Information” table.
TYP24 products time restrictions may be encoded in the IPE, otherwise they will be set by the “ITSO ProductInformation” table.
TYP 14 and TYP 16 product time restrictions will be specified by the “ITSO Product Information” table.
Note that for Bus validations, if the product is determined to be an ENCTS pass by means of the “ITSOProduct Information” table then a test is applied (see 9.7 below) to check for Local Authority restrictions.Only if no matching restrictions are found will this test then be applied to cater for TfL restrictions.
9.4.1 Direction-specific time restriction
Where a product is used at its origin or destination, then it is possible to apply a direction-specific timerestriction, based on the expectation that the product is being used to travel to its encoded origin ordestination. Note that this test is only applied at entry, as it is intended to apply a restriction that wouldnaturally apply at the exit point without any special checking. An example is a journey from south of Londonto a London Terminal, where an off peak ticket may only be available for arrival in London after 1000,however the same type of ticket might be available for travel outside of London after 0930. At entry, therestriction for travel to London must allow for the journey time however at exit (in London) the test is simplywhether or not the product is valid “now” regardless of entry location.
The test is applied using the following process:
If entry is at IPE origin, then use IPE destination as journey destination If entry is at IPE destination, then use IPE origin as journey destination (Note this is only relevant
for a Return ticket on the return leg, as other tests will prevent a Single ticket from being allowedentry at its destination).
Look up destination group from “NLC to Group Location Mapping” table Use the destination group to look up the corresponding Direction Set from “Location Group Details”
table Use the Direction Set with the product Time Code (obtained either from the “ITSO Product
Information” table or the “ATOC Restrictions Mapping” table depending on the IPE) to create anindex into the “Time Restrictions” table, which provides the start and end times to be applied
This test is not applicable to Tram or Bus validations.
9.5 WITHIN MAXIMUM JOURNEY TIME?
This test is used to determine whether subsequent validations for a journey that is in progress are within thedefined Maximum Journey Time. For IOP, the Maximum Journey Time is defined as any time on the sametraffic day on which the journey started.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Hence for a journey that starts at any time on a given day, the test will pass for any subsequent validation onthe same calendar day, or for the next calendar day from 00:00 until the ITSO EOD time (typically 02:30).Any other condition will result in the test failing.
This test is not applicable to Bus validations.
9.6 WITHIN MINIMUM JOURNEY TIME AT SAME LOCATION?
This test is used to determine whether or not a journey could be made between two validations at the samelocation. The Minimum Journey Time is station-specific and is defined in the Station Configuration table inref [8].
The test will be applied during entry processing; if two entry validations are made outside the MinimumJourney Time, then it will be considered that a journey has been made and any product(s) deemed to havebeen used to make the journey will be marked as such. If the validations are within the Minimum JourneyTime, then the preceding Entry will be undone and a new Entry will be performed.
The test will also be used during Autodriectional processing to establish whether an Entry or Exit validation isappropriate.
This test is not applicable to Tram or Bus validations.
9.7 ENCTS RESTRICTED?
This test is specific to Bus validations. There are two types of restriction specified to control ENCTSacceptance: TfL and Local Authority. This is provided to allow control where a bus route starts under a LocalAuthority area and runs into TfL, though the data will allow control in the reverse direction as well. When aproduct has been identified as an ENCTS pass from data within the “ITSO Product Information” table, thenrestriction data within the “Bus Configuration” table is considered to establish whether the product is time/dayrestricted. If there is a restriction found, then this is applied in place of day/time restriction specified withinthe product itself and/or within the “ITSO Product Information” table.
Note that for Rail and Tram validations, restrictions are applied based on the product encoding and anyadditional data within the “ITSO Product Information” table; however it is necessary for Bus validations tooverride this data if Local Authorities wish to apply different restrictions.
The current day type (weekday, Saturday, Sunday, Bank Holiday) and validation time are considered inconjunction with the current route and fare stage. This data is used to look up any active Local AuthorityPass Restrictions. If there is a matching record, then the test will pass or fail according to the value of theValidation Result in that matching record. If there is no matching record, then the day/time restrictions will beapplied according to data in the product and the “ITSO Product Information” table.
9.8 WITHIN TRAM MAXIMUM JOURNEY TIME?
This test is used to determine whether there is any potential onward validity where there is a through Rail-Tram product that has been validated for use on Tram. It is applied either at a Rail exit where there is directTram-Rail interchange or during Rail re-entry processing.
In either case, the test passes if the previous (Tram) validation is within the time specified in the GlobalSettings table, otherwise it fails.
10. PRODUCT PRIORITYIt is feasible that an ITSO card may contain multiple products that could be valid for a particular journey, andthere must be a method to determine which product to choose in such circumstances. This relevant whenperforming an exit validation, since at entry multiple candidates can be allowed. At entry, priority isconsidered and will affect the ordering of the CIPE data; the first candidate IPE in the CIPE data structure willbe that determined to have the highest priority.
The Product Priority test allows base data to determine what priority order to apply, based on parameterswithin the products being considered. Records in the “Ticket Logic Priority” table are date-specific and onlyone can be valid for a particular date. The valid record specifies the order in which up to four parameters areconsidered when two or more products have been determined to be valid for a journey, and the action totake if there is still no decision after considering the other factors:
The bytes in the record are allocated to specific factors:
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
0 : Don’t care (used after other non-zero values) 1 : Ticket Priority of the product as determined from the “ITSO Product Information” table 2 : Soonest End of Validity 3 : Lowest Monetary value 4 : Concession 5 : Reject if no decision (not used for Entry CIPE ordering)
The test iterates through each byte of the 5-byte record, considering the test identified from the list below. Ifthe test results in a decision then no further entries are considered. If no decision has been made afterconsidering the test, then the next byte is considered.
In all of the following sections, the tests are considered to be applied across all IPEs that have otherwisebeen determined to be valid for the journey involved, and are only relevant when there is a more than oneIPE valid.
10.1 PRIORITY: DON’T CARE
When this entry is encountered, the first valid IPE read from the entry candidate list of the TT will be selectedfor use, or if there is no TT then the first valid IPE read from the ITSO card will be selected.
10.2 PRIORITY: TICKET PRIORITY
When this entry is encountered, the logic will consider the IPE priority as determined from the “ITSO ProductDefinition” table. Each product combination is set a priority value, with 1 as the highest and 31 as the lowest.The IPEs are ordered by priority value, and the highest priority in the list is considered. If there is only oneIPE with the highest priority in the list, then it will be selected.
10.3 PRIORITY: SOONEST END OF VALIDITY
When this entry is encountered, the logic will consider the encoded End of Validity date for each IPE, and willorder the IPEs according to the soonest End of Validity. If there is only one IPE with the soonest End ofValidity in the list, then it will be selected.
10.4 PRIORITY: LOWEST MONETARY VALUE
When this entry is encountered, the logic will consider the encoded Amount Paid for each IPE (wherepresent), and will order the IPEs according to the lowest Amount Paid. If there is only one IPE with thelowest Amount Paid in the list, then it will be selected.
10.5 PRIORITY: CONCESSION
When this entry is encountered, the logic will consider whether or not any concession has been used byconsideration of the PartySizeConcession field in each IPE, or for a TYP14 or TYP16 IPE, the fact that thatthe IPE is used automatically makes it a concession. If there is only one IPE where a concession has beenused, then it will be selected.
10.6 PRIORITY: REJECT IF NO DECISION
When this entry is encountered, the test will result in no IPE being selected, and the ITSO card will berejected. This is intended to support a TOC requirement where, rather than make an automated decisionbased on other parameters, it is preferable to reject an otherwise valid card and rely on a member of staff toselect the appropriate product.
This test is not expected to be applied at TfL locations, i.e. TfL policy is to select using all the criteria above,and if there is still more than one choice the IPE is determined under the “Don’t Care” rule above (10.1).
This priority setting is not considered during Entry candidate ordering, and in this case it is considered as“Don’t Care”.
11. VALIDATION MODE TESTSThe following tests consider the operating mode of the validation device. These may be fixed for the givendevice type, may depend on configuration settings or may vary depending on current control settings.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
This test determines the subsystem on which the validation is occurring, and can therefore return a result of“Rail”, “Tram” or “Bus”.
11.2 VALIDATION DIRECTION
This test considers the direction of Validation. For a normal Gate, the result will be one of “Entry” or “Exit”;for a Bus or Tram Validator it will always be “Entry”. For a Rail autodirectional device – Interchange Gate orValidator, the result will be “Autodirection”.
11.3 BUS EMERGENCY MODE
Bus validators can be set into a mode where Rail tickets can be accepted in emergency situations. Thismode may be set by the driver or by an external system control. The normal state for this test is to be False,however if the emergency mode has been set then the result will be True.
11.4 DIRECT TRAM INTERCHANGE?
This test is used to detect where a Rail entry or exit device is being used at a location where there is directin-station interchange possible between Tram and Rail, e.g. Wimbledon or Elmers End. In this case, it isnecessary to allow entry access through the gateline, or for a Validator to show a “valid” display, when thereis only a product with Tram validity but no Rail validity, or to allow exit access when the previous use was aTram validation within the maximum Tram journey time.
At entry, this test is only applied if another candidate product is not already identified during the Entrycandidate selection process, and uses a separate set of data from the “normal” validation product list/locationdata (see [8] “Tram ITSO Product Information”). The implication of this is that a product valid for Rail travelwill be selected if it is available; only if no valid Rail product is available will a check then be made to seewhether a Tram product will allow access.
If the “Direct Interchange” flag in the Rail-Tram Interchange field of the “Station Configuration” table is notset, then this test will return FALSE, otherwise it will return TRUE.
12. SELECT ENTRY CANDIDATESThere are two aspects that need consideration when determining entry candidates at the start of a journey:the first is to find all IPEs on the card that are valid for entry at the current location and time. The second isto find, by preference, a TYP24 product that is valid for entry, since this is the only product that allowssufficient data storage potential to properly execute the Continuation Entry test.
Hence when searching the IPEs, any TYP24 that passes other validity tests will be selected as the firstcandidate IPE and will have its Value Group updated with the current location and date/time of validation aspart of the process.
No other priority checking is applied to the selection of entry candidates; it is simply a process of checking,for each IPE on the card, the following:
Is the IPE acceptable (see tests in section 6)? Is the IPE valid here (see tests in section 8)? Is the IPE valid now (see tests in section 9)?
Up to four candidate IPEs can be selected in this way; if there are more than four IPEs on the card, then onlythe first four are recorded, however noting that the TYP24 preference stated above will ensure that if there isany TYP24 IPE that is valid then it will be set as the first candidate, regardless of how many IPEs are presenton the card. The ordering of IPEs recorded in the TT CIPE data group will be based on priority settings asdefined in section 10.
Note that certain products may become potential candidates as a result of aliasing. No priority based onaliasing results will be applied to entry candidate selection.
13. SELECT BUS TICKETOnly Rail/Bus season tickets with zonal validity or passes with global or zonal validity are acceptable fortravel on Bus under normal circumstances. If a Bus Validator is operating in Emergency mode, then all Rail
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
products (as specified within the “Emergency Rail ITSO Product Information” table, see [8]) are consideredacceptable, as long as they pass the “Valid on day” test (see 9.1).
Hence a reduced set of tests is required, considering passback, location, date and time, though the ticketpriority tests must be used during validation as one candidate must be chosen to allow access to the bussince there will be no corresponding exit.
14. SELECT TRAM TICKETA Tram validation will behave in a similar manner to a rail validation, although the selection of multiplecandidates will only be relevant where the validation is determined to be the start of a journey, and where theproducts allow through tram-rail travel. If the validation is determined to be a continuation of a rail journey, orthe start of a journey where no products allow through tram-rail travel, then one IPE must be selected toallow access since there will be no corresponding exit.
15. SELECT EXIT CANDIDATESAt an exit validation, it is necessary to establish that an IPE exists to authorise the exit being performed. Ifan exit is allowed, it may be modified to be an OSI Exit, EOSI Exit, BOJ Exit, Interchange Exit orContinuation Exit depending on the card state and validation conditions.
By preference, any IPE(s) identified as entry candidates in the TT will be considered first, to establishwhether or not the entire journey is covered by any one of the IPEs. All IPEs identified as candidates arechecked, in case more than one could cover the journey involved. If there is a multiple choice of IPEsavailable, then a single candidate will be identified using the Product Priority test (see 10), or the card will berejected depending on the Priority settings.
If a single IPE is identified that covers the entire journey by virtue of the fact that it is valid here and now byapplication of Geography and Time tests, and its existence as an entry candidate, then no further cardchecks will be made. An exit will be allowed, and the selected IPE VG will be updated as appropriate toindicate its usage.
If no IPE identified as a candidate in the TT is valid for exit, then a search of all valid IPEs on the card isperformed, creating contiguous products using the rules in section 8.7. If this process results in a selectionof IPEs that, when considered together, provide the required validity, then this group is used. The VG of allIPEs in the group are updated, though only the IPE which was actually valid at the exit location will berecorded in the TT written at Exit. If this exit is actually at an OSI or EOSI, then it will be possible to undo theoperation, as required on re-entry, by identifying all IPEs with the same VG update DateTimeStamp asmatches the TT update.
Note that products may become candidates as a result of aliasing; any such product is considered as lessrelevant than a product which is a candidate without considering aliasing. Hence, products that are availableas a result of aliasing will only be considered if there are no direct candidates available.
16. FORCED ENTRY/EXITThere are circumstances where card validation is not performed properly by the passenger, and the businesslogic may need to complete an apparently unfinished journey, or to assume a start point where there is noentry recorded.
16.1 FORCED ENTRY
A Forced Entry is recorded when an exit validation is performed but there is no valid TT present showing anentry. The following identify all the card states where a Forced Entry is required:
Exit validation where current TT shows usage type of Check Out (12) Exit validation where current TT shows usage type of BOJ Out (8) Exit validation where current TT shows usage type of Undo Previous Event without Refund (3) and
DateTimeStamp is not current traffic day
If a TT usage type shows “Undo Previous Event without Refund”, i.e. it is in a state where zigzag is in theprocess of detection at an entry point, and it the TT DateTimeStamp is for the same date as an exit
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
validation, then in this case the location recorded in the IPE24 VG (if available) or the DestinationTT field(otherwise) will be used as the journey origin, and no Forced Entry will be recorded.
A Forced Entry is recorded by setting the OriginLocation element to Null (LocDefType=255) in the TT and inany ITSO data records. The only IPE adjusted is the one chosen to allow exit.
Note that it is possible to record a Forced Entry immediately after a Forced Exit (see below).
16.2 FORCED EXIT
A Forced Exit is recorded when the card state shows that there is a journey in process, however the currentvalidation is not a logical extension of that journey. The following identify all the card states where a ForcedExit is required:
Entry validation where current TT shows usage type of Check In Entry validation where current TT shows usage type of BOJ In Entry validation where current TT shows usage type of Inspected Exit validation where current TT shows usage type of Check In and DateTimeStamp is not current
traffic day Exit validation where current TT shows usage type of BOJ In and DateTimeStamp is not current
traffic day Entry validation where current TT shows usage type of Inspected and DateTimeStamp is not current
traffic day
When a Forced Exit is required, the journey in progress is marked as complete using an unknowndestination, i.e. the Destination field is null in any card updates and ITSO records generated. Only one IPEmust be selected to process as the completed journey, and this will be taken only from the candidatesidentified in the TT. If there is a choice between multiple IPEs, then the selection will be made according tothe priority test (see 10). If the IPE selected is a single or return product, then it will have its remaining usesdecremented as appropriate.
ITSO card updates due to a forced exit will be committed before any further processing takes place, toensure that the ITSO card contents remain consistent. Once committed, the validation will continue on thebasis that the card has not been previously presented for the current journey. Hence it would be possible toprocess an exit with a Forced Entry at this point if necessary.
17. UNDO CHECK-INThe “Undo Check-In” operation is required when there is potential zigzag activity, i.e. on an exit shortly afteran entry at the same Rail location. It is never relevant to Bus or Tram validations.
If the Undo is required, then a Rail TT will be written which records this event, i.e. the usage type will be setto “UndoPreviousEventWithoutRefund”.
By definition, no product relevant to the journey just started will have had its usage updated by the Entryvalidation, and hence there will be no further product update required as a result of the Undo. Any productupdates that occurred during the Entry would have been due to previous incomplete journeys, completed asa result of this validation.
18. OSI/EOSI RE-ENTRYWhen an OSI/EOSI re-entry is performed, it will be necessary to restore the card content, as much aspossible, to the state prior to the preceding exit.
If the TT CIPE data group is not present after an Exit validation (which may be the case if the exit validationis not performed by an IOP device) then it will be necessary to obtain this data from the previous TT, to allowit to be recorded in the Re-entry transaction.
It will also be necessary to undo any updates to usage fields for IPEs (single or return) that were performedat the preceding exit if an OSI re-entry is being performed after a preceding exit. Specifically, a product’susage will not be updated (except for the “part-used” flag, which has no detrimental effect on subsequent
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
validations) when a BOJ exit, Interchange exit or OSI exit is identified; when a “normal” exit is identified, thena product will be marked as “used”, however an OSI Re-entry must undo this operation.
When undoing usage, no historical data is available to directly restore any VG updates. Any IPE(s) updatedby the exit can be identified by checking the DateTimeStamp of update, comparing it to the TT that waswritten at the preceding exit. Working on the presumption that any IPE (single or return) VG showing anupdate at the time of the exit had its “Remaining Uses” field decremented, the OSI re-entry will increment the“Remaining Uses” field for all IPEs so identified.
EOSI re-entry depends on the exit validation being recorded as in “emergency” mode. ATOC has agreed toallocate bit 3 of the TT CIPEFlags field, within the TT CIPE data group, to be used for this purpose.
19. TRANSIENT TICKET FIELD USAGEThe following TT (FormatRevision 4) fields will be used by, and potentially updated by, the IOP ticket logic.Note that the definitions and comments here are copied from ref [2] part 5.
In the following sections, fields which are never present when a Rail TT is written are shaded in grey. Bydefinition, any such fields present on a Rail TT that is read are ignored.
Note that where “None” is shown in “Check during Validation” below, this only means that the field is notdirectly considered in the business logic. Data structure checks may use these fields.
19.1 TT DATA GROUP
ITSO Name Comment Check during Validation Potential Update Group
TTLength Equivalent to IPELength which isdefined in [2] part 2.
None None TT STD
TTBitMap1 Equivalent to IPEBitMap which isdefined in [2] part 2. Thiselement shall be set to Zero (0).
None None TT STD
TTFormatRevision Equivalent toIPEFormatRevision, this elementshall be set to the value of theversion used for this record.
Must be = 4 otherwise TTis not considered valid.
None TT STD
TTBitMap2 This element defines whichoptional elements are present ina record instance.
None None TT STD
TTTransactionType Category of transaction, codedaccording to EN1545EventTypeCode list. Only codesin the range 0 to 15 arepermissible, codes with values of16 and greater shall not be used.
Check for previousoperation type, see 5.1.
Set according tocurrent operationtype for anysuccessfulvalidation.
TT STD
DateTimeStamp Date and time of the transaction This is taken as theDate/Time of previousvalidation, regardless ofvalues in any IPE VG.
Always set to “now”for any successfulvalidation. Notchanged for anyfailed validation.
TT STD
AmountPaidMethodOfPayment Where more than one method ofpayment is used, it is suggestedthat the method used to pay themost monetary value shall berecorded here, but anyappropriate method may berecorded at the discretion of theIPE Owner.
None None TT AMT
AmountPaidCurrencyCode None None TT AMT
AmountPaid Actual Amount paid (cash oramount charged to CTA,deducted from stored travelrights or from an external purse).
None None TT AMT
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
ITSO Name Comment Check during Validation Potential Update Group
CompanionTravelled When set to zero (0) indicatesthat a single person is travelling.When set to one (1) indicatesthat a companion is travelling inaddition to the Product holder.
None None TT AMT
ReturnTicket When set to zero (0) indicatesthat a single Journey Ticket waspurchased. When set to one (1)indicates that a Return Ticketwas purchased.
None None TT AMT
RFU None None TT AMT
NoFareCharged None None TT AMT
AmountPaidVATSalesTax None None TT AMT
DestinationTT Location information, used onlywhen destination (alighting)location is determined at theoutset of a journey.
Used when processingOSI or EOSI re-entrywhen IPE is other thanTYP24.
Set as “here” on anyexit.
Note that thisusage does notcomply with theITSO definition ofthe field.
TT DEST
RFU None None TT IPEID
IPEPointer Pointer to an IPE directory entry,a number in the range 1 to e#identifying a directory entry whichrelates to the IPE used, where e#is defined in [2] part 2. When aticket has been recorded in theTransient Ticket Record thiselement shall contain a pointer toany entitlement IPE used in theTicket’s creation. Where theabove does not apply then theelement may be used to recordthe identity of any IPE relevant tothe transaction, or set to zeroindicating that no IPE is pointedto.
Used during any re-entry(OSI, EOSI, BOJ) orcontinuation exit todetermine whether theIPE used at previous exitis valid for onward travel.
Set on any exit toshow the IPE thatauthorised the exit.This may not be theIPE that authorisedentry whencontiguous validityis created (see 8.7).
TT IPEID
OriginLocation The location at which thetransaction was conducted,which may be the location ofjourney commencement(boarding). This data elementshall be used for entry location ina Closed System.
Used on any exit todetermine IPE validity forthe journey made. Alsoused within zigzag testsat first entry for IPEsother than TYP24.
Updated to “here” atfirst entry of ajourney. Notupdated on any re-entry that continuesthe journey, i.e. OSI,EOSI, BOJ.
TT ORGN
RoutingCode Routing Indicator where affectsfares charged etc – typically aRail National Location Code(NLC) would be stored here.
None None TT RC
IIN Issuer identification number. Inthis context this value shallidentify the network with whichthe POST is registered.
None None TT IIN
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
ITSO Name Comment Check during Validation Potential Update Group
IPEID1 Shall be the Directory Entry IDthat identifies the first candidateIPE. A Pointer to an IPE directoryentry, a number in the range 1 toe# identifying a directory entrywhich relates to the IPE used,where e# is defined in [2] part 2.This entry shall always bepopulated.
Used to determinecandidate IPEs for ajourney at exit; also usedto determine the VG thatcontains last usageinformation when this isan IPE24.
Created on firstentry of a journey.By preference willbe a TYP24 IPE ifthere is a multiplechoice valid at theentry point. Onlycleared following anexit where this IPEhas been usedduring the journeybut is not the IPEthat allowed exit.
Retained in exit TTto allow restore onOSI re-entry.
TT CIPE
IPEID2 Shall be the Directory Entry IDthat identifies the secondcandidate IPE. A Pointer to anIPE directory entry, a number inthe range 1 to e# identifying adirectory entry which relates tothe IPE used, where e# isdefined in [2] part 2. This entrymay be populated. If notpopulated, shall be set to 0.
Used to determinecandidate IPEs for ajourney at exit.
Created on firstentry of a journey ifthere is a multiplechoice valid at theentry point. Onlycleared following anexit where this IPEhas been usedduring the journeybut is not the IPEthat allowed exit.
Retained in exit TTto allow restore onOSI re-entry.
TT CIPE
IPEID3 Shall be the Directory Entry IDthat identifies the third candidateIPE. A Pointer to an IPE directoryentry, a number in the range 1 toe# identifying a directory entrywhich relates to the IPE used,where e# is defined in [2] part 2.This entry may be populated. Ifnot populated, shall be set to 0.
Used to determinecandidate IPEs for ajourney at exit.
Created on firstentry of a journey ifthere is a multiplechoice valid at theentry point. Onlycleared following anexit where this IPEhas been usedduring the journeybut is not the IPEthat allowed exit.
Retained in exit TTto allow restore onOSI re-entry.
TT CIPE
IPEID4 Shall be the Directory Entry IDthat identifies the fourthcandidate IPE. A Pointer to anIPE directory entry, a number inthe range 1 to e# identifying adirectory entry which relates tothe IPE used, where e# isdefined in [2] part 2. This entrymay be populated. If notpopulated, shall be set to 0.
Used to determinecandidate IPEs for ajourney at exit.
Created on firstentry of a journey ifthere is a multiplechoice valid at theentry point. Onlycleared following anexit where this IPEhas been usedduring the journeybut is not the IPEthat allowed exit.
Retained in exit TTto allow restore onOSI re-entry.
TT CIPE
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
ITSO Name Comment Check during Validation Potential Update Group
CIPEFlags See table 65 in [2] part 5. Used to check if producthas been inspected, see19.2 below. Also used todetermine ContinuationExit and EOSI status.
Set bit 2 to showAutoDirectionaldevice used for exit,which will allowsupport ofContinuation Exit.
Set bit 3 if exit isoperating inemergency mode, tosupport EOSI.
TT CIPE
ENTRY_TT_IPE_I SAMID Identifies the TTR (IPE) instanceof the original TTR created forcheck in to a Closed System.This value shall be taken fromthe (TTR) IPE data groupinstance.
None Set when TTcreated; not alteredthereafter.
TT ENTRY
ENTRY_TT_IPE_SAMSequenceNumber
Identifies the TTR (IPE) instanceof the original TTR created forcheck in to a Closed System.This value shall be taken fromthe (TTR) IPE data groupinstance.
None Set when TTcreated; not alteredthereafter.
TT ENTRY
ENTRY_DateTimeStamp The DateTime where thecustomer media checked in tothe Closed System. This valueshall be taken from the (TTR)DateTimeStamp field.
None Set when TTcreated; not alteredthereafter.
TT ENTRY
ENTRY_OID The service operator OID wherethe customer media entered(checked in) to the ClosedSystem
None Set when TTcreated; not alteredthereafter.
TTENTRY_OID
ENTRY_IIN_Index The IIN Index for the serviceoperator where the customermedia entered (checked in) tothe Closed System
None Set when TTcreated; not alteredthereafter.
TTENTRY_OID
UserDefined The Contents of this dataelement are determined by theoperator writing the record.
None If present, and ifthere is space in theTT being written,this data will bepreserved from anyexisting Rail TT onany TT update.
TT UD
Padding Pad to a whole number of blockswith 0x00
None As ITSO definition.
19.2 TTBITMAP2
Bit Data Element or Group Check During Validation Potential Update
0 AMT structure present (Amount paid data) None Never present
1 DEST structure present (Destination data) Used during history tests Set on exit
2 IPEID structure present (IPE Identity data) Used during history tests Set on exit and BOJ re-entry
3 ORGN structure present (Origin data) Used during history tests Set on any validation
4 RFU None None
5 RC structure present (Routing code) None Never present
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
6 RFU None None7 IIN structure present None Never present
8 CIPE structure present Used during history tests Set on entry and exit
9 Entry structure present Used during history tests Set on BOJ validations
10 Entry OID structure present None Set on all except exit
11 User defined element present None Never updated; copyfrom previous TT ifpresent
19.3 CIPEFLAGS
Bit Comment Check During Validation0 Invalid travel detected None
1 CM has been inspected during thecurrent journey
Used during exit checks.
2 Autodirectional Validation Used to enable Continuation Exit,Continuation Entry and Special OSIprocessing, set on any validation by anAutodirectional device.
3 Emergency mode Set on an EOSI exit, to allow for EOSI Re-entry check.
19.4 TT DATA ELEMENT PRESENCE
The following table has been provided by ATOC, showing which TT data groups will be present followingvarious card validation processes. The elements are restricted by the overall TT record size. The followingis based on standard formatting where there is 30 bytes of usable space (48 byte record).
ValidationPoint
TTSTD
TTAMT
TTDEST
TTIPEID
TTORGN
TT IIN TTCIPE
TT UD TTENTRY
TTENTRY
OID
TotalTT
Size
FreeTT
Space
(size) 7 5 7 1 7 3 3 - 10 3
Entry Y N N N Y N Y N* N Y 20 10
Inspection(withoutproductselection)
Y N N N Y N Y N* Y Y 30 0
Inspection(withproductselection)
Y N N Y Y N N N* Y Y 28 2
UndoCheckin Y N N N Y N Y N* Y* Y 30 0
BOJ Out Y N N Y Y N N N* Y Y 28 2
BOJ In Y N N Y Y N N N* Y Y 28 2
Exit Y N Y Y Y N Y** N* N N 25 5**
* Note that the IOP project may define data to be stored in the User-Defined group of the TT (TT UD), thoughthere is little space for this and in some circumstances such storage will not be possible. Therefore the
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
strategy will be to copy the TT UD data field from any existing Rail TT, regardless of date/time, to any newTT that is written, provided there is sufficient space to store the UD data. Typically this will be entry/exit TTrecords only. If there is insufficient space, then the UD will be dropped from the TT.
** ATOC has agreed that the CIPE data group can be retained in the TT exit record, both to make exit statusflags available (required for Continuation Exit and EOSI), and to allow OSI re-entry to avoid reading two TTs.This data group may only be present when the exit TT is created by an IOP validation.
20. IPE TYP22 FIELD USAGEThe following IPE TYP22 fields will be used by the IOP ticket logic. Note that the definitions and commentshere are copied from ref [2] part 5.
20.1 TYP22 DATA GROUP
ITSO Name Comment Check during Validation
IPELength Defined in [2] part 2 None
IPEBitMap Functionally defined in [2] part 2, bitassignment specific to this IPE is definedbelow.
None
IPEFormatRevision This element shall be set to the value of theversion used for this IPE
Must be 1 or 2. Used during look-up in“ITSO Product Information” table.
RemoveDate Count of days. IPE can be removed afterExpiryDate + RemoveDate A value of 255indicates that the IPE may not be removed.
None
ProductRetailer Identity of retailer, included for informationpurposes, not for the purpose of determiningIPE acceptability at the point of use
None
TYP22Flags The principal use of these flags in rail isto specify the peak/off-peak validity.The time periods defining ‘peak’ shallbe defined by the appropriateparameter table transmitted to thePOST. Actual use specified in 9.2 and9.3.
RFU NonePassbackTime Passback time in minutes. A setting of zero
shall indicate that passback time is notdefined within the IPE, in which case antipassback rules defined within the POSTshall be implemented.
Not used, data in device configurationused in preference.
IssueDate Date of IPE issue. The IPE shall not be usedprior to the Issue Date.
None
ExpiryTime Expiry time, on the day defined by expirydate
Used to determine time of end ofvalidity of the IPE.
RFUAutoRenewQuantity1 The contents of this element shall be
interpreted differently depending upon thestate of bit 1 of the TYP22ValueFlagselement, refer to operational rules 5 & 6.
None
Class Coded according to en1545AccommodationClassCode code list
None
ValidityCode A user defined element which may be usedto further define Product validity. A value ofzero shall designate a null condition.
Used to indicate a test or live product(see 6.4.1), and time restriction (see9.4).
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
ValidityStartDTS Date and time of commencement of validity.The IPE shall be valid from the timespecified.
Used to determine start of validity of theIPE.
PromotionCode An IPE owner defined data element. None
ValidOnDayCode Defines days of the week upon which theIPE is valid.
Used to determine day restriction (see9.2).
PartySizeAdult PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
PartySizeChild Used to operate “child” indication.PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
PartySizeConcession Number of concessionary travellersrecorded here shall not also be recorded ineither PartySizeAdult or PartySizeChild.
Used in IPE priority tests to identifywhen a concession is in use (see 10.5).Also used to operate “Concession”indication.PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
AmountPaidCurrencyCode Where the associated value data element isnot used, the value of this element shall beset to zero. May be used to define scalingfactor for Amount Paid.
None
AmountPaid Actual amount paid. Used in IPE priority tests to identify thelowest product price (see 10.4).
AmountPaidMethodOfPayment Where more than one MOP is used it issuggested that the method used to pay themost monetary value shall be recorded here,but any appropriate method may berecorded at the discretion of the IPE Owner.Where the associated value data element isnot used, the value of this element shall beset to zero.
None
AmountPaidVATSalesTax Where the associated value data element isnot used, the value of this element shall beset to zero.
None
PassDuration Optional element whose presence isidentified by bit 3 of the Bit Map. Duration ofthe pass in days. This value shall be used todetermine a new ExpiryDateCurrent when aStored Ticket (pass) is used, taking intoaccount any remaining validity of the currentpass. This element shall always be presentand used when this IPE is used in StoredTicket (pass) mode.
None
RouteCode Optional element whose presence isidentified by bit 1 of the Bit Map. Userdefined routing information.
Used to determine availability atlocations other than Origin/Destination.Used in geography tests (see 8).
ValidAtOrFrom Optional element whose presence isidentified by bit 1 of the Bit Map. Area orlocation code at which the Ticket is valid,where the Ticket is valid in an area or Originlocation code (or destination for return trips)where the IPE is valid for a defined journey.
Used as ticket origin NLC or zone(s). Ifnot present, “ValidTo” is expected to bea zonal location, or the product has nogeographical validity and its acceptanceis controlled by merit of it appearing inthe “ITSO Product Information” table forthis location. Used in geography tests(see 8).
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
ValidTo Optional element whose presence isidentified by bit 1 of the Bit Map. Destinationlocation code (or origin for return trips)
Used as ticket destination NLC orzone(s). If not present,“ValidAtOrFrom” is expected to be azonal location, or the product has nogeographical validity and its acceptanceis controlled by merit of it appearing inthe “ITSO Product Information” table forthis location Used in geography tests(see 8).
Padding As required to pad sector. None
IIN Optional element whose presence isidentified by bit 0 of the Bit Map. IIN used torepresent the product owner where theproduct owner is not the media owner.
Used during look-up in “ITSO ProductInformation” table.
20.2 TYP22 IPEBITMAP
The TYP22 IPEBitMap should be populated as defined below:
Bit Related Data Element Check During Validation
0 IIN data element present Must be = 1
1 RouteCode, ValidAtOrFrom and ValidTodata elements present
None, other than implication that if 0, nogeographical constraints will apply.
The TYP22 Value Group is optional, and its contents are not checked nor updated as part of Validation.
21. IPE TYP23 FIELD USAGEThe following IPE TYP23 fields will be used by the IOP ticket logic. Note that the definitions and commentshere are copied from ref [2] part 5.
21.1 TYP23 DATA GROUP
ITSO Name Comment Check during Validation
IPELength Defined in [2] part 2 None
IPEBitMap Defined in [2] parts 2 and 5 None
IPEFormatRevision This element shall be set to the value of theversion used for this IPE
Must be 1 or 2. Used during look-up in“ITSO Product Information” table.
RemoveDate Count of days. IPE can be removed afterExpiryDate + RemoveDate. A Value of 255indicates that the IPE may not be removed.
None
ProductRetailer ITSO Identity of the retailer, included forinformation purposes, not for the purpose ofdetermining IPE acceptability at the point ofuse.
None
TYP23Flags Refer to table 34 in [2] part 5 None
PassbackTime Passback time in minutes. A setting of zeroshall indicate that passback time is notdefined within the IPE, in which case anti-passback rules defined within the post shallbe implemented.
Not used; data in device configurationused in preference.
IssueDate Date of IPE issue. The IPE shall not be usedprior to the IssueDate.
None
ValidityCode A user defined element which may be usedto further define Product validity. A value ofzero shall designate a null condition.
Used to indicate a test or live product(see 6.4.2). Time restriction data will beignored (tests use base data from the“ITSO Product Information” table.
ExpiryTime ExpiryTime, on the day defined byExpiryDate.
Used to determine time of end ofvalidity of the IPE.
Class Coded according to EN1545AccommodationClassCodeList
None
PartySizeAdult - PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
PartySizeChild - Used to operate “child” indication.PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
PartySizeConcession Number of concessionary travellersrecorded here shall not also be recorded ineither PartySizeAdult or PartySizeChild.
Used in IPE priority tests to identifywhen a concession is in use (see 10.5).Also used to operate “Concession”indication.PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
AmountPaidCurrencyCode Where the associated value data element isnot used, the value of this element shall beset to zero. May be used to define scalingfactor for Amount Paid.
None
AmountPaid Actual amount paid. Used in IPE priority tests to identify thelowest product price (see 10.4).
AmountPaidMethodOfPayment Where more than one MOP is used it issuggested that the method used to pay themost monetary value shall be recorded here,but any appropriate method may berecorded at the discretion of the IPE Owner.Where the associated value data element isnot used, the value of this element shall beset to zero.
None
AmountPaidVATSalesTax Where the associated value data element isnot used, the value of this element shall beset to zero.
None
PhotocardNumber Number corresponding Transport photocard None
PromotionCode An IPE owner defined data element. None
ConcessionaryPassIssuerCostCentre
Optional element whose presence isidentified by bit 4 of the Bit Map. Defines aconcessionary pass or permit issuingauthority cost centre. This value shall bedetermined by the IPE Owner. A registeredOID value may be used in this data element.
None
TYP23Mode IPE operating mode (defined in [2] part 5,table 35):0 Stored single use of the Ticket – i.e. the
Ticket may be used for the number ofrides stored in“CountRemainingRidesJourneys”
1 Stored journeys, i.e. multi-leg journeysare allowed. The Ticket may be used forthe number of journeys stored in“CountRemainingRidesJourneys”, whereeach journey may have a number oflegs, subject to the limit in“MaxTransfers”, and the elapsed timebetween each leg not exceeding“TimeLimit”.
2 A simple ticket, the default option
If present, must be 0 or 1.
MaxTransfers Defines the maximum number of transfersallowable in a single journey.
None
TimeLimit Defines the maximum elapsed time allowedbetween the start of a leg and the start of thenext leg for the second of the two legs toqualify as part of a multi-leg journey.Specified as a count of 30 second intervals.
None
ValueOfRideJourney Nominal value of one ride or journey None
ValueOfRideJourneyCurrencyCode
- None
RouteCode Optional element whose presence isidentified by bit 1 of the Bit Map. Userdefined routing information.
Used to determine availability atlocations other than Origin/Destination.Used in geography tests (see 8).
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Origin1 Optional element whose presence isidentified by bit 1 of the Bit Map. Area orlocation code at which the Ticket is valid,where the Ticket is valid in an area or Originlocation code (or destination for return trips)where the IPE is valid for a defined journey.
Used as ticket origin NLC or zone(s). Ifnot present, “ValidTo” is expected to bea zonal location. Used in geographytests (see 8).
Destination1 Optional element whose presence isidentified by bit 1 of the Bit Map. Destinationlocation code (or origin for return trips)
Used as ticket destination NLC orzone(s). If not present,“ValidAtOrFrom” is expected to be azonal location. Used in geography tests(see 8).
Padding As required to pad sector. None
IIN Optional element whose presence isidentified by bit 0 of the Bit Map. IIN used torepresent the product owner where theproduct owner is not the media owner.
Used during look-up in “ITSO ProductInformation” table.
21.2 TYP23 IPEBITMAP
The TYP23 IPEBitMap should be populated as defined below:
Bit Related Data Element Check During Validation
0 IIN data element present Must be = 1
1 RouteCode, Origin1 and Destination 1data elements present
None, other than implication that if 0, nogeographical constraints will apply.
2 RFU None
3 TYP23Mode, MaxTansfers,TimeLimit,ValueOfRideJourney,optional RFU,ValueOfRideJourneyCurrencyCodedata elements present
Must be = 1
4 RFU None
5 RFU None
21.3 TYP23 FLAGS
The TYP23Flags should be populated as defined below:
Flag Flag Name and Purpose Check During Validation
0 RFU None
1 UsedChecked None
2-4 RFU None
5 PrintTicket - when set to 1 a ticketshall be printed, when appropriate, ifPOST is capable of this
None
6 PrintReceipt - when set to 1 a receiptshall be printed, when appropriate, ifPOST is capable of this
None
7 RFU None
21.4 TYP23 VALUE GROUP USAGE
ITSO Name Comment Check duringValidation
Potential Update
VGLength Defined in [2] part 2 None NoneVGBitMap Defined in [2] part 2 None None
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
TransactionType Defined in [2] part 2 None Set according to currentoperation type for anysuccessful validation.Not changed for anyfailed validation.
TransactionSequenceNumber Defined in [2] part 2 None Defined in [2] part 2
DateTimeStamp Defined in [2] part 2 None Always set to “now” forany successfulvalidation. Not changedfor any failed validation.
ISAMIDModifier Defined in [2] part 2 None Defined in [2] part 2
ActionSequenceNumber Defined in [2] part 2 None Defined in [2] part 2
CountRemainingJourneyRides Count of remaining rides,journeys or Tickets. Thiscount shall be decrementedeach time the ticket is used. Acount of zero shall indicatethat no rides or journeys areavailable.
Checked on entry todetermine ticket status,see 6.3.1.
Updated on exit to showremaining uses.
CountTransfers Count of transfers made inthe current journey. Thiselement shall be set to zeroupon IPE creation and whenan initial journey leg is made.
Bit 1 checked on entry todetermine ticket status,see 6.3.1.
Bit 1 set on exit, clearedon entry.
Padding As required.
22. IPE TYP24 FIELD USAGEThe following IPE TYP24fields will be used by the IOP ticket logic. Note that the definitions and commentshere are copied from ref [2] part 5.
22.1 TYP24 DATA GROUP
ITSO Name Comment Check during Validation
RemoveDate Count of days. IPE can be removed afterExpiryDate + RemoveDate. A value of255 indicates that the IPE may not beremoved.
None
ProductRetailer Identity of retailer, included for informationpurposes, not for the purpose ofdetermining IPE acceptability at the pointof use.
None
TYP24Flags Refer to table 138 in [2] part 5 Used to confirm not a Carnetproduct and to identify test/live, see22.3 below.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
ProductTypeEncoding Binary encoding to determine producttype (single, return)0 = n journeys in one direction.1 = n journeys where pairs are treated asreturns.2 = n journeys in either direction.3 – 15 = RFU.See ‘NumberOfJourneysSold’.
Used in conjunction with VG data toestablish IPE state (see 6.3.2).
TicketNumber Unique reference number for the ticket. None
NumberOfAssociatedIPEs Indicates the presence and number of theoptional 'Associated IPE reference' dataelements.
None
NumberOfDiscounts Indicates the presence and number of theoptional 'Discounts' data elements.
None
NumberOfSupplements Indicates the presence and number of theoptional 'Supplements' data elements.
None
NumberOfTransferTypes Indicates the presence and number of theoptional 'Transfer' data elements.
Used to determine if BOJ is allowed(see 7.10 and 7.11.)
NumberOfInterchanges Indicates the presence and number of theoptional 'Interchange' data elements.
Used to determine if interchangeexit/entry is allowed (see 7.8 and7.9).
NumberOfRestrictionTimeBands Indicates the presence and number of theoptional 'Restriction time band' dataelements.
None
NumberOfVehicleSpecificRestrictions Indicates the presence and number of theoptional vehicle specificrestrictions/easements' data elements.
None
NumberOfRoutingPoints Indicates the presence and number of theoptional 'Routing points' data elements.
None
Class Accommodation class (1st or std orunknown)
None
AutoRenewTimeAfterExpiry Number of days after expiry of originalproduct that auto-renew still applies
None
NumberOfJourneysSold Value of 'n' in ‘ProductTypeEncoding’,Where:n=1 for a singlen=2 for a returnn=10 for a carnet of 10 singlesn=60 for a carnet of 30 returns.
None
OutPortionPeriodOfValidity Out portion period of validity in daysrelative to ‘OutPortionValidFrom’ - used todefine outward portion end of validity.
Used to determine product validity(see 9.1).
RtnPortionPeriodOfValidity Rtn portion period of validity in daysrelative to ‘RtnPortionValidFrom’- used to define return portion end ofvalidity.
Used to determine product validity(see 9.1).
OperatorSpecificity Used to indicate that product is only validon the services of a specific operator.
None
FaresTypeOfTicket Fares Type of Ticket (FTOT) code. Used as part of the index to look upthe “ITSO Product Information”table.
PartySizeAdult Number of adult passengers PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
PartySizeChild Number of child passengers Used to operate “child” indication.PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
PartySizeConcession Number of concessionary passengers Used in IPE priority tests to identifywhen a concession is in use (see10.5). Also used to operate“Concession” indication.PartySizeAdult+PartySizeChild+PartySizeConcession must = 1.
IdDocumentReference To cross reference to an ID document(e.g. non-smart railcard or photocard)
None
Origin Location of ticket origin (as sold). Forvalidation purposes: on a return ticket, forthe out portion, this is the journey origin,on the return portion this field is to beused as the destination.
Used in geography tests (see 8)
Destination Location of ticket destination (as sold). Used in geography tests (see 8).AlternativeOrigin An alternative Location of ticket origin. None
AlternativeDestination An alternative Location of ticketdestination.
None
Route UD Route code. Used in geography tests (see 8.1,8.4, 8.8).
OutPortionValidFrom Out portion valid from date. Used to determine product validity(see 9.1).
RtnPortionValidFrom Rtn portion valid from date Used to determine product validity(see 9.1).
RestrictionCode Restriction code. Used to look up day/timerestrictions in the “ATOCRestrictions Mapping” table, thenapplied in Date/Time tests (see 9).
DaysTravelPermitted Restriction definition - days of week onwhich product is valid (binary flags forMTWTFSS & Bank Holidays)
None; replaced by“RestrictionCode” definition.
DaysRestrictionApplies Restriction definition - days of weekwhere restriction applies (binary flags forMTWTFSS & Bank Holidays)
None; replaced by“RestrictionCode” definition.
AmountPaidCurrencyCode As per item name. None
AmountPaidMOP Method of payment (majority if multiple) None
AmountPaid Price paid by customer Used in IPE priority tests to identifythe lowest product price (see 10.4).
VendorLoc Location of the ticket vendor None
Repeating Data Group of associated IPEs
IPEInstanceID Instance ID of other IPEs that form part ofthe total product
None
Repeating Data Group of discounts
DiscountCode 5 character UD code to identify discount. None
DiscountAmount Value in base units e.g. pence. Set tozero if ‘DiscountPercentage’ is populated.
None
DiscountPercentage Specified to 1 decimal place (e.g. 33.3%= 333). Set to zero ‘DiscountAmount’ ispopulated
None
DiscountCodeType Type of discount code. None
Repeating Data Group of supplement codes
AssociatedSupplementCode UD Supplement Code. None
Repeating Data Group of interchanges
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
0 When set indicates that the productcontains a Follow-on renewal Ticket
None
1 When set indicates that the productcontains a Duplicate Ticket
None
2 When set indicates that the productcontains a Replacement Ticket
None
3 When set indicates that the productcontains an Unfullfilled Warrant
None
4 When set indicates that the productcontains a Carnet
Must be = 0
5 TestOrLiveFlag: When set indicatesthat the product is a test ticket.
Used to determine test/live product (see6.4.3)
6 PassengerDetailsFlag: When setindicates that the IPE containspassenger name and gender details.
None
7 ReservationsMandatoryFlag: Whenset indicated that a reserved seat ismandatory.
None
8 CompanionPermittedFlag: When setindicates that a companion is allowed.
None
9 AutoRenewFlag: When set indicatesthat AutoRenew is enabled.
None
10 RFU None
11 RFU None
22.4 TYP24 VALUE GROUP USAGE
ITSO Name Comment Check duringValidation
Potential Update
JourneysRemaining Count of the number ofjourneys that the ticket is stillvalid for and is reduced onexit at destination. Initially setto 2 for a return ticket and 1for a single.
Checked on entry todetermine ticket status,see 6.3.2.
Updated on exit to showremaining uses.
TransfersRemaining Count of the total number ofremaining transfers - reducedby the equipment of theservice provider honouringthe transfer entitlement. Up to3 transfer types are permittedeach with up to 511 transfers
None None
JourneyPartUsedFlag Indicates that the current partof the product has been partused (e.g. an outward leg upto an out-of-stationinterchange) Set to 1 on exitat interchange and re-set to 0when a journey is completede.g. when the out portion isused
Used to determine IPEstatus (see 6.3.2).
Set to 1 on OSI exit,EOSI exit, Interchangeexit or BOJ exit. Set to 0on any “normal” exit.
NumberOfReservations Product structuring data:indicates the presence andnumber of the optionalreservations data elements.
None None
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
ReservationType Seat/Berth/Bike/No-place/Wheelchair type code.
None None
TogetherFlag Indication as to whethersleeper cabin is shared.
None None
Padding Pad to a whole number ofblocks with 0x00.Padding shall be providedonce only for the Data Groupcomprising value records.Padding shall be positioned atthe end of the Data Group.
None None
23. IPE TYP14 FIELD USAGEThe following IPE TYP14 fields will be used by the IOP ticket logic. Note that the definitions and commentshere are copied from ref [2] part 5.
23.1 TYP14 DATA GROUP
ITSO Name Comment Check during Validation
IPELength Defined in [2] part 2 None
IPEBitMap Defined in [2] parts 2 and 5. See 23.2.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
IPEFormatRevision This element shall be set to the value ofthe version used for this IPE
Must be = 1.
RemoveDate Count of days. IPE can be removed afterExpiryDate + RemoveDate. A Value of255 indicates that the IPE may not beremoved.
None.
ConcessionaryPassIssuerCostCentre Defines the Concessionary TravelAuthority that issued the ConcessionPass.ConcessionaryPassIssuerCostCentre is anumber that is unique to a given TravelConcession Authority.Where the concession is granted inrespect of the concessionaire‘s age ordisability, under a UK scheme, then thevalue of ConcessionaryPassIssuer-CostCentre allocated by the appropriateNational Concessionary Travel Body forthe country in which the pass holder isresident shall be used. This requirementdoes not prevent this element being usedto hold other ConcessionaryPassIssuer-CostCentre values when the IPE is usedwith other types of concession.A registered OID value may be used inthis data element.
None
IDFlags Refer to table 24 in [2] part 5 None
RoundingFlagsEnable This flag indicates when set to zero (0)that the RoundingFlag andRoundingValueFlag are not operationaland that the POST shall use its own ruleswhen calculating proportional and halffares.This flag indicates when set to one (1)that the RoundingFlag andRoundingValueFlag are operational andshall be used when calculatingproportional and half fares.
None
PassbackTime Passback time in minutes. A setting ofzero shall indicate that passback time isnot defined within the IPE, in which caseanti passback rules defined within thePOST shall be implemented.
None
HolderID Identifies the IPE Holder who is entitledto the product‘s benefits subject to theproduct‘s terms and conditions.Issuer defined holder identity number,OR electronically stored photo imageserial number, OR the serial number ofthe customer media holder‘s photoidentity card.
None
RoundingFlag This flag is only operative when theRoundingFlagsEnable flag is set to one(1).When set to one (1), any calculated fareshall be rounded up, otherwise, when setto zero (0), any calculated fare shall berounded down.
None
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
RoundingValueFlag This flag is only operative when theRoundingFlagsEnable flag is set to one(1).When set to zero (0), any calculated fareshall be rounded to the nearest singlecurrency unit (e.g. 1p). When set to one(1), any calculated fare shall be roundedto the nearest multiple of 5 currency units(e.g. 5p).
None
EntitlementExpiryDate Date a specific entitlement expires. Used in checking IPE validity (see6.2).
DepositCurrencyCode Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
DepositMethodofPayment Where more than one method ofpayment is used, it is suggested that themethod used to pay the most monetaryvalue shall be recorded here, but anyappropriate method may be recorded atthe discretion of the IPE Owner.Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
DepositVATSalesTax Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
Deposit Amount Amount of deposit or charge paid for theIPE.
None
EntitlementCode Entitlement code according to EN1545EntitlementTypeCode.
None
ConcessionaryClass Concessionary class code according toEN1545 ProfileCodeIOP.
None
SecondaryHolderID Identifies a secondary person who isentitled to the product‘s benefits subjectto the product‘s terms and conditions.Issuer defined holder identity number,OR electronically stored photo imageserial number, OR the serial number ofthe customer media holder‘s identitycustomer media, for a secondary holder.
None
HalfDayofWeek Defines AM/PM and Day of Weekvalidity.
If the field is present (see TYP14 BitMap section below) it will be used forDate and Time checks (see section9).
ValidAtOrFrom Area or location code at which the Ticketis valid, where the Ticket is valid in anarea, or Origin location code (ordestination for return trips) where the IPEis valid for a defined journey.
Used as ticket origin NLC or zone(s).If not present, “ValidTo” is expectedto be a zonal location, or the producthas no geographical validity and itsacceptance is controlled by merit of itappearing in the “ITSO ProductInformation” table for this location.Used in geography tests (see 8).
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Used as ticket destination NLC orzone(s). If not present,“ValidAtOrFrom” is expected to be azonal location, or the product has nogeographical validity and itsacceptance is controlled by merit of itappearing in the “ITSO ProductInformation” table for this location.Used in geography tests (see 8).
Padding Pad with 0x00 to a whole number ofblocks, less 3 bytes for IIN if that elementis present.
None
IIN Issuer Identification Number.IIN used to represent the product ownerOID where the product owner is not themedia owner.
Used as part of the index to look upthe “ITSO Product Information” table.
23.2 TYP14 IPEBITMAP
The TYP14 IPEBitMap should be populated as defined below:
Bit Comment Check during Validation
0 IIN data element present. Must be 1
1 SecondaryHolderID element present. None
2 HalfDayofWeek and ValidAtOrFromelements present.
None except indicating presence of definedfields.
3 ValidTo element present. None except indicating presence of definedfield.
4,5 RFU None
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
24. IPE TYP16 FIELD USAGEThe following IPE TYP16 fields will be used by the IOP ticket logic. Note that the definitions and commentshere are copied from ref [2] part 5.
24.1 TYP16 DATA GROUP
ITSO Name Comment Check during Validation
IPELength Defined in [2] part 2 None
IPEBitMap Defined in [2] parts 2 and 5. See 24.2.
IPEFormatRevision This element shall be set to the value ofthe version used for this IPE
Must be = 1.
RemoveDate Count of days. IPE can be removed afterExpiryDate + RemoveDate. A Value of255 indicates that the IPE may not beremoved.
None
ConcessionaryPassIssuerCostCentre Defines the Concessionary TravelAuthority that issued the ConcessionPass.ConcessionaryPassIssuerCostCentre is anumber that is unique to a given TravelConcession Authority.Where the concession is granted inrespect of the concessionaire‘s age ordisability, under a UK scheme, then thevalue of ConcessionaryPassIssuer-CostCentre allocated by the appropriateNational Concessionary Travel Body forthe country in which the pass holder isresident shall be used. This requirementdoes not prevent this element being usedto hold other ConcessionaryPassIssuer-CostCentre values when the IPE is usedwith other types of concession.A registered OID value may be used inthis data element.
None
IDFlags Refer to table 24 in [2] part 5 NoneRoundingFlagsEnable This flag indicates when set to zero (0)
that the RoundingFlag andRoundingValueFlag are not operationaland that the POST shall use its own ruleswhen calculating proportional and halffares.This flag indicates when set to one (1)that the RoundingFlag andRoundingValueFlag are operational andshall be used when calculatingproportional and half fares.
None
PassbackTime Passback time in minutes. A setting ofzero shall indicate that passback time isnot defined within the IPE, in which caseanti passback rules defined within thePOST shall be implemented.
None
DateofBirth Users of this field shall take note of therequirements of the Data Protection Act.
None
Language Language code – A pointer to a tablestored in the POST, which shall containthe matching codes based on ISO 639and defined in Table 24a. This dataelement shall be ignored if Idflag 3 is setto one (1).
None
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
HolderID Identifies the IPE Holder who is entitledto the product‘s benefits subject to theproduct‘s terms and conditions.Issuer defined holder identity number,OR electronically stored photo imageserial number, OR the serial number ofthe customer media holder‘s photoidentity card.
None
RoundingFlag This flag is only operative when theRoundingFlagsEnable flag is set to one(1).When set to one (1), any calculated fareshall be rounded up, otherwise, when setto zero (0), any calculated fare shall berounded down.
None
RoundingValueFlag This flag is only operative when theRoundingFlagsEnable flag is set to one(1).When set to zero (0), any calculated fareshall be rounded to the nearest singlecurrency unit (e.g. 1p). When set to one(1), any calculated fare shall be roundedto the nearest multiple of 5 currency units(e.g. 5p).
None
EntitlementExpiryDate Date a specific entitlement expires. Used to determine IPE expiry (see6.2).
DepositMethodofPayment Where more than one method ofpayment is used, it is suggested that themethod used to pay the most monetaryvalue shall be recorded here, but anyappropriate method may be recorded atthe discretion of the IPE Owner.Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
DepositVATSalesTax Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
ShellDepositMethodofPayment Where more than one method ofpayment is used, it is suggested that themethod used to pay the most monetaryvalue shall be recorded here, but anyappropriate method may be recorded atthe discretion of the IPE Owner.Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
ShellDepositVATSalesTax Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
DepositCurrencyCode Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
ShellDepositCurrencyCode Where the associated value data elementis not used, the value of this elementshall be set to zero (0).
None
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Deposit Amount Amount of deposit or charge paid for theTYP16 IPE. It may relate to a deposit forthe ID, or for the ConcessionaryEntitlement, or may relate to a charge foran enhanced Concessionary Entitlement.
None
ShellDeposit Amount of deposit paid for the entireITSO shell. Note that values recorded inthis data element and its associated dataelements shall be reported using the datamessages appropriate to the ITSO shelldeposit, not the TYP 16 IPE datamessages.
None
EntitlementCode Entitlement code according to EN1545EntitlementTypeCode.
None
ConcessionaryClass Concessionary class code according toEN1545 ProfileCodeIOP.
None
SecondaryHolderID Identifies a secondary person who isentitled to the product‘s benefits subjectto the product‘s terms and conditions.Issuer defined holder identity number,OR electronically stored photo imageserial number, OR the serial number ofthe customer media holder‘s identitycustomer media, for a secondary holder.
None
ForenameLength Length of Forename, in bytes. TheForename element shall be compressedto the actual size required for the textstored, and the actual size of the elementstored here.
None
Forename Holder‘s Forename according to EN1545.Users of this field shall take note of therequirements of the Data Protection Act.
None
SurnameLength Length of Surname, in bytes. TheSurname element shall be compressed tothe actual size required for the textstored, and the actual size of the elementstored here.
None
Surname Holder‘s Surname according to EN1545.Users of this field shall take note of therequirements of the Data Protection Act.
None
HalfDayofWeek Defines AM/PM and Day of Weekvalidity.
If the field is present (see TYP16IPEBitMap section below) it will beused for Date and Time checks (seesection 9).
ValidAtOrFrom Area or location code at which the Ticketis valid, where the Ticket is valid in anarea, or Origin location code (ordestination for return trips) where the IPEis valid for a defined journey.
Used as ticket origin NLC or zone(s).If not present, “ValidTo” is expectedto be a zonal location, or the producthas no geographical validity and itsacceptance is controlled by merit of itappearing in the “ITSO ProductInformation” table for this location.Used in geography tests (see 8).
Used as ticket destination NLC orzone(s). If not present,“ValidAtOrFrom” is expected to be azonal location, or the product has nogeographical validity and itsacceptance is controlled by merit of itappearing in the “ITSO ProductInformation” table for this location.Used in geography tests (see 8).
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Padding Pad with 0x00 to a whole number ofblocks, less 3 bytes for IIN if that elementis present.
As required.
IIN Issuer Identification Number.IIN used to represent the product ownerOID where the product owner is not themedia owner.
Used as part of the index to look upthe “ITSO Product Information” table.
24.2 TYP16 IPEBITMAP
The TYP16 IPEBitMap should be populated as defined below:
Bit Comment Check during Validation
0 IIN data element present. Must be = 1
1 SecondaryHolderID element present. None except indicating presence of definedfields.
2 ForenameLength, Forename,SurnameLength and Surname elementspresent.
None except indicating presence of definedfields.
3 HalfDayofWeek and ValidAtOrFromelements present.
None except indicating presence of definedfields.
4 ValidTo element present. None except indicating presence of definedfields.
5 RFU None
25. CARD-LEVEL PROCESSING BY VALIDATION DEVICES25.1 NOTE ON DATETIMESTAMP
There are circumstances where multiple records in the ITSO card must be updated, and the DateTimeStampmay appear in several places, e.g. IPE24 VG, Log directory, TT. When performing card updates, the readermust determine a Date/Time that will be used for all updates in that transaction, hence all DateTimeStampfields updated during a transaction must have the same value. This same value will be used for any ITSOdata records created as part of the transaction.
The above approach ensures consistency, and allows the possibility to determine which IPEs were updatedas part of a transaction even if they are not linked via entries in the TT.
25.2 ATOC DEFINITIONS
In ref [7], ATOC has defined the card updates to be performed as a number of media updates (MU) that areattached to specific types of operation (OP). The definitions of OP and MU are listed here:
OP1 Check In OP2 Check out no decrement OP3 Check out decrement OP4 Undo check in OP5` Reverse decrement OP6 Inspection product selection OP7 Inspection only OP8 Undo inspection product selection OP9* Check out forced check in no decrement OP10* Check out forced check in decrement OP11 BOJ out OP12 BOJ in OP13 BOJ out forced check in decrement OP14 Check out where part used update (e.g. OSI) OP15* Check out forced check in where part used update (e.g. OSI)
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
* these items differ only from the “normal” equivalent in having a forced check in, i.e. unknown origin.
MU1 Construct TT MU2 Copy previous TT MU3 Set TT checked out MU3a* Construct TT (null origin) checked out MU4 Set TT inspected MU5 Set TT undo-previous-event-without-refund MU6 Set TT destination MU7 Set TT IPE MU8 Remove candidate IPE from TT MU9 Set TT entry MU10 Remove TT entry MU11 Remove TT entry OID MU12a Decrement IPE22 VG remaining journeys MU12b Decrement IPE23 VG remaining journeys MU12c Decrement IPE24 VG remaining journeys MU13a Increment IPE22 VG remaining journeys MU13b Increment IPE23 VG remaining journeys MU13c Increment IPE24 VG remaining journeys MU14 Commit updates/modify Log directory MU15 Set TT BOJ out MU15a* Construct TT (null origin) BOJ out MU16 TYP24 Decrement VG remaining xfrs BOJ out MU17 Set TT BOJ in MU18 Set IPE24 VG part used
The following additional conditions need to be considered; number allocated in this document as these arenot covered in [7]:
OP100 Check in part used (e.g. OSI) OP101 Check out continuation exit MU100 Set TT checked in MU101 Set IPE24 VG Location Last Processed = here
25.3 CARD-LEVEL PROCESSING AT ENTRY
This section details the card-level processing performed during an entry validation (which excludes OSI,EOSI, interchange and BOJ re-entry).
During entry processing, the following checks will be performed:
that the LPF field in the Log Directory Entry is set to 1 (Normal mode) that the TT Format Revision in the Transient Ticket is set to 4
If there is no “Normal” log available, i.e. LPF=0, then the card must be rejected as the POST is not allowed tocreate a cyclic log where there in none present on the card, and no Rail TT can be created in this case.
If a TT exists with TT Format Revision lower than 4, the validation will continue on the basis that there is noRail TT, and hence the entry will be based only on current IPE state. Further history tests will not be applied.
During entry processing, the status of the ‘Invalid Travel Detected’ flag (bit 0 of the CIPE Flags) in theTransient Ticket is not checked.
If no products are valid for entry, entry is denied to the passenger. In this case no Transient Ticket isgenerated.
This definition of Entry is equivalent to ATOC OP1, and will generate a type 0210 ITSO data record (see 26.4below.)
25.3.1 IPE Value Group
For a TYP23 product, all fields will be updated according to the definitions in ref [2], with the followingclarifications:
TransactionType = Check in (11) or BOJ in (14) as appropriate
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
For a TYP24 product, all fields will be updated according to the definitions in ref [2], with the followingclarifications:
TransactionType = Check in (11) LocationOfLastValidation = NLC of current validation location
25.3.2 Transient Ticket
When a valid entry has occurred, a Transient Ticket (TT) will be created as follows:
TTLength set according to ref [2] part 5. TTBitMap1 bits all set to 0 TTFormatRevision set to 4 TTBitMap2 with all bits clear other than the following bits set:
o Bit 2: (IPEID structure present)o Bit 3: (ORGN structure present)o Bit 8: (CIPE structure present)o Bit 9: (Entry structure present)
TTTransactionType = 11 (check in) DateTimeStamp = “now” TT ORGN Origin Location set using LocDefType = 208, Country Code = 070 and NLC = NLC of
the entry station TT CIPE IPEID1 identifies the first candidate IPE available for travel from the entry station TT CIPE IPEID2 identifies the second candidate IPE available for travel from the entry station, or
is set to 0 if there is none. TT CIPE IPEID3 identifies the third candidate IPE available for travel from the entry station, or is
set to 0 if there is none. TT CIPE IPEID4 identifies the fourth candidate IPE available for travel from the entry station, or is
set to 0 if there is none. TT CIPE CIPE Flags set to 0 ENTRY_TT_IPE_ISAMID set to ISAMID of the validating device ENTRY_TT_IPE_SAMSequenceNumber set to SAM sequence number of the validating device ENTRY_DateTimeStamp set to “now”
A Log Directory Entry for the Transient Ticket will be created as follows:
LPF set to 1 (Normal mode) PTR set to 0 (to show that no definitive IPE has been selected) if there is more than one candidate
IPE and no candidates are TYP24, or set to point to the appropriate IPE if there is only onecandidate IPE, or set to point to the IPE24 whose VG was updated as part of the entry process ifthere are multiple candidate IPEs including an IPE24
EEI set to 1 (inside of a closed system (nesting level 1)) DTS set to “now” RO set according to ref [2] part 2. PTLBM set to the validating device’s passback time (see 7.2)
25.4 CARD-LEVEL PROCESSING AT RE-ENTRY
This section details the card-level processing performed during a re-entry validation (which includes OSI,EOSI, interchange and BOJ re-entry).
By definition, for a re-entry to be valid, there must be a valid TT present with format revision 4 and with TTTransaction Type = BOJ Out (8) or Check Out (12), and there must be a product or product(s) identified thatallow the re-entry to occur. The primary difference between an entry and a re-entry is that the existing TTfields are preserved in the case of a re-entry, with certain fields modified as below.
During re-entry processing, the status of the ‘Invalid Travel Detected’ flag (bit 0 of the CIPE Flags) in theTransient Ticket is not checked.
This definition of Re-Entry is equivalent to ATOC OP12, OP100 and OP101, and will generate a type 0210ITSO data record (see 26.4 below.)
25.4.1 IPE Value Group
For a TYP23 product, all fields will be updated according to the definitions in ref [2], with the followingclarifications:
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
TransactionType = Check in (11) or BOJ in (14) as appropriate
For a TYP24 product, all fields will be updated according to the definitions in ref [2], with the followingclarifications:
TransactionType = Check in (11) or BOJ in (14) as appropriate LocationOfLastValidation = NLC of current validation location
25.4.2 Transient Ticket
When a valid re-entry has occurred, a Transient Ticket (TT) will be created as follows:
All fields except those noted here will be copied from the previous TT TTTransactionType = 11 (check in) or = 14 (BOJ in) as appropriate DateTimeStamp = “now” TT DEST DestinationTT set using LocDefType = 208, Country Code = 070 and NLC = NLC of the
re-entry station.
A Log Directory Entry for the Transient Ticket will be created as follows:
LPF set to 1 (Normal mode) PTR set to 0 (to show that no definitive IPE has been selected) if there is more than one candidate
IPE and no candidates are TYP24, or set to point to the appropriate IPE if there is only onecandidate IPE, or set to point to the IPE24 whose VG was updated as part of the entry process ifthere are multiple candidate IPEs including an IPE24
EEI set to 1 (inside of a closed system (nesting level 1)) DTS set to “now” RO set according to ref [2] part 2. PTLBM set to the validating device’s passback time (see 7.2)
25.5 CARD-LEVEL PROCESSING AT EXIT
This section details the card-level processing performed during an exit validation (which includes OSI, EOSI,Continuation Exit, interchange Exit and BOJ exit).
During exit processing, the following checks will be performed:
that the LPF field in the Log Directory Entry is set to 1 (Normal mode) that the seal on the Transient Ticket is not corrupt that the TTFormat Revision in the Transient Ticket is set to 4 that if the Transient Ticket type is Check in (11) or BOJ in (14), then the TT ORGN and either TT
CIPE or TT IPEID structures are present
If any of these checks fail, the gate will process the card on the basis that the TT does not exist.
During exit validation, the status of the ‘Invalid Travel Detected’ flag (bit 0 of the CIPE Flags) in the TransientTicket will not be checked.
If no products are valid for exit, exit is denied to the passenger. In this case no Value Record is updated andno Transient Ticket is generated.
This definition of Exit is equivalent to ATOC OP2, OP3, OP9, OP10, OP11, OP14, OP15 and OP100; in allcases ITSO data records type 0209 and 0210 will be generated (see 26.1.2 and 26.4 below), and whereveran IPE is decremented as part of the operation an ITSO type 0208 data record will be generated in addition(see 26.1 below).
Note that only BOJ Exit has a specific TT usage type recorded; all others are marked as “Check Out”, theprimary difference being the condition that allows such an exit type, and the need for a subsequent re-entryto act appropriately.
25.5.1 IPE Value Group
When a valid exit occurs (whether the passenger validated in to start the journey or not), the Value Group ofthe IPE or IPEs that were selected for the journey will be updated.
For TYP 23 products, all fields will be updated according to the definitions in ref [2], with the followingclarifications:
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
TransactionType = Check Out (12), BOJ Out (8) or Undo Previous Event without Refund (3) asappropriate
For a single or return ticket, CountRemainingRidesJourneys is decremented on completion of theoutward leg of the journey
For a single or return ticket, CountRemainingRidesJourneys is decremented on completion of thereturn leg of the journey
For TYP 24 products, all fields will be updated according to the definitions in ref [2], with the followingclarifications:
TransactionType = Check Out (12), BOJ Out (8) or Undo Previous Event without Refund (3) asappropriate
For a single or return ticket, CountRemainingRidesJourneys is decremented on completion of theoutward leg of the journey
For a single or return ticket, CountRemainingRidesJourneys is decremented on completion of thereturn leg of the journey
LocationOfLastValidation = NLC of current validation location
25.5.2 Transient Ticket
When a valid exit occurs where the passenger has validated in to start the current journey, a Transient Ticket(TT) will be created as follows:
TTLength set according to ref [2] part 5. TTBitMap1 bits all set to 0 TTFormatRevision set to 3 TTBitMap2 with all bits clear other than the following bits set:
o Bit 1: (DEST structure present)o Bit 2: (IPEID structure present)o Bit 3: (ORGN structure present)o Bit 7: (IIN present)o Bit 8: (CIPE structure present)o Bit 9: (Entry structure present)
TTTransactionType is set to Check Out (12), BOJ exit (8) or Undo Previous Event without Refund (3)as appropriate
DateTimeStamp = “now” DestinationTT set using LocDefType = 208, Country Code = 070 and NLC = NLC of the exit station. TT IPEID IPE Pointer identifies the IPE selected for travel from the entry station, or to the IPE that
was valid at the exit location if multiple IPEs were used to authorise the journey TT ORGN Origin Location set using LocDefType = 208, Country Code = 070 and NLC = NLC of the
entry station. TT IIN set to the validator’s IIN value. ENTRY_TT_IPE_ISAMID from old TT’s IPEInstanceID.ISAMID ENTRY_TT_IPE_SAMSequenceNumber from old TT’s IPEInstanceID.ISAMS# ENTRY_DateTimeStamp from old TT’s DateTimeStamp
When a valid exit has occurs but the passenger has not validated in to start the current journey, a TransientTicket (TT) will be created as above, except for the following:
TT ORGN Origin Location set using LocDefType = 255, followed by 6 bytes all set to 0.
A Log Directory Entry for the Transient Ticket will be created as follows:
LPF set to 1 (Normal mode) PTR set to identify the IPE selected for travel from the entry station or to the IPE that was valid at the
exit location if multiple IPEs were used to authorise the journey EEI set to 0 (outside of a closed system) DTS set to “now” RO set according to ref [2] part 2. PTLBM set to the validating device’s passback time (see 7.2)
25.6 CARD-LEVEL PROCESSING ON BUS
This section details the card-level processing performed during a bus entry validation
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
During bus validation, the following check will be performed:
that the LPF field in the Log Directory Entry is set to 1 (Normal mode)
If there is no “Normal” log available, i.e. LPF=0, then the card must be rejected as the POST is not allowed tocreate a cyclic log where there in none present on the card, and no Rail TT can be created in this case.
During entry processing, the status of the ‘Invalid Travel Detected’ flag (bit 0 of the CIPE Flags) in theTransient Ticket is not checked.
If no products are valid for entry, entry is denied to the passenger. In this case no Transient Ticket isgenerated. If there is a Rail TT with Format Revision 4 and with a DateTimeStamp showing “today”, then noTransient Ticket will be created by the bus validation.
As the only valid products on Bus are passes, there will never be any updates made to the value groups ofIPEs. If a Rail product is accepted as a result of emergency mode validation, there will be no updates madeto the card.
25.6.1 Transient Ticket
When a valid entry has occurred, if required a Transient Ticket (TT) will be created as follows:
TTLength set according to ref [2] part 5. TTBitMap1 bits all set to 0 TTFormatRevision set to 4 TTBitMap2 with all bits clear other than the following bits set:
o Bit 1: (DEST structure present)o Bit 2: (IPEID structure present)o Bit 3: (ORGN structure present)
TTTransactionType = Inspected (0) DateTimeStamp = “now” TT ORGN Origin Location set using LocDefType = 209, Route/Stop determined from the Bus
SNCODE and current stop location. TT DESTN Destimation Location set using LocDefType = 209, Route/Stop determined from the
Bus SNCODE and current stop location.
A Log Directory Entry for the Transient Ticket will be created as follows:
LPF set to 1 (Normal mode) PTR set to point to the appropriate IPE EEI set to 0 DTS set to “now” RO set according to ref [2] part 2. PTLBM set to the validating device’s passback time (see 7.1)
25.7 CARD-LEVEL PROCESSING AT TRAMSTOPS
This section details the card-level processing performed during a Tram validation.
During Tram validation, the following checks will be performed:
that the LPF field in the Log Directory Entry is set to 1 (Normal mode) that the seal on the Transient Ticket (if present) is not corrupt that the TTFormat Revision in the Transient Ticket (if present) is set to 4 that if the Transient Ticket type (if present) is Check in (11) or BOJ in (14), then the TT ORGN and
either the TT CIPE or the TT IPEID structures are present
If any of these checks fail, the gate will process the card on the basis that the TT does not exist.
During Tramvalidation, the status of the ‘Invalid Travel Detected’ flag (bit 0 of the CIPE Flags) in theTransient Ticket will not be checked.
If no products are valid, the Validator will show a “failed” indication. In this case no Value Record is updatedand no Transient Ticket is generated.
25.7.1 IPE Value Group
When a valid Tram usage occurs, the Value Group of the IPE or IPEs that were selected for the journey willbe updated if appropriate.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
For TYP 23 products, no VG will be updated as, by definition, this will be performed by the preceding orsubsequent Rail validations that are part of the through journey.
For TYP 24 products, all fields will be updated according to the definitions in ref [2], with the followingclarifications:
TransactionType = Inspected (0) LocationOfLastValidation = NLC of current validation location
25.7.2 Transient Ticket
When a valid Tram usage, a Transient Ticket (TT) will be created as follows:
TTLength set according to ref [2] part 5. TTBitMap1 bits all set to 0 TTFormatRevision set to 3 TTBitMap2 with all bits clear other than the following bits set:
o Bit 1: (DEST structure present)o Bit 2: (IPEID structure present) if this is a transfer from Rail to Tramo Bit 3: (ORGN structure present)o Bit 7: (IIN present)o Bit 8: (CIPE structure present)o Bit 9: (Entry structure present)
TTTransactionType is set to Check Out (12) DateTimeStamp = “now” If this is the start of a journey:
o TT ORGN Origin Location set using LocDefType = 209, Route/Stop determined from theTramstop SNCODE.
o ENTRY_TT_IPE_ISAMID from old TT’s IPEInstanceID.ISAMIDo ENTRY_TT_IPE_SAMSequenceNumber from old TT’s IPEInstanceID.ISAMS#o ENTRY_DateTimeStamp from old TT’s DateTimeStamp
TT DEST Destination Location set using LocDefType = 209, Route/Stop determined from theTramstop SNCODE.
TT IIN set to the validator’s IIN value.
A Log Directory Entry for the Transient Ticket will be created as follows:
LPF set to 1 (Normal mode) EEI set to 0 (outside of a closed system) If this is the start of a journey:
o PTR set to 0 (to show that no definitive IPE has been selected) if there is more than onecandidate IPE and no candidates are TYP24, or set to point to the appropriate IPE if there isonly one candidate IPE, or set to point to the IPE24 whose VG was updated as part of the entryprocess if there are multiple candidate IPEs including an IPE24
If this is a continuation of a Rail journey:o PTR set to the same value as read from the TT
DTS set to “now” RO set according to ref [2] part 2. PTLBM set to the validating device’s passback time (see 7.2)
26. ITSO DATA RECORDS26.1 0208 AMEND IPE (TYP OTHER THAN 24)
This record is generated whenever an IPE other than TYP24 is amended, i.e. its VG is updated. It may begenerated at the same time as other data records are generated, e.g. to record a journey or a TT creation.This record will be created in accordance with [2] part 6, with format revision = 4.
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
Name Source Format Size Comment SettingValidAtOrFrom IPE LOC1 Variable,
max 17Taken from the IPE.Dependent on value of Bit 1 withinIPEBitMap, if this is set then useLocDefType 203, UK National RailLocation codeOtherwise LocDefType 255, NULLlocation
ValidTo IPE LOC1 Variable,max 17
Taken from the IPE.Dependent on value of Bit 1 withinIPEBitMap, if this is set then useLocDefType 203, UK National RailLocation codeOtherwise LocDefType 255, NULLlocation
26.1.3 TYP23 Data Fields
Name Source Format Size Comment Setting
Origin1 IPE LOC1 Variable,max 17
Taken from the IPE.Dependent on value of Bit 1 withinIPEBitMap, if this is set then useLocDefType 203, UK National RailLocation codeOtherwise LocDefType 255, NULLlocation
Destination1 IPE LOC1 Variable,max 17
Taken from the IPE.Dependent on value of Bit 1 withinIPEBitMap, if this is set then useLocDefType 203, UK National RailLocation codeOtherwise LocDefType 255, NULLlocation
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
This record is generated whenever an IPE TYP24 is amended, i.e. its VG is updated. It may be generated atthe same time as other data records are generated, e.g. to record a journey or a TT creation. This record willbe created in accordance with [2] part 6, with format revision = 5. The following sections are intended toclarify settings of fields in the transaction; all fields should be present according to the requirements stated in[2] part 6.
In the StandardData fields at the start of this message (see section 4.7.1 in [2] part 6), theSupplementalInformation field will be set to 01, regardless of whether the transaction is related to entry orexit, when the IPE is identified as a test product. Otherwise, code 03 will be used for entry and code 04 willbe used for exit.
26.2.1 Common Fields
Name Source Format Size Comment SettingIPE-TYP POST TYP 1 This element shall indicate the TYP of IPE to
which a message instance refers, and alsoindicates the type of optional data which maybe found within a message instance.
Set toappropriate IPETYP
NormalPrice POST VALI 4 Full price for ticket (if any), currency isdefined by CurrencyCode
Set to 0.
CurrencyCode POST VALC 1 A 0.5 byte value, occupying bits 0 to 3, bits 4to 7 shall be set to 0
Set to 0.
MachineNumber POST HEX 4 Serial number of the terminal conducting thetransaction
JourneysRemaining V HEX 1 Taken from the IPE VG. =2 foran unused Return, =1 for a half-used Return or unused Single,=0 for fully used ticket.
JourneyPartUsedFlag V Flag 1 A 0.125 byte valueoccupying bit 0; bits 1to 7 shall be set to 0.
Set if product is part-used, e.g.on BOJ exit, otherwise clear.
DTSOfLastValidation V DTS 3
LocationOfLastValidation V LOC1 Variable,max 17
Set to the NLC of the validationlocation.
26.3 0209 JOURNEY RECORD (IPE USAGE)
This record is generated whenever a journey is started/ended. It may be generated at the same time asother data records are generated, e.g. to update an IPE or a TT creation. This record will be created inaccordance with [2] part 6, with format revision = 3.
26.3.1 Common Fields
Name Source Format Size Comment Setting
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
AmountPaid POST VALI 4 Actual fare/price paid for journey(if any). Do not insert any valuehere if an amount value isentered in a simultaneous ticketcreation or amendment record.Currency is defined byCurrencyCode.
Set o 0
NormalPrice POST VALI 4 Full fare/price for journey. Donot insert any value here if anamount value is entered in asimultaneous ticket creation oramendment record. Currency isdefined by CurrencyCode.
Set to 0
CurrencyCode POST VALC 1 A 0.5 byte value, occupying bits0 to 3, bits 4 to 7 shall be set to0
Set to 0
Location POST LOC1 Variable Location at which the journeycommenced or location at whichthe event recorded hereinoccurred
Use LocDefType 203, UKNational Rail Locationcode.This will be the Origin asset in the transient ticketrecord or if no transientticket record present theNLC of the POST.
Destination POST LOC1 Variable Destination or proposeddestination where known
Use LocDefType 203, UKNational Rail Locationcode.This will be the Destinationas set in the transientticket record or if this is notrecorded the NLC of thePOST.
Concessionary-Authority
POST HEX 2 Identity of the concessionaryauthority within whose area thejourney commenced, obtainedfrom the POST configurationdata where this information maybe stored for this purpose.Where no concessionaryauthority ID data is stored in thisdata element then it shall be setto zero. This is a number that isunique to a given TravelConcession Authority. Thesenumbers are allocated by theappropriate NationalConcessionary Travel Authorityfor the country in which theboarding point is located. Thisvalue might be an OID
Set to 0
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
RemainingUses IPE HEX 1 If a multi -use IPE (i.e. multi-ride,journey ticket or multi-usevoucher) then record theremaining number of uses afterthe transaction. This data will beextracted from theTYP 22NumberRemainingPasses,TYP 23 or TYP 26CountRemainingRidesJourneys,TYP 24CountRemainingJourneys,TYP 25 CountUsesAvailable,TYP 29 QtyRemaining,IPE element, depending on theIPE used for the transaction.If the IPE element is smallerthan 1 byte, then it shall occupythe least significant bits of thiselement. If the IPE does notinclude this data, then set thiselement to a value of zero.If the value of the data elementin the IPE is greater than orequal to 255, then set thiselement to 255, or if the IPEvalue is less than 255 then setthis element to that value.
Taken from the IPE ValueGroup if present otherwiseset to 0
TransactionType IPEPOST
HEX 1 If a TransactionType code hasbeen recorded in either thetransient ticket log or in the IPEvalue record, then that valueshall be recorded here.Otherwise, where noTransactionType code has beenstored in an IPE or a transientTicket relevant to the JourneyRecord, use an appropriatecode according to EN1545EventTypeCode.As 8 bit codes can be storedhere [whereas only 4 bit codesare permissible in IPEs] then if amore appropriate code, greaterthan 15, is available in theEN1545 EventTypeCode list;that EventTypeCode value maybe used here.Further guidance may be foundin ITSO DG0007.
Set to a value whichcorresponds to the currentTransient Ticket Record
ServiceOperatorID POST UD 2 This could be an OID, or couldbe a user defined value, definedeither by the Service Operatoror by the owner of the Productused in the Transaction
Set to 0
ServiceNumber POST UD 10 An identifier for the route orservice relevant to theTransaction. If there is norelevant identifier available setto a null value (0 or ASCIIspaces).
Set to 0
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
POST UD 10 An identifier for the bus tripnumber or train numberrelevant to the Transaction. Ifthere is no relevant identifieravailable set to a null value(0 or ASCII spaces).
Set to 0
Reimbursement-DataFlags
POST BMP 1 Bit definitions:0: Concessionary Minimum CostContract1: Concessionary MinimumSubsidy Contract2: Direction (OUT or Clockwise,set to 0, IN or Anticlockwise,set to 1)3-7: RFU
Set to 0
Supplementary-Data
POST Variable Variable One or more elements encodedaccording to asn.1 using basicencoding rules. Allowable dataelements and associated tagvalues are defined in ITSODeveloper Guide DG0009.
Set to Null
26.4 0210 JOURNEY RECORD (TT)
This record is generated whenever a TT is created or updated. It may be generated at the same time asother data records are generated, e.g. to record a journey. This record will be created in accordance with [2]part 6, with format revision = 3.
26.4.1 Common Fields
Name Source Format Size Comment SettingTTTransactionType TTR HEX 1 A 0.5 byte value,
occupying bits 0 to 3, bits 4to 7 shall be set to 0
Taken from the mostrecently writtentransient ticket record
AmountPaidMethodOfPayment TTR MOP 1 A 0.5 byte value,occupying bits 0 to 3, bits 4to 7 shall be set to 0
Set to 0
AmountPaidCurrencyCode TTR VALC 1 A 0.5 byte value,occupying bits 0 to 3, bits 4to 7 shall be set to 0
Set to 0
AmountPaid TTR VALI 2 Set to 0
DestinationTT TTR LOC2 7 Taken from the mostrecently writtentransient ticket recordIf present useLocDefType 203, UKNational Rail Locationcode.If not present ontransient ticket recorduse LocDefType 255,for NULL location
OriginLocation TTR LOC2 7 Taken from the mostrecently writtentransient ticket recordUse LocDefType 203,UK National RailLocation code.If not present ontransient ticket recorduse LocDefType 255,for NULL location
FTA-FP039-9459-67061 REV A
Doc. No. 9459-67061 Rev. A DfT – IOP Business Rules phase 3IOP Ticket Logic Tests
RoutingCode TTR LOC2 7 Set to 0UserDefinedSize POST HEX 1 The size of the User
defined element in bytesSet to 0
26.5 0300 TRANSACTION REVERSAL/CANCELLATION
A transaction reversal record will be created as a result of a continued journey where an IPE was marked as“used”, i.e. its remaining uses were decremented, during the journey. Hence this might occur as a result ofan OSI re-entry or a Continuation Exit.
There must be one type 0300 message corresponding to the reversal of each IPE, hence if multiple IPEswere decremented then multiple type 0300 records must be generated.
This record will be created in accordance with [2] part 6, with format revision = 3.
The fields in the 0300 messages will be set as follows:
Name Source Format Size Comment SettingAmountPaid POST VALI 4 Actual fare/price refund amount for ticket (if
any), currency is defined by CurrencyCodeSet to 0
NormalPrice POST VALI 4 Full fare/price for ticket (if any), currency isdefined by CurrencyCode
Set to 0
CurrencyCode POST VALC 1 A 0.5 byte value, occupying bits 0 to 3, bits 4to 7 shall be set to 0
Set to 0
StoredUsesRefunded POST HEX 1 Number of stored uses of the ticket refunded(if any)
Refers to TYP23CountRemainingRidesJourney field
Refers to TYP24JourneysRemaining field
Set toappropriate fieldvalue
TicketNumber IPE orPOST
UD 6 Operators Ticket number, when available,otherwise set to zero. Shall be obtained fromthe IPE if IPE is of TYP 24, otherwiseobtained from the POST. An IPE elementshorter than 6 bytes shall occupy the leastsignificant bytes of this element.
TicketNumber ifthis is a TYP 24Set to zero forTYP 22 & 23
![Ticket Template Word€¦ · Web view[your. event name] date. time. ticket. date. time. ticket. date. time. ticket. date. time. ticket. date. time. ticket. date. time. ticket. date.](https://static.documents.pub/doc/80x56/5f0738fe7e708231d41beb46/ticket-template-word-web-view-your-event-name-date-time-ticket-date-time.jpg)
