Automatic Fare Collection in Metro System using QR Code

Automatic Fare Collection in Metro System using QR Code.

QR code is one type of barcode (or two-dimensional barcode) first designed for the automotive industry in Japan. The technology for QR codes was developed by Densa -Wave, a Toyota subsidiary. A barcode is a machine-readable label it contains information about the item to which it is attached. The code consists of black modules arranged in a square pattern on a white background. A QR code uses four standardized encoding modes (numeric, alphanumeric, byte/binary, and kanji) to efficiently store data; extensions may also be used..

1. Version information 2. Separators Timing Pattern 3. 4. Format information 5.Data and Error Correction 6. Quiet zone 7. Alignment Pattem S. PostionDetectionPattern.

Introduction. The initial target for the QR Ticketing System shall be to facilitate the usage of QR Tickets for all kinds of Urban Transport like Metro rail, City buses, Mono rail, Suburban rail, etc. Eventually this system shall include and encompass other industries including, but not limited to, Rail, Air, Museums, Archaeological sites, Hotel reservation, etc. So the QR Code Dataset should be designed with as much foresight as is possible on the current date. This has been the primary goal of the project – to design a specification that can be adopted easily across a large spectrum of service providers..

Acronyms and Abbreviations. AFC Automatic Fare Collection System CAFC Centralized AFC System ECC Error Correction Code GSM Grams per Square Meter HID Human Interface Device PTO Public Transport Operator QR Code Quick Response Code RFU Reserved for Future Use Stn code Station Code TOM Ticket Office Machine TRM Transit Rules Management TXN Ref. No Transaction Reference number.

Terms and Definitions. Some important definitions used throughout this specification are described here. These definitions mainly relate to fields of the QR Code Dataset described in this specification..

This term represents the unique ID of Application or TOM used for availing the QR Ticketing Services. This is either the AppID (Application ID) or TomID (Ticket office machine ID)..

QR Code Dataset Details. The figure below shows a diagrammatic representation of the QR Code Dataset hierarchical data structure ..

QR Code Dataset Diagram – II.

Big- endian Versus Little Endian.

Product ID (N = 2 bytes) Value (Decimal) Pass Type Description 0 Not used Invalid – must not be used 1 Standard Product This is the Default Value. Standard Journey Ticket 2 Senior Citizen Pass Pass for Citizens above the age of 60 with a Validity period of 65520 minutes or 45 days 3 Student Pass Pass for Students with a Validity period of 65520 minutes or 45 days. 4 Daily Pass A pass that can be used as a daily ticket from any stop to any stop. The Validity period of this ticket shall be one day only unless the period is explicitly specified by the user in the Validity field. 5 Monthly Pass A monthly pass that can be used for a period of one month or 43200 minutes.

6 Table 5.14: QR Ticket – Product ID A pass that would be valid only on Saturdays and Sundays. The Validity period of this ticket shall be 45 days unless the period is explicitly specified by the user in the Validity field. 7 Table 5.14: QR Ticket – Product ID This Pass is only Valid for the exact Source and Destination stations. The Validity period of this ticket shall be 45 days unless the period is explicitly specified by the user in the Validity field. 8 Table 5.14: QR Ticket – Product ID Pass for Armed Forces Personnel with a Validity period of 65520 minutes or 45 days. 9 Table 5.14: QR Ticket – Product ID This Pass is only for use by Differently abled persons. The Validity period of this ticket shall be 45 days unless the period is explicitly specified by the user in the Validity field. 10 Table 5.14: QR Ticket – Product ID May be used for providing Single Journey Discounted fares. E.g. can be provided for Women, Differently Abled Persons, Children, etc. 11 Table 5.14: QR Ticket – Product ID May be used for providing a Pass for multiple trips. Trip count value may be filled up in the second byte of this field. Maximum value of trip count is 255. 12 Table 5.14: QR Ticket – Product ID If a Ticket needs to be marked as Child Ticket i.e. for Minors – children below the age of 18. 13- 100 Table 5.14: QR Ticket – Product ID May not be used. Reserved for future use 101- 255 Table 5.14: QR Ticket – Product ID May be used if PTO want to define more passes for it implementation 256 - 65535 Table 5.14: QR Ticket – Product ID Only the LSB must be used for defining “Product ID”. This is the second byte or the MSB. This byte may be made use of in some way if an implementation chooses to. For example, if the ‘Trip Count Pass’ (Product ID = 11) is used, this byte may be used to fill in the trip count value..

Service ID (N = 1 bytes) ID Service Name Description 0 Invalid Not to be used 1 Regular Metro Regular or Normal Metro Line Service 2 Express Metro Express Metro Line Service 3 Regular City Bus Normal Fare Non- AC City Bus Service 4 AC City Bus AC Fare City Bus Service 5 Regular Inter- City Bus Normal Inter- city (within state) bus service 6 Express Inter- City Bus Express Inter- city (within state) bus service 7 Non- stop Inter- City Bus Non- stop Inter- city (within state) bus service 8 Regular Inter- State Bus Normal Inter- state bus service 9 Express Inter- State Bus Express Inter- state bus service 10 Non- stop Inter- State Bus Non- stop Inter- state bus service 11 Local Train This is the Indian Railways service used in many cities and towns 12 Sleeper class Low- fare Indian Railways Service 13 AC 2- tier High- fare Indian Railways Service 14 AC 3- tier High- fare (lower than 2-tier AC) Indian Railways Service 15 AC First Class First Class AC Service 16 Normal First Class Regular First Class Service 17 AC Chair Car AC Chair Car Service 18 Normal Chair Car Regular Chair Car Service 19 Rapid Rail Modern Rapid Rail Services introduced in big cities.

QR Image Properties. QR encoding method. Universally all QR codes can support any one of the modes specified in the table below. Current specification mandates only binary mode encoding technique in QR Ticketing System..

Ticket Request JSON files:. Sample 2x3_QR Ticket.

Sample 1x1_QR Ticket with Personalized Info.

Sample 1x1_QR Group Ticket with Personalized Info of 2 members.

SecureQR – Securitization of QR Codes in QR Ticketing System.

Phases of SecureQR - Alpha. SecureQR - Alpha Component- Attribute Model.

Creating a QR- friendly payload. Example text ( 34 bytes).

SecureQR - Alpha Algorithm Design. Ticket Generation :.

Ticket Validation Flowchart :. vv•ait For Scan SVC, a R Tkt block, Invalid TG Access invalid Signature ACCESS DENIED Invalid Serial ACCESS DENIED lid QR_- Tickets Not F Ound Invalid Decry ot ion F ailed ACCESS DENIED ACCE S S Tic k YES rity re retrieved key_ C cornpare with HASH Of STR_A YES Decode Retrieve public Key for given TG 10 IS Ticket Serial Nurnber F d Tickets for Operat YES Constru ct ST ¯ SVC and Extract T Data of a R_SVC Search Ticket Block for this Operator I O Signature Verified YES Transit tests Decode the Ticket block Base64 and then Decrypt block using opera decryption algo cry pti YES Perform-I PTO—Spe-CifiC Transit R is k Tests _ A. Secu Fit-y Tests B _ Valid ticket for "resent tirne C. update 0B.

Ticket Generation:. 2x2_QR Ticket Request JSON File.

This represents the unique identifier allocated for each generated QR. This identifier is 8 bytes long, where the first 4 most-significant bytes are used to represent the date of ticket generation and the remaining 4 bytes (or 32 bits) are used to maintain a sequence number. Bits 31 and 30 of the Ticket Serial No. are reserved for the “Requesting Source Indicator” as described in the table below. The remaining 30 bits (0 – 29) is the actual sequence or counter that has a range from 0 to 2 30 – 1 = 1073741823 . The value 0 is not used. The maximum value of the sequence number is greater than 100 Crores, a very large number. Therefore, there is no need to reset it until it gets exhausted. The sequence number can be stored in persistent storage. But it must be noted here that only one sequence shall be maintained on the TG irrespective of the Requesting Source..

QR Ticketing System Workflow. Logical Entities of the QR Ticketing System.

User : This is the customer. It interacts with the Mobile or Web App to avail QR ticket. In case of a ticket issued by the TOM at the operator premise, the TOM interacts on behalf of this user. The user’s roles can be summed up with the diagram above. Note that Steps 2 and 3 may be interchangeable depending on the mode of transport. For example, in case of Metro it is mandatory to get the ticket scanned and verified by a Validating Terminal before access is given into the Operator’s premises..

Policy Database: Policy database is a centralized repository tightly coupled with the Ticket Generator and stores information related to payments, security, fare tables, etc. for different operators. Only entities trusted by the operator like the TG and Mobile APP can access the Policy DB. Access to Policy DB is only possible with the API provided by the TG..

The three main components of a PTO when seen as a logical entity are:.

Mobile (or Webclient ) App and App Provider: The smart phone application or the Webclient application may be provided by the APP Provider and sometimes synonymously referred to as the merchant. Under all circumstances, the APP Provider must have a trust relationship with the TG.APP Provider – TG cardinality relationship described in details in further..

Single Centralized TG Single Operator Single Policy DB Single PTO Premise - AFC System + AFC DB + Validating terminal + TOM Single Mobile (or Web-client) APP Provider.

The Multi-TG Multi-Operator Architecture is for all practical purposes the actual form that the QR Ticketing Solution is going to be. With this solution, a user would be able to buy and avail services for multiple operators, we only show 2 Ticket Generators and 3 Operators: Multiple Centralized Ticket Generators – Fundamentally they operate in the same way as the Single operator scheme, except here we conveniently illustrate the possibility that the same TG may associate with multiple operators. Henceforth, TG ID 23 serves Operators with Operator ID 10 and Operator ID 135, whereas TG ID 54 serves Operators with Operator ID 135 and Operator ID 45. Of course there is no restriction on TG ID 23 also serving Operator ID 45, or TG ID 54 also serving Operator ID 10, as shown by the dotted lines. Multiple Operators – Again fundamentally similar to the single operator architecture, except here we conveniently illustrate the possibility that the same operator may get associated with multiple TGs. As seen in the diagram below, Operator ID 135 is associated with both TG ID 23 and TG ID 54. Again there is no restriction on APP ID 15 associating with TG ID 54 or APP ID 36 associating TG ID 23, as shown by the dotted lines. Single Policy DB integrated with the TG. AFC System, AFC DB, Validator and TOM work in the same way as with the single operator architecture. Multiple Mobile (or Web-client) APP Providers–Mobile APP1 sells services related to the “TG ID 23” operator base, and similarly Mobile APP2 caters only to “TG ID 54” operator base. APP Providers for Mobile APP1 – APP ID 15 and Mobile APP2 – APP ID 36 are different. Many such combinations of Mobile APP and Web-clients are also possible..

Mobile APPI APP ID 15 Payment Service Provider (UPI, RuPay, Wallets, NetBanking) TG ID 54 Mobile APP2 APP ID 36 Payment Service Provider (UPI, RuPay, Wallets, NetBanking) Paper QR Request TOM (Ticket Window) p TO I TG ID 23 Ticket Generator 1 AFC S stem Policy DB TOM (Ticket Window) p T02 AFC S stem AFC DB Validating Terminal AFC DB Validating Terminal PTO ID 10 Ticket Generator 2 TOM (Ticket Window) PT03 Policy DB AFC System AFC DB PTO ID 135 Validating Terminal PTO ID 45.

Fetch Route / Station Information.

Route Info Response JSON from TG for Operator ID 135.

Fetch All Stations Request JSON for Route 8011 – Operator ID 135.

Route Response with Stations JSON from TG for Operator ID 135.

Fetch All Stations Request JSON Operator ID 10.

Route Response with Stations JSON from TG for Operator ID 10.

Fetch Fare Request JSON by APP for Operator ID 10 & Operator ID 135.

Fetch Fare Details. Fetch Fare Details Workflow.

User Makes Payment for QR Ticket. The APP sends the payment details to the Payment Service Provider, which then facilitates the direct deduction of funds from the user’s bank account or wallet or any other mode of payment that the payment service provider facilitates..

" customer Payment Detail s : "Merchant ld" : 'T Me 15 "Mer chant country" "Me r chant currency" " INDIA" , " INR , "MO—I " "Me r chant order " Operating Mode " : " TXN Amount " "Aggregator ld" " Payment Moäe " "Access Medium" "TXN Source " "Other Details " "DOM" "300.00" " PSPEPAY" , " IMPS " " ONL INE " " ONL " "78; 23; 9201345678; 10; 135 "Multiaccount Payment Details " "App Provider MDR Account : " Flerchant order "3 - 00" " Cur " " INR" , "Account ld" : XXXXXXXX33 4 4 MDR Account : order "3 - 00" " currency" : "Account ld" " INR , xxxxxxxxl 7 2 9 " " PTO " PTO 10 corp Account " "Merchant Order Amount " "176.40 " Cur r en "Account ld " " INR" , "' xxxxxxxx 918 7 " 135 Corp Account " "Merchant Order Amount " "117 -6 "Account ld" : " xxxxxxxx 652 8 ".

Step I: Customer Selects Journey TG responds With ticket fares Station 01 to 15/06/2020 @ Station 12 15:15:00 -PTO ID 10 Station 03 to 18/06/2020 @ Station 34 11:30:00 -PTO ID 10 Station 24 to 28/06/2020 @ Station 42 18:10:00 Mobile App - PTO ID 135 TOM (Ticket Window) p V: Ticket Respnse QR Payload Ticket Generator Step IV: Ticket Request Request Containing Payment Intormation Step II: Process Payment Payment Service Provider (UPI, RuPay, Wallets, NetBanking) Step Ill: Payment Details Successful Payment TXN Ref No ABCDRC202006126782341 AFC System Policy DB TOM (Ticket Window) p TO 2 AFC System AFC DB Validating Terminal PTO ID 1 AFC DB Validating Terminal PTO ID 135.

QR Pa•ßoad from Ticket Res pons e -QR_Signauare-a.iOBOtqSA3mcA.icOnW6R 17 Uqszcrn57tzTzyK7FN3ajqbOVE5CX»RTd1a KWJ 17141 | 5EE3809380007EBE15EE380931 ABCDRC202006126782341 12C16FBDl 12DF319201345678}-, {(<A2131 KSYjXOud1 Scw9bGLbGpOPV+d—gedSQprO+RJD GHBZEs 1 101 11181% 1 a Md Dynamic Data Element to me QR Payload - from pre•hous step 's AgpK18qSKUNN01 | 5EE3809380007 EBE15EE380931 ABCDRC202006126782341 IFI 12C 16FBOl (+42131 IAL m JO GHBZEs ——-<87 | 1 | 101 1 | 1812A5EF88 FA01E017811191B418011 Render QR Image and display on mobile along '.mth Name, Mob No 120020201848 M000003244ø Sh_ Singh 920134 %.

TG and AFC System Interface. The AFC is a PTO-specific system so this interface is essentially also an interface between the AFC and PTO. In this section we describe the interface related to the ‘Purchase QR’ transactions only..

Send QR Info to AFC System & Receive Response. Integrated TG Ticket Generator chedule Timer goes off, time to send files Timer fires m in utes Scheduled/ Same as A Same as A TXN_REQUEST AFC system (Operator K) Count how many n on—empty —Scheduled— folders are there FORK as many Senders I _ create Transaction Request for AFC Payload 2_ send to AFC and watt tor Response ACK Operator-I Operator-N OperatorN ACKed/ TXN_RESPON SE Yes: Move file to ACKed folder Operator-I Opera NO CK RecvdO Goto A Step 2 No Increment Retry Count by 1 Retry Count > Failed/ Opera Yes: Move file to Failed folder and Stop.

QR Watchdog in Validating Terminal. The process of scanning and validating using a watchdog is shown in the figure below..

Direct API Mode QR Validation in Terminal. In the direct mode, the Scanning application directly sends the scanned data to the validator via an API call. In this case the validator always waits on a “function” of the Scanner as opposed to a physical folder location like in the watchdog mode..

QR Verification and Validation in Validating Terminal.

Table QR Transaction Type Values. Txn Type Payment Mode QR – Bits 7 to 5 QR Type – Bits 4 to 0 Txn Type Value Usage QR Purchase b010 b00001 0x41 (65) TOM, App or TG QR Transaction b010 b00010 0x42 (66) Ticket or Exit QR Verification b010 b00011 0x43 (67) Entry QR Error b010 b00100 0x44 (68) Inspector or exit QR Duplicate b010 b00101 0x45(69) Request for a duplicate of an existing valid Purchased QR ticket. QR Update B 010 b00110 0x46(70) Any.