Technical Board 2024-05-08 #62
emiltin
announced in
Technical Board
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Participants
David, Emil
Summary
At this meeting, we focused on preparations for the upcoming steering group meeting.
We reviewed the previous activity plan, and discussed what should be included in the proposed next activity plan that the steering group will consider.
Charter
Fintraffic and Oula will participate for the first time, as new permament guest.
From France, the Department of Transport and CEREMA will take par as guests.
There is no need for changes to the charter at this time.
RSMP landscape
Let's describe the "state of RSMP" once per year. Key metrics could include:
Data could be aggregated by country and year.
Staffing
Few people in WG's (david, emil) makes the organization fragile.
How do we expand the involved group? Fintraffic, French partners, Oslo?
Stockholm and Danish Road authorities in the Technical Board, not very active, at the moment.
Competition, marked situation
The main goals of road authorities are:
RSMP has attracted new players, but they still have a very low marked share.
Many smaller road authorities don't have resources for helping vendors with implementing RSMP. Many of the questions and bug fixes are currently handled by RSMP Nordic (currently hours are mainly provided by STA and CPH).
Activity Plan
Staffing
next:
David: 40%, 15h/week
Emil: to be determined
VD, Stockholm: to be determined
Fintraffic, France? Let's ask them.
Core
3.2.1:
Done
3.3:
Ongoing, planned for oct 2024, but will be moved.
4.0:
Technical investigations are ongoing and promising. We recommend to continue the v4 WG, but focused on MQTT, to answer questions around benefits, risks, resources, etc.
Issues with RSMP 3: transport layer, multiple supervisors, bandwidth, encryption, SXL modules.
Benefits of MQTT: battle tested transport layer, broker makes it easy to have multiple supervisors/central systems, many 3rd party tools, less bandwidth, SXLmodules, QUIC/encryption.
Encryption is an important topic. The french partners are working on proposals regarding this.
TLC SXL
1.1.1:
Done
1.2:
Done
LISA:
Stalled, since SWARCO will not support RSMP in LISA. So this activity will be cancelled for now. Instead we propose a new WG on signal programming, see below.
SXL Standardization
VMS:
Ongoing, we hav a good technical concept.
Counters:
Initiated.
IO:
Not started
Oct 2024 release to be moved
It has been a challenge to get relevant feedback from authorities. Next step is to get input from vendors.
Test Tools
1.0:
Planned for this month. Certain limitation will be noted. Documentation is already quite good.
Extend:
Done
Publishing test results:
We now have a limited publication of result, but would like to do more.
Test hub:
Ongoing, SWARCO has committed to having a TLC online. Dialogue with Yunix, contact with other vendors.
Certification (new WG)
We propose a new WG about RSMP certification.
Certification of equipment/systems would make it easier for road authorities to pick RSMP. How can certifications be managed?
French partners are already working on a setup for certification, handled by a national body.
Communication
Refine website:
Done (e.g. partner list, specifications, blog)
Conferences:
Done. Presentation in Paris.
User group:
Done, user group is ongoing.
Invite authorities:
Done, we have had a good dialogue with French partners, and it now looks as France will use RSMP. Initial contacts with Spanish partners.
New suppliers:
French vendors, Yunix, La Semaphorica.
Standardization:
STA is participating in NordicWays 3. French partners have strong representation in EU-groups on standardization. France has mentioned the possibility of working towards RSMP as an EU-standard.
Could we consider RSMP4 as a wrapper/unifier of various regional standards? E.g. you could send rsmp/ocit/ivera messages via rsmp4/mqtt. A step towards a EU-standard
Internal communication:
We will need to be better at telling the RSMP success stories, how much it's used, etc. If one partner would stop using RSMP, RSMP would still continue.
Strategic communication:
New VMS'es in STA will not using RSMP,, but NTP-IP. Why? equipment and central system already supported NTC-IP. so cheaper short-term, less perceived risk. No larger discussion about long term strategies around protocols took place. Using another protocol means less resources for RSMP development.
Admin
Membership list:
Done, is being maintained by the secretariat/KK.
Steering group:
Done, but there has been a gap in the meeting, due to Emil being on sick leave
EU-funding:
To do
Signal Programming (new)
We propose a new WG on TLC signal programming. (Alternatively, the activity could be part of the existing TLC SXL WG.)
The need for making signal programming easier and cheaper has been the main driver for the growth of LISA in Denmark.
RSMP has so far not really had a visions for how to meet this need. Should we get into this space, e.g. with an open spec for signal programs? This would open up the possibility for vendor-neutral tools and workflow for signal programming, open-source tools, etc.
A spec for signal programs would be easier to develop and verify if we also create a TLC emulator that can read and run the signal programs, similar to how we currently have a TLC emulator that is very helpful when developing our RSMP Validator test suite.
How would we move from a spec to actually having tools and equipment in production? How long would it take? Resources?
A secondary purpose of this WG coulld be to further clarify attributes and behaviour aspects of the existing TLC SXL, and to improve the TLC emulator so it becomes a true reference implementation.
Beta Was this translation helpful? Give feedback.
All reactions