Publications Office of the EU
Invitation for market dialog: solution for driver terminal as part of HSL information system - EU tenders
DisplayCustomHeader
Procurement Detail Actions Portlet
OP Portal - Procurement - Details

Invitation for market dialog: solution for driver terminal as part of HSL information system

  • Announced
    14/02/2025
  • Today
    27/08/2026
Status
Inactive
Type of contract
Services
Subject for Renewal
No
Buyer
Helsingin Seudun Liikenne - kuntayhtymä
Place of performance
NUTS code: anyw-eea
Location of buyer
NUTS code: FI1B1 Helsinki-Uusimaa
Business sector (Main CPV)
72000000 IT services: consulting, software development, Internet and support
Total estimated contract value (excluding VAT)
Not available
Total final contract value (excluding VAT)
The procedure is closed
Tender reference number
34/02.08.00/2025
Description

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.

Submission Method
Not available
Tenders may be submitted
Not available
Information about a public contract, a framework agreement or a dynamic purchasing system (DPS)
The procurement involves the establishment of a framework agreement
Conditions for opening tenders (date)
Not available
Place of performance
Award method
Not available
Estimated value
Not available
Final contracted value
The procedure is closed
Award of contract
The procedure is closed
Prior information
Contract
Award
Footnote - legal notice

This content published on this page is meant purely as an additional service and has no legal effect. The Union's institutions do not assume any liability for its contents. The official versions of the relevant tendering notices are those published in the Supplement of Official Journal of the European Union and available in TED. Those official texts are directly accessible through the links embedded in this page. For more information please see Public Procurement Explainability and Liability notice.