At the Requirements Committee meeting on the 14th of October, the Login Service Working Group was launched with Anastasia Founta from the ITxPT team as interim leader. Guido Di Pascale, Chairman of the Requirements Committee, requested tips and ideas of influential Public Transport organizations in each country to engage them in local ITxPT activities.
Members engagement – map local influencers
Chairman Guido Di Pascale informed the meeting that ITxPT composing a country-by-country list of influential Public Transport organizations and stakeholders. The Requirements Committee will contact them individually to inspire local engagement.
Influencers like the National Associations, who already have a strong connection to authorities, operators, and other stakeholders, can advance the engagement in ITxPT through hosting events, webinars and by reaching out to their network. All ITxPT members could aid this process.
Please contact ITxPT with ideas of organizations and specific persons to approach.
Kickoff – Login Service Working Group
The “Login Service,” Working Group launch was well attended, and the group meetings will continue to take place in connection with the regular Requirements Committee meetings for convenient scheduling. The end date is the 11th of November 2020, with a first draft of the Functional Requirements at the beginning of November.
Until the next meeting, group leader Anastasia Founta asked all participants to write use cases. The next meeting will decide which ones are the most relevant, and an additional workshop will process the selected ones.
Requirements Committee Working Group 03 description
Working Group focus
The group focuses on PTOs/PTAs needs related to the drivers‘ login methodology. It will discuss the daily operations challenges, such as ensuring the correct assignments between vehicles, drivers, and planned routes. From the discussions, the group will identify functional requirements.
Today, different operations and countries use login services in different ways and levels, which causes incompatibility problems and integration costs. The lack of compatibility has been a problem for a long time, affecting many systems. It is a core issue to solve before proceeding with other topics and areas.
According to input collected buy ITxPT through Incoming Requests and Change Requests, there is a need for a well-defined login service. A standardized API for systems to publish and subscribe to different types of login information:
- Onboard to Backoffice
- Backoffice to Backoffice
Main objectives list:
- Identify login types, such as driver, vehicle duty, and others
- Consider additional transport modes like tram, ferry, and train
- Harmonize the definitions of login types
- Identify login producer/consumer chains and potential variants. How does the map of users-consumers look?
- Identify core data and metadata needed per login type
- Create use-cases based on results above
- Create a Functional Request document based on the latest template
Working Group 03 – Additional notes and reflections
How far does the scope reach? Does it include driver check-in in the garage?
Yes. It can be shift login, driver/vehicle login, a driver assigned from the Backoffice, or driver change during a vehicle shift. The group should aim to identify all kinds of login.
When using Backoffice prediction of trip start, the system needs a confirmation when the actual trip starts. Will this be included?
Real-time systems would be one of the consumers of this information. That is why there is a need for plotting the producers and consumers. CCTV systems need info as well. The scope should cover all types of confirmations and logins.
Should we consider all transport modes?
Yes, the group should consider all transport modes as a starting point and possibly exclude certain aspects that prove too complicated later.
Are there other standards describing login methodology?
There are some descriptions in Transmodel to investigate, but the group shouldn’t be restricted to using just the Transmodel cases but describe what the users need.
Can the existing ITxPT specification be used?
It could be the case that some of the issues are possible to handle with the existing technical ITxPT specification. In that case, the Technical Committee response to the Functional Requests should explain how to use the specification to deal with it.