Our Method
- Verification: Aztec Code Scanning
- Offline 2D Aztec code changing over time (no single static image -> transfer hardly possible e.g., screenshot)
- Ticket code bound to account; account bound to one device at a time
- Why we did NOT consider the following technologies:
- QR Code: Aztec = standard for transportation, …
- BLE/NFC: Lacking support of older devices, must be activated; NFC = no “corona” distance
- Ticket inspection speedup: (semi-)permanent notifications when needed
- Notification shown if:
- Inspector in range of passenger (through iBeacons as they are still activated even if Bluetooth is deactivated via quick settings)
- Fixed schedule or manual activation by passenger as fallbacks
- Tap on notification directly opens ticket in app (fast & simple)
- Why we did NOT consider the following technologies:
- Digital wallet: overall usage, only 16 percent; multiple implementations to maintain
- Location services: location-based services must be activated, data protection issues, unreliable
- Verification code directly on lockscreen: major security concerns, image of code too small, easily shareable (screenshot)
- Optional in future: beacons for stations, trains, …
Example Scenarios
- Scenario 1: Passenger device DOES have Bluetooth support
- Inspector enters transportation vehicle.
- Passengers' phones vibrate due to notification being triggered via iBeacons.
- Passengers intuitively look at their phone screen, tap the notification and open the “WienConnect” app
- Drastically decrease ticket validation time because passenger already has phone and ticket ready to be checked by upcoming inspector due to being notified just in time.
- Scenario 2: Passenger device does NOT have Bluetooth support
- Inspector enters transportation vehicle.
- Passengers take out their phone if they hear or see the inspector asking for a valid ticket
- They have set up one of the 2 fallback scenarios, a notification is displayed on their phones lockscreen
- By simply tapping the notification they unlock their phone and get redirected to the “WienConnect” app
- The ticket is available to be verified by the ticket inspector
- Decrease ticket validation time by combing unlocking of the phone, searching the app and opening the ticket into a simple and easy step, that can be quickly done even if the inspector stands right in front of a passenger
Our Implemented Features
User App “WienConnect”
- ✅ PWA: Android, iOS; Quasar
- ✅ Easy to use, intuitive interface
- ✅ Secure storgage fot ticket tokens
- ✅ Local dynamic changing tickets --> offline usable
- ✅ Overview page:
- ✅ Currently valid ticket
- ✅ Button for manual notification activation (view ticket on lockscreen or status bar at specific time -> see fallbacks)
- ✅ Account page:
- ✅ Account settings (name, image)
- ✅ Configure notifications (fixed schedule, disable iBeacons)
- Nice to have but not implemented:
- Wizard: show how it works
- Ticket history
- Buy ticket and Routes page
Inspector App
- ✅ PWA: Android, (iOS possible); Quasar
- ✅ Easy to use, intuitive interface
- ✅ Main page:
- ✅ Scanner for verification
- ✅ Start inspection button (send notification to user devices with valid ticket ONLY)
- ✅ Current information about inspected ticket (name, validity, user + image)
- ✅ Ticket counter on top of screen
- ✅ Settings page for current inspections: line, inspector account, …
- Nice to have but not implemented:
- Wizard: show how it work
- Statistics page to view own ticket validation history (today, past week, month) --> viewable as charts and graphs (also log verification failures, passenger didn’t have a ticket etc.)
Statistics Dashboard
- ✅ Data analysis:
- ✅ Validated tickets + Information
- ✅ Tickets bought
Backend
- ✅ Python Flask
- ✅ Database (SQL): users, tickets
- ✅ REST APIs
- ✅ User:
- ✅ Ticketing account settings
- ✅ Ticket code generation
- ✅ Inspector:
- ✅ Inspector account management
- ✅ Ticket verification
- ✅ Statistics: Valid, Invalid, Overall checked...
- Nice to have but not implemented:
- AI trained CNN for data analysis --> where do the most passangers try to omit buying tickets...
Who we are
Name: Ing. Helmut Resch, BSc
https://www.linkedin.com/in/helmutresch/
Education:
- Engineer's degree - Building technology HVAC - HTL Vöcklabruck (1991 - 1996)
- Bachelor's degree - Electronic engineering - UAS Technikum Wien (2016 – 2019)
Experience:
- SAMsoric GmbH (www.samsoric.com) - 2 years
- Developing smart solutions for the waste industry mainly with Linux based SOC and Python.
- Ortner GmbH (www.ortner.com) - 14 years
- Commissioning, project management and site supervision for international HVAC projects.
Since many years, I am realising small, private projects with Raspberry Pi, Arduino, ESP and Teensy. Programming languages: Python, Java, C
A big field of interest is machine learning and machine vision.
Name: Christoph Swoboda, BSc
https://www.linkedin.com/in/christoph-swoboda-611687162/
Education:
- Engineer's degree - Electronic engineering - HTL Donaustadt (2011 - 2016)
- Bachelor's degree - Electronic engineering - UAS Technikum Wien (2016 - 2019)
- Master’s degree - Embedded systems - UAS Technikum Wien (2019 – today)
Experience:
- Elektrobit GmbH - 2 years
- Developing software for the automotive industry with Python and C.
In my freetime, I am developing full stack applications and smaller private projects.
Programming languages: TypeScript, JavaScript, Python, C
Name: Johannes Balog, BSc
Education:
- Engineer's degree – Electrotechnical engineering - HTL Wien 10 (2011 - 2016)
- Bachelor's degree - Electronic engineering - UAS Technikum Wien (2016 - 2019)
- Master’s degree - Embedded systems - UAS Technikum Wien (2019 – today)
Experience:
- Elektrobit GmbH - 2 years
- Developing software for the automotive industry (AUTOSAR) with C.
In my spare time, I am developing full stack applications (mainly frontend and app UI development)
Programming languages: JavaScript (Vue), C, Python (VHDL)