Solution for vehicle system as part of HSL information system

The main objective of the procurement is the vehicle system, including necessary software, hardware and services. HSL provides a software platform for the usage of Tenderer. The Tenderer will implement docker solutions for the software platform and provide the driver display hardware for buses. The provided vehicle system software is expected to be compatible with, and provide similar functionality to, the existing legacy driver displays integrated across all rail modes. The docker solution software must have all the necessary components to meet HSL needs for passenger information, driver aid, traffic light priority system, configuration management and provide HSL backend with different real time data sources. The vehicle system should include the following parts: * Passenger information • Announcements Text-To-Speech (TTS) • Indoor (Passenger information) display control • Outer displays control * Content Management System * Transit signal priority (TSP) (Also known as, traffic light priority) • Control of the radio modem to send requests • Implementation of the necessary vehicles side logic of the priorities * Driver aid •Hardware of driver displays to buses •Controlling necessary parts of the vehicle system •Driver aid for routes, schedules, timetables, etc. •Ticket inspection view * Real-time data •HFP (High Frequency positioning) •NOPTIS ROI •ITxPT APIs •In the later stage, SIRI * Configuration management •Different vehicle types HSL provides the following data sources and hardware for the Tenderer to be able to implement necessary parts of the vehicle system: * Provided planned data •GTFS •NOPTIS DOI •In the later stage, NETEX * Vehicle system •On-board computer and router Docker environment Necessary data connection with mobile network GPS source FMS CAN via FMStoIP •Internal passenger information displays hardware •External displays hardware •Ticket validator hardware •Announcement system hardware •Traffic light radio modem hardware * APIs •User and access management •Ticket validation status The vehicle system solution will be implemented in all HSL transport modes, that include buses, trams, trains, metros and ferries. The bus traffic and train traffic are procured publicly from private operators. Metro and tram traffic is due to be publicly procured in the future but is currently operated by Metropolitan Area Transport Ltd. Currently HSL operations include approximately: 1350 buses 200 trams 80 trains 50 metros 4 ferries These amounts are subject to changes according to possible changes to planned operations within the HSL jurisdiction. Software is needed in all modes of transport. Software needs to be configurable in different modes according to the type. In buses and trams Tenderer is responsible for the system throughout the life span of the solution. In the first stage for metros, ferries and trains system requirements are real time information to backend and route monitoring APIs for ticketing devices. In the future, possibly also parts of the passenger information controls will be handled by this system, for example passenger information displays and announcements. Hardware must include the driver display itself, possible special cables and a mounting bracket, that will be used to mount driver displays to buses. The number of displays needed is correlated with the number of buses in operation, which is estimated above. Also, additional driver displays are needed for maintenance cycles for the bus operator’s maintenance personnel. The Tenderer must be able to provide maintenance and support for the hardware offered in co-operation with third parties. The Tenderer is mainly responsible for fault analysis and hardware repair or replacement processes. Operators are responsible for swapping the faulty devices in vehicles and the Client is responsible for courier services to transfer devices between warehouses, operator’s depot and Tenderers local hardware service point. The client uses RFID tags for hardware stock management also known as inventory management system. These RFID tags must be installed to all tendered hardware by the Tenderer. However, the Client will provide RFID tags for the Tenderer. The Client’s inventory management is used to track and manage inventory to identify hardware location at any given moment. For example, displays might locate in the Client’s warehouse, the Tenderer’s hardware replacement inventory, Bus operator’s depot storage locker that is part of the inventory management system. The EU accessibility and usability directives must be respected. Summary of the planned project schedule Tenderer show cases current state of the solution and plan for next steps 12/2025-01/2026 Tenderer will start the completion of the Initial Release 01/2026 Tenderer will provide the Client with ten (10) test driver displays 03/2026 The Client will audit test driver displays with environment requirements 03-04/2026 The Client will monitor and support progress of the Initial Release 02-08/2026 The Tenderer will complete Initial Release (Including the installation to CAT 08/2026 The Client will audit and test Initial Release (If no flaws, accept it) 08/2026 Piloting of the solution in different transport modes 08-10/2026 The Client and Tenderer will plan the production installations 08-10/2026 Production installations will start 10/2026 Tenderer will start the implementation of the feature packs 10/2026 Production installations are completed, and feature packs are installed 08/2027. For more details, see Appendix Appendix_1_Subject_Matter_Of_The_Procurement. All the deadlines specified in the invitation to tender are given in Finnish time.