Ideas for a proof-of-concept project

[HtoTheB]

Hi all,
As we've discussed it might make sense to try to create a public reference project. This project should entail the full development lifecycle of a fusa application, including a proper requirements capture, architecture design, as well as accompanying review reports. The goal of this would be to test out what the currently available tools are already capable of, and where they are insufficient for our requirements. +

Please use this issue to discuss what this project should look like, how we can find a simple project that is easy to understand without railway domain knowledge, that still shows how many requirements it is subjected to regardless of it's actual functionality.

[Yale0wA]

Hello!

Here is my proposition: an Interlocking system.

To be clear, yes it does require some knowledge in railway sector, especially in signaling systems, but as long as it not a "niche" domain, there are plenty of resources.
Furthermore, I think this is a good starting point because it exposes some interesting challenges (see below).

As a starting point, this project requires inputs from "real world" customers (like DB/SNCF) for requirements. @HtoTheB I think we could discuss about it in next meeting. The goal here is to have requirements that matches the ones given to industrial companies (as an example), or, at least, something close to it.

1: System requirements
From these customers requirements we could write systems requirements that define:

• How the solution will be make? Does it requires sub-systems? If yes, how are they? What are they doing?
• Interface communication documents. Does the client imposes a specific manner? A specific protocol? If we have sub-systems, how they communicate between each others?

➡️ The first point would be to find a a proper software that is able to create requirements.

1 bis: Data management
One major thing of this kind of software is "data management". Indeed, in interlocking you have to defines all the objects on your track (and handle there number). I think this a crucial point because it need to be at the same time:

• Easy to input new elements/modify and visualize them.
• Generates secure data for your application. Since it has a direct impact on software behavior, the generation part must be qualified SIL4.

➡️ Here, in my opinion, we need to explore 2 topics:

• Existing data format (railjson for example) and do they meet the needs of railway customers?
• An editor + a generator that (eventually) is able to produce the database for system configuration. (maybe OSRD?)

2: Software part
If we plan to go on software part (at a later stage maybe?) there will be topics as well like:

• What language/framework would be suitable for the needs of the projects? (depends on software specifications)
• How to test them in order to prove it is a safety critical application? (unit/functional tests? MC/DC coverage...)

Just a quick note on software part. As discussed in previous meeting, going directly on a platform seems to be too complicated at this stage. I think we should stay on an "application only" project as a beginning.

Let me know what do you think about it this idea.

[HtoTheB]

Hi there,

To conduct the analyses in a structured way it would be beneficial if we set up the correct tools for the job initially. ELISA took part in the development of several such tools that we could use for a requirements capture and subsequent traceability such as BASIL. I'm sure we could get an instance set up for us to work on this.

Regarding the platform, the ELISA Systems WG had developed a "reference platform", but from my understanding so far I think pulling Linux into the system will be unnecessary in the beginning. It could run fully on a qualified RTOS such as Zephyr.

I think getting these things set up is a lot more important than actually working on the product. Showing that we could - in theory - create all required artifacts to get the product assessed just by using FOSS tools will be the largest lever that we can provide. And actually using those tools to notice what's still missing will give us lots of opportunities to improve.

Hope to discuss this more in todays meeting. See you then!

[lars-2a]

Hi there, I think the Idea of @Yale0wA is very interesting. But I fear it is a bit to large for a simple proof of concept. Maybe we could start with something a little smaller. Something that still requires some knowledge of the railway sector but is more manageable. I would propose something like a Level Crossing with one single track. It has a manageable amount of stakeholder requirements, and everybody can relate to it. Or something like a railroad signal.

[marco50129]

Regarding LX as Example: It could be a very small system: Controlled from the IXL with just traffic lights and barriers as with ixl controlled the time the LX is closed ist too long (german code for that: HP - LzH).

[HtoTheB]

Collection of material that showcases how an interlocking system works:

• Textbook of Prof. Dr.-Ing. Jörn Pachl: http://www.joernpachl.de/German_principles.htm
• Specification of interfaces between components: https://www.rasta-stack.ch/en/eulynx

Database of interlockings and interlocking accidents in Belgium:

• https://opendata.infrabel.be/explore/