34/02.08.00/2025 / Invitation for market dialog: solution for driver terminal as part of HSL information system
Tiivistelmä
Katso samankaltaisia mahdollisuuksia
Kaikkien tietojen näyttäminen vaatii rekisteröitymisen ja kirjautumisen palveluun.
34/02.08.00/2025 / Invitation for market dialog: solution for driver terminal as part of HSL information system
Hankintailmoitustyyppi
Suunnittelu [TED eF[5]]
Julkaistu
13.2.2025
14:51
(UTC+02:00)
Organisaatio
Helsingin Seudun Liikenne - kuntayhtymä
Kuvaus
Helsinki Region Transport, HSL in short, is a joint local authority whose member municipalities include Helsinki, Espoo, Vantaa, Kauniainen, Kerava, Sipoo, Tuusula, Kirkkonummi and Siuntio. HSL procures bus, tram, metro, ferry, and commuter train services and is responsible for public transport marketing and passenger information.
The new driver terminal solution will be implemented in all HSL buses, trams, metros and commuter trains: 1300 buses, 200 trams, 80 trains and 50 metros. Values are approximate and subject to change if HSL traffic increases. 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 Helsinki City Transport Ltd.
The current HSL information system has been provided and integrated by an overall supplier and is already a modular entirety, thus aiming towards a system migration in phases is probable choice of plan for the future. The current system is based on FARA vehicle configuration, Hogia PubTrans backend system and Mattersoft (part of INIT) operation monitoring and management software (OMM) and traffic light priority planning and management software (JLVEP). System components are integrated to each other with IBM ESB platform and most of the components are running on physical servers.
The intent of this invitation is to give participants an opportunity to present and discuss their solutions, one scenario being for example a proprietary software implemented as an Android/iOS application or a web application. The application will use onboard ITxPT services and possible other onboard services. The application may use also microservices offered from Azure cloud.
Here is a list of possible minimum set of applications in the driver terminal (MVP approach; not necessarily limited to these):
1. Vehicle assignment application: Provide a view to assign vehicle to a block and to a vehicle journey.
2. Vehicle progress application: Display route pattern and geometry. Display vehicle position on route pattern. Display schematic view for driver.
3. Driving aid application: Inform regulated timing point. Deviation route information.
4. Notices and messages application: Provide disruption notices browsing and reading view.
5. Driver terminal frame: Display official date and time. Produce audio notification. Display disruption notice indicator.
6. Outer display control application: “Bus full” -button in driver terminal.
Vehicle environment provides additional services for the driver terminal including vehicle computer with built in 5G and GNSS capabilities (router). The vehicle computer also provides a x64 Debian based Docker environment for driver terminal software which is required to be used in rail transport modes and is optionally available for buses. All specialized IO is available in the vehicle computer (serial ports, CAN connection etc.). Buses have FMStoIP available for driver terminal.
The purpose of the driver terminal procurement is to procure mostly software, and that the provider will use HSL hardware platform for the solution. It is possible that the driver display hardware is part of this procurement, but this is something that will be discussed within the technical discussions. However, the solution should be such that it is able to run on any given hardware, for example integrated touchscreen display as it is in the trams currently. The main idea behind this vehicle solution is that HSL will provide information of the current situation and the interfaces, and that the provider will give solution. HSL prefers not to specify the solution too much and thus find a mostly ready-made solution that fits the HSL's needs. We want to avoid technical tailoring, in other words, build to suit to our needs. Mostly the solutions should include all the tools for the driver to be able to do all the necessary actions to drive the route and the assistance for the driving. So, we want to discuss with providers to find the most suitable solution for our needs, including an open competition for tendering.