From 77422bf4b66d765ffcbe490966d260ec90509a5c Mon Sep 17 00:00:00 2001 From: flomonster Date: Tue, 21 Jan 2025 08:44:16 +0000 Subject: [PATCH] deploy: 6ef72865e5ec5bc6dfe92f19bbf3f5088e907fec --- en/404.html | 2 +- en/about/_print/index.html | 4 +- en/about/governance/index.html | 4 +- en/about/index.html | 4 +- en/about/opendata/index.html | 4 +- en/about/opensource/index.html | 4 +- en/about/roadmap/index.html | 4 +- en/about/use-case/_print/index.html | 4 +- en/about/use-case/index.html | 4 +- .../index.html | 4 +- .../04/12/dgex-solutions-forum/index.html | 4 +- .../index.html" | 4 +- en/blog/_print/index.html | 4 +- en/blog/index.html | 4 +- en/blog/news/_print/index.html | 4 +- en/blog/news/index.html | 4 +- en/categories/index.html | 2 +- en/docs/_print/index.html | 50 ++-- en/docs/explanation/_print/index.html | 4 +- .../containers-architecture/_print/index.html | 4 +- .../containers-architecture/index.html | 10 +- en/docs/explanation/index.html | 10 +- en/docs/explanation/models/_print/index.html | 4 +- .../data-models-full-example/index.html | 10 +- en/docs/explanation/models/index.html | 10 +- .../models/neutral_sections/index.html | 10 +- .../netzgrafik-editor/_print/index.html | 4 +- .../explanation/netzgrafik-editor/index.html | 10 +- .../_print/index.html | 4 +- .../allowances/index.html | 10 +- .../envelopes_system/index.html | 10 +- .../running_time_calculation/index.html | 10 +- .../numerical_integration/index.html | 10 +- .../physical_modeling/index.html | 10 +- .../pipeline/index.html | 10 +- en/docs/guides/_print/index.html | 24 +- en/docs/guides/contribute/_print/index.html | 4 +- .../guides/contribute/bug-reports/index.html | 10 +- .../guides/contribute/code-review/index.html | 10 +- .../contribute-code/_print/index.html | 4 +- .../backend-conventions/index.html | 10 +- .../commit-conventions/index.html | 10 +- .../frontend-conventions/index.html | 10 +- .../general-principles/index.html | 10 +- .../contribute/contribute-code/index.html | 10 +- .../contribute-code/share-changes/index.html | 10 +- .../contribute-code/tests/index.html | 10 +- .../contribute-code/write-code/index.html | 10 +- en/docs/guides/contribute/index.html | 10 +- .../contribute/install-docker/index.html | 10 +- .../contribute/license-and-set-up/index.html | 10 +- en/docs/guides/contribute/preamble/index.html | 10 +- .../contribute/review-process/index.html | 10 +- en/docs/guides/deploy/_print/index.html | 4 +- .../deploy/docker-compose/_print/index.html | 4 +- .../guides/deploy/docker-compose/index.html | 10 +- en/docs/guides/deploy/index.html | 10 +- .../deploy/kubernetes/_print/index.html | 4 +- en/docs/guides/deploy/kubernetes/index.html | 10 +- .../guides/deploy/stdcm-search-env/index.html | 10 +- en/docs/guides/design/index.html | 10 +- en/docs/guides/index.html | 10 +- en/docs/guides/index.xml | 63 +---- en/docs/guides/logo/index.html | 10 +- en/docs/guides/release/_print/index.html | 37 +++ en/docs/guides/release/index.html | 34 +-- en/docs/guides/release/index.xml | 90 +++++++ en/docs/guides/release/process/index.html | 95 +++++++ en/docs/guides/release/publish/index.html | 97 +++++++ en/docs/index.html | 10 +- en/docs/index.xml | 250 ++++++++---------- en/docs/railway-wiki/_print/index.html | 4 +- .../railway-wiki/glossary/_print/index.html | 4 +- en/docs/railway-wiki/glossary/index.html | 10 +- en/docs/railway-wiki/index.html | 10 +- .../spacing/ertms/_print/index.html | 4 +- .../signalling/spacing/ertms/etcs/index.html | 10 +- .../signalling/spacing/ertms/index.html | 10 +- en/docs/reference/_print/index.html | 30 +-- en/docs/reference/apis/_print/index.html | 4 +- en/docs/reference/apis/index.html | 10 +- .../reference/architecture/_print/index.html | 4 +- .../architecture/data_flow/index.html | 10 +- en/docs/reference/architecture/index.html | 10 +- .../architecture/services/index.html | 10 +- .../reference/design-docs/_print/index.html | 30 +-- .../design-docs/auth/_print/index.html | 4 +- .../auth/editoast-internal-api/index.html | 10 +- en/docs/reference/design-docs/auth/index.html | 10 +- .../design-docs/conflict-detection/index.html | 10 +- en/docs/reference/design-docs/index.html | 10 +- .../design-docs/scalable-async-rpc/index.html | 10 +- .../design-docs/signaling/_print/index.html | 20 +- .../signaling/blocks-and-signals/index.html | 10 +- .../design-docs/signaling/index.html | 10 +- .../reference/design-docs/signaling/index.xml | 16 +- .../signaling/signaling-systems/index.html | 10 +- .../signaling/simulation/index.html | 10 +- .../signaling/speed-limits/index.html | 26 +- .../design-docs/stdcm/_print/index.html | 4 +- .../stdcm/domain_context/index.html | 10 +- .../reference/design-docs/stdcm/index.html | 10 +- .../pathfinding_module/_print/index.html | 4 +- .../backtracking/index.html | 10 +- .../conflict_avoidance/index.html | 10 +- .../conflict_detection/index.html | 10 +- .../graph_representation/index.html | 10 +- .../implementation_details/index.html | 10 +- .../stdcm/pathfinding_module/index.html | 10 +- .../infrastructure_exploration/index.html | 10 +- .../standard_allowance/index.html | 10 +- .../design-docs/timetable/index.html | 10 +- .../train-sim-v3/_print/index.html | 14 +- .../driver-behavior-modules/index.html | 14 +- .../driving-instruction/index.html | 16 +- .../design-docs/train-sim-v3/index.html | 10 +- .../design-docs/train-sim-v3/index.xml | 10 +- .../train-sim-v3/overview/index.html | 10 +- .../train-sim-v3/prior-art/index.html | 10 +- en/docs/reference/index.html | 10 +- en/index.html | 4 +- en/join-us/_print/index.html | 4 +- en/join-us/index.html | 4 +- en/sitemap.xml | 2 +- en/tags/index.html | 2 +- fr/404.html | 2 +- fr/about/_print/index.html | 4 +- fr/about/governance/index.html | 4 +- fr/about/index.html | 4 +- fr/about/opendata/index.html | 4 +- fr/about/opensource/index.html | 4 +- fr/about/roadmap/index.html | 4 +- fr/about/use-case/_print/index.html | 4 +- fr/about/use-case/index.html | 4 +- .../index.html" | 4 +- .../index.html" | 4 +- .../04/12/forum-dgex-solutions/index.html | 4 +- .../04/24/ia5-et-pip6-avril-2023/index.html | 4 +- .../index.html" | 4 +- .../2023/12/13/presentation-osrd-1/index.html | 4 +- fr/blog/_print/index.html | 4 +- fr/blog/index.html | 4 +- fr/blog/news/_print/index.html | 4 +- fr/blog/news/index.html | 4 +- fr/categories/index.html | 2 +- fr/docs/_print/index.html | 42 ++- fr/docs/explanation/_print/index.html | 4 +- .../containers-architecture/_print/index.html | 4 +- .../containers-architecture/index.html | 9 +- fr/docs/explanation/index.html | 9 +- fr/docs/explanation/models/_print/index.html | 4 +- .../data-models-full-example/index.html | 9 +- fr/docs/explanation/models/index.html | 9 +- .../models/neutral_sections/index.html | 9 +- .../netzgrafik-editor/_print/index.html | 4 +- .../explanation/netzgrafik-editor/index.html | 9 +- .../_print/index.html | 4 +- .../allowances/index.html | 9 +- .../envelopes_system/index.html | 9 +- .../running_time_calculation/index.html | 9 +- .../numerical_integration/index.html | 9 +- .../physical_modeling/index.html | 9 +- .../pipeline/index.html | 9 +- fr/docs/guides/_print/index.html | 40 ++- fr/docs/guides/contribute/_print/index.html | 4 +- .../guides/contribute/bug-reports/index.html | 9 +- .../guides/contribute/code-review/index.html | 9 +- .../contribute-code/_print/index.html | 4 +- .../backend-conventions/index.html | 9 +- .../commit-conventions/index.html | 9 +- .../frontend-conventions/index.html | 9 +- .../general-principles/index.html | 9 +- .../contribute/contribute-code/index.html | 9 +- .../contribute-code/share-changes/index.html | 9 +- .../contribute-code/tests/index.html | 9 +- .../contribute-code/write-code/index.html | 9 +- fr/docs/guides/contribute/index.html | 9 +- .../contribute/install-docker/index.html | 9 +- .../contribute/license-and-set-up/index.html | 9 +- fr/docs/guides/contribute/preamble/index.html | 9 +- .../contribute/review-process/index.html | 9 +- fr/docs/guides/deploy/_print/index.html | 4 +- .../deploy/docker-compose/_print/index.html | 4 +- .../guides/deploy/docker-compose/index.html | 9 +- fr/docs/guides/deploy/index.html | 9 +- .../deploy/kubernetes/_print/index.html | 4 +- fr/docs/guides/deploy/kubernetes/index.html | 9 +- .../guides/deploy/stdcm-search-env/index.html | 9 +- fr/docs/guides/design/index.html | 9 +- fr/docs/guides/index.html | 9 +- fr/docs/guides/index.xml | 3 +- fr/docs/guides/logo/index.html | 9 +- fr/docs/guides/release/_print/index.html | 37 +++ fr/docs/guides/release/index.html | 95 +++++++ fr/docs/guides/release/index.xml | 90 +++++++ fr/docs/guides/release/process/index.html | 111 ++++++++ fr/docs/guides/release/publish/index.html | 113 ++++++++ fr/docs/index.html | 9 +- fr/docs/index.xml | 149 +++++++---- fr/docs/railway-wiki/_print/index.html | 4 +- .../railway-wiki/glossary/_print/index.html | 4 +- fr/docs/railway-wiki/glossary/index.html | 9 +- fr/docs/railway-wiki/index.html | 9 +- .../railway-wiki/signalling/_print/index.html | 4 +- fr/docs/railway-wiki/signalling/index.html | 9 +- .../operation-modes/_print/index.html | 4 +- .../double-track-lines/_print/index.html | 4 +- .../double-track-lines/index.html | 9 +- .../index.html | 9 +- .../opposite-track-movement/index.html | 9 +- .../index.html | 9 +- .../temporary-single-track/index.html | 9 +- .../signalling/operation-modes/index.html | 9 +- .../single-track-lines/_print/index.html | 4 +- .../single-track-lines/index.html | 9 +- .../single-track-shuttle/index.html | 9 +- .../single-track-two-ways/index.html | 9 +- .../index.html | 9 +- .../index.html | 9 +- .../single-track/index.html | 9 +- .../signalling/risks/_print/index.html | 4 +- .../railway-wiki/signalling/risks/index.html | 9 +- .../signalling/signals/_print/index.html | 4 +- .../signalling/signals/index.html | 9 +- .../signalling/spacing/_print/index.html | 4 +- .../automatic_block_systems/_print/index.html | 4 +- .../automatic_block_systems/bal/index.html | 9 +- .../automatic_block_systems/bapr/index.html | 9 +- .../automatic_block_systems/index.html | 9 +- .../spacing/ertms/_print/index.html | 4 +- .../signalling/spacing/ertms/etcs/index.html | 9 +- .../signalling/spacing/ertms/etml/index.html | 9 +- .../signalling/spacing/ertms/frmcs/index.html | 9 +- .../signalling/spacing/ertms/gprs/index.html | 9 +- .../signalling/spacing/ertms/gsm-r/index.html | 9 +- .../signalling/spacing/ertms/index.html | 9 +- .../signalling/spacing/index.html | 9 +- fr/docs/reference/_print/index.html | 4 +- fr/docs/reference/apis/_print/index.html | 4 +- fr/docs/reference/apis/index.html | 9 +- .../reference/architecture/_print/index.html | 4 +- .../architecture/data_flow/index.html | 9 +- fr/docs/reference/architecture/index.html | 9 +- .../reference/design-docs/_print/index.html | 4 +- fr/docs/reference/design-docs/index.html | 9 +- .../interlocking/_print/index.html | 4 +- .../design-docs/interlocking/index.html | 9 +- .../interlocking/location/index.html | 9 +- .../interlocking/movable-elements/index.html | 9 +- .../interlocking/ordering/index.html | 9 +- .../interlocking/reservation/index.html | 9 +- .../interlocking/routing/index.html | 9 +- .../design-docs/interlocking/train/index.html | 9 +- .../design-docs/stdcm/_print/index.html | 4 +- .../stdcm/domain_context/index.html | 9 +- .../reference/design-docs/stdcm/index.html | 9 +- .../pathfinding_module/_print/index.html | 4 +- .../backtracking/index.html | 9 +- .../conflict_avoidance/index.html | 9 +- .../conflict_detection/index.html | 9 +- .../graph_representation/index.html | 9 +- .../implementation_details/index.html | 9 +- .../stdcm/pathfinding_module/index.html | 9 +- .../infrastructure_exploration/index.html | 9 +- .../standard_allowance/index.html | 9 +- fr/docs/reference/index.html | 9 +- fr/index.html | 4 +- fr/join-us/_print/index.html | 4 +- fr/join-us/index.html | 4 +- fr/search/index.html | 2 +- fr/sitemap.xml | 2 +- fr/tags/index.html | 2 +- ...ndex.727c2448a85822052eaf432fb7c6ddab.json | 1 + ...ndex.e9842b231b04e10ba94e44ad11bfba07.json | 1 - 274 files changed, 2280 insertions(+), 1102 deletions(-) create mode 100644 en/docs/guides/release/_print/index.html create mode 100644 en/docs/guides/release/index.xml create mode 100644 en/docs/guides/release/process/index.html create mode 100644 en/docs/guides/release/publish/index.html create mode 100644 fr/docs/guides/release/_print/index.html create mode 100644 fr/docs/guides/release/index.html create mode 100644 fr/docs/guides/release/index.xml create mode 100644 fr/docs/guides/release/process/index.html create mode 100644 fr/docs/guides/release/publish/index.html create mode 100644 offline-search-index.727c2448a85822052eaf432fb7c6ddab.json delete mode 100644 offline-search-index.e9842b231b04e10ba94e44ad11bfba07.json diff --git a/en/404.html b/en/404.html index 7aac2fbe3..17ab45bd7 100644 --- a/en/404.html +++ b/en/404.html @@ -1,2 +1,2 @@ 404 Page not found | OSRD -

Not found

Oops! This page doesn't exist. Try going back to our home page.

You can learn how to make a 404 page like this in Custom 404 Pages.

© 2024 OSRD contributors. All Rights Reserved
\ No newline at end of file +

Not found

Oops! This page doesn't exist. Try going back to our home page.

You can learn how to make a 404 page like this in Custom 404 Pages.

© 2025 OSRD contributors. All Rights Reserved
\ No newline at end of file diff --git a/en/about/_print/index.html b/en/about/_print/index.html index 6665010de..e13713ac5 100644 --- a/en/about/_print/index.html +++ b/en/about/_print/index.html @@ -1,5 +1,5 @@ About | OSRD -

This is the multi-page printable view of this section. +

This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

About

OSRD is a railway toolbox designed for multiple use cases. These tools have in common a reliance on railway infrastructure simulation and results analysis.

1 - Governance

Governance and organization of OSRD

One of the ambitions of OSRD is to help with timetabling on a European scale.

To reach this goal, OSRD has to take local features into account by consulting and collaborating with railway companies and infrastructure operators.

And by contributing to OSRD, these companies:

  • Profit from all the common development efforts
  • Can freely build on the common effort to achieve their own goals1
  • Participate in the roadmap and technical direction of the project to the extent of their contribution

OSRD is currently developed by:

The OpenRail association

The OpenRail association is an upcoming non-profit committed to organizing cooperative work around railway software tools.

OpenRail association

  1. As long as they don’t modify the common tools without sharing their improvements. See the details of the LGPLv3 license. ↩︎

2 - Use cases

Use cases related to rail transport planning

OSRD presentation

OSRD is meant to fulfill a range of use-cases related to railway planning:

produits OSRD

Timetabling

Timetabling is about designing a transport service in order to meet the transit needs.

OSRD addresses this by providing:

  • a track level railway infrastructure database
  • a rolling stock database
  • an infrastructure edition tool
  • a timetabling tool
  • train path allowances, including an allowance distribution which minimizes energy use

Planned features include:

  • automated conflict detection1
  • line level infrastructure synthesis from track level infrastructure
  • interactive timetable diagrams
  • a throughput and rolling stock turnover optimizer

Operation studies

Operation studies assess the ability of infrastructures to meet demand, and balance infrastructure capacity with transportation needs. @@ -21,4 +21,4 @@ Maintainers are responsible for keeping the project working and consistent. Maintainers are chosen among developers by developers. What motivates whether to integrate a change or not is technical viability: the goal of everyone involved is to maintain high level of service and quality standard.

  1. Source code is a set of text documents which describes how a piece of software works. It’s the result of the work of software developers. ↩︎

4 - Open Data

OSRD and Open Data

Open Data is the practice of making data public accessible under a permissive license. It is not the same as open source, which only applies to software.

Open data and open source have a symbiotic relationship : without open data, an open source railway software can only be used by industry insiders. Managing data access is hard, expensive, often not necessary, and reduces the availability of critical data.

Alone, open data already brings a number of key benefits:

  • companies can use open data in their products, which also promotes railway services
  • researchers can study the data immediately, and can find the data by themselves

Yet, open data used by an open source toolbox open up new prospects:

  • companies and researchers can use the open source tools to analyse the data, which greatly reduces the barrier to entry by alleviating the need for custom or paid-for tools
  • customers can use the toolbox to improve how they use railway services

If multiple actors have open data exploitable by an open source tool, these datasets can be combined and used to provide and plan for common services.

OSRD and Open Data

  • having rolling stock and infrastructure open data enables anyone to simulate trains, study and evaluate the railway network
  • having timetable open data enables anyone to study rail network usage

5 - Roadmap

Macroscopic Roadmap

Here’s a list of the big features OSRD wants to support. The order of items depends on priority (the higher the item, the more valuable it is). -This roadmap is spread over a couple of years.

  • Add ERTMS signaling system support.
  • A fine-grained permission system.
  • Support cyclic train schedule. Improving Netzgrafik-Editor integration.
  • Send STDCM trains to external services for storage and processing.
  • Create annual transport plan service.
  • Support a linear referencing LRS commonly used in the railway industry. Usage of railway mileposts.
  • Revamp the infrastructure editor.
  • New dynamic simulator. Simulate a timetable on an infrastructure and observe generated delays.
  • Versioning infrastructures.
  • Revamp train simulation v3.

If you’d like to push for one of these features, or if you have ideas for what OSRD could do in the future, don’t hesitate to join the project!

© 2024 OSRD contributors. All Rights Reserved
\ No newline at end of file +This roadmap is spread over a couple of years.

  • Add ERTMS signaling system support.
  • A fine-grained permission system.
  • Support cyclic train schedule. Improving Netzgrafik-Editor integration.
  • Send STDCM trains to external services for storage and processing.
  • Create annual transport plan service.
  • Support a linear referencing LRS commonly used in the railway industry. Usage of railway mileposts.
  • Revamp the infrastructure editor.
  • New dynamic simulator. Simulate a timetable on an infrastructure and observe generated delays.
  • Versioning infrastructures.
  • Revamp train simulation v3.

If you’d like to push for one of these features, or if you have ideas for what OSRD could do in the future, don’t hesitate to join the project!

© 2025 OSRD contributors. All Rights Reserved
\ No newline at end of file diff --git a/en/about/governance/index.html b/en/about/governance/index.html index 147ad5148..8df0d665b 100644 --- a/en/about/governance/index.html +++ b/en/about/governance/index.html @@ -1,5 +1,5 @@ Governance | OSRD -

Governance

Governance and organization of OSRD

One of the ambitions of OSRD is to help with timetabling on a European scale.

To reach this goal, OSRD has to take local features into account by consulting and collaborating with railway companies and infrastructure operators.

And by contributing to OSRD, these companies:

  • Profit from all the common development efforts
  • Can freely build on the common effort to achieve their own goals1
  • Participate in the roadmap and technical direction of the project to the extent of their contribution

OSRD is currently developed by:

The OpenRail association

The OpenRail association is an upcoming non-profit committed to organizing cooperative work around railway software tools.

OpenRail association

  1. As long as they don’t modify the common tools without sharing their improvements. See the details of the LGPLv3 license. ↩︎

© 2025 OSRD contributors. All Rights Reserved
\ No newline at end of file diff --git a/en/about/index.html b/en/about/index.html index a143963b0..df6ac8346 100644 --- a/en/about/index.html +++ b/en/about/index.html @@ -1,5 +1,5 @@ About | OSRD -

About

OSRD is a railway toolbox designed for multiple use cases. These tools have in common a reliance on railway infrastructure simulation and results analysis.

Governance

Governance and organization of OSRD

Use cases

Use cases related to rail transport planning

Open Source

OSRD and Open Source

Open Data

OSRD and Open Data

Roadmap

Macroscopic Roadmap

© 2025 OSRD contributors. All Rights Reserved
\ No newline at end of file diff --git a/en/about/opendata/index.html b/en/about/opendata/index.html index 945e42f87..6fcfda155 100644 --- a/en/about/opendata/index.html +++ b/en/about/opendata/index.html @@ -1,5 +1,5 @@ Open Data | OSRD -
© 2025 OSRD contributors. All Rights Reserved
\ No newline at end of file diff --git a/en/about/opensource/index.html b/en/about/opensource/index.html index 14e862a0d..5d9feec9e 100644 --- a/en/about/opensource/index.html +++ b/en/about/opensource/index.html @@ -1,5 +1,5 @@ Open Source | OSRD -
© 2025 OSRD contributors. All Rights Reserved
\ No newline at end of file diff --git a/en/about/roadmap/index.html b/en/about/roadmap/index.html index 0452a06af..012aa22e0 100644 --- a/en/about/roadmap/index.html +++ b/en/about/roadmap/index.html @@ -1,5 +1,5 @@ Roadmap | OSRD -
© 2025 OSRD contributors. All Rights Reserved
\ No newline at end of file diff --git a/en/about/use-case/_print/index.html b/en/about/use-case/_print/index.html index 563f6b00e..e08283954 100644 --- a/en/about/use-case/_print/index.html +++ b/en/about/use-case/_print/index.html @@ -1,5 +1,5 @@ Use cases | OSRD -

This is the multi-page printable view of this section. +

This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Use cases

Use cases related to rail transport planning

    OSRD presentation

    OSRD is meant to fulfill a range of use-cases related to railway planning:

    produits OSRD

    Timetabling

    Timetabling is about designing a transport service in order to meet the transit needs.

    OSRD addresses this by providing:

    • a track level railway infrastructure database
    • a rolling stock database
    • an infrastructure edition tool
    • a timetabling tool
    • train path allowances, including an allowance distribution which minimizes energy use

    Planned features include:

    • automated conflict detection1
    • line level infrastructure synthesis from track level infrastructure
    • interactive timetable diagrams
    • a throughput and rolling stock turnover optimizer

    Operation studies

    Operation studies assess the ability of infrastructures to meet demand, and balance infrastructure capacity with transportation needs. @@ -15,4 +15,4 @@ It is a free and documented format, designed to be infrastructure manager-agnostic, easy to generate and use. ↩︎

  • A train paths is a right of way on the rail network, bounded in time and space. Train paths are sold by infrastructure -managers to railway companies. ↩︎

    © 2024 OSRD contributors. All Rights Reserved
    \ No newline at end of file +managers to railway companies. ↩︎

    \ No newline at end of file diff --git a/en/about/use-case/index.html b/en/about/use-case/index.html index da9f15194..9d1e5c322 100644 --- a/en/about/use-case/index.html +++ b/en/about/use-case/index.html @@ -1,5 +1,5 @@ Use cases | OSRD -
    \ No newline at end of file diff --git a/en/blog/2023/02/03/openstreetmap-and-open-data-talk-at-fosdem-2023/index.html b/en/blog/2023/02/03/openstreetmap-and-open-data-talk-at-fosdem-2023/index.html index 3b05932f6..04a599e93 100644 --- a/en/blog/2023/02/03/openstreetmap-and-open-data-talk-at-fosdem-2023/index.html +++ b/en/blog/2023/02/03/openstreetmap-and-open-data-talk-at-fosdem-2023/index.html @@ -3,7 +3,7 @@ I have presented the main results of this study during a talk at the FOSDEM 2023 meeting, and you can see the replay on their website.">
    © 2025 OSRD contributors. All Rights Reserved
    \ No newline at end of file diff --git a/en/blog/2023/04/12/dgex-solutions-forum/index.html b/en/blog/2023/04/12/dgex-solutions-forum/index.html index f2040beec..d16929632 100644 --- a/en/blog/2023/04/12/dgex-solutions-forum/index.html +++ b/en/blog/2023/04/12/dgex-solutions-forum/index.html @@ -3,7 +3,7 @@ First of all, what is a train path? It’s the reservation of space/time on the network, by railway undertakings (RU) such as SNCF Voyageurs. These reservations are generally made years in advance (A-3). RUs can also make emergency requests for train paths (called last-minute paths), from A-1 to D-day.">
    © 2025 OSRD contributors. All Rights Reserved
    \ No newline at end of file diff --git "a/en/blog/2023/07/19/osrd-at-dreil\303\244nder-hack-in-wien/index.html" "b/en/blog/2023/07/19/osrd-at-dreil\303\244nder-hack-in-wien/index.html" index b43875844..7065ba9e2 100644 --- "a/en/blog/2023/07/19/osrd-at-dreil\303\244nder-hack-in-wien/index.html" +++ "b/en/blog/2023/07/19/osrd-at-dreil\303\244nder-hack-in-wien/index.html" @@ -3,7 +3,7 @@ We were delighted to be invited to take part thanks to the OpenRail association, and this year’s theme being “Open Railways”, it would have been hard to refuse!">

    OSRD at Dreiländer Hack in Wien

    Dreiländer hack, the annual meeting of German-speaking railway companies… but not only!

    On 29 and 30 June, the “Dreiländer hack” (the hackathon of the three countries) was held in Wien (Austria). Organised by DB (Germany), ÖBB (Austria) and SBB (Switzerland), this is an annual event dedicated to collaboration on shared railway-related challenges.

    We were delighted to be invited to take part thanks to the OpenRail association, and this year’s theme being “Open Railways”, it would have been hard to refuse!

    24 hours to work together on a topic of common interest

    The 150 participants were divided into 16 working groups on a wide variety of topics such as:

    • Imagining a simple interface for ordering train paths (an important subject for the future of OSRD);
    • Offering passenger information adapted to different disabilities;
    • Optimizing the prioritisation of trains at junctions according to the number of passengers on board and on the platform (Motis project);
    • Automatically identifying energy-consuming trains in storage;
    • Calculating forecast maintenance dates from a historical database for each train component;
    • Detecting speed measurement and GPS positioning errors on track inspection trains;
    • Optimizing maintenance work to limit lost capacity;
    • Facilitating passenger information with a GPT chatbot;
    • Designing an easy-to-use display and ticketing interface for night trains across Europe.

    Challenge proposal by OSRD

    The challenge proposed by OSRD was to consolidate the railway data in OpenStreetMap, an open & collaborative database that we use as a source for railway infrastructure in Europe.

    The objective was to develop an algorithm to identify 5 types of probable errors in the data:

    Disconnected tracks

    A toy train with wooden tracks separated by a space

    Suspicious switches

    A toy train where an extra wooden track has been added to a switch

    Stations apart from tracks

    A toy train on wooden tracks and a station drawn on a post-it note. A question mark is drawn between the two.

    Weird angles

    A toy train with wooden tracks at a 60° angle

    Missing gauge info

    A wooden toy train. A measuring ruler is placed on the tracks, with a post-it note with a question mark.

    The subject was of interest and we formed a team of 10 people divided between the four participating companies. After a presentation of the challenge and of the OpenStreetMap data model, we looked for existing tools and chose to use Osmose, an open source application for detecting and displaying potential errors in OSM. We then split up to work on the 5 types of errors.

    The 10 members of the team pose in front of a decorated container wall reading “Es ist möglich”.

    From left to right: Christoph (DB), Klara (ÖBB), Frederik (SBB), Carl (SBB), Julius (DB), Jennifer (DB), Daniel (ÖBB), Céline (SNCF), Max (DB), Tristram (SNCF).

    Results

    After 24 hours of work, the result is an interactive map showing the various errors (click on the pictograms to show error details). You can find all the code that was produced on the OpenRail association’s GitHub.

    We did not manage to integrate our analysers into Osmose within the allotted time, but that remains the target on which we’re going to continue working, so that all OpenStreetMap contributors can easily correct errors in railway data!

    © 2025 OSRD contributors. All Rights Reserved
    \ No newline at end of file diff --git a/en/blog/_print/index.html b/en/blog/_print/index.html index 8de0e5076..6d4384f70 100644 --- a/en/blog/_print/index.html +++ b/en/blog/_print/index.html @@ -1,5 +1,5 @@ OSRD Blog | OSRD -

    This is the multi-page printable view of this section. +

    This is the multi-page printable view of this section. Click here to print.

    Return to the regular view of this page.

    OSRD Blog

    News

    OSRD at Dreiländer Hack in Wien

    Dreiländer hack, the annual meeting of German-speaking railway companies… but not only!

    On 29 and 30 June, the “Dreiländer hack” (the hackathon of the three countries) was held in Wien (Austria). Organised by DB (Germany), ÖBB (Austria) and SBB (Switzerland), this is an annual event dedicated to collaboration on shared railway-related challenges.

    We were delighted to be invited to take part thanks to the OpenRail association, and this year’s theme being “Open Railways”, it would have been hard to refuse!

    24 hours to work together on a topic of common interest

    The 150 participants were divided into 16 working groups on a wide variety of topics such as:

    • Imagining a simple interface for ordering train paths (an important subject for the future of OSRD);
    • Offering passenger information adapted to different disabilities;
    • Optimizing the prioritisation of trains at junctions according to the number of passengers on board and on the platform (Motis project);
    • Automatically identifying energy-consuming trains in storage;
    • Calculating forecast maintenance dates from a historical database for each train component;
    • Detecting speed measurement and GPS positioning errors on track inspection trains;
    • Optimizing maintenance work to limit lost capacity;
    • Facilitating passenger information with a GPT chatbot;
    • Designing an easy-to-use display and ticketing interface for night trains across Europe.

    Challenge proposal by OSRD

    The challenge proposed by OSRD was to consolidate the railway data in OpenStreetMap, an open & collaborative database that we use as a source for railway infrastructure in Europe.

    The objective was to develop an algorithm to identify 5 types of probable errors in the data:

    Disconnected tracks

    A toy train with wooden tracks separated by a space

    Suspicious switches

    A toy train where an extra wooden track has been added to a switch

    Stations apart from tracks

    A toy train on wooden tracks and a station drawn on a post-it note. A question mark is drawn between the two.

    Weird angles

    A toy train with wooden tracks at a 60° angle

    Missing gauge info

    A wooden toy train. A measuring ruler is placed on the tracks, with a post-it note with a question mark.

    The subject was of interest and we formed a team of 10 people divided between the four participating companies. After a presentation of the challenge and of the OpenStreetMap data model, we looked for existing tools and chose to use Osmose, an open source application for detecting and displaying potential errors in OSM. We then split up to work on the 5 types of errors.

    The 10 members of the team pose in front of a decorated container wall reading “Es ist möglich”.

    From left to right: Christoph (DB), Klara (ÖBB), Frederik (SBB), Carl (SBB), Julius (DB), Jennifer (DB), Daniel (ÖBB), Céline (SNCF), Max (DB), Tristram (SNCF).

    Results

    After 24 hours of work, the result is an interactive map showing the various errors (click on the pictograms to show error details). You can find all the code that was produced on the OpenRail association’s GitHub.

    We did not manage to integrate our analysers into Osmose within the allotted time, but that remains the target on which we’re going to continue working, so that all OpenStreetMap contributors can easily correct errors in railway data!

    DGEX Solutions Forum

    DGEX Solutions Forum

    Here’s an extract from Loïc Hamelin’s talk at the DGEX Solutions forum, on the subject of search for last-minute train slots (STDCM).

    First of all, what is a train path?

    It’s the reservation of space/time on the network, by railway undertakings (RU) such as SNCF Voyageurs. These reservations are generally made years in advance (A-3). RUs can also make emergency requests for train paths (called last-minute paths), from A-1 to D-day. These requests are currently managed by ticket offices, and the paths are traced by hand. There is therefore a risk of human error, and requests are sometimes processed over several days.

    What do we offer?

    The OSRD software, in addition to featuring a rail simulator for timetable planning, will also enable last-minute path requests to be processed automatically! With just a few clicks, you’ll be able to submit a last-minute path request and get a response in a matter of seconds (3 minutes at most)!

    If you’re interested in the #osrd project, please visit the osrd website and the GitHub repo, and the project is #opensource.

    Morgane Senejko’s LinkedIn post

    imagepostlinkedin

    OpenStreetMap and open data talk at Fosdem 2023

    Hi ! My name is Céline, and I am on a mission to bring more open data into OSRD. To do so, I searched open data that can fit OSRD’s needs in every country of the European Union (+ Norway, United Kingdom and Switzerland).

    I have presented the main results of this study during a talk at the FOSDEM 2023 meeting, and you can see the replay on their website.

    In this post I will go into details of the methodology I followed, feel free to contact me if you have any remarks or question :-)

    Data download

    You can download the detailed data I created here. Update 11/03/23 : get the updated file here.

    • Added open data sources links for : Estonia, Czechia, Poland, Slovakia
    • Added license detail pour : Sweden
    • Added information on real-time position of trains for : Finland @@ -11,4 +11,4 @@

    • Select electrified parts of the network using the “other_tages” field:

        "other_tags" like '%"electrified"=>"yes"%'
   or "other_tags" like '%"electrified"=>"contact_line"%'
   or "other_tags" like '%"electrified"=>"rail"%'
-

    • Report total length using the Basic Statistics for Fields tool

    Learn more about OpenStreetMap data model

    Calculate usability indicator

    • List required and optional data
    • For each data, indicate its availability using QGIS (Overpass Turbo can also be helpful to check OSM data) and the following scale :
      • “Yes”: fully available
      • “Partial”: not available everywhere on the country, or missing parts of the data
      • “No”: not available
    • Sum total required and optional data with Yes = 1; Partial = 0.5; No = 0
    • Generate indicator:
      • “Good” if required=2 and optional>2
      • “Okay” if required >1 and optional >=0
      • “Poor” if required=1 and optional >2
      • “Not usable” else

    Map the result

    To show the indicator and license compatibility on a map, use the Eurostat borders datasets (for my presentation, I have used the 1:20 million scale and EPSG:3035) and join the table using countries names.

    © 2024 OSRD contributors. All Rights Reserved
    \ No newline at end of file +

  • Report total length using the Basic Statistics for Fields tool

    • Learn more about OpenStreetMap data model

    Calculate usability indicator

    • List required and optional data
    • For each data, indicate its availability using QGIS (Overpass Turbo can also be helpful to check OSM data) and the following scale :
      • “Yes”: fully available
      • “Partial”: not available everywhere on the country, or missing parts of the data
      • “No”: not available
    • Sum total required and optional data with Yes = 1; Partial = 0.5; No = 0
    • Generate indicator:
      • “Good” if required=2 and optional>2
      • “Okay” if required >1 and optional >=0
      • “Poor” if required=1 and optional >2
      • “Not usable” else

    Map the result

    To show the indicator and license compatibility on a map, use the Eurostat borders datasets (for my presentation, I have used the 1:20 million scale and EPSG:3035) and join the table using countries names.

    © 2025 OSRD contributors. All Rights Reserved
    \ No newline at end of file diff --git a/en/blog/index.html b/en/blog/index.html index 4e674c2fd..31b68ed86 100644 --- a/en/blog/index.html +++ b/en/blog/index.html @@ -1,5 +1,5 @@ OSRD Blog | OSRD -
    \ No newline at end of file diff --git a/en/blog/news/_print/index.html b/en/blog/news/_print/index.html index 7364a3516..52478de5f 100644 --- a/en/blog/news/_print/index.html +++ b/en/blog/news/_print/index.html @@ -1,5 +1,5 @@ News | OSRD -

    This is the multi-page printable view of this section. +

    This is the multi-page printable view of this section. Click here to print.

    Return to the regular view of this page.

    News

    OSRD at Dreiländer Hack in Wien

    Dreiländer hack, the annual meeting of German-speaking railway companies… but not only!

    On 29 and 30 June, the “Dreiländer hack” (the hackathon of the three countries) was held in Wien (Austria). Organised by DB (Germany), ÖBB (Austria) and SBB (Switzerland), this is an annual event dedicated to collaboration on shared railway-related challenges.

    We were delighted to be invited to take part thanks to the OpenRail association, and this year’s theme being “Open Railways”, it would have been hard to refuse!

    24 hours to work together on a topic of common interest

    The 150 participants were divided into 16 working groups on a wide variety of topics such as:

    • Imagining a simple interface for ordering train paths (an important subject for the future of OSRD);
    • Offering passenger information adapted to different disabilities;
    • Optimizing the prioritisation of trains at junctions according to the number of passengers on board and on the platform (Motis project);
    • Automatically identifying energy-consuming trains in storage;
    • Calculating forecast maintenance dates from a historical database for each train component;
    • Detecting speed measurement and GPS positioning errors on track inspection trains;
    • Optimizing maintenance work to limit lost capacity;
    • Facilitating passenger information with a GPT chatbot;
    • Designing an easy-to-use display and ticketing interface for night trains across Europe.

    Challenge proposal by OSRD

    The challenge proposed by OSRD was to consolidate the railway data in OpenStreetMap, an open & collaborative database that we use as a source for railway infrastructure in Europe.

    The objective was to develop an algorithm to identify 5 types of probable errors in the data:

    Disconnected tracks

    A toy train with wooden tracks separated by a space

    Suspicious switches

    A toy train where an extra wooden track has been added to a switch

    Stations apart from tracks

    A toy train on wooden tracks and a station drawn on a post-it note. A question mark is drawn between the two.

    Weird angles

    A toy train with wooden tracks at a 60° angle

    Missing gauge info

    A wooden toy train. A measuring ruler is placed on the tracks, with a post-it note with a question mark.

    The subject was of interest and we formed a team of 10 people divided between the four participating companies. After a presentation of the challenge and of the OpenStreetMap data model, we looked for existing tools and chose to use Osmose, an open source application for detecting and displaying potential errors in OSM. We then split up to work on the 5 types of errors.

    The 10 members of the team pose in front of a decorated container wall reading “Es ist möglich”.

    From left to right: Christoph (DB), Klara (ÖBB), Frederik (SBB), Carl (SBB), Julius (DB), Jennifer (DB), Daniel (ÖBB), Céline (SNCF), Max (DB), Tristram (SNCF).

    Results

    After 24 hours of work, the result is an interactive map showing the various errors (click on the pictograms to show error details). You can find all the code that was produced on the OpenRail association’s GitHub.

    We did not manage to integrate our analysers into Osmose within the allotted time, but that remains the target on which we’re going to continue working, so that all OpenStreetMap contributors can easily correct errors in railway data!

    DGEX Solutions Forum

    DGEX Solutions Forum

    Here’s an extract from Loïc Hamelin’s talk at the DGEX Solutions forum, on the subject of search for last-minute train slots (STDCM).

    First of all, what is a train path?

    It’s the reservation of space/time on the network, by railway undertakings (RU) such as SNCF Voyageurs. These reservations are generally made years in advance (A-3). RUs can also make emergency requests for train paths (called last-minute paths), from A-1 to D-day. These requests are currently managed by ticket offices, and the paths are traced by hand. There is therefore a risk of human error, and requests are sometimes processed over several days.

    What do we offer?

    The OSRD software, in addition to featuring a rail simulator for timetable planning, will also enable last-minute path requests to be processed automatically! With just a few clicks, you’ll be able to submit a last-minute path request and get a response in a matter of seconds (3 minutes at most)!

    If you’re interested in the #osrd project, please visit the osrd website and the GitHub repo, and the project is #opensource.

    Morgane Senejko’s LinkedIn post

    imagepostlinkedin

    OpenStreetMap and open data talk at Fosdem 2023

    Hi ! My name is Céline, and I am on a mission to bring more open data into OSRD. To do so, I searched open data that can fit OSRD’s needs in every country of the European Union (+ Norway, United Kingdom and Switzerland).

    I have presented the main results of this study during a talk at the FOSDEM 2023 meeting, and you can see the replay on their website.

    In this post I will go into details of the methodology I followed, feel free to contact me if you have any remarks or question :-)

    Data download

    You can download the detailed data I created here. Update 11/03/23 : get the updated file here.

    • Added open data sources links for : Estonia, Czechia, Poland, Slovakia
    • Added license detail pour : Sweden
    • Added information on real-time position of trains for : Finland @@ -11,4 +11,4 @@

    • Select electrified parts of the network using the “other_tages” field:

        "other_tags" like '%"electrified"=>"yes"%'
   or "other_tags" like '%"electrified"=>"contact_line"%'
   or "other_tags" like '%"electrified"=>"rail"%'
-

    • Report total length using the Basic Statistics for Fields tool

    Learn more about OpenStreetMap data model

    Calculate usability indicator

    • List required and optional data
    • For each data, indicate its availability using QGIS (Overpass Turbo can also be helpful to check OSM data) and the following scale :
      • “Yes”: fully available
      • “Partial”: not available everywhere on the country, or missing parts of the data
      • “No”: not available
    • Sum total required and optional data with Yes = 1; Partial = 0.5; No = 0
    • Generate indicator:
      • “Good” if required=2 and optional>2
      • “Okay” if required >1 and optional >=0
      • “Poor” if required=1 and optional >2
      • “Not usable” else

    Map the result

    To show the indicator and license compatibility on a map, use the Eurostat borders datasets (for my presentation, I have used the 1:20 million scale and EPSG:3035) and join the table using countries names.

    © 2024 OSRD contributors. All Rights Reserved
    \ No newline at end of file +

  • Report total length using the Basic Statistics for Fields tool

    • Learn more about OpenStreetMap data model

    Calculate usability indicator

    • List required and optional data
    • For each data, indicate its availability using QGIS (Overpass Turbo can also be helpful to check OSM data) and the following scale :
      • “Yes”: fully available
      • “Partial”: not available everywhere on the country, or missing parts of the data
      • “No”: not available
    • Sum total required and optional data with Yes = 1; Partial = 0.5; No = 0
    • Generate indicator:
      • “Good” if required=2 and optional>2
      • “Okay” if required >1 and optional >=0
      • “Poor” if required=1 and optional >2
      • “Not usable” else

    Map the result

    To show the indicator and license compatibility on a map, use the Eurostat borders datasets (for my presentation, I have used the 1:20 million scale and EPSG:3035) and join the table using countries names.

    © 2025 OSRD contributors. All Rights Reserved
    \ No newline at end of file diff --git a/en/blog/news/index.html b/en/blog/news/index.html index 03f4f0f44..455561f8f 100644 --- a/en/blog/news/index.html +++ b/en/blog/news/index.html @@ -1,5 +1,5 @@ News | OSRD -
    \ No newline at end of file diff --git a/en/categories/index.html b/en/categories/index.html index 7c4a905fe..d8f067921 100644 --- a/en/categories/index.html +++ b/en/categories/index.html @@ -1,2 +1,2 @@ Categories | OSRD -

    Categories

    © 2024 OSRD contributors. All Rights Reserved
    \ No newline at end of file +

    Categories

    © 2025 OSRD contributors. All Rights Reserved
    \ No newline at end of file diff --git a/en/docs/_print/index.html b/en/docs/_print/index.html index b36b70a41..d84fec5ef 100644 --- a/en/docs/_print/index.html +++ b/en/docs/_print/index.html @@ -1,6 +1,6 @@ Documentation | OSRD -

    This is the multi-page printable view of this section. -Click here to print.

    Return to the regular view of this page.

    Documentation

    Whether you would like to use OSRD, understand it or contribute, this is the right place!

    1 - Explanations

    Learn more about key concepts

    Explanations discuss key topics and concepts at a fairly high level and provide useful background information and explanation.

    1.1 - Containers architecture

    How the containers works together and how they are built

    There are 3 main containers deployed in a standard OSRD setup:

    • Gateway (includes the frontend): Serves the front end, handles authentication and proxies requests to the backend.
    • Editoast: Acts as the backend that interacts with the front end.
    • Core: Handles computation and business logic, called by Editoast.

    Standard deployment

    The standard deployment can be represented with the following diagram.

    flowchart TD
+
    This is the multi-page printable view of this section.
+Click here to print.
    Return to the regular view of this page.
    Documentation
    Whether you would like to use OSRD, understand it or contribute, this is the right place!
    1 - Explanations
    Learn more about key concepts
    Explanations discuss key topics and concepts at a fairly high level and provide useful background information and explanation.
    1.1 - Containers architecture
    How the containers works together and how they are built
    There are 3 main containers deployed in a standard OSRD setup:
    • Gateway (includes the frontend): Serves the front end, handles authentication and proxies requests to the backend.
    • Editoast: Acts as the backend that interacts with the front end.
    • Core: Handles computation and business logic, called by Editoast.
    Standard deployment
    The standard deployment can be represented with the following diagram.
    flowchart TD
     gw["gateway"]
     front["front-end static files"]
     gw -- local file --> front
@@ -318,7 +318,23 @@
 
    Use of logo only (without text)
    Colors
    These colours are those of the logo and should not be confused with those of the overall design of the OSRD interface.
    #786ABF
-#C7B2DE
    2.4 - OSRD's design
    Colours, fonts, uses…
    Everything is presented on a dedicated website https://design.osrd.fr
    A “design system” is being developed.
    2.5 - Release
    How to make a release
    All OSRD releases are accessible here
    The process for creating a new release is as follows:
    1. We always release on a tested version of the application (staging branch)
      • git switch staging && git pull
    2. Create a git annotated tag
      • We are using the semantic versioning
      • git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version)
      • git push --tags
    3. Create a github release
      • Draft a new github release here
      • Select the created tag
      • Generate the releases notes
      • Rename the release like so: “Version x.y.z”
      • Check the “Set as a pre-release” box
      • Apply the changelog format
      • Then you can publish the release or save the draft if you want to come back later
    4. A github action should be triggered automatically.
    5. Post the link of the created release on matrix. Suggest that the developers review the release.
    Changelog format
    1. Use the following structure:
    ## What's Changed
+#C7B2DE
    2.4 - OSRD's design
    Colours, fonts, uses…
    Everything is presented on a dedicated website https://design.osrd.fr
    A “design system” is being developed.
    2.5 - Release
    Release section
    This section documents the process around creating a release of OSRD.
    2.5.1 - Release process
    Here’s how OSRD is currently released
    OSRD has three versions: development (dev), staging, and release.
    The development version is the most recent and unstable version of the application, containing the latest features and bug fixes in active development.
    Staging versions are created every Thursday at 12pm by tagging the current development state.
    If a staging version passes validation testing, it is promoted to become the latest release version. This ensures that only stable, tested code makes it into production releases.
    The release process follows this workflow:
    1. Ongoing development in the dev branch
    2. Weekly staging tags on Thursdays at 12pm
    3. Validation testing of staging version
    4. Promotion of validated staging builds to release status
        Development         Staging                   Release
+    (unstable)         (testing)                 (stable)
+
+    [Dev Branch]                                    |
+         |                                          |
+         |--->     Thursday 12pm                    |
+         |         [Staging Tag]                    |
+         |                |                         |
+         |            Validation                    |
+         |             Testing                      |
+         |                |                         |
+         |                o---> If Passes -->  [New Release]
+         |                       Tests              |
+    [Continue Dev]                                  |
+         |                                          |
+         V                                          V
+
    2.5.2 - Publish a new release
    How to publish a new release
    All OSRD releases are accessible here
    The process for creating a new release is as follows:
    1. We always release on a tested version of the application (staging branch)
      • git switch staging && git pull
    2. Create a git annotated tag
      • We are using the semantic versioning
      • git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version)
      • git push --tags
    3. Create a github release
      • Draft a new github release here
      • Select the created tag
      • Generate the releases notes
      • Rename the release like so: “Version x.y.z”
      • Check the “Set as a pre-release” box
      • Apply the changelog format
      • Then you can publish the release or save the draft if you want to come back later
    4. A github action should be triggered automatically.
    5. Post the link of the created release on matrix. Suggest that the developers review the release.
    Changelog format
    1. Use the following structure:
    ## What's Changed
 
 ### Features :tada:
 
@@ -473,18 +489,18 @@
 
     "track_ranges": [{"track": "${TRACK_SECTION}", "begin": 0, "end": 42, "applicable_directions": "START_TO_STOP"}],
 }
-
    Design considerations
    Where to put the speed limit value
    When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:
    • once in the signal itself
    • once in the speed limit
    There are multiple ways this issue can be dealt with:
    ✅
-Mandatory speed limit value in the speed section
    Upsides:
    • simpler to implement, works even without train reactions to signals nor additional API
    Downsides:
    • more work on the side of users
    • room for inconsistencies between the speed limit announced by signaling, and the effective speed limit
    ❌
+

    Design considerations

    Where to put the speed limit value

    When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:

    • once in the signal itself
    • once in the speed limit

    There are multiple ways this issue can be dealt with:

    ✅ +Mandatory speed limit value in the speed section

    Upsides:

    • simpler to implement, works even without train reactions to signals nor additional API

    Downsides:

    • more work on the side of users
    • room for inconsistencies between the speed limit announced by signaling, and the effective speed limit

    ❌ Deduce the signal constraint from the speed limit

    This option was not explored much, as it was deemed awkward -to deduce signal parameters from a speed limit value.

    ❌ +to deduce signal parameters from a speed limit value.

    ❌ Deduce the speed limit from the signal

    Make the speed limit value optional, and deduce it from the signal itself. Speed limits per tag also have to be deduced if missing.

    Upsides:

    • less work for users
    • lessens the likelyhood of configuration mismatches

    Downsides:

    • not all signaling systems work well with this. It may be difficult to deduce the announced speed limit from a signal configuration, such as with TVM.
    • speed limits have to be deduced, which increases implementation complexity

    Speed limit announced by dynamic signaling often start being enforced at a specific location, which is distinct from the signal which announces the speed limit.

    To allow for correct train reactions to this kind of limits, a link between the announce signal -and the speed limit section has to be made at some point.

    ❌ -Automated matching of signals and speed sections

    Was not deemed realistic.

    ❌ +Automated matching of signals and speed sections

    Was not deemed realistic.

    Was deemed to be awkward, as signaling is currently built over interlocking. -Referencing signaling from interlocking creates a circular dependency between the two schemas.

    Add a list of (route, signal) tuples to speed sections.

    Upside:

    • a link with the signal can be made with creating the speed section

    Downside:

    • Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.
    • Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.

    ❌ +Referencing signaling from interlocking creates a circular dependency between the two schemas.

    Add a list of (route, signal) tuples to speed sections.

    Upside:

    • a link with the signal can be made with creating the speed section

    Downside:

    • Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.
    • Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.

    ❌ Inlining speed limit definitions into signals

    Introduces a new type of speed limit, which are announced by signals. These speed limits are directly defined within signal definitions.

    {
     # ...
@@ -501,7 +517,7 @@
     ]
     # ...
 }
-

    Upsides:

    • straightforward infrastructure edition experience for speed sections announced by a single signal

    Downsides:

    • creates two separate kinds of speed limits:
      • can cause code duplication
      • could make later changes of the data model trickier
      • it’s unclear whether the criterion used to make this partition is appropriate
    • speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)
    • the cost of reversing this decision could be fairly high

    Upsides:

    • straightforward infrastructure edition experience for speed sections announced by a single signal

    Downsides:

    • creates two separate kinds of speed limits:
      • can cause code duplication
      • could make later changes of the data model trickier
      • it’s unclear whether the criterion used to make this partition is appropriate
    • speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)
    • the cost of reversing this decision could be fairly high
    {
     # ...
     "conditional_parameters": [
@@ -732,13 +748,13 @@
     LT, LE, EQ, GE, GT
 }

    Design decisions

    Lowering constraints to an intermediate representation

    Early on, we started making lists of what domain constraints can have an impact on train behavior. -Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.

    There’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:

    • either treat each type of constraint as its own thing during the simulation
    • abstract away constraints into a common representation, and then simulate that

    ❌ +Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.

    There’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:

    • either treat each type of constraint as its own thing during the simulation
    • abstract away constraints into a common representation, and then simulate that

    ❌ Distinct constraint types

    When we first started drafting architecture diagrams, the train simulation API directly took -a bunch of constraint types as an input. It brought up a number of issues:

    • the high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types
    • the domain of some of these interactions is very complex (block signaling)
    • when simulating, it does not seem to matter why a constraint is there, only what to do about it

    We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.

    ❌ +a bunch of constraint types as an input. It brought up a number of issues:

    • the high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types
    • the domain of some of these interactions is very complex (block signaling)
    • when simulating, it does not seem to matter why a constraint is there, only what to do about it

    We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.

    ❌ Internal constraint types abstraction

    We then realized that abstracting over constraint types during simulation had immense benefits:

    • it allows expressing requirements on what constraints need to be enforceable
    • it greatly simplifies the process of validating constraint semantics: instead of having to validate interactions between every possible type of constraints, we only have to validate that the semantics of each constraint type can be transferred to the abstract constraint type

    We decided to explore the possibility of keeping constraint types distinct in the external API, -but lowering these constraints into an intermediary representation internally. We found a number of downsides:

    • the public simulation API would still bear the complexity of dealing with many constraint types
    • there would be a need to incrementally generate internal abstracted constraints to support the incremental API

    ✅ +but lowering these constraints into an intermediary representation internally. We found a number of downsides:

    • the public simulation API would still bear the complexity of dealing with many constraint types
    • there would be a need to incrementally generate internal abstracted constraints to support the incremental API

    ✅ External constraint types abstraction

    We tried to improve over the previous proposal by moving the burden of converting many constraints into a common abstraction out of the simulation API.

    Instead of having many constraint types as an input, the simulation API takes a collection of a single abstract constraint type. The task of converting domain constraints to abstract driving instructions is left to the API user.

    We found that doing so:

    • reduces the API surface of the train simulation module
    • decouples behavior from constraint types: if a new constraint type needs to be added, the simulation API only needs expansion if the expected behavior expected for this constraint isn’t part of the API.

    Interpreting driving instructions

    As the train progresses through the simulation, it reacts according to driving instructions @@ -780,9 +796,9 @@ RK4. Such estimator then needs to call f multiple times.

    A number of questions came up:

    • should numerical integration within the driver behavior module, or outside
    • are driver behavior modules queried about their reaction to a specific instruction, or in general
    • does the driver behavior module return decisions, or parameters used to make decisions (such as curves)
    • if decisions are returned, is it a force, an acceleration, or a new state
    • if a new state is returned, how to deal with heterogenous time steps
    • do we check decisions for correctness? that is, if a decision causes the train to overshoot a limit curve, do we do anything?

    Do we have a single DBM for all driving instructions, or one per driving instruction?

    We identified that this API choice shouldn’t constrain the implementation. We decided to go the conservative route and have one DBM per driving instructions as it reduces the API surface -and relieves DBM from the responsibility of finding the most restrictive instruction.

    How do we prevent overshooting?

    We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).

    To do so we could either:

    1. Have a way to short-circuit our integration scheme, to snap to target curves without overshooting.
    2. Accept oscillations around target curves (and thus overshooting).
    3. Setup a feedback loop mechanism to avoid overshooting.

    We decided that only the first option was desirable.

    The design choices then are:

    ❌ +and relieves DBM from the responsibility of finding the most restrictive instruction.

    How do we prevent overshooting?

    We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).

    To do so we could either:

    1. Have a way to short-circuit our integration scheme, to snap to target curves without overshooting.
    2. Accept oscillations around target curves (and thus overshooting).
    3. Setup a feedback loop mechanism to avoid overshooting.

    We decided that only the first option was desirable.

    The design choices then are:

    ❌ Make the DBM as close as possible to a decision function

    Then the DBM would not be aware of the time step it is called with, and would return an acceleration. Then the module should expose two methods:

    • One for taking decisions, akin to f.
      Called several times depending on the integration method.

    • One for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves -(for example MARECO which sets it’s own speed limits).
      Called on the integration step results from this DBM, and the other DBMs integration step results.

    ✅ +(for example MARECO which sets it’s own speed limits).
    Called on the integration step results from this DBM, and the other DBMs integration step results.

    ✅ The DBM returns a new state

    The module would then expose two methods:

    • One for taking decisions, which, given a train state and a desired/maximum time step, returns a new state (which does not overshoot) and a new current time.

    • One for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves (for example MARECO which sets it’s own speed limits).
      Called only on other DBMs integration step results.

    How do we combine the decisions from all DBMs?

    1. For each state property, find the most constraining value and dt.
    2. Find the smallest dt amongst constraining properties. Interpolate remaining properties to this dt, to build a provisional state.
    3. Submit this provisional state for truncation to all DBMs and take the truncation with the smallest dt.

    To understand how this algorithm is designed, we need to consider two example cases:

    • For steps 1 and 2: if a neutral zone and a breaking instruction overlap, both are most constraining to different state properties: the neutral zone affects pantograph state, and the breaking instruction affects speed. The final state has to be a combination of both.
    • For step 3: We need to truncate integration steps to avoid overshoots, and thus avoid the need for feedback loops. @@ -1951,4 +1967,4 @@ queue before it can proceed to forward the message.

      If queues were created and deleted asynchronously when these events are received, it would introduce a race condition:

      • the orphan processor creates the queue
      • the queue gets deleted because it expired at the same time
      • the orphan processor forwards the message, which gets lost

      We found multiple solutions for this issue:

      • process all asynchronous events in a single actor. This was not deemed viable because worker activity processing is work intensive, and orphan request processing is latency sensitive.
      • having a single actor create and delete queues (the request queues control loop) and making the orphan processor wait until the control loop creates the queue

      Unbind the queue and wait before stopping workers

      In a previous design, we tried to delete work queue in one go. It created a race condition issue on queue deletion, caused by the fact ordyne does not get direct notifications of when messages are received on a work queue:

      • we decide to stop the worker group
      • work is received on the queue, but we aren’t made aware as no worker is up
      • we try to delete the queue, but cannot do so without loosing messages

      We could think of two fixes for this issue:

      • implement a two stage shutdown, where no work can get to the queue for a while before workers are stopped
      • detect that the queue still has messages after workers have stopped, and start workers back up

      We decided to implement two stage worker group shutdown:

      • if no activity is register for UNBIND_DELAY, unbind the work queue
      • wait for a while to see if any worker picks up work from the queue and notifies osrdyne, which would rebind the queue
      • if no orphan nor worker activity is registered for STOP_DELAY, stop workers and delete the queue

      1. The control loop is designed to make the state of all worker groups converge at once. Retrying convergence for one worker group adds latency to convergence for all worker groups. ↩︎ ↩︎

    3.3 - APIs

    Programming interfaces specifications

    RailJSON is the format used to describe a railway infrastructure, it’s -described in its JSON schema.

    Below are a list of REST APIs implemented by OSRD.

    3.3.1 - Editoast

    3.3.2 - Gateway

    4 - Railway Wiki

    International railway wiki

    This wiki is meant to help software engineers have a deep understanding of railway systems.

    It can only happen if content is added as needed. If something is missing, contribute!

    4.1 - Glossary

    Glossary of OSRD and railway vocabulary

    Please open an issue if you’re missing a word

    \ No newline at end of file +described in its JSON schema.

    Below are a list of REST APIs implemented by OSRD.

    3.3.1 - Editoast

    3.3.2 - Gateway

    4 - Railway Wiki

    International railway wiki

    This wiki is meant to help software engineers have a deep understanding of railway systems.

    It can only happen if content is added as needed. If something is missing, contribute!

    4.1 - Glossary

    Glossary of OSRD and railway vocabulary

    Please open an issue if you’re missing a word

    \ No newline at end of file diff --git a/en/docs/explanation/_print/index.html b/en/docs/explanation/_print/index.html index 7c3af4e93..e0ecec2b2 100644 --- a/en/docs/explanation/_print/index.html +++ b/en/docs/explanation/_print/index.html @@ -1,5 +1,5 @@ Explanations | OSRD -

    This is the multi-page printable view of this section. +

    This is the multi-page printable view of this section. Click here to print.

    Return to the regular view of this page.

    Explanations

    Learn more about key concepts

    Explanations discuss key topics and concepts at a fairly high level and provide useful background information and explanation.

    1 - Containers architecture

    How the containers works together and how they are built

    There are 3 main containers deployed in a standard OSRD setup:

    • Gateway (includes the frontend): Serves the front end, handles authentication and proxies requests to the backend.
    • Editoast: Acts as the backend that interacts with the front end.
    • Core: Handles computation and business logic, called by Editoast.

    Standard deployment

    The standard deployment can be represented with the following diagram.

    flowchart TD
     gw["gateway"]
     front["front-end static files"]
@@ -75,4 +75,4 @@
   OSRD (front-end)->> OSRD (front-end): convert timetable into <br> nge_light_model
   OSRD (front-end)->>NGE (osrd-nge): iframe.contentWindow.postMessage(nge_light_model, "*")
   NGE (osrd-nge)->>NGE (osrd-nge): (eventListener) <br> onLoad triggered
-  NGE (osrd-nge)->>NGE (nge-app): (callback function) <br> onLoad(nge_light_model, ...)

    2 - Converters

    To overpass the semantic differences and make the data models fit, 2 converters have to be implemented:

    • [OSRD -> NGE] a converter that transforms an OSRD timetable into an NGE model
    • [OSRD <- NGE] an event handler, that transforms NGE action into OSRD database update on timetable

    3 - Open-source (cooperation / contribution)

    To make NGE compatible with OSRD, some changes have been requested (disable back-end, create hooks on events) and directly implemented in the official repository of NGE, with the agreement and help of NGE team.

    Contributions for one project to another, from both sides, are valuable and will be entertained in the future.

    This feature also shows that open-source cooperation is powerful and a huge gain of time in software development.

    © 2024 OSRD contributors. All Rights Reserved
    \ No newline at end of file + NGE (osrd-nge)->>NGE (nge-app): (callback function) <br> onLoad(nge_light_model, ...)

    2 - Converters

    To overpass the semantic differences and make the data models fit, 2 converters have to be implemented:

    • [OSRD -> NGE] a converter that transforms an OSRD timetable into an NGE model
    • [OSRD <- NGE] an event handler, that transforms NGE action into OSRD database update on timetable

    3 - Open-source (cooperation / contribution)

    To make NGE compatible with OSRD, some changes have been requested (disable back-end, create hooks on events) and directly implemented in the official repository of NGE, with the agreement and help of NGE team.

    Contributions for one project to another, from both sides, are valuable and will be entertained in the future.

    This feature also shows that open-source cooperation is powerful and a huge gain of time in software development.

    © 2025 OSRD contributors. All Rights Reserved
    \ No newline at end of file diff --git a/en/docs/explanation/containers-architecture/_print/index.html b/en/docs/explanation/containers-architecture/_print/index.html index 5bd22f5fb..702f9cf50 100644 --- a/en/docs/explanation/containers-architecture/_print/index.html +++ b/en/docs/explanation/containers-architecture/_print/index.html @@ -1,5 +1,5 @@ Containers architecture | OSRD -

    This is the multi-page printable view of this section. +

    This is the multi-page printable view of this section. Click here to print.

    Return to the regular view of this page.

    Containers architecture

    How the containers works together and how they are built

      There are 3 main containers deployed in a standard OSRD setup:

      • Gateway (includes the frontend): Serves the front end, handles authentication and proxies requests to the backend.
      • Editoast: Acts as the backend that interacts with the front end.
      • Core: Handles computation and business logic, called by Editoast.

      Standard deployment

      The standard deployment can be represented with the following diagram.

      flowchart TD
     gw["gateway"]
     front["front-end static files"]
@@ -7,4 +7,4 @@
     
     browser --> gw
     gw -- HTTP --> editoast
-    editoast -- HTTP --> core

      External requests are received by the gateway. If the path asked starts with /api it will be forwarded using HTTP to editoast, otherwise it will serve a file with the asked path. Editoast reach the core using HTTP if required.

      The gateway is not only a reverse proxy with the front-end bundle included, it also provides all the authentication mechanisms: using OIDC or tokens.

      © 2024 OSRD contributors. All Rights Reserved
      \ No newline at end of file + editoast -- HTTP --> core

      External requests are received by the gateway. If the path asked starts with /api it will be forwarded using HTTP to editoast, otherwise it will serve a file with the asked path. Editoast reach the core using HTTP if required.

      The gateway is not only a reverse proxy with the front-end bundle included, it also provides all the authentication mechanisms: using OIDC or tokens.

      © 2025 OSRD contributors. All Rights Reserved
      \ No newline at end of file diff --git a/en/docs/explanation/containers-architecture/index.html b/en/docs/explanation/containers-architecture/index.html index 7e523b585..a0920a78f 100644 --- a/en/docs/explanation/containers-architecture/index.html +++ b/en/docs/explanation/containers-architecture/index.html @@ -1,5 +1,5 @@ Containers architecture | OSRD -
      © 2025 OSRD contributors. All Rights Reserved
      \ No newline at end of file diff --git a/en/docs/explanation/index.html b/en/docs/explanation/index.html index 249008bbd..23ab9ab55 100644 --- a/en/docs/explanation/index.html +++ b/en/docs/explanation/index.html @@ -1,5 +1,5 @@ Explanations | OSRD -

      Explanations

      Learn more about key concepts

      Explanations discuss key topics and concepts at a fairly high level and provide useful background information and explanation.

      Containers architecture

      How the containers works together and how they are built

      Models

      What is modeled in OSRD, and how it is modeled

      Running time calculation

      Netzgrafik-Editor

      Open-source software developed by SBB CFF FFS and its integration in OSRD

      © 2025 OSRD contributors. All Rights Reserved
      \ No newline at end of file diff --git a/en/docs/explanation/models/_print/index.html b/en/docs/explanation/models/_print/index.html index 21f37d07f..ff53d5e0f 100644 --- a/en/docs/explanation/models/_print/index.html +++ b/en/docs/explanation/models/_print/index.html @@ -1,5 +1,5 @@ Models | OSRD -

      This is the multi-page printable view of this section. +

      This is the multi-page printable view of this section. Click here to print.

      Return to the regular view of this page.

      Models

      What is modeled in OSRD, and how it is modeled

      1 - Infrastructure example

      Explains using an example how infrastructure data is structured

      Introduction

      This page gives an example of how the data formats are used to describe an infrastructure in OSRD.

      For this purpose, let’s take as an example the following toy infrastructure:

      Toy infrastructure diagram

      This diagram is an overview of the infrastructure with lines and stations only.

      This infrastructure is not meant to be realistic, but rather meant to help illustrate OSRD’s data model. This example will be created step by step and explained along the way.

      The infrastructure generator

      In the OSRD repository is a python library designed to help generate infrastructures in a format understood by OSRD.

      The infrastructure discussed in this section can be generated thanks to small_infra.py file. To learn more about the generation scripts, you can check out the related README.

      Tracks

      Track sections

      The first objects we need to define are TrackSections. Most other objects are positioned relative to track sections.

      A track section is a section of rail (switches not included). One can chose to divide the tracks of their infrastructure in as many track sections as they like. Here we chose to use the longest track sections possible, which means that between two switches there is always a single track section.

      Track sections is what simulated trains roll onto. They are the abstract equivalent to physical rail sections. Track sections are bidirectional.

      In this example, we define two tracks for the line between the West and North-East stations. We also have overpassing tracks at the North and Mid-West stations for added realism. Finally, we have three separate tracks in the West station, since it’s a major hub in our imaginary infrastructure.

      Track sections diagram

      These attributes are required for the track section to be complete:

      • length: the length of the track section in meters.
      • geo: the coordinates in real life (geo is for geographic), in the GeoJSON format.
      • cosmetic attributes: line_name, track_name, track_number which are used to indicate the name and labels that were given to the tracks / lines in real life.

      For all track sections in our infrastructure, the geo attributes very much resemble the given diagram.

      For most track sections, their length is proportional to what can be seen in the diagram. To preserve readability, exceptions were made for TA6, TA7, TD0 and TD1 (which are 10km and 25km).

      Node

      A Node represents a node in the infrastructure. In an OSRD simulation, a train can only move from one section of track to another if they are linked by a node.

      Node Types

      NodeTypes have two mandatory attributes:

      • ports: A list of port names. A port is an endpoint connected to a track section.
      • groups: A mapping between group names and lists of branch (connection between 2 ports) that characterises the different possible positions of the node type

      At any time, all nodes have an active group, and may have an active branch, which always belongs to the active group. During a simulation, changing the active branch inside a group is instantaneous, but changing the active branch across groups (changing the active group) takes configurable time. This is because a node is a physical object, and changing active branch can involve moving parts of it. Groups are designed to represent the different positions that a node can have. Each group contains the branches that can be used in the associated node position.

      The duration needed to change group is stored inside the Node, since it can vary depending on the physical implementation of the node.

      Our examples currently use five node types. Node types are just like other objects, and can easily be added as needed using extended_switch_type.

      1) Link

      This one represents the link between two sections of track. It has two ports: A and B.

      Link diagram

      It is used in the OSRD model to create a link between two track sections. This is not a physical object.

      2) The Point Switch

      The ubiquitous Y switch, which can be thought of as either two tracks merging, or one track splitting.

      This node type has three ports: A, B1 and B2.

      Point switch diagram

      There are two groups, each with one connection in their list: A_B1, which connects A to B1, and A_B2 which connects A to B2.

      Thus, at any given moment (except when the switch moves from one group to another), a train can go from A to B1 or from A to B2 but never to both at the same time. A train cannot go from B1 to B2.

      A Point Switch only has two positions:

      • A to B1
      • A to B2

      point switch position diagram point switch position diagram

      3) The Crossing

      This is simply two tracks crossing each other.

      This type has four ports: A1, B1, A2 et B2.

      Cross Switch Diagram

      It has only one group containing two connections: A1 to B1 and A2 to B2. Indeed this kind of switch is passive: it has no moving parts. Despite having a single group, it is still used by the simulation to enforce route reservations.

      Here are the two different connections this switch type has:

      • A1 to B1
      • A2 to B2

      Cross Switch Diagram positions Cross Switch Diagram positions

      4) The Double slip switch

      This one is more like two point switches back to back. It has four ports: A1, A2, B1 and B2.

      Double cross switch diagram

      However, it has four groups, each with one connection. The four groups are represented in the following diagram:

      • A1 to B1
      • A1 to B2
      • A2 to B1
      • A2 to B2

      Diagram of double crossing switch positions Diagram of double crossing switch positions

      Diagram of double crossing switch positions Diagram of double crossing switch positions

      5) The Single slip switch

      This one looks more like a cross between a single needle and a crossover. It has four ports: A1, A2, B1 and B2.

      Single slip switch diagram

      Here are the three connections that can be made by this switch:

      • A1 to B1
      • A1 to B2
      • A2 to B2

      Diagram of the positions of the single crossing points Diagram of the positions of the single crossing points @@ -24,4 +24,4 @@ } ] } -

      • lower_pantograph: indicates whether the pantograph should be lowered in this section
      • track_ranges: list of track sections ranges where the train must not traction
      • announcement_track_ranges: list of track sections ranges between the announcement sign and the execution sign

      Display

      Map

      The zones displayed in the map correspond to the track_ranges of neutral sections, thus are between the execution and end signs of the zone. The color of the zone indicates whether the train must lower its pantograph in the zone or not.

      The direction in which the zone applies is not represented.

      Simulation results

      In the linear display, it is always the area between EXE and FIN that is displayed.

      Pathfinding

      Neutral sections are therefore portions of “non-electrified” track where an electric train can still run (but where it cannot traction).

      When searching for a path in the infrastructure, an electric train can travel through a track section that is not covered by the track_ranges of a catenary object (documentation to be written) only if it is covered by the track_ranges of a neutral section.

      Simulation

      In our simulation, we approximate the driver’s behavior as follows:

      • The coasting is started as soon as the train’s head passes the announcement sign
      • The system times (pantograph reading and traction resumption) start as soon as the train’s head passes the end sign.

      In the current simulation, it is easier to use spatial integration bounds rather than temporal ones. We make the following approximation: when leaving the neutral section, we multiply the system times by the speed at the exit of the zone. The coasting is then extended over the obtained distance. This approximation is reasonable because the train’s inertia and the almost absence of friction guarantee that the speed varies little over this time interval.

      Improvements to be made

      Several aspects could be improved:

      • We do not model the REV signs, all trains therefore only have one pantograph at the front in our simulations.
      • System times are approximated.
      • The driver’s behavior is rather restrictive (coasting could start after the announcement sign).
      • The display of the zones is limited: no representation of the direction or the announcement zones.
      • These zones are not editable.
      © 2024 OSRD contributors. All Rights Reserved
      \ No newline at end of file +

      Display

      Map

      The zones displayed in the map correspond to the track_ranges of neutral sections, thus are between the execution and end signs of the zone. The color of the zone indicates whether the train must lower its pantograph in the zone or not.

      The direction in which the zone applies is not represented.

      Simulation results

      In the linear display, it is always the area between EXE and FIN that is displayed.

      Pathfinding

      Neutral sections are therefore portions of “non-electrified” track where an electric train can still run (but where it cannot traction).

      When searching for a path in the infrastructure, an electric train can travel through a track section that is not covered by the track_ranges of a catenary object (documentation to be written) only if it is covered by the track_ranges of a neutral section.

      Simulation

      In our simulation, we approximate the driver’s behavior as follows:

      In the current simulation, it is easier to use spatial integration bounds rather than temporal ones. We make the following approximation: when leaving the neutral section, we multiply the system times by the speed at the exit of the zone. The coasting is then extended over the obtained distance. This approximation is reasonable because the train’s inertia and the almost absence of friction guarantee that the speed varies little over this time interval.

      Improvements to be made

      Several aspects could be improved:

      \ No newline at end of file diff --git a/en/docs/explanation/models/data-models-full-example/index.html b/en/docs/explanation/models/data-models-full-example/index.html index 37bdda0a3..b437b7627 100644 --- a/en/docs/explanation/models/data-models-full-example/index.html +++ b/en/docs/explanation/models/data-models-full-example/index.html @@ -1,5 +1,5 @@ Infrastructure example | OSRD -
      © 2025 OSRD contributors. All Rights Reserved
      \ No newline at end of file diff --git a/en/docs/explanation/models/index.html b/en/docs/explanation/models/index.html index 5d94c7757..c4b30c204 100644 --- a/en/docs/explanation/models/index.html +++ b/en/docs/explanation/models/index.html @@ -1,5 +1,5 @@ Models | OSRD -

      Models

      What is modeled in OSRD, and how it is modeled
      Infrastructure example

      Explains using an example how infrastructure data is structured

      Neutral Sections

      Documentation about what they are and how they are implemented

      © 2025 OSRD contributors. All Rights Reserved
      \ No newline at end of file diff --git a/en/docs/explanation/models/neutral_sections/index.html b/en/docs/explanation/models/neutral_sections/index.html index 3af23318f..1d9268c73 100644 --- a/en/docs/explanation/models/neutral_sections/index.html +++ b/en/docs/explanation/models/neutral_sections/index.html @@ -1,5 +1,5 @@ Neutral Sections | OSRD -
      • lower_pantograph: indicates whether the pantograph should be lowered in this section
      • track_ranges: list of track sections ranges where the train must not traction
      • announcement_track_ranges: list of track sections ranges between the announcement sign and the execution sign

      Display

      Map

      The zones displayed in the map correspond to the track_ranges of neutral sections, thus are between the execution and end signs of the zone. The color of the zone indicates whether the train must lower its pantograph in the zone or not.

      The direction in which the zone applies is not represented.

      Simulation results

      In the linear display, it is always the area between EXE and FIN that is displayed.

      Pathfinding

      Neutral sections are therefore portions of “non-electrified” track where an electric train can still run (but where it cannot traction).

      When searching for a path in the infrastructure, an electric train can travel through a track section that is not covered by the track_ranges of a catenary object (documentation to be written) only if it is covered by the track_ranges of a neutral section.

      Simulation

      In our simulation, we approximate the driver’s behavior as follows:

      • The coasting is started as soon as the train’s head passes the announcement sign
      • The system times (pantograph reading and traction resumption) start as soon as the train’s head passes the end sign.

      In the current simulation, it is easier to use spatial integration bounds rather than temporal ones. We make the following approximation: when leaving the neutral section, we multiply the system times by the speed at the exit of the zone. The coasting is then extended over the obtained distance. This approximation is reasonable because the train’s inertia and the almost absence of friction guarantee that the speed varies little over this time interval.

      Improvements to be made

      Several aspects could be improved:

      • We do not model the REV signs, all trains therefore only have one pantograph at the front in our simulations.
      • System times are approximated.
      • The driver’s behavior is rather restrictive (coasting could start after the announcement sign).
      • The display of the zones is limited: no representation of the direction or the announcement zones.
      • These zones are not editable.
      \ No newline at end of file diff --git a/en/docs/explanation/netzgrafik-editor/_print/index.html b/en/docs/explanation/netzgrafik-editor/_print/index.html index 3d20d199d..d93687deb 100644 --- a/en/docs/explanation/netzgrafik-editor/_print/index.html +++ b/en/docs/explanation/netzgrafik-editor/_print/index.html @@ -1,5 +1,5 @@ Netzgrafik-Editor | OSRD -

      This is the multi-page printable view of this section. +

      This is the multi-page printable view of this section. Click here to print.

      Return to the regular view of this page.

      Netzgrafik-Editor

      Open-source software developed by SBB CFF FFS and its integration in OSRD

        Netzgrafik-Editor (NGE) is an open-source software that enables the creation, modification, and analysis of regular-interval timetable, at a macroscopic level of detail, developed by Swiss Federal Railways (SBB CFF FFS). See front-end and back-end repositories.

        OSRD (microscopic level of detail, trains scheduled once, based on a defined infrastructure, depicts a timetable) and NGE (macroscopic level of detail, regular-interval based train runs, no infrastructure, depicts a transportation plan) are semantically different, but close enough to make it work together. The compatibility between NGE and OSRD has been tested through a proof of concept, by running both pieces of software as separate services and without automated synchronization.

        The idea is to give to OSRD a graphical tool to edit (create, update and delete train schedules from) a timetable from an operational study scenario, and get some insights on analytics at the same time. The second benefit of using both microscopic and macroscopic level of detail is that OSRD microscopic calculations can be propagated in NGE to enhance the level of detail of it.

        The transversal objective of this feature is to make 2 open-source projects from 2 big infrastructure managers work along and cooperate with one another with the same goals.

        1 - Integration in OSRD

        Therefore, NGE is integrated in the operational studies section of OSRD, in an iframe. An alternative way to deal with the integration would have been to refactor NGE as web-components, thus easy to import in OSRD, but this solution has been abandoned, because of the quantity of refactoring that would have been needed. This iframe points to osrd-nge, a minimalist Angular app that embed the actual NGE app. It can also be seen as a wrapper of the actual NGE app. osrd-nge then customizes the actual NGE app with specific parameters and functionalities:

        • a standalone flag:
          • to tell NGE to disable all back-end interactions (no database on NGE side)
          • to tell NGE to disable some UI components (authentication, project management, versioning system view, etc.)
        • implementation of a communication interface between OSRD and NGE (message_event, eventListener and postMessage).

        NGE is then able to get the OSRD timetable as soon as a change is made on OSRD side, and OSRD is able to get the changes made on NGE side.

        The following diagram shows the workflow between the components.

        Concept diagram

        ---
 title: OSRD - NGE Sequence diagram
@@ -32,4 +32,4 @@
   OSRD (front-end)->> OSRD (front-end): convert timetable into <br> nge_light_model
   OSRD (front-end)->>NGE (osrd-nge): iframe.contentWindow.postMessage(nge_light_model, "*")
   NGE (osrd-nge)->>NGE (osrd-nge): (eventListener) <br> onLoad triggered
-  NGE (osrd-nge)->>NGE (nge-app): (callback function) <br> onLoad(nge_light_model, ...)

        2 - Converters

        To overpass the semantic differences and make the data models fit, 2 converters have to be implemented:

        • [OSRD -> NGE] a converter that transforms an OSRD timetable into an NGE model
        • [OSRD <- NGE] an event handler, that transforms NGE action into OSRD database update on timetable

        3 - Open-source (cooperation / contribution)

        To make NGE compatible with OSRD, some changes have been requested (disable back-end, create hooks on events) and directly implemented in the official repository of NGE, with the agreement and help of NGE team.

        Contributions for one project to another, from both sides, are valuable and will be entertained in the future.

        This feature also shows that open-source cooperation is powerful and a huge gain of time in software development.

        © 2024 OSRD contributors. All Rights Reserved
        \ No newline at end of file + NGE (osrd-nge)->>NGE (nge-app): (callback function) <br> onLoad(nge_light_model, ...)

        2 - Converters

        To overpass the semantic differences and make the data models fit, 2 converters have to be implemented:

        • [OSRD -> NGE] a converter that transforms an OSRD timetable into an NGE model
        • [OSRD <- NGE] an event handler, that transforms NGE action into OSRD database update on timetable

        3 - Open-source (cooperation / contribution)

        To make NGE compatible with OSRD, some changes have been requested (disable back-end, create hooks on events) and directly implemented in the official repository of NGE, with the agreement and help of NGE team.

        Contributions for one project to another, from both sides, are valuable and will be entertained in the future.

        This feature also shows that open-source cooperation is powerful and a huge gain of time in software development.

        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/explanation/netzgrafik-editor/index.html b/en/docs/explanation/netzgrafik-editor/index.html index 254c927d9..8757137a6 100644 --- a/en/docs/explanation/netzgrafik-editor/index.html +++ b/en/docs/explanation/netzgrafik-editor/index.html @@ -1,5 +1,5 @@ Netzgrafik-Editor | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/explanation/running_time_calculation/_print/index.html b/en/docs/explanation/running_time_calculation/_print/index.html index 10eb70e4f..101d2ac05 100644 --- a/en/docs/explanation/running_time_calculation/_print/index.html +++ b/en/docs/explanation/running_time_calculation/_print/index.html @@ -1,5 +1,5 @@ Running time calculation | OSRD -

        This is the multi-page printable view of this section. +

        This is the multi-page printable view of this section. Click here to print.

        Return to the regular view of this page.

        Running time calculation

        OSRD can be used to perform two types of calculations:

        • Standalone train simulation: calculation of the travel time of a train on a given route without interaction between the train and the signalling system.
        • Simulation: “dynamic” calculation of several trains interacting with each other via the signalling system.

        1 - The input data

        A running time calculation is based on 5 inputs:

        • Infrastructure: Line and track topology, position of stations and passenger buildings, position and type of points, signals, maximum line speeds, corrected line profile (gradients, ramps and curves).

        Infrastructure

        The blue histogram is a representation of the gradients in [‰] per position in [m]. The gradients are positive for ramps and negative for slopes.

        The orange line represents the cumulative profile, i.e. the relative altitude to the starting point.

        The blue line is a representation of turns in terms of radii of curves in [m].

        • The rolling stock: The characteristics of which needed to perform the simulation are shown below.

        Rolling Stock Material

        The orange curve, called the effort-speed curve, represents the maximum motor effort as a function of the speed of travel.

        The length, mass, and maximum speed of the train are shown at the bottom of the box.

        • The departure time is then used to calculate the times of passage at the various points of interest (including stations).

        • Allowances: Time added to the train’s journey to relax its running (see page on allowances).

        Allowances

        2 - The results

        The results of a running time calculation can be represented in different forms:

        • The space/time graph (GET): represents the path of trains in space and time, in the form of generally diagonal lines whose slope is the speed. Stops are shown as horizontal plates.

        Space/Time Graph

        Example of a GET with several trains spaced about 30 minutes apart.

        The x axis is the time of the train, the y axis is the position of the train in [m].

        The blue line represents the most tense running calculation for the train, the green line represents a relaxed, so-called “economic” running calculation.

        The solid rectangles surrounding the paths represent the portions of the track successively reserved for the train to pass (called blocks).

        • The space/speed graph (SSG): represents the journey of a single train, this time in terms of speed. Stops are therefore shown as a drop in the curve to zero, followed by a re-acceleration.

        Space/Speed Graph

        The x axis is the train position in [m], the y axis is the train speed in [km/h].

        The purple line represents the maximum permitted speed.

        The blue line represents the speed in the case of the most stretched running calculation.

        The green line represents the speed in the case of the “economic” travel calculation.

        • The timetable for the passage of the train at the various points of interest.

        Departure timetables

        1 - Physical modeling

        Physical modelling plays an important role in the OSRD core calculation. It allows us to simulate train traffic, and it must be as realistic as possible train traffic, and it must be as realistic as possible.

        Force review

        To calculate the displacement of the train over time, we must first calculate its speed at each instant. A simple way to obtain this speed is to calculate the acceleration. Thanks to the fundamental principle of dynamics, the acceleration of the train at each instant is directly dependent on the different forces applied to it: $$ \sum \vec{F}=m\vec{a} $$

        Running time

        • Traction: The value of the traction force \(F_{mot}\) depends on several factors:

          • the rolling stock
          • the speed of the train, \(v^{\prime}x\) according to the effort-speed curve below:

          $$ {\vec{F_{mot}}(v_{x^{\prime}}, x^{\prime})=F_{mot}(v_{x^{\prime}}, x^{\prime})\vec{e_x^{\prime}}} $$

          Running time

          The x axis represents the speed of the train in [km/h], the y axis the value of the traction force in [kN].

          • the action of the driver, who accelerates more or less strongly depending on where he is on his journey

        • Braking : The value of the braking force \(F_{brk}\) also depends on the rolling stock and the driver’s action but has a constant value for a given rolling stock. In the current state of modelling, braking is either zero or at its maximum value.

        $$ \vec{F_{brk}}(x^{\prime})=-F_{brk}(x^{\prime}){\vec{e_{x^{\prime}}}} $$

        A second approach to modelling braking is the so-called hourly approach, as it is used for hourly production at SNCF. In this case, the deceleration is fixed and the braking no longer depends on the different forces applied to the train. Typical deceleration values range from 0.4 to 0.7m/s².


        • Forward resistance: To model the forward resistance of the train, the Davis formula is used, which takes into account all the friction and aerodynamic resistance of the air. The value of the drag depends on the speed \(v^{\prime}_x\). The coefficients \(A\), \(B\), et \(C\) depend on the rolling stock.

        $$ {\vec{R}(v_{x^{\prime}})}=-(A+Bv_{x^{\prime}}+{Cv_{x^{\prime}}}^2){\vec{e_{x^{\prime}}}} $$


        • Weight (slopes + turns) : The weight force given by the product between the mass \(m\) of the train and the gravitational constant \(g\) is projected on the axes \(\vec{e_x}^{\prime}\) and \(\vec{e_y}^{\prime}\).For projection, we use the angle \(i(x^{\prime})\), which is calculated from the slope angle \(s(x^{\prime})\) corrected by a factor that takes into account the effect of the turning radius \(r(x^{\prime})\).

        $$ @@ -12,4 +12,4 @@ \(\vec{e_x}\) and \(\vec{e_x}^{\prime}\). The gradient still has an impact on the force balance, but it is assumed that the train is only moving horizontally, which gives the following simplified equation:

        $$ a_{x}(t) = \frac{1}{m}\Big[F_{mot}(v_{x}, x)-F_{brk}(x)-(A+Bv_{x}+{Cv_{x}}^2)-mgsin(i(x))\Big] $$

        Resolution

        The driving force and the braking force depend on the driver’s action (he decides to accelerate or brake more or less strongly depending on the situation). This dependence is reflected in the dependence of these two forces on the position of the train. The weight component is also dependent on the position of the train, as it comes directly from the slopes and bends below the train.

        In addition, the driving force depends on the speed of the train (according to the speed effort curve) as does the resistance to forward motion. resistance.

        These different dependencies make it impossible to solve this equation analytically, and the acceleration of the train at each moment must be calculated by numerical integration.

        2 - Numerical integration

        Introduction

        Since physical modelling has shown that the acceleration of the train is influenced by various factors that vary along the route (gradient, curvature, engine traction force, etc.), the calculation must be carried out using a numerical integration method. The path is then separated into sufficiently short steps to consider all these factors as constant, which allows this time to use the equation of motion to calculate the displacement and speed of the train.

        Euler’s method of numerical integration is the simplest way of doing this, but it has a number of drawbacks. This article explains the Euler method, why it is not suitable for OSRD purposes and which integration method should be used instead.

        Euler’s method

        The Euler method applied to the integration of the equation of motion of a train is:

        $$v(t+dt) = a(v(t), x(t))dt + v(t)$$

        $$x(t+dt) = \frac{1}{2}a(v(t), x(t))dt^2 + v(t)dt + x(t)$$

        Euler’s method

         

        Advantages of Euler’s method

        The advantages of the Euler method are that it is very simple to implement and has a rather fast calculation for a given time step, compared to other numerical integration methods (see appendix)

        Disadvantages of the Euler’s method

        The Euler integration method presents a number of problems for OSRD:

        • It is relatively imprecise, and therefore requires a small time step, which generates a lot of data.
        • With time integration, only the conditions at the starting point of the integration step (gradient, infrastructure parameters, etc.) are known, as one cannot predict precisely where it will end.
        • We cannot anticipate future changes in the directive: the train only reacts by comparing its current state with its set point at the same time. To illustrate, it is as if the driver is unable to see ahead, whereas in reality he anticipates according to the signals, slopes and bends he sees ahead.

        Runge-Kutta’s 4 method

        The Runge-Kutta 4 method applied to the integration of the equation of motion of a train is:

        $$v(t+dt) = v(t) + \frac{1}{6}(k_1 + 2k_2 + 2k_3 + k_4)dt$$

        With:

        $$k_1 = a(v(t), x(t))$$

        $$k_2 = a\Big(v(t+k_1\frac{dt}{2}), x(t) + v(t)\frac{dt}{2} + k_1\frac{dt^2}{8}\Big)$$

        $$k_3 = a\Big(v(t+k_2\frac{dt}{2}), x(t) + v(t)\frac{dt}{2} + k_2\frac{dt^2}{8}\Big)$$

        $$k_4 = a\Big(v(t+k_3dt), x(t) + v(t)dt + k_3\frac{dt^2}{2}\Big)$$

        Runge-Kutta 4’s method

         

        Advantages of Runge Kutta’s 4 method

        Runge Kutta’s method of integration 4 addresses the various problems raised by Euler’s method:

        • It allows the anticipation of directive changes within a calculation step, thus representing more accurately the reality of driving a train.
        • It is more accurate for the same calculation time (see appendix), allowing for larger integration steps and therefore fewer data points.

        Disadvantages of Runge Kutta’s 4 method

        The only notable drawback of the Runge Kutta 4 method encountered so far is its difficulty of implementation.

        The choice of integration method for OSRD

        Study of accuracy and speed of calculation

        Different integration methods could have replaced the basic Euler integration in the OSRD algorithm. In order to decide which method would be most suitable, a study of the accuracy and computational speed of different methods was carried out. This study compared the following methods:

        • Euler
        • Euler-Cauchy
        • Runge-Kutta 4
        • Adams 2
        • Adams 3

        All explanations of these methods can be found (in French) in this document, and the python code used for the simulation is here.

        The simulation calculates the position and speed of a high-speed train accelerating on a flat straight line.

        Equivalent time step simulations

        A reference curve was simulated using the Euler method with a time step of 0.1s, then the same path was simulated using the other methods with a time step of 1s. It is then possible to simply compare each curve to the reference curve, by calculating the absolute value of the difference at each calculated point. The resulting absolute error of the train’s position over its distance travelled is as follows:

        precisions_h_equivalent

        It is immediately apparent that the Euler method is less accurate than the other four by about an order of magnitude. Each curve has a peak where the accuracy is extremely high (extremely low error), which is explained by the fact that all curves start slightly above the reference curve, cross it at one point and end slightly below it, or vice versa.

        As accuracy is not the only important indicator, the calculation time of each method was measured. This is what we get for the same input parameters:

        Integration methodCalculation time (s)
        Euler1.86
        Euler-Cauchy3.80
        Runge-Kutta 47.01
        Adams 23.43
        Adams 35.27

        Thus, Euler-Cauchy and Adams 2 are about twice as slow as Euler, Adams 3 is about three times as slow, and RK4 is about four times as slow. These results have been verified on much longer simulations, and the different ratios are maintained.

        Simulation with equivalent calculation time

        As the computation times of all methods depend linearly on the time step, it is relatively simple to compare the accuracy for approximately the same computation time. Multiplying the time step of Euler-Cauchy and Adams 2 by 2, the time step of Adams 3 by 3, and the time step of RK4 by 4, here are the resulting absolute error curves:

        precisions_time_equivalent

        And here are the calculation times:

        Integration methodCalculation time (s)
        Euler1.75
        Euler-Cauchy2.10
        Runge-Kutta 41.95
        Adams 21.91
        Adams 31.99

        After some time, RK4 tends to be the most accurate method, slightly more accurate than Euler-Cauchy, and still much more accurate than the Euler method.

        Conclusions of the study

        The study of accuracy and computational speed presented above shows that RK4 and Euler-Cauchy would be good candidates to replace the Euler algorithm in OSRD: both are fast, accurate, and could replace the Euler method without requiring large implementation changes because they only compute within the current time step. It was decided that OSRD would use the Runge-Kutta 4 method because it is slightly more accurate than Euler-Cauchy and it is a well-known method for this type of calculation, so it is very suitable for an open-source simulator.

        3 - Envelopes system

        The envelope system is an interface created specifically for the OSRD gait calculation. It allows you to manipulate different space/velocity curves, to slice them, to end them, to interpolate specific points, and to address many other needs necessary for the gait calculation.

        A specific interface in the OSRD Core service

        The envelope system is part of the core service of OSRD (see software architecture).

        Its main components are :

        1 - EnvelopePart: space/speed curve, defined as a sequence of points and having metadata indicating for example if it is an acceleration curve, a braking curve, a speed hold curve, etc.

        2 - Envelope: a list of end-to-end EnvelopeParts on which it is possible to perform certain operations:

        • check for continuity in space (mandatory) and speed (optional)
        • look for the minimum and/or maximum speed of the envelope
        • cut a part of the envelope between two points in space
        • perform a velocity interpolation at a certain position
        • calculate the elapsed time between two positions in the envelope

        envelope_scheme

        3 - Overlays : system for adding more constrained (i.e. lower speed) EnvelopeParts to an existing envelope.

        Given envelopes vs. calculated envelopes

        During the simulation, the train is supposed to follow certain speed instructions. These are modelled in OSRD by envelopes in the form of space/speed curves. Two types can be distinguished:

        • Envelopes from infrastructure and rolling stock data, such as maximum line speed and maximum train speed. Being input data for our calculation, they do not correspond to curves with a physical meaning, as they are not derived from the results of a real integration of the physical equations of motion.
        • The envelopes result from real integration of the physical equations of motion. They correspond to a curve that is physically tenable by the train and also contain time information.

        A simple example to illustrate this difference: if we simulate a TER journey on a mountain line, one of the input data will be a maximum speed envelope of 160km/h, corresponding to the maximum speed of our TER. However, this envelope does not correspond to a physical reality, as it is possible that on certain sections the gradient is too steep for the train to be able to maintain this maximum speed of 160km/h. The calculated envelope will therefore show in this example a speed drop in the steepest areas, where the envelope given was perfectly flat.

        Simulation of several trains

        In the case of the simulation of many trains, the signalling system must ensure safety. The effect of signalling on the running calculation of a train is reproduced by superimposing dynamic envelopes on the static envelope. A new dynamic envelope is introduced for example when a signal closes. The train follows the static economic envelope superimposed on the dynamic envelopes, if any. In this simulation mode, a time check is performed against a theoretical time from the time information of the static economic envelope. If the train is late with respect to the scheduled time, it stops following the economic envelope and tries to go faster. Its space/speed curve will therefore be limited by the maximum effort envelope.

        4 - Pipeline

        The walk calculation in OSRD is a 4-step process, each using the envelopes system:

        1. Construction of the most restrictive speed profile
        2. Addition of the different braking curves
        3. Adding the different acceleration curves and checking the constant speed curves
        4. Application of allowance(s)

         

        Calculation of the Most Restricted Speed Profile (MRSP)

        A first envelope is calculated at the beginning of the simulation by grouping all static velocity limits:

        • maximum line speed
        • maximum speed of rolling stock
        • temporary speed limits (e.g. in case of works on a line)
        • speed limits by train category
        • speed limits according to train load
        • speed limits corresponding to signposts

        The length of the train is also taken into account to ensure that the train does not accelerate until its tail leaves the slowest speed zone. An offset is then applied to the red dashed curve. The resulting envelope (black curve) is called the Most Restricted Speed Profile (MRSP). It is on this envelope that the following steps will be calculated.

        Most Restricted Speed Profile

        The red dotted line represents the maximum permitted speed depending on the position. -The black line represents the MRSP where the train length has been taken into account.

        It should be noted that the different envelopeParts composing the MRSP are input data, so they do not correspond to curves with a physical reality.

        Calculation of the Max Speed Profile

        Starting from the MRSP, all braking curves are calculated using the overlay system (see here for more details on overlays), i.e. by creating envelopeParts which will be more restrictive than the MRSP. The resulting curve is called Max Speed Profile. This is the maximum speed envelope of the train, taking into account its braking capabilities.

        Since braking curves have an imposed end point and the braking equation has no analytical solution, it is impossible to predict their starting point. The braking curves are therefore calculated backwards from their target point, i.e. the point in space where a certain speed limit is imposed (finite target speed) or the stopping point (zero target speed).

        Max Speed Profile

        For historical reasons in hourly production, braking curves are calculated at SNCF with a fixed deceleration, the so-called hourly deceleration (typically ~0.5m/s²) without taking into account the other forces. This method has therefore also been implemented in OSRD, allowing the calculation of braking in two different ways: with this hourly rate or with a braking force that is simply added to the other forces.

        Calculation of the Max Effort Profile

        For each point corresponding to an increase in speed in the MRSP or at the end of a stop braking curve, an acceleration curve is calculated. The acceleration curves are calculated taking into account all active forces (traction force, driving resistance, weight) and therefore have a physical meaning.

        For envelopeParts whose physical meaning has not yet been verified (which at this stage are the constant speed running phases, always coming from the MRSP), a new integration of the equations of motion is performed. This last calculation is necessary to take into account possible speed stalls in case the train is physically unable to hold its speed, typically in the presence of steep ramps (see this example).

        The envelope that results from the addition of the acceleration curves and the verification of the speed plates is called the Max Effort Profile.

        Max Effort Profile

        At this stage, the resulting envelope is continuous and has a physical meaning from start to finish. The train accelerates to the maximum, runs as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum. The resulting travel calculation is called the basic running time. It corresponds to the fastest possible route for the given rolling stock on the given route.

        Application of allowance(s)

        After the calculation of the basic run (corresponding to the Max Effort Profile in OSRD), it is possible to apply allowances. Allowances are additions of extra time to the train’s journey. They are used to allow the train to catch up if necessary or for other operational purposes (more details on allowances here).

        A new Allowances envelope is therefore calculated using overlays to distribute the allowance requested by the user over the maximum effort envelope calculated previously.

        Allowances

        In the OSRD running calculation it is possible to distribute the allowances in a linear way, by lowering all speeds by a certain factor, or in an economic way, i.e. by minimising the energy consumption during the train run.

        5 - Allowances

        The purpose of allowances

        As explained in the calcul du Max Effort Profile, the basic running time represents the most stretched run normally achievable, i.e. the fastest possible run of the given equipment on the given route. The train accelerates to the maximum, travels as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum.

        This basic run has a major disadvantage: if a train leaves 10 minutes late, it will arrive at best 10 minutes late, because by definition it is impossible for it to run faster than the basic run. Therefore, trains are scheduled with one or more allowances added. The allowances are a relaxation of the train’s route, an addition of time to the scheduled timetable, which inevitably results in a lowering of running speeds.

        A train running in basic gear is unable to catch up!

        Allowances types

        There are two types of allowances:

        • The regularity allowance: this is the additional time added to the basic running time to take account of the inaccuracy of speed measurement, to compensate for the consequences of external incidents that disrupt the theoretical run of trains, and to maintain the regularity of the traffic. The regularity allowance applies to the whole route, although its value may change at certain intervals.
        • The construction allowance: this is the time added/removed on a specific interval, in addition to the regularity allowance, but this time for operational reasons (dodging another train, clearing a track more quickly, etc.)

        A basic running time with an added allowance of regularity gives what is known as a standard walk.

        Allowance distribution

        Since the addition of allowance results in lower speeds along the route, there are a number of possible routes. Indeed, there are an infinite number of solutions that result in the same journey time.

        As a simple example, in order to reduce the running time of a train by 10% of its journey time, it is possible to extend any stop by the time equivalent to this 10%, just as it is possible to run at 1/1.1 = 90.9% of the train’s capacity over the entire route, or to run slower, but only at high speeds…

        There are currently two algorithms for margin distribution in OSRD: linear and economic.

        Linear distribution

        Linear allowance distribution is simply lowering the speeds by the same factor over the area where the user applies the allowance. Here is an example of its application:

        Python plot linear

        The advantage of this distribution is that the allowance is spread evenly over the entire journey. A train that is late on 30% of its journey will have 70% of its allowance for the remaining 70% of its journey.

        Economic distribution

        The economic distribution of the allowance, presented in detail in this document (MARECO is an algorithm designed by the SNCF research department), consists of distributing the allowance in the most energy-efficient way possible. It is based on two principles:

        1. a maximum speed, avoiding the most energy-intensive speeds
        2. run-on zones, located before braking and steep gradients, where the train runs with the engine off thanks to its inertia, allowing it to consume no energy during this period

        Python plot eco with slopes

        An example of economic walking. Above, the gradients/ramps encountered by the train. The areas of travel on the track are shown in blue.

        © 2024 OSRD contributors. All Rights Reserved
        \ No newline at end of file +The black line represents the MRSP where the train length has been taken into account.

        It should be noted that the different envelopeParts composing the MRSP are input data, so they do not correspond to curves with a physical reality.

        Calculation of the Max Speed Profile

        Starting from the MRSP, all braking curves are calculated using the overlay system (see here for more details on overlays), i.e. by creating envelopeParts which will be more restrictive than the MRSP. The resulting curve is called Max Speed Profile. This is the maximum speed envelope of the train, taking into account its braking capabilities.

        Since braking curves have an imposed end point and the braking equation has no analytical solution, it is impossible to predict their starting point. The braking curves are therefore calculated backwards from their target point, i.e. the point in space where a certain speed limit is imposed (finite target speed) or the stopping point (zero target speed).

        Max Speed Profile

        For historical reasons in hourly production, braking curves are calculated at SNCF with a fixed deceleration, the so-called hourly deceleration (typically ~0.5m/s²) without taking into account the other forces. This method has therefore also been implemented in OSRD, allowing the calculation of braking in two different ways: with this hourly rate or with a braking force that is simply added to the other forces.

        Calculation of the Max Effort Profile

        For each point corresponding to an increase in speed in the MRSP or at the end of a stop braking curve, an acceleration curve is calculated. The acceleration curves are calculated taking into account all active forces (traction force, driving resistance, weight) and therefore have a physical meaning.

        For envelopeParts whose physical meaning has not yet been verified (which at this stage are the constant speed running phases, always coming from the MRSP), a new integration of the equations of motion is performed. This last calculation is necessary to take into account possible speed stalls in case the train is physically unable to hold its speed, typically in the presence of steep ramps (see this example).

        The envelope that results from the addition of the acceleration curves and the verification of the speed plates is called the Max Effort Profile.

        Max Effort Profile

        At this stage, the resulting envelope is continuous and has a physical meaning from start to finish. The train accelerates to the maximum, runs as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum. The resulting travel calculation is called the basic running time. It corresponds to the fastest possible route for the given rolling stock on the given route.

        Application of allowance(s)

        After the calculation of the basic run (corresponding to the Max Effort Profile in OSRD), it is possible to apply allowances. Allowances are additions of extra time to the train’s journey. They are used to allow the train to catch up if necessary or for other operational purposes (more details on allowances here).

        A new Allowances envelope is therefore calculated using overlays to distribute the allowance requested by the user over the maximum effort envelope calculated previously.

        Allowances

        In the OSRD running calculation it is possible to distribute the allowances in a linear way, by lowering all speeds by a certain factor, or in an economic way, i.e. by minimising the energy consumption during the train run.

        5 - Allowances

        The purpose of allowances

        As explained in the calcul du Max Effort Profile, the basic running time represents the most stretched run normally achievable, i.e. the fastest possible run of the given equipment on the given route. The train accelerates to the maximum, travels as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum.

        This basic run has a major disadvantage: if a train leaves 10 minutes late, it will arrive at best 10 minutes late, because by definition it is impossible for it to run faster than the basic run. Therefore, trains are scheduled with one or more allowances added. The allowances are a relaxation of the train’s route, an addition of time to the scheduled timetable, which inevitably results in a lowering of running speeds.

        A train running in basic gear is unable to catch up!

        Allowances types

        There are two types of allowances:

        • The regularity allowance: this is the additional time added to the basic running time to take account of the inaccuracy of speed measurement, to compensate for the consequences of external incidents that disrupt the theoretical run of trains, and to maintain the regularity of the traffic. The regularity allowance applies to the whole route, although its value may change at certain intervals.
        • The construction allowance: this is the time added/removed on a specific interval, in addition to the regularity allowance, but this time for operational reasons (dodging another train, clearing a track more quickly, etc.)

        A basic running time with an added allowance of regularity gives what is known as a standard walk.

        Allowance distribution

        Since the addition of allowance results in lower speeds along the route, there are a number of possible routes. Indeed, there are an infinite number of solutions that result in the same journey time.

        As a simple example, in order to reduce the running time of a train by 10% of its journey time, it is possible to extend any stop by the time equivalent to this 10%, just as it is possible to run at 1/1.1 = 90.9% of the train’s capacity over the entire route, or to run slower, but only at high speeds…

        There are currently two algorithms for margin distribution in OSRD: linear and economic.

        Linear distribution

        Linear allowance distribution is simply lowering the speeds by the same factor over the area where the user applies the allowance. Here is an example of its application:

        Python plot linear

        The advantage of this distribution is that the allowance is spread evenly over the entire journey. A train that is late on 30% of its journey will have 70% of its allowance for the remaining 70% of its journey.

        Economic distribution

        The economic distribution of the allowance, presented in detail in this document (MARECO is an algorithm designed by the SNCF research department), consists of distributing the allowance in the most energy-efficient way possible. It is based on two principles:

        1. a maximum speed, avoiding the most energy-intensive speeds
        2. run-on zones, located before braking and steep gradients, where the train runs with the engine off thanks to its inertia, allowing it to consume no energy during this period

        Python plot eco with slopes

        An example of economic walking. Above, the gradients/ramps encountered by the train. The areas of travel on the track are shown in blue.

        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/explanation/running_time_calculation/allowances/index.html b/en/docs/explanation/running_time_calculation/allowances/index.html index 14cf9a266..de39fdef5 100644 --- a/en/docs/explanation/running_time_calculation/allowances/index.html +++ b/en/docs/explanation/running_time_calculation/allowances/index.html @@ -3,7 +3,7 @@ This basic run has a major disadvantage: if a train leaves 10 minutes late, it will arrive at best 10 minutes late, because by definition it is impossible for it to run faster than the basic run.">

        Allowances

        The purpose of allowances

        As explained in the calcul du Max Effort Profile, the basic running time represents the most stretched run normally achievable, i.e. the fastest possible run of the given equipment on the given route. The train accelerates to the maximum, travels as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum.

        This basic run has a major disadvantage: if a train leaves 10 minutes late, it will arrive at best 10 minutes late, because by definition it is impossible for it to run faster than the basic run. Therefore, trains are scheduled with one or more allowances added. The allowances are a relaxation of the train’s route, an addition of time to the scheduled timetable, which inevitably results in a lowering of running speeds.

        A train running in basic gear is unable to catch up!

        Allowances types

        There are two types of allowances:

        • The regularity allowance: this is the additional time added to the basic running time to take account of the inaccuracy of speed measurement, to compensate for the consequences of external incidents that disrupt the theoretical run of trains, and to maintain the regularity of the traffic. The regularity allowance applies to the whole route, although its value may change at certain intervals.
        • The construction allowance: this is the time added/removed on a specific interval, in addition to the regularity allowance, but this time for operational reasons (dodging another train, clearing a track more quickly, etc.)

        A basic running time with an added allowance of regularity gives what is known as a standard walk.

        Allowance distribution

        Since the addition of allowance results in lower speeds along the route, there are a number of possible routes. Indeed, there are an infinite number of solutions that result in the same journey time.

        As a simple example, in order to reduce the running time of a train by 10% of its journey time, it is possible to extend any stop by the time equivalent to this 10%, just as it is possible to run at 1/1.1 = 90.9% of the train’s capacity over the entire route, or to run slower, but only at high speeds…

        There are currently two algorithms for margin distribution in OSRD: linear and economic.

        Linear distribution

        Linear allowance distribution is simply lowering the speeds by the same factor over the area where the user applies the allowance. Here is an example of its application:

        Python plot linear

        The advantage of this distribution is that the allowance is spread evenly over the entire journey. A train that is late on 30% of its journey will have 70% of its allowance for the remaining 70% of its journey.

        Economic distribution

        The economic distribution of the allowance, presented in detail in this document (MARECO is an algorithm designed by the SNCF research department), consists of distributing the allowance in the most energy-efficient way possible. It is based on two principles:

        1. a maximum speed, avoiding the most energy-intensive speeds
        2. run-on zones, located before braking and steep gradients, where the train runs with the engine off thanks to its inertia, allowing it to consume no energy during this period

        Python plot eco with slopes

        An example of economic walking. Above, the gradients/ramps encountered by the train. The areas of travel on the track are shown in blue.

        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/explanation/running_time_calculation/envelopes_system/index.html b/en/docs/explanation/running_time_calculation/envelopes_system/index.html index 5c06703d6..b95af2fc5 100644 --- a/en/docs/explanation/running_time_calculation/envelopes_system/index.html +++ b/en/docs/explanation/running_time_calculation/envelopes_system/index.html @@ -11,7 +11,7 @@ 1 - EnvelopePart: space/speed curve, defined as a sequence of points and having metadata indicating for example if it is an acceleration curve, a braking curve, a speed hold curve, etc.">

        Envelopes system

        The envelope system is an interface created specifically for the OSRD gait calculation. It allows you to manipulate different space/velocity curves, to slice them, to end them, to interpolate specific points, and to address many other needs necessary for the gait calculation.

        A specific interface in the OSRD Core service

        The envelope system is part of the core service of OSRD (see software architecture).

        Its main components are :

        1 - EnvelopePart: space/speed curve, defined as a sequence of points and having metadata indicating for example if it is an acceleration curve, a braking curve, a speed hold curve, etc.

        2 - Envelope: a list of end-to-end EnvelopeParts on which it is possible to perform certain operations:

        • check for continuity in space (mandatory) and speed (optional)
        • look for the minimum and/or maximum speed of the envelope
        • cut a part of the envelope between two points in space
        • perform a velocity interpolation at a certain position
        • calculate the elapsed time between two positions in the envelope

        envelope_scheme

        3 - Overlays : system for adding more constrained (i.e. lower speed) EnvelopeParts to an existing envelope.

        Given envelopes vs. calculated envelopes

        During the simulation, the train is supposed to follow certain speed instructions. These are modelled in OSRD by envelopes in the form of space/speed curves. Two types can be distinguished:

        • Envelopes from infrastructure and rolling stock data, such as maximum line speed and maximum train speed. Being input data for our calculation, they do not correspond to curves with a physical meaning, as they are not derived from the results of a real integration of the physical equations of motion.
        • The envelopes result from real integration of the physical equations of motion. They correspond to a curve that is physically tenable by the train and also contain time information.

        A simple example to illustrate this difference: if we simulate a TER journey on a mountain line, one of the input data will be a maximum speed envelope of 160km/h, corresponding to the maximum speed of our TER. However, this envelope does not correspond to a physical reality, as it is possible that on certain sections the gradient is too steep for the train to be able to maintain this maximum speed of 160km/h. The calculated envelope will therefore show in this example a speed drop in the steepest areas, where the envelope given was perfectly flat.

        Simulation of several trains

        In the case of the simulation of many trains, the signalling system must ensure safety. The effect of signalling on the running calculation of a train is reproduced by superimposing dynamic envelopes on the static envelope. A new dynamic envelope is introduced for example when a signal closes. The train follows the static economic envelope superimposed on the dynamic envelopes, if any. In this simulation mode, a time check is performed against a theoretical time from the time information of the static economic envelope. If the train is late with respect to the scheduled time, it stops following the economic envelope and tries to go faster. Its space/speed curve will therefore be limited by the maximum effort envelope.

        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/explanation/running_time_calculation/index.html b/en/docs/explanation/running_time_calculation/index.html index 84cc3ad43..037f59ced 100644 --- a/en/docs/explanation/running_time_calculation/index.html +++ b/en/docs/explanation/running_time_calculation/index.html @@ -1,5 +1,5 @@ Running time calculation | OSRD -

        Running time calculation

        OSRD can be used to perform two types of calculations:

        • Standalone train simulation: calculation of the travel time of a train on a given route without interaction between the train and the signalling system.
        • Simulation: “dynamic” calculation of several trains interacting with each other via the signalling system.

        1 - The input data

        A running time calculation is based on 5 inputs:

        • Infrastructure: Line and track topology, position of stations and passenger buildings, position and type of points, signals, maximum line speeds, corrected line profile (gradients, ramps and curves).

        Infrastructure

        The blue histogram is a representation of the gradients in [‰] per position in [m]. The gradients are positive for ramps and negative for slopes.

        The orange line represents the cumulative profile, i.e. the relative altitude to the starting point.

        The blue line is a representation of turns in terms of radii of curves in [m].

        • The rolling stock: The characteristics of which needed to perform the simulation are shown below.

        Rolling Stock Material

        The orange curve, called the effort-speed curve, represents the maximum motor effort as a function of the speed of travel.

        The length, mass, and maximum speed of the train are shown at the bottom of the box.

        • The departure time is then used to calculate the times of passage at the various points of interest (including stations).

        • Allowances: Time added to the train’s journey to relax its running (see page on allowances).

        Allowances

        2 - The results

        The results of a running time calculation can be represented in different forms:

        • The space/time graph (GET): represents the path of trains in space and time, in the form of generally diagonal lines whose slope is the speed. Stops are shown as horizontal plates.

        Space/Time Graph

        Example of a GET with several trains spaced about 30 minutes apart.

        The x axis is the time of the train, the y axis is the position of the train in [m].

        The blue line represents the most tense running calculation for the train, the green line represents a relaxed, so-called “economic” running calculation.

        The solid rectangles surrounding the paths represent the portions of the track successively reserved for the train to pass (called blocks).

        • The space/speed graph (SSG): represents the journey of a single train, this time in terms of speed. Stops are therefore shown as a drop in the curve to zero, followed by a re-acceleration.

        Space/Speed Graph

        The x axis is the train position in [m], the y axis is the train speed in [km/h].

        The purple line represents the maximum permitted speed.

        The blue line represents the speed in the case of the most stretched running calculation.

        The green line represents the speed in the case of the “economic” travel calculation.

        • The timetable for the passage of the train at the various points of interest.

        Departure timetables

        Physical modeling

        Numerical integration

        Envelopes system

        Pipeline

        Allowances

        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/explanation/running_time_calculation/numerical_integration/index.html b/en/docs/explanation/running_time_calculation/numerical_integration/index.html index d3141b861..0c026cbff 100644 --- a/en/docs/explanation/running_time_calculation/numerical_integration/index.html +++ b/en/docs/explanation/running_time_calculation/numerical_integration/index.html @@ -1,5 +1,5 @@ Numerical integration | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/explanation/running_time_calculation/physical_modeling/index.html b/en/docs/explanation/running_time_calculation/physical_modeling/index.html index 09f3f7ade..493fd2a39 100644 --- a/en/docs/explanation/running_time_calculation/physical_modeling/index.html +++ b/en/docs/explanation/running_time_calculation/physical_modeling/index.html @@ -3,7 +3,7 @@ Force review To calculate the displacement of the train over time, we must first calculate its speed at each instant. A simple way to obtain this speed is to calculate the acceleration. Thanks to the fundamental principle of dynamics, the acceleration of the train at each instant is directly dependent on the different forces applied to it: $$ \sum \vec{F}=m\vec{a} $$">
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/explanation/running_time_calculation/pipeline/index.html b/en/docs/explanation/running_time_calculation/pipeline/index.html index 86ac80662..d853ac1d2 100644 --- a/en/docs/explanation/running_time_calculation/pipeline/index.html +++ b/en/docs/explanation/running_time_calculation/pipeline/index.html @@ -11,7 +11,7 @@ maximum line speed maximum speed of rolling stock temporary speed limits (e.">
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/_print/index.html b/en/docs/guides/_print/index.html index 6c7d6f94e..3b4db7c90 100644 --- a/en/docs/guides/_print/index.html +++ b/en/docs/guides/_print/index.html @@ -1,6 +1,6 @@ How-to Guides | OSRD -

        This is the multi-page printable view of this section. -Click here to print.

        Return to the regular view of this page.

        How-to Guides

        Recipes for addressing key problems and use-cases

        How-to guides are recipes. They guide you through the steps involved in addressing key problems and use-cases. They are more advanced than tutorials and assume some knowledge of how OSRD works.

        1 - Contribute to OSRD

        Learn about the how we work, and how you can work with us

        1.1 - Preamble

        An introduction to contributing to OSRD

        First off, thanks for taking the time to contribute!

        The following chapters are a set of guidelines for contributing to OSRD. These guidelines are mostly not strict rules, it’s probably fine to do things slightly differently. If you have already contributed to open source projects before, you probably won’t be surprised. If you have not, it will probably help a lot!

        Communicate

        Chatting with other contributors is a great way to speed things up:

        Inquire

        Just like with any project, changes rely on past work. +

        This is the multi-page printable view of this section. +Click here to print.

        Return to the regular view of this page.

        How-to Guides

        Recipes for addressing key problems and use-cases

        How-to guides are recipes. They guide you through the steps involved in addressing key problems and use-cases. They are more advanced than tutorials and assume some knowledge of how OSRD works.

        1 - Contribute to OSRD

        Learn about the how we work, and how you can work with us

        1.1 - Preamble

        An introduction to contributing to OSRD

        First off, thanks for taking the time to contribute!

        The following chapters are a set of guidelines for contributing to OSRD. These guidelines are mostly not strict rules, it’s probably fine to do things slightly differently. If you have already contributed to open source projects before, you probably won’t be surprised. If you have not, it will probably help a lot!

        Communicate

        Chatting with other contributors is a great way to speed things up:

        Inquire

        Just like with any project, changes rely on past work. Before making changes, it is best to learn about what’s already there:

        • read technical documentation
        • read the existing source code related to your project
        • chat with developers who last worked on areas you are interested in

        Continue towards initial set-up ‣

        1.2 - License and set-up

        How to set up your development environment? What does our license involve?

        License of code contributions

        The source code of OSRD is available under the LGPLv3 license. By contributing to the codebase, you consent to the distribution of your changes under the project’s license.

        LGPLv3 forbids modifying source code without sharing the changes under the same license: use other people’s work, and share yours!

        This constraint does not propagate through APIs: You can use OSRD as a library, framework or API server to interface with proprietary software. Please suggest changes if you need new interfaces.

        Set things up

        Get the source code

        • Install git.1
        • Open a terminal2 in the folder where the source code of OSRD will be located
        • Run git clone https://github.com/OpenRailAssociation/osrd.git

        Launch the application

        Docker is a tool which greatly reduces the amount of setup required to work on OSRD:

        • download the latest development build: docker compose pull
        • start OSRD: docker compose up
        • build and start OSRD: docker compose up --build
        • review a PR using CI built images: TAG=pr-XXXXX docker compose up --no-build --pull always

        To get started:

        Continue towards code contribution ‣

        1. Under Linux, use the package manager (such as apt) ↩︎

        2. Under Windows, open Git Bash ↩︎

        1.3 - Contribute code

        Integrate changes into OSRD

        This chapter is about the process of integrating changes into the common code base. If you need help at any stage, open an issue or message us.

        OSRD application is split in multiple services written in several languages. We try to follow general code best practices and follow each language specificities when required.

        1.3.1 - General principles

        Please read this first!
        • Explain what you’re doing and why.
        • Document new code with doc comments.
        • Include clear, simple tests.
        • Break work into digestible chunks.
        • Take the time to pick good names.
        • Avoid non well-known abbreviations.
        • Control and consistency over 3rd party code reuse: Only add a dependency if it is absolutely necessary.
        • Every dependency we add decreases our autonomy and consistency.
        • We try to keep PRs bumping dependencies to a low number each week in each component, so grouping dependency bumps in a batch PR is a valid option (see component’s README.md).
        • Don’t reinvent every wheel: as a counter to the previous point, don’t reinvent everything at all costs.
        • If there is a dependency in the ecosystem that is the “de facto” standard, we should heavily consider using it.
        • More code general recommendations in main repository CONTRIBUTING.md.
        • Ask for any help that you need!

        Consult back-end conventions ‣

        Consult front-end conventions ‣

        Continue towards write code ‣

        Continue towards tests ‣

        1.3.2 - Back-end conventions

        Coding style guide and best practices for back-end

        Python

        Python code is used for some packages and integration testing.

        Rust

        • As a reference for our API development we are using the Rust API guidelines. @@ -243,7 +243,23 @@

        Use of logo only (without text)

        Colors

        These colours are those of the logo and should not be confused with those of the overall design of the OSRD interface.

        #786ABF -#C7B2DE

        4 - OSRD's design

        Colours, fonts, uses…

        Everything is presented on a dedicated website https://design.osrd.fr

        A “design system” is being developed.

        5 - Release

        How to make a release

        All OSRD releases are accessible here

        The process for creating a new release is as follows:

        1. We always release on a tested version of the application (staging branch)
          • git switch staging && git pull
        2. Create a git annotated tag
          • We are using the semantic versioning
          • git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version)
          • git push --tags
        3. Create a github release
          • Draft a new github release here
          • Select the created tag
          • Generate the releases notes
          • Rename the release like so: “Version x.y.z”
          • Check the “Set as a pre-release” box
          • Apply the changelog format
          • Then you can publish the release or save the draft if you want to come back later
        4. A github action should be triggered automatically.
        5. Post the link of the created release on matrix. Suggest that the developers review the release.

        Changelog format

        1. Use the following structure:
        ## What's Changed
+#C7B2DE

        4 - OSRD's design

        Colours, fonts, uses…

        Everything is presented on a dedicated website https://design.osrd.fr

        A “design system” is being developed.

        5 - Release

        Release section

        This section documents the process around creating a release of OSRD.

        5.1 - Release process

        Here’s how OSRD is currently released

        OSRD has three versions: development (dev), staging, and release.

        The development version is the most recent and unstable version of the application, containing the latest features and bug fixes in active development.

        Staging versions are created every Thursday at 12pm by tagging the current development state.

        If a staging version passes validation testing, it is promoted to become the latest release version. This ensures that only stable, tested code makes it into production releases.

        The release process follows this workflow:

        1. Ongoing development in the dev branch
        2. Weekly staging tags on Thursdays at 12pm
        3. Validation testing of staging version
        4. Promotion of validated staging builds to release status
            Development         Staging                   Release
+    (unstable)         (testing)                 (stable)
+
+    [Dev Branch]                                    |
+         |                                          |
+         |--->     Thursday 12pm                    |
+         |         [Staging Tag]                    |
+         |                |                         |
+         |            Validation                    |
+         |             Testing                      |
+         |                |                         |
+         |                o---> If Passes -->  [New Release]
+         |                       Tests              |
+    [Continue Dev]                                  |
+         |                                          |
+         V                                          V
+

        5.2 - Publish a new release

        How to publish a new release

        All OSRD releases are accessible here

        The process for creating a new release is as follows:

        1. We always release on a tested version of the application (staging branch)
          • git switch staging && git pull
        2. Create a git annotated tag
          • We are using the semantic versioning
          • git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version)
          • git push --tags
        3. Create a github release
          • Draft a new github release here
          • Select the created tag
          • Generate the releases notes
          • Rename the release like so: “Version x.y.z”
          • Check the “Set as a pre-release” box
          • Apply the changelog format
          • Then you can publish the release or save the draft if you want to come back later
        4. A github action should be triggered automatically.
        5. Post the link of the created release on matrix. Suggest that the developers review the release.

        Changelog format

        1. Use the following structure:
        ## What's Changed
 
 ### Features :tada:
 
@@ -261,4 +277,4 @@
 
 <!-- Copy from the generated release notes -->
 **Full Changelog**: ...
-
        1. Partition the different pull requests
        2. Merge or group PR when it make sense. Examples:
          • Bump of dependencies PR (merge)
          • Multi part PR (merge)
          • One big feature implemented by multiple PR (group)
        3. Reword PR title. It should be comprehensible to an external collaborator
        © 2024 OSRD contributors. All Rights Reserved
        \ No newline at end of file +
        1. Partition the different pull requests
        2. Merge or group PR when it make sense. Examples:
          • Bump of dependencies PR (merge)
          • Multi part PR (merge)
          • One big feature implemented by multiple PR (group)
        3. Reword PR title. It should be comprehensible to an external collaborator
        \ No newline at end of file diff --git a/en/docs/guides/contribute/_print/index.html b/en/docs/guides/contribute/_print/index.html index fc0435c71..e9577b36b 100644 --- a/en/docs/guides/contribute/_print/index.html +++ b/en/docs/guides/contribute/_print/index.html @@ -1,5 +1,5 @@ Contribute to OSRD | OSRD -

        This is the multi-page printable view of this section. +

        This is the multi-page printable view of this section. Click here to print.

        Return to the regular view of this page.

        Contribute to OSRD

        Learn about the how we work, and how you can work with us

        1 - Preamble

        An introduction to contributing to OSRD

        First off, thanks for taking the time to contribute!

        The following chapters are a set of guidelines for contributing to OSRD. These guidelines are mostly not strict rules, it’s probably fine to do things slightly differently. If you have already contributed to open source projects before, you probably won’t be surprised. If you have not, it will probably help a lot!

        Communicate

        Chatting with other contributors is a great way to speed things up:

        Inquire

        Just like with any project, changes rely on past work. Before making changes, it is best to learn about what’s already there:

        • read technical documentation
        • read the existing source code related to your project
        • chat with developers who last worked on areas you are interested in

        Continue towards initial set-up ‣

        2 - License and set-up

        How to set up your development environment? What does our license involve?

        License of code contributions

        The source code of OSRD is available under the LGPLv3 license. By contributing to the codebase, you consent to the distribution of your changes under the project’s license.

        LGPLv3 forbids modifying source code without sharing the changes under the same license: use other people’s work, and share yours!

        This constraint does not propagate through APIs: You can use OSRD as a library, framework or API server to interface with proprietary software. Please suggest changes if you need new interfaces.

        Set things up

        Get the source code

        • Install git.1
        • Open a terminal2 in the folder where the source code of OSRD will be located
        • Run git clone https://github.com/OpenRailAssociation/osrd.git

        Launch the application

        Docker is a tool which greatly reduces the amount of setup required to work on OSRD:

        • download the latest development build: docker compose pull
        • start OSRD: docker compose up
        • build and start OSRD: docker compose up --build
        • review a PR using CI built images: TAG=pr-XXXXX docker compose up --no-build --pull always

        To get started:

        Continue towards code contribution ‣

        1. Under Linux, use the package manager (such as apt) ↩︎

        2. Under Windows, open Git Bash ↩︎

        3 - Contribute code

        Integrate changes into OSRD

        This chapter is about the process of integrating changes into the common code base. If you need help at any stage, open an issue or message us.

        OSRD application is split in multiple services written in several languages. We try to follow general code best practices and follow each language specificities when required.

        3.1 - General principles

        Please read this first!
        • Explain what you’re doing and why.
        • Document new code with doc comments.
        • Include clear, simple tests.
        • Break work into digestible chunks.
        • Take the time to pick good names.
        • Avoid non well-known abbreviations.
        • Control and consistency over 3rd party code reuse: Only add a dependency if it is absolutely necessary.
        • Every dependency we add decreases our autonomy and consistency.
        • We try to keep PRs bumping dependencies to a low number each week in each component, so grouping @@ -210,4 +210,4 @@ A->>R: Rebase and apply fixups R->>A: Checks commits history R->>A: Approves or closes the PR - Note left of R: & Merges if maintainer
        © 2024 OSRD contributors. All Rights Reserved
        \ No newline at end of file + Note left of R: & Merges if maintainer
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/bug-reports/index.html b/en/docs/guides/contribute/bug-reports/index.html index e1a4c31f6..bb3548575 100644 --- a/en/docs/guides/contribute/bug-reports/index.html +++ b/en/docs/guides/contribute/bug-reports/index.html @@ -1,5 +1,5 @@ Report issues | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/code-review/index.html b/en/docs/guides/contribute/code-review/index.html index fbdaf6c2d..2dc36b9fc 100644 --- a/en/docs/guides/contribute/code-review/index.html +++ b/en/docs/guides/contribute/code-review/index.html @@ -1,5 +1,5 @@ Review process | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/_print/index.html b/en/docs/guides/contribute/contribute-code/_print/index.html index b1af3a546..f6a165f48 100644 --- a/en/docs/guides/contribute/contribute-code/_print/index.html +++ b/en/docs/guides/contribute/contribute-code/_print/index.html @@ -1,5 +1,5 @@ Contribute code | OSRD -

        This is the multi-page printable view of this section. +

        This is the multi-page printable view of this section. Click here to print.

        Return to the regular view of this page.

        Contribute code

        Integrate changes into OSRD

        This chapter is about the process of integrating changes into the common code base. If you need help at any stage, open an issue or message us.

        OSRD application is split in multiple services written in several languages. We try to follow general code best practices and follow each language specificities when required.

        1 - General principles

        Please read this first!
        • Explain what you’re doing and why.
        • Document new code with doc comments.
        • Include clear, simple tests.
        • Break work into digestible chunks.
        • Take the time to pick good names.
        • Avoid non well-known abbreviations.
        • Control and consistency over 3rd party code reuse: Only add a dependency if it is absolutely necessary.
        • Every dependency we add decreases our autonomy and consistency.
        • We try to keep PRs bumping dependencies to a low number each week in each component, so grouping dependency bumps in a batch PR is a valid option (see component’s README.md).
        • Don’t reinvent every wheel: as a counter to the previous point, don’t reinvent everything at all costs.
        • If there is a dependency in the ecosystem that is the “de facto” standard, we should heavily consider using it.
        • More code general recommendations in main repository CONTRIBUTING.md.
        • Ask for any help that you need!

        Consult back-end conventions ‣

        Consult front-end conventions ‣

        Continue towards write code ‣

        Continue towards tests ‣

        2 - Back-end conventions

        Coding style guide and best practices for back-end

        Python

        Python code is used for some packages and integration testing.

        Rust

        • As a reference for our API development we are using the Rust API guidelines. Generally, these should be followed.
        • Prefer granular imports over glob imports like diesel::*.
        • Tests are written with the built-in testing framework.
        • Use the documentation example to know how to phrase and format your documentation.
        • Use consistent comment style:
          • /// doc comments belong above #[derive(Trait)] invocations.
          • // comments should generally go above the line in question, rather than in-line.
          • Start comments with capital letters. End them with a period if they are sentence-like.
        • Use comments to organize long and complex stretches of code that can’t sensibly be refactored into separate functions.
        • Code is linted with clippy.
        • Code is formatted with fmt.

        Java

        3 - Front-end conventions

        Coding style guide and best practices for front-end

        We use ReactJS and all files must be written in Typescript.

        The code is linted with eslint, and formatted with prettier.

        Nomenclature

        Infrastructure diagram

        The applications (osrd eex, osrd stdcm, infra editor, rolling-stock editor) offer views (project management, study management, etc.) linked to modules (project, study, etc.) which contain the components.

        These views are made up of components and sub-components all derived from the modules. @@ -167,4 +167,4 @@ R->>A: Checks commits history R->>A: Approves or closes the PR Note left of R: & Merges if maintainer

        Finally continue towards tests ‣

        7 - Tests

        Recommandations for testing purpose

        Back-end

        • Integration tests are written with pytest in the /tests folder.
        • Each route described in the openapi.yaml files must have an integration test.
        • The test must check both the format and content of valid and invalid responses.

        Front-end

        The functional writing of the tests is carried out with the Product Owners, and the developers choose a technical implementation that precisely meets the needs expressed and fits in with the recommendations presented here.

        We use Playwright to write end-to-end tests, and vitest to write unit tests.

        The browsers tested are currently Firefox and Chromium.

        Basic principles

        • Tests must be short (1min max) and go straight to the point.
        • Arbitrary timeouts are outlawed; a test must systematically wait for a specific event. It is possible to use polling (retry an action - a click for example - after a certain time) proposed in the Playwright’s API.
        • All tests must be parallelizable.
        • Tests must not point to or wait for text elements from the translation, prefer the DOM tree structure or place specific id.
        • We’re not testing the data, but the application and its functionality. Data-specific tests should be developed in parallel.

        Data

        The data tested must be public data. -The data required (infrastructure and rolling stock) for the tests are offered in the application’s json files, injected at the start of each test and deleted at the end, regardless of its result or how it is stopped, including with CTRL+C.

        This is done by API calls in typescript before launching the actual test.

        The data tested is the same, both locally and via continuous integration.

        Atomicity of a test

        Each test must be atomic: it is self-sufficient and cannot be divided.

        A test will target a single feature or component, provided it is not too large. A test will not test an entire module or application; it will necessarily be a set of tests, in order to preserve test atomicity.

        If a test needs elements to be created or added, these operations must be carried out by API calls in typescript upstream of the test, as is done for adding data. These elements must be deleted at the end of the test, regardless of the result or how it is stopped, including by CTRL+C.

        This allows tests to be parallelized.

        However, in certain cases where it is relevant, a test may contain several clearly explained and justified test subdivisions (several test() in a single describe()).

        Example of a test

        The requirement: “We want to test the addition of a train to a timetable”.

        1. add the test infrastructure and rolling stock to the database by API calls.
        2. create project, study and scenario with choice of test infrastructure by API calls.
        3. start the test, clicking on “add one or more trains” until the presence of the trains in the timetable is verified
        4. the test passes, fails or is stopped, the project, study and scenario are deleted, along with the test rolling stock and infrastructure by API calls.

        NB: the test will not test all the possibilities offered by the addition of trains; this should be a specific test which would test the response of the interface for all scenarios without adding trains.

        Continue towards write code ‣

        © 2024 OSRD contributors. All Rights Reserved
        \ No newline at end of file +The data required (infrastructure and rolling stock) for the tests are offered in the application’s json files, injected at the start of each test and deleted at the end, regardless of its result or how it is stopped, including with CTRL+C.

        This is done by API calls in typescript before launching the actual test.

        The data tested is the same, both locally and via continuous integration.

        Atomicity of a test

        Each test must be atomic: it is self-sufficient and cannot be divided.

        A test will target a single feature or component, provided it is not too large. A test will not test an entire module or application; it will necessarily be a set of tests, in order to preserve test atomicity.

        If a test needs elements to be created or added, these operations must be carried out by API calls in typescript upstream of the test, as is done for adding data. These elements must be deleted at the end of the test, regardless of the result or how it is stopped, including by CTRL+C.

        This allows tests to be parallelized.

        However, in certain cases where it is relevant, a test may contain several clearly explained and justified test subdivisions (several test() in a single describe()).

        Example of a test

        The requirement: “We want to test the addition of a train to a timetable”.

        1. add the test infrastructure and rolling stock to the database by API calls.
        2. create project, study and scenario with choice of test infrastructure by API calls.
        3. start the test, clicking on “add one or more trains” until the presence of the trains in the timetable is verified
        4. the test passes, fails or is stopped, the project, study and scenario are deleted, along with the test rolling stock and infrastructure by API calls.

        NB: the test will not test all the possibilities offered by the addition of trains; this should be a specific test which would test the response of the interface for all scenarios without adding trains.

        Continue towards write code ‣

        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/backend-conventions/index.html b/en/docs/guides/contribute/contribute-code/backend-conventions/index.html index 448161dfb..96e9f84d8 100644 --- a/en/docs/guides/contribute/contribute-code/backend-conventions/index.html +++ b/en/docs/guides/contribute/contribute-code/backend-conventions/index.html @@ -1,5 +1,5 @@ Back-end conventions | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/commit-conventions/index.html b/en/docs/guides/contribute/contribute-code/commit-conventions/index.html index 81346f60e..82c7ede92 100644 --- a/en/docs/guides/contribute/contribute-code/commit-conventions/index.html +++ b/en/docs/guides/contribute/contribute-code/commit-conventions/index.html @@ -1,5 +1,5 @@ Commit conventions | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/frontend-conventions/index.html b/en/docs/guides/contribute/contribute-code/frontend-conventions/index.html index e123acec3..58c80897b 100644 --- a/en/docs/guides/contribute/contribute-code/frontend-conventions/index.html +++ b/en/docs/guides/contribute/contribute-code/frontend-conventions/index.html @@ -1,5 +1,5 @@ Front-end conventions | OSRD -

        This allows to:

        • Improve the performance and analysis process of the compiler and the linter.
        • Make these declarations more readable; we can clearly see what we are importing.
        • Avoid dependency cycles:

        dependency cycle

        The error disappears with the type keyword

        dependency cycle

        • Make final bundle lighter (all types disappear at compilation)
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/general-principles/index.html b/en/docs/guides/contribute/contribute-code/general-principles/index.html index 3f53ecb32..1df1d4bfe 100644 --- a/en/docs/guides/contribute/contribute-code/general-principles/index.html +++ b/en/docs/guides/contribute/contribute-code/general-principles/index.html @@ -1,5 +1,5 @@ General principles | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/index.html b/en/docs/guides/contribute/contribute-code/index.html index e1dd8a42e..43549ca94 100644 --- a/en/docs/guides/contribute/contribute-code/index.html +++ b/en/docs/guides/contribute/contribute-code/index.html @@ -1,5 +1,5 @@ Contribute code | OSRD -

        Contribute code

        Integrate changes into OSRD

        This chapter is about the process of integrating changes into the common code base. If you need help at any stage, open an issue or message us.

        OSRD application is split in multiple services written in several languages. We try to follow general code best practices and follow each language specificities when required.

        General principles

        Please read this first!

        Back-end conventions

        Coding style guide and best practices for back-end

        Front-end conventions

        Coding style guide and best practices for front-end

        Write code

        Integrate changes into OSRD

        Commit conventions

        A few advises and rules about commit messages

        Share your changes

        How to submit your code modifications for review?

        Tests

        Recommandations for testing purpose

        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/share-changes/index.html b/en/docs/guides/contribute/contribute-code/share-changes/index.html index dc1e3f101..5af111541 100644 --- a/en/docs/guides/contribute/contribute-code/share-changes/index.html +++ b/en/docs/guides/contribute/contribute-code/share-changes/index.html @@ -1,5 +1,5 @@ Share your changes | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/tests/index.html b/en/docs/guides/contribute/contribute-code/tests/index.html index 468992c78..636034212 100644 --- a/en/docs/guides/contribute/contribute-code/tests/index.html +++ b/en/docs/guides/contribute/contribute-code/tests/index.html @@ -1,5 +1,5 @@ Tests | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/contribute-code/write-code/index.html b/en/docs/guides/contribute/contribute-code/write-code/index.html index 848b4c651..135656ad2 100644 --- a/en/docs/guides/contribute/contribute-code/write-code/index.html +++ b/en/docs/guides/contribute/contribute-code/write-code/index.html @@ -1,5 +1,5 @@ Write code | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/index.html b/en/docs/guides/contribute/index.html index 613d658c9..36fc4d127 100644 --- a/en/docs/guides/contribute/index.html +++ b/en/docs/guides/contribute/index.html @@ -1,5 +1,5 @@ Contribute to OSRD | OSRD -

        Contribute to OSRD

        Learn about the how we work, and how you can work with us
        Preamble

        An introduction to contributing to OSRD

        License and set-up

        How to set up your development environment? What does our license involve?

        Contribute code

        Integrate changes into OSRD

        Review process

        How to give useful feedback

        Report issues

        Report a bug or suggest an enhancement

        Install docker

        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/install-docker/index.html b/en/docs/guides/contribute/install-docker/index.html index ed135b5d3..6303d05dd 100644 --- a/en/docs/guides/contribute/install-docker/index.html +++ b/en/docs/guides/contribute/install-docker/index.html @@ -11,7 +11,7 @@ If you’re on linux, install docker engine using your package manager If you’re on MacOS / Windows, install docker desktop if you are allowed to If you’re on windows and want to get docker running within WSL, or can’t use docker desktop, follow the docker on WSL tutorial If you’re on MacOS and can’t use docker desktop, follow the MacOS colima tutorial Docker on WSL This install option is very useful, as it allows having a perfectly normal linux install of docker engine inside WSL, which can still be reached from windows.">
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/license-and-set-up/index.html b/en/docs/guides/contribute/license-and-set-up/index.html index e6c3dee51..3ac5ba0ff 100644 --- a/en/docs/guides/contribute/license-and-set-up/index.html +++ b/en/docs/guides/contribute/license-and-set-up/index.html @@ -1,5 +1,5 @@ License and set-up | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/preamble/index.html b/en/docs/guides/contribute/preamble/index.html index c2c853b67..d9bb326a2 100644 --- a/en/docs/guides/contribute/preamble/index.html +++ b/en/docs/guides/contribute/preamble/index.html @@ -1,5 +1,5 @@ Preamble | OSRD -
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/contribute/review-process/index.html b/en/docs/guides/contribute/review-process/index.html index 177111b50..73fa96d93 100644 --- a/en/docs/guides/contribute/review-process/index.html +++ b/en/docs/guides/contribute/review-process/index.html @@ -7,7 +7,7 @@ It is advisable to configure OSRD repositories as “Participating and @mentions”. This allows you to be notified of activities only on issues and PRs in which you participate. Maintainers are automatically notified by the CODEOWNERS system. The author of a PR is responsible for advancing their PR through the review process and manually requesting maintainer feedback if necessary.">
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/deploy/_print/index.html b/en/docs/guides/deploy/_print/index.html index ea930554a..5e26ee4e2 100644 --- a/en/docs/guides/deploy/_print/index.html +++ b/en/docs/guides/deploy/_print/index.html @@ -1,5 +1,5 @@ Deploy OSRD | OSRD -

        This is the multi-page printable view of this section. +

        This is the multi-page printable view of this section. Click here to print.

        Return to the regular view of this page.

        Deploy OSRD

        Learn how to deploy OSRD in various environments

        First of all, we recommend learning about the containers architecture of OSRD.

        We will cover how to deploy OSRD within the following setups:

        It is also possible to deploy each service of OSRD manually on a system, but we will not cover this topic within this guide.

        1 - Docker Compose

        Using docker compose for single node deployment

        The OSRD project includes a docker-compose.yml file designed to facilitate the deployment of a fully functional OSRD environment. Only intended for development purposes, this Docker Compose configuration could be adapted for quick, single-node deployments.

        This configuration is queried by the frontend. That way, the right objects and time bounds are used transparently by the user.

        In order to setup this config, you can either

        • Use the provided REST API (see the editoast openAPI -in the stdcm_search_environment section)
        • Use the provided editoast cli (run editoast stdcm-search-env help for more information)
        © 2024 OSRD contributors. All Rights Reserved
        \ No newline at end of file +in the stdcm_search_environment section)
      • Use the provided editoast cli (run editoast stdcm-search-env help for more information)
        © 2025 OSRD contributors. All Rights Reserved
        \ No newline at end of file diff --git a/en/docs/guides/deploy/docker-compose/_print/index.html b/en/docs/guides/deploy/docker-compose/_print/index.html index 8453e3803..67947bfae 100644 --- a/en/docs/guides/deploy/docker-compose/_print/index.html +++ b/en/docs/guides/deploy/docker-compose/_print/index.html @@ -1,9 +1,9 @@ Docker Compose | OSRD -

        This is the multi-page printable view of this section. +

        This is the multi-page printable view of this section. Click here to print.

        Return to the regular view of this page.

        Docker Compose

        Using docker compose for single node deployment

          The OSRD project includes a docker-compose.yml file designed to facilitate the deployment of a fully functional OSRD environment. Only intended for development purposes, this Docker Compose configuration could be adapted for quick, single-node deployments.

          Prerequisites

          Before proceeding with the deployment, ensure that you have the following installed:

          • Docker
          • Docker Compose

          Configuration Overview

          The docker-compose.yml file defines the following services:

          1. PostgreSQL: A PostgreSQL database with PostGIS extension.
          2. Valkey: A Valkey server for caching.
          3. Core: The core OSRD service.
          4. Front: The front-end service for OSRD.
          5. Editoast: A OSRD service responsible for various editorial functions.
          6. Gateway: Serves as the gateway for the OSRD services.
          7. Wait-Healthy: A utility service to ensure all services are healthy before proceeding.

          Each service is configured with health checks, volume mounts and necessary environment variables.

          Deployment Steps

          1. Clone the Repository: First, clone the OSRD repository to your local machine.
          2. Configuration: The default configuration requires setting an environment variable for the Editoast service: ROOT_URL. It should be set to the URL pointing to the Editoast service through the gateway. For example, “http://your-domain.com/api". You can also adjust other environment variables if needed.
          3. Build and Run: Navigate to the directory containing docker-compose.yml and run:
          docker-compose up --build
-

          This command builds the images and starts the services defined in the Docker Compose file.

          Accessing Services

          While all HTTP service are used through the gateway (http://localhost:4000), you can access directly each service using their exposed ports:

          • PostgreSQL: Accessible on localhost:5432.
          • Valkey: Accessible on localhost:6379.
          • Core Service: Accessible on localhost:8080.
          • Front-End: Accessible on localhost:3000.
          • Editoast: Accessible on localhost:8090.

          Notes and Considerations

          • This setup is designed for development and quick deployments. For production environments, additional considerations for security, scalability and reliability should be addressed.
          • Ensure that the POSTGRES_PASSWORD and other sensitive credentials are securely managed, especially in production deployments.
          © 2024 OSRD contributors. All Rights Reserved
          \ No newline at end of file +

          This command builds the images and starts the services defined in the Docker Compose file.

          Accessing Services

          While all HTTP service are used through the gateway (http://localhost:4000), you can access directly each service using their exposed ports:

          • PostgreSQL: Accessible on localhost:5432.
          • Valkey: Accessible on localhost:6379.
          • Core Service: Accessible on localhost:8080.
          • Front-End: Accessible on localhost:3000.
          • Editoast: Accessible on localhost:8090.

          Notes and Considerations

          • This setup is designed for development and quick deployments. For production environments, additional considerations for security, scalability and reliability should be addressed.
          • Ensure that the POSTGRES_PASSWORD and other sensitive credentials are securely managed, especially in production deployments.
          \ No newline at end of file diff --git a/en/docs/guides/deploy/docker-compose/index.html b/en/docs/guides/deploy/docker-compose/index.html index a34b74acb..dee2129e8 100644 --- a/en/docs/guides/deploy/docker-compose/index.html +++ b/en/docs/guides/deploy/docker-compose/index.html @@ -1,5 +1,5 @@ Docker Compose | OSRD -

          This command builds the images and starts the services defined in the Docker Compose file.

          Accessing Services

          While all HTTP service are used through the gateway (http://localhost:4000), you can access directly each service using their exposed ports:

          • PostgreSQL: Accessible on localhost:5432.
          • Valkey: Accessible on localhost:6379.
          • Core Service: Accessible on localhost:8080.
          • Front-End: Accessible on localhost:3000.
          • Editoast: Accessible on localhost:8090.

          Notes and Considerations

          • This setup is designed for development and quick deployments. For production environments, additional considerations for security, scalability and reliability should be addressed.
          • Ensure that the POSTGRES_PASSWORD and other sensitive credentials are securely managed, especially in production deployments.
          \ No newline at end of file diff --git a/en/docs/guides/deploy/index.html b/en/docs/guides/deploy/index.html index 72f25f7b7..9f8759b50 100644 --- a/en/docs/guides/deploy/index.html +++ b/en/docs/guides/deploy/index.html @@ -1,5 +1,5 @@ Deploy OSRD | OSRD -
          \ No newline at end of file diff --git a/en/docs/guides/deploy/kubernetes/_print/index.html b/en/docs/guides/deploy/kubernetes/_print/index.html index cda0c5057..16f9e9f54 100644 --- a/en/docs/guides/deploy/kubernetes/_print/index.html +++ b/en/docs/guides/deploy/kubernetes/_print/index.html @@ -1,5 +1,5 @@ Kubernetes with Helm | OSRD -

          This is the multi-page printable view of this section. +

          This is the multi-page printable view of this section. Click here to print.

          Return to the regular view of this page.

          Kubernetes with Helm

          Using Helm for Kubernetes deployments

            The OSRD project’s Helm Chart provides a flexible and efficient way to deploy OSRD services in a Kubernetes environment. This document outlines the configuration options available in the Helm Chart, focusing on each service component.

            Prerequisites

            Before proceeding with the deployment, ensure that you have the following installed:

            • A Kubernetes cluster up and running
            • A PostgreSQL database with PostGIS
            • A Valkey server (used for caching)

            The tileserver

            Tileserver is the component responsible for generating vector map tiles. It is recommended to separate it from standard Editoast while running a production setup since Editoast cannot be scaled horizontally (it is stateful).

            You can visualize the recommended deployment here:

            flowchart TD
     gw["gateway"]
     front["front-end static files"]
@@ -11,4 +11,4 @@
     gw -- HTTP --> tileserver-2
     gw -- HTTP --> tileserver-n...
     editoast -- HTTP --> core

            The Helm chart leverages Kubernete’s HorizontalPodAutoscaler in order to spawn as much tileserver as required for the current workload.

            Chart Values Overview

            The Helm Chart is configurable through the following values:

            Core Service

            • core: Configuration for the core OSRD service.
              • internalUrl: Internal URL for service communication.
              • image: Docker image to use.
              • pullPolicy: Image pull policy.
              • replicaCount: Number of replicas.
              • service: Service type and port configuration.
              • resources, env, annotations, labels, nodeSelector, tolerations, affinity: Various Kubernetes deployment options.

            Editoast Service

            • editoast: Configuration for the Editoast service.
              • Includes similar options as core for Kubernetes deployment.
              • init: Initialization configuration.

            Tile Server

            • tileServer: Specialized Editoast service that serves only vector map tiles.
              • enabled: Set to true to enable tile server functionality.
              • image: Docker image to use (typically the same as Editoast).
              • replicaCount: Number of replicas, allowing for horizontal scaling.
              • hpa: Horizontal Pod Autoscaler configuration.
              • Other standard Kubernetes deployment options.

            Gateway

            • gateway: Configuration for the OSRD gateway.
              • Includes service, ingress, and other Kubernetes deployment options.
              • config: Specific configurations for authentication and trusted proxies.

            Deployment

            The chart is available at ghcr OCI repository. You can find 2 Helm charts:

            • Stable charts: oci://ghcr.io/OpenRailAssociation/charts/osrd
            • Dev charts: oci://ghcr.io/OpenRailAssociation/charts/osrd-dev

            To deploy the OSRD services using this Helm Chart:

            1. Configure Values: Adjust the values in the Helm Chart to suit your deployment needs.

            2. Install Chart: Use Helm to install the chart into your Kubernetes cluster.

              helm install osrd oci://ghcr.io/OpenRailAssociation/charts/osrd -f values.yml
-
            © 2024 OSRD contributors. All Rights Reserved
            \ No newline at end of file +
            \ No newline at end of file diff --git a/en/docs/guides/deploy/kubernetes/index.html b/en/docs/guides/deploy/kubernetes/index.html index 03ca51eb7..6d77f43ce 100644 --- a/en/docs/guides/deploy/kubernetes/index.html +++ b/en/docs/guides/deploy/kubernetes/index.html @@ -1,5 +1,5 @@ Kubernetes with Helm | OSRD -
            \ No newline at end of file diff --git a/en/docs/guides/deploy/stdcm-search-env/index.html b/en/docs/guides/deploy/stdcm-search-env/index.html index bf94a220a..02058e6ce 100644 --- a/en/docs/guides/deploy/stdcm-search-env/index.html +++ b/en/docs/guides/deploy/stdcm-search-env/index.html @@ -1,5 +1,5 @@ STDCM search environment configuration | OSRD -
            \ No newline at end of file diff --git a/en/docs/guides/design/index.html b/en/docs/guides/design/index.html index f08842212..f10ef357c 100644 --- a/en/docs/guides/design/index.html +++ b/en/docs/guides/design/index.html @@ -1,5 +1,5 @@ OSRD's design | OSRD -

            OSRD's design

            Colours, fonts, uses…

            Everything is presented on a dedicated website https://design.osrd.fr

            A “design system” is being developed.

            © 2025 OSRD contributors. All Rights Reserved
            \ No newline at end of file diff --git a/en/docs/guides/index.html b/en/docs/guides/index.html index a63b65544..6f99b343f 100644 --- a/en/docs/guides/index.html +++ b/en/docs/guides/index.html @@ -1,5 +1,5 @@ How-to Guides | OSRD -

            How-to Guides

            Recipes for addressing key problems and use-cases

            How-to guides are recipes. They guide you through the steps involved in addressing key problems and use-cases. They are more advanced than tutorials and assume some knowledge of how OSRD works.

            Contribute to OSRD

            Learn about the how we work, and how you can work with us

            Deploy OSRD

            Learn how to deploy OSRD in various environments

            Logo

            The OSRD logo, its variants, and its use

            OSRD's design

            Colours, fonts, uses…

            Release

            Release section

            © 2025 OSRD contributors. All Rights Reserved
            \ No newline at end of file diff --git a/en/docs/guides/index.xml b/en/docs/guides/index.xml index 767eb1b25..78648fd79 100644 --- a/en/docs/guides/index.xml +++ b/en/docs/guides/index.xml @@ -104,65 +104,4 @@ See the <a href="https://osrd.fr/en/docs/guides/deploy/stdcm-search-env/">ded <figure><a href="https://design.osrd.fr"> <img src="https://osrd.fr/en/docs/guides/design/images/design.webp"/> </a> </figure>Docs: Releasehttps://osrd.fr/en/docs/guides/release/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/release/ -<p>All OSRD releases are accessible <a href="https://github.com/OpenRailAssociation/osrd/releases">here</a></p> -<p>The process for creating a new release is as follows:</p> -<ol> -<li>We always release on a tested version of the application (staging branch) -<ul> -<li><code>git switch staging &amp;&amp; git pull</code></li> -</ul> -</li> -<li>Create a git <strong>annotated</strong> tag -<ul> -<li>We are using the <a href="https://semver.org/">semantic versioning</a></li> -<li><code>git tag -a vx.y.z</code> with the message <code>Release x.y.z</code> (most of the time use the latest version and increment the patch version)</li> -<li><code>git push --tags</code></li> -</ul> -</li> -<li>Create a github release -<ul> -<li>Draft a new github release <a href="https://github.com/OpenRailAssociation/osrd/releases/new">here</a></li> -<li>Select the created tag</li> -<li>Generate the releases notes</li> -<li>Rename the release like so: &ldquo;Version x.y.z&rdquo;</li> -<li>Check the &ldquo;Set as a pre-release&rdquo; box</li> -<li>Apply the <a href="#Changelog format">changelog format</a></li> -<li>Then you can <strong>publish</strong> the release or <strong>save</strong> the draft if you want to come back later</li> -</ul> -</li> -<li>A <a href="https://github.com/OpenRailAssociation/osrd/actions/workflows/release.yml">github action</a> should be triggered automatically.</li> -<li>Post the link of the created release on matrix. Suggest that the developers review the release.</li> -</ol> -<h3 id="changelog-format">Changelog format</h3> -<ol> -<li>Use the following structure:</li> -</ol> -<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-md" data-lang="md"><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## What&#39;s Changed -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Features :tada: -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span> -</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Code refactoring :recycle: -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span> -</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Bug fixes :bug: -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span> -</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## New Contributors -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> -</span></span><span style="display:flex;"><span>... -</span></span><span style="display:flex;"><span> -</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> -</span></span><span style="display:flex;"><span><span style="color:#000;font-weight:bold">**Full Changelog**</span>: ... -</span></span></code></pre></div><ol start="2"> -<li>Partition the different pull requests</li> -<li>Merge or group PR when it make sense. Examples: -<ul> -<li>Bump of dependencies PR (merge)</li> -<li>Multi part PR (merge)</li> -<li>One big feature implemented by multiple PR (group)</li> -</ul> -</li> -<li>Reword PR title. <strong>It should be comprehensible to an external collaborator</strong></li> -</ol> \ No newline at end of file +<p>This section documents the process around creating a release of OSRD.</p> \ No newline at end of file diff --git a/en/docs/guides/logo/index.html b/en/docs/guides/logo/index.html index 75a660e8e..20b58e6ee 100644 --- a/en/docs/guides/logo/index.html +++ b/en/docs/guides/logo/index.html @@ -1,5 +1,5 @@ Logo | OSRD -
            \ No newline at end of file diff --git a/en/docs/guides/release/_print/index.html b/en/docs/guides/release/_print/index.html new file mode 100644 index 000000000..a9ee82a4e --- /dev/null +++ b/en/docs/guides/release/_print/index.html @@ -0,0 +1,37 @@ +Release | OSRD +

            This is the multi-page printable view of this section. +Click here to print.

            Return to the regular view of this page.

            Release

            Release section

            This section documents the process around creating a release of OSRD.

            1 - Release process

            Here’s how OSRD is currently released

            OSRD has three versions: development (dev), staging, and release.

            The development version is the most recent and unstable version of the application, containing the latest features and bug fixes in active development.

            Staging versions are created every Thursday at 12pm by tagging the current development state.

            If a staging version passes validation testing, it is promoted to become the latest release version. This ensures that only stable, tested code makes it into production releases.

            The release process follows this workflow:

            1. Ongoing development in the dev branch
            2. Weekly staging tags on Thursdays at 12pm
            3. Validation testing of staging version
            4. Promotion of validated staging builds to release status
                Development         Staging                   Release
+    (unstable)         (testing)                 (stable)
+
+    [Dev Branch]                                    |
+         |                                          |
+         |--->     Thursday 12pm                    |
+         |         [Staging Tag]                    |
+         |                |                         |
+         |            Validation                    |
+         |             Testing                      |
+         |                |                         |
+         |                o---> If Passes -->  [New Release]
+         |                       Tests              |
+    [Continue Dev]                                  |
+         |                                          |
+         V                                          V
+

            2 - Publish a new release

            How to publish a new release

            All OSRD releases are accessible here

            The process for creating a new release is as follows:

            1. We always release on a tested version of the application (staging branch)
              • git switch staging && git pull
            2. Create a git annotated tag
              • We are using the semantic versioning
              • git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version)
              • git push --tags
            3. Create a github release
              • Draft a new github release here
              • Select the created tag
              • Generate the releases notes
              • Rename the release like so: “Version x.y.z”
              • Check the “Set as a pre-release” box
              • Apply the changelog format
              • Then you can publish the release or save the draft if you want to come back later
            4. A github action should be triggered automatically.
            5. Post the link of the created release on matrix. Suggest that the developers review the release.

            Changelog format

            1. Use the following structure:
            ## What's Changed
+
+### Features :tada:
+
+
+### Code refactoring :recycle:
+
+
+### Bug fixes :bug:
+
+
+## New Contributors
+
+<!-- Copy from the generated release notes -->
+...
+
+<!-- Copy from the generated release notes -->
+**Full Changelog**: ...
+
            1. Partition the different pull requests
            2. Merge or group PR when it make sense. Examples:
              • Bump of dependencies PR (merge)
              • Multi part PR (merge)
              • One big feature implemented by multiple PR (group)
            3. Reword PR title. It should be comprehensible to an external collaborator
            © 2025 OSRD contributors. All Rights Reserved
            \ No newline at end of file diff --git a/en/docs/guides/release/index.html b/en/docs/guides/release/index.html index a8eca2025..debcf8463 100644 --- a/en/docs/guides/release/index.html +++ b/en/docs/guides/release/index.html @@ -1,5 +1,5 @@ -Release | OSRD -

            Release

            How to make a release

            All OSRD releases are accessible here

            The process for creating a new release is as follows:

            1. We always release on a tested version of the application (staging branch)
              • git switch staging && git pull
            2. Create a git annotated tag
              • We are using the semantic versioning
              • git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version)
              • git push --tags
            3. Create a github release
              • Draft a new github release here
              • Select the created tag
              • Generate the releases notes
              • Rename the release like so: “Version x.y.z”
              • Check the “Set as a pre-release” box
              • Apply the changelog format
              • Then you can publish the release or save the draft if you want to come back later
            4. A github action should be triggered automatically.
            5. Post the link of the created release on matrix. Suggest that the developers review the release.

            Changelog format

            1. Use the following structure:
            ## What's Changed
-
-### Features :tada:
-
-
-### Code refactoring :recycle:
-
-
-### Bug fixes :bug:
-
-
-## New Contributors
-
-<!-- Copy from the generated release notes -->
-...
-
-<!-- Copy from the generated release notes -->
-**Full Changelog**: ...
-
            1. Partition the different pull requests
            2. Merge or group PR when it make sense. Examples:
              • Bump of dependencies PR (merge)
              • Multi part PR (merge)
              • One big feature implemented by multiple PR (group)
            3. Reword PR title. It should be comprehensible to an external collaborator
            © 2024 OSRD contributors. All Rights Reserved
            \ No newline at end of file + Print entire section

            Release

            Release section

            This section documents the process around creating a release of OSRD.

            Release process

            Here’s how OSRD is currently released

            Publish a new release

            How to publish a new release

            \ No newline at end of file diff --git a/en/docs/guides/release/index.xml b/en/docs/guides/release/index.xml new file mode 100644 index 000000000..74030368a --- /dev/null +++ b/en/docs/guides/release/index.xml @@ -0,0 +1,90 @@ +OSRD – Releasehttps://osrd.fr/en/docs/guides/release/Recent content in Release on OSRDHugo -- gohugo.ioenDocs: Release processhttps://osrd.fr/en/docs/guides/release/process/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/release/process/ +<p>OSRD has three versions: development (dev), staging, and release.</p> +<p>The development version is the most recent and unstable version of the application, containing the latest features and bug fixes in active development.</p> +<p>Staging versions are created every Thursday at 12pm by tagging the current development state.</p> +<p>If a staging version passes validation testing, it is promoted to become the latest release version. This ensures that only stable, tested code makes it into production releases.</p> +<p>The release process follows this workflow:</p> +<ol> +<li>Ongoing development in the dev branch</li> +<li>Weekly staging tags on Thursdays at 12pm</li> +<li>Validation testing of staging version</li> +<li>Promotion of validated staging builds to release status</li> +</ol> +<pre tabindex="0"><code class="language-ascii" data-lang="ascii"> Development Staging Release +(unstable) (testing) (stable) +[Dev Branch] | +| | +|---&gt; Thursday 12pm | +| [Staging Tag] | +| | | +| Validation | +| Testing | +| | | +| o---&gt; If Passes --&gt; [New Release] +| Tests | +[Continue Dev] | +| | +V V +</code></pre>Docs: Publish a new releasehttps://osrd.fr/en/docs/guides/release/publish/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/release/publish/ +<p>All OSRD releases are accessible <a href="https://github.com/OpenRailAssociation/osrd/releases">here</a></p> +<p>The process for creating a new release is as follows:</p> +<ol> +<li>We always release on a tested version of the application (staging branch) +<ul> +<li><code>git switch staging &amp;&amp; git pull</code></li> +</ul> +</li> +<li>Create a git <strong>annotated</strong> tag +<ul> +<li>We are using the <a href="https://semver.org/">semantic versioning</a></li> +<li><code>git tag -a vx.y.z</code> with the message <code>Release x.y.z</code> (most of the time use the latest version and increment the patch version)</li> +<li><code>git push --tags</code></li> +</ul> +</li> +<li>Create a github release +<ul> +<li>Draft a new github release <a href="https://github.com/OpenRailAssociation/osrd/releases/new">here</a></li> +<li>Select the created tag</li> +<li>Generate the releases notes</li> +<li>Rename the release like so: &ldquo;Version x.y.z&rdquo;</li> +<li>Check the &ldquo;Set as a pre-release&rdquo; box</li> +<li>Apply the <a href="#Changelog format">changelog format</a></li> +<li>Then you can <strong>publish</strong> the release or <strong>save</strong> the draft if you want to come back later</li> +</ul> +</li> +<li>A <a href="https://github.com/OpenRailAssociation/osrd/actions/workflows/release.yml">github action</a> should be triggered automatically.</li> +<li>Post the link of the created release on matrix. Suggest that the developers review the release.</li> +</ol> +<h3 id="changelog-format">Changelog format</h3> +<ol> +<li>Use the following structure:</li> +</ol> +<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-md" data-lang="md"><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## What&#39;s Changed +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Features :tada: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Code refactoring :recycle: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Bug fixes :bug: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## New Contributors +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> +</span></span><span style="display:flex;"><span>... +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> +</span></span><span style="display:flex;"><span><span style="color:#000;font-weight:bold">**Full Changelog**</span>: ... +</span></span></code></pre></div><ol start="2"> +<li>Partition the different pull requests</li> +<li>Merge or group PR when it make sense. Examples: +<ul> +<li>Bump of dependencies PR (merge)</li> +<li>Multi part PR (merge)</li> +<li>One big feature implemented by multiple PR (group)</li> +</ul> +</li> +<li>Reword PR title. <strong>It should be comprehensible to an external collaborator</strong></li> +</ol> \ No newline at end of file diff --git a/en/docs/guides/release/process/index.html b/en/docs/guides/release/process/index.html new file mode 100644 index 000000000..5252ab722 --- /dev/null +++ b/en/docs/guides/release/process/index.html @@ -0,0 +1,95 @@ +Release process | OSRD +

            Release process

            Here’s how OSRD is currently released

            OSRD has three versions: development (dev), staging, and release.

            The development version is the most recent and unstable version of the application, containing the latest features and bug fixes in active development.

            Staging versions are created every Thursday at 12pm by tagging the current development state.

            If a staging version passes validation testing, it is promoted to become the latest release version. This ensures that only stable, tested code makes it into production releases.

            The release process follows this workflow:

            1. Ongoing development in the dev branch
            2. Weekly staging tags on Thursdays at 12pm
            3. Validation testing of staging version
            4. Promotion of validated staging builds to release status
                Development         Staging                   Release
+    (unstable)         (testing)                 (stable)
+
+    [Dev Branch]                                    |
+         |                                          |
+         |--->     Thursday 12pm                    |
+         |         [Staging Tag]                    |
+         |                |                         |
+         |            Validation                    |
+         |             Testing                      |
+         |                |                         |
+         |                o---> If Passes -->  [New Release]
+         |                       Tests              |
+    [Continue Dev]                                  |
+         |                                          |
+         V                                          V
+
            © 2025 OSRD contributors. All Rights Reserved
            \ No newline at end of file diff --git a/en/docs/guides/release/publish/index.html b/en/docs/guides/release/publish/index.html new file mode 100644 index 000000000..352eb38ff --- /dev/null +++ b/en/docs/guides/release/publish/index.html @@ -0,0 +1,97 @@ +Publish a new release | OSRD +

            Publish a new release

            How to publish a new release

            All OSRD releases are accessible here

            The process for creating a new release is as follows:

            1. We always release on a tested version of the application (staging branch)
              • git switch staging && git pull
            2. Create a git annotated tag
              • We are using the semantic versioning
              • git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version)
              • git push --tags
            3. Create a github release
              • Draft a new github release here
              • Select the created tag
              • Generate the releases notes
              • Rename the release like so: “Version x.y.z”
              • Check the “Set as a pre-release” box
              • Apply the changelog format
              • Then you can publish the release or save the draft if you want to come back later
            4. A github action should be triggered automatically.
            5. Post the link of the created release on matrix. Suggest that the developers review the release.

            Changelog format

            1. Use the following structure:
            ## What's Changed
+
+### Features :tada:
+
+
+### Code refactoring :recycle:
+
+
+### Bug fixes :bug:
+
+
+## New Contributors
+
+<!-- Copy from the generated release notes -->
+...
+
+<!-- Copy from the generated release notes -->
+**Full Changelog**: ...
+
            1. Partition the different pull requests
            2. Merge or group PR when it make sense. Examples:
              • Bump of dependencies PR (merge)
              • Multi part PR (merge)
              • One big feature implemented by multiple PR (group)
            3. Reword PR title. It should be comprehensible to an external collaborator
            © 2025 OSRD contributors. All Rights Reserved
            \ No newline at end of file diff --git a/en/docs/index.html b/en/docs/index.html index c65453b52..a3327b7e6 100644 --- a/en/docs/index.html +++ b/en/docs/index.html @@ -1,5 +1,5 @@ Documentation | OSRD -

            Documentation

            Whether you would like to use OSRD, understand it or contribute, this is the right place!

            Explanations

            Learn more about key concepts

            How-to Guides

            Recipes for addressing key problems and use-cases

            Technical reference

            Internal machinery and APIs

            Railway Wiki

            International railway wiki

            © 2025 OSRD contributors. All Rights Reserved
            \ No newline at end of file diff --git a/en/docs/index.xml b/en/docs/index.xml index f213d41e3..f2a7cb57a 100644 --- a/en/docs/index.xml +++ b/en/docs/index.xml @@ -34,7 +34,34 @@ Before making changes, it is best to learn about what&rsquo;s already there: <li>read the existing source code related to your project</li> <li>chat with developers who last worked on areas you are interested in</li> </ul> -<p><em><a href="https://osrd.fr/en/docs/guides/contribute/license-and-set-up/">Continue towards initial set-up ‣</a></em></p>Docs: Back-end conventionshttps://osrd.fr/en/docs/guides/contribute/contribute-code/backend-conventions/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/contribute/contribute-code/backend-conventions/ +<p><em><a href="https://osrd.fr/en/docs/guides/contribute/license-and-set-up/">Continue towards initial set-up ‣</a></em></p>Docs: Release processhttps://osrd.fr/en/docs/guides/release/process/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/release/process/ +<p>OSRD has three versions: development (dev), staging, and release.</p> +<p>The development version is the most recent and unstable version of the application, containing the latest features and bug fixes in active development.</p> +<p>Staging versions are created every Thursday at 12pm by tagging the current development state.</p> +<p>If a staging version passes validation testing, it is promoted to become the latest release version. This ensures that only stable, tested code makes it into production releases.</p> +<p>The release process follows this workflow:</p> +<ol> +<li>Ongoing development in the dev branch</li> +<li>Weekly staging tags on Thursdays at 12pm</li> +<li>Validation testing of staging version</li> +<li>Promotion of validated staging builds to release status</li> +</ol> +<pre tabindex="0"><code class="language-ascii" data-lang="ascii"> Development Staging Release +(unstable) (testing) (stable) +[Dev Branch] | +| | +|---&gt; Thursday 12pm | +| [Staging Tag] | +| | | +| Validation | +| Testing | +| | | +| o---&gt; If Passes --&gt; [New Release] +| Tests | +[Continue Dev] | +| | +V V +</code></pre>Docs: Back-end conventionshttps://osrd.fr/en/docs/guides/contribute/contribute-code/backend-conventions/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/contribute/contribute-code/backend-conventions/ <h1 id="python">Python</h1> <p>Python code is used for some packages and integration testing.</p> <ul> @@ -344,7 +371,69 @@ Most OSRD developers use Linux (incl. <a href="https://learn.microsoft.com/en <p>Under Windows, open <code>Git Bash</code>&#160;<a href="#fnref:2" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p> </li> </ol> -</div>Docs: Write codehttps://osrd.fr/en/docs/guides/contribute/contribute-code/write-code/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/contribute/contribute-code/write-code/ +</div>Docs: Publish a new releasehttps://osrd.fr/en/docs/guides/release/publish/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/release/publish/ +<p>All OSRD releases are accessible <a href="https://github.com/OpenRailAssociation/osrd/releases">here</a></p> +<p>The process for creating a new release is as follows:</p> +<ol> +<li>We always release on a tested version of the application (staging branch) +<ul> +<li><code>git switch staging &amp;&amp; git pull</code></li> +</ul> +</li> +<li>Create a git <strong>annotated</strong> tag +<ul> +<li>We are using the <a href="https://semver.org/">semantic versioning</a></li> +<li><code>git tag -a vx.y.z</code> with the message <code>Release x.y.z</code> (most of the time use the latest version and increment the patch version)</li> +<li><code>git push --tags</code></li> +</ul> +</li> +<li>Create a github release +<ul> +<li>Draft a new github release <a href="https://github.com/OpenRailAssociation/osrd/releases/new">here</a></li> +<li>Select the created tag</li> +<li>Generate the releases notes</li> +<li>Rename the release like so: &ldquo;Version x.y.z&rdquo;</li> +<li>Check the &ldquo;Set as a pre-release&rdquo; box</li> +<li>Apply the <a href="#Changelog format">changelog format</a></li> +<li>Then you can <strong>publish</strong> the release or <strong>save</strong> the draft if you want to come back later</li> +</ul> +</li> +<li>A <a href="https://github.com/OpenRailAssociation/osrd/actions/workflows/release.yml">github action</a> should be triggered automatically.</li> +<li>Post the link of the created release on matrix. Suggest that the developers review the release.</li> +</ol> +<h3 id="changelog-format">Changelog format</h3> +<ol> +<li>Use the following structure:</li> +</ol> +<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-md" data-lang="md"><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## What&#39;s Changed +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Features :tada: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Code refactoring :recycle: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Bug fixes :bug: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## New Contributors +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> +</span></span><span style="display:flex;"><span>... +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> +</span></span><span style="display:flex;"><span><span style="color:#000;font-weight:bold">**Full Changelog**</span>: ... +</span></span></code></pre></div><ol start="2"> +<li>Partition the different pull requests</li> +<li>Merge or group PR when it make sense. Examples: +<ul> +<li>Bump of dependencies PR (merge)</li> +<li>Multi part PR (merge)</li> +<li>One big feature implemented by multiple PR (group)</li> +</ul> +</li> +<li>Reword PR title. <strong>It should be comprehensible to an external collaborator</strong></li> +</ol>Docs: Write codehttps://osrd.fr/en/docs/guides/contribute/contribute-code/write-code/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/contribute/contribute-code/write-code/ <ol> <li> <p>If you are not used to Git, <a href="https://learngitbranching.js.org/">follow this tutorial</a></p> @@ -1578,69 +1667,7 @@ The algorithm is described in detail in the <a href="https://osrd.fr/en/docs/ <h2 id="design-limits">Design limits</h2> <ul> <li>trains do not anticipate margin transitions: only the next target arrival time matters for finding the slowdown factor</li> -</ul>Docs: Releasehttps://osrd.fr/en/docs/guides/release/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/guides/release/ -<p>All OSRD releases are accessible <a href="https://github.com/OpenRailAssociation/osrd/releases">here</a></p> -<p>The process for creating a new release is as follows:</p> -<ol> -<li>We always release on a tested version of the application (staging branch) -<ul> -<li><code>git switch staging &amp;&amp; git pull</code></li> -</ul> -</li> -<li>Create a git <strong>annotated</strong> tag -<ul> -<li>We are using the <a href="https://semver.org/">semantic versioning</a></li> -<li><code>git tag -a vx.y.z</code> with the message <code>Release x.y.z</code> (most of the time use the latest version and increment the patch version)</li> -<li><code>git push --tags</code></li> -</ul> -</li> -<li>Create a github release -<ul> -<li>Draft a new github release <a href="https://github.com/OpenRailAssociation/osrd/releases/new">here</a></li> -<li>Select the created tag</li> -<li>Generate the releases notes</li> -<li>Rename the release like so: &ldquo;Version x.y.z&rdquo;</li> -<li>Check the &ldquo;Set as a pre-release&rdquo; box</li> -<li>Apply the <a href="#Changelog format">changelog format</a></li> -<li>Then you can <strong>publish</strong> the release or <strong>save</strong> the draft if you want to come back later</li> -</ul> -</li> -<li>A <a href="https://github.com/OpenRailAssociation/osrd/actions/workflows/release.yml">github action</a> should be triggered automatically.</li> -<li>Post the link of the created release on matrix. Suggest that the developers review the release.</li> -</ol> -<h3 id="changelog-format">Changelog format</h3> -<ol> -<li>Use the following structure:</li> -</ol> -<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-md" data-lang="md"><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## What&#39;s Changed -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Features :tada: -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span> -</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Code refactoring :recycle: -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span> -</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Bug fixes :bug: -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span> -</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## New Contributors -</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> -</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> -</span></span><span style="display:flex;"><span>... -</span></span><span style="display:flex;"><span> -</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> -</span></span><span style="display:flex;"><span><span style="color:#000;font-weight:bold">**Full Changelog**</span>: ... -</span></span></code></pre></div><ol start="2"> -<li>Partition the different pull requests</li> -<li>Merge or group PR when it make sense. Examples: -<ul> -<li>Bump of dependencies PR (merge)</li> -<li>Multi part PR (merge)</li> -<li>One big feature implemented by multiple PR (group)</li> -</ul> -</li> -<li>Reword PR title. <strong>It should be comprehensible to an external collaborator</strong></li> -</ol>Docs: Signaling systemshttps://osrd.fr/en/docs/reference/design-docs/signaling/signaling-systems/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/reference/design-docs/signaling/signaling-systems/ +</ul>Docs: Signaling systemshttps://osrd.fr/en/docs/reference/design-docs/signaling/signaling-systems/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/reference/design-docs/signaling/signaling-systems/ <p>Each signaling system has:</p> <ul> <li>A unique identifier (a string).</li> @@ -2687,7 +2714,7 @@ Meanwhile, to simulate train behavior, we figured out that we need to know which <li>either treat each type of constraint as its own thing during the simulation</li> <li>abstract away constraints into a common representation, and then simulate that</li> </ul> -<h4 id="hahahugoshortcode182s1hbhb-distinct-constraint-types">❌ +<h4 id="hahahugoshortcode184s1hbhb-distinct-constraint-types">❌ Distinct constraint types</h4> <p>When we first started drafting architecture diagrams, the train simulation API directly took a bunch of constraint types as an input. It brought up a number of issues:</p> @@ -2697,7 +2724,7 @@ a bunch of constraint types as an input. It brought up a number of issues:</p <li>when simulating, it does not seem to matter why a constraint is there, only what to do about it</li> </ul> <p>We couldn&rsquo;t find clear benefits to dragging distinctions between constraint types deep into the implementation.</p> -<h4 id="hahahugoshortcode182s2hbhb-internal-constraint-types-abstraction">❌ +<h4 id="hahahugoshortcode184s2hbhb-internal-constraint-types-abstraction">❌ Internal constraint types abstraction</h4> <p>We then realized that abstracting over constraint types during simulation had immense benefits:</p> <ul> @@ -2712,7 +2739,7 @@ but lowering these constraints into an intermediary representation internally. W <li>the public simulation API would still bear the complexity of dealing with many constraint types</li> <li>there would be a need to incrementally generate internal abstracted constraints to support the incremental API</li> </ul> -<h4 id="hahahugoshortcode182s3hbhb-external-constraint-types-abstraction">✅ +<h4 id="hahahugoshortcode184s3hbhb-external-constraint-types-abstraction">✅ External constraint types abstraction</h4> <p>We tried to improve over the previous proposal by moving the burden of converting many constraints into a common abstraction out of the simulation API.</p> <p>Instead of having many constraint types as an input, the simulation API takes a collection of a single abstract constraint type. The task of converting @@ -2801,7 +2828,7 @@ adding some kind of priority / rank field, which was adopted</li> <li>once in the speed limit</li> </ul> <p>There are multiple ways this issue can be dealt with:</p> -<h4 id="hahahugoshortcode156s0hbhb-mandatory-speed-limit-value-in-the-speed-section">✅ +<h4 id="hahahugoshortcode162s0hbhb-mandatory-speed-limit-value-in-the-speed-section">✅ Mandatory speed limit value in the speed section</h4> <p>Upsides:</p> <ul> @@ -2812,11 +2839,11 @@ Mandatory speed limit value in the speed section</h4> <li>more work on the side of users</li> <li>room for inconsistencies between the speed limit announced by signaling, and the effective speed limit</li> </ul> -<h4 id="hahahugoshortcode156s1hbhb-deduce-the-signal-constraint-from-the-speed-limit">❌ +<h4 id="hahahugoshortcode162s1hbhb-deduce-the-signal-constraint-from-the-speed-limit">❌ Deduce the signal constraint from the speed limit</h4> <p>This option was not explored much, as it was deemed awkward to deduce signal parameters from a speed limit value.</p> -<h4 id="hahahugoshortcode156s2hbhb-deduce-the-speed-limit-from-the-signal">❌ +<h4 id="hahahugoshortcode162s2hbhb-deduce-the-speed-limit-from-the-signal">❌ Deduce the speed limit from the signal</h4> <p>Make the speed limit value optional, and deduce it from the signal itself. Speed limits per tag also have to be deduced if missing.</p> @@ -2835,14 +2862,14 @@ Speed limits per tag also have to be deduced if missing.</p> which is distinct from the signal which announces the speed limit.</p> <p>To allow for correct train reactions to this kind of limits, a link between the announce signal and the speed limit section has to be made at some point.</p> -<h4 id="hahahugoshortcode156s3hbhb-automated-matching-of-signals-and-speed-sections">❌ +<h4 id="hahahugoshortcode162s3hbhb-automated-matching-of-signals-and-speed-sections">❌ Automated matching of signals and speed sections</h4> <p>Was not deemed realistic.</p> -<h4 id="hahahugoshortcode156s4hbhb-explicit-link-from-route-to-speed-limit-and-signals">❌ +<h4 id="hahahugoshortcode162s4hbhb-explicit-link-from-route-to-speed-limit-and-signals">❌ Explicit link from route to speed limit and signals</h4> <p>Was deemed to be awkward, as signaling is currently built over interlocking. Referencing signaling from interlocking creates a circular dependency between the two schemas.</p> -<h4 id="hahahugoshortcode156s5hbhb-explicit-link-from-speed-limit-to-signals">❌ +<h4 id="hahahugoshortcode162s5hbhb-explicit-link-from-speed-limit-to-signals">❌ Explicit link from speed limit to signals</h4> <p>Add a list of <code>(route, signal)</code> tuples to speed sections.</p> <p>Upside:</p> @@ -2854,7 +2881,7 @@ Explicit link from speed limit to signals</h4> <li>Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.</li> <li>Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.</li> </ul> -<h4 id="hahahugoshortcode156s6hbhb-inlining-speed-limit-definitions-into-signals">❌ +<h4 id="hahahugoshortcode162s6hbhb-inlining-speed-limit-definitions-into-signals">❌ Inlining speed limit definitions into signals</h4> <p>Introduces a new type of speed limit, which are announced by signals. These speed limits are directly defined within signal definitions.</p> @@ -2889,7 +2916,7 @@ These speed limits are directly defined within signal definitions.</p> <li>speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)</li> <li>the cost of reversing this decision could be fairly high</li> </ul> -<h4 id="hahahugoshortcode156s7hbhb-explicit-link-from-signal-to-speed-section">✅ +<h4 id="hahahugoshortcode162s7hbhb-explicit-link-from-signal-to-speed-section">✅ Explicit link from signal to speed section</h4> <div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-yaml" data-lang="yaml"><span style="display:flex;"><span>{<span style="color:#f8f8f8;text-decoration:underline"> </span></span></span><span style="display:flex;"><span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#8f5902;font-style:italic"># ...</span><span style="color:#f8f8f8;text-decoration:underline"> @@ -3172,7 +3199,7 @@ and relieves DBM from the responsibility of finding the most restrictive instruc </ol> <p>We decided that only the first option was desirable.</p> <p>The design choices then are:</p> -<h5 id="hahahugoshortcode180s3hbhb-make-the-dbm-as-close-as-possible-to-a-decision-function">❌ +<h5 id="hahahugoshortcode182s3hbhb-make-the-dbm-as-close-as-possible-to-a-decision-function">❌ Make the DBM as close as possible to a decision function</h5> <p>Then the DBM would not be aware of the time step it is called with, and would return an acceleration. Then the module should expose two methods:</p> <ul> @@ -3186,7 +3213,7 @@ Called several times depending on the integration method.</p> Called on the integration step results from this DBM, and the other DBMs integration step results.</p> </li> </ul> -<h5 id="hahahugoshortcode180s4hbhb-the-dbm-returns-a-new-state">✅ +<h5 id="hahahugoshortcode182s4hbhb-the-dbm-returns-a-new-state">✅ The DBM returns a new state</h5> <p>The module would then expose two methods:</p> <ul> @@ -4742,69 +4769,4 @@ This roadmap is spread over a couple of years.</p> <li>Versioning infrastructures.</li> <li>Revamp train simulation v3.</li> </ul> -<p>If you&rsquo;d like to push for one of these features, or if you have ideas for what OSRD could do in the future, don&rsquo;t hesitate to join the project!</p>Docs: ETCShttps://osrd.fr/en/docs/railway-wiki/signalling/spacing/ertms/etcs/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/en/docs/railway-wiki/signalling/spacing/ertms/etcs/ -<h2 id="context">Context</h2> -<p>The onboard computer of ETCS-enabled trains has to compute a number of position / speed curves. -Here is how it works:</p> -<ul> -<li>below all the curves, the speed indicator is white</li> -<li>above the indication curve, the speed indicator is yellow</li> -<li>above the permitted curve, the speed indicator is orange</li> -<li>above the warning curve, an alarm rings</li> -<li>above the intervention curves, an emergency break intervention is triggered</li> -</ul> -<h2 id="inputs">Inputs</h2> -<p>In order to compute any of these curves, a number of things are needed:</p> -<ul> -<li>target data (the destination of the braking curve, which can be EOA and SvL or LOA and MRSP)</li> -<li>train data</li> -<li>infrastructure data</li> -<li>infrastructure manager constants</li> -<li>standardized constants</li> -</ul> -<h3 id="train">Train</h3> -<ul> -<li>max speed</li> -<li>length</li> -<li>rotating mass</li> -<li><code>T_traction_cutoff</code>: the time it take to cut off traction</li> -<li>braking model, either lambda or gamma: -<ul> -<li>lambda (braking weight/mass)</li> -<li>gamma (contant deceleration at a given speed)</li> -</ul> -</li> -<li>correction factors (k_dry and k_wet for gamma braking) for braking curves</li> -</ul> -<h3 id="infrastructure">Infrastructure</h3> -<ul> -<li>corrected gradients (it incorporates curvature)</li> -<li>odometry balises location</li> -</ul> -<h2 id="processes">Processes</h2> -<h3 id="braking-coefficients">Braking coefficients:</h3> -<ul> -<li><code>A_brake_emergency</code> is the expected emergency braking capability, without safety margins</li> -<li><code>A_brake_safe</code> is the emergency braking coefficient, <strong>with</strong> safety margins</li> -<li><code>A_brake_service</code> is the expected service braking capability, without safety margins</li> -</ul> -<h3 id="speed--distance-targets">Speed / distance targets</h3> -<ul> -<li><code>EOA</code> end of movement authority: the location until which the train is allowed to move</li> -<li><code>SvL</code> supervized location: the protected location</li> -</ul> -<h3 id="curves">Curves</h3> -<ul> -<li><code>SBD</code> supervised braking deceleration: intermediary result computed from <code>EOA</code> and <code>A_brake_service</code></li> -<li><code>EBD</code> emergency braking deceleration: intermediary result computed from <code>SvL</code> and <code>A_brake_safe</code></li> -</ul> -<p>All the curves below are cut below a given release speed:</p> -<ul> -<li><code>EBI</code> (emergency break intervention) computed from <code>EBD</code>, shifted in position and space given rolling stock metadata</li> -<li><code>SBI1</code> computed from <code>SBD</code>, shifted in <strong>time</strong> with <code>Tbs1</code></li> -<li><code>SBI2</code> computed from <code>SBD</code>, shifted in <strong>time</strong> with <code>Tbs2</code></li> -<li><code>FLOI</code> (also called <code>SBI</code>, the intervention curve) the minimum of <code>SBI1</code> and <code>SBI2</code></li> -<li><code>WARNING</code> (warning curve) computed as a shift of <code>FLOI</code> by <code>Twarning</code></li> -<li><code>PS</code> (permitted speed curve): shift of <code>WARNING</code> by time <code>Tdriver</code></li> -<li><code>INDICATION</code> is a shift of <code>PS</code> by time <code>Tindication</code></li> -</ul> \ No newline at end of file +<p>If you&rsquo;d like to push for one of these features, or if you have ideas for what OSRD could do in the future, don&rsquo;t hesitate to join the project!</p> \ No newline at end of file diff --git a/en/docs/railway-wiki/_print/index.html b/en/docs/railway-wiki/_print/index.html index c83930dc7..e71ce04eb 100644 --- a/en/docs/railway-wiki/_print/index.html +++ b/en/docs/railway-wiki/_print/index.html @@ -1,3 +1,3 @@ Railway Wiki | OSRD -

            This is the multi-page printable view of this section. -Click here to print.

            Return to the regular view of this page.

            Railway Wiki

            International railway wiki

            This wiki is meant to help software engineers have a deep understanding of railway systems.

            It can only happen if content is added as needed. If something is missing, contribute!

            1 - Glossary

            Glossary of OSRD and railway vocabulary

            Please open an issue if you’re missing a word

            © 2024 OSRD contributors. All Rights Reserved
            \ No newline at end of file +

            This is the multi-page printable view of this section. +Click here to print.

            Return to the regular view of this page.

            Railway Wiki

            International railway wiki

            This wiki is meant to help software engineers have a deep understanding of railway systems.

            It can only happen if content is added as needed. If something is missing, contribute!

            1 - Glossary

            Glossary of OSRD and railway vocabulary

            Please open an issue if you’re missing a word

            © 2025 OSRD contributors. All Rights Reserved
            \ No newline at end of file diff --git a/en/docs/railway-wiki/glossary/_print/index.html b/en/docs/railway-wiki/glossary/_print/index.html index 84055cd3e..c3142bbf1 100644 --- a/en/docs/railway-wiki/glossary/_print/index.html +++ b/en/docs/railway-wiki/glossary/_print/index.html @@ -1,3 +1,3 @@ Glossary | OSRD -

            This is the multi-page printable view of this section. -Click here to print.

            Return to the regular view of this page.

            Glossary

            Glossary of OSRD and railway vocabulary

              Please open an issue if you’re missing a word

              © 2024 OSRD contributors. All Rights Reserved
              \ No newline at end of file +

              This is the multi-page printable view of this section. +Click here to print.

              Return to the regular view of this page.

              Glossary

              Glossary of OSRD and railway vocabulary

                Please open an issue if you’re missing a word

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/railway-wiki/glossary/index.html b/en/docs/railway-wiki/glossary/index.html index 4de45a6eb..ae9b4720d 100644 --- a/en/docs/railway-wiki/glossary/index.html +++ b/en/docs/railway-wiki/glossary/index.html @@ -1,5 +1,5 @@ Glossary | OSRD -

                Glossary

                Glossary of OSRD and railway vocabulary

                Please open an issue if you’re missing a word

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/railway-wiki/index.html b/en/docs/railway-wiki/index.html index f3167c461..3e59797e1 100644 --- a/en/docs/railway-wiki/index.html +++ b/en/docs/railway-wiki/index.html @@ -1,5 +1,5 @@ Railway Wiki | OSRD -

                Railway Wiki

                International railway wiki

                This wiki is meant to help software engineers have a deep understanding of railway systems.

                It can only happen if content is added as needed. If something is missing, contribute!

                Glossary

                Glossary of OSRD and railway vocabulary

                ETCS (ERTMS)

                The European Train Control System, part of ERTMS

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/railway-wiki/signalling/spacing/ertms/_print/index.html b/en/docs/railway-wiki/signalling/spacing/ertms/_print/index.html index 438fcbd02..d8769a0e4 100644 --- a/en/docs/railway-wiki/signalling/spacing/ertms/_print/index.html +++ b/en/docs/railway-wiki/signalling/spacing/ertms/_print/index.html @@ -1,4 +1,4 @@ ETCS (ERTMS) | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                ETCS (ERTMS)

                The European Train Control System, part of ERTMS

                1 - ETCS

                European Train Control System

                Context

                The onboard computer of ETCS-enabled trains has to compute a number of position / speed curves. -Here is how it works:

                • below all the curves, the speed indicator is white
                • above the indication curve, the speed indicator is yellow
                • above the permitted curve, the speed indicator is orange
                • above the warning curve, an alarm rings
                • above the intervention curves, an emergency break intervention is triggered

                Inputs

                In order to compute any of these curves, a number of things are needed:

                • target data (the destination of the braking curve, which can be EOA and SvL or LOA and MRSP)
                • train data
                • infrastructure data
                • infrastructure manager constants
                • standardized constants

                Train

                • max speed
                • length
                • rotating mass
                • T_traction_cutoff: the time it take to cut off traction
                • braking model, either lambda or gamma:
                  • lambda (braking weight/mass)
                  • gamma (contant deceleration at a given speed)
                • correction factors (k_dry and k_wet for gamma braking) for braking curves

                Infrastructure

                • corrected gradients (it incorporates curvature)
                • odometry balises location

                Processes

                Braking coefficients:

                • A_brake_emergency is the expected emergency braking capability, without safety margins
                • A_brake_safe is the emergency braking coefficient, with safety margins
                • A_brake_service is the expected service braking capability, without safety margins

                Speed / distance targets

                • EOA end of movement authority: the location until which the train is allowed to move
                • SvL supervized location: the protected location

                Curves

                • SBD supervised braking deceleration: intermediary result computed from EOA and A_brake_service
                • EBD emergency braking deceleration: intermediary result computed from SvL and A_brake_safe

                All the curves below are cut below a given release speed:

                • EBI (emergency break intervention) computed from EBD, shifted in position and space given rolling stock metadata
                • SBI1 computed from SBD, shifted in time with Tbs1
                • SBI2 computed from SBD, shifted in time with Tbs2
                • FLOI (also called SBI, the intervention curve) the minimum of SBI1 and SBI2
                • WARNING (warning curve) computed as a shift of FLOI by Twarning
                • PS (permitted speed curve): shift of WARNING by time Tdriver
                • INDICATION is a shift of PS by time Tindication
                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +Here is how it works:

                • below all the curves, the speed indicator is white
                • above the indication curve, the speed indicator is yellow
                • above the permitted curve, the speed indicator is orange
                • above the warning curve, an alarm rings
                • above the intervention curves, an emergency break intervention is triggered

                Inputs

                In order to compute any of these curves, a number of things are needed:

                • target data (the destination of the braking curve, which can be EOA and SvL or LOA and MRSP)
                • train data
                • infrastructure data
                • infrastructure manager constants
                • standardized constants

                Train

                • max speed
                • length
                • rotating mass
                • T_traction_cutoff: the time it take to cut off traction
                • braking model, either lambda or gamma:
                  • lambda (braking weight/mass)
                  • gamma (contant deceleration at a given speed)
                • correction factors (k_dry and k_wet for gamma braking) for braking curves

                Infrastructure

                • corrected gradients (it incorporates curvature)
                • odometry balises location

                Processes

                Braking coefficients:

                • A_brake_emergency is the expected emergency braking capability, without safety margins
                • A_brake_safe is the emergency braking coefficient, with safety margins
                • A_brake_service is the expected service braking capability, without safety margins

                Speed / distance targets

                • EOA end of movement authority: the location until which the train is allowed to move
                • SvL supervized location: the protected location

                Curves

                • SBD supervised braking deceleration: intermediary result computed from EOA and A_brake_service
                • EBD emergency braking deceleration: intermediary result computed from SvL and A_brake_safe

                All the curves below are cut below a given release speed:

                • EBI (emergency break intervention) computed from EBD, shifted in position and space given rolling stock metadata
                • SBI1 computed from SBD, shifted in time with Tbs1
                • SBI2 computed from SBD, shifted in time with Tbs2
                • FLOI (also called SBI, the intervention curve) the minimum of SBI1 and SBI2
                • WARNING (warning curve) computed as a shift of FLOI by Twarning
                • PS (permitted speed curve): shift of WARNING by time Tdriver
                • INDICATION is a shift of PS by time Tindication
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/railway-wiki/signalling/spacing/ertms/etcs/index.html b/en/docs/railway-wiki/signalling/spacing/ertms/etcs/index.html index 0dff32ac3..82618c566 100644 --- a/en/docs/railway-wiki/signalling/spacing/ertms/etcs/index.html +++ b/en/docs/railway-wiki/signalling/spacing/ertms/etcs/index.html @@ -1,5 +1,5 @@ ETCS | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/railway-wiki/signalling/spacing/ertms/index.html b/en/docs/railway-wiki/signalling/spacing/ertms/index.html index 07774d17c..782c30ed7 100644 --- a/en/docs/railway-wiki/signalling/spacing/ertms/index.html +++ b/en/docs/railway-wiki/signalling/spacing/ertms/index.html @@ -1,5 +1,5 @@ ETCS (ERTMS) | OSRD -

                ETCS (ERTMS)

                The European Train Control System, part of ERTMS
                ETCS

                European Train Control System

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/_print/index.html b/en/docs/reference/_print/index.html index ec6858bda..0def7422a 100644 --- a/en/docs/reference/_print/index.html +++ b/en/docs/reference/_print/index.html @@ -1,5 +1,5 @@ Technical reference | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                Technical reference

                Internal machinery and APIs

                Technical reference guides contain technical reference for APIs and other aspects of OSRD’s machinery. They describe how it works and how to use it but assume that you have a basic understanding of key concepts.

                1 - Architecture

                Learn more about OSRD architecture

                Architecture documents are meant to help understand how OSRD works overall.

                1.1 - Data-flow

                OSRD’s data-flow diagram

                Data-flow diagram

                1.2 - Services

                OSRD’s services architecture

                It is a multi-service architecture where several software components interact with each other. This choice was made to ensure the modularity of the code and to guarantee the exploitability of certain OSRD services by external applications.

                • Valkey is configured as maxmemory-policy=allkeys-lru (documentation)
                • Osrdyne has multiple drivers to support:
                  • k8s
                  • docker
                  • process compose
                • The gateway supports multiple authentication providers:
                  • OpenID Connect (OIDC)
                  • Bearer token
                  • Mock (for development purpose)
                • Some editoast endpoints requires an InfraCache object which make them stateful. These endpoints are only used in the editoast-stateful service. Doing so most endpoints are run by a scalable service.

                Coming soon:

                • Adapt editoast-stateful so editoast is fully scalable.

                Services architecture

                2 - Design documents

                Learn more about how the software was designed

                Design documents are meant to help understand and participate in designing software.

                Each design document describes a number of things about a piece of software:

                • its goals
                • its constraints
                • how its inputs and outputs were modeled
                • how it works

                2.1 - Signaling

                Describes the signaling model

                Description

                The signaling layer includes all signals, which respond to track occupancy and reservation. Signals can be of different types, and are modularly loaded. Only their behavior towards the state of the infrastructure and the train’s reaction @@ -137,18 +137,18 @@ "track_ranges": [{"track": "${TRACK_SECTION}", "begin": 0, "end": 42, "applicable_directions": "START_TO_STOP"}], } -

                Design considerations

                Where to put the speed limit value

                When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:

                • once in the signal itself
                • once in the speed limit

                There are multiple ways this issue can be dealt with:

                ✅ -Mandatory speed limit value in the speed section

                Upsides:

                • simpler to implement, works even without train reactions to signals nor additional API

                Downsides:

                • more work on the side of users
                • room for inconsistencies between the speed limit announced by signaling, and the effective speed limit

                ❌ +

                Design considerations

                Where to put the speed limit value

                When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:

                • once in the signal itself
                • once in the speed limit

                There are multiple ways this issue can be dealt with:

                ✅ +Mandatory speed limit value in the speed section

                Upsides:

                • simpler to implement, works even without train reactions to signals nor additional API

                Downsides:

                • more work on the side of users
                • room for inconsistencies between the speed limit announced by signaling, and the effective speed limit

                ❌ Deduce the signal constraint from the speed limit

                This option was not explored much, as it was deemed awkward -to deduce signal parameters from a speed limit value.

                ❌ +to deduce signal parameters from a speed limit value.

                ❌ Deduce the speed limit from the signal

                Make the speed limit value optional, and deduce it from the signal itself. Speed limits per tag also have to be deduced if missing.

                Upsides:

                • less work for users
                • lessens the likelyhood of configuration mismatches

                Downsides:

                • not all signaling systems work well with this. It may be difficult to deduce the announced speed limit from a signal configuration, such as with TVM.
                • speed limits have to be deduced, which increases implementation complexity

                Speed limit announced by dynamic signaling often start being enforced at a specific location, which is distinct from the signal which announces the speed limit.

                To allow for correct train reactions to this kind of limits, a link between the announce signal -and the speed limit section has to be made at some point.

                ❌ -Automated matching of signals and speed sections

                Was not deemed realistic.

                ❌ +Automated matching of signals and speed sections

                Was not deemed realistic.

                Was deemed to be awkward, as signaling is currently built over interlocking. -Referencing signaling from interlocking creates a circular dependency between the two schemas.

                Add a list of (route, signal) tuples to speed sections.

                Upside:

                • a link with the signal can be made with creating the speed section

                Downside:

                • Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.
                • Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.

                ❌ +Referencing signaling from interlocking creates a circular dependency between the two schemas.

                Add a list of (route, signal) tuples to speed sections.

                Upside:

                • a link with the signal can be made with creating the speed section

                Downside:

                • Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.
                • Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.

                ❌ Inlining speed limit definitions into signals

                Introduces a new type of speed limit, which are announced by signals. These speed limits are directly defined within signal definitions.

                {
     # ...
@@ -165,7 +165,7 @@
     ]
     # ...
 }
-

                Upsides:

                • straightforward infrastructure edition experience for speed sections announced by a single signal

                Downsides:

                • creates two separate kinds of speed limits:
                  • can cause code duplication
                  • could make later changes of the data model trickier
                  • it’s unclear whether the criterion used to make this partition is appropriate
                • speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)
                • the cost of reversing this decision could be fairly high

                Upsides:

                • straightforward infrastructure edition experience for speed sections announced by a single signal

                Downsides:

                • creates two separate kinds of speed limits:
                  • can cause code duplication
                  • could make later changes of the data model trickier
                  • it’s unclear whether the criterion used to make this partition is appropriate
                • speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)
                • the cost of reversing this decision could be fairly high
                {
     # ...
     "conditional_parameters": [
@@ -396,13 +396,13 @@
     LT, LE, EQ, GE, GT
 }

                Design decisions

                Lowering constraints to an intermediate representation

                Early on, we started making lists of what domain constraints can have an impact on train behavior. -Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.

                There’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:

                • either treat each type of constraint as its own thing during the simulation
                • abstract away constraints into a common representation, and then simulate that

                ❌ +Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.

                There’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:

                • either treat each type of constraint as its own thing during the simulation
                • abstract away constraints into a common representation, and then simulate that

                ❌ Distinct constraint types

                When we first started drafting architecture diagrams, the train simulation API directly took -a bunch of constraint types as an input. It brought up a number of issues:

                • the high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types
                • the domain of some of these interactions is very complex (block signaling)
                • when simulating, it does not seem to matter why a constraint is there, only what to do about it

                We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.

                ❌ +a bunch of constraint types as an input. It brought up a number of issues:

                • the high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types
                • the domain of some of these interactions is very complex (block signaling)
                • when simulating, it does not seem to matter why a constraint is there, only what to do about it

                We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.

                ❌ Internal constraint types abstraction

                We then realized that abstracting over constraint types during simulation had immense benefits:

                • it allows expressing requirements on what constraints need to be enforceable
                • it greatly simplifies the process of validating constraint semantics: instead of having to validate interactions between every possible type of constraints, we only have to validate that the semantics of each constraint type can be transferred to the abstract constraint type

                We decided to explore the possibility of keeping constraint types distinct in the external API, -but lowering these constraints into an intermediary representation internally. We found a number of downsides:

                • the public simulation API would still bear the complexity of dealing with many constraint types
                • there would be a need to incrementally generate internal abstracted constraints to support the incremental API

                ✅ +but lowering these constraints into an intermediary representation internally. We found a number of downsides:

                • the public simulation API would still bear the complexity of dealing with many constraint types
                • there would be a need to incrementally generate internal abstracted constraints to support the incremental API

                ✅ External constraint types abstraction

                We tried to improve over the previous proposal by moving the burden of converting many constraints into a common abstraction out of the simulation API.

                Instead of having many constraint types as an input, the simulation API takes a collection of a single abstract constraint type. The task of converting domain constraints to abstract driving instructions is left to the API user.

                We found that doing so:

                • reduces the API surface of the train simulation module
                • decouples behavior from constraint types: if a new constraint type needs to be added, the simulation API only needs expansion if the expected behavior expected for this constraint isn’t part of the API.

                Interpreting driving instructions

                As the train progresses through the simulation, it reacts according to driving instructions @@ -444,9 +444,9 @@ RK4. Such estimator then needs to call f multiple times.

                A number of questions came up:

                • should numerical integration within the driver behavior module, or outside
                • are driver behavior modules queried about their reaction to a specific instruction, or in general
                • does the driver behavior module return decisions, or parameters used to make decisions (such as curves)
                • if decisions are returned, is it a force, an acceleration, or a new state
                • if a new state is returned, how to deal with heterogenous time steps
                • do we check decisions for correctness? that is, if a decision causes the train to overshoot a limit curve, do we do anything?

                Do we have a single DBM for all driving instructions, or one per driving instruction?

                We identified that this API choice shouldn’t constrain the implementation. We decided to go the conservative route and have one DBM per driving instructions as it reduces the API surface -and relieves DBM from the responsibility of finding the most restrictive instruction.

                How do we prevent overshooting?

                We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).

                To do so we could either:

                1. Have a way to short-circuit our integration scheme, to snap to target curves without overshooting.
                2. Accept oscillations around target curves (and thus overshooting).
                3. Setup a feedback loop mechanism to avoid overshooting.

                We decided that only the first option was desirable.

                The design choices then are:

                ❌ +and relieves DBM from the responsibility of finding the most restrictive instruction.

                How do we prevent overshooting?

                We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).

                To do so we could either:

                1. Have a way to short-circuit our integration scheme, to snap to target curves without overshooting.
                2. Accept oscillations around target curves (and thus overshooting).
                3. Setup a feedback loop mechanism to avoid overshooting.

                We decided that only the first option was desirable.

                The design choices then are:

                ❌ Make the DBM as close as possible to a decision function

                Then the DBM would not be aware of the time step it is called with, and would return an acceleration. Then the module should expose two methods:

                • One for taking decisions, akin to f.
                  Called several times depending on the integration method.

                • One for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves -(for example MARECO which sets it’s own speed limits).
                  Called on the integration step results from this DBM, and the other DBMs integration step results.

                ✅ +(for example MARECO which sets it’s own speed limits).
                Called on the integration step results from this DBM, and the other DBMs integration step results.

                ✅ The DBM returns a new state

                The module would then expose two methods:

                • One for taking decisions, which, given a train state and a desired/maximum time step, returns a new state (which does not overshoot) and a new current time.

                • One for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves (for example MARECO which sets it’s own speed limits).
                  Called only on other DBMs integration step results.

                How do we combine the decisions from all DBMs?

                1. For each state property, find the most constraining value and dt.
                2. Find the smallest dt amongst constraining properties. Interpolate remaining properties to this dt, to build a provisional state.
                3. Submit this provisional state for truncation to all DBMs and take the truncation with the smallest dt.

                To understand how this algorithm is designed, we need to consider two example cases:

                • For steps 1 and 2: if a neutral zone and a breaking instruction overlap, both are most constraining to different state properties: the neutral zone affects pantograph state, and the breaking instruction affects speed. The final state has to be a combination of both.
                • For step 3: We need to truncate integration steps to avoid overshoots, and thus avoid the need for feedback loops. @@ -1615,4 +1615,4 @@ queue before it can proceed to forward the message.

                  If queues were created and deleted asynchronously when these events are received, it would introduce a race condition:

                  • the orphan processor creates the queue
                  • the queue gets deleted because it expired at the same time
                  • the orphan processor forwards the message, which gets lost

                  We found multiple solutions for this issue:

                  • process all asynchronous events in a single actor. This was not deemed viable because worker activity processing is work intensive, and orphan request processing is latency sensitive.
                  • having a single actor create and delete queues (the request queues control loop) and making the orphan processor wait until the control loop creates the queue

                  Unbind the queue and wait before stopping workers

                  In a previous design, we tried to delete work queue in one go. It created a race condition issue on queue deletion, caused by the fact ordyne does not get direct notifications of when messages are received on a work queue:

                  • we decide to stop the worker group
                  • work is received on the queue, but we aren’t made aware as no worker is up
                  • we try to delete the queue, but cannot do so without loosing messages

                  We could think of two fixes for this issue:

                  • implement a two stage shutdown, where no work can get to the queue for a while before workers are stopped
                  • detect that the queue still has messages after workers have stopped, and start workers back up

                  We decided to implement two stage worker group shutdown:

                  • if no activity is register for UNBIND_DELAY, unbind the work queue
                  • wait for a while to see if any worker picks up work from the queue and notifies osrdyne, which would rebind the queue
                  • if no orphan nor worker activity is registered for STOP_DELAY, stop workers and delete the queue

                  1. The control loop is designed to make the state of all worker groups converge at once. Retrying convergence for one worker group adds latency to convergence for all worker groups. ↩︎ ↩︎

                3 - APIs

                Programming interfaces specifications

                RailJSON is the format used to describe a railway infrastructure, it’s -described in its JSON schema.

                Below are a list of REST APIs implemented by OSRD.

                3.1 - Editoast

                3.2 - Gateway

                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +described in its JSON schema.

                Below are a list of REST APIs implemented by OSRD.

                3.1 - Editoast

                3.2 - Gateway

                \ No newline at end of file diff --git a/en/docs/reference/apis/_print/index.html b/en/docs/reference/apis/_print/index.html index 0b7808d82..e9a648783 100644 --- a/en/docs/reference/apis/_print/index.html +++ b/en/docs/reference/apis/_print/index.html @@ -1,4 +1,4 @@ APIs | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                APIs

                Programming interfaces specifications

                RailJSON is the format used to describe a railway infrastructure, it’s -described in its JSON schema.

                Below are a list of REST APIs implemented by OSRD.

                1 - Editoast

                2 - Gateway

                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +described in its JSON schema.

                Below are a list of REST APIs implemented by OSRD.

                1 - Editoast

                2 - Gateway

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/apis/index.html b/en/docs/reference/apis/index.html index 6354fcb0f..8b3c74d13 100644 --- a/en/docs/reference/apis/index.html +++ b/en/docs/reference/apis/index.html @@ -1,5 +1,5 @@ APIs | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/architecture/_print/index.html b/en/docs/reference/architecture/_print/index.html index 8e6fc7f18..bf90d3f3f 100644 --- a/en/docs/reference/architecture/_print/index.html +++ b/en/docs/reference/architecture/_print/index.html @@ -1,3 +1,3 @@ Architecture | OSRD -

                This is the multi-page printable view of this section. -Click here to print.

                Return to the regular view of this page.

                Architecture

                Learn more about OSRD architecture

                Architecture documents are meant to help understand how OSRD works overall.

                1 - Data-flow

                OSRD’s data-flow diagram

                Data-flow diagram

                2 - Services

                OSRD’s services architecture

                It is a multi-service architecture where several software components interact with each other. This choice was made to ensure the modularity of the code and to guarantee the exploitability of certain OSRD services by external applications.

                • Valkey is configured as maxmemory-policy=allkeys-lru (documentation)
                • Osrdyne has multiple drivers to support:
                  • k8s
                  • docker
                  • process compose
                • The gateway supports multiple authentication providers:
                  • OpenID Connect (OIDC)
                  • Bearer token
                  • Mock (for development purpose)
                • Some editoast endpoints requires an InfraCache object which make them stateful. These endpoints are only used in the editoast-stateful service. Doing so most endpoints are run by a scalable service.

                Coming soon:

                • Adapt editoast-stateful so editoast is fully scalable.

                Services architecture

                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +

                This is the multi-page printable view of this section. +Click here to print.

                Return to the regular view of this page.

                Architecture

                Learn more about OSRD architecture

                Architecture documents are meant to help understand how OSRD works overall.

                1 - Data-flow

                OSRD’s data-flow diagram

                Data-flow diagram

                2 - Services

                OSRD’s services architecture

                It is a multi-service architecture where several software components interact with each other. This choice was made to ensure the modularity of the code and to guarantee the exploitability of certain OSRD services by external applications.

                • Valkey is configured as maxmemory-policy=allkeys-lru (documentation)
                • Osrdyne has multiple drivers to support:
                  • k8s
                  • docker
                  • process compose
                • The gateway supports multiple authentication providers:
                  • OpenID Connect (OIDC)
                  • Bearer token
                  • Mock (for development purpose)
                • Some editoast endpoints requires an InfraCache object which make them stateful. These endpoints are only used in the editoast-stateful service. Doing so most endpoints are run by a scalable service.

                Coming soon:

                • Adapt editoast-stateful so editoast is fully scalable.

                Services architecture

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/architecture/data_flow/index.html b/en/docs/reference/architecture/data_flow/index.html index f27c84208..62df40c59 100644 --- a/en/docs/reference/architecture/data_flow/index.html +++ b/en/docs/reference/architecture/data_flow/index.html @@ -1,5 +1,5 @@ Data-flow | OSRD -

                Data-flow

                OSRD’s data-flow diagram

                Data-flow diagram

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/architecture/index.html b/en/docs/reference/architecture/index.html index 9591ab344..8df247aff 100644 --- a/en/docs/reference/architecture/index.html +++ b/en/docs/reference/architecture/index.html @@ -1,5 +1,5 @@ Architecture | OSRD -

                Architecture

                Learn more about OSRD architecture

                Architecture documents are meant to help understand how OSRD works overall.

                Data-flow

                OSRD’s data-flow diagram

                Services

                OSRD’s services architecture

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/architecture/services/index.html b/en/docs/reference/architecture/services/index.html index cecbbdf2b..6833d2b65 100644 --- a/en/docs/reference/architecture/services/index.html +++ b/en/docs/reference/architecture/services/index.html @@ -1,5 +1,5 @@ Services | OSRD -

                Services

                OSRD’s services architecture

                It is a multi-service architecture where several software components interact with each other. This choice was made to ensure the modularity of the code and to guarantee the exploitability of certain OSRD services by external applications.

                • Valkey is configured as maxmemory-policy=allkeys-lru (documentation)
                • Osrdyne has multiple drivers to support:
                  • k8s
                  • docker
                  • process compose
                • The gateway supports multiple authentication providers:
                  • OpenID Connect (OIDC)
                  • Bearer token
                  • Mock (for development purpose)
                • Some editoast endpoints requires an InfraCache object which make them stateful. These endpoints are only used in the editoast-stateful service. Doing so most endpoints are run by a scalable service.

                Coming soon:

                • Adapt editoast-stateful so editoast is fully scalable.

                Services architecture

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/_print/index.html b/en/docs/reference/design-docs/_print/index.html index 331f71cb3..5649068d3 100644 --- a/en/docs/reference/design-docs/_print/index.html +++ b/en/docs/reference/design-docs/_print/index.html @@ -1,5 +1,5 @@ Design documents | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                Design documents

                Learn more about how the software was designed

                Design documents are meant to help understand and participate in designing software.

                Each design document describes a number of things about a piece of software:

                • its goals
                • its constraints
                • how its inputs and outputs were modeled
                • how it works

                1 - Signaling

                Describes the signaling model

                Description

                The signaling layer includes all signals, which respond to track occupancy and reservation. Signals can be of different types, and are modularly loaded. Only their behavior towards the state of the infrastructure and the train’s reaction @@ -137,18 +137,18 @@ "track_ranges": [{"track": "${TRACK_SECTION}", "begin": 0, "end": 42, "applicable_directions": "START_TO_STOP"}], } -

                Design considerations

                Where to put the speed limit value

                When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:

                • once in the signal itself
                • once in the speed limit

                There are multiple ways this issue can be dealt with:

                ✅ -Mandatory speed limit value in the speed section

                Upsides:

                • simpler to implement, works even without train reactions to signals nor additional API

                Downsides:

                • more work on the side of users
                • room for inconsistencies between the speed limit announced by signaling, and the effective speed limit

                ❌ +

                Design considerations

                Where to put the speed limit value

                When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:

                • once in the signal itself
                • once in the speed limit

                There are multiple ways this issue can be dealt with:

                ✅ +Mandatory speed limit value in the speed section

                Upsides:

                • simpler to implement, works even without train reactions to signals nor additional API

                Downsides:

                • more work on the side of users
                • room for inconsistencies between the speed limit announced by signaling, and the effective speed limit

                ❌ Deduce the signal constraint from the speed limit

                This option was not explored much, as it was deemed awkward -to deduce signal parameters from a speed limit value.

                ❌ +to deduce signal parameters from a speed limit value.

                ❌ Deduce the speed limit from the signal

                Make the speed limit value optional, and deduce it from the signal itself. Speed limits per tag also have to be deduced if missing.

                Upsides:

                • less work for users
                • lessens the likelyhood of configuration mismatches

                Downsides:

                • not all signaling systems work well with this. It may be difficult to deduce the announced speed limit from a signal configuration, such as with TVM.
                • speed limits have to be deduced, which increases implementation complexity

                Speed limit announced by dynamic signaling often start being enforced at a specific location, which is distinct from the signal which announces the speed limit.

                To allow for correct train reactions to this kind of limits, a link between the announce signal -and the speed limit section has to be made at some point.

                ❌ -Automated matching of signals and speed sections

                Was not deemed realistic.

                ❌ +Automated matching of signals and speed sections

                Was not deemed realistic.

                Was deemed to be awkward, as signaling is currently built over interlocking. -Referencing signaling from interlocking creates a circular dependency between the two schemas.

                Add a list of (route, signal) tuples to speed sections.

                Upside:

                • a link with the signal can be made with creating the speed section

                Downside:

                • Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.
                • Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.

                ❌ +Referencing signaling from interlocking creates a circular dependency between the two schemas.

                Add a list of (route, signal) tuples to speed sections.

                Upside:

                • a link with the signal can be made with creating the speed section

                Downside:

                • Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.
                • Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.

                ❌ Inlining speed limit definitions into signals

                Introduces a new type of speed limit, which are announced by signals. These speed limits are directly defined within signal definitions.

                {
     # ...
@@ -165,7 +165,7 @@
     ]
     # ...
 }
-

                Upsides:

                • straightforward infrastructure edition experience for speed sections announced by a single signal

                Downsides:

                • creates two separate kinds of speed limits:
                  • can cause code duplication
                  • could make later changes of the data model trickier
                  • it’s unclear whether the criterion used to make this partition is appropriate
                • speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)
                • the cost of reversing this decision could be fairly high

                Upsides:

                • straightforward infrastructure edition experience for speed sections announced by a single signal

                Downsides:

                • creates two separate kinds of speed limits:
                  • can cause code duplication
                  • could make later changes of the data model trickier
                  • it’s unclear whether the criterion used to make this partition is appropriate
                • speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)
                • the cost of reversing this decision could be fairly high
                {
     # ...
     "conditional_parameters": [
@@ -396,13 +396,13 @@
     LT, LE, EQ, GE, GT
 }

                Design decisions

                Lowering constraints to an intermediate representation

                Early on, we started making lists of what domain constraints can have an impact on train behavior. -Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.

                There’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:

                • either treat each type of constraint as its own thing during the simulation
                • abstract away constraints into a common representation, and then simulate that

                ❌ +Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.

                There’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:

                • either treat each type of constraint as its own thing during the simulation
                • abstract away constraints into a common representation, and then simulate that

                ❌ Distinct constraint types

                When we first started drafting architecture diagrams, the train simulation API directly took -a bunch of constraint types as an input. It brought up a number of issues:

                • the high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types
                • the domain of some of these interactions is very complex (block signaling)
                • when simulating, it does not seem to matter why a constraint is there, only what to do about it

                We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.

                ❌ +a bunch of constraint types as an input. It brought up a number of issues:

                • the high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types
                • the domain of some of these interactions is very complex (block signaling)
                • when simulating, it does not seem to matter why a constraint is there, only what to do about it

                We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.

                ❌ Internal constraint types abstraction

                We then realized that abstracting over constraint types during simulation had immense benefits:

                • it allows expressing requirements on what constraints need to be enforceable
                • it greatly simplifies the process of validating constraint semantics: instead of having to validate interactions between every possible type of constraints, we only have to validate that the semantics of each constraint type can be transferred to the abstract constraint type

                We decided to explore the possibility of keeping constraint types distinct in the external API, -but lowering these constraints into an intermediary representation internally. We found a number of downsides:

                • the public simulation API would still bear the complexity of dealing with many constraint types
                • there would be a need to incrementally generate internal abstracted constraints to support the incremental API

                ✅ +but lowering these constraints into an intermediary representation internally. We found a number of downsides:

                • the public simulation API would still bear the complexity of dealing with many constraint types
                • there would be a need to incrementally generate internal abstracted constraints to support the incremental API

                ✅ External constraint types abstraction

                We tried to improve over the previous proposal by moving the burden of converting many constraints into a common abstraction out of the simulation API.

                Instead of having many constraint types as an input, the simulation API takes a collection of a single abstract constraint type. The task of converting domain constraints to abstract driving instructions is left to the API user.

                We found that doing so:

                • reduces the API surface of the train simulation module
                • decouples behavior from constraint types: if a new constraint type needs to be added, the simulation API only needs expansion if the expected behavior expected for this constraint isn’t part of the API.

                Interpreting driving instructions

                As the train progresses through the simulation, it reacts according to driving instructions @@ -444,9 +444,9 @@ RK4. Such estimator then needs to call f multiple times.

                A number of questions came up:

                • should numerical integration within the driver behavior module, or outside
                • are driver behavior modules queried about their reaction to a specific instruction, or in general
                • does the driver behavior module return decisions, or parameters used to make decisions (such as curves)
                • if decisions are returned, is it a force, an acceleration, or a new state
                • if a new state is returned, how to deal with heterogenous time steps
                • do we check decisions for correctness? that is, if a decision causes the train to overshoot a limit curve, do we do anything?

                Do we have a single DBM for all driving instructions, or one per driving instruction?

                We identified that this API choice shouldn’t constrain the implementation. We decided to go the conservative route and have one DBM per driving instructions as it reduces the API surface -and relieves DBM from the responsibility of finding the most restrictive instruction.

                How do we prevent overshooting?

                We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).

                To do so we could either:

                1. Have a way to short-circuit our integration scheme, to snap to target curves without overshooting.
                2. Accept oscillations around target curves (and thus overshooting).
                3. Setup a feedback loop mechanism to avoid overshooting.

                We decided that only the first option was desirable.

                The design choices then are:

                ❌ +and relieves DBM from the responsibility of finding the most restrictive instruction.

                How do we prevent overshooting?

                We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).

                To do so we could either:

                1. Have a way to short-circuit our integration scheme, to snap to target curves without overshooting.
                2. Accept oscillations around target curves (and thus overshooting).
                3. Setup a feedback loop mechanism to avoid overshooting.

                We decided that only the first option was desirable.

                The design choices then are:

                ❌ Make the DBM as close as possible to a decision function

                Then the DBM would not be aware of the time step it is called with, and would return an acceleration. Then the module should expose two methods:

                • One for taking decisions, akin to f.
                  Called several times depending on the integration method.

                • One for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves -(for example MARECO which sets it’s own speed limits).
                  Called on the integration step results from this DBM, and the other DBMs integration step results.

                ✅ +(for example MARECO which sets it’s own speed limits).
                Called on the integration step results from this DBM, and the other DBMs integration step results.

                ✅ The DBM returns a new state

                The module would then expose two methods:

                • One for taking decisions, which, given a train state and a desired/maximum time step, returns a new state (which does not overshoot) and a new current time.

                • One for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves (for example MARECO which sets it’s own speed limits).
                  Called only on other DBMs integration step results.

                How do we combine the decisions from all DBMs?

                1. For each state property, find the most constraining value and dt.
                2. Find the smallest dt amongst constraining properties. Interpolate remaining properties to this dt, to build a provisional state.
                3. Submit this provisional state for truncation to all DBMs and take the truncation with the smallest dt.

                To understand how this algorithm is designed, we need to consider two example cases:

                • For steps 1 and 2: if a neutral zone and a breaking instruction overlap, both are most constraining to different state properties: the neutral zone affects pantograph state, and the breaking instruction affects speed. The final state has to be a combination of both.
                • For step 3: We need to truncate integration steps to avoid overshoots, and thus avoid the need for feedback loops. @@ -1614,4 +1614,4 @@ This queue can be watched by osrdyne, which can use these events to know when to stop a worker group.

                  Make worker group lifetime decisions in a separate actor

                  The lifetime of worker groups is influenced by three types of asynchronous events:

                  • worker activity
                  • orphan requests
                  • worker group spooldown deadlines

                  When the orphan processor gets a request, it needs to create the worker group’s request queue before it can proceed to forward the message.

                  If queues were created and deleted asynchronously when these events are received, it would introduce a race condition:

                  • the orphan processor creates the queue
                  • the queue gets deleted because it expired at the same time
                  • the orphan processor forwards the message, which gets lost

                  We found multiple solutions for this issue:

                  • process all asynchronous events in a single actor. This was not deemed viable because worker activity processing is work intensive, and orphan request processing is latency sensitive.
                  • having a single actor create and delete queues (the request queues control loop) and making the orphan processor wait until the control loop creates the queue

                  Unbind the queue and wait before stopping workers

                  In a previous design, we tried to delete work queue in one go. It created a race condition issue on queue deletion, caused by the fact ordyne does not get direct notifications of when messages are received on a work queue:

                  • we decide to stop the worker group
                  • work is received on the queue, but we aren’t made aware as no worker is up
                  • we try to delete the queue, but cannot do so without loosing messages

                  We could think of two fixes for this issue:

                  • implement a two stage shutdown, where no work can get to the queue for a while before workers are stopped
                  • detect that the queue still has messages after workers have stopped, and start workers back up

                  We decided to implement two stage worker group shutdown:

                  • if no activity is register for UNBIND_DELAY, unbind the work queue
                  • wait for a while to see if any worker picks up work from the queue and notifies osrdyne, which would rebind the queue
                  • if no orphan nor worker activity is registered for STOP_DELAY, stop workers and delete the queue

                  1. The control loop is designed to make the state of all worker groups converge at once. -Retrying convergence for one worker group adds latency to convergence for all worker groups. ↩︎ ↩︎

                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +Retrying convergence for one worker group adds latency to convergence for all worker groups. ↩︎ ↩︎

                \ No newline at end of file diff --git a/en/docs/reference/design-docs/auth/_print/index.html b/en/docs/reference/design-docs/auth/_print/index.html index f284a4110..0d94a3998 100644 --- a/en/docs/reference/design-docs/auth/_print/index.html +++ b/en/docs/reference/design-docs/auth/_print/index.html @@ -1,5 +1,5 @@ Authentication and authorization | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                Authentication and authorization

                Context and requirements

                • authentication (authn) is the process of figuring out a user’s identity.
                • authorization (authz) is the process of figuring out whether a user can do something.

                This design project started as a result of a feature request coming from SNCF users and stakeholders. After some interviews, we believe the overall needs to be as follows:

                • controlling access to features
                  • some users are supposed to only view results of operational studies
                  • some users only get access to part of the app
                  • not everyone can have access to the admin panel
                  • it could be nice to be able to roll experimental features out incrementaly
                • controlling access to data
                  • some infrastructures shall only be changed by automated import jobs
                  • users might want to control who can mess with what they’re currently working on
                  • rolling stock, infrastructure and timetable data may be confidential

                Overall architecture

                flowchart LR
   subgraph gateway
@@ -651,4 +651,4 @@
     }).await?;
     Ok(Json(response))
 }
-
                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/auth/editoast-internal-api/index.html b/en/docs/reference/design-docs/auth/editoast-internal-api/index.html index d1d3543cb..f00b263fb 100644 --- a/en/docs/reference/design-docs/auth/editoast-internal-api/index.html +++ b/en/docs/reference/design-docs/auth/editoast-internal-api/index.html @@ -11,7 +11,7 @@ (high priority) role and privilege checks were performed (low priority) privilege checks are performed before changes are made / data is returned (low priority) access patterns match privilege checks Other design criterias have an impact:">
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/auth/index.html b/en/docs/reference/design-docs/auth/index.html index 1df48b47b..9251fc26e 100644 --- a/en/docs/reference/design-docs/auth/index.html +++ b/en/docs/reference/design-docs/auth/index.html @@ -1,5 +1,5 @@ Authentication and authorization | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/conflict-detection/index.html b/en/docs/reference/design-docs/conflict-detection/index.html index 125a95cb9..fcd123020 100644 --- a/en/docs/reference/design-docs/conflict-detection/index.html +++ b/en/docs/reference/design-docs/conflict-detection/index.html @@ -1,5 +1,5 @@ Conflict detection | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/index.html b/en/docs/reference/design-docs/index.html index 7bf420e1c..0265d0c74 100644 --- a/en/docs/reference/design-docs/index.html +++ b/en/docs/reference/design-docs/index.html @@ -1,5 +1,5 @@ Design documents | OSRD -

                Design documents

                Learn more about how the software was designed

                Design documents are meant to help understand and participate in designing software.

                Each design document describes a number of things about a piece of software:

                • its goals
                • its constraints
                • how its inputs and outputs were modeled
                • how it works
                Signaling

                Describes the signaling model

                Conflict detection

                Detect unrealistic timetables

                Train simulation v3

                Modeling and API design of train simulations

                Search for last-minute train slots (STDCM)

                Timetable v2

                Describes evolutions to the new timetable and train schedule models

                Authentication and authorization

                Scalable async RPC

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/scalable-async-rpc/index.html b/en/docs/reference/design-docs/scalable-async-rpc/index.html index fa4d7b500..7a5c5cd1d 100644 --- a/en/docs/reference/design-docs/scalable-async-rpc/index.html +++ b/en/docs/reference/design-docs/scalable-async-rpc/index.html @@ -11,7 +11,7 @@ To respond to a request, the core worker need to hold the request’s full infrastructure in memory. Workers do not have enough memory to hold all infrastructures in memory.">
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/signaling/_print/index.html b/en/docs/reference/design-docs/signaling/_print/index.html index 29e458e5c..268433a78 100644 --- a/en/docs/reference/design-docs/signaling/_print/index.html +++ b/en/docs/reference/design-docs/signaling/_print/index.html @@ -1,5 +1,5 @@ Signaling | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                Signaling

                Describes the signaling model

                Description

                The signaling layer includes all signals, which respond to track occupancy and reservation. Signals can be of different types, and are modularly loaded. Only their behavior towards the state of the infrastructure and the train’s reaction @@ -137,18 +137,18 @@ "track_ranges": [{"track": "${TRACK_SECTION}", "begin": 0, "end": 42, "applicable_directions": "START_TO_STOP"}], } -

                Design considerations

                Where to put the speed limit value

                When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:

                • once in the signal itself
                • once in the speed limit

                There are multiple ways this issue can be dealt with:

                ✅ -Mandatory speed limit value in the speed section

                Upsides:

                • simpler to implement, works even without train reactions to signals nor additional API

                Downsides:

                • more work on the side of users
                • room for inconsistencies between the speed limit announced by signaling, and the effective speed limit

                ❌ +

                Design considerations

                Where to put the speed limit value

                When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:

                • once in the signal itself
                • once in the speed limit

                There are multiple ways this issue can be dealt with:

                ✅ +Mandatory speed limit value in the speed section

                Upsides:

                • simpler to implement, works even without train reactions to signals nor additional API

                Downsides:

                • more work on the side of users
                • room for inconsistencies between the speed limit announced by signaling, and the effective speed limit

                ❌ Deduce the signal constraint from the speed limit

                This option was not explored much, as it was deemed awkward -to deduce signal parameters from a speed limit value.

                ❌ +to deduce signal parameters from a speed limit value.

                ❌ Deduce the speed limit from the signal

                Make the speed limit value optional, and deduce it from the signal itself. Speed limits per tag also have to be deduced if missing.

                Upsides:

                • less work for users
                • lessens the likelyhood of configuration mismatches

                Downsides:

                • not all signaling systems work well with this. It may be difficult to deduce the announced speed limit from a signal configuration, such as with TVM.
                • speed limits have to be deduced, which increases implementation complexity

                Speed limit announced by dynamic signaling often start being enforced at a specific location, which is distinct from the signal which announces the speed limit.

                To allow for correct train reactions to this kind of limits, a link between the announce signal -and the speed limit section has to be made at some point.

                ❌ -Automated matching of signals and speed sections

                Was not deemed realistic.

                ❌ +Automated matching of signals and speed sections

                Was not deemed realistic.

                Was deemed to be awkward, as signaling is currently built over interlocking. -Referencing signaling from interlocking creates a circular dependency between the two schemas.

                Add a list of (route, signal) tuples to speed sections.

                Upside:

                • a link with the signal can be made with creating the speed section

                Downside:

                • Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.
                • Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.

                ❌ +Referencing signaling from interlocking creates a circular dependency between the two schemas.

                Add a list of (route, signal) tuples to speed sections.

                Upside:

                • a link with the signal can be made with creating the speed section

                Downside:

                • Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.
                • Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.

                ❌ Inlining speed limit definitions into signals

                Introduces a new type of speed limit, which are announced by signals. These speed limits are directly defined within signal definitions.

                {
     # ...
@@ -165,7 +165,7 @@
     ]
     # ...
 }
-

                Upsides:

                • straightforward infrastructure edition experience for speed sections announced by a single signal

                Downsides:

                • creates two separate kinds of speed limits:
                  • can cause code duplication
                  • could make later changes of the data model trickier
                  • it’s unclear whether the criterion used to make this partition is appropriate
                • speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)
                • the cost of reversing this decision could be fairly high

                Upsides:

                • straightforward infrastructure edition experience for speed sections announced by a single signal

                Downsides:

                • creates two separate kinds of speed limits:
                  • can cause code duplication
                  • could make later changes of the data model trickier
                  • it’s unclear whether the criterion used to make this partition is appropriate
                • speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)
                • the cost of reversing this decision could be fairly high
                {
     # ...
     "conditional_parameters": [
@@ -226,4 +226,4 @@

                The view should allow access to the following data:

                • a synthetized view of zones downstream until the end of the train’s MA
                • the block chain
                • the state of downstream signals which belong to the current block chain

                Signaling view path

                The path along which the MAView and SpeedLimitView live is best expressed using blocks:

                • blocks can be added to extend the view along the path of a train
                • the view can be reduced by removing blocks, as the train passes by signals

                Simulation outside the train path

                Everything mentionned so far was designed to simulate signals between a train the end of its movement authority, as all others signals have no influence over the behavior of trains (they cannot be seen, or are disregarded by drivers).

                Nevertheless, one may want to simulate and display the state of all signals at a given point in time, -regardless of which signals are in use.

                Simulation rules are as follows:

                • if a signal starts blocks which have differing paths, it is simulated as if it were at the end of a route
                • if a signal starts blocks which all start the same path, it is simulated in the same view as the next signals in this path
                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +regardless of which signals are in use.

                Simulation rules are as follows:

                \ No newline at end of file diff --git a/en/docs/reference/design-docs/signaling/blocks-and-signals/index.html b/en/docs/reference/design-docs/signaling/blocks-and-signals/index.html index 7fb90d98e..5a53e29ad 100644 --- a/en/docs/reference/design-docs/signaling/blocks-and-signals/index.html +++ b/en/docs/reference/design-docs/signaling/blocks-and-signals/index.html @@ -3,7 +3,7 @@ A signaling system that corresponds to that displayed by its first signal. A path, which is a list of direction + detector pairs (just like route paths). An entry signal, (optional when the block starts from a buffer stop). Intermediate signals, if any (only used by systems with distant signals). An exit signal, (optional when the block ends at a buffer stop). The path is expressed from detector to detector so that it can be overlayed with the route graph.">
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/signaling/index.html b/en/docs/reference/design-docs/signaling/index.html index 67743e0f1..7efbec825 100644 --- a/en/docs/reference/design-docs/signaling/index.html +++ b/en/docs/reference/design-docs/signaling/index.html @@ -1,5 +1,5 @@ Signaling | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/signaling/index.xml b/en/docs/reference/design-docs/signaling/index.xml index e424dd852..6032fe7f1 100644 --- a/en/docs/reference/design-docs/signaling/index.xml +++ b/en/docs/reference/design-docs/signaling/index.xml @@ -240,7 +240,7 @@ It&rsquo;s built as follows:</p> <li>once in the speed limit</li> </ul> <p>There are multiple ways this issue can be dealt with:</p> -<h4 id="hahahugoshortcode156s0hbhb-mandatory-speed-limit-value-in-the-speed-section">✅ +<h4 id="hahahugoshortcode162s0hbhb-mandatory-speed-limit-value-in-the-speed-section">✅ Mandatory speed limit value in the speed section</h4> <p>Upsides:</p> <ul> @@ -251,11 +251,11 @@ Mandatory speed limit value in the speed section</h4> <li>more work on the side of users</li> <li>room for inconsistencies between the speed limit announced by signaling, and the effective speed limit</li> </ul> -<h4 id="hahahugoshortcode156s1hbhb-deduce-the-signal-constraint-from-the-speed-limit">❌ +<h4 id="hahahugoshortcode162s1hbhb-deduce-the-signal-constraint-from-the-speed-limit">❌ Deduce the signal constraint from the speed limit</h4> <p>This option was not explored much, as it was deemed awkward to deduce signal parameters from a speed limit value.</p> -<h4 id="hahahugoshortcode156s2hbhb-deduce-the-speed-limit-from-the-signal">❌ +<h4 id="hahahugoshortcode162s2hbhb-deduce-the-speed-limit-from-the-signal">❌ Deduce the speed limit from the signal</h4> <p>Make the speed limit value optional, and deduce it from the signal itself. Speed limits per tag also have to be deduced if missing.</p> @@ -274,14 +274,14 @@ Speed limits per tag also have to be deduced if missing.</p> which is distinct from the signal which announces the speed limit.</p> <p>To allow for correct train reactions to this kind of limits, a link between the announce signal and the speed limit section has to be made at some point.</p> -<h4 id="hahahugoshortcode156s3hbhb-automated-matching-of-signals-and-speed-sections">❌ +<h4 id="hahahugoshortcode162s3hbhb-automated-matching-of-signals-and-speed-sections">❌ Automated matching of signals and speed sections</h4> <p>Was not deemed realistic.</p> -<h4 id="hahahugoshortcode156s4hbhb-explicit-link-from-route-to-speed-limit-and-signals">❌ +<h4 id="hahahugoshortcode162s4hbhb-explicit-link-from-route-to-speed-limit-and-signals">❌ Explicit link from route to speed limit and signals</h4> <p>Was deemed to be awkward, as signaling is currently built over interlocking. Referencing signaling from interlocking creates a circular dependency between the two schemas.</p> -<h4 id="hahahugoshortcode156s5hbhb-explicit-link-from-speed-limit-to-signals">❌ +<h4 id="hahahugoshortcode162s5hbhb-explicit-link-from-speed-limit-to-signals">❌ Explicit link from speed limit to signals</h4> <p>Add a list of <code>(route, signal)</code> tuples to speed sections.</p> <p>Upside:</p> @@ -293,7 +293,7 @@ Explicit link from speed limit to signals</h4> <li>Creates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred.</li> <li>Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work.</li> </ul> -<h4 id="hahahugoshortcode156s6hbhb-inlining-speed-limit-definitions-into-signals">❌ +<h4 id="hahahugoshortcode162s6hbhb-inlining-speed-limit-definitions-into-signals">❌ Inlining speed limit definitions into signals</h4> <p>Introduces a new type of speed limit, which are announced by signals. These speed limits are directly defined within signal definitions.</p> @@ -328,7 +328,7 @@ These speed limits are directly defined within signal definitions.</p> <li>speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction)</li> <li>the cost of reversing this decision could be fairly high</li> </ul> -<h4 id="hahahugoshortcode156s7hbhb-explicit-link-from-signal-to-speed-section">✅ +<h4 id="hahahugoshortcode162s7hbhb-explicit-link-from-signal-to-speed-section">✅ Explicit link from signal to speed section</h4> <div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-yaml" data-lang="yaml"><span style="display:flex;"><span>{<span style="color:#f8f8f8;text-decoration:underline"> </span></span></span><span style="display:flex;"><span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#8f5902;font-style:italic"># ...</span><span style="color:#f8f8f8;text-decoration:underline"> diff --git a/en/docs/reference/design-docs/signaling/signaling-systems/index.html b/en/docs/reference/design-docs/signaling/signaling-systems/index.html index 3d94ffa6c..41c4672ba 100644 --- a/en/docs/reference/design-docs/signaling/signaling-systems/index.html +++ b/en/docs/reference/design-docs/signaling/signaling-systems/index.html @@ -3,7 +3,7 @@ A unique identifier (a string). Its signal state type, which enables deducing: The graphical representation of the signal How a train would react to the signal If the signal state constrains Movement Authority The signal parameter types, names and description, which enable front-end edition of signal parameters. The block and route conditions, which enable evaluating whether a signal delimits blocks or routes, given its parameters. { # unique identifier for the signaling system &#34;id&#34;: &#34;BAL&#34;, &#34;version&#34;: &#34;1.">
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/signaling/simulation/index.html b/en/docs/reference/design-docs/signaling/simulation/index.html index 0c49e2653..9aba00691 100644 --- a/en/docs/reference/design-docs/signaling/simulation/index.html +++ b/en/docs/reference/design-docs/signaling/simulation/index.html @@ -1,5 +1,5 @@ Simulation lifecycle | OSRD -
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/signaling/speed-limits/index.html b/en/docs/reference/design-docs/signaling/speed-limits/index.html index 7ebd0ccb3..a56e3e54c 100644 --- a/en/docs/reference/design-docs/signaling/speed-limits/index.html +++ b/en/docs/reference/design-docs/signaling/speed-limits/index.html @@ -1,5 +1,5 @@ Speed limits | OSRD -
                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +

                Upsides:

                Downsides:

                Speed limits by route

                Some speed limits only apply so some routes. This relationship needs to be modeled:

                1. speed limits could have a list of routes they apply on
                2. routes could have a list of speed limits they enforce
                3. the routes a speed limit apply on could be deduced from its announce signals, plus an explicit list of routes per speed section

                We took option 3.

                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/_print/index.html b/en/docs/reference/design-docs/stdcm/_print/index.html index f7befc1ef..b6ced5237 100644 --- a/en/docs/reference/design-docs/stdcm/_print/index.html +++ b/en/docs/reference/design-docs/stdcm/_print/index.html @@ -1,5 +1,5 @@ Search for last-minute train slots (STDCM) | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                Search for last-minute train slots (STDCM)

                OSRD can be used to find a slot for a train in an already established timetable, without causing conflicts with other trains.

                The acronym STDCM (Short Term Digital Capacity Management) is used to describe this concept in general.

                1 - Business context

                Some definitions:

                Capacity

                Capacity, in this context, is the ability to @@ -210,4 +210,4 @@ longer than the maximum allowed total run time. But for the same reason, adding this feature would break any STDCM test on generated infras. More details in -this issue.

                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +this issue.

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/domain_context/index.html b/en/docs/reference/design-docs/stdcm/domain_context/index.html index 868fed04f..55e1a3fb9 100644 --- a/en/docs/reference/design-docs/stdcm/domain_context/index.html +++ b/en/docs/reference/design-docs/stdcm/domain_context/index.html @@ -11,7 +11,7 @@ It can be displayed on a chart, with the time on the horizontal axis and the distance traveled on the vertical axis.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/index.html b/en/docs/reference/design-docs/stdcm/index.html index 7575ee74b..86146ded4 100644 --- a/en/docs/reference/design-docs/stdcm/index.html +++ b/en/docs/reference/design-docs/stdcm/index.html @@ -1,5 +1,5 @@ Search for last-minute train slots (STDCM) | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/_print/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/_print/index.html index 72b20b6cd..e0d6c0615 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/_print/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/_print/index.html @@ -1,5 +1,5 @@ Train slot search module | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                Train slot search module

                This module handles the search for solutions.

                To reduce the problem to its simplest form and for easy and efficient testing, inputs and outputs are strongly simplified and abstracted.

                To summarize its behavior: the solution space is described as a graph that encodes locations, @@ -181,4 +181,4 @@ longer than the maximum allowed total run time. But for the same reason, adding this feature would break any STDCM test on generated infras. More details in -this issue.

                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +this issue.

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/index.html index 2d7d0905e..094f1bf57 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/index.html @@ -3,7 +3,7 @@ This example illustrates the problem: by default the first edge is explored by going at maximum speed. The destination is only visible once the second edge is visited, which doesn&rsquo;t leave enough distance to stop.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/index.html index d3e0ac31f..6cbfd12eb 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/index.html @@ -7,7 +7,7 @@ Shifting the departure time The departure time is defined as an interval in the module parameters: the train can leave at a given time, or up to x seconds later. Whenever possible, delay should be added by shifting the departure time. for example : a train can leave between 10:00 et 11:00.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/index.html index c8473d5bb..4b7f699ae 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/index.html @@ -3,7 +3,7 @@ The documentation of the conflict detection module explains how it&rsquo;s done internally. Generally speaking, a train is in conflict when it has to slow down because of a signal. In our case, that means the solution would not be valid, we need to arrive later (or earlier) to see the signal when it&rsquo;s not restrictive anymore.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/index.html index ea44e2885..ee7d23155 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/index.html @@ -7,7 +7,7 @@ We consider the product graph of position, time, and speed. This means that every graph element contains these 3 variables (among other things) Every graph edge is computed using running-time calculation to get speed and positions as functions of time.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/index.html index 7f3abc2c2..8e17d1796 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/index.html @@ -7,7 +7,7 @@ STDCMEdgeBuilder This refers to this class in the project. This class is used to make it easier to create instances of STDCMEdge, the graph edges. Those contain many attributes, most of which can be determined from the context (e.g. the previous node). The STDCMEdgeBuilder class makes some parameters optional and automatically computes others.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/index.html index d4893c1c3..1aceef2c2 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/index.html @@ -1,5 +1,5 @@ Train slot search module | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/index.html index 81ea647a2..4863ba3aa 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/index.html @@ -7,7 +7,7 @@ We need a way to define and enumerate the different possible paths and explore the infrastructure graph, with several constraints: The path must be compatible with the given rolling stock (loading gauge / electrification / signaling system) At any point, we need to access path properties from its start up to the considered point.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/index.html b/en/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/index.html index 5279dbcfa..e1111b9e1 100644 --- a/en/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/index.html +++ b/en/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/index.html @@ -3,7 +3,7 @@ For example: the user can set a margin of 5 minutes per 100km. On a 42km long path that would take 10 minutes at best, the train should arrive 12 minutes and 6 seconds after leaving.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/timetable/index.html b/en/docs/reference/design-docs/timetable/index.html index b339de9b5..427a8f8dc 100644 --- a/en/docs/reference/design-docs/timetable/index.html +++ b/en/docs/reference/design-docs/timetable/index.html @@ -1,5 +1,5 @@ Timetable v2 | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/train-sim-v3/_print/index.html b/en/docs/reference/design-docs/train-sim-v3/_print/index.html index 4098893c8..912d9d2ba 100644 --- a/en/docs/reference/design-docs/train-sim-v3/_print/index.html +++ b/en/docs/reference/design-docs/train-sim-v3/_print/index.html @@ -1,5 +1,5 @@ Train simulation v3 | OSRD -

                This is the multi-page printable view of this section. +

                This is the multi-page printable view of this section. Click here to print.

                Return to the regular view of this page.

                Train simulation v3

                Modeling and API design of train simulations

                This work is pending implementation, and has not yet been adjusted to reflect potential required adjustments.

                These articles describe the design of the new train simulation system.

                This system should be simpler and more stable than the current one, and should enable more advanced features in the future.

                1 - Overview

                This work is pending implementation, and has not yet been adjusted to @@ -133,13 +133,13 @@ LT, LE, EQ, GE, GT }

                Design decisions

                Lowering constraints to an intermediate representation

                Early on, we started making lists of what domain constraints can have an impact on train behavior. -Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.

                There’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:

                • either treat each type of constraint as its own thing during the simulation
                • abstract away constraints into a common representation, and then simulate that

                ❌ +Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.

                There’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:

                • either treat each type of constraint as its own thing during the simulation
                • abstract away constraints into a common representation, and then simulate that

                ❌ Distinct constraint types

                When we first started drafting architecture diagrams, the train simulation API directly took -a bunch of constraint types as an input. It brought up a number of issues:

                • the high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types
                • the domain of some of these interactions is very complex (block signaling)
                • when simulating, it does not seem to matter why a constraint is there, only what to do about it

                We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.

                ❌ +a bunch of constraint types as an input. It brought up a number of issues:

                • the high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types
                • the domain of some of these interactions is very complex (block signaling)
                • when simulating, it does not seem to matter why a constraint is there, only what to do about it

                We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.

                ❌ Internal constraint types abstraction

                We then realized that abstracting over constraint types during simulation had immense benefits:

                • it allows expressing requirements on what constraints need to be enforceable
                • it greatly simplifies the process of validating constraint semantics: instead of having to validate interactions between every possible type of constraints, we only have to validate that the semantics of each constraint type can be transferred to the abstract constraint type

                We decided to explore the possibility of keeping constraint types distinct in the external API, -but lowering these constraints into an intermediary representation internally. We found a number of downsides:

                • the public simulation API would still bear the complexity of dealing with many constraint types
                • there would be a need to incrementally generate internal abstracted constraints to support the incremental API

                ✅ +but lowering these constraints into an intermediary representation internally. We found a number of downsides:

                • the public simulation API would still bear the complexity of dealing with many constraint types
                • there would be a need to incrementally generate internal abstracted constraints to support the incremental API

                ✅ External constraint types abstraction

                We tried to improve over the previous proposal by moving the burden of converting many constraints into a common abstraction out of the simulation API.

                Instead of having many constraint types as an input, the simulation API takes a collection of a single abstract constraint type. The task of converting domain constraints to abstract driving instructions is left to the API user.

                We found that doing so:

                • reduces the API surface of the train simulation module
                • decouples behavior from constraint types: if a new constraint type needs to be added, the simulation API only needs expansion if the expected behavior expected for this constraint isn’t part of the API.

                Interpreting driving instructions

                As the train progresses through the simulation, it reacts according to driving instructions @@ -181,12 +181,12 @@ RK4. Such estimator then needs to call f multiple times.

                A number of questions came up:

                • should numerical integration within the driver behavior module, or outside
                • are driver behavior modules queried about their reaction to a specific instruction, or in general
                • does the driver behavior module return decisions, or parameters used to make decisions (such as curves)
                • if decisions are returned, is it a force, an acceleration, or a new state
                • if a new state is returned, how to deal with heterogenous time steps
                • do we check decisions for correctness? that is, if a decision causes the train to overshoot a limit curve, do we do anything?

                Do we have a single DBM for all driving instructions, or one per driving instruction?

                We identified that this API choice shouldn’t constrain the implementation. We decided to go the conservative route and have one DBM per driving instructions as it reduces the API surface -and relieves DBM from the responsibility of finding the most restrictive instruction.

                How do we prevent overshooting?

                We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).

                To do so we could either:

                1. Have a way to short-circuit our integration scheme, to snap to target curves without overshooting.
                2. Accept oscillations around target curves (and thus overshooting).
                3. Setup a feedback loop mechanism to avoid overshooting.

                We decided that only the first option was desirable.

                The design choices then are:

                ❌ +and relieves DBM from the responsibility of finding the most restrictive instruction.

                How do we prevent overshooting?

                We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).

                To do so we could either:

                1. Have a way to short-circuit our integration scheme, to snap to target curves without overshooting.
                2. Accept oscillations around target curves (and thus overshooting).
                3. Setup a feedback loop mechanism to avoid overshooting.

                We decided that only the first option was desirable.

                The design choices then are:

                ❌ Make the DBM as close as possible to a decision function

                Then the DBM would not be aware of the time step it is called with, and would return an acceleration. Then the module should expose two methods:

                • One for taking decisions, akin to f.
                  Called several times depending on the integration method.

                • One for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves -(for example MARECO which sets it’s own speed limits).
                  Called on the integration step results from this DBM, and the other DBMs integration step results.

                ✅ +(for example MARECO which sets it’s own speed limits).
                Called on the integration step results from this DBM, and the other DBMs integration step results.

                ✅ The DBM returns a new state

                The module would then expose two methods:

                • One for taking decisions, which, given a train state and a desired/maximum time step, returns a new state (which does not overshoot) and a new current time.

                • One for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves (for example MARECO which sets it’s own speed limits).
                  Called only on other DBMs integration step results.

                How do we combine the decisions from all DBMs?

                1. For each state property, find the most constraining value and dt.
                2. Find the smallest dt amongst constraining properties. Interpolate remaining properties to this dt, to build a provisional state.
                3. Submit this provisional state for truncation to all DBMs and take the truncation with the smallest dt.

                To understand how this algorithm is designed, we need to consider two example cases:

                • For steps 1 and 2: if a neutral zone and a breaking instruction overlap, both are most constraining to different state properties: the neutral zone affects pantograph state, and the breaking instruction affects speed. The final state has to be a combination of both.
                • For step 3: We need to truncate integration steps to avoid overshoots, and thus avoid the need for feedback loops. Ideally, we want to truncate to the exact overshoot location. This overshoot location is not the same as the initial dt for the overshot constraint.

                Should truncate_integration_step depend on the driver behavior module?

                Yes: DBMs may use internal representations that the new state should not overshoot. For instance, when passed a driving instruction with a speed limit of 60km/h, -a DBM wishing to lose time may reduce the speed to 50 km/h.

                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +a DBM wishing to lose time may reduce the speed to 50 km/h.

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/train-sim-v3/driver-behavior-modules/index.html b/en/docs/reference/design-docs/train-sim-v3/driver-behavior-modules/index.html index 33b4bc655..cf745ead6 100644 --- a/en/docs/reference/design-docs/train-sim-v3/driver-behavior-modules/index.html +++ b/en/docs/reference/design-docs/train-sim-v3/driver-behavior-modules/index.html @@ -7,7 +7,7 @@ To perform this critical task, it needs access to additional context: the physical properties of the path, which are used to make coasting decisions, and to model natural forces. a slowdown coefficient, which is used to adjust how much the train is slowed down compared to a full power simulation.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/train-sim-v3/driving-instruction/index.html b/en/docs/reference/design-docs/train-sim-v3/driving-instruction/index.html index 627cbe562..b7604d1ef 100644 --- a/en/docs/reference/design-docs/train-sim-v3/driving-instruction/index.html +++ b/en/docs/reference/design-docs/train-sim-v3/driving-instruction/index.html @@ -7,7 +7,7 @@ unsignaled line speed limits permanent signaled speed limits temporary speed limits dynamic signaling: block / moving block dynamically signaled speed restrictions neutral zones stops margins There are two types of driving instructions: Abstract driving instructions model the high-level, rolling stock independent range of acceptable behavior: reach 30km/h at this location Concrete driving instructions model the specific range of acceptable behavior for a specific rolling stock, using limit curves: don’t go faster than this curve flowchart TD Constraint[constraint] AbstractDrivingInstruction[abstract driving instruction] ConcreteDrivingInstruction[concrete driving instruction] RollingStockIntegrator[rolling stock integrator] Compiler([compiler]) Constraint -- generates one or more --> AbstractDrivingInstruction AbstractDrivingInstruction --> Compiler RollingStockIntegrator --> Compiler Compiler --> ConcreteDrivingInstruction After reviewing the design document, the necessity to distinguish between abstract and concrete driving instructions was questioned.">
                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +adding some kind of priority / rank field, which was adopted \ No newline at end of file diff --git a/en/docs/reference/design-docs/train-sim-v3/index.html b/en/docs/reference/design-docs/train-sim-v3/index.html index 0a295e3a2..7c6c45cf6 100644 --- a/en/docs/reference/design-docs/train-sim-v3/index.html +++ b/en/docs/reference/design-docs/train-sim-v3/index.html @@ -1,5 +1,5 @@ Train simulation v3 | OSRD -
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/train-sim-v3/index.xml b/en/docs/reference/design-docs/train-sim-v3/index.xml index 534920a93..228aa9a51 100644 --- a/en/docs/reference/design-docs/train-sim-v3/index.xml +++ b/en/docs/reference/design-docs/train-sim-v3/index.xml @@ -308,7 +308,7 @@ Meanwhile, to simulate train behavior, we figured out that we need to know which <li>either treat each type of constraint as its own thing during the simulation</li> <li>abstract away constraints into a common representation, and then simulate that</li> </ul> -<h4 id="hahahugoshortcode182s1hbhb-distinct-constraint-types">❌ +<h4 id="hahahugoshortcode184s1hbhb-distinct-constraint-types">❌ Distinct constraint types</h4> <p>When we first started drafting architecture diagrams, the train simulation API directly took a bunch of constraint types as an input. It brought up a number of issues:</p> @@ -318,7 +318,7 @@ a bunch of constraint types as an input. It brought up a number of issues:</p <li>when simulating, it does not seem to matter why a constraint is there, only what to do about it</li> </ul> <p>We couldn&rsquo;t find clear benefits to dragging distinctions between constraint types deep into the implementation.</p> -<h4 id="hahahugoshortcode182s2hbhb-internal-constraint-types-abstraction">❌ +<h4 id="hahahugoshortcode184s2hbhb-internal-constraint-types-abstraction">❌ Internal constraint types abstraction</h4> <p>We then realized that abstracting over constraint types during simulation had immense benefits:</p> <ul> @@ -333,7 +333,7 @@ but lowering these constraints into an intermediary representation internally. W <li>the public simulation API would still bear the complexity of dealing with many constraint types</li> <li>there would be a need to incrementally generate internal abstracted constraints to support the incremental API</li> </ul> -<h4 id="hahahugoshortcode182s3hbhb-external-constraint-types-abstraction">✅ +<h4 id="hahahugoshortcode184s3hbhb-external-constraint-types-abstraction">✅ External constraint types abstraction</h4> <p>We tried to improve over the previous proposal by moving the burden of converting many constraints into a common abstraction out of the simulation API.</p> <p>Instead of having many constraint types as an input, the simulation API takes a collection of a single abstract constraint type. The task of converting @@ -521,7 +521,7 @@ and relieves DBM from the responsibility of finding the most restrictive instruc </ol> <p>We decided that only the first option was desirable.</p> <p>The design choices then are:</p> -<h5 id="hahahugoshortcode180s3hbhb-make-the-dbm-as-close-as-possible-to-a-decision-function">❌ +<h5 id="hahahugoshortcode182s3hbhb-make-the-dbm-as-close-as-possible-to-a-decision-function">❌ Make the DBM as close as possible to a decision function</h5> <p>Then the DBM would not be aware of the time step it is called with, and would return an acceleration. Then the module should expose two methods:</p> <ul> @@ -535,7 +535,7 @@ Called several times depending on the integration method.</p> Called on the integration step results from this DBM, and the other DBMs integration step results.</p> </li> </ul> -<h5 id="hahahugoshortcode180s4hbhb-the-dbm-returns-a-new-state">✅ +<h5 id="hahahugoshortcode182s4hbhb-the-dbm-returns-a-new-state">✅ The DBM returns a new state</h5> <p>The module would then expose two methods:</p> <ul> diff --git a/en/docs/reference/design-docs/train-sim-v3/overview/index.html b/en/docs/reference/design-docs/train-sim-v3/overview/index.html index 5b3a6375f..887d1e962 100644 --- a/en/docs/reference/design-docs/train-sim-v3/overview/index.html +++ b/en/docs/reference/design-docs/train-sim-v3/overview/index.html @@ -11,7 +11,7 @@ handle reactions to signaling handle rich train state (pantograph position, battery state) allow for different margin algorithms integrate driver behavior properties be easy to integrate with timetable v2 handle both: simulations of a full trip, with a complete known path, possibly following a schedule simulations where the path is discovered incrementally provide a low-level API, usable independently In the long-term, this system is also expected to:">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/design-docs/train-sim-v3/prior-art/index.html b/en/docs/reference/design-docs/train-sim-v3/prior-art/index.html index 913e86a93..f3309b33c 100644 --- a/en/docs/reference/design-docs/train-sim-v3/prior-art/index.html +++ b/en/docs/reference/design-docs/train-sim-v3/prior-art/index.html @@ -7,7 +7,7 @@ The previous implementation cannot be changed to: react to signaling, as constraints stay the same as the simulation evolves handle rich train state vectors, due to the way margins are implemented be usable for both incremental simulation and batch These limitations are the primary reasons for this redesign.">
                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/docs/reference/index.html b/en/docs/reference/index.html index aca52593f..8ab2f3604 100644 --- a/en/docs/reference/index.html +++ b/en/docs/reference/index.html @@ -1,5 +1,5 @@ Technical reference | OSRD -

                Technical reference

                Internal machinery and APIs

                Technical reference guides contain technical reference for APIs and other aspects of OSRD’s machinery. They describe how it works and how to use it but assume that you have a basic understanding of key concepts.

                Architecture

                Learn more about OSRD architecture

                Design documents

                Learn more about how the software was designed

                APIs

                Programming interfaces specifications

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/index.html b/en/index.html index 1a4e18396..69019a275 100644 --- a/en/index.html +++ b/en/index.html @@ -1,5 +1,5 @@ OSRD -

                Open Source Railway Designer

                About +

                Open Source Railway Designer

                About Github

                An open source web application for railway infrastructure design, capacity analysis, timetabling and more!

                Railway design

                		Design railway infrastructure and timetables

                Capacity Analysis

                		Detect conflicts and visualize capacity

                Short-term planning

                		Automatically add new trains to an existing timetable
@@ -9,4 +9,4 @@

                Sponsors

                Ministère chargé des Transports European Union -SNCF Réseau

                © 2024 OSRD contributors. All Rights Reserved
                \ No newline at end of file +SNCF Réseau

                © 2025 OSRD contributors. All Rights Reserved
                \ No newline at end of file diff --git a/en/join-us/_print/index.html b/en/join-us/_print/index.html index 04a435311..ab457d12e 100644 --- a/en/join-us/_print/index.html +++ b/en/join-us/_print/index.html @@ -1,3 +1,3 @@ Join us | OSRD -

                This is the multi-page printable view of this section. -Click here to print.

                Return to the regular view of this page.

                Join us

                  The team dedicated to OSRD within SNCF Réseau is always keen to hear from new profiles: if working on the project motivates you, send us a message on contact@osrd.fr!

                  © 2024 OSRD contributors. All Rights Reserved
                  \ No newline at end of file +

                  This is the multi-page printable view of this section. +Click here to print.

                  Return to the regular view of this page.

                  Join us

                    The team dedicated to OSRD within SNCF Réseau is always keen to hear from new profiles: if working on the project motivates you, send us a message on contact@osrd.fr!

                    © 2025 OSRD contributors. All Rights Reserved
                    \ No newline at end of file diff --git a/en/join-us/index.html b/en/join-us/index.html index ffee01e7b..489ecd056 100644 --- a/en/join-us/index.html +++ b/en/join-us/index.html @@ -1,7 +1,7 @@ Join us | OSRD -

                    Join us

                    The team dedicated to OSRD within SNCF Réseau is always keen to hear from new profiles: if working on the project motivates you, send us a message on contact@osrd.fr!

                    © 2025 OSRD contributors. All Rights Reserved
                    \ No newline at end of file diff --git a/en/sitemap.xml b/en/sitemap.xml index 3180db4de..90e682b65 100644 --- a/en/sitemap.xml +++ b/en/sitemap.xml @@ -1 +1 @@ -https://osrd.fr/en/docs/guides/contribute/contribute-code/general-principles/https://osrd.fr/en/docs/guides/contribute/preamble/https://osrd.fr/en/docs/guides/contribute/contribute-code/backend-conventions/https://osrd.fr/en/docs/guides/contribute/contribute-code/frontend-conventions/https://osrd.fr/en/docs/guides/contribute/license-and-set-up/https://osrd.fr/en/docs/guides/contribute/contribute-code/https://osrd.fr/en/docs/guides/contribute/contribute-code/write-code/https://osrd.fr/en/docs/guides/contribute/contribute-code/commit-conventions/https://osrd.fr/en/docs/guides/contribute/code-review/https://osrd.fr/en/docs/guides/contribute/bug-reports/https://osrd.fr/en/docs/guides/contribute/contribute-code/share-changes/https://osrd.fr/en/docs/guides/contribute/contribute-code/tests/https://osrd.fr/en/docs/reference/design-docs/stdcm/domain_context/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/https://osrd.fr/en/docs/explanation/running_time_calculation/physical_modeling/https://osrd.fr/en/docs/explanation/containers-architecture/https://osrd.fr/en/docs/guides/contribute/https://osrd.fr/en/docs/guides/deploy/https://osrd.fr/en/docs/guides/deploy/docker-compose/https://osrd.fr/en/docs/reference/design-docs/auth/editoast-internal-api/https://osrd.fr/en/docs/guides/deploy/kubernetes/https://osrd.fr/en/docs/guides/logo/https://osrd.fr/en/docs/guides/design/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/overview/https://osrd.fr/en/docs/guides/release/https://osrd.fr/en/docs/reference/design-docs/signaling/signaling-systems/https://osrd.fr/en/docs/guides/deploy/stdcm-search-env/https://osrd.fr/en/docs/guides/contribute/install-docker/https://osrd.fr/en/blog/news/2023-07-19T00:00:00+00:00https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/https://osrd.fr/en/docs/explanation/running_time_calculation/numerical_integration/https://osrd.fr/en/docs/reference/design-docs/signaling/blocks-and-signals/https://osrd.fr/en/docs/explanation/https://osrd.fr/en/docs/explanation/models/data-models-full-example/https://osrd.fr/en/docs/explanation/models/https://osrd.fr/en/docs/explanation/models/neutral_sections/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/prior-art/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/https://osrd.fr/en/docs/explanation/running_time_calculation/envelopes_system/https://osrd.fr/en/docs/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/driving-instruction/https://osrd.fr/en/docs/guides/https://osrd.fr/en/docs/explanation/running_time_calculation/https://osrd.fr/en/docs/reference/design-docs/signaling/speed-limits/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/https://osrd.fr/en/docs/explanation/running_time_calculation/pipeline/https://osrd.fr/en/docs/reference/architecture/https://osrd.fr/en/docs/reference/design-docs/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/driver-behavior-modules/https://osrd.fr/en/about/governance/https://osrd.fr/en/docs/explanation/netzgrafik-editor/https://osrd.fr/en/docs/reference/https://osrd.fr/en/docs/reference/architecture/data_flow/https://osrd.fr/en/docs/reference/architecture/services/https://osrd.fr/en/docs/reference/design-docs/signaling/https://osrd.fr/en/docs/reference/design-docs/conflict-detection/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/https://osrd.fr/en/docs/explanation/running_time_calculation/allowances/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/https://osrd.fr/en/docs/reference/design-docs/stdcm/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/https://osrd.fr/en/docs/reference/apis/https://osrd.fr/en/docs/railway-wiki/https://osrd.fr/en/docs/reference/design-docs/timetable/https://osrd.fr/en/about/use-case/https://osrd.fr/en/docs/reference/design-docs/auth/https://osrd.fr/en/docs/reference/design-docs/signaling/simulation/https://osrd.fr/en/docs/railway-wiki/glossary/https://osrd.fr/en/docs/reference/design-docs/scalable-async-rpc/https://osrd.fr/en/about/opensource/https://osrd.fr/en/about/opendata/https://osrd.fr/en/about/roadmap/https://osrd.fr/en/docs/railway-wiki/signalling/spacing/ertms/etcs/https://osrd.fr/en/blog/2023-07-19T00:00:00+00:00https://osrd.fr/en/2023-07-19T00:00:00+00:00https://osrd.fr/en/blog/2023/07/19/osrd-at-dreil%C3%A4nder-hack-in-wien/2023-07-19T00:00:00+00:00https://osrd.fr/en/blog/2023/04/12/dgex-solutions-forum/2023-04-12T00:00:00+00:00https://osrd.fr/en/blog/2023/02/03/openstreetmap-and-open-data-talk-at-fosdem-2023/2023-02-03T00:00:00+00:00https://osrd.fr/en/docs/guides/contribute/review-process/https://osrd.fr/en/about/https://osrd.fr/en/categories/https://osrd.fr/en/docs/reference/apis/editoast/https://osrd.fr/en/docs/railway-wiki/signalling/spacing/ertms/https://osrd.fr/en/docs/reference/apis/gateway/https://osrd.fr/en/join-us/https://osrd.fr/en/tags/ \ No newline at end of file +https://osrd.fr/en/docs/guides/contribute/contribute-code/general-principles/https://osrd.fr/en/docs/guides/contribute/preamble/https://osrd.fr/en/docs/guides/release/process/https://osrd.fr/en/docs/guides/contribute/contribute-code/backend-conventions/https://osrd.fr/en/docs/guides/contribute/contribute-code/frontend-conventions/https://osrd.fr/en/docs/guides/contribute/license-and-set-up/https://osrd.fr/en/docs/guides/release/publish/https://osrd.fr/en/docs/guides/contribute/contribute-code/https://osrd.fr/en/docs/guides/contribute/contribute-code/write-code/https://osrd.fr/en/docs/guides/contribute/contribute-code/commit-conventions/https://osrd.fr/en/docs/guides/contribute/code-review/https://osrd.fr/en/docs/guides/contribute/bug-reports/https://osrd.fr/en/docs/guides/contribute/contribute-code/share-changes/https://osrd.fr/en/docs/guides/contribute/contribute-code/tests/https://osrd.fr/en/docs/reference/design-docs/stdcm/domain_context/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/https://osrd.fr/en/docs/explanation/running_time_calculation/physical_modeling/https://osrd.fr/en/docs/explanation/containers-architecture/https://osrd.fr/en/docs/guides/contribute/https://osrd.fr/en/docs/guides/deploy/https://osrd.fr/en/docs/guides/deploy/docker-compose/https://osrd.fr/en/docs/reference/design-docs/auth/editoast-internal-api/https://osrd.fr/en/docs/guides/deploy/kubernetes/https://osrd.fr/en/docs/guides/logo/https://osrd.fr/en/docs/guides/design/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/overview/https://osrd.fr/en/docs/guides/release/https://osrd.fr/en/docs/reference/design-docs/signaling/signaling-systems/https://osrd.fr/en/docs/guides/deploy/stdcm-search-env/https://osrd.fr/en/docs/guides/contribute/install-docker/https://osrd.fr/en/blog/news/2023-07-19T00:00:00+00:00https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/https://osrd.fr/en/docs/explanation/running_time_calculation/numerical_integration/https://osrd.fr/en/docs/reference/design-docs/signaling/blocks-and-signals/https://osrd.fr/en/docs/explanation/https://osrd.fr/en/docs/explanation/models/data-models-full-example/https://osrd.fr/en/docs/explanation/models/https://osrd.fr/en/docs/explanation/models/neutral_sections/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/prior-art/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/https://osrd.fr/en/docs/explanation/running_time_calculation/envelopes_system/https://osrd.fr/en/docs/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/driving-instruction/https://osrd.fr/en/docs/guides/https://osrd.fr/en/docs/explanation/running_time_calculation/https://osrd.fr/en/docs/reference/design-docs/signaling/speed-limits/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/https://osrd.fr/en/docs/explanation/running_time_calculation/pipeline/https://osrd.fr/en/docs/reference/architecture/https://osrd.fr/en/docs/reference/design-docs/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/driver-behavior-modules/https://osrd.fr/en/about/governance/https://osrd.fr/en/docs/explanation/netzgrafik-editor/https://osrd.fr/en/docs/reference/https://osrd.fr/en/docs/reference/architecture/data_flow/https://osrd.fr/en/docs/reference/architecture/services/https://osrd.fr/en/docs/reference/design-docs/signaling/https://osrd.fr/en/docs/reference/design-docs/conflict-detection/https://osrd.fr/en/docs/reference/design-docs/train-sim-v3/https://osrd.fr/en/docs/explanation/running_time_calculation/allowances/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/https://osrd.fr/en/docs/reference/design-docs/stdcm/https://osrd.fr/en/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/https://osrd.fr/en/docs/reference/apis/https://osrd.fr/en/docs/railway-wiki/https://osrd.fr/en/docs/reference/design-docs/timetable/https://osrd.fr/en/about/use-case/https://osrd.fr/en/docs/reference/design-docs/auth/https://osrd.fr/en/docs/reference/design-docs/signaling/simulation/https://osrd.fr/en/docs/railway-wiki/glossary/https://osrd.fr/en/docs/reference/design-docs/scalable-async-rpc/https://osrd.fr/en/about/opensource/https://osrd.fr/en/about/opendata/https://osrd.fr/en/about/roadmap/https://osrd.fr/en/docs/railway-wiki/signalling/spacing/ertms/etcs/https://osrd.fr/en/blog/2023-07-19T00:00:00+00:00https://osrd.fr/en/2023-07-19T00:00:00+00:00https://osrd.fr/en/blog/2023/07/19/osrd-at-dreil%C3%A4nder-hack-in-wien/2023-07-19T00:00:00+00:00https://osrd.fr/en/blog/2023/04/12/dgex-solutions-forum/2023-04-12T00:00:00+00:00https://osrd.fr/en/blog/2023/02/03/openstreetmap-and-open-data-talk-at-fosdem-2023/2023-02-03T00:00:00+00:00https://osrd.fr/en/docs/guides/contribute/review-process/https://osrd.fr/en/about/https://osrd.fr/en/categories/https://osrd.fr/en/docs/reference/apis/editoast/https://osrd.fr/en/docs/railway-wiki/signalling/spacing/ertms/https://osrd.fr/en/docs/reference/apis/gateway/https://osrd.fr/en/join-us/https://osrd.fr/en/tags/ \ No newline at end of file diff --git a/en/tags/index.html b/en/tags/index.html index f15866177..3737ba391 100644 --- a/en/tags/index.html +++ b/en/tags/index.html @@ -1,2 +1,2 @@ Tags | OSRD -

                    Tags

                    © 2024 OSRD contributors. All Rights Reserved
                    \ No newline at end of file +

                    Tags

                    © 2025 OSRD contributors. All Rights Reserved
                    \ No newline at end of file diff --git a/fr/404.html b/fr/404.html index 0fb07137f..bafc5efaa 100644 --- a/fr/404.html +++ b/fr/404.html @@ -1,2 +1,2 @@ 404 Page not found | OSRD -

                    Not found

                    Oops! This page doesn't exist. Try going back to our home page.

                    You can learn how to make a 404 page like this in Custom 404 Pages.

                    © 2024 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file +

                    Not found

                    Oops! This page doesn't exist. Try going back to our home page.

                    You can learn how to make a 404 page like this in Custom 404 Pages.

                    © 2025 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file diff --git a/fr/about/_print/index.html b/fr/about/_print/index.html index 9632c8c26..79e83eaf0 100644 --- a/fr/about/_print/index.html +++ b/fr/about/_print/index.html @@ -1,5 +1,5 @@ À propos | OSRD -

                    Version imprimable multipages. +

                    Version imprimable multipages. Cliquer ici pour imprimer.

                    Retour à la version par défaut.

                    À propos

                    OSRD est une suite d’outils ferroviaires pour différents cas d’utilisation. Ces outils sont basés sur la simulation de l’infrastructure ferroviaire ainsi que son analyse.

                    1 - Gouvernance

                    Organisation et gouvernance d’OSRD

                    Une des ambitions d’OSRD est d’aider à la planification horaire à l’échelle européenne.

                    Pour atteindre cet objectif, OSRD doit tenir compte des spécificités locales en consultant et collaborant avec les compagnies ferroviaires et les gestionnaires d’infrastructure.

                    En échange de leur contribution, ces entreprises :

                    • Profitent des efforts de développement commun ;
                    • Peuvent se baser sur les outils communs pour créer les leurs1 ;
                    • Participent à la feuille de route et à la direction technique du projet à la mesure de leur contribution.

                    OSRD est actuellement développé par:

                    L’association Open Rail

                    La association Open Rail est une association à but non lucratif en cours de création ayant pour objectif d’organiser le travail autour d’outils logiciels communs au monde du ferroviaire.

                    Association OpenRail

                    1. Tant qu’elles ne modifient pas les outils communs sans partager leurs améliorations, voir les détails de la license LGPLv3. ↩︎

                    2 - Cas d'utilisation

                    Applications et axes directeurs

                    OSRD presentation

                    Le projet a pour ambition de répondre à une large gamme de besoins autour de la planification ferroviaire :

                    produits OSRD

                    Conception des plans de transport

                    La conception de plans de transport consiste à formuler une réponse1 aux schémas de dessertes2. OSRD fournit déjà un certain nombre de fonctionnalités utiles à cette fin :

                    • base d’infrastructure ferroviaire à la voie
                    • base de données de matériel roulant
                    • possibilité de modifier l’infrastructure
                    • visualisation de grilles horaires
                    • application de différents types de marges sur les sillons, y compris une marge économique, qui minimise l’énergie consommée

                    Les perspectives futures comprennent notamment :

                    • la détection automatique de conflits3
                    • synthèse d’infrastructure à la ligne à partir d’infrastructure à la voie
                    • visualisation schématique du plan de transport
                    • module d’optimisation de la capacité en ligne, d’occupation de la voie en gare et de roulement matériel

                    Études d’exploitation

                    Les études d’exploitation permettent d’évaluer la capacité de l’infrastructure à @@ -25,4 +25,4 @@ Les mainteneurs sont responsables de la cohérence technique du projet, et obtiennent cette position par consensus. L’intégration des changement n’est motivée que par leur viabilité technique : l’objectif des mainteneurs et reviewers est de s’assurer que le projet reste de bonne qualité.

                    1. Le code source est un ensemble de documents texte qui définit comment fonctionne une application. C’est le produit du travail de développeurs logiciels. ↩︎

                    4 - Open Data

                    OSRD et l’Open Data

                    L’open data, c’est la pratique de rendre publiquement accessible des données sous une license permissive. C’est une pratique distincte de l’open source, qui ne s’applique qu’au logiciel.

                    Open data et open source ont une relation symbiotique : sans Open Data, un logiciel open source ferroviaire n’est utilisable que par des initiés. Gérer l’accès aux données est difficile, coûteux, souvent inutile, et réduit l’accessibilité de données pourtant essentielles.

                    Seul, l’open data présente déjà un certain nombre d’avantages clés :

                    • des entreprises peuvent utiliser ces données dans leur produit, ce qui promeut les services ferroviaires
                    • des chercheurs peuvent étudier les données sans démarche particulière, et découvrir eux-même les données disponibles

                    Des données open data exploitées par une suite d’outils open source ouvrent de nouveaux horizons :

                    • les chercheurs et entreprises peuvent maintenant exploiter les données sans avoir à créer leurs propres outils, ou en acquérir par leurs propres moyens
                    • les clients de l’entreprise peuvent utiliser outils et données pour améliorer leur usage des services

                    Si plusieurs acteurs mettent en open data des données exploitables par un même logiciel open source, il devient également possible de recouper les données et de fournir et plannifier des services communs.

                    Dans le cadre d’OSRD

                    • si les données de matériel roulant et d’infrastructure sont en open data, alors il est possible pour tous de simuler des trajets, d’étudier et évaluer le réseau ferroviaire
                    • si les données de grilles horaires sont accessibles en open data, alors il est possible pour tous d’étudier l’usage du réseau

                    5 - Roadmap

                    Roadmap macroscopique

                    Voici une liste des principales fonctionnalités que OSRD souhaite ajouter, par ordre de priorité. -Cette feuille de route s’étale sur plusieurs années.

                    • Ajout du système de signalisation [ERTMS] (https://fr.wikipedia.org/wiki/Syst%C3%A8me_europ%C3%A9en_de_gestion_du_trafic_ferroviaire).
                    • Système de permission fin.
                    • Support du cadencement des trains. Améliorer l’intégration de Netzgrafik-Editor.
                    • Envoyer des trains STDCM à des services externes pour stockage et traitement.
                    • Création d’un plan de transport annuel.
                    • Support d’un système de référencement linéaire LRS couramment utilisé dans l’industrie ferroviaire. Utilisation de point kilométrique.
                    • Refonte de l’éditeur d’infrastructure.
                    • Ajout d’un simulateur dynamique. Simuler une grille horaire sur une infrastructure et observer les retards générés.
                    • Gestion de version des infrastructures.
                    • Refonte du calcul de marche.

                    Si vous souhaitez pousser l’une de ces fonctionnalités, ou si vous avez des idées sur ce que OSRD pourrait faire à l’avenir, n’hésitez pas à rejoindre le projet !

                    © 2024 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file +Cette feuille de route s’étale sur plusieurs années.

                    • Ajout du système de signalisation [ERTMS] (https://fr.wikipedia.org/wiki/Syst%C3%A8me_europ%C3%A9en_de_gestion_du_trafic_ferroviaire).
                    • Système de permission fin.
                    • Support du cadencement des trains. Améliorer l’intégration de Netzgrafik-Editor.
                    • Envoyer des trains STDCM à des services externes pour stockage et traitement.
                    • Création d’un plan de transport annuel.
                    • Support d’un système de référencement linéaire LRS couramment utilisé dans l’industrie ferroviaire. Utilisation de point kilométrique.
                    • Refonte de l’éditeur d’infrastructure.
                    • Ajout d’un simulateur dynamique. Simuler une grille horaire sur une infrastructure et observer les retards générés.
                    • Gestion de version des infrastructures.
                    • Refonte du calcul de marche.

                    Si vous souhaitez pousser l’une de ces fonctionnalités, ou si vous avez des idées sur ce que OSRD pourrait faire à l’avenir, n’hésitez pas à rejoindre le projet !

                    © 2025 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file diff --git a/fr/about/governance/index.html b/fr/about/governance/index.html index a0832a536..b3ebcd0c4 100644 --- a/fr/about/governance/index.html +++ b/fr/about/governance/index.html @@ -1,5 +1,5 @@ Gouvernance | OSRD -

                    Gouvernance

                    Organisation et gouvernance d’OSRD

                    Une des ambitions d’OSRD est d’aider à la planification horaire à l’échelle européenne.

                    Pour atteindre cet objectif, OSRD doit tenir compte des spécificités locales en consultant et collaborant avec les compagnies ferroviaires et les gestionnaires d’infrastructure.

                    En échange de leur contribution, ces entreprises :

                    • Profitent des efforts de développement commun ;
                    • Peuvent se baser sur les outils communs pour créer les leurs1 ;
                    • Participent à la feuille de route et à la direction technique du projet à la mesure de leur contribution.

                    OSRD est actuellement développé par:

                    L’association Open Rail

                    La association Open Rail est une association à but non lucratif en cours de création ayant pour objectif d’organiser le travail autour d’outils logiciels communs au monde du ferroviaire.

                    Association OpenRail

                    1. Tant qu’elles ne modifient pas les outils communs sans partager leurs améliorations, voir les détails de la license LGPLv3. ↩︎

                    © 2025 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file diff --git a/fr/about/index.html b/fr/about/index.html index 77821b1a3..2a4da48e5 100644 --- a/fr/about/index.html +++ b/fr/about/index.html @@ -1,5 +1,5 @@ À propos | OSRD -

                    À propos

                    OSRD est une suite d’outils ferroviaires pour différents cas d’utilisation. Ces outils sont basés sur la simulation de l’infrastructure ferroviaire ainsi que son analyse.

                    Gouvernance

                    Organisation et gouvernance d’OSRD

                    Cas d'utilisation

                    Applications et axes directeurs

                    Open Source

                    OSRD et l’Open Source

                    Open Data

                    OSRD et l’Open Data

                    Roadmap

                    Roadmap macroscopique

                    © 2025 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file diff --git a/fr/about/opendata/index.html b/fr/about/opendata/index.html index e27cd991b..8826526fc 100644 --- a/fr/about/opendata/index.html +++ b/fr/about/opendata/index.html @@ -1,5 +1,5 @@ Open Data | OSRD -
                    © 2025 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file diff --git a/fr/about/opensource/index.html b/fr/about/opensource/index.html index c36038d61..5c78bbe8a 100644 --- a/fr/about/opensource/index.html +++ b/fr/about/opensource/index.html @@ -1,5 +1,5 @@ Open Source | OSRD -
                    © 2025 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file diff --git a/fr/about/roadmap/index.html b/fr/about/roadmap/index.html index e2ff821fd..79a8434d7 100644 --- a/fr/about/roadmap/index.html +++ b/fr/about/roadmap/index.html @@ -1,5 +1,5 @@ Roadmap | OSRD -
                    © 2025 Contributeurs à OSRD. Tous droits réservés
                    \ No newline at end of file diff --git a/fr/about/use-case/_print/index.html b/fr/about/use-case/_print/index.html index a1f997277..2fafab90a 100644 --- a/fr/about/use-case/_print/index.html +++ b/fr/about/use-case/_print/index.html @@ -1,5 +1,5 @@ Cas d'utilisation | OSRD -

                    Version imprimable multipages. +

                    Version imprimable multipages. Cliquer ici pour imprimer.

                    Retour à la version par défaut.

                    Cas d'utilisation

                    Applications et axes directeurs

                      OSRD presentation

                      Le projet a pour ambition de répondre à une large gamme de besoins autour de la planification ferroviaire :

                      produits OSRD

                      Conception des plans de transport

                      La conception de plans de transport consiste à formuler une réponse1 aux schémas de dessertes2. OSRD fournit déjà un certain nombre de fonctionnalités utiles à cette fin :

                      • base d’infrastructure ferroviaire à la voie
                      • base de données de matériel roulant
                      • possibilité de modifier l’infrastructure
                      • visualisation de grilles horaires
                      • application de différents types de marges sur les sillons, y compris une marge économique, qui minimise l’énergie consommée

                      Les perspectives futures comprennent notamment :

                      • la détection automatique de conflits3
                      • synthèse d’infrastructure à la ligne à partir d’infrastructure à la voie
                      • visualisation schématique du plan de transport
                      • module d’optimisation de la capacité en ligne, d’occupation de la voie en gare et de roulement matériel

                      Études d’exploitation

                      Les études d’exploitation permettent d’évaluer la capacité de l’infrastructure à @@ -19,4 +19,4 @@ Il est libre, documenté, conçu pour être agnostique au gestionnaire d’infrastructure, facile à générer et manipuler. ↩︎

                    • Un sillon est un droit de passage sur le réseau ferroviaire, inscrit dans l’espace et dans le temps. Il est vendu par un -gestionnaire d’infrastructure (GI) à une entreprise ferroviaire (EF). ↩︎

                      © 2024 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file +gestionnaire d’infrastructure (GI) à une entreprise ferroviaire (EF). ↩︎

                      \ No newline at end of file diff --git a/fr/about/use-case/index.html b/fr/about/use-case/index.html index 321f89b10..11e679c1a 100644 --- a/fr/about/use-case/index.html +++ b/fr/about/use-case/index.html @@ -1,5 +1,5 @@ Cas d'utilisation | OSRD -
                      \ No newline at end of file diff --git "a/fr/blog/2023/02/06/fosdem-2023-osrd-\303\251tait-pr\303\251sent/index.html" "b/fr/blog/2023/02/06/fosdem-2023-osrd-\303\251tait-pr\303\251sent/index.html" index 0075afdde..39678f933 100644 --- "a/fr/blog/2023/02/06/fosdem-2023-osrd-\303\251tait-pr\303\251sent/index.html" +++ "b/fr/blog/2023/02/06/fosdem-2023-osrd-\303\251tait-pr\303\251sent/index.html" @@ -1,5 +1,5 @@ Fosdem 2023 : OSRD était présent ! | OSRD -
                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git "a/fr/blog/2023/02/13/ia-et-pip-4-f\303\251vrier-2023/index.html" "b/fr/blog/2023/02/13/ia-et-pip-4-f\303\251vrier-2023/index.html" index 62210b9c1..b10e57270 100644 --- "a/fr/blog/2023/02/13/ia-et-pip-4-f\303\251vrier-2023/index.html" +++ "b/fr/blog/2023/02/13/ia-et-pip-4-f\303\251vrier-2023/index.html" @@ -3,7 +3,7 @@ Après avoir assisté à la demo de toutes les fonctionnalités développées par nos 3 équipes (PI system demo), nos parties prenantes ont pu évaluer l’atteinte de nos objectifs.">
                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git a/fr/blog/2023/04/12/forum-dgex-solutions/index.html b/fr/blog/2023/04/12/forum-dgex-solutions/index.html index ff5636279..aefc60230 100644 --- a/fr/blog/2023/04/12/forum-dgex-solutions/index.html +++ b/fr/blog/2023/04/12/forum-dgex-solutions/index.html @@ -3,7 +3,7 @@ Mais tout d’abord qu’est ce qu’un sillon ? Il s’agit de la réservation d’espace/temps sur le réseau, par les entreprises ferroviaires (EF), comme SNCF Voyageurs. Ces réservations se font généralement des années en amont (A-3). Les EF peuvent également faire des demandes de sillons en urgence (appelés sillons de dernière minute), de A-1 jusqu’au jour J.">
                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git a/fr/blog/2023/04/24/ia5-et-pip6-avril-2023/index.html b/fr/blog/2023/04/24/ia5-et-pip6-avril-2023/index.html index 220e17afd..3ecc4eaa9 100644 --- a/fr/blog/2023/04/24/ia5-et-pip6-avril-2023/index.html +++ b/fr/blog/2023/04/24/ia5-et-pip6-avril-2023/index.html @@ -3,7 +3,7 @@ Planification de notre 6ème Product Increment (PIP6) !">

                      I&A5 et PIP6 - avril 2023

                      Un I&A prometteur

                      Notre 5ème Inspect & Adapt a commencé avec la présentation de notre PI System demo de l’application OSRD, démontrant l’ensemble des travaux réalisés au cours de ce PI5 par nos équipes. À la suite de cette demo, l’atteinte de nos objectifs (engagés et non engagés) a été évaluée par nos partie-prenantes. Verdict : 113 % de réussite… Si, si, c’est possible 😉 !

                      Planification de notre 6ème Product Increment (PIP6) !

                      Après les traditionnelles séquences portant sur l’évolution de notre contexte de métier et technique, nous avons assisté à l’intervention de François Marchal, Responsable domaine numérique exploitation à la Digit, portant sur les enjeux du numérique au sein de SNCF Réseau et le rôle d’OSRD au sein de l’organisation.

                      Le lendemain, Nathanaël Dias, Chargé d’étude exploitation ferroviaire, nous a présenté son métier, et le processus d’élaboration d’une étude exploitation. Il a insisté sur l’importance de partager les résultats et les travaux.

                      Au cours du PIP, de nouvelles fonctionnalités ont été embarquées par les équipes, et transformées en objectifs à atteindre. Le travail a été planifié pour les 11 semaines à venir et les risques ont été évalués pour être minimisés.

                      Rendez-vous mi-juillet pour le 7ème PIP !

                      image pip 6.1

                      image pip 6.2

                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git "a/fr/blog/2023/07/19/osrd-au-dreil\303\244nder-hack-\303\240-vienne/index.html" "b/fr/blog/2023/07/19/osrd-au-dreil\303\244nder-hack-\303\240-vienne/index.html" index f99d550e4..3656e7418 100644 --- "a/fr/blog/2023/07/19/osrd-au-dreil\303\244nder-hack-\303\240-vienne/index.html" +++ "b/fr/blog/2023/07/19/osrd-au-dreil\303\244nder-hack-\303\240-vienne/index.html" @@ -3,7 +3,7 @@ Nous avons eu le plaisir d&rsquo;être invité·es à participer dans le cadre de l&rsquo;association OpenRail, et le thème de cette année étant &ldquo;Open Railways&rdquo; il aurait été difficile de refuser !">
                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git a/fr/blog/2023/12/13/presentation-osrd-1/index.html b/fr/blog/2023/12/13/presentation-osrd-1/index.html index 477ab0502..3bf0543e0 100644 --- a/fr/blog/2023/12/13/presentation-osrd-1/index.html +++ b/fr/blog/2023/12/13/presentation-osrd-1/index.html @@ -7,7 +7,7 @@ Voici la rediffusion des interventions : Ouverture Présentations OpenRail ">
                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git a/fr/blog/_print/index.html b/fr/blog/_print/index.html index dd1298711..386a54789 100644 --- a/fr/blog/_print/index.html +++ b/fr/blog/_print/index.html @@ -1,5 +1,5 @@ Blog OSRD | OSRD -

                      Version imprimable multipages. +

                      Version imprimable multipages. Cliquer ici pour imprimer.

                      Retour à la version par défaut.

                      Blog OSRD

                      News

                      Présentation OSRD #1

                      Le 13 décembre 2023, l’équipe OSRD a présenté ses premiers résultats lors d’une conférence.

                      Voici la rediffusion des interventions :

                      Ouverture

                      Présentations

                      @@ -19,4 +19,4 @@ Nous nous sommes donc réunis ce lundi 13 février pour clore le 4ème Increment de notre programme (PI 4).

                      Après avoir assisté à la demo de toutes les fonctionnalités développées par nos 3 équipes (PI system demo), nos parties prenantes ont pu évaluer l’atteinte de nos objectifs. Résultat : environ 80% de réussite.

                      Lancement de notre 5ème PIP !

                      Le Product Increment Planning (PIP) est une cérémonie au cours de laquelle les équipes se répartissent le backlog des nouvelles fonctionnalités et planifient leur travail sur les 11 prochaines semaines. Avant d’entamer le travail de planification en sous-groupe, Loïc Hamelin nous a présenté les évolutions du contexte business d’OSRD, retraçant les attentes de nos clients.

                      Dans la matinée du 15 février, Caroline Johnson, Directrice Solutions Numériques Exploitation chez SNCF Réseau, nous a présenté l’offre de service sur la DG-Num et a répondu à nos questions sur l’intégration prochaine de notre application dans le SI interne.

                      A l’issue du PIP, nos business owners ont attribué une valeur, entre 1 et 10, à nos nouveaux objectifs de PI et les risques de programme ont été évalués.

                      Photo du pip 5.1

                      Photo du pip 5.2

                      Photo du pip 5.3

                      Fosdem 2023 : OSRD était présent !

                      fosdem

                      Une Devroom pour l’association Openrail

                      Les 4 et 5 février se tenait le FOSDEM, l’évènement européen annuel incontournable pour la communauté open source. Tout au long de ces 2 jours à Bruxelles, les participants ont pu assister à une variété de conférences et ateliers portant sur les dernières tendances du logiciel libre et de l’open source. -L’un des moments forts de l’événement était le lancement de la Devroom « Opening railways and open transport », portée par la toute nouvelle OpenRail association. Le programme OSRD a eu la chance d’ouvrir cette nouvelle room avec ST DCM.

                      « Short-term digital capacity management » ou le challenge des sillons de dernière minute

                      La conférence d’Eloi Charpentier, intitulée « automated short-term train planning in OSRD » présentait les réflexions issues de nos travaux sur la simulation de sillons de dernière minute. Ou comment permettre aux entreprises de fret ferroviaire d’obtenir des autorisations de circulation de dernière minute évitant les embouteillages sur le réseau, et d’avoir ainsi l’agilité indispensable pour concurrencer le transport routier ?

                      Slides

                      Vidéo

                      fosdem

                      Opendata et cartographie du réseau ferroviaire

                      La présentation de Céline Durupt, “OpenStreetMap, one geographic database to rule them all?” abordait le sujet de l’opendata en matière de réseau ferroviaire. Sur la base d’une analyse européenne, Céline a présenté un plan d’actions pour partager la donnée ferroviaire via OSM et la rendre utilisable par OSRD.

                      Slides

                      Vidéo

                      fosdem

                      Rendez-vous l’année prochaine au FOSDEM 2024 avec des exemples concrets de collaboration et de nouveaux développements d’open source ferroviaire.

                      © 2024 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file +L’un des moments forts de l’événement était le lancement de la Devroom « Opening railways and open transport », portée par la toute nouvelle OpenRail association. Le programme OSRD a eu la chance d’ouvrir cette nouvelle room avec ST DCM.

                      « Short-term digital capacity management » ou le challenge des sillons de dernière minute

                      La conférence d’Eloi Charpentier, intitulée « automated short-term train planning in OSRD » présentait les réflexions issues de nos travaux sur la simulation de sillons de dernière minute. Ou comment permettre aux entreprises de fret ferroviaire d’obtenir des autorisations de circulation de dernière minute évitant les embouteillages sur le réseau, et d’avoir ainsi l’agilité indispensable pour concurrencer le transport routier ?

                      Slides

                      Vidéo

                      fosdem

                      Opendata et cartographie du réseau ferroviaire

                      La présentation de Céline Durupt, “OpenStreetMap, one geographic database to rule them all?” abordait le sujet de l’opendata en matière de réseau ferroviaire. Sur la base d’une analyse européenne, Céline a présenté un plan d’actions pour partager la donnée ferroviaire via OSM et la rendre utilisable par OSRD.

                      Slides

                      Vidéo

                      fosdem

                      Rendez-vous l’année prochaine au FOSDEM 2024 avec des exemples concrets de collaboration et de nouveaux développements d’open source ferroviaire.

                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git a/fr/blog/index.html b/fr/blog/index.html index 19fc01fed..eae717979 100644 --- a/fr/blog/index.html +++ b/fr/blog/index.html @@ -1,5 +1,5 @@ Blog OSRD | OSRD -
                      © 2024 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file +Mais tout d’abord qu’est ce qu’un sillon ? Il s’agit de la réservation d’espace/temps sur le …

                      Lire plus

                    • I&A et PIP 4 - février 2023

                      13.02.2023 dans News

                      I&A février 2023 : ce qu’on retiendra ! L‘Inspect & Adapt est une cérémonie issue du framework d’agilité à l’échelle SAFe (Scaled Agile Framework), au cours de laquelle nous inspectons notre travail réalisé sur les 11 dernières semaines …

                      Lire plus

                    • Fosdem 2023 : OSRD était présent !

                      06.02.2023 dans News

                      Une Devroom pour l’association Openrail Les 4 et 5 février se tenait le FOSDEM, l’évènement européen annuel incontournable pour la communauté open source. Tout au long de ces 2 jours à Bruxelles, les participants ont pu assister à une variété …

                      Lire plus

                      • \ No newline at end of file diff --git a/fr/blog/news/_print/index.html b/fr/blog/news/_print/index.html index ab58ba3e1..63c00ec7f 100644 --- a/fr/blog/news/_print/index.html +++ b/fr/blog/news/_print/index.html @@ -1,5 +1,5 @@ News | OSRD -

                      Version imprimable multipages. +

                      Version imprimable multipages. Cliquer ici pour imprimer.

                      Retour à la version par défaut.

                      News

                      Présentation OSRD #1

                      Le 13 décembre 2023, l’équipe OSRD a présenté ses premiers résultats lors d’une conférence.

                      Voici la rediffusion des interventions :

                      Ouverture

                      Présentations

                      @@ -19,4 +19,4 @@ Nous nous sommes donc réunis ce lundi 13 février pour clore le 4ème Increment de notre programme (PI 4).

                      Après avoir assisté à la demo de toutes les fonctionnalités développées par nos 3 équipes (PI system demo), nos parties prenantes ont pu évaluer l’atteinte de nos objectifs. Résultat : environ 80% de réussite.

                      Lancement de notre 5ème PIP !

                      Le Product Increment Planning (PIP) est une cérémonie au cours de laquelle les équipes se répartissent le backlog des nouvelles fonctionnalités et planifient leur travail sur les 11 prochaines semaines. Avant d’entamer le travail de planification en sous-groupe, Loïc Hamelin nous a présenté les évolutions du contexte business d’OSRD, retraçant les attentes de nos clients.

                      Dans la matinée du 15 février, Caroline Johnson, Directrice Solutions Numériques Exploitation chez SNCF Réseau, nous a présenté l’offre de service sur la DG-Num et a répondu à nos questions sur l’intégration prochaine de notre application dans le SI interne.

                      A l’issue du PIP, nos business owners ont attribué une valeur, entre 1 et 10, à nos nouveaux objectifs de PI et les risques de programme ont été évalués.

                      Photo du pip 5.1

                      Photo du pip 5.2

                      Photo du pip 5.3

                      Fosdem 2023 : OSRD était présent !

                      fosdem

                      Une Devroom pour l’association Openrail

                      Les 4 et 5 février se tenait le FOSDEM, l’évènement européen annuel incontournable pour la communauté open source. Tout au long de ces 2 jours à Bruxelles, les participants ont pu assister à une variété de conférences et ateliers portant sur les dernières tendances du logiciel libre et de l’open source. -L’un des moments forts de l’événement était le lancement de la Devroom « Opening railways and open transport », portée par la toute nouvelle OpenRail association. Le programme OSRD a eu la chance d’ouvrir cette nouvelle room avec ST DCM.

                      « Short-term digital capacity management » ou le challenge des sillons de dernière minute

                      La conférence d’Eloi Charpentier, intitulée « automated short-term train planning in OSRD » présentait les réflexions issues de nos travaux sur la simulation de sillons de dernière minute. Ou comment permettre aux entreprises de fret ferroviaire d’obtenir des autorisations de circulation de dernière minute évitant les embouteillages sur le réseau, et d’avoir ainsi l’agilité indispensable pour concurrencer le transport routier ?

                      Slides

                      Vidéo

                      fosdem

                      Opendata et cartographie du réseau ferroviaire

                      La présentation de Céline Durupt, “OpenStreetMap, one geographic database to rule them all?” abordait le sujet de l’opendata en matière de réseau ferroviaire. Sur la base d’une analyse européenne, Céline a présenté un plan d’actions pour partager la donnée ferroviaire via OSM et la rendre utilisable par OSRD.

                      Slides

                      Vidéo

                      fosdem

                      Rendez-vous l’année prochaine au FOSDEM 2024 avec des exemples concrets de collaboration et de nouveaux développements d’open source ferroviaire.

                      © 2024 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file +L’un des moments forts de l’événement était le lancement de la Devroom « Opening railways and open transport », portée par la toute nouvelle OpenRail association. Le programme OSRD a eu la chance d’ouvrir cette nouvelle room avec ST DCM.

                      « Short-term digital capacity management » ou le challenge des sillons de dernière minute

                      La conférence d’Eloi Charpentier, intitulée « automated short-term train planning in OSRD » présentait les réflexions issues de nos travaux sur la simulation de sillons de dernière minute. Ou comment permettre aux entreprises de fret ferroviaire d’obtenir des autorisations de circulation de dernière minute évitant les embouteillages sur le réseau, et d’avoir ainsi l’agilité indispensable pour concurrencer le transport routier ?

                      Slides

                      Vidéo

                      fosdem

                      Opendata et cartographie du réseau ferroviaire

                      La présentation de Céline Durupt, “OpenStreetMap, one geographic database to rule them all?” abordait le sujet de l’opendata en matière de réseau ferroviaire. Sur la base d’une analyse européenne, Céline a présenté un plan d’actions pour partager la donnée ferroviaire via OSM et la rendre utilisable par OSRD.

                      Slides

                      Vidéo

                      fosdem

                      Rendez-vous l’année prochaine au FOSDEM 2024 avec des exemples concrets de collaboration et de nouveaux développements d’open source ferroviaire.

                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git a/fr/blog/news/index.html b/fr/blog/news/index.html index 23804c41b..5f1fa0fbb 100644 --- a/fr/blog/news/index.html +++ b/fr/blog/news/index.html @@ -1,5 +1,5 @@ News | OSRD -
                      © 2024 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file +Mais tout d’abord qu’est ce qu’un sillon ? Il s’agit de la réservation d’espace/temps sur le …

                      Lire plus

                    • I&A et PIP 4 - février 2023

                      13.02.2023 dans News

                      I&A février 2023 : ce qu’on retiendra ! L‘Inspect & Adapt est une cérémonie issue du framework d’agilité à l’échelle SAFe (Scaled Agile Framework), au cours de laquelle nous inspectons notre travail réalisé sur les 11 dernières semaines …

                      Lire plus

                    • Fosdem 2023 : OSRD était présent !

                      06.02.2023 dans News

                      Une Devroom pour l’association Openrail Les 4 et 5 février se tenait le FOSDEM, l’évènement européen annuel incontournable pour la communauté open source. Tout au long de ces 2 jours à Bruxelles, les participants ont pu assister à une variété …

                      Lire plus

                      • \ No newline at end of file diff --git a/fr/categories/index.html b/fr/categories/index.html index 40f0fef7a..0857620c7 100644 --- a/fr/categories/index.html +++ b/fr/categories/index.html @@ -1,2 +1,2 @@ Categories | OSRD -

                      Categories

                      © 2024 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file +

                      Categories

                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git a/fr/docs/_print/index.html b/fr/docs/_print/index.html index cbcf0c124..20a701225 100644 --- a/fr/docs/_print/index.html +++ b/fr/docs/_print/index.html @@ -1,6 +1,6 @@ Documentation | OSRD -

                      Version imprimable multipages. -Cliquer ici pour imprimer.

                      Retour à la version par défaut.

                      Documentation

                      Vous souhaitez utiliser OSRD, y contribuer, ou simplement en comprendre le fonctionnement ? Cette documentation est pour vous !

                      1 - Explications

                      Comprendre les concepts clés

                      Les explications abordent des thèmes et concepts clés d’un point de vue général et fournissent des informations et explications détaillées sur les éléments fondamentaux.

                      1.1 - Architecture des conteneurs

                      Comment les conteneurs fonctionnent ensemble et comment ils sont construits

                      Il y a 3 principaux conteneurs déployés dans une configuration OSRD standard :

                      • Gateway (inclut le frontend) : Sert le front-end, gère l’authentification et proxy les requêtes vers le backend.
                      • Editoast : Agit comme le backend qui interagit avec le front-end.
                      • Core : Gère les calculs et la logique métier, appelé par Editoast.

                      Déploiement standard

                      Le déploiement standard peut être représenté par le diagramme suivant.

                      flowchart TD
+
                      Version imprimable multipages.
+Cliquer ici pour imprimer.
                      Retour à la version par défaut.
                      Documentation
                      Vous souhaitez utiliser OSRD, y contribuer, ou simplement en comprendre le fonctionnement ? Cette documentation est pour vous !
                      1 - Explications
                      Comprendre les concepts clés
                      Les explications abordent des thèmes et concepts clés d’un point de vue général et fournissent des informations et explications détaillées sur les éléments fondamentaux.
                      1.1 - Architecture des conteneurs
                      Comment les conteneurs fonctionnent ensemble et comment ils sont construits
                      Il y a 3 principaux conteneurs déployés dans une configuration OSRD standard :
                      • Gateway (inclut le frontend) : Sert le front-end, gère l’authentification et proxy les requêtes vers le backend.
                      • Editoast : Agit comme le backend qui interagit avec le front-end.
                      • Core : Gère les calculs et la logique métier, appelé par Editoast.
                      Déploiement standard
                      Le déploiement standard peut être représenté par le diagramme suivant.
                      flowchart TD
     gw["gateway"]
     front["fichiers statiques front-end"]
     gw -- fichier local --> front
@@ -321,7 +321,41 @@
 
                      Utilisation seule du logo (sans le texte)
                      Les couleurs
                      Ces couleurs sont celles du logo, elles ne sont pas à confondre avec celles du design global de l’interface d’OSRD.
                      #786ABF
-#C7B2DE
                      3 - Référence technique
                      Machinerie interne et APIs
                      Les guides de référence technique contiennent des références techniques pour les API et autres aspects de la machinerie OSRD. Ils présentent son fonctionnement et la manière de l’exploiter en partant du principe que les concepts clés de base sont maîtrisés.
                      3.1 - Architecture
                      Détails lié à l’architecture de OSRD
                      Les documents d’architecture permettent de comprendre comment OSRD fonctionne globalement.
                      3.1.1 - Flux des données
                      Schéma des flux des données d’osrd
                      Data-flow diagram
                      3.2 - Documents de conception
                      Détails liés à la conceptions de solutions techniques
                      Les documents de conceptions décrivent comment et pourquoi un composant logiciel a été conçu, de l’exposition du problème à la solution technique, en passant par le chemin pris pour y arriver.
                      3.2.1 - Poste d'aiguillage
                      Décrit le fonctionnement du poste d’aiguillage virtuel
                      Le modèle de simulation définit le rôle et comportement des différents objets simulés au sein d’OSRD.
                      Cette modélisation est un compromis entre de multiples enjeux:
                      • fidélité de la simulation
                      • interprétabilité des résultats
                      • adaptabilité du modèle à différentes technologies et usages, que cela soit en terme de signalisation, de poste d’aiguillage, ou d’usage des données
                      En particulier, certaines subtilités propres aux systèmes pratiques ont été sacrifiées sur l’autel de la compatibilité et de l’interprétabilité:
                      • un signal doit forcément s’addresser à un train en particulier: les signaux n’ont pas d’aspect par défaut; ils n’existent que pour être vus
                      • les itinéraires / routes sont formées à destination d’un train en particulier
                      Ce document est une description du modèle de fonctionnement cible d’OSRD.
+#C7B2DE
                      2.5 - Publication
                      Section sur les releases
                      Cette section documente le processus de création d’une publication d’OSRD.
                      2.5.1 - Processus de publication
                      Voici comment OSRD est actuellement publié
                      OSRD possède trois versions : développement (dev), staging et publication.
                      La version de développement est la version la plus récente et la plus instable de l’application, contenant les dernières fonctionnalités et corrections de bugs en cours de développement.
                      Les versions staging sont créées tous les jeudis à 12h en taguant l’état actuel du développement.
                      Si une version staging passe les tests de validation, elle est promue pour devenir la dernière version publication. Cela garantit que seul du code stable et testé est intégré dans les versions de production.
                      Le processus de publication suit ce workflow :
                      1. Développement continu dans la branche dev
                      2. Tags de staging hebdomadaires les jeudis à 12h
                      3. Tests de validation de la version staging
                      4. Promotion des builds staging validés au statut de publication
                          Développement      Staging                publication
+    (instable)         (test)                   (stable)
+
+    [Branche Dev]                                  |
+         |                                         |
+         |--->     Jeudi 12h                       |
+         |         [Tag Staging]                   |
+         |                |                        |
+         |            Validation                   |
+         |              Tests                      |
+         |                |                        |
+         |                o---> Si Passage -->  Nouvelle
+         |                        Tests        publication
+    [Suite Dev]                                    |
+         |                                         |
+         V                                         V
+
                      2.5.2 - Publier une nouvelle version
                      Comment publier une nouvelle version
                      Toutes les versions d’OSRD sont accessibles ici
                      Le processus de création d’une nouvelle version est le suivant :
                      1. Nous publions toujours sur une version testée de l’application (branche staging)
                        • git switch staging && git pull
                      2. Créer un tag git annoté
                        • Nous utilisons le versionnement sémantique
                        • git tag -a vx.y.z avec le message Release x.y.z (la plupart du temps, utilisez la dernière version et incrémentez la version patch)
                        • git push --tags
                      3. Créer une release GitHub
                        • Créer une nouvelle release GitHub ici
                        • Sélectionner le tag créé
                        • Générer les notes de version
                        • Renommer la release ainsi : “Version x.y.z”
                        • Cocher la case “Set as a pre-release”
                        • Appliquer le format du changelog
                        • Vous pouvez ensuite publier la release ou sauvegarder le brouillon si vous souhaitez y revenir plus tard
                      4. Une action GitHub devrait être déclenchée automatiquement.
                      5. Poster le lien de la release créée sur Matrix. Suggérer aux développeurs de revoir la release.
                      Format du changelog
                      1. Utiliser la structure suivante :
                      ## What's Changed
+
+### Features :tada:
+
+
+### Code refactoring :recycle:
+
+
+### Bug fixes :bug:
+
+
+## New Contributors
+
+<!-- Copy from the generated release notes -->
+...
+
+<!-- Copy from the generated release notes -->
+**Full Changelog**: ...
+
                      1. Répartir les différentes pull requests
                      2. Fusionner ou regrouper les PR quand cela a du sens. Exemples :
                        • PR de mise à jour des dépendances (fusionner)
                        • PR en plusieurs parties (fusionner)
                        • Une grande fonctionnalité implémentée par plusieurs PR (regrouper)
                      3. Reformuler les titres des PR. Ils doivent être compréhensibles pour un collaborateur externe
                      3 - Référence technique
                      Machinerie interne et APIs
                      Les guides de référence technique contiennent des références techniques pour les API et autres aspects de la machinerie OSRD. Ils présentent son fonctionnement et la manière de l’exploiter en partant du principe que les concepts clés de base sont maîtrisés.
                      3.1 - Architecture
                      Détails lié à l’architecture de OSRD
                      Les documents d’architecture permettent de comprendre comment OSRD fonctionne globalement.
                      3.1.1 - Flux des données
                      Schéma des flux des données d’osrd
                      Data-flow diagram
                      3.2 - Documents de conception
                      Détails liés à la conceptions de solutions techniques
                      Les documents de conceptions décrivent comment et pourquoi un composant logiciel a été conçu, de l’exposition du problème à la solution technique, en passant par le chemin pris pour y arriver.
                      3.2.1 - Poste d'aiguillage
                      Décrit le fonctionnement du poste d’aiguillage virtuel
                      Le modèle de simulation définit le rôle et comportement des différents objets simulés au sein d’OSRD.
                      Cette modélisation est un compromis entre de multiples enjeux:
                      • fidélité de la simulation
                      • interprétabilité des résultats
                      • adaptabilité du modèle à différentes technologies et usages, que cela soit en terme de signalisation, de poste d’aiguillage, ou d’usage des données
                      En particulier, certaines subtilités propres aux systèmes pratiques ont été sacrifiées sur l’autel de la compatibilité et de l’interprétabilité:
                      • un signal doit forcément s’addresser à un train en particulier: les signaux n’ont pas d’aspect par défaut; ils n’existent que pour être vus
                      • les itinéraires / routes sont formées à destination d’un train en particulier
                      Ce document est une description du modèle de fonctionnement cible d’OSRD.
 Il a pour objectif de renseigner développeurs et experts métiers sur le fonctionnement du simulateur.
 Des changements y sont apportés au fil de l’évolution du projet.
                      Ce modèle est en cours d’implémentation
                      Architecture
                      flowchart TD
     %%%% NODES
@@ -817,4 +851,4 @@
 que la vitesse du train.
                    • Mode NL : Conduite d’un engin moteur non en tête du mouvement
                      Ce mode technique est utilisé en cas de pousse ou de double traction.
                      • Protection contre le rattrapage
                      En mode FS, une vitesse autorisée affichée sans la présentation de l’EOA signifie « marche normale ».
                      La MA constituée d’un ou plusieurs cantons est allouée canton par canton, par ajout successif d’un canton.
 Si le canton en aval du dernier canton alloué est occupé le train doit être en mesure de s’arrêter avant l’entrée de ce
 canton. Le conducteur est alors avisé par une indication sonore au DMI.
                      Dès lors, les indications de conduite (vitesse but égale à 0 et une distance but) permettant de respecter la courbe de
-freinage sont affichées.
                      Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.
                      4.2.4.2.2 - GSM-R
                      Global System for Mobiles - Railways
                      4.2.4.2.3 - GPRS
                      General Packet Radio Service
                      4.2.4.2.4 - FRMCS
                      Futur Système de Communications Mobiles Ferroviaires
                      4.2.4.2.5 - ETML
                      European Train Management Layer
                      © 2024 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file +freinage sont affichées.

                      Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                      4.2.4.2.2 - GSM-R

                      Global System for Mobiles - Railways

                      4.2.4.2.3 - GPRS

                      General Packet Radio Service

                      4.2.4.2.4 - FRMCS

                      Futur Système de Communications Mobiles Ferroviaires

                      4.2.4.2.5 - ETML

                      European Train Management Layer
                      \ No newline at end of file diff --git a/fr/docs/explanation/_print/index.html b/fr/docs/explanation/_print/index.html index ff893b1ab..7e0eca7f0 100644 --- a/fr/docs/explanation/_print/index.html +++ b/fr/docs/explanation/_print/index.html @@ -1,5 +1,5 @@ Explications | OSRD -

                      Version imprimable multipages. +

                      Version imprimable multipages. Cliquer ici pour imprimer.

                      Retour à la version par défaut.

                      Explications

                      Comprendre les concepts clés

                      Les explications abordent des thèmes et concepts clés d’un point de vue général et fournissent des informations et explications détaillées sur les éléments fondamentaux.

                      1 - Architecture des conteneurs

                      Comment les conteneurs fonctionnent ensemble et comment ils sont construits

                      Il y a 3 principaux conteneurs déployés dans une configuration OSRD standard :

                      • Gateway (inclut le frontend) : Sert le front-end, gère l’authentification et proxy les requêtes vers le backend.
                      • Editoast : Agit comme le backend qui interagit avec le front-end.
                      • Core : Gère les calculs et la logique métier, appelé par Editoast.

                      Déploiement standard

                      Le déploiement standard peut être représenté par le diagramme suivant.

                      flowchart TD
     gw["gateway"]
     front["fichiers statiques front-end"]
@@ -78,4 +78,4 @@
   OSRD (front-end)->> OSRD (front-end): converti la grille horaire en<br> nge_light_model
   OSRD (front-end)->>NGE (osrd-nge): iframe.contentWindow.postMessage(nge_light_model, "*")
   NGE (osrd-nge)->>NGE (osrd-nge): (eventListener) <br> onLoad déclenché
-  NGE (osrd-nge)->>NGE (nge-app): (callback function) <br> onLoad(nge_light_model, ...)

                      2 - Convertisseurs

                      Pour surpasser les différences sémantiques et adapter les modèles de données, deux convertisseurs doivent être implémentés :

                      • [OSRD -> NGE] un convertisseur qui transforme une grille horaire OSRD en un modèle NGE
                      • [OSRD <- NGE] un gestionnaire d’événements, qui transforme une action NGE en mise à jour de la base de données OSRD sur la grille horaire

                      3 - Open-source (coopération / contribution)

                      Pour rendre NGE compatible avec OSRD, certaines modifications ont été demandées (désactivation du back-end, création de hooks sur les événements) et directement implémentées dans le répertoire officiel de NGE, avec l’accord et l’aide de l’équipe NGE.

                      Les contributions d’un projet à l’autre, de part et d’autre, sont précieuses et seront encouragées à l’avenir.

                      Cette fonctionnalité montre également que la coopération open-source est puissante et constitue un gain de temps considérable dans le développement de logiciels.

                      © 2024 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file + NGE (osrd-nge)->>NGE (nge-app): (callback function) <br> onLoad(nge_light_model, ...)

                      2 - Convertisseurs

                      Pour surpasser les différences sémantiques et adapter les modèles de données, deux convertisseurs doivent être implémentés :

                      • [OSRD -> NGE] un convertisseur qui transforme une grille horaire OSRD en un modèle NGE
                      • [OSRD <- NGE] un gestionnaire d’événements, qui transforme une action NGE en mise à jour de la base de données OSRD sur la grille horaire

                      3 - Open-source (coopération / contribution)

                      Pour rendre NGE compatible avec OSRD, certaines modifications ont été demandées (désactivation du back-end, création de hooks sur les événements) et directement implémentées dans le répertoire officiel de NGE, avec l’accord et l’aide de l’équipe NGE.

                      Les contributions d’un projet à l’autre, de part et d’autre, sont précieuses et seront encouragées à l’avenir.

                      Cette fonctionnalité montre également que la coopération open-source est puissante et constitue un gain de temps considérable dans le développement de logiciels.

                      © 2025 Contributeurs à OSRD. Tous droits réservés
                      \ No newline at end of file diff --git a/fr/docs/explanation/containers-architecture/_print/index.html b/fr/docs/explanation/containers-architecture/_print/index.html index bff80a306..a77588803 100644 --- a/fr/docs/explanation/containers-architecture/_print/index.html +++ b/fr/docs/explanation/containers-architecture/_print/index.html @@ -1,5 +1,5 @@ Architecture des conteneurs | OSRD -

                      Version imprimable multipages. +

                      Version imprimable multipages. Cliquer ici pour imprimer.

                      Retour à la version par défaut.

                      Architecture des conteneurs

                      Comment les conteneurs fonctionnent ensemble et comment ils sont construits

                        Il y a 3 principaux conteneurs déployés dans une configuration OSRD standard :

                        • Gateway (inclut le frontend) : Sert le front-end, gère l’authentification et proxy les requêtes vers le backend.
                        • Editoast : Agit comme le backend qui interagit avec le front-end.
                        • Core : Gère les calculs et la logique métier, appelé par Editoast.

                        Déploiement standard

                        Le déploiement standard peut être représenté par le diagramme suivant.

                        flowchart TD
     gw["gateway"]
     front["fichiers statiques front-end"]
@@ -7,4 +7,4 @@
     
     navigateur --> gw
     gw -- HTTP --> editoast
-    editoast -- HTTP --> core

                        Les requêtes externes sont reçues par le gateway. Si le chemin demandé commence par /api, il sera transféré en utilisant HTTP vers editoast, sinon il servira un fichier avec le chemin demandé. Editoast atteint le core en utilisant HTTP si nécessaire.

                        Le gateway n’est pas seulement un proxy inverse avec le bundle front-end inclus, il fournit également tous les mécanismes d’authentification : utilisant OIDC ou des tokens.

                        © 2024 Contributeurs à OSRD. Tous droits réservés
                        \ No newline at end of file + editoast -- HTTP --> core

                        Les requêtes externes sont reçues par le gateway. Si le chemin demandé commence par /api, il sera transféré en utilisant HTTP vers editoast, sinon il servira un fichier avec le chemin demandé. Editoast atteint le core en utilisant HTTP si nécessaire.

                        Le gateway n’est pas seulement un proxy inverse avec le bundle front-end inclus, il fournit également tous les mécanismes d’authentification : utilisant OIDC ou des tokens.

                        © 2025 Contributeurs à OSRD. Tous droits réservés
                        \ No newline at end of file diff --git a/fr/docs/explanation/containers-architecture/index.html b/fr/docs/explanation/containers-architecture/index.html index 911808eb1..fee9c1837 100644 --- a/fr/docs/explanation/containers-architecture/index.html +++ b/fr/docs/explanation/containers-architecture/index.html @@ -1,5 +1,5 @@ Architecture des conteneurs | OSRD -
                        © 2025 Contributeurs à OSRD. Tous droits réservés
                        \ No newline at end of file diff --git a/fr/docs/explanation/index.html b/fr/docs/explanation/index.html index 6108339c2..76cc5d1cd 100644 --- a/fr/docs/explanation/index.html +++ b/fr/docs/explanation/index.html @@ -1,5 +1,5 @@ Explications | OSRD -

                        Explications

                        Comprendre les concepts clés

                        Les explications abordent des thèmes et concepts clés d’un point de vue général et fournissent des informations et explications détaillées sur les éléments fondamentaux.

                        Architecture des conteneurs

                        Comment les conteneurs fonctionnent ensemble et comment ils sont construits

                        Modèles

                        Ce qui est modélisé dans OSRD, et comment c’est modélisé

                        Calcul de marche

                        Netzgrafik-Editor

                        Logiciel open-source développé par SBB CFF FFS et son intégration dans OSRD

                        © 2025 Contributeurs à OSRD. Tous droits réservés
                        \ No newline at end of file diff --git a/fr/docs/explanation/models/_print/index.html b/fr/docs/explanation/models/_print/index.html index f73e75c0c..695aee2e5 100644 --- a/fr/docs/explanation/models/_print/index.html +++ b/fr/docs/explanation/models/_print/index.html @@ -1,5 +1,5 @@ Modèles | OSRD -

                        Version imprimable multipages. +

                        Version imprimable multipages. Cliquer ici pour imprimer.

                        Retour à la version par défaut.

                        Modèles

                        Ce qui est modélisé dans OSRD, et comment c’est modélisé

                        1 - Exemple d'infrastructure

                        Explique par l’exemple comment les données d’infrastructure sont structurées

                        Introduction

                        Cette page donne un exemple de la manière dont les formats de données sont utilisés pour décrire une infrastructure dans OSRD.

                        À cette fin, prenons comme exemple l’infrastructure-jouet suivante :

                        Diagramme de l’Infrastructure

                        Ce diagramme est un aperçu de l’infrastructure avec les lignes et les stations uniquement.

                        Cette infrastructure ne se veut pas réaliste, mais plutôt destinée à illustrer le modèle de données d’OSRD. Cet exemple sera créé étape par étape et expliqué en cours de route.

                        Le générateur d’infrastructures

                        Dans le dépôt OSRD se trouve une bibliothèque python conçue pour aider à générer des infrastructures dans un format compris par OSRD.

                        L’infrastructure discutée dans cette section peut être générée grâce au fichier small_infra.py. Pour en savoir plus sur les scripts de génération, vous pouvez consulter le README correspondant.

                        Voies

                        Sections de voie (Track Sections)

                        Les premiers objets que nous devons définir sont les TrackSections. La plupart des autres objets sont positionnés par rapport à celles-ci.

                        Une section de voie est une section de rail (sans aiguillages). On peut choisir de diviser les voies de son infrastructure en autant de sections qu’on le souhaite. Ici, nous avons choisi d’utiliser les sections de voie les plus longues possibles, ce qui signifie qu’entre deux aiguillages, il y a toujours une seule section de voie.

                        Les sections de voie sont ce sur quoi les trains simulés roulent. Ils sont l’équivalent abstrait des sections de rails physiques. Les sections de voie sont bidirectionnelles.

                        Dans cet exemple, nous définissons deux voies pour la ligne entre les stations Ouest et Nord-Est. Nous avons également des voies de contournement aux stations Nord et Centre-Ouest pour plus de réalisme. Enfin, nous avons trois voies distinctes dans la station Ouest, puisqu’il s’agit d’une plaque tournante majeure dans notre infrastructure imaginaire.

                        Diagramme des sections de voies

                        Ces attributs sont nécessaires pour que la section de voie soit complète :

                        • length : la longueur de la section de voie en mètres.
                        • geo : les coordonnées dans la réalité (geo pour géographique), au format GeoJSON.
                        • attributs cosmétiques : line_name, track_name, track_number qui sont utilisés pour indiquer le nom et les étiquettes qui ont été donnés aux voies / lignes dans la réalité.

                        Pour toutes les sections de voies de notre infrastructure, les attributs geo se rapprochent beaucoup au schéma donné.

                        Pour la plupart des sections de voies, leur length est proportionnelle à ce que l’on peut voir sur le diagramme. Pour préserver la lisibilité, des exceptions ont été faites pour TA6, TA7, TD0 et TD1 (qui font 10km et 25km).

                        Noeud

                        Un Node représente un noeud dans l’infrastructure. Dans une simulation OSRD, un train ne peut passer d’une section de voie à une autre que si elles sont reliées par un noeud. Un noeud peut se présenter de deux manières différentes :

                        1) Aiguillages

                        Les aiguillages peuvent être vus comme une collection de liens de sections de voies, partitionnés en groupes. Chaque groupe représente un état de l’aiguillage. Passer d’un groupe à un autre peut prendre du temps, et au maximum un lien peut être prêt à être utilisé à la fois.

                        Dans le monde réel, les aiguillages ne sont pas uniques, mais plutôt des instances de modèles existants.

                        2) Liens de sections de voies

                        Pour le moment, nous n’avons créé que des sections de voies, qui ne sont pas interconnectées (les données géospatiales ne sont pas utilisées pour déduire quelles voies sont connectées).

                        Les link sont utilisés pour connecter deux sections de voie ensemble, tout comme un joint de soudure le ferait dans la vie réelle. Dans une simulation OSRD, un train ne peut passer d’une section de voie à une autre que si elles sont reliées par ce type de noeud, le link (ou par un autre NodeType).

                        Que ce soit pour les aiguillages ou les liens de sections de voies, les liens et les groupes ne font pas partie du switch lui-même, mais d’un objet NodeType, qui est partagé par les aiguillages du même modèle.

                        Types de Noeud

                        Les NodeTypes ont deux attributs obligatoires :

                        • ports : Une liste de noms de ports. Un port est une extrémité du noeud qui peut être connecté à une section de voie.
                        • groups : Un table de correspondance entre le nom des groupes et les listes de branches (connexion entre 2 ports) qui caractérisent les différentes positions possibles du type de Noeud

                        À tout moment, tous les noeuds ont un groupe actif, et peuvent avoir une branche active, qui appartient toujours au groupe actif. Pendant une simulation, le changement de branche active à l’intérieur d’un groupe est instantané, mais le changement de branche active entre les groupes prend un temps configurable. @@ -25,4 +25,4 @@ } ] } -

                        • lower_pantograph : indique si le pantographe doit être baissé dans cette zone
                        • track_ranges : liste des portions de voie où le train ne doit pas tractionner
                        • announcement_track_ranges : liste des portions de voie entre le panneau d’annonce et le panneau d’exécution

                        Affichage

                        Cartographie

                        Les zones affichées dans la cartographie correspondent aux track_ranges, donc entre les panneaux d’exécution et de fin de zone. La couleur de la zone indique si le train doit baisser son pantographe dans la zone ou non.

                        La direction dans laquelle la zone s’applique n’est pas représentée.

                        Résultat de simulation

                        Dans l’affichage linéaire, c’est toujours la zone entre EXE et FIN qui est affichée.

                        Recherche d’itinéraire

                        Les zones neutres sont donc des portions de voie “non électrifiées” où un train électrique peut tout de même circuler (mais où il ne peut pas tractionner).

                        Lors de la recherche de chemin dans l’infrastructure, une portion de voie qui n’est pas couverte par les track_ranges d’un objet caténaire (documentation à écrire) peut être empruntée par un train électrique seulement si elle est couverte par les track_ranges d’une zone neutre.

                        Simulation

                        Dans la simulation, nous approximons le comportement du conducteur de la façon suivante :

                        • La marche sur l’erre est entamée dès que la tête du train passe le panneau d’annonce
                        • Le décompte des temps systèmes (relevé du pantographe et reprise de la traction) commence dès que la tête du train passe le panneau de fin.

                        Dans la simulation actuelle, il est plus facile de manier des bornes d’intégration spatiales que temporelles. Nous effectuons l’approximation suivante: lors de la sortie de la zone neutre, on multiplie les temps systèmes par la vitesse en sortie de zone. La marche sur l’erre est alors prolongée de la distance obtenue. Cette approximation est raisonnable car l’inertie du train et la quasi-absence de frottement garantissent que la vitesse varie peu sur cet intervalle de temps.

                        Potentielles améliorations

                        Plusieurs points pourraient être améliorés :

                        • On ne considère pas les pancartes REV, tous les trains ne possèdent donc qu’un pantographe à l’avant dans nos simulations.
                        • Les temps systèmes sont approximés.
                        • Le comportement conducteur est plutôt restrictif (la marche sur l’erre pourrait commencer après le panneau d’annonce).
                        • L’affichage des zones est limité: pas de représentation de la direction ou des zones d’annonce.
                        • Ces zones ne sont pas éditables.
                        © 2024 Contributeurs à OSRD. Tous droits réservés
                        \ No newline at end of file +

                        Affichage

                        Cartographie

                        Les zones affichées dans la cartographie correspondent aux track_ranges, donc entre les panneaux d’exécution et de fin de zone. La couleur de la zone indique si le train doit baisser son pantographe dans la zone ou non.

                        La direction dans laquelle la zone s’applique n’est pas représentée.

                        Résultat de simulation

                        Dans l’affichage linéaire, c’est toujours la zone entre EXE et FIN qui est affichée.

                        Recherche d’itinéraire

                        Les zones neutres sont donc des portions de voie “non électrifiées” où un train électrique peut tout de même circuler (mais où il ne peut pas tractionner).

                        Lors de la recherche de chemin dans l’infrastructure, une portion de voie qui n’est pas couverte par les track_ranges d’un objet caténaire (documentation à écrire) peut être empruntée par un train électrique seulement si elle est couverte par les track_ranges d’une zone neutre.

                        Simulation

                        Dans la simulation, nous approximons le comportement du conducteur de la façon suivante :

                        Dans la simulation actuelle, il est plus facile de manier des bornes d’intégration spatiales que temporelles. Nous effectuons l’approximation suivante: lors de la sortie de la zone neutre, on multiplie les temps systèmes par la vitesse en sortie de zone. La marche sur l’erre est alors prolongée de la distance obtenue. Cette approximation est raisonnable car l’inertie du train et la quasi-absence de frottement garantissent que la vitesse varie peu sur cet intervalle de temps.

                        Potentielles améliorations

                        Plusieurs points pourraient être améliorés :

                        \ No newline at end of file diff --git a/fr/docs/explanation/models/data-models-full-example/index.html b/fr/docs/explanation/models/data-models-full-example/index.html index 0620f4c0e..2a5ebc19d 100644 --- a/fr/docs/explanation/models/data-models-full-example/index.html +++ b/fr/docs/explanation/models/data-models-full-example/index.html @@ -1,5 +1,5 @@ Exemple d'infrastructure | OSRD -
                        © 2025 Contributeurs à OSRD. Tous droits réservés
                        \ No newline at end of file diff --git a/fr/docs/explanation/models/index.html b/fr/docs/explanation/models/index.html index b8fe8415e..56ec3e501 100644 --- a/fr/docs/explanation/models/index.html +++ b/fr/docs/explanation/models/index.html @@ -1,5 +1,5 @@ Modèles | OSRD -

                        Modèles

                        Ce qui est modélisé dans OSRD, et comment c’est modélisé
                        Exemple d'infrastructure

                        Explique par l’exemple comment les données d’infrastructure sont structurées

                        Zones neutres

                        Documentation des zones neutres et de leur implémentation

                        © 2025 Contributeurs à OSRD. Tous droits réservés
                        \ No newline at end of file diff --git a/fr/docs/explanation/models/neutral_sections/index.html b/fr/docs/explanation/models/neutral_sections/index.html index 285705144..fba23ee88 100644 --- a/fr/docs/explanation/models/neutral_sections/index.html +++ b/fr/docs/explanation/models/neutral_sections/index.html @@ -1,5 +1,5 @@ Zones neutres | OSRD -
                        • lower_pantograph : indique si le pantographe doit être baissé dans cette zone
                        • track_ranges : liste des portions de voie où le train ne doit pas tractionner
                        • announcement_track_ranges : liste des portions de voie entre le panneau d’annonce et le panneau d’exécution

                        Affichage

                        Cartographie

                        Les zones affichées dans la cartographie correspondent aux track_ranges, donc entre les panneaux d’exécution et de fin de zone. La couleur de la zone indique si le train doit baisser son pantographe dans la zone ou non.

                        La direction dans laquelle la zone s’applique n’est pas représentée.

                        Résultat de simulation

                        Dans l’affichage linéaire, c’est toujours la zone entre EXE et FIN qui est affichée.

                        Recherche d’itinéraire

                        Les zones neutres sont donc des portions de voie “non électrifiées” où un train électrique peut tout de même circuler (mais où il ne peut pas tractionner).

                        Lors de la recherche de chemin dans l’infrastructure, une portion de voie qui n’est pas couverte par les track_ranges d’un objet caténaire (documentation à écrire) peut être empruntée par un train électrique seulement si elle est couverte par les track_ranges d’une zone neutre.

                        Simulation

                        Dans la simulation, nous approximons le comportement du conducteur de la façon suivante :

                        • La marche sur l’erre est entamée dès que la tête du train passe le panneau d’annonce
                        • Le décompte des temps systèmes (relevé du pantographe et reprise de la traction) commence dès que la tête du train passe le panneau de fin.

                        Dans la simulation actuelle, il est plus facile de manier des bornes d’intégration spatiales que temporelles. Nous effectuons l’approximation suivante: lors de la sortie de la zone neutre, on multiplie les temps systèmes par la vitesse en sortie de zone. La marche sur l’erre est alors prolongée de la distance obtenue. Cette approximation est raisonnable car l’inertie du train et la quasi-absence de frottement garantissent que la vitesse varie peu sur cet intervalle de temps.

                        Potentielles améliorations

                        Plusieurs points pourraient être améliorés :

                        • On ne considère pas les pancartes REV, tous les trains ne possèdent donc qu’un pantographe à l’avant dans nos simulations.
                        • Les temps systèmes sont approximés.
                        • Le comportement conducteur est plutôt restrictif (la marche sur l’erre pourrait commencer après le panneau d’annonce).
                        • L’affichage des zones est limité: pas de représentation de la direction ou des zones d’annonce.
                        • Ces zones ne sont pas éditables.
                        \ No newline at end of file diff --git a/fr/docs/explanation/netzgrafik-editor/_print/index.html b/fr/docs/explanation/netzgrafik-editor/_print/index.html index 98b151c46..4468f0f51 100644 --- a/fr/docs/explanation/netzgrafik-editor/_print/index.html +++ b/fr/docs/explanation/netzgrafik-editor/_print/index.html @@ -1,5 +1,5 @@ Netzgrafik-Editor | OSRD -

                        Version imprimable multipages. +

                        Version imprimable multipages. Cliquer ici pour imprimer.

                        Retour à la version par défaut.

                        Netzgrafik-Editor

                        Logiciel open-source développé par SBB CFF FFS et son intégration dans OSRD

                          Netzgrafik-Editor (NGE) est un logiciel open-source qui permet la création, la modification et l’analyse d’horaires à intervalles réguliers, à un niveau de détail macroscopique, développé par les Chemins de Fer Fédéraux suisses (SBB CFF FFS). Voir les dépôts front-end et back-end

                          OSRD (niveau de détail microscopique, trains à occurence unique, basé sur une infrastructure définie, représente une grille horaire) et NGE (niveau de détail macroscopique, courses de trains à intervalles réguliers, sans infrastructure, représente un plan de transport) sont sémantiquement différents, mais suffisamment proches pour fonctionner ensemble. La compatibilité entre NGE et OSRD a été testée à travers une preuve de concept, en exécutant les deux applications comme services distincts sans synchronisation automatisée.

                          L’idée est de fournir à OSRD un outil graphique pour éditer (créer, mettre à jour et supprimer les horaires des trains) un horaire à partir d’un scénario d’étude opérationnelle, et obtenir en même temps des informations analytiques. Le deuxième avantage de l’utilisation des niveaux de détail microscopique et macroscopique est que les calculs microscopiques d’OSRD peuvent être propagés dans NGE pour améliorer son niveau de détail.

                          L’objectif transversal de cette fonctionnalité est de faire collaborer deux projets open-source de deux grands gestionnaires d’infrastructure pour atteindre des objectifs communs.

                          1 - Intégration dans OSRD

                          Ainsi, NGE est intégré dans la section des études opérationnelles d’OSRD, dans un iframe. Une alternative pour répondre au problème d’intégration aurait été de refacto NGE en web-components, pour les importer facilement dans OSRD, mais cette solution a été abandonnée compte tenu de la quantité de refacto que cela représenterait. Cet iframe pointe vers osrd-nge, une application Angular minimaliste qui intègre l’application NGE réelle. Il peut également être vu comme un conteneur de l’application NGE réelle. osrd-nge personnalise ensuite l’application NGE réelle avec des paramètres et des fonctionnalités spécifiques :

                          • un drapeau standalone :
                            • pour indiquer à NGE de désactiver toutes les interactions back-end (pas de base de données côté NGE)
                            • pour indiquer à NGE de désactiver certains composants de l’interface utilisateur (authentification, gestion de projet, vue du système de versionnage, etc…)
                          • implémentation d’une interface de communication entre OSRD et NGE (message_event, eventListener and postMessage).

                          NGE est alors capable d’obtenir la grille horaire OSRD dès qu’un changement est effectué du côté d’OSRD, et OSRD est capable d’obtenir les modifications effectuées du côté de NGE.

                          Les diagrammes suivants montrent workflow entre les composants.

                          Diagramme conceptuel

                          ---
 title: OSRD - NGE Sequence diagram
@@ -32,4 +32,4 @@
   OSRD (front-end)->> OSRD (front-end): converti la grille horaire en<br> nge_light_model
   OSRD (front-end)->>NGE (osrd-nge): iframe.contentWindow.postMessage(nge_light_model, "*")
   NGE (osrd-nge)->>NGE (osrd-nge): (eventListener) <br> onLoad déclenché
-  NGE (osrd-nge)->>NGE (nge-app): (callback function) <br> onLoad(nge_light_model, ...)

                          2 - Convertisseurs

                          Pour surpasser les différences sémantiques et adapter les modèles de données, deux convertisseurs doivent être implémentés :

                          • [OSRD -> NGE] un convertisseur qui transforme une grille horaire OSRD en un modèle NGE
                          • [OSRD <- NGE] un gestionnaire d’événements, qui transforme une action NGE en mise à jour de la base de données OSRD sur la grille horaire

                          3 - Open-source (coopération / contribution)

                          Pour rendre NGE compatible avec OSRD, certaines modifications ont été demandées (désactivation du back-end, création de hooks sur les événements) et directement implémentées dans le répertoire officiel de NGE, avec l’accord et l’aide de l’équipe NGE.

                          Les contributions d’un projet à l’autre, de part et d’autre, sont précieuses et seront encouragées à l’avenir.

                          Cette fonctionnalité montre également que la coopération open-source est puissante et constitue un gain de temps considérable dans le développement de logiciels.

                          © 2024 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file + NGE (osrd-nge)->>NGE (nge-app): (callback function) <br> onLoad(nge_light_model, ...)

                          2 - Convertisseurs

                          Pour surpasser les différences sémantiques et adapter les modèles de données, deux convertisseurs doivent être implémentés :

                          • [OSRD -> NGE] un convertisseur qui transforme une grille horaire OSRD en un modèle NGE
                          • [OSRD <- NGE] un gestionnaire d’événements, qui transforme une action NGE en mise à jour de la base de données OSRD sur la grille horaire

                          3 - Open-source (coopération / contribution)

                          Pour rendre NGE compatible avec OSRD, certaines modifications ont été demandées (désactivation du back-end, création de hooks sur les événements) et directement implémentées dans le répertoire officiel de NGE, avec l’accord et l’aide de l’équipe NGE.

                          Les contributions d’un projet à l’autre, de part et d’autre, sont précieuses et seront encouragées à l’avenir.

                          Cette fonctionnalité montre également que la coopération open-source est puissante et constitue un gain de temps considérable dans le développement de logiciels.

                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/explanation/netzgrafik-editor/index.html b/fr/docs/explanation/netzgrafik-editor/index.html index ed7d528bc..b8025a979 100644 --- a/fr/docs/explanation/netzgrafik-editor/index.html +++ b/fr/docs/explanation/netzgrafik-editor/index.html @@ -1,5 +1,5 @@ Netzgrafik-Editor | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/explanation/running_time_calculation/_print/index.html b/fr/docs/explanation/running_time_calculation/_print/index.html index 5239b3228..a057df8a1 100644 --- a/fr/docs/explanation/running_time_calculation/_print/index.html +++ b/fr/docs/explanation/running_time_calculation/_print/index.html @@ -1,5 +1,5 @@ Calcul de marche | OSRD -

                          Version imprimable multipages. +

                          Version imprimable multipages. Cliquer ici pour imprimer.

                          Retour à la version par défaut.

                          Calcul de marche

                          OSRD peut être utilisé pour effectuer deux types de calculs :

                          • Calcul de marche (standalone train simulation) : calcul du temps de parcours d’un train sur un trajet donné, effectué sans interaction entre le train et le système de signalisation.
                          • Simulation : calcul “dynamique” de plusieurs trains interagissant entre eux via le système de signalisation.

                          1 - Les données d’entrée

                          Un calcul de marche est basé sur 5 entrées :

                          • L’infrastructure : Topologie des lignes et des voies, position des gares et bâtiments voyageurs, position et type des aiguilles, signaux, vitesses maximales de ligne, profil de ligne corrigée (pentes, rampes et virages).

                          Infrastructure

                          L’histogramme bleu est une représentation des déclivités en [‰] par position en [m]. Les déclivités sont positives pour les rampes et négatives pour les pentes.

                          La ligne orange représente le profil cumulé, c’est-à-dire l’altitude relative par rapport au point de départ.

                          La ligne bleue est une représentation des virages en termes de rayons des courbures en [m].

                          • Le matériel roulant : Dont les caractéristiques nécessaires pour effectuer la simulation sont représentées ci-dessous.

                          Matériel roulant

                          La courbe orange, appelée courbe effort-vitesse du matériel, représente l’effort moteur maximal en fonction de la vitesse de circulation.

                          La longueur, la masse, et la vitesse max du train sont représentées en bas de l’encadré.

                          • L’horaire de départ permettant ensuite de calculer les horaires de passage aux différents points remarquables (dont gares).

                          • Les marges : Temps ajouté au trajet du train pour détendre sa marche (voir page sur les marges).

                          Marge

                          2 - Les résultats

                          Les résultats d’un calcul de marche peuvent se représenter sous différentes formes :

                          • Le graphique espace/temps (GET) : représente le parcours des trains dans l’espace et dans le temps, sous la forme de traits globalement diagonaux dont la pente est la vitesse. Les arrêts apparaissent sous la forme de plateaux horizontaux.

                          Graphique Espace/Temps

                          Exemple de GET avec plusieurs trains espacés d’environ 30mn.

                          L’axe x est l’horaire de passage du train, l’axe y est la position du train en [m].

                          La ligne bleue représente le calcul de marche le plus tendu pour le train, la ligne verte représente un calcul de marche détendu, dit « économique ».

                          Les rectangles pleins entourant les trajets représentent les portions de la voie successivement reservées au passage du train (appelées cantons).

                          • Le graphique espace/vitesse (GEV) : représente le parcours d’un seul train, cette fois-ci en termes de vitesse. Les arrêts apparaissent donc sous forme de décrochages de la courbe jusqu’à zéro, suivis d’un réaccélération.

                          Graphique Espace/Vitesse

                          L’axe x est la position du train en [m], l’axe y est la vitesse du train en [km/h] .

                          La ligne violette représente la vitesse maximale autorisée.

                          La ligne bleue représente la vitesse dans le cas du calcul de marche le plus tendu.

                          La ligne verte représente la vitesse dans le cas du calcul de marche « économique ».

                          • Les horaires de passage du train aux différents points remarquables

                          Horaire de départ

                          1 - Modélisation physique

                          La modélisation physique joue un rôle important dans le cœur de calcul d’OSRD. C’est elle qui nous permet de simuler la circulation des trains, et elle doit être aussi réaliste que possible.

                          Bilan des forces

                          Pour calculer le déplacement du train au cours du temps, il faut d’abord calculer sa vitesse à chaque instant. Une manière simple d’obtenir cette vitesse est de passer par le calcul de l’accélération. @@ -14,4 +14,4 @@ \(\vec{e_x}\) et \(\vec{e_x}^{\prime}\). La pente a toujours un impact sur le bilan des forces mais on considère que le train ne se déplace qu’horizontalement, ce qui donne l’équation simplifiée suivante :

                          $$ a_{x}(t) = \frac{1}{m}\Big[F_{mot}(v_{x}, x)-F_{brk}(x)-(A+Bv_{x}+{Cv_{x}}^2)-mgsin(i(x))\Big] $$

                          Résolution

                          La force motrice et la force de freinage dépendent de l’action du conducteur (il décide d’accélérer ou de freiner plus ou moins fort en fonction de la situation). Cette dépendance se traduit donc par une dépendance de ces deux forces à la position du train. La composante du poids dépend elle aussi de la position du train, car provenant directement des pentes et des virages situées sous ce dernier.

                          De plus, la force motrice dépend de la vitesse du train (selon la courbe effort vitesse) tout comme la résistance à l’avancement.

                          Ces différentes dépendances rendent impossible la résolution analytique de cette équation, et l’accélération du train à chaque instant doit être calculée par intégration numérique.

                          2 - Intégration numérique

                          Introduction

                          La modélisation physique ayant montré que l’accélération du train était influencée par différents facteurs variant le long du trajet (pente, courbure, force de traction du moteur…), le calcul doit passer par une méthode d’intégration numérique. Le trajet est alors séparé en étapes suffisamment courtes pour considérer tous ces facteurs comme constants, ce qui permet cette fois ci d’utiliser l’équation du mouvement pour calculer le déplacement et la vitesse du train.

                          La méthode d’intégration numérique d’Euler est la plus simple pour effectuer ce genre de calcul, mais elle présente un certain nombre d’inconvénients. Cet article explique la méthode d’Euler, pourquoi elle ne convient pas aux besoins d’OSRD et quelle méthode d’intégration doit être utilisée à la place.

                          La méthode d’Euler

                          La méthode d’Euler appliquée à l’intégration de l’équation du mouvement d’un train est :

                          $$v(t+dt) = a(v(t), x(t))dt + v(t)$$

                          $$x(t+dt) = \frac{1}{2}a(v(t), x(t))dt^2 + v(t)dt + x(t)$$

                          Méthode d’Euler

                           

                          Les avantages de la méthode d’Euler

                          La méthode d’Euler a pour avantages d’être très simple à implémenter et d’avoir un calcul plutôt rapide pour un pas de temps donné, en comparaison avec d’autres méthodes d’intégration numérique (voir annexe)

                          Les inconvénients de la méthode d’Euler

                          La méthode d’intégration d’Euler présente un certain nombre de problèmes pour OSRD :

                          • Elle est relativement imprécise, et donc nécessite un faible pas de temps, ce qui génère beaucoup de données.
                          • En intégrant dans le temps, on ne connaît que les conditions du point de départ du pas d’intégration (pente, paramètres d’infrastructure, etc.) car on ne peut pas prédire précisément l’endroit où il se termine.
                          • On ne peut pas anticiper les futurs changements de directive : le train ne réagit qu’en comparant son état actuel à sa consigne au même instant. Pour illustrer c’est un peu comme si le conducteur était incapable de voir devant lui, alors que dans la réalité il anticipe en fonction des signaux, pentes, virages qu’il voit devant lui.

                          La méthode Runge-Kutta 4

                          La méthode Runge-Kutta 4 appliquée à l’intégration de l’équation du mouvement d’un train est :

                          $$v(t+dt) = v(t) + \frac{1}{6}(k_1 + 2k_2 + 2k_3 + k_4)dt$$

                          Avec :

                          $$k_1 = a(v(t), x(t))$$

                          $$k_2 = a\Big(v(t+k_1\frac{dt}{2}), x(t) + v(t)\frac{dt}{2} + k_1\frac{dt^2}{8}\Big)$$

                          $$k_3 = a\Big(v(t+k_2\frac{dt}{2}), x(t) + v(t)\frac{dt}{2} + k_2\frac{dt^2}{8}\Big)$$

                          $$k_4 = a\Big(v(t+k_3dt), x(t) + v(t)dt + k_3\frac{dt^2}{2}\Big)$$

                          Méthode de Runge-Kutta 4

                           

                          Les avantages de la méthode de Runge Kutta 4

                          La méthode d’intégration de Runge Kutta 4 permet de répondre aux différents problèmes soulevés par celle d’Euler :

                          • Elle permet d’anticiper les changements de directive au sein d’un pas de calcul, représentant ainsi davantage la réalité de conduite d’un train.
                          • Elle est plus précise pour le même temps de calcul (voir annexe), permettant des étapes d’intégration plus grandes, donc moins de points de données.

                          Les inconvénients de la méthode de Runge Kutta 4

                          Le seul inconvénient notable de la méthode de Runge Kutta 4 rencontré pour l’instant est sa difficulté d’implémentation.

                          Le choix de la méthode d’intégration pour OSRD

                          Étude de la précision et de la vitesse de calcul

                          Différentes méthodes d’intégration auraient pu remplacer l’intégration d’Euler de base dans l’algorithme d’OSRD. Afin de décider quelle méthode conviendrait le mieux, une étude sur la précision et la vitesse de calcul de différentes méthodes a été menée. Cette étude sert à comparé les méthodes suivantes :

                          • Euler
                          • Euler-Cauchy
                          • Runge-Kutta 4
                          • Adams 2
                          • Adams 3

                          Toutes les explications sur ces méthodes peuvent être trouvées dans ce document, et le code python utilisé pour la simulation est ici.

                          La simulation calcule la position et la vitesse d’un TGV accélérant sur une ligne droite plate.

                          Simulations à pas de temps équivalent

                          Une courbe de référence a été simulée en utilisant la méthode d’Euler avec un pas de temps de 0,1s, puis le même parcours a été simulé en utilisant les autres méthodes avec un pas de temps de 1s. Il est alors possible de comparer simplement chaque courbe à la courbe de référence, en calculant la valeur absolue de la différence à chaque point calculé. Voici l’erreur absolue résultante de la position du train sur sa distance parcourue :

                          precisions_h_equivalent

                          Il apparaît immédiatement que la méthode d’Euler est moins précise que les quatre autres d’environ un ordre de grandeur. Chaque courbe présente un pic où la précision est extrêmement élevée (erreur extrêmement faible), ce qui s’explique par le fait que toutes les courbes commencent légèrement au-dessus de la courbe de référence, la croisent en un point et finissent légèrement en dessous, ou vice versa.

                          Comme la précision n’est pas le seul indicateur important, le temps de calcul de chaque méthode a été mesuré. Voici ce que nous obtenons pour les mêmes paramètres d’entrée :

                          Méthode d’intégrationTemps de calcul (s)
                          Euler1.86
                          Euler-Cauchy3.80
                          Runge-Kutta 47.01
                          Adams 23.43
                          Adams 35.27

                          Ainsi, Euler-Cauchy et Adams 2 sont environ deux fois plus lents que Euler, Adams 3 est environ trois fois plus lent, et RK4 est environ quatre fois plus lent. Ces résultats ont été vérifiés sur des simulations beaucoup plus longues, et les différents ratios sont maintenus.

                          Simulation à temps de calcul équivalent

                          Comme les temps de calcul de toutes les méthodes dépendent linéairement du pas de temps, il est relativement simple de comparer la précision pour un temps de calcul à peu près identique. En multipliant le pas de temps d’Euler-Cauchy et d’Adams 2 par 2, le pas de temps d’Adams 3 par 3, et le pas de temps de RK4 par 4, voici les courbes d’erreur absolue résultantes :

                          precisions_time_equivalent

                          Et voici les temps de calcul :

                          Méthode d’intégrationTemps de calcul (s)
                          Euler1.75
                          Euler-Cauchy2.10
                          Runge-Kutta 41.95
                          Adams 21.91
                          Adams 31.99

                          Après un certain temps, RK4 tend à être la méthode la plus précise, légèrement plus précise que Euler-Cauchy, et toujours bien plus précise que la méthode d’Euler.

                          Conclusions de l’étude

                          L’étude de la précision et de la vitesse de calcul présentée ci-dessus montre que RK4 et Euler-Cauchy seraient de bons candidats pour remplacer l’algorithme d’Euler dans OSRD : les deux sont rapides, précis, et pourraient remplacer la méthode d’Euler sans nécessiter de gros changements d’implémentation car ils ne font que des calculs au sein du pas de temps en cours de calcul. Il a été décidé qu’OSRD utiliserait la méthode Runge-Kutta 4 parce qu’elle est légèrement plus précise que Euler-Cauchy et que c’est une méthode bien connue pour ce type de calcul, donc très adaptée à un simulateur open-source.

                          3 - Le système d'enveloppes

                          Le système d’enveloppes est une interface créée spécifiquement pour le calcul de marche d’OSRD. Il permet de manipuler différentes courbes espace/vitesse, de les découper, de les mettre bout à bout, d’interpoler des points spécifiques, et d’adresser beaucoup d’autres besoins nécessaires au calcul de marche.

                          Une interface spécifique dans le service OSRD Core

                          Le système d’enveloppes fait partie du service core d’OSRD (voir l’architecture du logiciel).

                          Ses principaux composants sont :

                          1 - EnvelopePart : courbe espace/vitesse, définie comme une séquence des points et possédant des métadonnées indiquant par exemple s’il s’agit d’une courbe d’accélération, de freinage, de maintien de vitesse, etc.

                          2 - Envelope : liste d’EnvelopeParts mises bout-à-bout et sur laquelle il est possible d’effectuer certaines opérations :

                          • vérifier la continuité dans l’espace (obligatoire) et dans la vitesse (facultative)
                          • chercher la vitesse minimale et/ou maximale de l’enveloppe
                          • couper une partie de l’enveloppe entre deux points de l’espace
                          • effectuer une interpolation de vitesse à une certaine position
                          • calculer le temps écoulé entre deux positions de l’enveloppe

                          envelope_scheme

                          3 - Overlays : système permettant d’ajouter des EnvelopePart plus contraignantes (c’est-à-dire dont la vitesse est plus faible) à une enveloppe existante.

                          Enveloppes données vs enveloppes calculées

                          Pendant la simulation, le train est censé suivre certaines instructions de vitesse. Celles-ci sont modélisées dans OSRD par des enveloppes sous forme de courbes espace/vitesse. On en distingue deux types :

                          • Les enveloppes provenant des données d’infrastructure et de matériel roulant, comme la vitesse maximale de la ligne et la vitesse maximale du train. Etant des données d’entrée de notre calcul, elles ne correspondent pas à des courbes ayant un sens physique, car elles ne sont pas issues des résultats d’une intégration réelle des équations physiques du mouvement.
                          • Les enveloppes résultant d’une intégration réelle des équations du mouvement physique. Elles correspondent à une courbe physiquement tenable par le train et contiennent également des informations sur le temps.

                          Un exemple simple pour illustrer cette différence : si l’on simule un trajet de TER sur une ligne de montagne, une des données d’entrée va être une enveloppe de vitesse maximale à 160km/h, correspondant à la vitesse maximale de notre TER. Mais cette enveloppe ne correspond pas à une réalité physique, car il se peut que sur certaines portions la rampe soit trop raide pour que le train arrive effectivement à maintenir cette vitesse maximale de 160km/h. L’enveloppe calculée présentera donc dans cet exemple un décrochage de vitesse dans les zones de fortes rampes, là où l’enveloppe donnée était parfaitement plate.

                          Simulation de plusieurs trains

                          Dans le cas de la simulation de nombreux trains, le système de signalisation doit assurer la sécurité. L’effet de la signalisation sur le calcul de marche d’un train est reproduit en superposant des enveloppes dynamiques à l’enveloppe statique. Une nouvelle enveloppe dynamique est introduite par exemple lorsqu’un signal se ferme. Le train suit l’enveloppe économique statique superposée aux enveloppes dynamiques, s’il y en a. Dans ce mode de simulation, un contrôle du temps est effectué par rapport à un temps théorique provenant de l’information temporelle de l’enveloppe économique statique. Si le train est en retard par rapport à l’heure prévue, il cesse de suivre l’enveloppe économique et essaie d’aller plus vite. Sa courbe espace/vitesse sera donc limitée par l’enveloppe d’effort maximum.

                          4 - Le processus de calcul de marche

                          Le calcul de marche dans OSRD est un processus à 4 étapes, utilisant chacune le système d’enveloppes :

                          1. Construction du profil de vitesse le plus restrictif
                          2. Ajout des différentes courbes de freinage
                          3. Ajout des différentes courbes d’accélération et vérification des courbes de vitesse constante
                          4. Application de marge(s)

                           

                          Calcul du profil de vitesse le plus restrictif

                          Une première enveloppe est calculée au début de la simulation en regroupant toutes les limites de vitesse statiques :

                          • vitesse maximale de la ligne
                          • vitesse maximale du matériel roulant
                          • limitations temporaires de vitesse (en cas de travaux sur une ligne par exemple)
                          • limitations de vitesse par catégorie de train
                          • limitations de vitesse selon la charge du train
                          • limitations de vitesse correspondant à des panneaux de signalisation

                          La longueur du train est également prise en compte pour s’assurer que le train n’accélère qu’une fois sa queue ayant quitté la zone de plus faible vitesse. Un décalage est alors appliqué à la courbe en pointillée rouge. L’enveloppe résultante (courbe noire) est appelée MRSP (Most Restricted Speed Profile) correspondant donc au profil de vitesse le plus restrictif. C’est sur cette enveloppe que seront calculées les étapes suivantes.

                          Most Restricted Speed Profile

                          La ligne pointillée rouge représente la vitesse maximale autorisée en fonction de la position. -La ligne noire représente le MRSP où la longueur du train a été prise en compte.

                          Il est à noter que les différentes envelopeParts composant le MRSP sont des données d’entrée, elles ne correspondent donc pas à des courbes avec une réalité physique.

                          Calcul du profil de vitesse maximale

                          En partant du MRSP, toutes les courbes de freinage sont calculées grâce au système d’overlay (voir ici pour plus de détails sur les overlays), c’est-à-dire en créant des envelopeParts qui seront plus restrictives que le MRSP. La courbe ainsi obtenue est appelée Max Speed Profile (profil de vitesse maximale). Il s’agit de l’enveloppe de vitesse maximale du train, tenant compte de ses capacités de freinage.

                          Etant donné que les courbes de freinage ont un point de fin imposé et que l’équation de freinage n’a pas de solution analytique, il est impossible de prédire leur point de départ. Les courbes de freinage sont donc calculées à rebours en partant de leur point cible, c’est-à-dire le point dans l’espace où une certaine limite de vitesse est imposée (vitesse cible finie) ou le point d’arrêt (vitesse cible nulle).

                          Max Speed Profile

                          Pour des raisons historiques en production horaire, les courbes de freinages sont calculées avec une décélération forfaitaire, dite décélération horaire (typiquement ~0,5m/s²) sans prendre en compte les autres forces. Cette méthode a donc également été implémentée dans OSRD, permettant ainsi de calculer les freinages de deux manières différentes : avec ce taux horaire ou avec une force de freinage qui vient simplement s’ajouter aux autres forces.

                          Calcul du profil d’effort maximal

                          Pour chaque point correspondant à une augmentation de vitesse dans le MRSP ou à la fin d’une courbe de freinage d’arrêt, une courbe d’accélération est calculée. Les courbes d’accélération sont calculées en tenant compte de toutes les forces actives (force de traction, résistance à l’avancement, poids) et ont donc un sens physique.

                          Pour les envelopeParts dont le sens physique n’a pas encore été vérifié (qui à ce stade sont les phases de circulation à vitesse constante, provenant toujours du MRSP), une nouvelle intégration des équations de mouvement est effectuée. Ce dernier calcul est nécessaire pour prendre en compte d’éventuels décrochages de vitesse dans le cas où le train serait physiquement incapable de tenir sa vitesse, typiquement en présence de fortes rampes (voir cet exemple).

                          L’enveloppe qui résulte de ces ajouts de courbes d’accélérations et de la vérification des plateaux de vitesse est appelée Max Effort Profile (profil d’effort maximal).

                          Max Effort Profile

                          A ce stade, l’enveloppe obtenue est continue et a un sens physique du début à fin. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum. Le calcul de marche obtenu s’appelle la marche de base. Elle correspond au trajet le plus rapide possible pour le matériel roulant donné sur le parcours donné.

                          Application de marge(s)

                          Après avoir effectué le calcul de la marche de base (correspondant au Max Effort Profile dans OSRD), il est possible d’y appliquer des marges (allowances). Les marges sont des ajouts de temps supplémentaire au parcours du train. Elles servent notamment à lui permettre de rattraper son retard si besoin ou à d’autres besoins opérationnels (plus de détails sur les marges ici).

                          Une nouvelle enveloppe Allowances est donc calculée grâce à des overlays pour distribuer la marge demandée par l’utilisateur sur l’enveloppe d’effort maximal calculée précédemment.

                          Marges

                          Dans le calcul de marche d’OSRD, il est possible de distribuer les marges d’une manière linéaire, en abaissant toutes les vitesses d’un certain facteur, ou économique, c’est-à-dire en minimisant la consommation d’énergie pendant le parcours du train.

                          5 - Les marges

                          La raison d’être des marges

                          Comme expliqué dans le calcul du Max Effort Profile, la marche de base représente la marche la plus tendue normalement réalisable, c’est-à-dire le trajet le plus rapide possible du matériel donné sur le parcours donné. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum.

                          Cette marche de base présente un inconvénient majeur : si un train part avec 10min de retard, il arrivera au mieux avec 10min de retard, car par définition il lui est impossible de rouler plus vite que la marche de base. Par conséquent, les trains sont programmés avec un ajout d’une ou de plusieurs marges. Les marges sont une détente du trajet du train, un ajout de temps à l’horaire prévu, qui se traduit inévitablement par un abaissement des vitesses de circulation.

                          Un train circulant en marche de base est incapable de rattraper son retard !

                          Le type de marge

                          On distingue deux types de marges :

                          • La marge de régularité : il s’agit du temps complémentaire ajouté à la marche de base pour tenir compte de l’imprécision de la mesure de la vitesse, pour pallier les conséquences des incidents extérieurs venant perturber la marche théorique des trains, et pour maintenir la régularité de la circulation. La marge de régularité s’applique sur l’ensemble du trajet, bien que sa valeur puisse changer sur certains intervalles.
                          • La marge de construction : il s’agit du temps ajouté / retiré sur un intervalle spécifique, en plus de la marge de régularité, mais cette fois pour des raisons opérationnelles (esquiver un autre train, libérer une voie plus rapidement, etc.)

                          Une marche de base à laquelle on vient ajouter une marge de régularité donne ce que l’on appelle une marche type.

                          La distribution de la marge

                          L’ajout de marge se traduisant par un abaissement des vitesses le long du trajet, plusieurs marches types sont possibles. En effet, il existe une infinité de solutions aboutissant au même temps de parcours.

                          En guise d’exemple simple, pour détendre la marche d’un train de 10% de son temps de parcours, il est possible de prolonger n’importe quel arrêt de l’équivalent en temps de ces 10%, tout comme il est possible de rouler à 1/1,1 = 90,9% des capacités du train sur l’ensemble du parcours, ou encore de rouler moins vite, mais seulement aux vitesses élevées…

                          Il y a pour l’instant deux algorithmes de distribution de la marge dans OSRD : linéaire et économique.

                          La distribution linéaire

                          La distribution de marge linéaire consiste simplement à abaisser les vitesses d’un même facteur sur la zone où l’utilisateur applique la marge. En voici un exemple d’application :

                          Python plot linear

                          Cette distribution a pour avantage de répartir la marge de la même manière sur tout le trajet. Un train prenant du retard à 30% de son trajet disposera de 70% de sa marge pour les 70% de trajets restants.

                          La distribution économique

                          La distribution économique de la marge, présentée en détail dans ce document (MARECO est un algorithme conçu par la direction de la recherche SNCF), consiste à répartir la marge de la manière la plus économe possible en énergie. Elle est basée sur deux principes :

                          1. une vitesse plafond, évitant les vitesses les plus consommatrices en énergie
                          2. des zones de marche sur l’erre, situées avant les freinages et les fortes pentes, où le train circule à moteur coupé grâce à son inertie, permettant de ne consommer aucune énergie pendant ce laps de temps

                          Python plot eco with slopes

                          Un exemple de marche économique. En haut, les pentes/rampes rencontrées par le train. Les zones de marche sur l’erre sont représentées en bleu.

                          © 2024 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file +La ligne noire représente le MRSP où la longueur du train a été prise en compte.

                          Il est à noter que les différentes envelopeParts composant le MRSP sont des données d’entrée, elles ne correspondent donc pas à des courbes avec une réalité physique.

                          Calcul du profil de vitesse maximale

                          En partant du MRSP, toutes les courbes de freinage sont calculées grâce au système d’overlay (voir ici pour plus de détails sur les overlays), c’est-à-dire en créant des envelopeParts qui seront plus restrictives que le MRSP. La courbe ainsi obtenue est appelée Max Speed Profile (profil de vitesse maximale). Il s’agit de l’enveloppe de vitesse maximale du train, tenant compte de ses capacités de freinage.

                          Etant donné que les courbes de freinage ont un point de fin imposé et que l’équation de freinage n’a pas de solution analytique, il est impossible de prédire leur point de départ. Les courbes de freinage sont donc calculées à rebours en partant de leur point cible, c’est-à-dire le point dans l’espace où une certaine limite de vitesse est imposée (vitesse cible finie) ou le point d’arrêt (vitesse cible nulle).

                          Max Speed Profile

                          Pour des raisons historiques en production horaire, les courbes de freinages sont calculées avec une décélération forfaitaire, dite décélération horaire (typiquement ~0,5m/s²) sans prendre en compte les autres forces. Cette méthode a donc également été implémentée dans OSRD, permettant ainsi de calculer les freinages de deux manières différentes : avec ce taux horaire ou avec une force de freinage qui vient simplement s’ajouter aux autres forces.

                          Calcul du profil d’effort maximal

                          Pour chaque point correspondant à une augmentation de vitesse dans le MRSP ou à la fin d’une courbe de freinage d’arrêt, une courbe d’accélération est calculée. Les courbes d’accélération sont calculées en tenant compte de toutes les forces actives (force de traction, résistance à l’avancement, poids) et ont donc un sens physique.

                          Pour les envelopeParts dont le sens physique n’a pas encore été vérifié (qui à ce stade sont les phases de circulation à vitesse constante, provenant toujours du MRSP), une nouvelle intégration des équations de mouvement est effectuée. Ce dernier calcul est nécessaire pour prendre en compte d’éventuels décrochages de vitesse dans le cas où le train serait physiquement incapable de tenir sa vitesse, typiquement en présence de fortes rampes (voir cet exemple).

                          L’enveloppe qui résulte de ces ajouts de courbes d’accélérations et de la vérification des plateaux de vitesse est appelée Max Effort Profile (profil d’effort maximal).

                          Max Effort Profile

                          A ce stade, l’enveloppe obtenue est continue et a un sens physique du début à fin. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum. Le calcul de marche obtenu s’appelle la marche de base. Elle correspond au trajet le plus rapide possible pour le matériel roulant donné sur le parcours donné.

                          Application de marge(s)

                          Après avoir effectué le calcul de la marche de base (correspondant au Max Effort Profile dans OSRD), il est possible d’y appliquer des marges (allowances). Les marges sont des ajouts de temps supplémentaire au parcours du train. Elles servent notamment à lui permettre de rattraper son retard si besoin ou à d’autres besoins opérationnels (plus de détails sur les marges ici).

                          Une nouvelle enveloppe Allowances est donc calculée grâce à des overlays pour distribuer la marge demandée par l’utilisateur sur l’enveloppe d’effort maximal calculée précédemment.

                          Marges

                          Dans le calcul de marche d’OSRD, il est possible de distribuer les marges d’une manière linéaire, en abaissant toutes les vitesses d’un certain facteur, ou économique, c’est-à-dire en minimisant la consommation d’énergie pendant le parcours du train.

                          5 - Les marges

                          La raison d’être des marges

                          Comme expliqué dans le calcul du Max Effort Profile, la marche de base représente la marche la plus tendue normalement réalisable, c’est-à-dire le trajet le plus rapide possible du matériel donné sur le parcours donné. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum.

                          Cette marche de base présente un inconvénient majeur : si un train part avec 10min de retard, il arrivera au mieux avec 10min de retard, car par définition il lui est impossible de rouler plus vite que la marche de base. Par conséquent, les trains sont programmés avec un ajout d’une ou de plusieurs marges. Les marges sont une détente du trajet du train, un ajout de temps à l’horaire prévu, qui se traduit inévitablement par un abaissement des vitesses de circulation.

                          Un train circulant en marche de base est incapable de rattraper son retard !

                          Le type de marge

                          On distingue deux types de marges :

                          • La marge de régularité : il s’agit du temps complémentaire ajouté à la marche de base pour tenir compte de l’imprécision de la mesure de la vitesse, pour pallier les conséquences des incidents extérieurs venant perturber la marche théorique des trains, et pour maintenir la régularité de la circulation. La marge de régularité s’applique sur l’ensemble du trajet, bien que sa valeur puisse changer sur certains intervalles.
                          • La marge de construction : il s’agit du temps ajouté / retiré sur un intervalle spécifique, en plus de la marge de régularité, mais cette fois pour des raisons opérationnelles (esquiver un autre train, libérer une voie plus rapidement, etc.)

                          Une marche de base à laquelle on vient ajouter une marge de régularité donne ce que l’on appelle une marche type.

                          La distribution de la marge

                          L’ajout de marge se traduisant par un abaissement des vitesses le long du trajet, plusieurs marches types sont possibles. En effet, il existe une infinité de solutions aboutissant au même temps de parcours.

                          En guise d’exemple simple, pour détendre la marche d’un train de 10% de son temps de parcours, il est possible de prolonger n’importe quel arrêt de l’équivalent en temps de ces 10%, tout comme il est possible de rouler à 1/1,1 = 90,9% des capacités du train sur l’ensemble du parcours, ou encore de rouler moins vite, mais seulement aux vitesses élevées…

                          Il y a pour l’instant deux algorithmes de distribution de la marge dans OSRD : linéaire et économique.

                          La distribution linéaire

                          La distribution de marge linéaire consiste simplement à abaisser les vitesses d’un même facteur sur la zone où l’utilisateur applique la marge. En voici un exemple d’application :

                          Python plot linear

                          Cette distribution a pour avantage de répartir la marge de la même manière sur tout le trajet. Un train prenant du retard à 30% de son trajet disposera de 70% de sa marge pour les 70% de trajets restants.

                          La distribution économique

                          La distribution économique de la marge, présentée en détail dans ce document (MARECO est un algorithme conçu par la direction de la recherche SNCF), consiste à répartir la marge de la manière la plus économe possible en énergie. Elle est basée sur deux principes :

                          1. une vitesse plafond, évitant les vitesses les plus consommatrices en énergie
                          2. des zones de marche sur l’erre, situées avant les freinages et les fortes pentes, où le train circule à moteur coupé grâce à son inertie, permettant de ne consommer aucune énergie pendant ce laps de temps

                          Python plot eco with slopes

                          Un exemple de marche économique. En haut, les pentes/rampes rencontrées par le train. Les zones de marche sur l’erre sont représentées en bleu.

                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/explanation/running_time_calculation/allowances/index.html b/fr/docs/explanation/running_time_calculation/allowances/index.html index 248b80d11..628a81bf1 100644 --- a/fr/docs/explanation/running_time_calculation/allowances/index.html +++ b/fr/docs/explanation/running_time_calculation/allowances/index.html @@ -3,7 +3,7 @@ Cette marche de base présente un inconvénient majeur : si un train part avec 10min de retard, il arrivera au mieux avec 10min de retard, car par définition il lui est impossible de rouler plus vite que la marche de base.">

                          Les marges

                          La raison d’être des marges

                          Comme expliqué dans le calcul du Max Effort Profile, la marche de base représente la marche la plus tendue normalement réalisable, c’est-à-dire le trajet le plus rapide possible du matériel donné sur le parcours donné. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum.

                          Cette marche de base présente un inconvénient majeur : si un train part avec 10min de retard, il arrivera au mieux avec 10min de retard, car par définition il lui est impossible de rouler plus vite que la marche de base. Par conséquent, les trains sont programmés avec un ajout d’une ou de plusieurs marges. Les marges sont une détente du trajet du train, un ajout de temps à l’horaire prévu, qui se traduit inévitablement par un abaissement des vitesses de circulation.

                          Un train circulant en marche de base est incapable de rattraper son retard !

                          Le type de marge

                          On distingue deux types de marges :

                          • La marge de régularité : il s’agit du temps complémentaire ajouté à la marche de base pour tenir compte de l’imprécision de la mesure de la vitesse, pour pallier les conséquences des incidents extérieurs venant perturber la marche théorique des trains, et pour maintenir la régularité de la circulation. La marge de régularité s’applique sur l’ensemble du trajet, bien que sa valeur puisse changer sur certains intervalles.
                          • La marge de construction : il s’agit du temps ajouté / retiré sur un intervalle spécifique, en plus de la marge de régularité, mais cette fois pour des raisons opérationnelles (esquiver un autre train, libérer une voie plus rapidement, etc.)

                          Une marche de base à laquelle on vient ajouter une marge de régularité donne ce que l’on appelle une marche type.

                          La distribution de la marge

                          L’ajout de marge se traduisant par un abaissement des vitesses le long du trajet, plusieurs marches types sont possibles. En effet, il existe une infinité de solutions aboutissant au même temps de parcours.

                          En guise d’exemple simple, pour détendre la marche d’un train de 10% de son temps de parcours, il est possible de prolonger n’importe quel arrêt de l’équivalent en temps de ces 10%, tout comme il est possible de rouler à 1/1,1 = 90,9% des capacités du train sur l’ensemble du parcours, ou encore de rouler moins vite, mais seulement aux vitesses élevées…

                          Il y a pour l’instant deux algorithmes de distribution de la marge dans OSRD : linéaire et économique.

                          La distribution linéaire

                          La distribution de marge linéaire consiste simplement à abaisser les vitesses d’un même facteur sur la zone où l’utilisateur applique la marge. En voici un exemple d’application :

                          Python plot linear

                          Cette distribution a pour avantage de répartir la marge de la même manière sur tout le trajet. Un train prenant du retard à 30% de son trajet disposera de 70% de sa marge pour les 70% de trajets restants.

                          La distribution économique

                          La distribution économique de la marge, présentée en détail dans ce document (MARECO est un algorithme conçu par la direction de la recherche SNCF), consiste à répartir la marge de la manière la plus économe possible en énergie. Elle est basée sur deux principes :

                          1. une vitesse plafond, évitant les vitesses les plus consommatrices en énergie
                          2. des zones de marche sur l’erre, situées avant les freinages et les fortes pentes, où le train circule à moteur coupé grâce à son inertie, permettant de ne consommer aucune énergie pendant ce laps de temps

                          Python plot eco with slopes

                          Un exemple de marche économique. En haut, les pentes/rampes rencontrées par le train. Les zones de marche sur l’erre sont représentées en bleu.

                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/explanation/running_time_calculation/envelopes_system/index.html b/fr/docs/explanation/running_time_calculation/envelopes_system/index.html index e66d9f161..7014b9d30 100644 --- a/fr/docs/explanation/running_time_calculation/envelopes_system/index.html +++ b/fr/docs/explanation/running_time_calculation/envelopes_system/index.html @@ -7,7 +7,7 @@ Une interface spécifique dans le service OSRD Core Le système d’enveloppes fait partie du service core d’OSRD (voir l’architecture du logiciel). Ses principaux composants sont :">

                          Le système d'enveloppes

                          Le système d’enveloppes est une interface créée spécifiquement pour le calcul de marche d’OSRD. Il permet de manipuler différentes courbes espace/vitesse, de les découper, de les mettre bout à bout, d’interpoler des points spécifiques, et d’adresser beaucoup d’autres besoins nécessaires au calcul de marche.

                          Une interface spécifique dans le service OSRD Core

                          Le système d’enveloppes fait partie du service core d’OSRD (voir l’architecture du logiciel).

                          Ses principaux composants sont :

                          1 - EnvelopePart : courbe espace/vitesse, définie comme une séquence des points et possédant des métadonnées indiquant par exemple s’il s’agit d’une courbe d’accélération, de freinage, de maintien de vitesse, etc.

                          2 - Envelope : liste d’EnvelopeParts mises bout-à-bout et sur laquelle il est possible d’effectuer certaines opérations :

                          • vérifier la continuité dans l’espace (obligatoire) et dans la vitesse (facultative)
                          • chercher la vitesse minimale et/ou maximale de l’enveloppe
                          • couper une partie de l’enveloppe entre deux points de l’espace
                          • effectuer une interpolation de vitesse à une certaine position
                          • calculer le temps écoulé entre deux positions de l’enveloppe

                          envelope_scheme

                          3 - Overlays : système permettant d’ajouter des EnvelopePart plus contraignantes (c’est-à-dire dont la vitesse est plus faible) à une enveloppe existante.

                          Enveloppes données vs enveloppes calculées

                          Pendant la simulation, le train est censé suivre certaines instructions de vitesse. Celles-ci sont modélisées dans OSRD par des enveloppes sous forme de courbes espace/vitesse. On en distingue deux types :

                          • Les enveloppes provenant des données d’infrastructure et de matériel roulant, comme la vitesse maximale de la ligne et la vitesse maximale du train. Etant des données d’entrée de notre calcul, elles ne correspondent pas à des courbes ayant un sens physique, car elles ne sont pas issues des résultats d’une intégration réelle des équations physiques du mouvement.
                          • Les enveloppes résultant d’une intégration réelle des équations du mouvement physique. Elles correspondent à une courbe physiquement tenable par le train et contiennent également des informations sur le temps.

                          Un exemple simple pour illustrer cette différence : si l’on simule un trajet de TER sur une ligne de montagne, une des données d’entrée va être une enveloppe de vitesse maximale à 160km/h, correspondant à la vitesse maximale de notre TER. Mais cette enveloppe ne correspond pas à une réalité physique, car il se peut que sur certaines portions la rampe soit trop raide pour que le train arrive effectivement à maintenir cette vitesse maximale de 160km/h. L’enveloppe calculée présentera donc dans cet exemple un décrochage de vitesse dans les zones de fortes rampes, là où l’enveloppe donnée était parfaitement plate.

                          Simulation de plusieurs trains

                          Dans le cas de la simulation de nombreux trains, le système de signalisation doit assurer la sécurité. L’effet de la signalisation sur le calcul de marche d’un train est reproduit en superposant des enveloppes dynamiques à l’enveloppe statique. Une nouvelle enveloppe dynamique est introduite par exemple lorsqu’un signal se ferme. Le train suit l’enveloppe économique statique superposée aux enveloppes dynamiques, s’il y en a. Dans ce mode de simulation, un contrôle du temps est effectué par rapport à un temps théorique provenant de l’information temporelle de l’enveloppe économique statique. Si le train est en retard par rapport à l’heure prévue, il cesse de suivre l’enveloppe économique et essaie d’aller plus vite. Sa courbe espace/vitesse sera donc limitée par l’enveloppe d’effort maximum.

                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/explanation/running_time_calculation/index.html b/fr/docs/explanation/running_time_calculation/index.html index f1a6f440c..6413f70dc 100644 --- a/fr/docs/explanation/running_time_calculation/index.html +++ b/fr/docs/explanation/running_time_calculation/index.html @@ -1,5 +1,5 @@ Calcul de marche | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/explanation/running_time_calculation/numerical_integration/index.html b/fr/docs/explanation/running_time_calculation/numerical_integration/index.html index 43dfd5057..b41bf221b 100644 --- a/fr/docs/explanation/running_time_calculation/numerical_integration/index.html +++ b/fr/docs/explanation/running_time_calculation/numerical_integration/index.html @@ -1,5 +1,5 @@ Intégration numérique | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/explanation/running_time_calculation/physical_modeling/index.html b/fr/docs/explanation/running_time_calculation/physical_modeling/index.html index 100a8e9d4..705de1af0 100644 --- a/fr/docs/explanation/running_time_calculation/physical_modeling/index.html +++ b/fr/docs/explanation/running_time_calculation/physical_modeling/index.html @@ -3,7 +3,7 @@ Bilan des forces Pour calculer le déplacement du train au cours du temps, il faut d&rsquo;abord calculer sa vitesse à chaque instant. Une manière simple d&rsquo;obtenir cette vitesse est de passer par le calcul de l&rsquo;accélération. Grâce au principe fondamental de la dynamique, l&rsquo;accélération du train à chaque instant est directement dépendant des différentes forces qui lui sont appliquées : $$ \sum \vec{F}=m\vec{a} $$">
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/explanation/running_time_calculation/pipeline/index.html b/fr/docs/explanation/running_time_calculation/pipeline/index.html index 430f3464c..0e6670daa 100644 --- a/fr/docs/explanation/running_time_calculation/pipeline/index.html +++ b/fr/docs/explanation/running_time_calculation/pipeline/index.html @@ -7,7 +7,7 @@ Construction du profil de vitesse le plus restrictif Ajout des différentes courbes de freinage Ajout des différentes courbes d’accélération et vérification des courbes de vitesse constante Application de marge(s)   Calcul du profil de vitesse le plus restrictif Une première enveloppe est calculée au début de la simulation en regroupant toutes les limites de vitesse statiques :">
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/_print/index.html b/fr/docs/guides/_print/index.html index 2c52a937c..01bce66ce 100644 --- a/fr/docs/guides/_print/index.html +++ b/fr/docs/guides/_print/index.html @@ -1,6 +1,6 @@ Guides pratiques | OSRD -

                          Version imprimable multipages. -Cliquer ici pour imprimer.

                          Retour à la version par défaut.

                          Guides pratiques

                          Marches à suivre pour des tâches classiques

                          Les guides pratiques sont des marches à suivre. Vous êtes guidés pas-à-pas dans la résolution de problèmes, ou dans des scénarios classiques. Les connaissances requises sont plus élevées que pour les tutoriels, et le fonctionnement d’OSRD doit être compris.

                          1 - Contribuer à OSRD

                          Comment apporter sa pierre à l’édifice

                          1.1 - Avant toutes choses

                          Quelques premières informations importantes.

                          Déjà, merci de prendre le temps de contribuer !

                          Si les sections suivantes forment un guide du contributeur, ce n’est pas pour autant un ensemble de règles strictes. En fait, si vous avez déjà contribué à des gros projets open-source, la suite ne sera pas surprenante. Dans le cas contraire, elle vous sera probablement très utile !

                          Communiquer

                          Vous pouvez gagner du temps en discutant de votre projet de contribution avec les autres contributeurs :

                          Se renseigner

                          Comme dans tout projet, chaque changement repose sur ce qui a été fait par le passé. +

                          Version imprimable multipages. +Cliquer ici pour imprimer.

                          Retour à la version par défaut.

                          Guides pratiques

                          Marches à suivre pour des tâches classiques

                          Les guides pratiques sont des marches à suivre. Vous êtes guidés pas-à-pas dans la résolution de problèmes, ou dans des scénarios classiques. Les connaissances requises sont plus élevées que pour les tutoriels, et le fonctionnement d’OSRD doit être compris.

                          1 - Contribuer à OSRD

                          Comment apporter sa pierre à l’édifice

                          1.1 - Avant toutes choses

                          Quelques premières informations importantes.

                          Déjà, merci de prendre le temps de contribuer !

                          Si les sections suivantes forment un guide du contributeur, ce n’est pas pour autant un ensemble de règles strictes. En fait, si vous avez déjà contribué à des gros projets open-source, la suite ne sera pas surprenante. Dans le cas contraire, elle vous sera probablement très utile !

                          Communiquer

                          Vous pouvez gagner du temps en discutant de votre projet de contribution avec les autres contributeurs :

                          Se renseigner

                          Comme dans tout projet, chaque changement repose sur ce qui a été fait par le passé. Avant d’apporter un changement, renseignez-vous sur l’existant :

                          • Vous pouvez lire la documentation technique
                          • Il est préférable de lire le code source de l’application en rapport avec votre projet
                          • Vous pouvez contacter les derniers développeurs à avoir travaillé sur les zones du code en rapport avec votre projet

                          Continuer vers la mise en place ‣

                          1.2 - Licence et mise en place

                          Comment mettre en place l’environnement de développement ? Qu’implique notre licence ?

                          La licence des contributions de code

                          Tout le code du dépot OSRD est mis à disposition sous la licence LGPLv3. En contribuant du code, vous acceptez la redistribution de votre contribution sous cette license.

                          La licence LGPL interdit de modifier OSRD sans publier le code source de l’application modifiée : profitez du travail des autres, et laissez les autres profiter de votre travail !

                          Cette contrainte n’est pas contagieuse à travers les API : Il est possible d’utiliser OSRD comme bibliothèque, framework ou serveur pour s’interfacer avec des composants propriétaires. N’hésitez pas à proposer des changements pour répondre à vos besoins.

                          Mise en place

                          Obtenir le code source

                          • Installer git1
                          • Ouvrir un terminal2 dans le dossier qui contiendra le code source d’OSRD
                          • git clone https://github.com/OpenRailAssociation/osrd.git

                          Lancer l’application

                          Docker est un outil qui réduit considérablement la préparation nécessaire pour travailler sur OSRD:

                          • télécharger le dernier build de développement : docker compose pull
                          • démarrer OSRD : docker compose up
                          • compiler et démarrer OSRD: docker compose up --build
                          • review une PR avec les images compilées par la CI: TAG=pr-XXXXX docker compose up --no-build --pull always

                          Pour commencer :

                          Continuer vers la contribution au code ‣

                          1. Sous Linux, utilisez le gestionnaire de packet (comme apt) ↩︎

                          2. Sous Windows, ouvrez Git Bash ↩︎

                          1.3 - Contribuer au code

                          Apporter des modifications au code d’OSRD

                          Ce chapitre décrit le processus aboutissant à l’intégration de code au sein du projet. Si vous avez besoin d’aide, ouvrez une issue ou envoyez un message instantané.

                          L’application OSRD est divisée en plusieurs services écrits dans plusieurs langues. Nous essayons de suivre les bonnes pratiques générales en matière de code et de respecter les spécificités de chaque langage lorsque cela est nécessaire.

                          1.3.1 - Principes généraux

                          À lire en premier !
                          • Expliquez ce que vous faites et pourquoi.
                          • Documentez le nouveau code.
                          • Ajoutez des tests clairs et simples.
                          • Décomposez le travail en morceaux intelligibles.
                          • Prenez le temps de choisir de bons noms.
                          • Évitez les abréviations peu connues.
                          • Contrôle et cohérence de la réutilisation du code de tiers : une dépendance est ajoutée seulement si elle est absolument nécessaire.
                          • Chaque dépendance ajoutée diminue notre autonomie et notre cohérence.
                          • Nous essayons de limiter à un petit nombre les PRs de mise à jour des dépendances chaque semaine dans chaque composant, donc regrouper les montées de version dans une même PR est une bonne option @@ -243,4 +243,38 @@

                          Utilisation seule du logo (sans le texte)

                          Les couleurs

                          Ces couleurs sont celles du logo, elles ne sont pas à confondre avec celles du design global de l’interface d’OSRD.

                          #786ABF -#C7B2DE

                          © 2024 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file +#C7B2DE

                          5 - Publication

                          Section sur les releases

                          Cette section documente le processus de création d’une publication d’OSRD.

                          5.1 - Processus de publication

                          Voici comment OSRD est actuellement publié

                          OSRD possède trois versions : développement (dev), staging et publication.

                          La version de développement est la version la plus récente et la plus instable de l’application, contenant les dernières fonctionnalités et corrections de bugs en cours de développement.

                          Les versions staging sont créées tous les jeudis à 12h en taguant l’état actuel du développement.

                          Si une version staging passe les tests de validation, elle est promue pour devenir la dernière version publication. Cela garantit que seul du code stable et testé est intégré dans les versions de production.

                          Le processus de publication suit ce workflow :

                          1. Développement continu dans la branche dev
                          2. Tags de staging hebdomadaires les jeudis à 12h
                          3. Tests de validation de la version staging
                          4. Promotion des builds staging validés au statut de publication
                              Développement      Staging                publication
+    (instable)         (test)                   (stable)
+
+    [Branche Dev]                                  |
+         |                                         |
+         |--->     Jeudi 12h                       |
+         |         [Tag Staging]                   |
+         |                |                        |
+         |            Validation                   |
+         |              Tests                      |
+         |                |                        |
+         |                o---> Si Passage -->  Nouvelle
+         |                        Tests        publication
+    [Suite Dev]                                    |
+         |                                         |
+         V                                         V
+

                          5.2 - Publier une nouvelle version

                          Comment publier une nouvelle version

                          Toutes les versions d’OSRD sont accessibles ici

                          Le processus de création d’une nouvelle version est le suivant :

                          1. Nous publions toujours sur une version testée de l’application (branche staging)
                            • git switch staging && git pull
                          2. Créer un tag git annoté
                            • Nous utilisons le versionnement sémantique
                            • git tag -a vx.y.z avec le message Release x.y.z (la plupart du temps, utilisez la dernière version et incrémentez la version patch)
                            • git push --tags
                          3. Créer une release GitHub
                            • Créer une nouvelle release GitHub ici
                            • Sélectionner le tag créé
                            • Générer les notes de version
                            • Renommer la release ainsi : “Version x.y.z”
                            • Cocher la case “Set as a pre-release”
                            • Appliquer le format du changelog
                            • Vous pouvez ensuite publier la release ou sauvegarder le brouillon si vous souhaitez y revenir plus tard
                          4. Une action GitHub devrait être déclenchée automatiquement.
                          5. Poster le lien de la release créée sur Matrix. Suggérer aux développeurs de revoir la release.

                          Format du changelog

                          1. Utiliser la structure suivante :
                          ## What's Changed
+
+### Features :tada:
+
+
+### Code refactoring :recycle:
+
+
+### Bug fixes :bug:
+
+
+## New Contributors
+
+<!-- Copy from the generated release notes -->
+...
+
+<!-- Copy from the generated release notes -->
+**Full Changelog**: ...
+
                          1. Répartir les différentes pull requests
                          2. Fusionner ou regrouper les PR quand cela a du sens. Exemples :
                            • PR de mise à jour des dépendances (fusionner)
                            • PR en plusieurs parties (fusionner)
                            • Une grande fonctionnalité implémentée par plusieurs PR (regrouper)
                          3. Reformuler les titres des PR. Ils doivent être compréhensibles pour un collaborateur externe
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/_print/index.html b/fr/docs/guides/contribute/_print/index.html index 3167e9069..934e2da3a 100644 --- a/fr/docs/guides/contribute/_print/index.html +++ b/fr/docs/guides/contribute/_print/index.html @@ -1,5 +1,5 @@ Contribuer à OSRD | OSRD -

                          Version imprimable multipages. +

                          Version imprimable multipages. Cliquer ici pour imprimer.

                          Retour à la version par défaut.

                          Contribuer à OSRD

                          Comment apporter sa pierre à l’édifice

                          1 - Avant toutes choses

                          Quelques premières informations importantes.

                          Déjà, merci de prendre le temps de contribuer !

                          Si les sections suivantes forment un guide du contributeur, ce n’est pas pour autant un ensemble de règles strictes. En fait, si vous avez déjà contribué à des gros projets open-source, la suite ne sera pas surprenante. Dans le cas contraire, elle vous sera probablement très utile !

                          Communiquer

                          Vous pouvez gagner du temps en discutant de votre projet de contribution avec les autres contributeurs :

                          Se renseigner

                          Comme dans tout projet, chaque changement repose sur ce qui a été fait par le passé. Avant d’apporter un changement, renseignez-vous sur l’existant :

                          • Vous pouvez lire la documentation technique
                          • Il est préférable de lire le code source de l’application en rapport avec votre projet
                          • Vous pouvez contacter les derniers développeurs à avoir travaillé sur les zones du code en rapport avec votre projet

                          Continuer vers la mise en place ‣

                          2 - Licence et mise en place

                          Comment mettre en place l’environnement de développement ? Qu’implique notre licence ?

                          La licence des contributions de code

                          Tout le code du dépot OSRD est mis à disposition sous la licence LGPLv3. En contribuant du code, vous acceptez la redistribution de votre contribution sous cette license.

                          La licence LGPL interdit de modifier OSRD sans publier le code source de l’application modifiée : profitez du travail des autres, et laissez les autres profiter de votre travail !

                          Cette contrainte n’est pas contagieuse à travers les API : Il est possible d’utiliser OSRD comme bibliothèque, framework ou serveur pour s’interfacer avec des composants propriétaires. N’hésitez pas à proposer des changements pour répondre à vos besoins.

                          Mise en place

                          Obtenir le code source

                          • Installer git1
                          • Ouvrir un terminal2 dans le dossier qui contiendra le code source d’OSRD
                          • git clone https://github.com/OpenRailAssociation/osrd.git

                          Lancer l’application

                          Docker est un outil qui réduit considérablement la préparation nécessaire pour travailler sur OSRD:

                          • télécharger le dernier build de développement : docker compose pull
                          • démarrer OSRD : docker compose up
                          • compiler et démarrer OSRD: docker compose up --build
                          • review une PR avec les images compilées par la CI: TAG=pr-XXXXX docker compose up --no-build --pull always

                          Pour commencer :

                          Continuer vers la contribution au code ‣

                          1. Sous Linux, utilisez le gestionnaire de packet (comme apt) ↩︎

                          2. Sous Windows, ouvrez Git Bash ↩︎

                          3 - Contribuer au code

                          Apporter des modifications au code d’OSRD

                          Ce chapitre décrit le processus aboutissant à l’intégration de code au sein du projet. Si vous avez besoin d’aide, ouvrez une issue ou envoyez un message instantané.

                          L’application OSRD est divisée en plusieurs services écrits dans plusieurs langues. Nous essayons de suivre les bonnes pratiques générales en matière de code et de respecter les spécificités de chaque langage lorsque cela est nécessaire.

                          3.1 - Principes généraux

                          À lire en premier !
                          • Expliquez ce que vous faites et pourquoi.
                          • Documentez le nouveau code.
                          • Ajoutez des tests clairs et simples.
                          • Décomposez le travail en morceaux intelligibles.
                          • Prenez le temps de choisir de bons noms.
                          • Évitez les abréviations peu connues.
                          • Contrôle et cohérence de la réutilisation du code de tiers : une dépendance est ajoutée seulement si elle est absolument nécessaire.
                          • Chaque dépendance ajoutée diminue notre autonomie et notre cohérence.
                          • Nous essayons de limiter à un petit nombre les PRs de mise à jour des dépendances chaque semaine @@ -210,4 +210,4 @@ A->>R: Rebase si nécessaire R->>A: Vérifie l'historique des commits R->>A: Approuve ou ferme la PR - Note left of R: Et fusionne si mainteneur

                            Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).

                          © 2024 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file + Note left of R: Et fusionne si mainteneur

                          Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).

                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/bug-reports/index.html b/fr/docs/guides/contribute/bug-reports/index.html index 93b47125f..dd47166be 100644 --- a/fr/docs/guides/contribute/bug-reports/index.html +++ b/fr/docs/guides/contribute/bug-reports/index.html @@ -1,5 +1,5 @@ Signaler des problèmes | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/code-review/index.html b/fr/docs/guides/contribute/code-review/index.html index 37c223362..32c75be02 100644 --- a/fr/docs/guides/contribute/code-review/index.html +++ b/fr/docs/guides/contribute/code-review/index.html @@ -1,5 +1,5 @@ Revue de code | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/_print/index.html b/fr/docs/guides/contribute/contribute-code/_print/index.html index 2bb885cf7..49af3bfb5 100644 --- a/fr/docs/guides/contribute/contribute-code/_print/index.html +++ b/fr/docs/guides/contribute/contribute-code/_print/index.html @@ -1,5 +1,5 @@ Contribuer au code | OSRD -

                          Version imprimable multipages. +

                          Version imprimable multipages. Cliquer ici pour imprimer.

                          Retour à la version par défaut.

                          Contribuer au code

                          Apporter des modifications au code d’OSRD

                          Ce chapitre décrit le processus aboutissant à l’intégration de code au sein du projet. Si vous avez besoin d’aide, ouvrez une issue ou envoyez un message instantané.

                          L’application OSRD est divisée en plusieurs services écrits dans plusieurs langues. Nous essayons de suivre les bonnes pratiques générales en matière de code et de respecter les spécificités de chaque langage lorsque cela est nécessaire.

                          1 - Principes généraux

                          À lire en premier !
                          • Expliquez ce que vous faites et pourquoi.
                          • Documentez le nouveau code.
                          • Ajoutez des tests clairs et simples.
                          • Décomposez le travail en morceaux intelligibles.
                          • Prenez le temps de choisir de bons noms.
                          • Évitez les abréviations peu connues.
                          • Contrôle et cohérence de la réutilisation du code de tiers : une dépendance est ajoutée seulement si elle est absolument nécessaire.
                          • Chaque dépendance ajoutée diminue notre autonomie et notre cohérence.
                          • Nous essayons de limiter à un petit nombre les PRs de mise à jour des dépendances chaque semaine dans chaque composant, donc regrouper les montées de version dans une même PR est une bonne option (reportez-vous au README.md de chaque composant).
                          • Ne pas réinventer la roue : en opposition au point précédent, ne réinventez pas tout à tout prix.
                          • S’il existe une dépendance dans l’écosystème qui est le standard « de facto », nous devrions fortement envisager de l’utiliser.
                          • Plus de code et de recommandations générales dans le dépôt principal CONTRIBUTING.md.
                          • Demandez toute l’aide dont vous avez besoin !

                          Consulter les conventions pour le back-end ‣

                          Consulter les conventions pour le front-end ‣

                          Continuer vers l’écriture de code ‣

                          Continuer vers l’écriture de tests ‣

                          2 - Conventions back-end

                          Conventions de codes et bonnes pratiques pour le back-end

                          Python

                          Le code Python est utilisé pour certains paquets et pour les tests d’intégration.

                          Rust

                          • Comme référence pour le développement de notre API, nous utilisons les Rust API guidelines. @@ -167,4 +167,4 @@ R->>A: Vérifie l'historique des commits R->>A: Approuve ou ferme la PR Note left of R: Et fusionne si mainteneur

                            Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).

                            Continuer enfin vers les tests ‣

                          7 - Tests

                          Recommandations pour les tests

                          Back-end

                          • Les tests d’intégration sont écrits avec pytest dans le dossier /tests.
                          • Chaque route décrite dans les fichiers openapi.yaml doit avoir un test d’intégration.
                          • Le test doit vérifier à la fois le format et le contenu des réponses valides et invalides.

                          Front-end

                          L’écriture fonctionnelle des tests est réalisée avec les Product Owners, et les développeurs choisissent une implémentation technique qui répond précisément aux besoins exprimés et qui s’intègre dans les recommandations présentes ici.

                          Nous utilisons Playwright pour écrire les tests bout en bout, et vitest pour écrire les tests unitaires.

                          Les navigateurs testés sont pour l’instant Firefox et Chromium.

                          Principes de base

                          • Les tests doivent être courts (1min max) et aller droit au but.
                          • Les timeout arbitraires sont proscrits, un test doit systématiquement attendre un évènement spécifique. Il est possible d’utiliser le polling (retenter une action — un clic par exemple — au bout d’un certain temps) proposé dans l’API de Playwright.
                          • Les tests doivent tous pouvoir être parallélisables.
                          • Les tests ne doivent pas pointer/attendre des éléments de texte issus de la traduction, préférer l’arborescence du DOM ou encore placer des id spécifiques.
                          • On ne teste pas les données mais l’application et ses fonctionnalités. Des tests spécifiques aux données sont à élaborer par ailleurs.

                          Données

                          Les données testées doivent impérativement être des données publiques. -Les données nécessaires (infrastructure et matériel) aux tests sont proposées dans des fichiers json de l’application, injectées au début de chaque test et effacées à la fin peu importe son résultat ou la manière d’être stoppé, y compris par CTRL+C.

                          Cela se fait par des appels API en typescript avant de lancer le test à proprement parler.

                          Les données testées sont les mêmes en local ou via l’intégration continue.

                          Atomicité d’un test

                          Chaque test doit être atomique : il se suffit à lui même et ne peut pas être divisé.

                          Un test va cibler une fonctionnalité ou un composant, si ce dernier n’est pas trop gros. Un test ne testera pas tout un module ou tout une application, ce sera forcément un ensemble de tests afin de préserver l’atomicité des tests.

                          Si un test a besoin que des éléments soient créés ou ajoutés, ces opérations doivent être opérées par des appels API en typescript en amont du test, à l’instar de ce qui est fait pour l’ajout de données. Ces éléments doivent être supprimés à l’issue du test, peu importe son résultat ou la manière d’être stoppé, y compris par CTRL+C.

                          Cela permettra notamment la parallélisation des tests.

                          Un test peut cependant, dans certains cas de figure où cela est pertinent, contenir plusieurs sous-divisions de test, clairement explicitées, et justifiées (plusieurs test() dans un seul describe()).

                          Exemple de test

                          Le besoin : « nous voulons tester l’ajout d’un train dans une grille horaire ».

                          1. ajouter l’infrastructure et le matériel roulant de test dans la base de données par appels API
                          2. créer projet, étude et scénario avec choix de l’infra de test par appels API
                          3. début du test qui clique sur « ajouter un ou plusieurs trains » jusqu’à la vérification de la présence des trains dans la grille horaire
                          4. le test a réussi, a échoué, ou est stoppé, le projet, l’étude et le scénario sont effacés, ainsi que le matériel roulant et et l’infrastructure de test par appels API

                          NB : le test ne va pas tester toutes les possibilités offertes par l’ajout de trains, cela relève d’un test spécifique qui testerait la réponse de l’interface pour tous les cas de figure sans ajouter de trains.

                          Continuer vers l’écriture de code ‣

                          © 2024 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file +Les données nécessaires (infrastructure et matériel) aux tests sont proposées dans des fichiers json de l’application, injectées au début de chaque test et effacées à la fin peu importe son résultat ou la manière d’être stoppé, y compris par CTRL+C.

                          Cela se fait par des appels API en typescript avant de lancer le test à proprement parler.

                          Les données testées sont les mêmes en local ou via l’intégration continue.

                          Atomicité d’un test

                          Chaque test doit être atomique : il se suffit à lui même et ne peut pas être divisé.

                          Un test va cibler une fonctionnalité ou un composant, si ce dernier n’est pas trop gros. Un test ne testera pas tout un module ou tout une application, ce sera forcément un ensemble de tests afin de préserver l’atomicité des tests.

                          Si un test a besoin que des éléments soient créés ou ajoutés, ces opérations doivent être opérées par des appels API en typescript en amont du test, à l’instar de ce qui est fait pour l’ajout de données. Ces éléments doivent être supprimés à l’issue du test, peu importe son résultat ou la manière d’être stoppé, y compris par CTRL+C.

                          Cela permettra notamment la parallélisation des tests.

                          Un test peut cependant, dans certains cas de figure où cela est pertinent, contenir plusieurs sous-divisions de test, clairement explicitées, et justifiées (plusieurs test() dans un seul describe()).

                          Exemple de test

                          Le besoin : « nous voulons tester l’ajout d’un train dans une grille horaire ».

                          1. ajouter l’infrastructure et le matériel roulant de test dans la base de données par appels API
                          2. créer projet, étude et scénario avec choix de l’infra de test par appels API
                          3. début du test qui clique sur « ajouter un ou plusieurs trains » jusqu’à la vérification de la présence des trains dans la grille horaire
                          4. le test a réussi, a échoué, ou est stoppé, le projet, l’étude et le scénario sont effacés, ainsi que le matériel roulant et et l’infrastructure de test par appels API

                          NB : le test ne va pas tester toutes les possibilités offertes par l’ajout de trains, cela relève d’un test spécifique qui testerait la réponse de l’interface pour tous les cas de figure sans ajouter de trains.

                          Continuer vers l’écriture de code ‣

                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/backend-conventions/index.html b/fr/docs/guides/contribute/contribute-code/backend-conventions/index.html index 8876a569c..bd04fc997 100644 --- a/fr/docs/guides/contribute/contribute-code/backend-conventions/index.html +++ b/fr/docs/guides/contribute/contribute-code/backend-conventions/index.html @@ -1,5 +1,5 @@ Conventions back-end | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/commit-conventions/index.html b/fr/docs/guides/contribute/contribute-code/commit-conventions/index.html index 194da9354..69351a209 100644 --- a/fr/docs/guides/contribute/contribute-code/commit-conventions/index.html +++ b/fr/docs/guides/contribute/contribute-code/commit-conventions/index.html @@ -1,5 +1,5 @@ Conventions de commits | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/frontend-conventions/index.html b/fr/docs/guides/contribute/contribute-code/frontend-conventions/index.html index 0f1bc77ab..fedcd28fa 100644 --- a/fr/docs/guides/contribute/contribute-code/frontend-conventions/index.html +++ b/fr/docs/guides/contribute/contribute-code/frontend-conventions/index.html @@ -1,5 +1,5 @@ Conventions front-end | OSRD -

                          Cette pratique permet de :

                          • Améliorer les performances et le travail d’analyse du compilateur et du linter.
                          • Rendre ces déclarations plus lisibles, on voit clairement ce qu’on est en train d’importer.
                          • Éviter des cycles de dépendances :

                          dependency cycle

                          L’erreur disparaît avec le mot clé type

                          dependency cycle

                          • Alléger le bundle final (tous les types disparaissent à la compilation).
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/general-principles/index.html b/fr/docs/guides/contribute/contribute-code/general-principles/index.html index 4884b3e6d..313b3f7bc 100644 --- a/fr/docs/guides/contribute/contribute-code/general-principles/index.html +++ b/fr/docs/guides/contribute/contribute-code/general-principles/index.html @@ -1,5 +1,5 @@ Principes généraux | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/index.html b/fr/docs/guides/contribute/contribute-code/index.html index ed4e9d8ea..9422daf6e 100644 --- a/fr/docs/guides/contribute/contribute-code/index.html +++ b/fr/docs/guides/contribute/contribute-code/index.html @@ -1,5 +1,5 @@ Contribuer au code | OSRD -

                          Contribuer au code

                          Apporter des modifications au code d’OSRD

                          Ce chapitre décrit le processus aboutissant à l’intégration de code au sein du projet. Si vous avez besoin d’aide, ouvrez une issue ou envoyez un message instantané.

                          L’application OSRD est divisée en plusieurs services écrits dans plusieurs langues. Nous essayons de suivre les bonnes pratiques générales en matière de code et de respecter les spécificités de chaque langage lorsque cela est nécessaire.

                          Principes généraux

                          À lire en premier !

                          Conventions back-end

                          Conventions de codes et bonnes pratiques pour le back-end

                          Conventions front-end

                          Conventions de codes et bonnes pratiques pour le front-end

                          Écrire du code

                          Apporter des modifications au code d’OSRD

                          Conventions de commits

                          Quelques bonnes pratiques et règles pour les messages de commits

                          Partagez vos changements

                          Comment soumettre votre code pour qu’il soit vérifié ?

                          Tests

                          Recommandations pour les tests

                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/share-changes/index.html b/fr/docs/guides/contribute/contribute-code/share-changes/index.html index ce3b755d6..d97715617 100644 --- a/fr/docs/guides/contribute/contribute-code/share-changes/index.html +++ b/fr/docs/guides/contribute/contribute-code/share-changes/index.html @@ -1,5 +1,5 @@ Partagez vos changements | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/tests/index.html b/fr/docs/guides/contribute/contribute-code/tests/index.html index 8f87d3025..c5f351604 100644 --- a/fr/docs/guides/contribute/contribute-code/tests/index.html +++ b/fr/docs/guides/contribute/contribute-code/tests/index.html @@ -1,5 +1,5 @@ Tests | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/contribute-code/write-code/index.html b/fr/docs/guides/contribute/contribute-code/write-code/index.html index ff40215a9..acd1cc30e 100644 --- a/fr/docs/guides/contribute/contribute-code/write-code/index.html +++ b/fr/docs/guides/contribute/contribute-code/write-code/index.html @@ -1,5 +1,5 @@ Écrire du code | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/index.html b/fr/docs/guides/contribute/index.html index fd73d6314..f59d4b4d9 100644 --- a/fr/docs/guides/contribute/index.html +++ b/fr/docs/guides/contribute/index.html @@ -1,5 +1,5 @@ Contribuer à OSRD | OSRD -

                          Contribuer à OSRD

                          Comment apporter sa pierre à l’édifice
                          Avant toutes choses

                          Quelques premières informations importantes.

                          Licence et mise en place

                          Comment mettre en place l’environnement de développement ? Qu’implique notre licence ?

                          Contribuer au code

                          Apporter des modifications au code d’OSRD

                          Revue de code

                          Comment faire des retours constructifs

                          Signaler des problèmes

                          Comment signaler un bug ou suggérer une amélioration

                          Installer docker

                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/install-docker/index.html b/fr/docs/guides/contribute/install-docker/index.html index 9fc1e4a2c..6f4520bcb 100644 --- a/fr/docs/guides/contribute/install-docker/index.html +++ b/fr/docs/guides/contribute/install-docker/index.html @@ -11,7 +11,7 @@ Si vous êtes sous linux, installez docker engine via votre gestionnaire de packet Si vous êtes sous MacOS / Windows, installez docker desktop si vous y êtes autorisés Si vous êtes sous windows, et voulez faire fonctionner docker sous WSL, ou ne pouvez pas utiliser docker desktop, suivez le guide docker sous WSL Si vous êtes sous MacOS, et vous ne pouvez pas utiliser docker desktop, suivez le guide colima pour MacOS Docker sous WSL Cette option d’installation est très utile, car elle permet de disposer d’une installation tout à fait normale de docker engine Linux à l’intérieur de WSL, qui reste accessible depuis Windows.">
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/license-and-set-up/index.html b/fr/docs/guides/contribute/license-and-set-up/index.html index f2ebb5287..7f251e276 100644 --- a/fr/docs/guides/contribute/license-and-set-up/index.html +++ b/fr/docs/guides/contribute/license-and-set-up/index.html @@ -1,5 +1,5 @@ Licence et mise en place | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/preamble/index.html b/fr/docs/guides/contribute/preamble/index.html index eb1c2a549..a69c732ce 100644 --- a/fr/docs/guides/contribute/preamble/index.html +++ b/fr/docs/guides/contribute/preamble/index.html @@ -1,5 +1,5 @@ Avant toutes choses | OSRD -
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/contribute/review-process/index.html b/fr/docs/guides/contribute/review-process/index.html index 16b0b2ab2..69752825a 100644 --- a/fr/docs/guides/contribute/review-process/index.html +++ b/fr/docs/guides/contribute/review-process/index.html @@ -7,7 +7,7 @@ Il est conseillé de configurer les dépôts OSRD en “Participating and @mentions”. Cela permet d’être notifié d’activités uniquement sur les issues et PR auxquelles vous participez. sequenceDiagram actor A as Auteur PR actor R as Reviewer/mainteneur A->>R: Demande une review en notifiant spéciquement quelques personnes R->>A: Répond à la demande par oui ou non loop Boucle entre auteur et reviewer R-->>A: Commente, demande des changements A-->>R: Répond à chaque commentaire/demande de changement A-->>R: Corrige le code si nécessaire dans des « fixups » dédiés R-->>A: Vérifie, teste, et commente à nouveau le code R-->>A: Résout les conversations/demandes de changement le cas échéant end A->>R: Rebase si nécessaire R->>A: Vérifie l'historique des commits R->>A: Approuve ou ferme la PR Note left of R: Et fusionne si mainteneur Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS.">
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/deploy/_print/index.html b/fr/docs/guides/deploy/_print/index.html index a3d9cb5ea..842bbe458 100644 --- a/fr/docs/guides/deploy/_print/index.html +++ b/fr/docs/guides/deploy/_print/index.html @@ -1,5 +1,5 @@ Déployer OSRD | OSRD -

                          Version imprimable multipages. +

                          Version imprimable multipages. Cliquer ici pour imprimer.

                          Retour à la version par défaut.

                          Déployer OSRD

                          Apprenez à déployer OSRD dans différents environnements

                          Tout d’abord, nous recommandons de se familiariser sur l’architecture des conteneurs d’OSRD.

                          Nous allons couvrir comment déployer OSRD dans les configurations suivantes :

                          Il est également possible de déployer manuellement chaque service d’OSRD sur un système, mais nous ne couvrirons pas ce sujet dans ce guide.

                          1 - Configuration de l'environnement de recherche STDCM

                          Comment configurer l’environnement de recherche STDCM

                          Pour que l’outil STDCM fonctionne, il faut configurer l’environnement de recherche STDCM, une configuration stockée en base de données.

                          Les champs configurables sont les suivants :

                          pub struct StdcmSearchEnvironment {
     pub infra_id: i64,
@@ -28,4 +28,4 @@
     gw -- HTTP --> tileserver-2
     gw -- HTTP --> tileserver-n...
     editoast -- HTTP --> core

                          Le Helm Chart utilise leHorizontalPodAutoscaler de Kubernetes pour lancer autant de serveurs de tuiles que nécessaire en fonction de la charge de travail.

                          Configuration de la Helm Chart (values)

                          Le Helm Chart est configurable à travers les valeurs suivantes :

                          Service Core

                          • core : Configuration pour le service central OSRD.
                            • internalUrl : URL interne pour la communication entre services.
                            • image : Image Docker à utiliser.
                            • pullPolicy : Politique de récupération de l’image.
                            • replicaCount : Nombre de réplicas.
                            • service : Type de service et configuration des ports.
                            • resources, env, annotations, labels, nodeSelector, tolerations, affinity : Diverses options de déploiement Kubernetes.

                          Service Editoast

                          • editoast : Configuration pour le service Editoast.
                            • Comprend des options similaires à core pour le déploiement Kubernetes.
                            • init : Configuration d’initialisation.

                          Serveur de tuiles

                          • tileServer : Service Editoast spécialisé qui sert uniquement des tuiles cartographiques vectorielles.
                            • enabled : Définir sur true pour activer la fonctionnalité de serveur de tuiles.
                            • image : Image Docker à utiliser (généralement la même que Editoast).
                            • replicaCount : Nombre de réplicas, permettant la mise à l’échelle horizontale.
                            • hpa : Configuration de l’Horizontal Pod Autoscaler.
                            • Autres options standard de déploiement Kubernetes.

                          Gateway

                          • gateway : Configuration pour le gateway OSRD.
                            • Comprend des options de service, d’ingress et d’autres options de déploiement Kubernetes.
                            • config : Configurations spécifiques pour l’authentification et les proxys de confiance.

                          Déploiement

                          Le chart est disponible dans le dépôt OCI ghcr. Vous pouvez trouver 2 versions de la chart :

                          Pour déployer les services OSRD en utilisant Helm :

                          1. Configurer les valeurs : Ajustez les valeurs selon vos besoins de déploiement.

                          2. Installer le Chart : Utilisez la commande helm install pour installer la chart dans votre cluster Kubernetes.

                            helm install osrd oci://ghcr.io/OpenRailAssociation/charts/osrd -f values.yml
-
                          © 2024 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file +
                          © 2025 Contributeurs à OSRD. Tous droits réservés
                          \ No newline at end of file diff --git a/fr/docs/guides/deploy/docker-compose/_print/index.html b/fr/docs/guides/deploy/docker-compose/_print/index.html index 1b3baa519..4735c2f2b 100644 --- a/fr/docs/guides/deploy/docker-compose/_print/index.html +++ b/fr/docs/guides/deploy/docker-compose/_print/index.html @@ -1,9 +1,9 @@ Docker Compose | OSRD -

                          Version imprimable multipages. +

                          Version imprimable multipages. Cliquer ici pour imprimer.

                          Retour à la version par défaut.

                          Docker Compose

                          Utiliser docker compose pour un déploiement sur un seul nœud

                            Le projet OSRD inclut un fichier docker-compose.yml conçu pour faciliter le déploiement d’un environnement OSRD pleinement fonctionnel. Exclusivement destiné à des fins de développement, cette configuration Docker Compose pourrait être adaptée pour des déploiements rapides sur un seul nœud.

                            Prérequis

                            Avant de procéder au déploiement, assurez-vous que vous avez installé :

                            • Docker
                            • Docker Compose

                            Vue d’ensemble de la configuration

                            Le fichier docker-compose.yml définit les services suivants :

                            1. PostgreSQL : Une base de données PostgreSQL avec l’extension PostGIS.
                            2. Valkey : Un serveur Valkey pour le cache.
                            3. Core : Le service central OSRD.
                            4. Front : Le service front-end pour OSRD.
                            5. Editoast : Un service OSRD responsable de diverses fonctions d’édition.
                            6. Gateway : Sert de passerelle pour les services OSRD.
                            7. Wait-Healthy : Un service utilitaire pour s’assurer que tous les services sont sains avant de procéder.

                            Chaque service est configuré avec des contrôles de santé, des montages de volumes et les variables d’environnement nécessaires.

                            Étapes du déploiement

                            1. Cloner le dépôt : Tout d’abord, clonez le dépôt OSRD sur votre machine locale.
                            2. Configuration : La configuration par défaut nécessite le renseignement d’une variable d’environnement pour le service Editoast: ROOT_URL. Il faut lui donner la valeur de l’URL qui pointe vers le service Editoast par la gateway. Par exemple “http://your-domain.com/api". Vous pouvez également ajuster d’autres variables d’environnement si nécessaire.
                            3. Construire et exécuter : Naviguez vers le répertoire contenant docker-compose.yml et exécutez :
                            docker-compose up --build
-

                            Cette commande construit les images et démarre les services définis dans le fichier Docker Compose.

                            Accès aux services

                            Bien que tous les services HTTP soient utilisés via la passerelle (http://localhost:4000), vous pouvez accéder directement à chaque service en utilisant leurs ports exposés :

                            • PostgreSQL : Accessible sur localhost:5432.
                            • Valkey : Accessible sur localhost:6379.
                            • Service Core : Accessible sur localhost:8080.
                            • Front-End : Accessible sur localhost:3000.
                            • Editoast : Accessible sur localhost:8090.

                            Notes et considérations

                            • Cette configuration est conçue pour le développement et les déploiements rapides. Pour les environnements de production, des considérations supplémentaires en matière de sécurité, de scalabilité et de fiabilité doivent être abordées.
                            • Assurez-vous que le POSTGRES_PASSWORD et d’autres identifiants sensibles sont gérés en toute sécurité, en particulier dans les déploiements de production.
                            © 2024 Contributeurs à OSRD. Tous droits réservés
                            \ No newline at end of file +

                            Cette commande construit les images et démarre les services définis dans le fichier Docker Compose.

                            Accès aux services

                            Bien que tous les services HTTP soient utilisés via la passerelle (http://localhost:4000), vous pouvez accéder directement à chaque service en utilisant leurs ports exposés :

                            • PostgreSQL : Accessible sur localhost:5432.
                            • Valkey : Accessible sur localhost:6379.
                            • Service Core : Accessible sur localhost:8080.
                            • Front-End : Accessible sur localhost:3000.
                            • Editoast : Accessible sur localhost:8090.

                            Notes et considérations

                            • Cette configuration est conçue pour le développement et les déploiements rapides. Pour les environnements de production, des considérations supplémentaires en matière de sécurité, de scalabilité et de fiabilité doivent être abordées.
                            • Assurez-vous que le POSTGRES_PASSWORD et d’autres identifiants sensibles sont gérés en toute sécurité, en particulier dans les déploiements de production.
                            \ No newline at end of file diff --git a/fr/docs/guides/deploy/docker-compose/index.html b/fr/docs/guides/deploy/docker-compose/index.html index 215f19bde..2cad65e4d 100644 --- a/fr/docs/guides/deploy/docker-compose/index.html +++ b/fr/docs/guides/deploy/docker-compose/index.html @@ -1,5 +1,5 @@ Docker Compose | OSRD -

                            Cette commande construit les images et démarre les services définis dans le fichier Docker Compose.

                            Accès aux services

                            Bien que tous les services HTTP soient utilisés via la passerelle (http://localhost:4000), vous pouvez accéder directement à chaque service en utilisant leurs ports exposés :

                            • PostgreSQL : Accessible sur localhost:5432.
                            • Valkey : Accessible sur localhost:6379.
                            • Service Core : Accessible sur localhost:8080.
                            • Front-End : Accessible sur localhost:3000.
                            • Editoast : Accessible sur localhost:8090.

                            Notes et considérations

                            • Cette configuration est conçue pour le développement et les déploiements rapides. Pour les environnements de production, des considérations supplémentaires en matière de sécurité, de scalabilité et de fiabilité doivent être abordées.
                            • Assurez-vous que le POSTGRES_PASSWORD et d’autres identifiants sensibles sont gérés en toute sécurité, en particulier dans les déploiements de production.
                            \ No newline at end of file diff --git a/fr/docs/guides/deploy/index.html b/fr/docs/guides/deploy/index.html index 5ffb37fea..482d43c52 100644 --- a/fr/docs/guides/deploy/index.html +++ b/fr/docs/guides/deploy/index.html @@ -1,5 +1,5 @@ Déployer OSRD | OSRD -
                            \ No newline at end of file diff --git a/fr/docs/guides/deploy/kubernetes/_print/index.html b/fr/docs/guides/deploy/kubernetes/_print/index.html index 373f891ef..b6731f19f 100644 --- a/fr/docs/guides/deploy/kubernetes/_print/index.html +++ b/fr/docs/guides/deploy/kubernetes/_print/index.html @@ -1,5 +1,5 @@ Kubernetes avec Helm | OSRD -

                            Version imprimable multipages. +

                            Version imprimable multipages. Cliquer ici pour imprimer.

                            Retour à la version par défaut.

                            Kubernetes avec Helm

                            Utilisation de Helm pour les déploiements Kubernetes

                              La Helm Chart du projet OSRD fournit une solution pour déployer les services OSRD dans un environnement Kubernetes de manière standardisée. Ce document décrit les options de configuration disponibles dans le Helm Chart.

                              Prérequis

                              Avant de procéder au déploiement, assurez-vous que vous avez installé :

                              • Un cluster Kubernetes opérationnel
                              • Une base de données PostgreSQL avec PostGIS
                              • Un serveur Valkey (utilisé pour le cache)

                              Le serveur de tuiles

                              Le serveur de tuiles est le composant responsable de la génération des tuiles cartographiques vectorielles. Il est recommandé de le séparer du Editoast standard lors de l’exécution d’une configuration de production, car Editoast ne peut pas être mis à l’échelle horizontalement (il est stateful).

                              Vous pouvez visualiser le déploiement recommandé ici :

                              flowchart TD
     gw["gateway"]
     front["fichier statiques front-end"]
@@ -11,4 +11,4 @@
     gw -- HTTP --> tileserver-2
     gw -- HTTP --> tileserver-n...
     editoast -- HTTP --> core

                              Le Helm Chart utilise leHorizontalPodAutoscaler de Kubernetes pour lancer autant de serveurs de tuiles que nécessaire en fonction de la charge de travail.

                              Configuration de la Helm Chart (values)

                              Le Helm Chart est configurable à travers les valeurs suivantes :

                              Service Core

                              • core : Configuration pour le service central OSRD.
                                • internalUrl : URL interne pour la communication entre services.
                                • image : Image Docker à utiliser.
                                • pullPolicy : Politique de récupération de l’image.
                                • replicaCount : Nombre de réplicas.
                                • service : Type de service et configuration des ports.
                                • resources, env, annotations, labels, nodeSelector, tolerations, affinity : Diverses options de déploiement Kubernetes.

                              Service Editoast

                              • editoast : Configuration pour le service Editoast.
                                • Comprend des options similaires à core pour le déploiement Kubernetes.
                                • init : Configuration d’initialisation.

                              Serveur de tuiles

                              • tileServer : Service Editoast spécialisé qui sert uniquement des tuiles cartographiques vectorielles.
                                • enabled : Définir sur true pour activer la fonctionnalité de serveur de tuiles.
                                • image : Image Docker à utiliser (généralement la même que Editoast).
                                • replicaCount : Nombre de réplicas, permettant la mise à l’échelle horizontale.
                                • hpa : Configuration de l’Horizontal Pod Autoscaler.
                                • Autres options standard de déploiement Kubernetes.

                              Gateway

                              • gateway : Configuration pour le gateway OSRD.
                                • Comprend des options de service, d’ingress et d’autres options de déploiement Kubernetes.
                                • config : Configurations spécifiques pour l’authentification et les proxys de confiance.

                              Déploiement

                              Le chart est disponible dans le dépôt OCI ghcr. Vous pouvez trouver 2 versions de la chart :

                              Pour déployer les services OSRD en utilisant Helm :

                              1. Configurer les valeurs : Ajustez les valeurs selon vos besoins de déploiement.

                              2. Installer le Chart : Utilisez la commande helm install pour installer la chart dans votre cluster Kubernetes.

                                helm install osrd oci://ghcr.io/OpenRailAssociation/charts/osrd -f values.yml
-
                              © 2024 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file +
                              \ No newline at end of file diff --git a/fr/docs/guides/deploy/kubernetes/index.html b/fr/docs/guides/deploy/kubernetes/index.html index 486df2d1d..ca0cb2970 100644 --- a/fr/docs/guides/deploy/kubernetes/index.html +++ b/fr/docs/guides/deploy/kubernetes/index.html @@ -1,5 +1,5 @@ Kubernetes avec Helm | OSRD -
                              \ No newline at end of file diff --git a/fr/docs/guides/deploy/stdcm-search-env/index.html b/fr/docs/guides/deploy/stdcm-search-env/index.html index bbad5a2a0..ab17c1e2d 100644 --- a/fr/docs/guides/deploy/stdcm-search-env/index.html +++ b/fr/docs/guides/deploy/stdcm-search-env/index.html @@ -1,5 +1,5 @@ Configuration de l'environnement de recherche STDCM | OSRD -
                              \ No newline at end of file diff --git a/fr/docs/guides/design/index.html b/fr/docs/guides/design/index.html index c284a3363..2ae86e990 100644 --- a/fr/docs/guides/design/index.html +++ b/fr/docs/guides/design/index.html @@ -1,5 +1,5 @@ Le design d'OSRD | OSRD -

                              Le design d'OSRD

                              Les couleurs, la police, les usages…

                              Tout est présenté dans un site dédié https://design.osrd.fr

                              Un « design system » est en cours d’élaboration.

                              © 2025 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file diff --git a/fr/docs/guides/index.html b/fr/docs/guides/index.html index 7932637d6..faa73cb45 100644 --- a/fr/docs/guides/index.html +++ b/fr/docs/guides/index.html @@ -1,5 +1,5 @@ Guides pratiques | OSRD -

                              Guides pratiques

                              Marches à suivre pour des tâches classiques

                              Les guides pratiques sont des marches à suivre. Vous êtes guidés pas-à-pas dans la résolution de problèmes, ou dans des scénarios classiques. Les connaissances requises sont plus élevées que pour les tutoriels, et le fonctionnement d’OSRD doit être compris.

                              Contribuer à OSRD

                              Comment apporter sa pierre à l’édifice

                              Déployer OSRD

                              Apprenez à déployer OSRD dans différents environnements

                              Le design d'OSRD

                              Les couleurs, la police, les usages…

                              Le logo

                              Le logo d’OSRD, ses variantes, et son usage

                              Publication

                              Section sur les releases

                              © 2025 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file diff --git a/fr/docs/guides/index.xml b/fr/docs/guides/index.xml index 91bd1b824..5ebacd7da 100644 --- a/fr/docs/guides/index.xml +++ b/fr/docs/guides/index.xml @@ -103,4 +103,5 @@ Consultez la <a href="https://osrd.fr/fr/docs/guides/deploy/stdcm-search-env/ <p>Ces couleurs sont <strong>celles du logo</strong>, elles ne sont pas à confondre avec celles du design global de l&rsquo;interface d&rsquo;OSRD.</p> </blockquote> <p><span style="display:inline-block;background-color:#786abf;width:128px;height:128px;color:white;font-weight:bold;padding:16px;margin-top:16px">#786ABF</span> -<span style="display:inline-block;background-color:#c7b2de;width:128px;height:128px;color:white;font-weight:bold;padding:16px;margin-top:16px;margin-left:16px">#C7B2DE</span></p> \ No newline at end of file +<span style="display:inline-block;background-color:#c7b2de;width:128px;height:128px;color:white;font-weight:bold;padding:16px;margin-top:16px;margin-left:16px">#C7B2DE</span></p>Docs: Publicationhttps://osrd.fr/fr/docs/guides/release/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/release/ +<p>Cette section documente le processus de création d&rsquo;une publication d&rsquo;OSRD.</p> \ No newline at end of file diff --git a/fr/docs/guides/logo/index.html b/fr/docs/guides/logo/index.html index 25c450b5e..a019dfb17 100644 --- a/fr/docs/guides/logo/index.html +++ b/fr/docs/guides/logo/index.html @@ -1,5 +1,5 @@ Le logo | OSRD -
                              \ No newline at end of file diff --git a/fr/docs/guides/release/_print/index.html b/fr/docs/guides/release/_print/index.html new file mode 100644 index 000000000..d90d18e1a --- /dev/null +++ b/fr/docs/guides/release/_print/index.html @@ -0,0 +1,37 @@ +Publication | OSRD +

                              Version imprimable multipages. +Cliquer ici pour imprimer.

                              Retour à la version par défaut.

                              Publication

                              Section sur les releases

                              Cette section documente le processus de création d’une publication d’OSRD.

                              1 - Processus de publication

                              Voici comment OSRD est actuellement publié

                              OSRD possède trois versions : développement (dev), staging et publication.

                              La version de développement est la version la plus récente et la plus instable de l’application, contenant les dernières fonctionnalités et corrections de bugs en cours de développement.

                              Les versions staging sont créées tous les jeudis à 12h en taguant l’état actuel du développement.

                              Si une version staging passe les tests de validation, elle est promue pour devenir la dernière version publication. Cela garantit que seul du code stable et testé est intégré dans les versions de production.

                              Le processus de publication suit ce workflow :

                              1. Développement continu dans la branche dev
                              2. Tags de staging hebdomadaires les jeudis à 12h
                              3. Tests de validation de la version staging
                              4. Promotion des builds staging validés au statut de publication
                                  Développement      Staging                publication
+    (instable)         (test)                   (stable)
+
+    [Branche Dev]                                  |
+         |                                         |
+         |--->     Jeudi 12h                       |
+         |         [Tag Staging]                   |
+         |                |                        |
+         |            Validation                   |
+         |              Tests                      |
+         |                |                        |
+         |                o---> Si Passage -->  Nouvelle
+         |                        Tests        publication
+    [Suite Dev]                                    |
+         |                                         |
+         V                                         V
+

                              2 - Publier une nouvelle version

                              Comment publier une nouvelle version

                              Toutes les versions d’OSRD sont accessibles ici

                              Le processus de création d’une nouvelle version est le suivant :

                              1. Nous publions toujours sur une version testée de l’application (branche staging)
                                • git switch staging && git pull
                              2. Créer un tag git annoté
                                • Nous utilisons le versionnement sémantique
                                • git tag -a vx.y.z avec le message Release x.y.z (la plupart du temps, utilisez la dernière version et incrémentez la version patch)
                                • git push --tags
                              3. Créer une release GitHub
                                • Créer une nouvelle release GitHub ici
                                • Sélectionner le tag créé
                                • Générer les notes de version
                                • Renommer la release ainsi : “Version x.y.z”
                                • Cocher la case “Set as a pre-release”
                                • Appliquer le format du changelog
                                • Vous pouvez ensuite publier la release ou sauvegarder le brouillon si vous souhaitez y revenir plus tard
                              4. Une action GitHub devrait être déclenchée automatiquement.
                              5. Poster le lien de la release créée sur Matrix. Suggérer aux développeurs de revoir la release.

                              Format du changelog

                              1. Utiliser la structure suivante :
                              ## What's Changed
+
+### Features :tada:
+
+
+### Code refactoring :recycle:
+
+
+### Bug fixes :bug:
+
+
+## New Contributors
+
+<!-- Copy from the generated release notes -->
+...
+
+<!-- Copy from the generated release notes -->
+**Full Changelog**: ...
+
                              1. Répartir les différentes pull requests
                              2. Fusionner ou regrouper les PR quand cela a du sens. Exemples :
                                • PR de mise à jour des dépendances (fusionner)
                                • PR en plusieurs parties (fusionner)
                                • Une grande fonctionnalité implémentée par plusieurs PR (regrouper)
                              3. Reformuler les titres des PR. Ils doivent être compréhensibles pour un collaborateur externe
                              © 2025 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file diff --git a/fr/docs/guides/release/index.html b/fr/docs/guides/release/index.html new file mode 100644 index 000000000..d69058d33 --- /dev/null +++ b/fr/docs/guides/release/index.html @@ -0,0 +1,95 @@ +Publication | OSRD +

                              Publication

                              Section sur les releases

                              Cette section documente le processus de création d’une publication d’OSRD.

                              Processus de publication

                              Voici comment OSRD est actuellement publié

                              Publier une nouvelle version

                              Comment publier une nouvelle version

                              © 2025 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file diff --git a/fr/docs/guides/release/index.xml b/fr/docs/guides/release/index.xml new file mode 100644 index 000000000..5eda24f98 --- /dev/null +++ b/fr/docs/guides/release/index.xml @@ -0,0 +1,90 @@ +OSRD – Publicationhttps://osrd.fr/fr/docs/guides/release/Recent content in Publication on OSRDHugo -- gohugo.iofrDocs: Processus de publicationhttps://osrd.fr/fr/docs/guides/release/process/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/release/process/ +<p>OSRD possède trois versions : développement (dev), staging et publication.</p> +<p>La version de développement est la version la plus récente et la plus instable de l&rsquo;application, contenant les dernières fonctionnalités et corrections de bugs en cours de développement.</p> +<p>Les versions staging sont créées tous les jeudis à 12h en taguant l&rsquo;état actuel du développement.</p> +<p>Si une version staging passe les tests de validation, elle est promue pour devenir la dernière version publication. Cela garantit que seul du code stable et testé est intégré dans les versions de production.</p> +<p>Le processus de publication suit ce workflow :</p> +<ol> +<li>Développement continu dans la branche dev</li> +<li>Tags de staging hebdomadaires les jeudis à 12h</li> +<li>Tests de validation de la version staging</li> +<li>Promotion des builds staging validés au statut de publication</li> +</ol> +<pre tabindex="0"><code class="language-ascii" data-lang="ascii"> Développement Staging publication +(instable) (test) (stable) +[Branche Dev] | +| | +|---&gt; Jeudi 12h | +| [Tag Staging] | +| | | +| Validation | +| Tests | +| | | +| o---&gt; Si Passage --&gt; Nouvelle +| Tests publication +[Suite Dev] | +| | +V V +</code></pre>Docs: Publier une nouvelle versionhttps://osrd.fr/fr/docs/guides/release/publish/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/release/publish/ +<p>Toutes les versions d&rsquo;OSRD sont accessibles <a href="https://github.com/OpenRailAssociation/osrd/releases">ici</a></p> +<p>Le processus de création d&rsquo;une nouvelle version est le suivant :</p> +<ol> +<li>Nous publions toujours sur une version testée de l&rsquo;application (branche staging) +<ul> +<li><code>git switch staging &amp;&amp; git pull</code></li> +</ul> +</li> +<li>Créer un tag git <strong>annoté</strong> +<ul> +<li>Nous utilisons le <a href="https://semver.org/">versionnement sémantique</a></li> +<li><code>git tag -a vx.y.z</code> avec le message <code>Release x.y.z</code> (la plupart du temps, utilisez la dernière version et incrémentez la version patch)</li> +<li><code>git push --tags</code></li> +</ul> +</li> +<li>Créer une release GitHub +<ul> +<li>Créer une nouvelle release GitHub <a href="https://github.com/OpenRailAssociation/osrd/releases/new">ici</a></li> +<li>Sélectionner le tag créé</li> +<li>Générer les notes de version</li> +<li>Renommer la release ainsi : &ldquo;Version x.y.z&rdquo;</li> +<li>Cocher la case &ldquo;Set as a pre-release&rdquo;</li> +<li>Appliquer le <a href="#Format du changelog">format du changelog</a></li> +<li>Vous pouvez ensuite <strong>publier</strong> la release ou <strong>sauvegarder</strong> le brouillon si vous souhaitez y revenir plus tard</li> +</ul> +</li> +<li>Une <a href="https://github.com/OpenRailAssociation/osrd/actions/workflows/release.yml">action GitHub</a> devrait être déclenchée automatiquement.</li> +<li>Poster le lien de la release créée sur Matrix. Suggérer aux développeurs de revoir la release.</li> +</ol> +<h3 id="format-du-changelog">Format du changelog</h3> +<ol> +<li>Utiliser la structure suivante :</li> +</ol> +<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-md" data-lang="md"><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## What&#39;s Changed +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Features :tada: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Code refactoring :recycle: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Bug fixes :bug: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## New Contributors +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> +</span></span><span style="display:flex;"><span>... +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> +</span></span><span style="display:flex;"><span><span style="color:#000;font-weight:bold">**Full Changelog**</span>: ... +</span></span></code></pre></div><ol start="2"> +<li>Répartir les différentes pull requests</li> +<li>Fusionner ou regrouper les PR quand cela a du sens. Exemples : +<ul> +<li>PR de mise à jour des dépendances (fusionner)</li> +<li>PR en plusieurs parties (fusionner)</li> +<li>Une grande fonctionnalité implémentée par plusieurs PR (regrouper)</li> +</ul> +</li> +<li>Reformuler les titres des PR. <strong>Ils doivent être compréhensibles pour un collaborateur externe</strong></li> +</ol> \ No newline at end of file diff --git a/fr/docs/guides/release/process/index.html b/fr/docs/guides/release/process/index.html new file mode 100644 index 000000000..8af9fdb7e --- /dev/null +++ b/fr/docs/guides/release/process/index.html @@ -0,0 +1,111 @@ +Processus de publication | OSRD +

                              Processus de publication

                              Voici comment OSRD est actuellement publié

                              OSRD possède trois versions : développement (dev), staging et publication.

                              La version de développement est la version la plus récente et la plus instable de l’application, contenant les dernières fonctionnalités et corrections de bugs en cours de développement.

                              Les versions staging sont créées tous les jeudis à 12h en taguant l’état actuel du développement.

                              Si une version staging passe les tests de validation, elle est promue pour devenir la dernière version publication. Cela garantit que seul du code stable et testé est intégré dans les versions de production.

                              Le processus de publication suit ce workflow :

                              1. Développement continu dans la branche dev
                              2. Tags de staging hebdomadaires les jeudis à 12h
                              3. Tests de validation de la version staging
                              4. Promotion des builds staging validés au statut de publication
                                  Développement      Staging                publication
+    (instable)         (test)                   (stable)
+
+    [Branche Dev]                                  |
+         |                                         |
+         |--->     Jeudi 12h                       |
+         |         [Tag Staging]                   |
+         |                |                        |
+         |            Validation                   |
+         |              Tests                      |
+         |                |                        |
+         |                o---> Si Passage -->  Nouvelle
+         |                        Tests        publication
+    [Suite Dev]                                    |
+         |                                         |
+         V                                         V
+
                              © 2025 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file diff --git a/fr/docs/guides/release/publish/index.html b/fr/docs/guides/release/publish/index.html new file mode 100644 index 000000000..b5c292916 --- /dev/null +++ b/fr/docs/guides/release/publish/index.html @@ -0,0 +1,113 @@ +Publier une nouvelle version | OSRD +

                              Publier une nouvelle version

                              Comment publier une nouvelle version

                              Toutes les versions d’OSRD sont accessibles ici

                              Le processus de création d’une nouvelle version est le suivant :

                              1. Nous publions toujours sur une version testée de l’application (branche staging)
                                • git switch staging && git pull
                              2. Créer un tag git annoté
                                • Nous utilisons le versionnement sémantique
                                • git tag -a vx.y.z avec le message Release x.y.z (la plupart du temps, utilisez la dernière version et incrémentez la version patch)
                                • git push --tags
                              3. Créer une release GitHub
                                • Créer une nouvelle release GitHub ici
                                • Sélectionner le tag créé
                                • Générer les notes de version
                                • Renommer la release ainsi : “Version x.y.z”
                                • Cocher la case “Set as a pre-release”
                                • Appliquer le format du changelog
                                • Vous pouvez ensuite publier la release ou sauvegarder le brouillon si vous souhaitez y revenir plus tard
                              4. Une action GitHub devrait être déclenchée automatiquement.
                              5. Poster le lien de la release créée sur Matrix. Suggérer aux développeurs de revoir la release.

                              Format du changelog

                              1. Utiliser la structure suivante :
                              ## What's Changed
+
+### Features :tada:
+
+
+### Code refactoring :recycle:
+
+
+### Bug fixes :bug:
+
+
+## New Contributors
+
+<!-- Copy from the generated release notes -->
+...
+
+<!-- Copy from the generated release notes -->
+**Full Changelog**: ...
+
                              1. Répartir les différentes pull requests
                              2. Fusionner ou regrouper les PR quand cela a du sens. Exemples :
                                • PR de mise à jour des dépendances (fusionner)
                                • PR en plusieurs parties (fusionner)
                                • Une grande fonctionnalité implémentée par plusieurs PR (regrouper)
                              3. Reformuler les titres des PR. Ils doivent être compréhensibles pour un collaborateur externe
                              © 2025 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file diff --git a/fr/docs/index.html b/fr/docs/index.html index a4e0eddb2..e7e839f65 100644 --- a/fr/docs/index.html +++ b/fr/docs/index.html @@ -1,5 +1,5 @@ Documentation | OSRD -

                              Documentation

                              Vous souhaitez utiliser OSRD, y contribuer, ou simplement en comprendre le fonctionnement ? Cette documentation est pour vous !

                              Explications

                              Comprendre les concepts clés

                              Guides pratiques

                              Marches à suivre pour des tâches classiques

                              Référence technique

                              Machinerie interne et APIs

                              Wiki Ferroviaire

                              Wiki ferroviaire international

                              © 2025 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file diff --git a/fr/docs/index.xml b/fr/docs/index.xml index a8dc26779..6ce910ebe 100644 --- a/fr/docs/index.xml +++ b/fr/docs/index.xml @@ -35,7 +35,34 @@ dans chaque composant, donc regrouper les montées de version dans une même PR <p><em><a href="https://osrd.fr/fr/docs/guides/contribute/contribute-code/backend-conventions/">Consulter les conventions pour le back-end ‣</a></em></p> <p><em><a href="https://osrd.fr/fr/docs/guides/contribute/contribute-code/frontend-conventions/">Consulter les conventions pour le front-end ‣</a></em></p> <p><em><a href="https://osrd.fr/fr/docs/guides/contribute/contribute-code/write-code/">Continuer vers l&rsquo;écriture de code ‣</a></em></p> -<p><em><a href="https://osrd.fr/fr/docs/guides/contribute/contribute-code/tests/">Continuer vers l&rsquo;écriture de tests ‣</a></em></p>Docs: Conventions back-endhttps://osrd.fr/fr/docs/guides/contribute/contribute-code/backend-conventions/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/contribute/contribute-code/backend-conventions/ +<p><em><a href="https://osrd.fr/fr/docs/guides/contribute/contribute-code/tests/">Continuer vers l&rsquo;écriture de tests ‣</a></em></p>Docs: Processus de publicationhttps://osrd.fr/fr/docs/guides/release/process/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/release/process/ +<p>OSRD possède trois versions : développement (dev), staging et publication.</p> +<p>La version de développement est la version la plus récente et la plus instable de l&rsquo;application, contenant les dernières fonctionnalités et corrections de bugs en cours de développement.</p> +<p>Les versions staging sont créées tous les jeudis à 12h en taguant l&rsquo;état actuel du développement.</p> +<p>Si une version staging passe les tests de validation, elle est promue pour devenir la dernière version publication. Cela garantit que seul du code stable et testé est intégré dans les versions de production.</p> +<p>Le processus de publication suit ce workflow :</p> +<ol> +<li>Développement continu dans la branche dev</li> +<li>Tags de staging hebdomadaires les jeudis à 12h</li> +<li>Tests de validation de la version staging</li> +<li>Promotion des builds staging validés au statut de publication</li> +</ol> +<pre tabindex="0"><code class="language-ascii" data-lang="ascii"> Développement Staging publication +(instable) (test) (stable) +[Branche Dev] | +| | +|---&gt; Jeudi 12h | +| [Tag Staging] | +| | | +| Validation | +| Tests | +| | | +| o---&gt; Si Passage --&gt; Nouvelle +| Tests publication +[Suite Dev] | +| | +V V +</code></pre>Docs: Conventions back-endhttps://osrd.fr/fr/docs/guides/contribute/contribute-code/backend-conventions/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/contribute/contribute-code/backend-conventions/ <h1 id="python">Python</h1> <p>Le code Python est utilisé pour certains paquets et pour les tests d&rsquo;intégration.</p> <ul> @@ -346,7 +373,69 @@ La plupart des développeurs OSRD utilisent Linux (y compris <a href="https:/ <p>Sous Windows, ouvrez <code>Git Bash</code>&#160;<a href="#fnref:2" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p> </li> </ol> -</div>Docs: Écrire du codehttps://osrd.fr/fr/docs/guides/contribute/contribute-code/write-code/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/contribute/contribute-code/write-code/ +</div>Docs: Publier une nouvelle versionhttps://osrd.fr/fr/docs/guides/release/publish/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/release/publish/ +<p>Toutes les versions d&rsquo;OSRD sont accessibles <a href="https://github.com/OpenRailAssociation/osrd/releases">ici</a></p> +<p>Le processus de création d&rsquo;une nouvelle version est le suivant :</p> +<ol> +<li>Nous publions toujours sur une version testée de l&rsquo;application (branche staging) +<ul> +<li><code>git switch staging &amp;&amp; git pull</code></li> +</ul> +</li> +<li>Créer un tag git <strong>annoté</strong> +<ul> +<li>Nous utilisons le <a href="https://semver.org/">versionnement sémantique</a></li> +<li><code>git tag -a vx.y.z</code> avec le message <code>Release x.y.z</code> (la plupart du temps, utilisez la dernière version et incrémentez la version patch)</li> +<li><code>git push --tags</code></li> +</ul> +</li> +<li>Créer une release GitHub +<ul> +<li>Créer une nouvelle release GitHub <a href="https://github.com/OpenRailAssociation/osrd/releases/new">ici</a></li> +<li>Sélectionner le tag créé</li> +<li>Générer les notes de version</li> +<li>Renommer la release ainsi : &ldquo;Version x.y.z&rdquo;</li> +<li>Cocher la case &ldquo;Set as a pre-release&rdquo;</li> +<li>Appliquer le <a href="#Format du changelog">format du changelog</a></li> +<li>Vous pouvez ensuite <strong>publier</strong> la release ou <strong>sauvegarder</strong> le brouillon si vous souhaitez y revenir plus tard</li> +</ul> +</li> +<li>Une <a href="https://github.com/OpenRailAssociation/osrd/actions/workflows/release.yml">action GitHub</a> devrait être déclenchée automatiquement.</li> +<li>Poster le lien de la release créée sur Matrix. Suggérer aux développeurs de revoir la release.</li> +</ol> +<h3 id="format-du-changelog">Format du changelog</h3> +<ol> +<li>Utiliser la structure suivante :</li> +</ol> +<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-md" data-lang="md"><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## What&#39;s Changed +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Features :tada: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Code refactoring :recycle: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">### Bug fixes :bug: +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold">## New Contributors +</span></span></span><span style="display:flex;"><span><span style="color:#800080;font-weight:bold"></span> +</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> +</span></span><span style="display:flex;"><span>... +</span></span><span style="display:flex;"><span> +</span></span><span style="display:flex;"><span><span style="color:#8f5902;font-style:italic">&lt;!-- Copy from the generated release notes --&gt;</span> +</span></span><span style="display:flex;"><span><span style="color:#000;font-weight:bold">**Full Changelog**</span>: ... +</span></span></code></pre></div><ol start="2"> +<li>Répartir les différentes pull requests</li> +<li>Fusionner ou regrouper les PR quand cela a du sens. Exemples : +<ul> +<li>PR de mise à jour des dépendances (fusionner)</li> +<li>PR en plusieurs parties (fusionner)</li> +<li>Une grande fonctionnalité implémentée par plusieurs PR (regrouper)</li> +</ul> +</li> +<li>Reformuler les titres des PR. <strong>Ils doivent être compréhensibles pour un collaborateur externe</strong></li> +</ol>Docs: Écrire du codehttps://osrd.fr/fr/docs/guides/contribute/contribute-code/write-code/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/guides/contribute/contribute-code/write-code/ <ol> <li> <p>Si vous n&rsquo;être pas un habitué de Git, <a href="https://learngitbranching.js.org/">suivez ce tutoriel</a></p> @@ -2462,58 +2551,4 @@ carré protégeant l’aiguille de sortie.</p> <ul> <li>que le train est parvenu à <strong>la fin du parcours à contresens</strong> ;</li> <li>qu’à partir de ce tableau, <strong>les signaux qui le concernent sont implantés à gauche</strong>.</li> -</ul>Docs: GPRShttps://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/Docs: La voie unique temporaire (VUT)https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/ -<h3 id="principe">Principe</h3> -<p>Lorsqu’une cause quelconque (incident, exécution de travaux, etc.), interdit l’utilisation d’une voie et en l’absence -d’installations permettant la circulation dans les deux sens en sécurité sur l’autre voie (ICS, voie banalisée), la -circulation des trains est organisée par les agents du service de gestion des circulations situés aux extrémités selon -des procédures adaptées.</p> -<p>La VUT est donc un régime temporaire d’exploitation permettant, sur une ligne à double voie non équipée d’installation -de contresens, de faire circuler les trains des deux sens sur une seule et même voie.</p> -<p>Les trains devant circuler à contre sens sont <strong>arrêtés à l’entrée</strong>.</p> -<p>La circulation sur la VUT dans les deux sens se fait selon le principe de la demande et de l’accord de voie entre agents -du service de la gestion des circulations.</p> -<p>La vitesse limite à contre sens est de 70 km/h.</p> -<p>La sortie de la VUT est repérée soit :</p> -<ul> -<li>par un <strong>signal carré</strong> implanté à gauche, à droite ou au-dessus de la voie ;</li> -<li>par un <strong>signal d’arrêt à main</strong>.</li> -</ul> -<h3 id="organisation">Organisation</h3> -<p>La VUT est établie entre les deux changements de voies utilisables les plus rapprochés qui en constituent les extrémités.</p> -<p>La VUT est organisée par l’agent du service de la gestion des circulations qui expédie les trains à contresens sur cette -voie (gare B dans l’exemple ci-dessous) et qui doit aviser ou faire aviser les agents intéressés : agents des postes, -des PN gardés, agents travaillant sur la voie ou les caténaires.</p> -<h3 id="circulation-sur-la-vut">Circulation sur la VUT</h3> -<p><img src="https://osrd.fr/images/docs/railway-wiki/signalling/image-077.png" alt=""></p> -<h4 id="le-risque-de-nez-à-nez">Le risque de nez à nez</h4> -<p>L’expédition de tout train sur la VUT est subordonnée à un accord de voie donné par l’agent du service de gestion des -circulations de l’autre extrémité de la VUT à l’agent-du service de gestion des circulations qui doit expédier le train.</p> -<h4 id="le-risque-de-rattrapage">Le risque de rattrapage</h4> -<p>Les trains de sens normal sont cantonnés dans les conditions habituelles.</p> -<p>Les trains circulant à contresens sont cantonnés téléphoniquement dans les conditions prévues pour la voie unique (voir 4.3.).</p> -<h3 id="avis-au-conducteur">Avis au conducteur</h3> -<p><strong>En sens normal :</strong> aucun avis n’est fait au conducteur, les trains circulent sans arrêt à l’entrée.</p> -<p><strong>À contre sens :</strong> le conducteur est arrêté à l’entrée de la VUT puis informé par écrit par l’agent du service de la -gestion des circulations qu’il va circuler à contresens en VUT.</p> -<p>Cet ordre écrit reprend les points ou zones du parcours sur lesquels le conducteur doit appliquer des prescriptions -particulières.</p> -<p>En effet, les installations et la signalisation ne sont généralement pas prévues pour les circulations en sens inverse -du sens normal (PN, limitations de vitesse, etc.).</p>Docs: La voie unique à trafic restreint (VUTR)https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/ -<h3 id="définition">Définition</h3> -<p>Ce régime concerne des lignes fermées au service voyageurs qui ne comportent normalement pas de signaux. Les règles -concernant le régime général d’exploitation de la voie unique ne sont pas applicables et sont remplacées par des -modalités particulières définies par le gestionnaire d&rsquo;infrastructure.</p> -<h3 id="principe">Principe</h3> -<p>Une consigne locale d’exploitation adaptée à chaque VUTR précise les caractéristiques d&rsquo;exploitation comme la vitesse de -la ligne, la signalisation, les établissements, les liaisons téléphoniques, les PN, etc.</p> -<p>Elle est complétée par un programme de circulation qui comporte les horaires des trains devant circuler et précise les -dispositions particulières concernant chaque train (trains entre lesquels l&rsquo;espacement doit être assuré, croisements, -etc.).</p> -<p>Ces lignes ne comportent normalement pas de signaux, les limitations de vitesse à observer sur les aiguilles ainsi que -les autres limitations permanentes de vitesse sont inscrites à la consigne locale d’exploitation de la ligne ; elles ne -sont pas rappelées par des signaux sur le terrain.</p> -<p>Par principe, la vitesse de circulation ne dépasse généralement pas 50 km/h.</p> -<p>Aucun enclenchement n’est prévu. Chaque ligne dépend d&rsquo;un agent de SNCF Réseau dénommé « chef de ligne ». La sécurité -des circulations est assurée par le chef de ligne et par les agents des trains.</p> -<p><em>Nota : Les VUTR ne sont pas définies dans les RT.</em></p> \ No newline at end of file +</ul>Docs: GPRShttps://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/Mon, 01 Jan 0001 00:00:00 +0000https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/ \ No newline at end of file diff --git a/fr/docs/railway-wiki/_print/index.html b/fr/docs/railway-wiki/_print/index.html index 7ba411c35..235c5eba7 100644 --- a/fr/docs/railway-wiki/_print/index.html +++ b/fr/docs/railway-wiki/_print/index.html @@ -1,5 +1,5 @@ Wiki Ferroviaire | OSRD -

                              Version imprimable multipages. +

                              Version imprimable multipages. Cliquer ici pour imprimer.

                              Retour à la version par défaut.

                              Wiki Ferroviaire

                              Wiki ferroviaire international

                              Ce wiki a pour objectif de rendre accessible aux développeurs des informations sur le monde ferroviaire.

                              Cela ne peut se produire que si le contenu est ajouté lorsque nécessaire. Si quelque chose manque, contribuez !

                              1 - Glossaire

                              Glossaire thématique d’OSRD et du ferroviaire

                              À compléter : ouvrez une issue en cas de mot manquant

                              A

                              • ADV : Appareil de voie

                              B

                              • BA : Block automatique
                              • BAL : Block automatique lumineux
                              • BAPR : Block automatique à permissivité restreinte
                              • BM : Block manuel
                              • BMCV : BM par circuit de voie
                              • BMVU : BM de voie unique

                              C

                              • CAPI : Cantonnement assisté par informatique
                              • CC : Commande et contrôle
                              • COVIT : Contrôle de vitesse
                              • CT : Cantonnement téléphonique

                              D

                              • DAAT : Dispositif d’arrêt automatique des trains
                              • DMI : Driver machine interface : dispositif qui permet la communication entre le système bord et le conducteur
                              • DV : Double voie

                              E

                              • EOA : End of authority (fin d’autorisation de mouvement)
                              • EPSF : Établissement public de sécurité ferroviaire
                              • ETCS : European train control system (système européen de contrôle commande des trains)
                              • ERTMS : European rail traffic management system (système européen de gestion du trafic ferroviaire)
                              • EVC : European vital computer. (ordinateur européen de sécurité) : calculateur de bord qui supervise la marche du train en fonction des données sol et bord

                              F

                              • FA : Fermeture automatique
                              • FS : Full supervision (supervision complète) : mode technique dans lequel le train est supervisé en vitesse et déplacement = marche normale attribuée au train

                              G

                              • GI : Gestionnaire d’infrastructure
                              • GSM/GFU : Global system for mobile communication/Groupe fermé d’utilisateurs
                              • GSM-R : Global system for mobile communication railways (Système de communication téléphonique pour mobile dédié aux chemins de fer)
                              • GSM-R Data : Système de transmission de données entre les installations « sol » et les installations « bord » via le réseau GSM-R

                              I

                              • ICS : Installations de circulation à contre-sens
                              • IPCS : Installations permanentes de contre-sens
                              • IS : Installation de sécurité
                              • ITCS : Installations temporaires de contre-sens

                              J

                              • JRU : Juridical recording unit (Enregistreur des paramètres d’exploitation)

                              K

                              • KVB : Contrôle de vitesse par balises

                              L

                              • LEU : Line side electronic unit (codeur ERTMS)
                              • LGV : Ligne à grande vitesse
                              • LTV : Limitation temporaire de vitesse

                              M

                              • MA : Movement authority : autorisation donnée à un train de circuler vers un point donné en tant que mouvement supervisé

                              N

                              • Nf : Non franchissable
                              • NL : Non leading (non en tête) : Mode technique de circulation utilisé pour la double traction ou la pousse

                              O

                              • OS : On sight (conduite à vue) : mode technique de circulation qui autorise le conducteur à s’avancer en marche à vue. En ETCS1, le mode OS accompagné du message textuel national « Voie de service » impose la marche en manoeuvre pour la réception sur voie de service

                              P

                              • PI ETCS : Point d’information ETCS : constitué d’une ou plusieurs balises transmettant des informations vers le bord (par exemple PI avancé ou PI signal)
                              • PK : Point Kilométrique : position géographique basée sur un RK (Repère Kilométrique)
                              • PL : Pleine ligne
                              • PLD : Point limite de domaine : point où une transition entre ETCS et un autre système de signalisation a lieu
                              • PN : Passage à niveau
                              • PO : Point opérationnel : collection de points représentant un lieu d’intérêt, voir exemple.
                              • PR : Point remarquable : voir PO

                              R

                              • RBC : Radio block center : système centralisé fonctionnant avec les enclenchements afin d’établir et de contrôler l’espacement et le mouvement des trains en envoyant et recevant des informations par radio en ETCS2 ou 3
                              • RFN : Réseau Ferré National
                              • RK : Repère Kilométrique : bornes (physiques) placées sur une voie à distance régulière (environ un kilomètre les unes des autres mais pouvant varier) servant à se repérer sur une voie
                              • RST : Radio sol-train
                              • RT : Renseignement technique
                              • RV : Reversing (refoulement) : mode technique de circulation utilisé pour permettre au train de reculer d’urgence sans signaux ni ordre dans une zone prédéfinie. Ce mode n’est pas utilisé sur le RFN

                              S

                              • SEL : Section d’électrification. La plus petite portion d’un caténaire pouvant être coupée pour travaux
                              • SGS : Système de gestion de la sécurité
                              • SH : Shunting (manoeuvre) : mode technique de circulation manoeuvre
                              • SN : System national : mode technique de circulation de niveau STM
                              • SR : Staff responsible (responsabilité agent) : mode technique de circulation utilisé dans les situations dégradées. Il est utilisable sous la responsabilité respective de l’agent-circulation et du conducteur
                              • SR : Système de repérage
                              • SRV : Système de repérage voie : métadonnées et anomalies (données correctives) permettant de faire des calculs de distance entre deux PKs sur une voie
                              • STM : Specific transmission module (Module spécifique de transmission) : ce dispositif permet à l’ETCS d’utiliser un système de signalisation national

                              T

                              • TECS : Tableau lumineux d’entrée à contre sens
                              • TIV : Tableau indicateur de vitesse
                              • TIV : Tronçon d’itinéraire de voie (Track Section en anglais).
                              • TR : Trip : mode technique de circulation entraînant une application irréversible du freinage d’urgence par le système ETCS jusqu’à l’arrêt du train
                              • TSCS : Tableau lumineux de sortie à contre sens
                              • TVM : Transmission voie machine

                              V

                              • VB : Voie banalisée
                              • VP : Voie principale
                              • VS : Voie de service
                              • VU : Voie unique
                              • VUT : Voie unique temporaire
                              • VUTP : Voie unique temporaire à caractère permanent

                              Z

                              • ZEP : Zone élémentaire de protection : la plus petite portion de voie pouvant être fermée pour des travaux

                              2 - Signalisation

                              Les signaux, régimes d’exploitation des trains, et les systèmes d’espacement des trains

                              Cette section est destinée à exposer les principes généraux relatifs :

                              • aux signaux
                              • aux régimes d’exploitation des lignes (à venir)
                              • aux différents systèmes d’espacement des trains

                              La grande majorité des informations de cette section sont extraites du document pédagogique de l’Établissement Public de Sécurité Ferroviaire (EPSF) édité le 05 juillet 2017.

                              2.1 - Les risques ferroviaires

                              Les trains doivent circuler en toute sécurité. Les risques majeurs liés aux circulations ferroviaires sont les suivants :

                              • le rattrapage des trains qui circulent dans le même sens sur la même voie ;
                              • la prise en écharpe, c’est-à-dire la collision latérale de trains qui circulent sur des itinéraires convergents ;
                              • le nez à nez, c’est-à-dire la collision frontale de trains qui circulent en sens contraire sur la même voie ;
                              • le déraillement ;
                              • la collision avec un obstacle.

                              On prévient ces risques notamment par :

                              • la mise en place d’une signalisation ;
                              • l’établissement d’un régime d’exploitation de la ligne (double voie, voie banalisée, voie unique) ;
                              • la mise en place d’un système d’espacement des trains ;
                              • la mise en oeuvre de procédures d’exploitation.

                              D’autres dispositifs techniques contribuent également à couvrir ces risques tels que :

                              • les installations de sécurité, notamment les enclenchements des postes d’aiguillage ;
                              • le DAAT qui est un dispositif permettant d’assurer l’arrêt automatique des trains en cas de franchissement intempestif d’un point d’information avec signal d’arrêt fermé ;
                              • le KVB, le COVIT (TVM) sont des exemples de systèmes de contrôle de la vitesse, avec contrôle de franchissement des signaux non franchissables ;
                              • le système de contrôle commande des trains, intégré dans l’ETCS.

                              La sécurité des circulations repose aussi sur le respect rigoureux des consignes et instructions opérationnelles par tous les agents concernés par la circulation des trains.

                              Ces procédures sont de la responsabilité des exploitants ferroviaires. Elles sont décrites dans le manuel du système de gestion de la sécurité (SGS) qu’ils établissent et qui fait l’objet d’une instruction par l’EPSF chargé de délivrer le certificat ou l’agrément de sécurité.

                              2.2 - Les signaux

                              Principe

                              Pour transmettre au conducteur des ordres et informations liées à la sécurité des circulations, il est fait usage de signaux. Ces signaux peuvent indiquer des informations relatives aux limites de vitesse, peuvent servir à garantir @@ -191,4 +191,4 @@ que la vitesse du train.

                            • Mode NL : Conduite d’un engin moteur non en tête du mouvement

                              Ce mode technique est utilisé en cas de pousse ou de double traction.

                              • Protection contre le rattrapage

                              En mode FS, une vitesse autorisée affichée sans la présentation de l’EOA signifie « marche normale ».

                              La MA constituée d’un ou plusieurs cantons est allouée canton par canton, par ajout successif d’un canton. Si le canton en aval du dernier canton alloué est occupé le train doit être en mesure de s’arrêter avant l’entrée de ce canton. Le conducteur est alors avisé par une indication sonore au DMI.

                              Dès lors, les indications de conduite (vitesse but égale à 0 et une distance but) permettant de respecter la courbe de -freinage sont affichées.

                              Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                              2.4.2.2 - GSM-R

                              Global System for Mobiles - Railways

                              2.4.2.3 - GPRS

                              General Packet Radio Service

                              2.4.2.4 - FRMCS

                              Futur Système de Communications Mobiles Ferroviaires

                              2.4.2.5 - ETML

                              European Train Management Layer
                              © 2024 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file +freinage sont affichées.

                              Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                              2.4.2.2 - GSM-R

                              Global System for Mobiles - Railways

                              2.4.2.3 - GPRS

                              General Packet Radio Service

                              2.4.2.4 - FRMCS

                              Futur Système de Communications Mobiles Ferroviaires

                              2.4.2.5 - ETML

                              European Train Management Layer
                              © 2025 Contributeurs à OSRD. Tous droits réservés
                              \ No newline at end of file diff --git a/fr/docs/railway-wiki/glossary/_print/index.html b/fr/docs/railway-wiki/glossary/_print/index.html index 5159f03d7..2bcd0fac9 100644 --- a/fr/docs/railway-wiki/glossary/_print/index.html +++ b/fr/docs/railway-wiki/glossary/_print/index.html @@ -1,3 +1,3 @@ Glossaire | OSRD -

                              Version imprimable multipages. -Cliquer ici pour imprimer.

                              Retour à la version par défaut.

                              Glossaire

                              Glossaire thématique d’OSRD et du ferroviaire

                                À compléter : ouvrez une issue en cas de mot manquant

                                A

                                • ADV : Appareil de voie

                                B

                                • BA : Block automatique
                                • BAL : Block automatique lumineux
                                • BAPR : Block automatique à permissivité restreinte
                                • BM : Block manuel
                                • BMCV : BM par circuit de voie
                                • BMVU : BM de voie unique

                                C

                                • CAPI : Cantonnement assisté par informatique
                                • CC : Commande et contrôle
                                • COVIT : Contrôle de vitesse
                                • CT : Cantonnement téléphonique

                                D

                                • DAAT : Dispositif d’arrêt automatique des trains
                                • DMI : Driver machine interface : dispositif qui permet la communication entre le système bord et le conducteur
                                • DV : Double voie

                                E

                                • EOA : End of authority (fin d’autorisation de mouvement)
                                • EPSF : Établissement public de sécurité ferroviaire
                                • ETCS : European train control system (système européen de contrôle commande des trains)
                                • ERTMS : European rail traffic management system (système européen de gestion du trafic ferroviaire)
                                • EVC : European vital computer. (ordinateur européen de sécurité) : calculateur de bord qui supervise la marche du train en fonction des données sol et bord

                                F

                                • FA : Fermeture automatique
                                • FS : Full supervision (supervision complète) : mode technique dans lequel le train est supervisé en vitesse et déplacement = marche normale attribuée au train

                                G

                                • GI : Gestionnaire d’infrastructure
                                • GSM/GFU : Global system for mobile communication/Groupe fermé d’utilisateurs
                                • GSM-R : Global system for mobile communication railways (Système de communication téléphonique pour mobile dédié aux chemins de fer)
                                • GSM-R Data : Système de transmission de données entre les installations « sol » et les installations « bord » via le réseau GSM-R

                                I

                                • ICS : Installations de circulation à contre-sens
                                • IPCS : Installations permanentes de contre-sens
                                • IS : Installation de sécurité
                                • ITCS : Installations temporaires de contre-sens

                                J

                                • JRU : Juridical recording unit (Enregistreur des paramètres d’exploitation)

                                K

                                • KVB : Contrôle de vitesse par balises

                                L

                                • LEU : Line side electronic unit (codeur ERTMS)
                                • LGV : Ligne à grande vitesse
                                • LTV : Limitation temporaire de vitesse

                                M

                                • MA : Movement authority : autorisation donnée à un train de circuler vers un point donné en tant que mouvement supervisé

                                N

                                • Nf : Non franchissable
                                • NL : Non leading (non en tête) : Mode technique de circulation utilisé pour la double traction ou la pousse

                                O

                                • OS : On sight (conduite à vue) : mode technique de circulation qui autorise le conducteur à s’avancer en marche à vue. En ETCS1, le mode OS accompagné du message textuel national « Voie de service » impose la marche en manoeuvre pour la réception sur voie de service

                                P

                                • PI ETCS : Point d’information ETCS : constitué d’une ou plusieurs balises transmettant des informations vers le bord (par exemple PI avancé ou PI signal)
                                • PK : Point Kilométrique : position géographique basée sur un RK (Repère Kilométrique)
                                • PL : Pleine ligne
                                • PLD : Point limite de domaine : point où une transition entre ETCS et un autre système de signalisation a lieu
                                • PN : Passage à niveau
                                • PO : Point opérationnel : collection de points représentant un lieu d’intérêt, voir exemple.
                                • PR : Point remarquable : voir PO

                                R

                                • RBC : Radio block center : système centralisé fonctionnant avec les enclenchements afin d’établir et de contrôler l’espacement et le mouvement des trains en envoyant et recevant des informations par radio en ETCS2 ou 3
                                • RFN : Réseau Ferré National
                                • RK : Repère Kilométrique : bornes (physiques) placées sur une voie à distance régulière (environ un kilomètre les unes des autres mais pouvant varier) servant à se repérer sur une voie
                                • RST : Radio sol-train
                                • RT : Renseignement technique
                                • RV : Reversing (refoulement) : mode technique de circulation utilisé pour permettre au train de reculer d’urgence sans signaux ni ordre dans une zone prédéfinie. Ce mode n’est pas utilisé sur le RFN

                                S

                                • SEL : Section d’électrification. La plus petite portion d’un caténaire pouvant être coupée pour travaux
                                • SGS : Système de gestion de la sécurité
                                • SH : Shunting (manoeuvre) : mode technique de circulation manoeuvre
                                • SN : System national : mode technique de circulation de niveau STM
                                • SR : Staff responsible (responsabilité agent) : mode technique de circulation utilisé dans les situations dégradées. Il est utilisable sous la responsabilité respective de l’agent-circulation et du conducteur
                                • SR : Système de repérage
                                • SRV : Système de repérage voie : métadonnées et anomalies (données correctives) permettant de faire des calculs de distance entre deux PKs sur une voie
                                • STM : Specific transmission module (Module spécifique de transmission) : ce dispositif permet à l’ETCS d’utiliser un système de signalisation national

                                T

                                • TECS : Tableau lumineux d’entrée à contre sens
                                • TIV : Tableau indicateur de vitesse
                                • TIV : Tronçon d’itinéraire de voie (Track Section en anglais).
                                • TR : Trip : mode technique de circulation entraînant une application irréversible du freinage d’urgence par le système ETCS jusqu’à l’arrêt du train
                                • TSCS : Tableau lumineux de sortie à contre sens
                                • TVM : Transmission voie machine

                                V

                                • VB : Voie banalisée
                                • VP : Voie principale
                                • VS : Voie de service
                                • VU : Voie unique
                                • VUT : Voie unique temporaire
                                • VUTP : Voie unique temporaire à caractère permanent

                                Z

                                • ZEP : Zone élémentaire de protection : la plus petite portion de voie pouvant être fermée pour des travaux
                                © 2024 Contributeurs à OSRD. Tous droits réservés
                                \ No newline at end of file +

                                Version imprimable multipages. +Cliquer ici pour imprimer.

                                Retour à la version par défaut.

                                Glossaire

                                Glossaire thématique d’OSRD et du ferroviaire

                                  À compléter : ouvrez une issue en cas de mot manquant

                                  A

                                  • ADV : Appareil de voie

                                  B

                                  • BA : Block automatique
                                  • BAL : Block automatique lumineux
                                  • BAPR : Block automatique à permissivité restreinte
                                  • BM : Block manuel
                                  • BMCV : BM par circuit de voie
                                  • BMVU : BM de voie unique

                                  C

                                  • CAPI : Cantonnement assisté par informatique
                                  • CC : Commande et contrôle
                                  • COVIT : Contrôle de vitesse
                                  • CT : Cantonnement téléphonique

                                  D

                                  • DAAT : Dispositif d’arrêt automatique des trains
                                  • DMI : Driver machine interface : dispositif qui permet la communication entre le système bord et le conducteur
                                  • DV : Double voie

                                  E

                                  • EOA : End of authority (fin d’autorisation de mouvement)
                                  • EPSF : Établissement public de sécurité ferroviaire
                                  • ETCS : European train control system (système européen de contrôle commande des trains)
                                  • ERTMS : European rail traffic management system (système européen de gestion du trafic ferroviaire)
                                  • EVC : European vital computer. (ordinateur européen de sécurité) : calculateur de bord qui supervise la marche du train en fonction des données sol et bord

                                  F

                                  • FA : Fermeture automatique
                                  • FS : Full supervision (supervision complète) : mode technique dans lequel le train est supervisé en vitesse et déplacement = marche normale attribuée au train

                                  G

                                  • GI : Gestionnaire d’infrastructure
                                  • GSM/GFU : Global system for mobile communication/Groupe fermé d’utilisateurs
                                  • GSM-R : Global system for mobile communication railways (Système de communication téléphonique pour mobile dédié aux chemins de fer)
                                  • GSM-R Data : Système de transmission de données entre les installations « sol » et les installations « bord » via le réseau GSM-R

                                  I

                                  • ICS : Installations de circulation à contre-sens
                                  • IPCS : Installations permanentes de contre-sens
                                  • IS : Installation de sécurité
                                  • ITCS : Installations temporaires de contre-sens

                                  J

                                  • JRU : Juridical recording unit (Enregistreur des paramètres d’exploitation)

                                  K

                                  • KVB : Contrôle de vitesse par balises

                                  L

                                  • LEU : Line side electronic unit (codeur ERTMS)
                                  • LGV : Ligne à grande vitesse
                                  • LTV : Limitation temporaire de vitesse

                                  M

                                  • MA : Movement authority : autorisation donnée à un train de circuler vers un point donné en tant que mouvement supervisé

                                  N

                                  • Nf : Non franchissable
                                  • NL : Non leading (non en tête) : Mode technique de circulation utilisé pour la double traction ou la pousse

                                  O

                                  • OS : On sight (conduite à vue) : mode technique de circulation qui autorise le conducteur à s’avancer en marche à vue. En ETCS1, le mode OS accompagné du message textuel national « Voie de service » impose la marche en manoeuvre pour la réception sur voie de service

                                  P

                                  • PI ETCS : Point d’information ETCS : constitué d’une ou plusieurs balises transmettant des informations vers le bord (par exemple PI avancé ou PI signal)
                                  • PK : Point Kilométrique : position géographique basée sur un RK (Repère Kilométrique)
                                  • PL : Pleine ligne
                                  • PLD : Point limite de domaine : point où une transition entre ETCS et un autre système de signalisation a lieu
                                  • PN : Passage à niveau
                                  • PO : Point opérationnel : collection de points représentant un lieu d’intérêt, voir exemple.
                                  • PR : Point remarquable : voir PO

                                  R

                                  • RBC : Radio block center : système centralisé fonctionnant avec les enclenchements afin d’établir et de contrôler l’espacement et le mouvement des trains en envoyant et recevant des informations par radio en ETCS2 ou 3
                                  • RFN : Réseau Ferré National
                                  • RK : Repère Kilométrique : bornes (physiques) placées sur une voie à distance régulière (environ un kilomètre les unes des autres mais pouvant varier) servant à se repérer sur une voie
                                  • RST : Radio sol-train
                                  • RT : Renseignement technique
                                  • RV : Reversing (refoulement) : mode technique de circulation utilisé pour permettre au train de reculer d’urgence sans signaux ni ordre dans une zone prédéfinie. Ce mode n’est pas utilisé sur le RFN

                                  S

                                  • SEL : Section d’électrification. La plus petite portion d’un caténaire pouvant être coupée pour travaux
                                  • SGS : Système de gestion de la sécurité
                                  • SH : Shunting (manoeuvre) : mode technique de circulation manoeuvre
                                  • SN : System national : mode technique de circulation de niveau STM
                                  • SR : Staff responsible (responsabilité agent) : mode technique de circulation utilisé dans les situations dégradées. Il est utilisable sous la responsabilité respective de l’agent-circulation et du conducteur
                                  • SR : Système de repérage
                                  • SRV : Système de repérage voie : métadonnées et anomalies (données correctives) permettant de faire des calculs de distance entre deux PKs sur une voie
                                  • STM : Specific transmission module (Module spécifique de transmission) : ce dispositif permet à l’ETCS d’utiliser un système de signalisation national

                                  T

                                  • TECS : Tableau lumineux d’entrée à contre sens
                                  • TIV : Tableau indicateur de vitesse
                                  • TIV : Tronçon d’itinéraire de voie (Track Section en anglais).
                                  • TR : Trip : mode technique de circulation entraînant une application irréversible du freinage d’urgence par le système ETCS jusqu’à l’arrêt du train
                                  • TSCS : Tableau lumineux de sortie à contre sens
                                  • TVM : Transmission voie machine

                                  V

                                  • VB : Voie banalisée
                                  • VP : Voie principale
                                  • VS : Voie de service
                                  • VU : Voie unique
                                  • VUT : Voie unique temporaire
                                  • VUTP : Voie unique temporaire à caractère permanent

                                  Z

                                  • ZEP : Zone élémentaire de protection : la plus petite portion de voie pouvant être fermée pour des travaux
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/glossary/index.html b/fr/docs/railway-wiki/glossary/index.html index d75366ac8..bfd7934c3 100644 --- a/fr/docs/railway-wiki/glossary/index.html +++ b/fr/docs/railway-wiki/glossary/index.html @@ -1,5 +1,5 @@ Glossaire | OSRD -

                                  Glossaire

                                  Glossaire thématique d’OSRD et du ferroviaire

                                  À compléter : ouvrez une issue en cas de mot manquant

                                  A

                                  • ADV : Appareil de voie

                                  B

                                  • BA : Block automatique
                                  • BAL : Block automatique lumineux
                                  • BAPR : Block automatique à permissivité restreinte
                                  • BM : Block manuel
                                  • BMCV : BM par circuit de voie
                                  • BMVU : BM de voie unique

                                  C

                                  • CAPI : Cantonnement assisté par informatique
                                  • CC : Commande et contrôle
                                  • COVIT : Contrôle de vitesse
                                  • CT : Cantonnement téléphonique

                                  D

                                  • DAAT : Dispositif d’arrêt automatique des trains
                                  • DMI : Driver machine interface : dispositif qui permet la communication entre le système bord et le conducteur
                                  • DV : Double voie

                                  E

                                  • EOA : End of authority (fin d’autorisation de mouvement)
                                  • EPSF : Établissement public de sécurité ferroviaire
                                  • ETCS : European train control system (système européen de contrôle commande des trains)
                                  • ERTMS : European rail traffic management system (système européen de gestion du trafic ferroviaire)
                                  • EVC : European vital computer. (ordinateur européen de sécurité) : calculateur de bord qui supervise la marche du train en fonction des données sol et bord

                                  F

                                  • FA : Fermeture automatique
                                  • FS : Full supervision (supervision complète) : mode technique dans lequel le train est supervisé en vitesse et déplacement = marche normale attribuée au train

                                  G

                                  • GI : Gestionnaire d’infrastructure
                                  • GSM/GFU : Global system for mobile communication/Groupe fermé d’utilisateurs
                                  • GSM-R : Global system for mobile communication railways (Système de communication téléphonique pour mobile dédié aux chemins de fer)
                                  • GSM-R Data : Système de transmission de données entre les installations « sol » et les installations « bord » via le réseau GSM-R

                                  I

                                  • ICS : Installations de circulation à contre-sens
                                  • IPCS : Installations permanentes de contre-sens
                                  • IS : Installation de sécurité
                                  • ITCS : Installations temporaires de contre-sens

                                  J

                                  • JRU : Juridical recording unit (Enregistreur des paramètres d’exploitation)

                                  K

                                  • KVB : Contrôle de vitesse par balises

                                  L

                                  • LEU : Line side electronic unit (codeur ERTMS)
                                  • LGV : Ligne à grande vitesse
                                  • LTV : Limitation temporaire de vitesse

                                  M

                                  • MA : Movement authority : autorisation donnée à un train de circuler vers un point donné en tant que mouvement supervisé

                                  N

                                  • Nf : Non franchissable
                                  • NL : Non leading (non en tête) : Mode technique de circulation utilisé pour la double traction ou la pousse

                                  O

                                  • OS : On sight (conduite à vue) : mode technique de circulation qui autorise le conducteur à s’avancer en marche à vue. En ETCS1, le mode OS accompagné du message textuel national « Voie de service » impose la marche en manoeuvre pour la réception sur voie de service

                                  P

                                  • PI ETCS : Point d’information ETCS : constitué d’une ou plusieurs balises transmettant des informations vers le bord (par exemple PI avancé ou PI signal)
                                  • PK : Point Kilométrique : position géographique basée sur un RK (Repère Kilométrique)
                                  • PL : Pleine ligne
                                  • PLD : Point limite de domaine : point où une transition entre ETCS et un autre système de signalisation a lieu
                                  • PN : Passage à niveau
                                  • PO : Point opérationnel : collection de points représentant un lieu d’intérêt, voir exemple.
                                  • PR : Point remarquable : voir PO

                                  R

                                  • RBC : Radio block center : système centralisé fonctionnant avec les enclenchements afin d’établir et de contrôler l’espacement et le mouvement des trains en envoyant et recevant des informations par radio en ETCS2 ou 3
                                  • RFN : Réseau Ferré National
                                  • RK : Repère Kilométrique : bornes (physiques) placées sur une voie à distance régulière (environ un kilomètre les unes des autres mais pouvant varier) servant à se repérer sur une voie
                                  • RST : Radio sol-train
                                  • RT : Renseignement technique
                                  • RV : Reversing (refoulement) : mode technique de circulation utilisé pour permettre au train de reculer d’urgence sans signaux ni ordre dans une zone prédéfinie. Ce mode n’est pas utilisé sur le RFN

                                  S

                                  • SEL : Section d’électrification. La plus petite portion d’un caténaire pouvant être coupée pour travaux
                                  • SGS : Système de gestion de la sécurité
                                  • SH : Shunting (manoeuvre) : mode technique de circulation manoeuvre
                                  • SN : System national : mode technique de circulation de niveau STM
                                  • SR : Staff responsible (responsabilité agent) : mode technique de circulation utilisé dans les situations dégradées. Il est utilisable sous la responsabilité respective de l’agent-circulation et du conducteur
                                  • SR : Système de repérage
                                  • SRV : Système de repérage voie : métadonnées et anomalies (données correctives) permettant de faire des calculs de distance entre deux PKs sur une voie
                                  • STM : Specific transmission module (Module spécifique de transmission) : ce dispositif permet à l’ETCS d’utiliser un système de signalisation national

                                  T

                                  • TECS : Tableau lumineux d’entrée à contre sens
                                  • TIV : Tableau indicateur de vitesse
                                  • TIV : Tronçon d’itinéraire de voie (Track Section en anglais).
                                  • TR : Trip : mode technique de circulation entraînant une application irréversible du freinage d’urgence par le système ETCS jusqu’à l’arrêt du train
                                  • TSCS : Tableau lumineux de sortie à contre sens
                                  • TVM : Transmission voie machine

                                  V

                                  • VB : Voie banalisée
                                  • VP : Voie principale
                                  • VS : Voie de service
                                  • VU : Voie unique
                                  • VUT : Voie unique temporaire
                                  • VUTP : Voie unique temporaire à caractère permanent

                                  Z

                                  • ZEP : Zone élémentaire de protection : la plus petite portion de voie pouvant être fermée pour des travaux
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/index.html b/fr/docs/railway-wiki/index.html index a44b627c6..0ff2dfc3f 100644 --- a/fr/docs/railway-wiki/index.html +++ b/fr/docs/railway-wiki/index.html @@ -1,5 +1,5 @@ Wiki Ferroviaire | OSRD -

                                  Wiki Ferroviaire

                                  Wiki ferroviaire international

                                  Ce wiki a pour objectif de rendre accessible aux développeurs des informations sur le monde ferroviaire.

                                  Cela ne peut se produire que si le contenu est ajouté lorsque nécessaire. Si quelque chose manque, contribuez !

                                  Glossaire

                                  Glossaire thématique d’OSRD et du ferroviaire

                                  Signalisation

                                  Les signaux, régimes d’exploitation des trains, et les systèmes d’espacement des trains

                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/_print/index.html b/fr/docs/railway-wiki/signalling/_print/index.html index 99bb94efa..ea00d78ca 100644 --- a/fr/docs/railway-wiki/signalling/_print/index.html +++ b/fr/docs/railway-wiki/signalling/_print/index.html @@ -1,5 +1,5 @@ Signalisation | OSRD -

                                  Version imprimable multipages. +

                                  Version imprimable multipages. Cliquer ici pour imprimer.

                                  Retour à la version par défaut.

                                  Signalisation

                                  Les signaux, régimes d’exploitation des trains, et les systèmes d’espacement des trains

                                  Cette section est destinée à exposer les principes généraux relatifs :

                                  • aux signaux
                                  • aux régimes d’exploitation des lignes (à venir)
                                  • aux différents systèmes d’espacement des trains

                                  La grande majorité des informations de cette section sont extraites du document pédagogique de l’Établissement Public de Sécurité Ferroviaire (EPSF) édité le 05 juillet 2017.

                                  1 - Les risques ferroviaires

                                  Les trains doivent circuler en toute sécurité. Les risques majeurs liés aux circulations ferroviaires sont les suivants :

                                  • le rattrapage des trains qui circulent dans le même sens sur la même voie ;
                                  • la prise en écharpe, c’est-à-dire la collision latérale de trains qui circulent sur des itinéraires convergents ;
                                  • le nez à nez, c’est-à-dire la collision frontale de trains qui circulent en sens contraire sur la même voie ;
                                  • le déraillement ;
                                  • la collision avec un obstacle.

                                  On prévient ces risques notamment par :

                                  • la mise en place d’une signalisation ;
                                  • l’établissement d’un régime d’exploitation de la ligne (double voie, voie banalisée, voie unique) ;
                                  • la mise en place d’un système d’espacement des trains ;
                                  • la mise en oeuvre de procédures d’exploitation.

                                  D’autres dispositifs techniques contribuent également à couvrir ces risques tels que :

                                  • les installations de sécurité, notamment les enclenchements des postes d’aiguillage ;
                                  • le DAAT qui est un dispositif permettant d’assurer l’arrêt automatique des trains en cas de franchissement intempestif d’un point d’information avec signal d’arrêt fermé ;
                                  • le KVB, le COVIT (TVM) sont des exemples de systèmes de contrôle de la vitesse, avec contrôle de franchissement des signaux non franchissables ;
                                  • le système de contrôle commande des trains, intégré dans l’ETCS.

                                  La sécurité des circulations repose aussi sur le respect rigoureux des consignes et instructions opérationnelles par tous les agents concernés par la circulation des trains.

                                  Ces procédures sont de la responsabilité des exploitants ferroviaires. Elles sont décrites dans le manuel du système de gestion de la sécurité (SGS) qu’ils établissent et qui fait l’objet d’une instruction par l’EPSF chargé de délivrer le certificat ou l’agrément de sécurité.

                                  2 - Les signaux

                                  Principe

                                  Pour transmettre au conducteur des ordres et informations liées à la sécurité des circulations, il est fait usage de signaux. Ces signaux peuvent indiquer des informations relatives aux limites de vitesse, peuvent servir à garantir @@ -191,4 +191,4 @@ que la vitesse du train.

                                • Mode NL : Conduite d’un engin moteur non en tête du mouvement

                                  Ce mode technique est utilisé en cas de pousse ou de double traction.

                                  • Protection contre le rattrapage

                                  En mode FS, une vitesse autorisée affichée sans la présentation de l’EOA signifie « marche normale ».

                                  La MA constituée d’un ou plusieurs cantons est allouée canton par canton, par ajout successif d’un canton. Si le canton en aval du dernier canton alloué est occupé le train doit être en mesure de s’arrêter avant l’entrée de ce canton. Le conducteur est alors avisé par une indication sonore au DMI.

                                  Dès lors, les indications de conduite (vitesse but égale à 0 et une distance but) permettant de respecter la courbe de -freinage sont affichées.

                                  Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                                  4.2.2 - GSM-R

                                  Global System for Mobiles - Railways

                                  4.2.3 - GPRS

                                  General Packet Radio Service

                                  4.2.4 - FRMCS

                                  Futur Système de Communications Mobiles Ferroviaires

                                  4.2.5 - ETML

                                  European Train Management Layer
                                  © 2024 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file +freinage sont affichées.

                                  Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                                  4.2.2 - GSM-R

                                  Global System for Mobiles - Railways

                                  4.2.3 - GPRS

                                  General Packet Radio Service

                                  4.2.4 - FRMCS

                                  Futur Système de Communications Mobiles Ferroviaires

                                  4.2.5 - ETML

                                  European Train Management Layer
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/index.html b/fr/docs/railway-wiki/signalling/index.html index 06aeb3226..2b32c450e 100644 --- a/fr/docs/railway-wiki/signalling/index.html +++ b/fr/docs/railway-wiki/signalling/index.html @@ -1,5 +1,5 @@ Signalisation | OSRD -
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/_print/index.html b/fr/docs/railway-wiki/signalling/operation-modes/_print/index.html index 83e7e3ea6..0eed28fce 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/_print/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/_print/index.html @@ -1,5 +1,5 @@ Les régimes d’exploitation des lignes | OSRD -

                                  Version imprimable multipages. +

                                  Version imprimable multipages. Cliquer ici pour imprimer.

                                  Retour à la version par défaut.

                                  Les régimes d’exploitation des lignes

                                  Définition

                                  Ensemble des règles d’exploitation, c’est-à-dire des règles appliquées pour organiser et assurer le trafic, propres à une ligne en fonction des installations mises en œuvre pour en assurer l’exploitation.

                                  Les principaux régimes d’exploitation sont : la voie unique, la voie banalisée, la double voie.

                                  Principe

                                  Il ne faut pas confondre régime d’exploitation et nombre de voies sur une plateforme, car il existe des plateformes à 2 @@ -105,4 +105,4 @@ écrit ou le transmet par dépêche. Cet ordre reprend les points ou zones du parcours sur lesquels le conducteur doit appliquer des prescriptions particulières.

                                  En effet, les installations et la signalisation ne sont généralement pas prévues pour les circulations en sens inverse du sens normal (PN, limitations de vitesse, etc.).

                                  Lorsque le conducteur est en tête du mouvement, la circulation s’effectue en marche à vue sur tout le parcours effectué -à contre-voie (le conducteur peut rencontrer un obstacle non protégé).

                                  Lorsque le conducteur n’est pas en tête, la circulation est guidée par des signaux de manœuvre.

                                  La fin du parcours à contre voie est généralement repérée soit :

                                  • par un signal carré ;
                                  • par un signal d’arrêt à main.
                                  © 2024 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file +à contre-voie (le conducteur peut rencontrer un obstacle non protégé).

                                  Lorsque le conducteur n’est pas en tête, la circulation est guidée par des signaux de manœuvre.

                                  La fin du parcours à contre voie est généralement repérée soit :

                                  • par un signal carré ;
                                  • par un signal d’arrêt à main.
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/_print/index.html b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/_print/index.html index b72604857..b9e6ab896 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/_print/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/_print/index.html @@ -1,5 +1,5 @@ La double voie | OSRD -

                                  Version imprimable multipages. +

                                  Version imprimable multipages. Cliquer ici pour imprimer.

                                  Retour à la version par défaut.

                                  La double voie

                                  Définition

                                  Régime d’exploitation d’une ligne à deux voies (ou plus) dans lequel chaque voie est normalement affectée à la circulation des trains dans un sens déterminé.

                                  Principe

                                  Le risque de nez à nez

                                  Sur une ligne à deux voies, les circulations empruntent normalement la voie de gauche dans le sens de la marche (voie de droite sur les lignes désignées à la documentation d’exploitation).

                                  La double voie est exploitée selon les modalités définies par SNCF Réseau qui prévoit que chaque agent du service de la @@ -49,4 +49,4 @@ écrit ou le transmet par dépêche. Cet ordre reprend les points ou zones du parcours sur lesquels le conducteur doit appliquer des prescriptions particulières.

                                  En effet, les installations et la signalisation ne sont généralement pas prévues pour les circulations en sens inverse du sens normal (PN, limitations de vitesse, etc.).

                                  Lorsque le conducteur est en tête du mouvement, la circulation s’effectue en marche à vue sur tout le parcours effectué -à contre-voie (le conducteur peut rencontrer un obstacle non protégé).

                                  Lorsque le conducteur n’est pas en tête, la circulation est guidée par des signaux de manœuvre.

                                  La fin du parcours à contre voie est généralement repérée soit :

                                  • par un signal carré ;
                                  • par un signal d’arrêt à main.
                                  © 2024 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file +à contre-voie (le conducteur peut rencontrer un obstacle non protégé).

                                  Lorsque le conducteur n’est pas en tête, la circulation est guidée par des signaux de manœuvre.

                                  La fin du parcours à contre voie est généralement repérée soit :

                                  • par un signal carré ;
                                  • par un signal d’arrêt à main.
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/index.html b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/index.html index 2aa98b983..e567137f5 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/index.html @@ -1,5 +1,5 @@ La double voie | OSRD -
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-direction-installations/index.html b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-direction-installations/index.html index 06666aad3..68f12b41e 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-direction-installations/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-direction-installations/index.html @@ -3,7 +3,7 @@ Le risque de nez à nez Des enclenchements de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre.">
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-track-movement/index.html b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-track-movement/index.html index 44faf381c..7346be4af 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-track-movement/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-track-movement/index.html @@ -1,5 +1,5 @@ Mouvement à contre-voie | OSRD -
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track-of-permanent-nature/index.html b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track-of-permanent-nature/index.html index a76088094..5f5f9b1cd 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track-of-permanent-nature/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track-of-permanent-nature/index.html @@ -7,7 +7,7 @@ Les sections de ligne équipées de VUTP sont désignées aux RT. Le risque de nez à nez Des enclenchements de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre.">
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/index.html b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/index.html index 554eb6836..ccf2070fe 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/index.html @@ -3,7 +3,7 @@ La VUT est donc un régime temporaire d’exploitation permettant, sur une ligne à double voie non équipée d’installation de contresens, de faire circuler les trains des deux sens sur une seule et même voie.">
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/index.html b/fr/docs/railway-wiki/signalling/operation-modes/index.html index 00fd9c8b5..63ff281cb 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/index.html @@ -1,5 +1,5 @@ Les régimes d’exploitation des lignes | OSRD -
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/_print/index.html b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/_print/index.html index 29831acd5..9d8132404 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/_print/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/_print/index.html @@ -1,5 +1,5 @@ Les lignes à une seule voie | OSRD -

                                  Version imprimable multipages. +

                                  Version imprimable multipages. Cliquer ici pour imprimer.

                                  Retour à la version par défaut.

                                  Les lignes à une seule voie

                                  Elles sont principalement exploitées selon les dispositions du régime général d’exploitation de la voie unique, certaines d’entre elles disposant d’un minimum d’équipement de signalisation sont désignées « voie unique à signalisation simplifiée ».

                                  D’autres lignes, peu fréquentées et fermées au service voyageur sont exploitées selon le régime de la voie unique à @@ -46,4 +46,4 @@ Cette interdiction est maintenue tant que l’intervalle est occupé.

                                  Le risque de rattrapage

                                  L’espacement est assuré automatiquement. En signalisation au sol, l’espacement des trains de même sens est assuré par le block automatique par l’intermédiaire de circuits de voie ou de compteur d’essieux. Selon l’importance du trafic, il peut s’agir de :

                                  En signalisation de cabine, la TVM ou l’ETCS assurent l’espacement.

                                  © 2024 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file +plus important.

                                  En signalisation de cabine, la TVM ou l’ETCS assurent l’espacement.

                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/index.html b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/index.html index 5e281064b..9084bb4d4 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/index.html @@ -1,5 +1,5 @@ Les lignes à une seule voie | OSRD -
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-shuttle/index.html b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-shuttle/index.html index 021b6a0cb..ef4a1fd09 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-shuttle/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-shuttle/index.html @@ -7,7 +7,7 @@ Principe L’exploitation en navette consiste à n’autoriser la présence que d’une seule circulation sur la section de ligne concernée, cette circulation revenant à son point de départ, ce qui par conception limite les risques de collision de trains. Toutefois, le programme peut inclure moyennant des procédures adaptées des mouvements de desserte, avec ou sans possibilité de garage (desserte origine terminus ou desserte en antenne).">
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-two-ways/index.html b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-two-ways/index.html index d2f0a0a7c..e86886c78 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-two-ways/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-two-ways/index.html @@ -3,7 +3,7 @@ Principe Une voie banalisée peut être découpée en plusieurs intervalles (points entre lesquels il n’existe aucune possibilité de croisement ou dépassement).">
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/index.html b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/index.html index 3079332f3..97e2ab517 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/index.html @@ -3,7 +3,7 @@ Principe Une consigne locale d’exploitation adaptée à chaque VUTR précise les caractéristiques d&rsquo;exploitation comme la vitesse de la ligne, la signalisation, les établissements, les liaisons téléphoniques, les PN, etc.">
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-simplified-signalling/index.html b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-simplified-signalling/index.html index b909a1786..006903427 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-simplified-signalling/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-simplified-signalling/index.html @@ -3,7 +3,7 @@ Principe Le risque de nez à nez Elles sont exploitées selon les modalités du régime général d’exploitation de la voie unique (notamment le respect de l’ordre théorique de circulation).">
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track/index.html b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track/index.html index f22a9f82c..c6a74daea 100644 --- a/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track/index.html +++ b/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track/index.html @@ -1,5 +1,5 @@ La voie unique | OSRD -
                                  © 2025 Contributeurs à OSRD. Tous droits réservés
                                  \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/risks/_print/index.html b/fr/docs/railway-wiki/signalling/risks/_print/index.html index 2663219f3..aa5f64ae4 100644 --- a/fr/docs/railway-wiki/signalling/risks/_print/index.html +++ b/fr/docs/railway-wiki/signalling/risks/_print/index.html @@ -1,3 +1,3 @@ Les risques ferroviaires | OSRD -

                                  Version imprimable multipages. -Cliquer ici pour imprimer.

                                  Retour à la version par défaut.

                                  Les risques ferroviaires

                                    Les trains doivent circuler en toute sécurité. Les risques majeurs liés aux circulations ferroviaires sont les suivants :

                                    • le rattrapage des trains qui circulent dans le même sens sur la même voie ;
                                    • la prise en écharpe, c’est-à-dire la collision latérale de trains qui circulent sur des itinéraires convergents ;
                                    • le nez à nez, c’est-à-dire la collision frontale de trains qui circulent en sens contraire sur la même voie ;
                                    • le déraillement ;
                                    • la collision avec un obstacle.

                                    On prévient ces risques notamment par :

                                    • la mise en place d’une signalisation ;
                                    • l’établissement d’un régime d’exploitation de la ligne (double voie, voie banalisée, voie unique) ;
                                    • la mise en place d’un système d’espacement des trains ;
                                    • la mise en oeuvre de procédures d’exploitation.

                                    D’autres dispositifs techniques contribuent également à couvrir ces risques tels que :

                                    • les installations de sécurité, notamment les enclenchements des postes d’aiguillage ;
                                    • le DAAT qui est un dispositif permettant d’assurer l’arrêt automatique des trains en cas de franchissement intempestif d’un point d’information avec signal d’arrêt fermé ;
                                    • le KVB, le COVIT (TVM) sont des exemples de systèmes de contrôle de la vitesse, avec contrôle de franchissement des signaux non franchissables ;
                                    • le système de contrôle commande des trains, intégré dans l’ETCS.

                                    La sécurité des circulations repose aussi sur le respect rigoureux des consignes et instructions opérationnelles par tous les agents concernés par la circulation des trains.

                                    Ces procédures sont de la responsabilité des exploitants ferroviaires. Elles sont décrites dans le manuel du système de gestion de la sécurité (SGS) qu’ils établissent et qui fait l’objet d’une instruction par l’EPSF chargé de délivrer le certificat ou l’agrément de sécurité.

                                    © 2024 Contributeurs à OSRD. Tous droits réservés
                                    \ No newline at end of file +

                                    Version imprimable multipages. +Cliquer ici pour imprimer.

                                    Retour à la version par défaut.

                                    Les risques ferroviaires

                                      Les trains doivent circuler en toute sécurité. Les risques majeurs liés aux circulations ferroviaires sont les suivants :

                                      • le rattrapage des trains qui circulent dans le même sens sur la même voie ;
                                      • la prise en écharpe, c’est-à-dire la collision latérale de trains qui circulent sur des itinéraires convergents ;
                                      • le nez à nez, c’est-à-dire la collision frontale de trains qui circulent en sens contraire sur la même voie ;
                                      • le déraillement ;
                                      • la collision avec un obstacle.

                                      On prévient ces risques notamment par :

                                      • la mise en place d’une signalisation ;
                                      • l’établissement d’un régime d’exploitation de la ligne (double voie, voie banalisée, voie unique) ;
                                      • la mise en place d’un système d’espacement des trains ;
                                      • la mise en oeuvre de procédures d’exploitation.

                                      D’autres dispositifs techniques contribuent également à couvrir ces risques tels que :

                                      • les installations de sécurité, notamment les enclenchements des postes d’aiguillage ;
                                      • le DAAT qui est un dispositif permettant d’assurer l’arrêt automatique des trains en cas de franchissement intempestif d’un point d’information avec signal d’arrêt fermé ;
                                      • le KVB, le COVIT (TVM) sont des exemples de systèmes de contrôle de la vitesse, avec contrôle de franchissement des signaux non franchissables ;
                                      • le système de contrôle commande des trains, intégré dans l’ETCS.

                                      La sécurité des circulations repose aussi sur le respect rigoureux des consignes et instructions opérationnelles par tous les agents concernés par la circulation des trains.

                                      Ces procédures sont de la responsabilité des exploitants ferroviaires. Elles sont décrites dans le manuel du système de gestion de la sécurité (SGS) qu’ils établissent et qui fait l’objet d’une instruction par l’EPSF chargé de délivrer le certificat ou l’agrément de sécurité.

                                      © 2025 Contributeurs à OSRD. Tous droits réservés
                                      \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/risks/index.html b/fr/docs/railway-wiki/signalling/risks/index.html index 416f49999..8c39467a2 100644 --- a/fr/docs/railway-wiki/signalling/risks/index.html +++ b/fr/docs/railway-wiki/signalling/risks/index.html @@ -1,5 +1,5 @@ Les risques ferroviaires | OSRD -

                                      Les risques ferroviaires

                                      Les trains doivent circuler en toute sécurité. Les risques majeurs liés aux circulations ferroviaires sont les suivants :

                                      • le rattrapage des trains qui circulent dans le même sens sur la même voie ;
                                      • la prise en écharpe, c’est-à-dire la collision latérale de trains qui circulent sur des itinéraires convergents ;
                                      • le nez à nez, c’est-à-dire la collision frontale de trains qui circulent en sens contraire sur la même voie ;
                                      • le déraillement ;
                                      • la collision avec un obstacle.

                                      On prévient ces risques notamment par :

                                      • la mise en place d’une signalisation ;
                                      • l’établissement d’un régime d’exploitation de la ligne (double voie, voie banalisée, voie unique) ;
                                      • la mise en place d’un système d’espacement des trains ;
                                      • la mise en oeuvre de procédures d’exploitation.

                                      D’autres dispositifs techniques contribuent également à couvrir ces risques tels que :

                                      • les installations de sécurité, notamment les enclenchements des postes d’aiguillage ;
                                      • le DAAT qui est un dispositif permettant d’assurer l’arrêt automatique des trains en cas de franchissement intempestif d’un point d’information avec signal d’arrêt fermé ;
                                      • le KVB, le COVIT (TVM) sont des exemples de systèmes de contrôle de la vitesse, avec contrôle de franchissement des signaux non franchissables ;
                                      • le système de contrôle commande des trains, intégré dans l’ETCS.

                                      La sécurité des circulations repose aussi sur le respect rigoureux des consignes et instructions opérationnelles par tous les agents concernés par la circulation des trains.

                                      Ces procédures sont de la responsabilité des exploitants ferroviaires. Elles sont décrites dans le manuel du système de gestion de la sécurité (SGS) qu’ils établissent et qui fait l’objet d’une instruction par l’EPSF chargé de délivrer le certificat ou l’agrément de sécurité.

                                      © 2025 Contributeurs à OSRD. Tous droits réservés
                                      \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/signals/_print/index.html b/fr/docs/railway-wiki/signalling/signals/_print/index.html index 11c44461b..14b2b8c3b 100644 --- a/fr/docs/railway-wiki/signalling/signals/_print/index.html +++ b/fr/docs/railway-wiki/signalling/signals/_print/index.html @@ -1,5 +1,5 @@ Les signaux | OSRD -

                                      Version imprimable multipages. +

                                      Version imprimable multipages. Cliquer ici pour imprimer.

                                      Retour à la version par défaut.

                                      Les signaux

                                        Principe

                                        Pour transmettre au conducteur des ordres et informations liées à la sécurité des circulations, il est fait usage de signaux. Ces signaux peuvent indiquer des informations relatives aux limites de vitesse, peuvent servir à garantir l’espacement des trains ou donner des indications diverses telles que l’accès à des voies de service, des ouvrages @@ -18,4 +18,4 @@ des ordres et une consigne de vitesse associée éventuellement à une distance but. La signalisation de cabine peut être complétée par une signalisation au sol dans certains cas pour :

                                        • repérer les points à ne pas dépasser, par exemple :

                                        • donner des ordres de traction électrique, des informations aux points d’entrée et de sortie du domaine de signalisation de cabine, etc.

                                        Des pancartes ou tableaux indiquent ces ordres et informations.

                                        Ces repères, pancartes ou tableaux sont implantés :

                                        • à gauche de la voie sur les plateformes à une seule voie ;
                                        • côté piste, à l’extérieur sur les plateformes à deux voies ;
                                        • dans le cas de plan de voie plus complexe, les pancartes ou tableaux sont fléchés.

                                        Nota : les repères ETCS et de la TVM ne sont pas fléchés du fait de leur graphisme indiquant la voie à laquelle ils s’adressent.

                                        Point de transition de signalisation (entrée sur LGV, armement de la signalisation de cabine)

                                        Le point de transition de signalisation (tableau CAB), ainsi que l’armement de la signalisation de cabine, se situent à -hauteur ou immédiatement en aval du dernier signal au sol (signal carré).

                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +hauteur ou immédiatement en aval du dernier signal au sol (signal carré).

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/signals/index.html b/fr/docs/railway-wiki/signalling/signals/index.html index f40341ad3..1ec87489e 100644 --- a/fr/docs/railway-wiki/signalling/signals/index.html +++ b/fr/docs/railway-wiki/signalling/signals/index.html @@ -1,5 +1,5 @@ Les signaux | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/_print/index.html b/fr/docs/railway-wiki/signalling/spacing/_print/index.html index 872bf1cc2..326ced789 100644 --- a/fr/docs/railway-wiki/signalling/spacing/_print/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/_print/index.html @@ -1,5 +1,5 @@ Les systèmes d'espacement des trains | OSRD -

                                        Version imprimable multipages. +

                                        Version imprimable multipages. Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Les systèmes d'espacement des trains

                                        Définition

                                        Le système d’espacement des trains de même sens, est destiné à éviter les rattrapages et consiste à fractionner la ligne en plusieurs cantons dont l’entrée est protégée par un signal d’arrêt.

                                        Principe

                                        Compte tenu de leur masse importante, de leur vitesse élevée, de la faible adhérence rail-roue, les trains ont besoin d’une distance importante pour s’arrêter.

                                        De ce fait, la distance nécessaire pour obtenir l’arrêt est généralement plus grande que la partie de voie visible par @@ -67,4 +67,4 @@ que la vitesse du train.

                                      • Mode NL : Conduite d’un engin moteur non en tête du mouvement

                                        Ce mode technique est utilisé en cas de pousse ou de double traction.

                                        • Protection contre le rattrapage

                                        En mode FS, une vitesse autorisée affichée sans la présentation de l’EOA signifie « marche normale ».

                                        La MA constituée d’un ou plusieurs cantons est allouée canton par canton, par ajout successif d’un canton. Si le canton en aval du dernier canton alloué est occupé le train doit être en mesure de s’arrêter avant l’entrée de ce canton. Le conducteur est alors avisé par une indication sonore au DMI.

                                        Dès lors, les indications de conduite (vitesse but égale à 0 et une distance but) permettant de respecter la courbe de -freinage sont affichées.

                                        Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                                        2.2 - GSM-R

                                        Global System for Mobiles - Railways

                                        2.3 - GPRS

                                        General Packet Radio Service

                                        2.4 - FRMCS

                                        Futur Système de Communications Mobiles Ferroviaires

                                        2.5 - ETML

                                        European Train Management Layer
                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +freinage sont affichées.

                                        Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                                        2.2 - GSM-R

                                        Global System for Mobiles - Railways

                                        2.3 - GPRS

                                        General Packet Radio Service

                                        2.4 - FRMCS

                                        Futur Système de Communications Mobiles Ferroviaires

                                        2.5 - ETML

                                        European Train Management Layer
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/_print/index.html b/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/_print/index.html index 208dd65a8..ee4a769ab 100644 --- a/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/_print/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/_print/index.html @@ -1,5 +1,5 @@ BA | OSRD -

                                        Version imprimable multipages. +

                                        Version imprimable multipages. Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        BA

                                        Block Automatique

                                        Principe

                                        Le block automatique se caractérise en block automatique lumineux (BAL) et en block automatique à permissivité restreinte (BAPR) par :

                                        • le fonctionnement entièrement automatique des signaux de cantonnement dont le changement d’état (fermeture ou ouverture) est provoqué par le passage des circulations sans aucune intervention humaine ;
                                        • l’état d’occupation de chaque canton, agissant directement sur le signal d’entrée correspondant est obtenu par le circuit de voie en BAL, généralement par un comptage d’essieu en BAPR. Le BAL permet un débit élevé des circulations sur la ligne.

                                        Fonctionnement d’un circuit de voie

                                        Un circuit de voie est principalement constitué de trois éléments :

                                        • un émetteur, branché à l’une des extrémités de la zone. Il délivre un courant qui peut être de différente nature selon les types de circuit de voie (continu, impulsionnel, alternatif, etc.) ;
                                        • une ligne de transmission, constituée par les deux files de rails ;
                                        • un récepteur, branché à l’autre extrémité de la zone. Il assure le filtrage, l’amplification et la transformation du signal reçu via les rails, ce qui agit sur un relais appelé relais de voie. Les contacts de ce relais sont utilisés pour établir ou couper le circuit électrique du signal d’entrée du canton.

                                        Lorsqu’aucun véhicule n’est présent sur la zone délimitant le circuit de voie (voie libre), le signal délivré par l’émetteur parvient au récepteur à travers la ligne de transmission, et le relais de voie est excité. Le feu d’entrée du canton est à voie libre (cas 1 ci-dessous).

                                        Lorsqu’un véhicule est présent, son premier essieu agit comme une faible résistance, appelée shunt, qui court-circuite la transmission. Dans ce cas, le niveau du signal parvenant au récepteur n’est plus suffisant et le relais de voie se désexcite, ce qui entraine la fermeture du signal d’entrée du canton (cas 2 ci-dessous).

                                        Fonctionnement des compteurs d’essieux

                                        Un compteur d’essieux est un dispositif technique servant à détecter la présence d’une circulation sur une section, par comptage des essieux qui franchissent les détecteurs encadrant cette section.

                                        Un point de détection est installé à chaque extrémité de la section, et chaque fois qu’un essieu passe sur ce point au @@ -11,4 +11,4 @@ roue et le rail.

                                        Implémentation

                                        Simuler correctement le système BAL nécessite de respecter les critères suivants :

                                        • lorsque la tête du train pénètre dans un canton, le signal d’entrée de celui-ci passe en indication d’arrêt
                                        • lorsque la queue du train libère un canton, son signal d’entrée passe en annonce
                                        • lorsque la queue du train libère un canton, le signal d’entrée du canton précédent passe en voie libre
                                        • les signaux présentent une voie libre par défaut, sauf les signaux Nf qui sont par défaut en indication d’arrêt

                                        2 - BAPR

                                        Block Automatique à Permitivité Restreinte

                                        Le signal d’entrée du canton est un signal qui présente une indication liée à l’état d’occupation du canton suivant (indication d’arrêt ou de voie libre). Sur certaines lignes l’occupation du canton n’est pas obtenue par le circuit de voie mais par un système de comptage d’essieux entrants et sortants.

                                        Les cantons sont beaucoup plus longs que le BAL (jusqu’à 15 km et plus) et par conséquent le débit est moins important.

                                        Avantages du BAPR

                                        Le BAPR offre un bon niveau de sécurité et il est moins coûteux que le BAL.

                                        Limites

                                        Ce type de block n’est adapté qu’aux lignes conventionnelles à trafic moyen compte tenu de l’espacement imposé entre 2 -trains successifs.

                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +trains successifs.

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bal/index.html b/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bal/index.html index e406a384d..131854927 100644 --- a/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bal/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bal/index.html @@ -1,5 +1,5 @@ BAL | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bapr/index.html b/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bapr/index.html index cf1e6e1fc..9ed527f77 100644 --- a/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bapr/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bapr/index.html @@ -1,5 +1,5 @@ BAPR | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/index.html b/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/index.html index 8d3b9cc97..ea29a1c5f 100644 --- a/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/index.html @@ -1,5 +1,5 @@ BA | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/ertms/_print/index.html b/fr/docs/railway-wiki/signalling/spacing/ertms/_print/index.html index fe19a69be..cce7eb9a9 100644 --- a/fr/docs/railway-wiki/signalling/spacing/ertms/_print/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/ertms/_print/index.html @@ -1,5 +1,5 @@ ERTMS | OSRD -

                                        Version imprimable multipages. +

                                        Version imprimable multipages. Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        ERTMS

                                        European Rail Traffic Management System

                                        Introduction

                                        L’ERTMS, pour European Rail Traffic Management System, est un système qui vise à harmoniser la signalisation ferroviaire en Europe.

                                        Il est composé de trois sous-systèmes :

                                        • un système de signalisation : l’ETCS
                                        • un système de communication : GSM-R / GPRS / FRMCS
                                        • un système de gestion du traffic : l’ETML

                                        1 - ETCS

                                        European Train Control System

                                        Généralités

                                        ETCS est le système européen de contrôle commande des trains. La partie bord est interopérable. La partie sol peut être différente selon les pays tout en répondant aux mêmes objectifs de fonctionnalité.

                                        Il existe quatre niveaux différents dont deux sont en service : L’ETCS 1 et L’ETCS 2. L’ETCS 0 est interdit en France. @@ -45,4 +45,4 @@ que la vitesse du train.

                                      • Mode NL : Conduite d’un engin moteur non en tête du mouvement

                                        Ce mode technique est utilisé en cas de pousse ou de double traction.

                                        • Protection contre le rattrapage

                                        En mode FS, une vitesse autorisée affichée sans la présentation de l’EOA signifie « marche normale ».

                                        La MA constituée d’un ou plusieurs cantons est allouée canton par canton, par ajout successif d’un canton. Si le canton en aval du dernier canton alloué est occupé le train doit être en mesure de s’arrêter avant l’entrée de ce canton. Le conducteur est alors avisé par une indication sonore au DMI.

                                        Dès lors, les indications de conduite (vitesse but égale à 0 et une distance but) permettant de respecter la courbe de -freinage sont affichées.

                                        Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                                        2 - GSM-R

                                        Global System for Mobiles - Railways

                                        3 - GPRS

                                        General Packet Radio Service

                                        4 - FRMCS

                                        Futur Système de Communications Mobiles Ferroviaires

                                        5 - ETML

                                        European Train Management Layer
                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +freinage sont affichées.

                                        Le conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.

                                        2 - GSM-R

                                        Global System for Mobiles - Railways

                                        3 - GPRS

                                        General Packet Radio Service

                                        4 - FRMCS

                                        Futur Système de Communications Mobiles Ferroviaires

                                        5 - ETML

                                        European Train Management Layer
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/ertms/etcs/index.html b/fr/docs/railway-wiki/signalling/spacing/ertms/etcs/index.html index 4c507568a..e138a04a1 100644 --- a/fr/docs/railway-wiki/signalling/spacing/ertms/etcs/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/ertms/etcs/index.html @@ -1,5 +1,5 @@ ETCS | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/ertms/etml/index.html b/fr/docs/railway-wiki/signalling/spacing/ertms/etml/index.html index 2926f326a..e9544bc81 100644 --- a/fr/docs/railway-wiki/signalling/spacing/ertms/etml/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/ertms/etml/index.html @@ -1,5 +1,5 @@ ETML | OSRD -

                                        ETML

                                        European Train Management Layer
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/ertms/frmcs/index.html b/fr/docs/railway-wiki/signalling/spacing/ertms/frmcs/index.html index 882fa506f..1bc12236a 100644 --- a/fr/docs/railway-wiki/signalling/spacing/ertms/frmcs/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/ertms/frmcs/index.html @@ -1,5 +1,5 @@ FRMCS | OSRD -

                                        FRMCS

                                        Futur Système de Communications Mobiles Ferroviaires
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/index.html b/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/index.html index 43211bcac..886e150cf 100644 --- a/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/index.html @@ -1,5 +1,5 @@ GPRS | OSRD -

                                        GPRS

                                        General Packet Radio Service
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/ertms/gsm-r/index.html b/fr/docs/railway-wiki/signalling/spacing/ertms/gsm-r/index.html index e9b26c70c..35df52545 100644 --- a/fr/docs/railway-wiki/signalling/spacing/ertms/gsm-r/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/ertms/gsm-r/index.html @@ -1,5 +1,5 @@ GSM-R | OSRD -

                                        GSM-R

                                        Global System for Mobiles - Railways
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/ertms/index.html b/fr/docs/railway-wiki/signalling/spacing/ertms/index.html index 2340c5ac2..d817c726c 100644 --- a/fr/docs/railway-wiki/signalling/spacing/ertms/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/ertms/index.html @@ -1,5 +1,5 @@ ERTMS | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/railway-wiki/signalling/spacing/index.html b/fr/docs/railway-wiki/signalling/spacing/index.html index 5cddbd0f5..a740b0b14 100644 --- a/fr/docs/railway-wiki/signalling/spacing/index.html +++ b/fr/docs/railway-wiki/signalling/spacing/index.html @@ -1,5 +1,5 @@ Les systèmes d'espacement des trains | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/_print/index.html b/fr/docs/reference/_print/index.html index e79573501..c22010cf6 100644 --- a/fr/docs/reference/_print/index.html +++ b/fr/docs/reference/_print/index.html @@ -1,5 +1,5 @@ Référence technique | OSRD -

                                        Version imprimable multipages. +

                                        Version imprimable multipages. Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Référence technique

                                        Machinerie interne et APIs

                                        Les guides de référence technique contiennent des références techniques pour les API et autres aspects de la machinerie OSRD. Ils présentent son fonctionnement et la manière de l’exploiter en partant du principe que les concepts clés de base sont maîtrisés.

                                        1 - Architecture

                                        Détails lié à l’architecture de OSRD

                                        Les documents d’architecture permettent de comprendre comment OSRD fonctionne globalement.

                                        1.1 - Flux des données

                                        Schéma des flux des données d’osrd

                                        Data-flow diagram

                                        2 - Documents de conception

                                        Détails liés à la conceptions de solutions techniques

                                        Les documents de conceptions décrivent comment et pourquoi un composant logiciel a été conçu, de l’exposition du problème à la solution technique, en passant par le chemin pris pour y arriver.

                                        2.1 - Poste d'aiguillage

                                        Décrit le fonctionnement du poste d’aiguillage virtuel

                                        Le modèle de simulation définit le rôle et comportement des différents objets simulés au sein d’OSRD.

                                        Cette modélisation est un compromis entre de multiples enjeux:

                                        • fidélité de la simulation
                                        • interprétabilité des résultats
                                        • adaptabilité du modèle à différentes technologies et usages, que cela soit en terme de signalisation, de poste d’aiguillage, ou d’usage des données

                                        En particulier, certaines subtilités propres aux systèmes pratiques ont été sacrifiées sur l’autel de la compatibilité et de l’interprétabilité:

                                        • un signal doit forcément s’addresser à un train en particulier: les signaux n’ont pas d’aspect par défaut; ils n’existent que pour être vus
                                        • les itinéraires / routes sont formées à destination d’un train en particulier

                                        Ce document est une description du modèle de fonctionnement cible d’OSRD. Il a pour objectif de renseigner développeurs et experts métiers sur le fonctionnement du simulateur. Des changements y sont apportés au fil de l’évolution du projet.

                                        Ce modèle est en cours d’implémentation

                                        Architecture

                                        flowchart TD
@@ -305,4 +305,4 @@
 Mais pour la même raison, ajouter ce critère rend STDCM
 inutilisable sur les infrastructures générées.
 Plus de détails dans
-cette issue.

                                        3 - APIs

                                        Spécifications des interfaces de programmation

                                        Le format utilisé pour décrire une infrastructure ferroviaire est RailJSON, il est décrit dans son schéma JSON.

                                        Ci-dessous se trouve une liste des APIs REST implémentées par OSRD.

                                        3.1 - Editoast

                                        3.2 - Gateway

                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +cette issue.

                                        3 - APIs

                                        Spécifications des interfaces de programmation

                                        Le format utilisé pour décrire une infrastructure ferroviaire est RailJSON, il est décrit dans son schéma JSON.

                                        Ci-dessous se trouve une liste des APIs REST implémentées par OSRD.

                                        3.1 - Editoast

                                        3.2 - Gateway

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/apis/_print/index.html b/fr/docs/reference/apis/_print/index.html index 32776af07..260921caa 100644 --- a/fr/docs/reference/apis/_print/index.html +++ b/fr/docs/reference/apis/_print/index.html @@ -1,3 +1,3 @@ APIs | OSRD -

                                        Version imprimable multipages. -Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        APIs

                                        Spécifications des interfaces de programmation

                                        Le format utilisé pour décrire une infrastructure ferroviaire est RailJSON, il est décrit dans son schéma JSON.

                                        Ci-dessous se trouve une liste des APIs REST implémentées par OSRD.

                                        1 - Editoast

                                        2 - Gateway

                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +

                                        Version imprimable multipages. +Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        APIs

                                        Spécifications des interfaces de programmation

                                        Le format utilisé pour décrire une infrastructure ferroviaire est RailJSON, il est décrit dans son schéma JSON.

                                        Ci-dessous se trouve une liste des APIs REST implémentées par OSRD.

                                        1 - Editoast

                                        2 - Gateway

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/apis/index.html b/fr/docs/reference/apis/index.html index 81d1e7fad..3fc8921fc 100644 --- a/fr/docs/reference/apis/index.html +++ b/fr/docs/reference/apis/index.html @@ -1,5 +1,5 @@ APIs | OSRD -

                                        APIs

                                        Spécifications des interfaces de programmation

                                        Le format utilisé pour décrire une infrastructure ferroviaire est RailJSON, il est décrit dans son schéma JSON.

                                        Ci-dessous se trouve une liste des APIs REST implémentées par OSRD.

                                        Editoast

                                        Gateway

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/architecture/_print/index.html b/fr/docs/reference/architecture/_print/index.html index 3de98c304..e73e382b3 100644 --- a/fr/docs/reference/architecture/_print/index.html +++ b/fr/docs/reference/architecture/_print/index.html @@ -1,3 +1,3 @@ Architecture | OSRD -

                                        Version imprimable multipages. -Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Architecture

                                        Détails lié à l’architecture de OSRD

                                        Les documents d’architecture permettent de comprendre comment OSRD fonctionne globalement.

                                        1 - Flux des données

                                        Schéma des flux des données d’osrd

                                        Data-flow diagram

                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +

                                        Version imprimable multipages. +Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Architecture

                                        Détails lié à l’architecture de OSRD

                                        Les documents d’architecture permettent de comprendre comment OSRD fonctionne globalement.

                                        1 - Flux des données

                                        Schéma des flux des données d’osrd

                                        Data-flow diagram

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/architecture/data_flow/index.html b/fr/docs/reference/architecture/data_flow/index.html index 605ebce7c..26a3c1d8b 100644 --- a/fr/docs/reference/architecture/data_flow/index.html +++ b/fr/docs/reference/architecture/data_flow/index.html @@ -1,5 +1,5 @@ Flux des données | OSRD -

                                        Flux des données

                                        Schéma des flux des données d’osrd

                                        Data-flow diagram

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/architecture/index.html b/fr/docs/reference/architecture/index.html index 087bb607d..fde2a6e16 100644 --- a/fr/docs/reference/architecture/index.html +++ b/fr/docs/reference/architecture/index.html @@ -1,5 +1,5 @@ Architecture | OSRD -

                                        Architecture

                                        Détails lié à l’architecture de OSRD

                                        Les documents d’architecture permettent de comprendre comment OSRD fonctionne globalement.

                                        Flux des données

                                        Schéma des flux des données d’osrd

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/_print/index.html b/fr/docs/reference/design-docs/_print/index.html index d7e95768d..73dad90e1 100644 --- a/fr/docs/reference/design-docs/_print/index.html +++ b/fr/docs/reference/design-docs/_print/index.html @@ -1,5 +1,5 @@ Documents de conception | OSRD -

                                        Version imprimable multipages. +

                                        Version imprimable multipages. Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Documents de conception

                                        Détails liés à la conceptions de solutions techniques

                                        Les documents de conceptions décrivent comment et pourquoi un composant logiciel a été conçu, de l’exposition du problème à la solution technique, en passant par le chemin pris pour y arriver.

                                        1 - Poste d'aiguillage

                                        Décrit le fonctionnement du poste d’aiguillage virtuel

                                        Le modèle de simulation définit le rôle et comportement des différents objets simulés au sein d’OSRD.

                                        Cette modélisation est un compromis entre de multiples enjeux:

                                        • fidélité de la simulation
                                        • interprétabilité des résultats
                                        • adaptabilité du modèle à différentes technologies et usages, que cela soit en terme de signalisation, de poste d’aiguillage, ou d’usage des données

                                        En particulier, certaines subtilités propres aux systèmes pratiques ont été sacrifiées sur l’autel de la compatibilité et de l’interprétabilité:

                                        • un signal doit forcément s’addresser à un train en particulier: les signaux n’ont pas d’aspect par défaut; ils n’existent que pour être vus
                                        • les itinéraires / routes sont formées à destination d’un train en particulier

                                        Ce document est une description du modèle de fonctionnement cible d’OSRD. Il a pour objectif de renseigner développeurs et experts métiers sur le fonctionnement du simulateur. Des changements y sont apportés au fil de l’évolution du projet.

                                        Ce modèle est en cours d’implémentation

                                        Architecture

                                        flowchart TD
@@ -305,4 +305,4 @@
 Mais pour la même raison, ajouter ce critère rend STDCM
 inutilisable sur les infrastructures générées.
 Plus de détails dans
-cette issue.
                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +cette issue.

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/index.html b/fr/docs/reference/design-docs/index.html index a46c7eac7..8c0f093c9 100644 --- a/fr/docs/reference/design-docs/index.html +++ b/fr/docs/reference/design-docs/index.html @@ -1,5 +1,5 @@ Documents de conception | OSRD -

                                        Documents de conception

                                        Détails liés à la conceptions de solutions techniques

                                        Les documents de conceptions décrivent comment et pourquoi un composant logiciel a été conçu, de l’exposition du problème à la solution technique, en passant par le chemin pris pour y arriver.

                                        Poste d'aiguillage

                                        Décrit le fonctionnement du poste d’aiguillage virtuel

                                        Recherche de sillons de dernière minute (STDCM)

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/interlocking/_print/index.html b/fr/docs/reference/design-docs/interlocking/_print/index.html index 7cbcbcd33..38bc3b22a 100644 --- a/fr/docs/reference/design-docs/interlocking/_print/index.html +++ b/fr/docs/reference/design-docs/interlocking/_print/index.html @@ -1,5 +1,5 @@ Poste d'aiguillage | OSRD -

                                        Version imprimable multipages. +

                                        Version imprimable multipages. Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Poste d'aiguillage

                                        Décrit le fonctionnement du poste d’aiguillage virtuel

                                        Le modèle de simulation définit le rôle et comportement des différents objets simulés au sein d’OSRD.

                                        Cette modélisation est un compromis entre de multiples enjeux:

                                        • fidélité de la simulation
                                        • interprétabilité des résultats
                                        • adaptabilité du modèle à différentes technologies et usages, que cela soit en terme de signalisation, de poste d’aiguillage, ou d’usage des données

                                        En particulier, certaines subtilités propres aux systèmes pratiques ont été sacrifiées sur l’autel de la compatibilité et de l’interprétabilité:

                                        • un signal doit forcément s’addresser à un train en particulier: les signaux n’ont pas d’aspect par défaut; ils n’existent que pour être vus
                                        • les itinéraires / routes sont formées à destination d’un train en particulier

                                        Ce document est une description du modèle de fonctionnement cible d’OSRD. Il a pour objectif de renseigner développeurs et experts métiers sur le fonctionnement du simulateur. Des changements y sont apportés au fil de l’évolution du projet.

                                        Ce modèle est en cours d’implémentation

                                        Architecture

                                        flowchart TD
@@ -85,4 +85,4 @@
 }

                                        Exigences de conception

                                        • Les zones doivent pouvoir être verrouillées dans une configuration particulière.
                                        • Il doit être possible pour plusieurs routes de partager une réservation de configuration.
                                        • Il doit être possible d’observer l’évolution de statut d’une réservation.
                                        • Il doit être possible de faire évoluer le statut d’une réservation.

                                        Dépendances

                                        • statique les détecteurs qui délimitent chaque zone
                                        • statique les aiguilles dans chaque zone
                                        • dynamique capacité d’observer l’occupation des zones
                                        • dynamique capacité d’actionner les éléments mobiles

                                        Opérations

                                        • espacement: Observer l’état d’une zone
                                        • routage: Verrouiller et déverrouiller la zone : permet d’obtenir un droit d’action. Toutes les opérations en écriture nécessitent d’avoir acquis le verrou.
                                        • routage: Attendre que toutes les réservations d’une zone expirent
                                        • routage: Pré-réserver une configuration de zone
                                        • routage: Confirmer la réservation d’une zone
                                        • routage: Attendre que la réservation de la zone soit occupée par son train
                                        • routage: Relacher une réservation de zone

                                        4 - Routage

                                        Gère le cycle des routes

                                        Description

                                        • Les routes ont pour responsabilité d’autoriser le déplacement des trains dans l’infrastructure. Elles doivent se terminer à un point où l’arrêt du train est prévu (en terme de signalisation, pas voyageur).
                                        • Les routes sont assimilables à des itinéraires, ou à des suites d’itinéraires et d’installations de pleine voie.
                                        • Les routes n’ont pas de lien direct avec le cantonnement et la signalisation. Elles nourrissent des informations sur la disponibilité des voies qui sont utilisées par le cantonnement et la signalisation.
                                        • Une route est un chemin de détecteur en détecteur. Elle représente une portion de chemin qu’il est sûr pour un train d’emprunter.
                                        • Les routes ont des points de libération, qui sont des détecteurs qui délimitent quand détruire l’itinéraire, ce qui permet d’implémenter transit souple, rigide, et entre-deux.
                                        • Une route peut être à nouveau formée alors qu’un train est déjà en train de la parcourir. Cela permet à plusieurs trains de se suivre sur la même route.

                                        Cycle de vie d’une route

                                        Les routes n’ont pas d’état, mais leur commande donne lieu à une suite d’événements systématique :

                                        • le système commande toutes les routes sur le trajet du train dans l’ordre, sans attendre
                                          • la commande doit être acceptée par le régulateur
                                        • lorsque le régulateur accepte la commande, la formation commence
                                          • le droit d’action de chaque zone de la route est acquis, selon un ordre global
                                          • en parallèle pour toutes les zones:
                                            • si la zone n’est pas dans la configuration souhaitée:
                                              • si elle est déjà réservée, attendre que les réservations expirent
                                              • sinon, la mettre dans la configuration souhaitée en déplaçant les aiguilles
                                            • pré-réserver la zone pour le passage du train
                                            • le droit d’action de la zone est cédé
                                        • une fois que la formation est terminée, la route est établie
                                          • pour chaque zone, transformer la pré-réservation du train en réservation
                                        • dès que la route est établie, un processus de destruction de la route commence
                                          • pour chaque zone de la route donnant lieu à une libération
                                            • attendre que le train quitte la zone (que la réservation passe de l’état OCCUPIED à l’état PENDING_RELEASE)
                                            • libérer la réservation des zones du début de la route jusqu’à la zone actuelle

                                        Exigences de conception

                                        Le système doit, indirectement ou directement:

                                        • permettre à la signalisation de déterminer si une section de voie est prête à être empruntée.
                                        • permettre l’ordonnancement des trains selon des critères configurables.
                                        • permettre la destruction progressive (transit souple) de l’itinéraire après le passage du train.
                                        • il doit être possible d’avoir plusieurs processus de commande actifs au même moment pour la même route, afin de supporter des trains qui se suivent

                                        Dépendances

                                        • statique le chemin des routes de détecteur à détecteur

                                        • statique la position requise des aiguilles, par zone

                                        • statique les points de libération des zones (qui implémentent le transit souple / rigide)

                                        • dynamique régulateur soumettre des commandes

                                        • dynamique réservation acquérir et relacher un droit d’action par zone

                                        • dynamique réservation attendre que les réservations d’une zone expirent

                                        • dynamique éléments mobiles déplacer des aiguilles

                                        • dynamique réservation pré-réserver une zone

                                        • dynamique réservation promouvoir une pré-réservation en réservation

                                        • dynamique réservation lors de la destruction de la route, attendre qu’une réservation passe en PENDING_RELEASE

                                        • dynamique réservation libérer une réservation

                                        Opérations

                                        • commander une route: démarre un processus asynchrone qui ne se terminera que lorsque la route aura été établie. Un processus de destruction doit démarrer dès que la route est établie.

                                        Notes de conception

                                        Ces notes permettent d’expliquer les décisions qui ont été prises, afin de pouvoir plus aisément les comprendre et évoluer.

                                        Informer la signalisation

                                        Sachant que:

                                        • il peut y avoir beaucoup de zones partant d’un même point, il est préférable d’éviter de contraindre les signaux à observer une liste de routes
                                        • il est potentiellement difficile d’associer un état clair à chaque route

                                        Il en ressort plusieurs manières d’informer la signalisation de la navigabilité des voies:

                                        • soit directement, en faisant observer à la signalisation les points d’entrée des routes. Si plusieurs routes partent du même endroit, elles partageraient un objet entrée:
                                          • moins de complexité dans la couche de réservation, plus de complexité dans la couche de routage
                                        • soit indirectement, via la couche de réservation des zones, qui auraient un état supplémentaire pour marquer leur navigabilité:
                                          • moins de complexité dans la couche de routage, plus de complexité dans la couche de réservation
                                          • avantage le processus d’activation des routes n’aurait pas besoin d’attendre l’arrivée du train, la couche de réservation s’en occuperait.
                                          • avantage découplage entre routage et cantonnement / signalisation.

                                        La seconde option a été choisie, car :

                                        • elle permet d’avoir un couplage moins fort entre la signalisation et les routes.
                                        • elle évite aussi au processus d’activation des routes d’attendre le passage du train alors que la couche de réservation le fait déjà.

                                        Cycle de vie des routes et état des zones

                                        Plusieurs enjeux motivent le cycle de vie des routes et l’état des zones :

                                        • d’une part, l’état des zones est au coeur de la détection de conflit : il doit être possible d’extraire d’une simulation d’un train seul ses besoins en ressources
                                        • d’autre part, il faut qu’une simulation multi-train fonctionne correctement : le temps de déplacement des aiguilles selon la configuration actuellement en place, en particulier, est un point de friction important

                                        5 - Ordonnancement

                                        Décide de l’ordre de formation des itinéraires

                                        Définition

                                        La couche d’ordonnancement a pour responsabilité d’établir l’ordre de commande des itinéraires, et par conséquent, l’ordre de passage des trains. La méthode exacte utilisée pour prendre cette décision n’importe pas, du moment qu’elle garantit que la simulation se termine (elle ne doit pas amener de trains en nez-à-nez, ou créer d’autres cas de figure de blocage).

                                        Il est possible d’implémenter un module d’ordonnancement via des tableaux d’ordre de succession des trains aux aiguilles.

                                        Exigences de conception

                                        • Il doit être possible de connecter n’importe quel algorithme d’ordonnancement
                                        • Le module d’ordonnancement doit approuver les commandes de routes.

                                        Opérations

                                        • train: Des itinéraires sont commandés pour chaque trains, aussi loin et aussi tôt que possible. L’approbation de la commande est soumise au régulateur, qui peut la retarder indéfiniment, selon des critères de son choix.

                                        6 - Train

                                        Représente un train dans la simulation

                                        Description

                                        Les contraintes sur ce qu’est un train sont relativement faibles. -Il doit seulement avoir un identifiant, qui permet aux autres systèmes de garder des références vers des trains.

                                        Exigences de conception

                                        • Les trains occupent les zones.
                                        • Les trains doivent être suivis pour préserver leur ordre de passage.
                                        • Les trains ont pour responsabilité de demander les itinéraires devant eux.
                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +Il doit seulement avoir un identifiant, qui permet aux autres systèmes de garder des références vers des trains.

                                        Exigences de conception

                                        • Les trains occupent les zones.
                                        • Les trains doivent être suivis pour préserver leur ordre de passage.
                                        • Les trains ont pour responsabilité de demander les itinéraires devant eux.
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/interlocking/index.html b/fr/docs/reference/design-docs/interlocking/index.html index 34f28a203..4302a8270 100644 --- a/fr/docs/reference/design-docs/interlocking/index.html +++ b/fr/docs/reference/design-docs/interlocking/index.html @@ -1,5 +1,5 @@ Poste d'aiguillage | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/interlocking/location/index.html b/fr/docs/reference/design-docs/interlocking/location/index.html index 1fa0c2508..26fa986bd 100644 --- a/fr/docs/reference/design-docs/interlocking/location/index.html +++ b/fr/docs/reference/design-docs/interlocking/location/index.html @@ -1,5 +1,5 @@ Localisation | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/interlocking/movable-elements/index.html b/fr/docs/reference/design-docs/interlocking/movable-elements/index.html index 6a7ac687b..7bcc97400 100644 --- a/fr/docs/reference/design-docs/interlocking/movable-elements/index.html +++ b/fr/docs/reference/design-docs/interlocking/movable-elements/index.html @@ -1,5 +1,5 @@ Éléments mobiles | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/interlocking/ordering/index.html b/fr/docs/reference/design-docs/interlocking/ordering/index.html index 7bbc77d70..12a933cba 100644 --- a/fr/docs/reference/design-docs/interlocking/ordering/index.html +++ b/fr/docs/reference/design-docs/interlocking/ordering/index.html @@ -1,5 +1,5 @@ Ordonnancement | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/interlocking/reservation/index.html b/fr/docs/reference/design-docs/interlocking/reservation/index.html index 95e610754..989683d85 100644 --- a/fr/docs/reference/design-docs/interlocking/reservation/index.html +++ b/fr/docs/reference/design-docs/interlocking/reservation/index.html @@ -1,5 +1,5 @@ Reservation | OSRD -

                                        Exigences de conception

                                        • Les zones doivent pouvoir être verrouillées dans une configuration particulière.
                                        • Il doit être possible pour plusieurs routes de partager une réservation de configuration.
                                        • Il doit être possible d’observer l’évolution de statut d’une réservation.
                                        • Il doit être possible de faire évoluer le statut d’une réservation.

                                        Dépendances

                                        • statique les détecteurs qui délimitent chaque zone
                                        • statique les aiguilles dans chaque zone
                                        • dynamique capacité d’observer l’occupation des zones
                                        • dynamique capacité d’actionner les éléments mobiles

                                        Opérations

                                        • espacement: Observer l’état d’une zone
                                        • routage: Verrouiller et déverrouiller la zone : permet d’obtenir un droit d’action. Toutes les opérations en écriture nécessitent d’avoir acquis le verrou.
                                        • routage: Attendre que toutes les réservations d’une zone expirent
                                        • routage: Pré-réserver une configuration de zone
                                        • routage: Confirmer la réservation d’une zone
                                        • routage: Attendre que la réservation de la zone soit occupée par son train
                                        • routage: Relacher une réservation de zone
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/interlocking/routing/index.html b/fr/docs/reference/design-docs/interlocking/routing/index.html index 592020f66..0c020f766 100644 --- a/fr/docs/reference/design-docs/interlocking/routing/index.html +++ b/fr/docs/reference/design-docs/interlocking/routing/index.html @@ -1,5 +1,5 @@ Routage | OSRD -

                                        Routage

                                        Gère le cycle des routes

                                        Description

                                        • Les routes ont pour responsabilité d’autoriser le déplacement des trains dans l’infrastructure. Elles doivent se terminer à un point où l’arrêt du train est prévu (en terme de signalisation, pas voyageur).
                                        • Les routes sont assimilables à des itinéraires, ou à des suites d’itinéraires et d’installations de pleine voie.
                                        • Les routes n’ont pas de lien direct avec le cantonnement et la signalisation. Elles nourrissent des informations sur la disponibilité des voies qui sont utilisées par le cantonnement et la signalisation.
                                        • Une route est un chemin de détecteur en détecteur. Elle représente une portion de chemin qu’il est sûr pour un train d’emprunter.
                                        • Les routes ont des points de libération, qui sont des détecteurs qui délimitent quand détruire l’itinéraire, ce qui permet d’implémenter transit souple, rigide, et entre-deux.
                                        • Une route peut être à nouveau formée alors qu’un train est déjà en train de la parcourir. Cela permet à plusieurs trains de se suivre sur la même route.

                                        Cycle de vie d’une route

                                        Les routes n’ont pas d’état, mais leur commande donne lieu à une suite d’événements systématique :

                                        • le système commande toutes les routes sur le trajet du train dans l’ordre, sans attendre
                                          • la commande doit être acceptée par le régulateur
                                        • lorsque le régulateur accepte la commande, la formation commence
                                          • le droit d’action de chaque zone de la route est acquis, selon un ordre global
                                          • en parallèle pour toutes les zones:
                                            • si la zone n’est pas dans la configuration souhaitée:
                                              • si elle est déjà réservée, attendre que les réservations expirent
                                              • sinon, la mettre dans la configuration souhaitée en déplaçant les aiguilles
                                            • pré-réserver la zone pour le passage du train
                                            • le droit d’action de la zone est cédé
                                        • une fois que la formation est terminée, la route est établie
                                          • pour chaque zone, transformer la pré-réservation du train en réservation
                                        • dès que la route est établie, un processus de destruction de la route commence
                                          • pour chaque zone de la route donnant lieu à une libération
                                            • attendre que le train quitte la zone (que la réservation passe de l’état OCCUPIED à l’état PENDING_RELEASE)
                                            • libérer la réservation des zones du début de la route jusqu’à la zone actuelle

                                        Exigences de conception

                                        Le système doit, indirectement ou directement:

                                        • permettre à la signalisation de déterminer si une section de voie est prête à être empruntée.
                                        • permettre l’ordonnancement des trains selon des critères configurables.
                                        • permettre la destruction progressive (transit souple) de l’itinéraire après le passage du train.
                                        • il doit être possible d’avoir plusieurs processus de commande actifs au même moment pour la même route, afin de supporter des trains qui se suivent

                                        Dépendances

                                        • statique le chemin des routes de détecteur à détecteur

                                        • statique la position requise des aiguilles, par zone

                                        • statique les points de libération des zones (qui implémentent le transit souple / rigide)

                                        • dynamique régulateur soumettre des commandes

                                        • dynamique réservation acquérir et relacher un droit d’action par zone

                                        • dynamique réservation attendre que les réservations d’une zone expirent

                                        • dynamique éléments mobiles déplacer des aiguilles

                                        • dynamique réservation pré-réserver une zone

                                        • dynamique réservation promouvoir une pré-réservation en réservation

                                        • dynamique réservation lors de la destruction de la route, attendre qu’une réservation passe en PENDING_RELEASE

                                        • dynamique réservation libérer une réservation

                                        Opérations

                                        • commander une route: démarre un processus asynchrone qui ne se terminera que lorsque la route aura été établie. Un processus de destruction doit démarrer dès que la route est établie.

                                        Notes de conception

                                        Ces notes permettent d’expliquer les décisions qui ont été prises, afin de pouvoir plus aisément les comprendre et évoluer.

                                        Informer la signalisation

                                        Sachant que:

                                        • il peut y avoir beaucoup de zones partant d’un même point, il est préférable d’éviter de contraindre les signaux à observer une liste de routes
                                        • il est potentiellement difficile d’associer un état clair à chaque route

                                        Il en ressort plusieurs manières d’informer la signalisation de la navigabilité des voies:

                                        • soit directement, en faisant observer à la signalisation les points d’entrée des routes. Si plusieurs routes partent du même endroit, elles partageraient un objet entrée:
                                          • moins de complexité dans la couche de réservation, plus de complexité dans la couche de routage
                                        • soit indirectement, via la couche de réservation des zones, qui auraient un état supplémentaire pour marquer leur navigabilité:
                                          • moins de complexité dans la couche de routage, plus de complexité dans la couche de réservation
                                          • avantage le processus d’activation des routes n’aurait pas besoin d’attendre l’arrivée du train, la couche de réservation s’en occuperait.
                                          • avantage découplage entre routage et cantonnement / signalisation.

                                        La seconde option a été choisie, car :

                                        • elle permet d’avoir un couplage moins fort entre la signalisation et les routes.
                                        • elle évite aussi au processus d’activation des routes d’attendre le passage du train alors que la couche de réservation le fait déjà.

                                        Cycle de vie des routes et état des zones

                                        Plusieurs enjeux motivent le cycle de vie des routes et l’état des zones :

                                        • d’une part, l’état des zones est au coeur de la détection de conflit : il doit être possible d’extraire d’une simulation d’un train seul ses besoins en ressources
                                        • d’autre part, il faut qu’une simulation multi-train fonctionne correctement : le temps de déplacement des aiguilles selon la configuration actuellement en place, en particulier, est un point de friction important
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/interlocking/train/index.html b/fr/docs/reference/design-docs/interlocking/train/index.html index 8d2139987..7347f379d 100644 --- a/fr/docs/reference/design-docs/interlocking/train/index.html +++ b/fr/docs/reference/design-docs/interlocking/train/index.html @@ -1,5 +1,5 @@ Train | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/_print/index.html b/fr/docs/reference/design-docs/stdcm/_print/index.html index 3318dd1cb..d2a14c097 100644 --- a/fr/docs/reference/design-docs/stdcm/_print/index.html +++ b/fr/docs/reference/design-docs/stdcm/_print/index.html @@ -1,5 +1,5 @@ Recherche de sillons de dernière minute (STDCM) | OSRD -

                                        Version imprimable multipages. +

                                        Version imprimable multipages. Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Recherche de sillons de dernière minute (STDCM)

                                        OSRD permet d’ajouter un nouveau train dans une grille horaire déjà établie, sans générer aucun conflit avec les autres trains. L’application directe de cette fonctionnalité est appelée la recherche de sillon de dernière minute.

                                        L’acronyme STDCM (Short Term Digital Capacity Management) est utilisé @@ -220,4 +220,4 @@ Mais pour la même raison, ajouter ce critère rend STDCM inutilisable sur les infrastructures générées. Plus de détails dans -cette issue.

                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +cette issue.

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/domain_context/index.html b/fr/docs/reference/design-docs/stdcm/domain_context/index.html index 930682f66..ef5e13192 100644 --- a/fr/docs/reference/design-docs/stdcm/domain_context/index.html +++ b/fr/docs/reference/design-docs/stdcm/domain_context/index.html @@ -11,7 +11,7 @@ On peut la représenter sur un graphique, avec le temps en abscisse et la distance parcourue sur un chemin en ordonnée.">
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/index.html b/fr/docs/reference/design-docs/stdcm/index.html index d2e0a2767..0ef73fb4e 100644 --- a/fr/docs/reference/design-docs/stdcm/index.html +++ b/fr/docs/reference/design-docs/stdcm/index.html @@ -1,5 +1,5 @@ Recherche de sillons de dernière minute (STDCM) | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/_print/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/_print/index.html index 910d502ef..dccf7e1a9 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/_print/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/_print/index.html @@ -1,5 +1,5 @@ Module de recherche de sillons | OSRD -

                                        Version imprimable multipages. +

                                        Version imprimable multipages. Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Module de recherche de sillons

                                        Ce module gère la recherche de solution.

                                        Les entrées et sorties sont fortement simplifiées et abstraites pour simplifier le problème au maximum et permettre des tests efficaces.

                                        Pour décrire son fonctionnement en quelques phrases : l’espace de solutions est représenté sous forme d’un graphe qui encode le temps, @@ -187,4 +187,4 @@ Mais pour la même raison, ajouter ce critère rend STDCM inutilisable sur les infrastructures générées. Plus de détails dans -cette issue.

                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +cette issue.

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/index.html index d84f0e793..be91ab3f3 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/index.html @@ -3,7 +3,7 @@ Cet exemple illustre le problème : par défaut la première arête est explorée en allant à la vitesse maximale.">
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/index.html index ce6aa1a13..1cbd55cf6 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/index.html @@ -3,7 +3,7 @@ Décalage du temps de départ Dans les paramètres de l&rsquo;algorithme, le temps de départ est donné sous la forme d&rsquo;une fenêtre : un temps de départ au plus tôt et au plus tard. Tant que c&rsquo;est possible, il est toujours préférable de décaler le temps de départ pour éviter les conflits.">
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/index.html index 69c18c8cb..136ac7c0d 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/index.html @@ -3,7 +3,7 @@ La documentation (en anglais seulement) de la détection de conflits explique comment elle est réalisée en interne. Pour résumer, un train est en conflit avec un autre quand il observe un signal lui indiquant de ralentir. Dans notre cas, une solution où cette situation se produit est considérée comme invalide, le train doit arriver au signal donné plus tard (ou plus tôt) quand le signal n&rsquo;est plus contraignant.">
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/index.html index aea1b328f..e2a17b87b 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/index.html @@ -7,7 +7,7 @@ Le graphe produit de la position, du temps, et de la vitesse est utilisé. Autrement dit, chaque élément du graphe contient (entre autres) ces 3 variables. Chaque arête du graphe est calculée avec un calcul de marche pour connaître l’évolution de la vitesse et de la position dans le temps.">
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/index.html index 1c1bf1968..e67542fb1 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/index.html @@ -3,7 +3,7 @@ STDCMEdgeBuilder Cette classe est utilisée pour simplifier la création d&rsquo;instances de STDCMEdge, les arêtes du graphe. Celles-ci contiennent de nombreux attributs, la plupart pouvant être déterminés en fonction du contexte (comme le nœud précédent). La classe STDCMEdgeBuilder permet de rendre certains attributs optionnels et en calcule d&rsquo;autres.">
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/index.html index 2a83a5af7..5935c8564 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/index.html @@ -1,5 +1,5 @@ Module de recherche de sillons | OSRD -
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/index.html index 30e7edaa8..de1bfe483 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/index.html @@ -7,7 +7,7 @@ On a besoin d’une manière de définir et d’énumérer les différents chemins possibles et de parcourir l’infrastructure, avec plusieurs contraintes : Le chemin doit être compatible avec le matériel roulant donné (électrification, gabarit, systèmes de signalisation) À n’importe quel point, on doit être en mesure d’accéder aux propriétés du chemin depuis le point de départ jusqu’au point considéré.">
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/index.html b/fr/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/index.html index 4a105fabf..acb6f27bf 100644 --- a/fr/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/index.html +++ b/fr/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/index.html @@ -3,7 +3,7 @@ Par exemple : l&rsquo;utilisateur peut indiquer une marge de 5 minutes au 100km. Sur un trajet de 42km, un trajet de 10 minutes au plus rapide doit maintenant durer 12 minutes et 6 secondes.">
                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/docs/reference/index.html b/fr/docs/reference/index.html index c3308d8d3..559bc87d4 100644 --- a/fr/docs/reference/index.html +++ b/fr/docs/reference/index.html @@ -1,5 +1,5 @@ Référence technique | OSRD -

                                        Référence technique

                                        Machinerie interne et APIs

                                        Les guides de référence technique contiennent des références techniques pour les API et autres aspects de la machinerie OSRD. Ils présentent son fonctionnement et la manière de l’exploiter en partant du principe que les concepts clés de base sont maîtrisés.

                                        Architecture

                                        Détails lié à l’architecture de OSRD

                                        Documents de conception

                                        Détails liés à la conceptions de solutions techniques

                                        APIs

                                        Spécifications des interfaces de programmation

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/index.html b/fr/index.html index 5bb084bf4..bd2acb090 100644 --- a/fr/index.html +++ b/fr/index.html @@ -1,5 +1,5 @@ OSRD -

                                        Open Source Railway Designer

                                        À propos +

                                        Open Source Railway Designer

                                        À propos Github

                                        Une application web, open source, de conception d'infrastructure ferroviaire, d'horaires, d'analyse de capacité et bien plus !

                                        Conception ferroviaire

                                        		Modifiez l’infrastructure ferroviaire et les grilles horaires

                                        Analyse de capacité

                                        		Détectez les conflits et visualisez la capacité
@@ -11,4 +11,4 @@

                                        Sponsors

                                        Ministère chargé des Transports European Union -SNCF Réseau

                                        © 2024 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file +SNCF Réseau

                                        © 2025 Contributeurs à OSRD. Tous droits réservés
                                        \ No newline at end of file diff --git a/fr/join-us/_print/index.html b/fr/join-us/_print/index.html index f93741213..76e1d6cb6 100644 --- a/fr/join-us/_print/index.html +++ b/fr/join-us/_print/index.html @@ -1,3 +1,3 @@ Rejoignez-nous | OSRD -

                                        Version imprimable multipages. -Cliquer ici pour imprimer.

                                        Retour à la version par défaut.

                                        Rejoignez-nous

                                          L’équipe dédiée à OSRD au sein de SNCF Réseau est toujours intéressée par de nouveaux profils : si travailler sur le projet vous motive, envoyez-nous un message sur contact@osrd.fr !

                                          © 2024 Contributeurs à OSRD. Tous droits réservés
                                          \ No newline at end of file +

                                          Version imprimable multipages. +Cliquer ici pour imprimer.

                                          Retour à la version par défaut.

                                          Rejoignez-nous

                                            L’équipe dédiée à OSRD au sein de SNCF Réseau est toujours intéressée par de nouveaux profils : si travailler sur le projet vous motive, envoyez-nous un message sur contact@osrd.fr !

                                            © 2025 Contributeurs à OSRD. Tous droits réservés
                                            \ No newline at end of file diff --git a/fr/join-us/index.html b/fr/join-us/index.html index 7b236f35d..597c04f41 100644 --- a/fr/join-us/index.html +++ b/fr/join-us/index.html @@ -1,7 +1,7 @@ Rejoignez-nous | OSRD -

                                            Rejoignez-nous

                                            L’équipe dédiée à OSRD au sein de SNCF Réseau est toujours intéressée par de nouveaux profils : si travailler sur le projet vous motive, envoyez-nous un message sur contact@osrd.fr !

                                            © 2025 Contributeurs à OSRD. Tous droits réservés
                                            \ No newline at end of file diff --git a/fr/search/index.html b/fr/search/index.html index 41141f400..ffb12f646 100644 --- a/fr/search/index.html +++ b/fr/search/index.html @@ -1,2 +1,2 @@ Search Results | OSRD -

                                            Search Results

                                            © 2024 Contributeurs à OSRD. Tous droits réservés
                                            \ No newline at end of file +

                                            Search Results

                                            © 2025 Contributeurs à OSRD. Tous droits réservés
                                            \ No newline at end of file diff --git a/fr/sitemap.xml b/fr/sitemap.xml index 63195f6c1..3c12d04b0 100644 --- a/fr/sitemap.xml +++ b/fr/sitemap.xml @@ -1 +1 @@ -https://osrd.fr/fr/docs/guides/contribute/preamble/https://osrd.fr/fr/docs/guides/contribute/contribute-code/general-principles/https://osrd.fr/fr/docs/guides/contribute/contribute-code/backend-conventions/https://osrd.fr/fr/docs/guides/contribute/contribute-code/frontend-conventions/https://osrd.fr/fr/docs/guides/contribute/license-and-set-up/https://osrd.fr/fr/docs/guides/contribute/contribute-code/https://osrd.fr/fr/docs/guides/contribute/contribute-code/write-code/https://osrd.fr/fr/docs/guides/contribute/contribute-code/commit-conventions/https://osrd.fr/fr/docs/guides/contribute/code-review/https://osrd.fr/fr/docs/guides/contribute/contribute-code/share-changes/https://osrd.fr/fr/docs/guides/contribute/bug-reports/https://osrd.fr/fr/docs/guides/contribute/contribute-code/tests/https://osrd.fr/fr/docs/reference/design-docs/stdcm/domain_context/https://osrd.fr/fr/docs/explanation/running_time_calculation/physical_modeling/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/https://osrd.fr/fr/docs/explanation/containers-architecture/https://osrd.fr/fr/docs/guides/deploy/stdcm-search-env/https://osrd.fr/fr/docs/guides/contribute/https://osrd.fr/fr/docs/guides/deploy/https://osrd.fr/fr/docs/guides/deploy/docker-compose/https://osrd.fr/fr/docs/reference/design-docs/interlocking/movable-elements/https://osrd.fr/fr/docs/guides/deploy/kubernetes/https://osrd.fr/fr/docs/guides/design/https://osrd.fr/fr/docs/guides/logo/https://osrd.fr/fr/docs/guides/contribute/install-docker/https://osrd.fr/fr/blog/news/2023-12-13T00:00:00+00:00https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/https://osrd.fr/fr/docs/explanation/running_time_calculation/numerical_integration/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/https://osrd.fr/fr/docs/explanation/models/data-models-full-example/https://osrd.fr/fr/docs/explanation/https://osrd.fr/fr/docs/reference/design-docs/interlocking/location/https://osrd.fr/fr/docs/explanation/models/https://osrd.fr/fr/docs/explanation/models/neutral_sections/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/https://osrd.fr/fr/docs/explanation/running_time_calculation/envelopes_system/https://osrd.fr/fr/docs/explanation/running_time_calculation/https://osrd.fr/fr/docs/https://osrd.fr/fr/docs/guides/https://osrd.fr/fr/docs/reference/design-docs/interlocking/reservation/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/https://osrd.fr/fr/docs/explanation/running_time_calculation/pipeline/https://osrd.fr/fr/docs/reference/architecture/https://osrd.fr/fr/docs/reference/design-docs/https://osrd.fr/fr/about/governance/https://osrd.fr/fr/docs/explanation/netzgrafik-editor/https://osrd.fr/fr/docs/reference/design-docs/interlocking/https://osrd.fr/fr/docs/reference/https://osrd.fr/fr/docs/reference/design-docs/interlocking/routing/https://osrd.fr/fr/docs/reference/architecture/data_flow/https://osrd.fr/fr/docs/explanation/running_time_calculation/allowances/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/https://osrd.fr/fr/docs/reference/design-docs/stdcm/https://osrd.fr/fr/docs/reference/design-docs/interlocking/ordering/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/https://osrd.fr/fr/docs/reference/apis/https://osrd.fr/fr/about/use-case/https://osrd.fr/fr/docs/railway-wiki/https://osrd.fr/fr/docs/reference/design-docs/interlocking/train/https://osrd.fr/fr/docs/railway-wiki/glossary/https://osrd.fr/fr/about/opensource/https://osrd.fr/fr/docs/railway-wiki/signalling/https://osrd.fr/fr/about/opendata/https://osrd.fr/fr/about/roadmap/https://osrd.fr/fr/docs/railway-wiki/signalling/risks/https://osrd.fr/fr/docs/railway-wiki/signalling/signals/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/etcs/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-direction-installations/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/gsm-r/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-simplified-signalling/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track-of-permanent-nature/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/frmcs/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-track-movement/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-shuttle/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/etml/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-two-ways/https://osrd.fr/fr/blog/2023-12-13T00:00:00+00:00https://osrd.fr/fr/2023-12-13T00:00:00+00:00https://osrd.fr/fr/blog/2023/12/13/presentation-osrd-1/2023-12-13T00:00:00+00:00https://osrd.fr/fr/blog/2023/07/19/osrd-au-dreil%C3%A4nder-hack-%C3%A0-vienne/2023-07-19T00:00:00+00:00https://osrd.fr/fr/blog/2023/04/24/ia5-et-pip6-avril-2023/2023-04-24T00:00:00+00:00https://osrd.fr/fr/blog/2023/04/12/forum-dgex-solutions/2023-04-12T00:00:00+00:00https://osrd.fr/fr/blog/2023/04/12/forum-dgex-solutions/2023-04-12T00:00:00+00:00https://osrd.fr/fr/blog/2023/02/13/ia-et-pip-4-f%C3%A9vrier-2023/2023-02-13T00:00:00+00:00https://osrd.fr/fr/blog/2023/02/06/fosdem-2023-osrd-%C3%A9tait-pr%C3%A9sent/2023-02-06T00:00:00+00:00https://osrd.fr/fr/docs/guides/contribute/review-process/https://osrd.fr/fr/about/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bal/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bapr/https://osrd.fr/fr/categories/https://osrd.fr/fr/docs/reference/apis/editoast/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/https://osrd.fr/fr/docs/reference/apis/gateway/https://osrd.fr/fr/join-us/https://osrd.fr/fr/search/https://osrd.fr/fr/tags/ \ No newline at end of file +https://osrd.fr/fr/docs/guides/contribute/preamble/https://osrd.fr/fr/docs/guides/contribute/contribute-code/general-principles/https://osrd.fr/fr/docs/guides/release/process/https://osrd.fr/fr/docs/guides/contribute/contribute-code/backend-conventions/https://osrd.fr/fr/docs/guides/contribute/contribute-code/frontend-conventions/https://osrd.fr/fr/docs/guides/contribute/license-and-set-up/https://osrd.fr/fr/docs/guides/release/publish/https://osrd.fr/fr/docs/guides/contribute/contribute-code/https://osrd.fr/fr/docs/guides/contribute/contribute-code/write-code/https://osrd.fr/fr/docs/guides/contribute/contribute-code/commit-conventions/https://osrd.fr/fr/docs/guides/contribute/code-review/https://osrd.fr/fr/docs/guides/contribute/contribute-code/share-changes/https://osrd.fr/fr/docs/guides/contribute/bug-reports/https://osrd.fr/fr/docs/guides/contribute/contribute-code/tests/https://osrd.fr/fr/docs/reference/design-docs/stdcm/domain_context/https://osrd.fr/fr/docs/explanation/running_time_calculation/physical_modeling/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/https://osrd.fr/fr/docs/explanation/containers-architecture/https://osrd.fr/fr/docs/guides/deploy/stdcm-search-env/https://osrd.fr/fr/docs/guides/contribute/https://osrd.fr/fr/docs/guides/deploy/https://osrd.fr/fr/docs/guides/deploy/docker-compose/https://osrd.fr/fr/docs/reference/design-docs/interlocking/movable-elements/https://osrd.fr/fr/docs/guides/deploy/kubernetes/https://osrd.fr/fr/docs/guides/design/https://osrd.fr/fr/docs/guides/logo/https://osrd.fr/fr/docs/guides/release/https://osrd.fr/fr/docs/guides/contribute/install-docker/https://osrd.fr/fr/blog/news/2023-12-13T00:00:00+00:00https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/https://osrd.fr/fr/docs/explanation/running_time_calculation/numerical_integration/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/https://osrd.fr/fr/docs/explanation/models/data-models-full-example/https://osrd.fr/fr/docs/explanation/https://osrd.fr/fr/docs/reference/design-docs/interlocking/location/https://osrd.fr/fr/docs/explanation/models/https://osrd.fr/fr/docs/explanation/models/neutral_sections/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/https://osrd.fr/fr/docs/explanation/running_time_calculation/envelopes_system/https://osrd.fr/fr/docs/explanation/running_time_calculation/https://osrd.fr/fr/docs/https://osrd.fr/fr/docs/guides/https://osrd.fr/fr/docs/reference/design-docs/interlocking/reservation/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/https://osrd.fr/fr/docs/explanation/running_time_calculation/pipeline/https://osrd.fr/fr/docs/reference/architecture/https://osrd.fr/fr/docs/reference/design-docs/https://osrd.fr/fr/about/governance/https://osrd.fr/fr/docs/explanation/netzgrafik-editor/https://osrd.fr/fr/docs/reference/design-docs/interlocking/https://osrd.fr/fr/docs/reference/https://osrd.fr/fr/docs/reference/design-docs/interlocking/routing/https://osrd.fr/fr/docs/reference/architecture/data_flow/https://osrd.fr/fr/docs/explanation/running_time_calculation/allowances/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/https://osrd.fr/fr/docs/reference/design-docs/stdcm/https://osrd.fr/fr/docs/reference/design-docs/interlocking/ordering/https://osrd.fr/fr/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/https://osrd.fr/fr/docs/reference/apis/https://osrd.fr/fr/about/use-case/https://osrd.fr/fr/docs/railway-wiki/https://osrd.fr/fr/docs/reference/design-docs/interlocking/train/https://osrd.fr/fr/docs/railway-wiki/glossary/https://osrd.fr/fr/about/opensource/https://osrd.fr/fr/docs/railway-wiki/signalling/https://osrd.fr/fr/about/opendata/https://osrd.fr/fr/about/roadmap/https://osrd.fr/fr/docs/railway-wiki/signalling/risks/https://osrd.fr/fr/docs/railway-wiki/signalling/signals/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/etcs/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-direction-installations/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/gsm-r/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-simplified-signalling/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track-of-permanent-nature/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/frmcs/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-track-movement/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-shuttle/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/etml/https://osrd.fr/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-two-ways/https://osrd.fr/fr/blog/2023-12-13T00:00:00+00:00https://osrd.fr/fr/2023-12-13T00:00:00+00:00https://osrd.fr/fr/blog/2023/12/13/presentation-osrd-1/2023-12-13T00:00:00+00:00https://osrd.fr/fr/blog/2023/07/19/osrd-au-dreil%C3%A4nder-hack-%C3%A0-vienne/2023-07-19T00:00:00+00:00https://osrd.fr/fr/blog/2023/04/24/ia5-et-pip6-avril-2023/2023-04-24T00:00:00+00:00https://osrd.fr/fr/blog/2023/04/12/forum-dgex-solutions/2023-04-12T00:00:00+00:00https://osrd.fr/fr/blog/2023/04/12/forum-dgex-solutions/2023-04-12T00:00:00+00:00https://osrd.fr/fr/blog/2023/02/13/ia-et-pip-4-f%C3%A9vrier-2023/2023-02-13T00:00:00+00:00https://osrd.fr/fr/blog/2023/02/06/fosdem-2023-osrd-%C3%A9tait-pr%C3%A9sent/2023-02-06T00:00:00+00:00https://osrd.fr/fr/docs/guides/contribute/review-process/https://osrd.fr/fr/about/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bal/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bapr/https://osrd.fr/fr/categories/https://osrd.fr/fr/docs/reference/apis/editoast/https://osrd.fr/fr/docs/railway-wiki/signalling/spacing/ertms/https://osrd.fr/fr/docs/reference/apis/gateway/https://osrd.fr/fr/join-us/https://osrd.fr/fr/search/https://osrd.fr/fr/tags/ \ No newline at end of file diff --git a/fr/tags/index.html b/fr/tags/index.html index 035f46966..d47f348d6 100644 --- a/fr/tags/index.html +++ b/fr/tags/index.html @@ -1,2 +1,2 @@ Tags | OSRD -

                                            Tags

                                            © 2024 Contributeurs à OSRD. Tous droits réservés
                                            \ No newline at end of file +

                                            Tags

                                            © 2025 Contributeurs à OSRD. Tous droits réservés
                                            \ No newline at end of file diff --git a/offline-search-index.727c2448a85822052eaf432fb7c6ddab.json b/offline-search-index.727c2448a85822052eaf432fb7c6ddab.json new file mode 100644 index 000000000..d9d41a20f --- /dev/null +++ b/offline-search-index.727c2448a85822052eaf432fb7c6ddab.json @@ -0,0 +1 @@ +[{"body":" Explain what you’re doing and why. Document new code with doc comments. Include clear, simple tests. Break work into digestible chunks. Take the time to pick good names. Avoid non well-known abbreviations. Control and consistency over 3rd party code reuse: Only add a dependency if it is absolutely necessary. Every dependency we add decreases our autonomy and consistency. We try to keep PRs bumping dependencies to a low number each week in each component, so grouping dependency bumps in a batch PR is a valid option (see component’s README.md). Don’t reinvent every wheel: as a counter to the previous point, don’t reinvent everything at all costs. If there is a dependency in the ecosystem that is the “de facto” standard, we should heavily consider using it. More code general recommendations in main repository CONTRIBUTING.md. Ask for any help that you need! Consult back-end conventions ‣\nConsult front-end conventions ‣\nContinue towards write code ‣\nContinue towards tests ‣\n","categories":"","description":"Please read this first!","excerpt":"Please read this first!","ref":"/en/docs/guides/contribute/contribute-code/general-principles/","tags":"","title":"General principles"},{"body":"First off, thanks for taking the time to contribute!\nThe following chapters are a set of guidelines for contributing to OSRD. These guidelines are mostly not strict rules, it’s probably fine to do things slightly differently. If you have already contributed to open source projects before, you probably won’t be surprised. If you have not, it will probably help a lot!\nCommunicate Chatting with other contributors is a great way to speed things up:\nCreate an issue to discuss your contribution project. Inquire Just like with any project, changes rely on past work. Before making changes, it is best to learn about what’s already there:\nread technical documentation read the existing source code related to your project chat with developers who last worked on areas you are interested in Continue towards initial set-up ‣\n","categories":"","description":"An introduction to contributing to OSRD","excerpt":"An introduction to contributing to OSRD","ref":"/en/docs/guides/contribute/preamble/","tags":"","title":"Preamble"},{"body":"Déjà, merci de prendre le temps de contribuer !\nSi les sections suivantes forment un guide du contributeur, ce n’est pas pour autant un ensemble de règles strictes. En fait, si vous avez déjà contribué à des gros projets open-source, la suite ne sera pas surprenante. Dans le cas contraire, elle vous sera probablement très utile !\nCommuniquer Vous pouvez gagner du temps en discutant de votre projet de contribution avec les autres contributeurs :\nCréez une issue pour avoir un endroit pour discuter de votre contribution. Se renseigner Comme dans tout projet, chaque changement repose sur ce qui a été fait par le passé. Avant d’apporter un changement, renseignez-vous sur l’existant :\nVous pouvez lire la documentation technique Il est préférable de lire le code source de l’application en rapport avec votre projet Vous pouvez contacter les derniers développeurs à avoir travaillé sur les zones du code en rapport avec votre projet Continuer vers la mise en place ‣\n","categories":"","description":"Quelques premières informations importantes.","excerpt":"Quelques premières informations importantes.","ref":"/fr/docs/guides/contribute/preamble/","tags":"","title":"Avant toutes choses"},{"body":" Expliquez ce que vous faites et pourquoi. Documentez le nouveau code. Ajoutez des tests clairs et simples. Décomposez le travail en morceaux intelligibles. Prenez le temps de choisir de bons noms. Évitez les abréviations peu connues. Contrôle et cohérence de la réutilisation du code de tiers : une dépendance est ajoutée seulement si elle est absolument nécessaire. Chaque dépendance ajoutée diminue notre autonomie et notre cohérence. Nous essayons de limiter à un petit nombre les PRs de mise à jour des dépendances chaque semaine dans chaque composant, donc regrouper les montées de version dans une même PR est une bonne option (reportez-vous au README.md de chaque composant). Ne pas réinventer la roue : en opposition au point précédent, ne réinventez pas tout à tout prix. S’il existe une dépendance dans l’écosystème qui est le standard « de facto », nous devrions fortement envisager de l’utiliser. Plus de code et de recommandations générales dans le dépôt principal CONTRIBUTING.md. Demandez toute l’aide dont vous avez besoin ! Consulter les conventions pour le back-end ‣\nConsulter les conventions pour le front-end ‣\nContinuer vers l’écriture de code ‣\nContinuer vers l’écriture de tests ‣\n","categories":"","description":"À lire en premier !","excerpt":"À lire en premier !","ref":"/fr/docs/guides/contribute/contribute-code/general-principles/","tags":"","title":"Principes généraux"},{"body":"OSRD possède trois versions : développement (dev), staging et publication.\nLa version de développement est la version la plus récente et la plus instable de l’application, contenant les dernières fonctionnalités et corrections de bugs en cours de développement.\nLes versions staging sont créées tous les jeudis à 12h en taguant l’état actuel du développement.\nSi une version staging passe les tests de validation, elle est promue pour devenir la dernière version publication. Cela garantit que seul du code stable et testé est intégré dans les versions de production.\nLe processus de publication suit ce workflow :\nDéveloppement continu dans la branche dev Tags de staging hebdomadaires les jeudis à 12h Tests de validation de la version staging Promotion des builds staging validés au statut de publication Développement Staging publication (instable) (test) (stable) [Branche Dev] | | | |---\u003e Jeudi 12h | | [Tag Staging] | | | | | Validation | | Tests | | | | | o---\u003e Si Passage --\u003e Nouvelle | Tests publication [Suite Dev] | | | V V ","categories":"","description":"Voici comment OSRD est actuellement publié","excerpt":"Voici comment OSRD est actuellement publié","ref":"/fr/docs/guides/release/process/","tags":"","title":"Processus de publication"},{"body":"OSRD has three versions: development (dev), staging, and release.\nThe development version is the most recent and unstable version of the application, containing the latest features and bug fixes in active development.\nStaging versions are created every Thursday at 12pm by tagging the current development state.\nIf a staging version passes validation testing, it is promoted to become the latest release version. This ensures that only stable, tested code makes it into production releases.\nThe release process follows this workflow:\nOngoing development in the dev branch Weekly staging tags on Thursdays at 12pm Validation testing of staging version Promotion of validated staging builds to release status Development Staging Release (unstable) (testing) (stable) [Dev Branch] | | | |---\u003e Thursday 12pm | | [Staging Tag] | | | | | Validation | | Testing | | | | | o---\u003e If Passes --\u003e [New Release] | Tests | [Continue Dev] | | | V V ","categories":"","description":"Here's how OSRD is currently released","excerpt":"Here's how OSRD is currently released","ref":"/en/docs/guides/release/process/","tags":"","title":"Release process"},{"body":"Python Python code is used for some packages and integration testing.\nFollow the Zen of Python. Code is linted with flake8. Code is formatted with Black. Imports are sorted with Isort. Python tests are written using pytest. Typing is checked using pytype. Rust As a reference for our API development we are using the Rust API guidelines. Generally, these should be followed. Prefer granular imports over glob imports like diesel::*. Tests are written with the built-in testing framework. Use the documentation example to know how to phrase and format your documentation. Use consistent comment style: /// doc comments belong above #[derive(Trait)] invocations. // comments should generally go above the line in question, rather than in-line. Start comments with capital letters. End them with a period if they are sentence-like. Use comments to organize long and complex stretches of code that can’t sensibly be refactored into separate functions. Code is linted with clippy. Code is formatted with fmt. Java Code is formatted with checkstyle. ","categories":"","description":"Coding style guide and best practices for back-end","excerpt":"Coding style guide and best practices for back-end","ref":"/en/docs/guides/contribute/contribute-code/backend-conventions/","tags":"","title":"Back-end conventions"},{"body":"Python Le code Python est utilisé pour certains paquets et pour les tests d’intégration.\nSuivez le Zen of Python. Le code est linté avec flake8. Le code est formaté avec Black. Les imports sont triées avec Isort. Les tests sont écrits avec pytest. Les types sont vérifiés avec pytype. Rust Comme référence pour le développement de notre API, nous utilisons les Rust API guidelines. D’une manière générale, il convient de les respecter. Préférer les importations granulaires aux importations globales comme diesel::*. Les tests sont écrits avec le framework de base. Utilisez l’exemple de documentation pour savoir comment formuler et formater votre documentation. Utilisez un style de commentaire cohérent : /// les commentaires de la documentation sont au-dessus des invocations #[derive(Trait)]. Les commentaires // doivent généralement être placés au-dessus de la ligne en question, plutôt qu’en ligne. Les commentaires commencent par des lettres majuscules. Terminez-les par un point s’ils ressemblent à une phrase. Utilisez les commentaires pour organiser des portions de code longues et complexes qui ne peuvent être raisonnablement remaniées en fonctions distinctes. Le code est linté avec clippy. Le code est formaté avec fmt. Java Le code est formaté avec checkstyle. ","categories":"","description":"Conventions de codes et bonnes pratiques pour le back-end","excerpt":"Conventions de codes et bonnes pratiques pour le back-end","ref":"/fr/docs/guides/contribute/contribute-code/backend-conventions/","tags":"","title":"Conventions back-end"},{"body":"Nous utilisons ReactJS et tous les fichiers doivent être écrits en Typescript.\nLe code est linté avec eslint, et formaté avec prettier.\nNomenclature Les applications (osrd eex, osrd stdcm, éditeur infra, éditeur matériel) proposent des vues (gestion des projets, gestions des études, etc.) liées à des modules (projet, étude, etc.) qui contiennent les composants.\nCes vues sont constituées de composants et sous-composants tous issus des modules. En plus de contenir les fichiers de vues des applications, elles peuvent contenir un répertoire scripts qui propose des scripts liés à ces vues. Les vues déterminent la logique et l’accès au store.\nLes modules sont des collections de composants rattachés à un objet (un scénario, un matériel roulant, un TrainSchedule). Ils contiennent :\nun répertoire components qui héberge tous les composants un répertoire styles optionnel par module pour le style des composants en scss un répertoire assets optionnel par module (qui contient les assets, de jeux de données par défaut par ex, spécifiques au module) un fichier reducers optionnel par module un fichier types optionnel par module un fichier consts optionnel par module Un répertoire assets (qui contient les images et autre fichiers).\nEnfin, un répertoire common qui propose :\nun répertoire utils pour les fonctions utilitaires communes à l’ensemble du projet un fichier types pour les types communs à l’ensemble du projet un fichier consts pour les constantes communes à l’ensemble du projet Principes d’implémentation Routage \u0026 SLUG Rédaction en cours\nprojects/{nom du projet}/studies/{nom de l'étude}/scenarios/{nom du scenario}\nStyles \u0026 SCSS ATTENTION : en CSS/React, le scope d’une classe ne dépend pas de l’endroit où le fichier est importé mais est valide pour toute l’application. Si vous importez un fichier scss au fin fond d’un composant (ce que nous déconseillons fortement par ailleurs), ses classes seront disponibles pour toute l’application et peuvent donc provoquer des effets de bord. Vous pouvez utiliser les CSS modules pour éviter les conflits.\nIl est donc très recommandé de pouvoir facilement suivre l’arborescence des applications, vues, modules et composants également au sein du code SCSS, et notamment imbriquer les noms de classes pour éviter les effets de bord, le compilateur se chargera de fabriquer la hiérarchie nécessaire.\nSi par exemple nous avons un composant rollingStockSelector qui propose une liste de matériel rollingStockList représentés par des cartes rollingStockCard contenant une image représentant le matériel roulant rollingStockImg nous devrions avoir la structure SCSS suivante :\n.rollinStockSelector { .rollingStockList { .rollingStockCard { .rollingStockImg { width: 5rem; height: auto; } } } } Ainsi, on a la garantie que l’image contenue dans la carte de matériel roulant héritera bien des bonnes propriétés css .rollinStockSelector.rollingStockList.rollingStockCard.rollingStockImg.\nCSS Modules Les CSS modules permettent de scoper les styles CSS à un composant spécifique, évitant ainsi les conflits de noms de classe globaux.\nVite prend en charge nativement les CSS modules. Assurez-vous que votre fichier CSS a l’extension .module.css. Par exemple, styles.module.css.\nUtilisation des CSS modules dans les composants Créez un fichier SCSS avec l’extension .module.scss : /* MyComponent.module.scss */ .container { background-color: white; } .title { font-size: 24px; color: #333; } Utilisez les classes dans votre composant React : Vite transforme les classes en objets qui contiennent les classes hashées (exemple _container_h3d8bg) et les utilise au moment de la génération du bundle, rendant ainsi les classes uniques.\nimport React from \"react\"; import styles from \"./MyComponent.module.scss\"; export function MyComponent() { return ( \u003cdiv className={styles.container}\u003e \u003ch1 className={styles[\"title\"]}\u003eMon Titre\u003c/h1\u003e \u003c/div\u003e ); } Pour plus d’information, vous pouvez regarder la documentation de vite.js\nNoms de classes, utilisation de cx() Les classes sont ajoutées les unes à la suite des autres, normalement, dans la propriété className=\"\".\nCependant, quand cela est nécessaire — tests pour l’utilisation d’une classe, concaténation, etc. — nous utilisons la bibliothèque classnames qui préconise l’usage suivant :\n\u003cdiv className=\"rollingStockSelector\"\u003e \u003cdiv className=\"rollingStockList\"\u003e \u003cdiv className=\"rollingStockCard w-100 my-2\"\u003e \u003cimg className={cx(\"rollingStockImg\", \"m-2\", \"p-1\", \"bg-white\", { valid: isValid(), selected: rollingStockID === selectedRollingStockID, })} /\u003e \u003c/div\u003e \u003c/div\u003e \u003c/div\u003e Les classes sont séparées chacune dans un string et les opérations booléennes ou autres sont réalisées dans un objet qui retournera — ou pas — le nom de propriété comme nom de classe à utiliser dans le CSS.\nStore/Redux Tout ce qui est selector est géré par la vue et passé en props aux composants et sous-composants.\nPar conséquent les appels au store en lecture et en écriture doivent être passés un niveau de la vue, en irrigant par des props et states les composants proposées par la vue.\nRTK Utiliser les endpoints générés à partir des fichiers openapi.yaml pour consommer le backend.\nFonctionnement du cache dans RTK Query Lorsque de la donnée est récupérée depuis le back, RTK va mettre cette donnée en cache dans le store. Si le même endpoint est appelé avec les même paramètres, RTK va réutiliser la donnée dans le cache plutôt que de rappeler le back.\nDans le store, vous verrez cette clé editoastApi qui contient la donnée en cache de tous les endpoints editoast :\nIci par exemple l’endpoint getProjects a été appelé.\nRTK stocke le nom de l’endpoint, ainsi que les paramètres d’appel, pour former une clé unique nomDuEndpoint({ paramètres }). (ici getProjects({\"ordering\":\"LastModifiedDesc\",\"pageSize\":1000})).\n{ 'getProjectsByProjectIdStudiesAndStudyId({\"projectId\":13,\"studyId\":16})': { status :\"fulfilled\", etc… }, 'getProjectsByProjectIdStudiesAndStudyId({\"projectId\":13,\"studyId\":14})': { … } } Dans ce deuxième exemple, le même endpoint a été appelé avec le même paramètre projectId, mais un paramètre studyId différent.\nSérialisation des clés dans le cache Les string utilisées comme clé dans le cache sont à peu de choses près l’objet paramètre passé à la moulinette JSON.stringify que transforme un object JS en string (donc sérialisé).\nNormalement La sérialisation ne conserve pas l’ordre des clés des objets. Par exemple, JSON.stringify ne produira pas la même string avec ces deux objets: { a: 1, b: 2 } et { b: 2, a: 1 }.\nRTK va optimiser la mise en cache en faisant en sorte que le résultat d’un appel avec {\"projectId\":13,\"studyId\":16} ou {\"studyId\":16, \"projectId\":13} soient stockées dans la même clé dans le cache.\nPour voir le fonctionnement en détail, voici le code de cette fonction de sérialisation :\nFonction de sérialisation RTK const defaultSerializeQueryArgs: SerializeQueryArgs\u003cany\u003e = ({ endpointName, queryArgs, }) =\u003e { let serialized = '' const cached = cache?.get(queryArgs) if (typeof cached === 'string') { serialized = cached } else { const stringified = JSON.stringify(queryArgs, (key, value) =\u003e isPlainObject(value) ? Object.keys(value) .sort() // les clés sont remises dans l’ordre ici .reduce\u003cany\u003e((acc, key) =\u003e { acc[key] = (value as any)[key] return acc }, {}) : value ) if (isPlainObject(queryArgs)) { cache?.set(queryArgs, stringified) } serialized = stringified } // Sort the object keys before stringifying, to prevent useQuery({ a: 1, b: 2 }) having a different cache key than useQuery({ b: 2, a: 1 }) return `${endpointName}(${serialized})` } Souscriptions à la donnée Dans la terminologie de RTK query, Lorsqu’un composant react appelle un endpoint défini dans RTK Query, il souscrit à la donnée.\nRTK compte le nombre de référence à la même paire (endpoint,{paramètres}). Lorsque deux composants souscrivent à la même donnée. Ils partagent la même clé dans le cache.\nimport { osrdEditoastApi } from \"./api.ts\"; function Component1() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(1); return \u003cdiv\u003e...\u003c/div\u003e; } function Component2() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(2); return \u003cdiv\u003e...\u003c/div\u003e; } function Component3() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(3); return \u003cdiv\u003e...\u003c/div\u003e; } function Component4() { // component subscribes to the *same* data as ComponentThree, // as it has the same query parameters const { data } = osrdEditoastApi.useGetXQuery(3); return \u003cdiv\u003e...\u003c/div\u003e; } Ici Component3 et Component4 ne vont générer qu’un seul appel vers le back. Ils souscrivent à la même donnée (même endpoint et même paramètre 3). Ils vont partager la même clé dans le cache.\nAu total ici il y aura trois appels vers le back, avec les paramètres 1, 2, 3.\nTant qu’il existe au moins un composant react monté, qui appelle le hook osrdEditoastApi.endpoints.getProjectsByProjectId.useQuery par exemple, la donnée sera conservée dans le cache.\nDès que le dernier composant est démonté, la donnée est supprimée du cache au bout de 60 secondes (valeur par défaut).\nTraduction de l’application La traduction de l’application est effectuée sur Transifex. La langue par défaut est le français. A noter que si l’on doit corriger une traduction, il est recommandé de passer par Transifex. En revanche, si on ajoute une nouvelle clé de traduction, celle-ci peut être ajoutée dans le code directement, dans toutes les langues disponibles.\nLois et éléments importants Aucun composant ne doit détenir la responsabilité de mise à jour de la donnée qu’il utilise Seules les vues contiennent les sélecteurs du store, donnés ensuite en props aux composants du module lié à la vue.\nLe SCSS n’est pas scopé Un fichier .scss enfoui dans l’arborescence ne vous garantit pas que les classes contenues soient seulement accessibles à cet endroit, y compris par import react (formellement interdit au passage : vous devez utiliser l’import SCSS), toutes les classes déclarées sont accessibles partout.\nPréférez un choix judicieux de nom de classe racine pour un module donné et utilisez l’arborescence possible dans le fichier SCSS.\nLes imports doivent être triés d’une certaine manière ESLint est configuré pour trier automatiquement les imports en 4 groupes, chacun trié alphabétiquement :\nReact Librairies externes Fichiers internes en chemin absolu Fichiers internes en chemin relatif Chacun de ces groupes est séparé par une ligne vide.\nESLint déclenchera un avertissement si ces recommandations ne sont pas respectées.\nLes liens des imports doivent être absolus Vous devez utiliser le chemin complet pour tous vos imports.\nLe chemin peut être relatif seulement si le fichier à importer est dans le même répertoire.\nTypeScript import \u0026 export ESLint et Typescript sont configurés pour imposer l’import type pour un import de type.\nCeci permet de :\nAutomatiquement ajouter type devant l’import quand on ajoute un type avec l’autocomplétion dans un fichier. Afficher 2 erreurs de chacun de ces packages demandant d’ajouter type devant l’import si vous ne l’avez pas fait. Lorsque qu’un import ou un export ne comporte que des types, il faut l’indiquer par le mot clé type.\nexport type { Direction, DirectionalTrackRange as TrackRange }; import type { typedEntries, ValueOf } from \"utils/types\"; Quand un import ne contient pas que des types, il sera agencé de cette manière, par ordre alphabétique.\nimport { osrdEditoastApi, type ScenarioCreateForm, } from \"common/api/osrdEditoastApi\"; Cette pratique permet de :\nAméliorer les performances et le travail d’analyse du compilateur et du linter. Rendre ces déclarations plus lisibles, on voit clairement ce qu’on est en train d’importer. Éviter des cycles de dépendances : L’erreur disparaît avec le mot clé type\nAlléger le bundle final (tous les types disparaissent à la compilation). ","categories":"","description":"Conventions de codes et bonnes pratiques pour le front-end","excerpt":"Conventions de codes et bonnes pratiques pour le front-end","ref":"/fr/docs/guides/contribute/contribute-code/frontend-conventions/","tags":"","title":"Conventions front-end"},{"body":"We use ReactJS and all files must be written in Typescript.\nThe code is linted with eslint, and formatted with prettier.\nNomenclature The applications (osrd eex, osrd stdcm, infra editor, rolling-stock editor) offer views (project management, study management, etc.) linked to modules (project, study, etc.) which contain the components.\nThese views are made up of components and sub-components all derived from the modules. In addition to containing the views files for the applications, they may also contain a scripts directory which offers scripts related to these views. The views determine the logic and access to the store.\nModules are collections of components attached to an object (a scenario, a rolling stock, a TrainSchedule). They contain :\na components directory hosting all components an optional styles directory per module for styling components in scss an optional assets directory per module (which contains assets, e.g. default datasets, specific to the module) an optional reducers file per module an optional types file per module an optional consts file per module An assets directory (containing images and other files).\nLast but not least, a common directory offering :\na utils directory for utility functions common to the entire project a types file for types common to the entire project a consts file for constants common to the entire project Implementation principles Routing \u0026 SLUG In progress\nprojects/{nom du projet}/studies/{nom de l'étude}/scenarios/{nom du scenario}\nStyles \u0026 SCSS WARNING: in CSS/React, the scope of a class does not depend on where the file is imported, but is valid for the entire application. If you import an scss file in the depths of a component (which we strongly advise against), its classes will be available to the whole application and may therefore cause side effects.\nIt is therefore highly recommended to be able to easily follow the tree structure of applications, views, modules and components also within the SCSS code, and in particular to nest class names to avoid edge effects, as the compiler will take care of making the necessary hierarchy.\nIf, for example, we have a rollingStockSelector component which proposes a list of rolling stock rollingStockList represented by rollingStockCard containing an image representing the rolling stock rollingStockImg we should have the following SCSS structure:\n.rollinStockSelector { .rollingStockList { .rollingStockCard { .rollingStockImg { width: 5rem; height: auto; } } } } This ensures that the image contained in the rolling stock card inherits the correct css properties .rollinStockSelector.rollingStockList.rollingStockCard.rollingStockImg.\nCSS Modules CSS modules allow scoping CSS styles to a specific component, thereby avoiding conflicts with global class names.\nVite natively supports CSS modules. Ensure that your CSS file has the .module.css extension, for example, styles.module.css.\nUsing CSS Modules in Components Create an SCSS file with the .module.scss extension: /* MyComponent.module.scss */ .container { background-color: white; } .title { font-size: 24px; color: #333; } Use the classes in your React component: Vite transforms classes into objects that contain hashed classes (e.g., _container_h3d8bg) and uses them during bundle generation, making the classes unique.\nimport React from \"react\"; import styles from \"./MyComponent.module.scss\"; export function MyComponent() { return ( \u003cdiv className={styles.container}\u003e \u003ch1 className={styles[\"title\"]}\u003eMy Title\u003c/h1\u003e \u003c/div\u003e ); } For more information, you can refer to the Vite.js documentation.\nClass names, using cx(). Classes are normally added one after the other, in the className=\"\" property.\nHowever, when necessary - class usage tests, concatenation, etc. - we use the classnames library, which recommends the following usage:\n\u003cdiv className=\"rollingStockSelector\"\u003e \u003cdiv className=\"rollingStockList\"\u003e \u003cdiv className=\"rollingStockCard w-100 my-2\"\u003e \u003cimg className={cx(\"rollingStockImg\", \"m-2\", \"p-1\", \"bg-white\", { valid: isValid(), selected: rollingStockID === selectedRollingStockID, })} /\u003e \u003c/div\u003e \u003c/div\u003e \u003c/div\u003e Classes are separated each in a string and Boolean or other operations are performed in an object that will return - or not - the property name as the class name to be used in CSS.\nStore/Redux Everything that is selector is managed by the view and passed as props to components and sub-components.\nConsequently, read and write calls to the store must be made at view level, irrigating the components proposed by the view with props and states.\nRTK Use generated endpoints from openapi.yaml files to consume the backend.\nOperation of RTK Query cache When the data is retrieved from the back, RTK is caching it into the store. If the same endpoint is called again with same parameters, RTK will use the cache data instead of making a new call to the back.\nIn the store, you will see the editoastApi key containing the cached data of all editoast endpoints:\nHere for example, the getProjects endpoint is called.\nRTK stores the endpoint’s name, as well as the call’s parameters, to form an unique key nomDuEndpoint({ paramètres }). (here getProjects({\"ordering\":\"LastModifiedDesc\",\"pageSize\":1000})).\n{ 'getProjectsByProjectIdStudiesAndStudyId({\"projectId\":13,\"studyId\":16})': { status :\"fulfilled\", etc… }, 'getProjectsByProjectIdStudiesAndStudyId({\"projectId\":13,\"studyId\":14})': { … } } In this second example, the same endpoint has been called with the ssame projectId parameter, but a different studyId parameter.\nSerialization of keys in the cache The strings used as keys in the cache are essentially the parameter object passed through the JSON.stringify function, which converts a JS object into a string (thus serialized).\nNormally, serialization does not preserve the order of object keys. For example, JSON.stringify will not produce the same string with these two objects: { a: 1, b: 2 } and { b: 2, a: 1 }.\nRTK will optimize caching by ensuring that the result of a call with {\"projectId\":13,\"studyId\":16} or {\"studyId\":16, \"projectId\":13} is stored under the same key in the cache.\nTo see the detailed operation, here is the code for this serialization function:\nRTK Serialization Function const defaultSerializeQueryArgs: SerializeQueryArgs\u003cany\u003e = ({ endpointName, queryArgs, }) =\u003e { let serialized = '' const cached = cache?.get(queryArgs) if (typeof cached === 'string') { serialized = cached } else { const stringified = JSON.stringify(queryArgs, (key, value) =\u003e isPlainObject(value) ? Object.keys(value) .sort() // keys are reordered here .reduce\u003cany\u003e((acc, key) =\u003e { acc[key] = (value as any)[key] return acc }, {}) : value ) if (isPlainObject(queryArgs)) { cache?.set(queryArgs, stringified) } serialized = stringified } // Sort the object keys before stringifying, to prevent useQuery({ a: 1, b: 2 }) having a different cache key than useQuery({ b: 2, a: 1 }) return `${endpointName}(${serialized})` } Data subscription In RTK Query terminology, when a React component calls an endpoint defined in RTK Query, it subscribes to the data.\nRTK counts the number of references to the same pair (endpoint, {parameters}). When two components subscribe to the same data, they share the same key in the cache.\nimport { osrdEditoastApi } from \"./api.ts\"; function Component1() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(1); return \u003cdiv\u003e...\u003c/div\u003e; } function Component2() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(2); return \u003cdiv\u003e...\u003c/div\u003e; } function Component3() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(3); return \u003cdiv\u003e...\u003c/div\u003e; } function Component4() { // component subscribes to the *same* data as ComponentThree, // as it has the same query parameters const { data } = osrdEditoastApi.useGetXQuery(3); return \u003cdiv\u003e...\u003c/div\u003e; } Here, Component3 and Component4 will generate only one call to the backend. They subscribe to the same data (same endpoint and same parameter 3). They will share the same key in the cache.\nIn total, there will be three calls to the backend here, with parameters 1, 2, and 3.\nAs long as at least one mounted React component calls the osrdEditoastApi.endpoints.getProjectsByProjectId.useQuery hook, for example, the data will be retained in the cache.\nOnce the last component is unmounted, the data is removed from the cache after 60 seconds (default value).\nTranslation Application translation is performed on Transifex. The default language is French. If you add a new translation key, it can be added directly to the code, in all available languages. Please note that if you need to correct a translation, we recommend that you use Transifex, to avoid any conflict.\nRules and important elements No component should be responsible for updating the data it uses Only views contain the store selectors, which are then given as props to the components of the module linked to the view.\nSCSS is not scoped A .scss file buried in the tree structure doesn’t guarantee that the classes it contains can only be accessed there, even by importing react (formally forbidden by the way: you must use SCSS import), all declared classes are accessible everywhere.\nPrefer a judicious choice of root class name for a given module, and use the tree structure available in the SCSS file.\nImports must follow a specific order ESLint is setup to automatically sort imports in four import groups, each of them sorted in alphabetical order :\nReact External libraries Internal absolute path files Internal relative path files Each of these groups will be separated by an empty line.\nESLint will trigger a warning if you don’t follow these guidelines.\nImport links must be absolute You must use the full path for all your imports.\nImport links can be relative only if the file to be imported is in the same directory.\nTypeScript import \u0026 export ESLint and Typescript are setup to enforce typed imports for an exported type.\nThis current setup allows to :\nAuto typing the import when using a type in a file with autocompletion. Getting 2 errors from each package asking to use type import if you didn’t. When an import or export contains only types, indicate it with the type keyword.\nexport type { Direction, DirectionalTrackRange as TrackRange }; import type { typedEntries, ValueOf } from \"utils/types\"; When an import contains not only types, it will be structured like below, in alphabetical order.\nimport { osrdEditoastApi, type ScenarioCreateForm, } from \"common/api/osrdEditoastApi\"; This allows to:\nImprove the performance and analysis process of the compiler and the linter. Make these declarations more readable; we can clearly see what we are importing. Avoid dependency cycles: The error disappears with the type keyword\nMake final bundle lighter (all types disappear at compilation) ","categories":"","description":"Coding style guide and best practices for front-end","excerpt":"Coding style guide and best practices for front-end","ref":"/en/docs/guides/contribute/contribute-code/frontend-conventions/","tags":"","title":"Front-end conventions"},{"body":"La licence des contributions de code Tout le code du dépot OSRD est mis à disposition sous la licence LGPLv3. En contribuant du code, vous acceptez la redistribution de votre contribution sous cette license.\nLa licence LGPL interdit de modifier OSRD sans publier le code source de l’application modifiée : profitez du travail des autres, et laissez les autres profiter de votre travail !\nCette contrainte n’est pas contagieuse à travers les API : Il est possible d’utiliser OSRD comme bibliothèque, framework ou serveur pour s’interfacer avec des composants propriétaires. N’hésitez pas à proposer des changements pour répondre à vos besoins.\nMise en place La plupart des développeurs OSRD utilisent Linux (y compris WSL). Vous pouvez utiliser Windows ou MacOS, mais pourriez rencontrer quelques problèmes. Obtenir le code source Installer git1 Ouvrir un terminal2 dans le dossier qui contiendra le code source d’OSRD git clone https://github.com/OpenRailAssociation/osrd.git Lancer l’application Docker est un outil qui réduit considérablement la préparation nécessaire pour travailler sur OSRD:\ntélécharger le dernier build de développement : docker compose pull démarrer OSRD : docker compose up compiler et démarrer OSRD: docker compose up --build review une PR avec les images compilées par la CI: TAG=pr-XXXXX docker compose up --no-build --pull always Pour commencer :\nInstaller docker Suivre le README d’OSRD. Continuer vers la contribution au code ‣\nSous Linux, utilisez le gestionnaire de packet (comme apt) ↩︎\nSous Windows, ouvrez Git Bash ↩︎\n","categories":"","description":"Comment mettre en place l'environnement de développement ? Qu'implique notre licence ?","excerpt":"Comment mettre en place l'environnement de développement ? Qu'implique …","ref":"/fr/docs/guides/contribute/license-and-set-up/","tags":"","title":"Licence et mise en place"},{"body":"License of code contributions The source code of OSRD is available under the LGPLv3 license. By contributing to the codebase, you consent to the distribution of your changes under the project’s license.\nLGPLv3 forbids modifying source code without sharing the changes under the same license: use other people’s work, and share yours!\nThis constraint does not propagate through APIs: You can use OSRD as a library, framework or API server to interface with proprietary software. Please suggest changes if you need new interfaces.\nSet things up Most OSRD developers use Linux (incl. WSL). Windows and MacOS should work too, but you may run into some issues. Get the source code Install git.1 Open a terminal2 in the folder where the source code of OSRD will be located Run git clone https://github.com/OpenRailAssociation/osrd.git Launch the application Docker is a tool which greatly reduces the amount of setup required to work on OSRD:\ndownload the latest development build: docker compose pull start OSRD: docker compose up build and start OSRD: docker compose up --build review a PR using CI built images: TAG=pr-XXXXX docker compose up --no-build --pull always To get started:\nInstall docker Follow OSRD’s README. Continue towards code contribution ‣\nUnder Linux, use the package manager (such as apt) ↩︎\nUnder Windows, open Git Bash ↩︎\n","categories":"","description":"How to set up your development environment? What does our license involve?","excerpt":"How to set up your development environment? What does our license …","ref":"/en/docs/guides/contribute/license-and-set-up/","tags":"","title":"License and set-up"},{"body":"Toutes les versions d’OSRD sont accessibles ici\nLe processus de création d’une nouvelle version est le suivant :\nNous publions toujours sur une version testée de l’application (branche staging) git switch staging \u0026\u0026 git pull Créer un tag git annoté Nous utilisons le versionnement sémantique git tag -a vx.y.z avec le message Release x.y.z (la plupart du temps, utilisez la dernière version et incrémentez la version patch) git push --tags Créer une release GitHub Créer une nouvelle release GitHub ici Sélectionner le tag créé Générer les notes de version Renommer la release ainsi : “Version x.y.z” Cocher la case “Set as a pre-release” Appliquer le format du changelog Vous pouvez ensuite publier la release ou sauvegarder le brouillon si vous souhaitez y revenir plus tard Une action GitHub devrait être déclenchée automatiquement. Poster le lien de la release créée sur Matrix. Suggérer aux développeurs de revoir la release. Format du changelog Utiliser la structure suivante : ## What's Changed ### Features :tada: ### Code refactoring :recycle: ### Bug fixes :bug: ## New Contributors \u003c!-- Copy from the generated release notes --\u003e ... \u003c!-- Copy from the generated release notes --\u003e **Full Changelog**: ... Répartir les différentes pull requests Fusionner ou regrouper les PR quand cela a du sens. Exemples : PR de mise à jour des dépendances (fusionner) PR en plusieurs parties (fusionner) Une grande fonctionnalité implémentée par plusieurs PR (regrouper) Reformuler les titres des PR. Ils doivent être compréhensibles pour un collaborateur externe ","categories":"","description":"Comment publier une nouvelle version","excerpt":"Comment publier une nouvelle version","ref":"/fr/docs/guides/release/publish/","tags":"","title":"Publier une nouvelle version"},{"body":"All OSRD releases are accessible here\nThe process for creating a new release is as follows:\nWe always release on a tested version of the application (staging branch) git switch staging \u0026\u0026 git pull Create a git annotated tag We are using the semantic versioning git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version) git push --tags Create a github release Draft a new github release here Select the created tag Generate the releases notes Rename the release like so: “Version x.y.z” Check the “Set as a pre-release” box Apply the changelog format Then you can publish the release or save the draft if you want to come back later A github action should be triggered automatically. Post the link of the created release on matrix. Suggest that the developers review the release. Changelog format Use the following structure: ## What's Changed ### Features :tada: ### Code refactoring :recycle: ### Bug fixes :bug: ## New Contributors \u003c!-- Copy from the generated release notes --\u003e ... \u003c!-- Copy from the generated release notes --\u003e **Full Changelog**: ... Partition the different pull requests Merge or group PR when it make sense. Examples: Bump of dependencies PR (merge) Multi part PR (merge) One big feature implemented by multiple PR (group) Reword PR title. It should be comprehensible to an external collaborator ","categories":"","description":"How to publish a new release","excerpt":"How to publish a new release","ref":"/en/docs/guides/release/publish/","tags":"","title":"Publish a new release"},{"body":"Ce chapitre décrit le processus aboutissant à l’intégration de code au sein du projet. Si vous avez besoin d’aide, ouvrez une issue ou envoyez un message instantané.\nL’application OSRD est divisée en plusieurs services écrits dans plusieurs langues. Nous essayons de suivre les bonnes pratiques générales en matière de code et de respecter les spécificités de chaque langage lorsque cela est nécessaire.\n","categories":"","description":"Apporter des modifications au code d'OSRD","excerpt":"Apporter des modifications au code d'OSRD","ref":"/fr/docs/guides/contribute/contribute-code/","tags":"","title":"Contribuer au code"},{"body":"This chapter is about the process of integrating changes into the common code base. If you need help at any stage, open an issue or message us.\nOSRD application is split in multiple services written in several languages. We try to follow general code best practices and follow each language specificities when required.\n","categories":"","description":"Integrate changes into OSRD","excerpt":"Integrate changes into OSRD","ref":"/en/docs/guides/contribute/contribute-code/","tags":"","title":"Contribute code"},{"body":" Si vous n’être pas un habitué de Git, suivez ce tutoriel\nCréez une branche\nSi vous comptez contribuer régulièrement, vous pouvez demander accès au dépot principal. Sinon, créez un fork.\nAjoutez des changements sur votre branche\nEssayez de découper votre travail en étapes macroscopiques, et sauvegardez vos changements dans un commit à la fin de chaque étape. Essayez de suivre les conventions du projet.\nConservez votre branche à jour\ngit switch \u003cyour_branch\u003e git fetch git rebase origin/dev Continuer vers le style des commits ‣\n","categories":"","description":"Apporter des modifications au code d'OSRD","excerpt":"Apporter des modifications au code d'OSRD","ref":"/fr/docs/guides/contribute/contribute-code/write-code/","tags":"","title":"Écrire du code"},{"body":" If you are not used to Git, follow this tutorial\nCreate a branch\nIf you intend to contribute regularly, you can request access to the main repository. Otherwise, create a fork.\nAdd changes to your branch\nBefore you start working, try to split your work into macroscopic steps. At the end of each stop, save your changes into a commit. Try to make commits of logical and atomic units. Try to follow style conventions.\nKeep your branch up-to-date\ngit switch \u003cyour_branch\u003e git fetch git rebase origin/dev Continue towards commit style ‣\n","categories":"","description":"Integrate changes into OSRD","excerpt":"Integrate changes into OSRD","ref":"/en/docs/guides/contribute/contribute-code/write-code/","tags":"","title":"Write code"},{"body":"Commit style The overall format for git commits is as follows:\ncomponent1, component2: imperative description of the change Detailed or technical description of the change and what motivates it, if it is not entirely obvious from the title. the commit message, just like the code, must be in english (only ASCII characters for the title) there can be multiple components separated by : in case of hierarchical relationships, with , otherwise components are lower-case, using -, _ or . if necessary the imperative description of the change begins with a lower-case verb the title must not contain any link (# is forbidden) Ideally:\nthe title should be self-explanatory: no need to read anything else to understand it the commit title is all lower-case the title is clear to a reader not familiar with the code the body of the commit contains a detailled description of the change An automated check is performed to enforce as much as possible this formating. Counter-examples of commit titles To be avoided entirely:\ncomponent: update ./some/file.ext: specify the update itself rather than the file, the files are technical elements welcome in the body of the commit component: fix #42: specify the problem fixed in the title, links (to issue, etc.) are very welcome in commit’s body wip: describe the work (and finish it) Welcome to ease review, but do not merge:\nfixup! previous commit: an autosquash must be run before the merge Revert \"previous commit of the same PR\": both commits must be dropped before merging The Developer Certificate of Origin (DCO) All of OSRD’s projects use the DCO (Developer Certificate of Origin) to address legal matters. The DCO helps confirm that you have the rights to the code you contribute. For more on the history and purpose of the DCO, you can read The Developer Certificate of Origin by Roscoe A. Bartlett.\nTo comply with the DCO, all commits must include a Signed-off-by line.\nHow to sign a commit using git in a shell ? To sign off a commit, simply add the -s flags to your git commit command, like so:\ngit commit -s -m \"Your commit message\" This also applies when using the git revert command.\nHow to do sign a commit using git in Visual Studio Code (VS Code) ? Now, go in Files -\u003e Preferences -\u003e Settings, search for and activate the Always Sign Off setting.\nFinally, when you’ll commit your changes via the VS Code interface, your commits will automaticaly be signed-off.\nContinue towards sharing your changes ‣\n","categories":"","description":"A few advises and rules about commit messages","excerpt":"A few advises and rules about commit messages","ref":"/en/docs/guides/contribute/contribute-code/commit-conventions/","tags":"","title":"Commit conventions"},{"body":"Style de commits Le format général des commits est le suivant :\ncomposant1, composant2: description du changement à l'impératif Description détaillée ou technique du contenu et de la motivation du changement, si le titre n'est pas complètement évident. le message comme le code doit être en anglais (seulement des caractères ASCII pour le titre) il peut y avoir plusieurs composants, séparés par des : quand il y a une relation hiérarchique, ou des , sinon les composants sont en minuscule, avec éventuellement -, _ ou . la description du changement à l’impératif commence par un verbe en minuscule le titre ne doit pas comporter de lien (# est interdit) Idéalement :\nle titre doit être autonome : pas besoin de lire autre chose pour le comprendre le titre du commit est entièrement en minuscule le titre est clair pour une personne étrangère au code le corps du commit contient une description du changement Une vérification automatique est effectuée pour vérifier autant que possible ce formatage. Contre-exemples de titres de commit A éviter absolument:\ncomponent: update ./some/file.ext : préciser la mise à jour en question plutôt que le fichier, les fichiers sont des éléments techniques bienvenus dans le corps du commit component: fix #42 : préciser le problème corrigé, les liens (vers l’issue, etc.) sont encouragés dans le corps du commit wip : décrire le travail (et le finir) Bienvenus pour faciliter la relecture, mais ne pas merger:\nfixup! previous commit : un autosquash devra être lancé avant le merge Revert \"previous commit of the same PR\" : les deux commits devront être retirés avant merge Le Developer Certificate of Origin (DCO) Tous les projets d’OSRD utilisent le DCO (certificat du développeur d’orgine) pour des raisons légales. Le DCO permet de confirmer que vous avez les droits sur le code que vous contribuez. Pour en savoir plus sur l’histoire et l’objectif du DCO, vous pouvez lire The Developer Certificate of Origin de Roscoe A. Bartlett.\nPour se conformer au DCO, tous les commits doivent inclure une ligne Signed-off-by.\nComment signer un commit avec Git dans un terminal ? Pour signer un commit, il suffit d’ajouter l’option -s à votre commande git commit, comme ceci :\ngit commit -s -m \"Your commit message\" Cela s’applique également lors de l’utilisation de la commande git revert.\nComment signer un commit avec Git dans Visual Studio Code (VS Code) ? Allez dans Fichiers -\u003e Préférences -\u003e Paramètres, puis recherchez et activez le paramètre Always Sign Off.\nEnsuite, lorsque vous ferez un commit via l’interface de VS Code, ils seront automatiquement signés.\nContinuer vers le partage des changements ‣\n","categories":"","description":"Quelques bonnes pratiques et règles pour les messages de commits","excerpt":"Quelques bonnes pratiques et règles pour les messages de commits","ref":"/fr/docs/guides/contribute/contribute-code/commit-conventions/","tags":"","title":"Conventions de commits"},{"body":"The reviewer/maintainer undertakes to carry out the review quickly, and is also responsible for closing request changes, check commit history and quickly merge the pull request if allowed.\nWe propose you a few tips and recommendations that we think are relevant to a human, relevant and rewarding code review for all contributors:\nHow to Make Your Code Reviewer Fall in Love with You? by Michael Lynch. How to Do Code Reviews Like a Human? by Michael Lynch. Review cycle A code review is an iterative process. For a smooth review, it is imperative to correctly configure your github notifications.\nIt is advisable to configure OSRD repositories as “Participating and @mentions”. This allows you to be notified of activities only on issues and PRs in which you participate.\nMaintainers are automatically notified by the CODEOWNERS system. The author of a PR is responsible for advancing their PR through the review process and manually requesting maintainer feedback if necessary.\nsequenceDiagram actor A as PR author actor R as Reviewer/Maintainer A-\u003e\u003eR: Asks for a review, notifying some people R-\u003e\u003eA: Answers yes or no loop Loop between author and reviewer R--\u003e\u003eA: Comments, asks for changes A--\u003e\u003eR: Answers to comments or requested changes A--\u003e\u003eR: Makes necessary changes in dedicated \"fixups\" R--\u003e\u003eA: Reviews, tests changes, and comments again R--\u003e\u003eA: Resolves requested changes/conversations if ok end A-\u003e\u003eR: Rebase and apply fixups R-\u003e\u003eA: Checks commits history R-\u003e\u003eA: Approves or closes the PR Note left of R: \u0026 Merges if maintainer The code review pyramid Script for testing a PR When reviewing a PR, it is useful to test the changes by starting an instance of the OSRD app based on the PR branch.\nA script is available to spin up a separate and dedicated app instance using the PR number. The script uses the Docker images already built by the CI and launches the app, running in isolation. This allows you to run both instances simultaneously without conflicts (ideal for comparing changes, for example).\nAdditionally, you can specify a database backup, which the script will load directly into the app.\nThe app will be launched on the 4001 port. You can access it at: http://localhost:4001/\nAvailable Commands: ./scripts/pr-tests-compose.sh 8914 up: Downloads the CI-generated images for PR #8914 and launches the application. ./scripts/pr-tests-compose.sh 8914 up-and-load-backup ./path_to_backup: Downloads the images for PR #8914, restores data from the provided backup, and starts the application. ./scripts/pr-tests-compose.sh down: Shuts down the test application instance for PR #8914. ./scripts/pr-tests-compose.sh down-and-clean: Shuts down the test instance and cleans all the instance’s docker volumes (PG data, Valkey cache, RabbitMQ) to prevent any side-effects. Accessing Services: Apart from the frontend server, all localhost services are available on localhost, with a minor port adjustment (to avoid conflicts with the dev environment): for a list of common ports, have a look at the dedicated docker-compose file.\n","categories":"","description":"How to give useful feedback","excerpt":"How to give useful feedback","ref":"/en/docs/guides/contribute/code-review/","tags":"","title":"Review process"},{"body":"Le reviewer/mainteneur s’engage à effectuer la revue de code rapidement, c’est aussi à lui qu’appartient de fermer les « request changes », de bien vérifier l’historique des commits, et de fusionner la « pull request » s’il en a les droits.\nNous vous soumettons quelques conseils et recommandations qui nous semblent pertinentes pour une revue de code humaine, pertinente et enrichissante pour tous ses contributeurs :\nHow to Make Your Code Reviewer Fall in Love with You? par Michael Lynch. How to Do Code Reviews Like a Human? par Michael Lynch. Cycle de review Une revue de code est un processus itératif. Pour la fluidité d’une review, il est impératif de configurer correctement ses notifications github.\nIl est conseillé de configurer les dépôts OSRD en “Participating and @mentions”. Cela permet d’être notifié d’activités uniquement sur les issues et PR auxquelles vous participez.\nsequenceDiagram actor A as Auteur PR actor R as Reviewer/mainteneur A-\u003e\u003eR: Demande une review en notifiant spéciquement quelques personnes R-\u003e\u003eA: Répond à la demande par oui ou non loop Boucle entre auteur et reviewer R--\u003e\u003eA: Commente, demande des changements A--\u003e\u003eR: Répond à chaque commentaire/demande de changement A--\u003e\u003eR: Corrige le code si nécessaire dans des « fixups » dédiés R--\u003e\u003eA: Vérifie, teste, et commente à nouveau le code R--\u003e\u003eA: Résout les conversations/demandes de changement le cas échéant end A-\u003e\u003eR: Rebase si nécessaire R-\u003e\u003eA: Vérifie l'historique des commits R-\u003e\u003eA: Approuve ou ferme la PR Note left of R: Et fusionne si mainteneur Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).\nLa pyramide de la revue de code Script pour le test d’une PR Lors de la revue d’une PR, il est utile de tester les changements en démarrant une instance de l’application OSRD basée sur la branche de la PR.\nUn script est disponible pour lancer automatiquement une instance séparée et dédiée de l’application en utilisant le numéro de la PR. Le script utilise les images Docker déjà construites par la CI et lance l’application de manière isolée. Cela permet d’exécuter les deux instances en parallèle, sans conflits (idéal pour comparer les modifications, par exemple).\nDe plus, vous pouvez fournir une sauvegarde de la base de données, que le script chargera directement dans l’application.\nL’application sera lancée sur le port 4001. Vous pouvez y accéder en suivant : http://localhost:4001/\nCommandes Disponibles : ./scripts/pr-tests-compose.sh 8914 up : Télécharge les images CI générées pour la PR #8914 et lance l’application. ./scripts/pr-tests-compose.sh 8914 up-and-load-backup ./path_to_backup : Télécharge les images pour la PR #8914, restaure les données à partir de la sauvegarde spécifiée, et démarre l’application. ./scripts/pr-tests-compose.sh down : Arrête l’instance de test de l’application pour la PR #8914. ./scripts/pr-tests-compose.sh down-and-clean : Arrête l’instance de test et nettoie l’ensemble des volumes docker de l’instance (base de donnée PG, cache Valkey, RabbitMQ) pour éviter tout effet de bord. Accès aux Services : À l’exception du serveur frontend, tous les services sont disponibles sur localhost, avec un léger ajustement de port (pour éviter les conflits avec l’environnement de développement) : pour la liste des ports, reportez-vous au fichier docker compose dédié.\n","categories":"","description":"Comment faire des retours constructifs","excerpt":"Comment faire des retours constructifs","ref":"/fr/docs/guides/contribute/code-review/","tags":"","title":"Revue de code"},{"body":"L’auteur d’une pull request (PR) est responsable de son « cycle de vie ». Il se charge de contacter les différents acteurs, de suivre la revue de code, répondre aux commentaires et corriger le code suite à la revue de code (vous pouvez également consulter la page dédiée à la revue de code).\nEn cas de PR conséquente, ne pas hésiter à solliciter plusieurs reviewers qui pourront s’organiser, voire de faire la review ensemble, reviewers et auteur.\nOuvrez une pull request Une fois que vos changements sont prêts, il est temps de proposer de les intégrer à la branche dev. Cela se fait dans l’interface web de Github.\nSi possible :\nFaites des PRs d’unités logiques et atomiques également (évitez de mélanger le refactoring, les nouvelles fonctionnalités et la correction de bugs en même temps). Ajoutez une description aux PR pour expliquer ce qu’elles font et pourquoi. Aidez le relecteur en suivant les conseils donnés dans l’article de mtlynch. Ajoutez les balises area:\u003caffected_area\u003e pour montrer quelle partie de l’application a été impactée. Cela peut être fait via l’interface web. Prenez en compte les retours Une fois que votre PR est ouverte, d’autres contributeurs doivent donner leur avis sur votre proposition :\nN’importe qui peut donner son avis. Il est nécessaire d’obtenir l’approbation d’un contributeur familier avec le code. Il est d’usage de prendre en compte tous les commentaires critiques. Les commentaires sont souvent écrits dans un style plutôt direct, dans le souci de collaborer efficacement vers une solution acceptable par tous. Une fois que tous les commentaires ont été pris en compte, un mainteneur intègre le changement. Sur les PR conséquentes et vouées à évoluer dans le temps, conserver les corrections suite à la relecture dans des commits séparés facilite le travail de relecture. En cas de rebase et de relectures multiples par la même personne ils sont le moyen d’économiser une nouvelle relecture complète (demandez de l’aide au besoin) :\nAjoutez des commits de fixup, amend, squash ou reword à l’aide de la documentation dédiée à git commit. Fusionnez automatiquement les corrections dans les commits originaux de votre PR et vérifier le résultat , à l’aide de git rebase -i --autosquash origin/dev (juste avant le merge et une fois les relectures terminées). Poussez vos changements avec git push --force-with-lease car vous ne poussez pas seulement de nouveaux commits, mais bien un changement des commits existants. N’hésitez pas à relancer vos interlocuteurs, plusieurs fois si besoin est : vous êtes responsable de la vie de votre pull request. Cycle de review Une revue de code est un processus itératif. Pour la fluidité d’une review, il est impératif de configurer correctement ses notifications github.\nIl est conseillé de configurer les dépôts OSRD en “Participating and @mentions”. Cela permet d’être notifié d’activités uniquement sur les issues et PR auxquelles vous participez.\nsequenceDiagram actor A as Auteur PR actor R as Reviewer/mainteneur A-\u003e\u003eR: Demande une review en notifiant spéciquement quelques personnes R-\u003e\u003eA: Répond à la demande par oui ou non loop Boucle entre auteur et reviewer R--\u003e\u003eA: Commente, demande des changements A--\u003e\u003eR: Répond à chaque commentaire/demande de changement A--\u003e\u003eR: Corrige le code si nécessaire dans des « fixups » dédiés R--\u003e\u003eA: Vérifie, teste, et commente à nouveau le code R--\u003e\u003eA: Résout les conversations/demandes de changement le cas échéant end A-\u003e\u003eR: Rebase si nécessaire R-\u003e\u003eA: Vérifie l'historique des commits R-\u003e\u003eA: Approuve ou ferme la PR Note left of R: Et fusionne si mainteneur Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).\nContinuer enfin vers les tests ‣\n","categories":"","description":"Comment soumettre votre code pour qu'il soit vérifié ?","excerpt":"Comment soumettre votre code pour qu'il soit vérifié ?","ref":"/fr/docs/guides/contribute/contribute-code/share-changes/","tags":"","title":"Partagez vos changements"},{"body":"Please report anything you deem significant!\nOur bug tracking platform is github, so you have to register to report bugs.\nFollow this link and pick whatever template fits the best.\nBugs Bug must have a correct description and the bug’s issue template must be filled carefully. Bug must be tagged with (for team members): kind:bug one or several area:\u003caffected_area\u003e if possible, if the affected area is not known leave it blank it will be added later by another team member. one severity:\u003cbug_severity\u003e if possible, if severity is not known leave it blank it will be added later by another team member. severity:minor: User can still use the feature. severity:major: User sometimes can’t use the feature. severity:critical: User can’t use the feature. OSRD team members can change issues’ tags (severity, area, kind, …). You may leave a comment to explain changes. If you are working on a bug or plan to work on a bug, assign yourself to the bug. PRs solving bugs should add a regression tests to ensure that bug will not be back in the future. ","categories":"","description":"Report a bug or suggest an enhancement","excerpt":"Report a bug or suggest an enhancement","ref":"/en/docs/guides/contribute/bug-reports/","tags":"","title":"Report issues"},{"body":"The author of a pull request (PR) is responsible for its “life cycle”. He is responsible for contacting the various parties involved, following the review, responding to comments and correcting the code following review (you could also check dedicated page about code review).\nIn the case of a large PR, don’t hesitate to ask several reviewers to organize themselves, or even to carry out the review together, reviewers and author.\nOpen a pull request Once your changes are ready, you have to request integration with the dev branch.\nIf possible:\nMake PR of logical and atomic units too (avoid mixing refactoring, new features and bug fix at the same time). Add a description to PRs to explain what they do and why. Help the reviewer by following advice given in mtlynch article. Add tags area:\u003caffected_area\u003e to show which part of the application have been impacted. It can be done through the web interface. Take feedback into account Once your PR is open, other contributors can review your changes:\nAny user can review your changes. Your code has to be approved by a contributor familiar with the code. All users are expected to take comments into account. Comments tend to be written in an open and direct manner. The intent is to efficiently collaborate towards a solution we all agree on. Once all discussions are resolved, a maintainer integrates the change. For large PRs that are bound to evolve over time, keeping corrections during review in separate commits helps reviewers. In the case of multiple reviews by the same person, this can save full re-review (ask for help if necessary):\nAdd fixup, amend, squash or reword commits using the git commit documentation. Automatically merge corrections into the original commits of your PR and check the result, using git rebase -i --autosquash origin/dev (just before the merge and once review process is complete). Push your changes with git push --force-with-lease because you are not just pushing new commits, you are pushing changes to existing commits. If you believe somebody forgot to review / merge your change, please speak out, multiple times if needs be. Review cycle A code review is an iterative process. For a smooth review, it is imperative to correctly configure your github notifications.\nIt is advisable to configure OSRD repositories as “Participating and @mentions”. This allows you to be notified of activities only on issues and PRs in which you participate.\nMaintainers are automatically notified by the CODEOWNERS system. The author of a PR is responsible for advancing their PR through the review process and manually requesting maintainer feedback if necessary.\nsequenceDiagram actor A as PR author actor R as Reviewer/Maintainer A-\u003e\u003eR: Asks for a review, notifying some people R-\u003e\u003eA: Answers yes or no loop Loop between author and reviewer R--\u003e\u003eA: Comments, asks for changes A--\u003e\u003eR: Answers to comments or requested changes A--\u003e\u003eR: Makes necessary changes in dedicated \"fixups\" R--\u003e\u003eA: Reviews, tests changes, and comments again R--\u003e\u003eA: Resolves requested changes/conversations if ok end A-\u003e\u003eR: Rebase and apply fixups R-\u003e\u003eA: Checks commits history R-\u003e\u003eA: Approves or closes the PR Note left of R: \u0026 Merges if maintainer Finally continue towards tests ‣\n","categories":"","description":"How to submit your code modifications for review?","excerpt":"How to submit your code modifications for review?","ref":"/en/docs/guides/contribute/contribute-code/share-changes/","tags":"","title":"Share your changes"},{"body":"N’hésitez pas à signaler tout ce qui vous semble important !\nNotre outil de suivi des bugs est github. Il est nécessaire de s’inscrire pour signaler un bug.\nSuivez ce lien et choisissez le modèle qui correspond à votre cas de figure.\nBugs Le bug doit avoir une description correcte et le modèle du bug doit être rempli avec soin. Le bug doit être étiqueté avec (pour les membres de l’équipe) : kind:bug une ou plusieurs area:\u003caffected_area\u003e si possible (si la zone affectée n’est pas connue, laissez-la vide et elle sera ajoutée plus tard par un autre membre de l’équipe). un severity:\u003cbug_severity\u003e si possible (si la sévérité n’est pas connue, laissez-la vide et elle sera ajoutée plus tard par un autre membre de l’équipe). severity:minor : L’utilisateur peut encore utiliser la fonctionnalité. severity:major : L’utilisateur ne peut parfois pas utiliser la fonctionnalité. severity:critical : L’utilisateur ne peut pas utiliser la fonctionnalité. Les membres de l’équipe OSRD peuvent modifier les étiquettes des problèmes (gravité, domaine, type, …). Vous pouvez laisser un commentaire pour expliquer les changements. Si vous travaillez sur un bug ou planifiez de travailler sur un bug, assignez vous au bug. Les PRs qui résolvent des bugs doivent ajouter des tests de régression pour s’assurer que le bug ne reviendra pas dans le futur. ","categories":"","description":"Comment signaler un bug ou suggérer une amélioration","excerpt":"Comment signaler un bug ou suggérer une amélioration","ref":"/fr/docs/guides/contribute/bug-reports/","tags":"","title":"Signaler des problèmes"},{"body":"Back-end Integration tests are written with pytest in the /tests folder. Each route described in the openapi.yaml files must have an integration test. The test must check both the format and content of valid and invalid responses. Front-end The functional writing of the tests is carried out with the Product Owners, and the developers choose a technical implementation that precisely meets the needs expressed and fits in with the recommendations presented here.\nWe use Playwright to write end-to-end tests, and vitest to write unit tests.\nThe browsers tested are currently Firefox and Chromium.\nBasic principles Tests must be short (1min max) and go straight to the point. Arbitrary timeouts are outlawed; a test must systematically wait for a specific event. It is possible to use polling (retry an action - a click for example - after a certain time) proposed in the Playwright’s API. All tests must be parallelizable. Tests must not point to or wait for text elements from the translation, prefer the DOM tree structure or place specific id. We’re not testing the data, but the application and its functionality. Data-specific tests should be developed in parallel. Data The data tested must be public data. The data required (infrastructure and rolling stock) for the tests are offered in the application’s json files, injected at the start of each test and deleted at the end, regardless of its result or how it is stopped, including with CTRL+C.\nThis is done by API calls in typescript before launching the actual test.\nThe data tested is the same, both locally and via continuous integration.\nAtomicity of a test Each test must be atomic: it is self-sufficient and cannot be divided.\nA test will target a single feature or component, provided it is not too large. A test will not test an entire module or application; it will necessarily be a set of tests, in order to preserve test atomicity.\nIf a test needs elements to be created or added, these operations must be carried out by API calls in typescript upstream of the test, as is done for adding data. These elements must be deleted at the end of the test, regardless of the result or how it is stopped, including by CTRL+C.\nThis allows tests to be parallelized.\nHowever, in certain cases where it is relevant, a test may contain several clearly explained and justified test subdivisions (several test() in a single describe()).\nExample of a test The requirement: “We want to test the addition of a train to a timetable”.\nadd the test infrastructure and rolling stock to the database by API calls. create project, study and scenario with choice of test infrastructure by API calls. start the test, clicking on “add one or more trains” until the presence of the trains in the timetable is verified the test passes, fails or is stopped, the project, study and scenario are deleted, along with the test rolling stock and infrastructure by API calls. NB: the test will not test all the possibilities offered by the addition of trains; this should be a specific test which would test the response of the interface for all scenarios without adding trains.\nContinue towards write code ‣\n","categories":"","description":"Recommandations for testing purpose","excerpt":"Recommandations for testing purpose","ref":"/en/docs/guides/contribute/contribute-code/tests/","tags":"","title":"Tests"},{"body":"Back-end Les tests d’intégration sont écrits avec pytest dans le dossier /tests. Chaque route décrite dans les fichiers openapi.yaml doit avoir un test d’intégration. Le test doit vérifier à la fois le format et le contenu des réponses valides et invalides. Front-end L’écriture fonctionnelle des tests est réalisée avec les Product Owners, et les développeurs choisissent une implémentation technique qui répond précisément aux besoins exprimés et qui s’intègre dans les recommandations présentes ici.\nNous utilisons Playwright pour écrire les tests bout en bout, et vitest pour écrire les tests unitaires.\nLes navigateurs testés sont pour l’instant Firefox et Chromium.\nPrincipes de base Les tests doivent être courts (1min max) et aller droit au but. Les timeout arbitraires sont proscrits, un test doit systématiquement attendre un évènement spécifique. Il est possible d’utiliser le polling (retenter une action — un clic par exemple — au bout d’un certain temps) proposé dans l’API de Playwright. Les tests doivent tous pouvoir être parallélisables. Les tests ne doivent pas pointer/attendre des éléments de texte issus de la traduction, préférer l’arborescence du DOM ou encore placer des id spécifiques. On ne teste pas les données mais l’application et ses fonctionnalités. Des tests spécifiques aux données sont à élaborer par ailleurs. Données Les données testées doivent impérativement être des données publiques. Les données nécessaires (infrastructure et matériel) aux tests sont proposées dans des fichiers json de l’application, injectées au début de chaque test et effacées à la fin peu importe son résultat ou la manière d’être stoppé, y compris par CTRL+C.\nCela se fait par des appels API en typescript avant de lancer le test à proprement parler.\nLes données testées sont les mêmes en local ou via l’intégration continue.\nAtomicité d’un test Chaque test doit être atomique : il se suffit à lui même et ne peut pas être divisé.\nUn test va cibler une fonctionnalité ou un composant, si ce dernier n’est pas trop gros. Un test ne testera pas tout un module ou tout une application, ce sera forcément un ensemble de tests afin de préserver l’atomicité des tests.\nSi un test a besoin que des éléments soient créés ou ajoutés, ces opérations doivent être opérées par des appels API en typescript en amont du test, à l’instar de ce qui est fait pour l’ajout de données. Ces éléments doivent être supprimés à l’issue du test, peu importe son résultat ou la manière d’être stoppé, y compris par CTRL+C.\nCela permettra notamment la parallélisation des tests.\nUn test peut cependant, dans certains cas de figure où cela est pertinent, contenir plusieurs sous-divisions de test, clairement explicitées, et justifiées (plusieurs test() dans un seul describe()).\nExemple de test Le besoin : « nous voulons tester l’ajout d’un train dans une grille horaire ».\najouter l’infrastructure et le matériel roulant de test dans la base de données par appels API créer projet, étude et scénario avec choix de l’infra de test par appels API début du test qui clique sur « ajouter un ou plusieurs trains » jusqu’à la vérification de la présence des trains dans la grille horaire le test a réussi, a échoué, ou est stoppé, le projet, l’étude et le scénario sont effacés, ainsi que le matériel roulant et et l’infrastructure de test par appels API NB : le test ne va pas tester toutes les possibilités offertes par l’ajout de trains, cela relève d’un test spécifique qui testerait la réponse de l’interface pour tous les cas de figure sans ajouter de trains.\nContinuer vers l’écriture de code ‣\n","categories":"","description":"Recommandations pour les tests","excerpt":"Recommandations pour les tests","ref":"/fr/docs/guides/contribute/contribute-code/tests/","tags":"","title":"Tests"},{"body":"Some definitions:\nCapacity Capacity, in this context, is the ability to reserve infrastructure elements to allow the passage of a train.\nCapacity is expressed in both space and time: the reservation of an element can block a specific zone that becomes inaccessible to other trains, and this reservation lasts for a given time interval.\nIt can be displayed on a chart, with the time on the horizontal axis and the distance traveled on the vertical axis.\nExample of a space-time chart displaying the passage of a train.\nThe colors here represent aspects of the signals, but display a consumption of the capacity as well: when these blocks overlap for two trains, they conflict.\nThere is a conflict between two trains when they reserve the same object at the same time, in incompatible configurations.\nExample of a space-time graph with a conflict: the second train is faster than the first one, they are in conflict at the end of the path, when the rectangles overlap.\nWhen simulating this timetable, the second train would be slowed down by the yellow signals, caused by the presence of the first train.\nTrain slots A train slot corresponds to a capacity reservation for the passage of a train. It is fixed in space and time: the departure time and the path taken are known. On the space-time charts in this page, a train slot corresponds to the set of blocks displayed for a train.\nNote: in English-speaking countries, these are often simply called “train paths”. But in this context, this name would be ambiguous with the physical path taken by the train.\nThe usual procedure is for the infrastructure manager (e.g. SNCF Réseau) to offers train slots for sale to railway companies (e.g. SNCF Voyageurs).\nAt a given date before the scheduled day of operation, all the train paths are allocated. But there may be enough capacity to fit more trains. Trains can fit between scheduled slots, when they are sufficiently far apart or have not found a buyer.\nThe remaining capacity after the allocation of train paths is called residual capacity. This section explains how OSRD looks for train slots in this residual capacity.\n","categories":"","description":"","excerpt":"Some definitions:\nCapacity Capacity, in this context, is the ability …","ref":"/en/docs/reference/design-docs/stdcm/domain_context/","tags":"","title":"Business context"},{"body":"Quelques définitions :\nLa capacité La capacité, dans ce contexte, correspond à la possibilité de réserver des éléments d’infrastructure pour permettre le passage d’un train.\nLa capacité s’exprime en fonction de l’espace et du temps : la réservation d’un élément peut bloquer une zone précise qui devient inaccessible aux autres trains, et cette réservation se fait sur un intervalle de temps.\nOn peut la représenter sur un graphique, avec le temps en abscisse et la distance parcourue sur un chemin en ordonnée.\nExemple d’un graphique espace-temps montrant le passage d’un train.\nLes couleurs représentent ici les aspects des signaux, mais montrent également une consommation de la capacité : quand ces blocs se superposent pour deux trains, ils sont en conflit.\nDeux trains d’une grille horaire sont en conflit quand ils réservent en même temps un même objet, dans des configurations incompatibles.\nExemple d’un graphique espace-temps avec conflit : le second train est plus rapide que le premier, ils sont en conflit sur la fin du trajet, quand les rectangles se superposent.\nEn essayant de simuler cette grille horaire, le second train serait ralentis par des signaux indiquant de ralentir, provoqués par la présence du premier train.\nLa consommation de capacité est souvent représentée sous la forme de rectangles car, dans les systèmes de signalisation les plus simples, il s’agit de réservations d’une zone fixe dans l’espace pendant un intervalle de temps donné.\nLes sillons horaires Un sillon correspond à une réservation de capacité pour le passage d’un train. Il est fixé dans l’espace et dans le temps : le temps de départ et le chemin emprunté sont connus. Sur les graphiques espace-temps de cette page, un sillon correspond à l’ensemble des blocs pour un train.\nDans un fonctionnement habituel, le gestionnaire d’infrastructure (ex : SNCF Réseau) propose des sillons à la vente pour les entreprises ferroviaires (ex : SNCF Voyageurs).\nÀ une date donnée avant le jour de circulation prévu, tous les sillons sont attribués. Mais il peut rester assez de capacité pour faire rouler plus de trains. Il est possible de placer des trains entre les sillons déjà établis, quand ces derniers sont suffisamment espacés ou n’ont pas trouvé d’acheteurs.\nLa capacité restante après l’attribution des sillons est appelée la capacité résiduelle. Le problème traité ici est la recherche de sillons dans celle-ci.\n","categories":"","description":"","excerpt":"Quelques définitions :\nLa capacité La capacité, dans ce contexte, …","ref":"/fr/docs/reference/design-docs/stdcm/domain_context/","tags":"","title":"Contexte métier"},{"body":"The first thing we need to define is how we move through the infrastructure, without dealing with conflicts yet.\nWe need a way to define and enumerate the different possible paths and explore the infrastructure graph, with several constraints:\nThe path must be compatible with the given rolling stock (loading gauge / electrification / signaling system) At any point, we need to access path properties from its start up to the considered point. This includes block and route lists. We sometimes need to know where the train will go after the point currently being evaluated, for proper conflict detection To do this, we have defined the class InfraExplorer. It uses blocks (sections from signal to signal) as a main subdivision. It has 3 sections: the current block, predecessors, and a “lookahead”.\nIn this example, the green arrows are the predecessor blocks. What happens there is considered to be immutable.\nThe red arrow is the current block. This is where we run train and signaling simulations, and where we deal with conflicts.\nThe blue arrows are part of the lookahead. This section hasn’t been simulated yet, its only purpose is to know in advance where the train will go next. In this example, it would tell us that the bottom right signal can be ignored entirely. The top path is the path being currently evaluated. The bottom section of the path will be evaluated in a different and already instanciated InfraExplorer\nThe InfraExplorer is manipulated with two main functions (the accessors have been removed here for clarity):\ninterface InfraExplorer { /** * Clone the current object and extend the lookahead by one route, for each route starting at * the current end of the lookahead section. The current instance is not modified. */ fun cloneAndExtendLookahead(): Collection\u003cInfraExplorer\u003e /** * Move the current block by one, following the lookahead section. Can only be called when the * lookahead isn't empty. */ fun moveForward(): InfraExplorer } cloneAndExtendLookahead() is the method that actually enumerates the different paths, returning clones for each possibility. It’s called when we need a more precise lookahead to properly identify conflicts, or when it’s empty and we need to move forward.\nA variation of this class can also keep track of the train simulation and time information (called InfraExplorerWithEnvelope). This is the version that is actually used to explore the infrastructure.\n","categories":"","description":"","excerpt":"The first thing we need to define is how we move through the …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/","tags":"","title":"Infrastructure exploration"},{"body":" La modélisation physique joue un rôle important dans le cœur de calcul d’OSRD. C’est elle qui nous permet de simuler la circulation des trains, et elle doit être aussi réaliste que possible.\nBilan des forces Pour calculer le déplacement du train au cours du temps, il faut d’abord calculer sa vitesse à chaque instant. Une manière simple d’obtenir cette vitesse est de passer par le calcul de l’accélération. Grâce au principe fondamental de la dynamique, l’accélération du train à chaque instant est directement dépendant des différentes forces qui lui sont appliquées : $$ \\sum \\vec{F}=m\\vec{a} $$\nTraction : La valeur de la force de traction \\(F_{mot}\\) dépend de plusieurs facteurs :\ndu matériel roulant de la vitesse du train \\(v^{\\prime}x\\), selon la courbe effort-vitesse ci-dessous : $$ {\\vec{F_{mot}}(v_{x^{\\prime}}, x^{\\prime})=F_{mot}(v_{x^{\\prime}}, x^{\\prime})\\vec{e_x^{\\prime}}} $$\nL’axe x représente la vitesse du train en [km/h], l’axe y, la valeur de la force de traction en [kN].\nde l’action du conducteur, qui accélère plus ou moins fort en fonction de l’endroit où il se trouve sur son trajet Freinage : La valeur de la force de freinage \\(F_{brk}\\) dépend elle aussi du matériel roulant et de l’action du conducteur mais possède une valeur constante pour un matériel donné. Dans l’état actuel de la modélisation, le freinage est soit nul, soit à sa valeur maximale. $$ \\vec{F_{brk}}(x^{\\prime})=-F_{brk}(x^{\\prime}){\\vec{e_{x^{\\prime}}}} $$\nUne seconde approche de la modélisation du freinage est l’approche dite horaire, car utilisée pour la production horaire à la SNCF. Dans ce cas, la décélération est fixe et le freinage ne dépend plus des différentes forces appliquées au train. Les valeurs de décélération typiques vont de 0.4 à 0.7m/s².\nRésistance à l’avancement : Pour modéliser la résistance à l’avancement du train on utilise la formule de Davis qui prend en compte tous les frottements et la résistance aérodynamique de l’air. La valeur de la résistance à l’avancement dépend de la vitesse \\(v^{\\prime}_x\\). Les coefficients \\(A\\), \\(B\\), et \\(C\\) dépendent du matériel roulant. $$ {\\vec{R}(v_{x^{\\prime}})}=-(A+Bv_{x^{\\prime}}+{Cv_{x^{\\prime}}}^2){\\vec{e_{x^{\\prime}}}} $$\nPoids (pentes + virages) : La force du poids donnée par le produit entre la masse \\(m\\) du train et la constante gravitationnelle \\(g\\) est projetée sur les axes \\(\\vec{e_x}^{\\prime}\\) et \\(\\vec{e_y}^{\\prime}\\).Pour la projection, on utilise l’angle \\(i(x^{\\prime})\\), qui est calculé à partir de l’angle de déclivité \\(s(x^{\\prime})\\) corrigé par un facteur qui prend en compte l’effet du rayon de virage \\(r(x^{\\prime})\\). $$ \\vec{P(x^{\\prime})}=-mg\\vec{e_y}(x^{\\prime})= -mg\\Big[sin\\big(i(x^{\\prime})\\big){\\vec{e_{x^{\\prime}}}(x^{\\prime})}+cos\\big(i(x^{\\prime})\\big){\\vec{e_{{\\prime}}}(x^{\\prime})}\\Big] $$\n$$ i(x^{\\prime})= s(x^{\\prime})+\\frac{800m}{r(x^{\\prime})} $$\nRéaction du sol : La force de réaction du sol compense simplement la composante verticale du poids, mais n’a pas d’impact sur la dynamique du train car elle n’a aucune composante selon l’axe \\({\\vec{e_x}^{\\prime}}\\). $$ \\vec{R_{gnd}}=R_{gnd}{\\vec{e_{y^{\\prime}}}} $$\nEquilibre des forces L’équation du principe fondamental de la dynamique projetée sur l’axe \\({\\vec{e_x}^{\\prime}}\\) (dans le référentiel du train) donne l’équation scalaire suivante :\n$$ a_{x^{\\prime}}(t) = \\frac{1}{m}\\Big [F_{mot}(v_{x^{\\prime}}, x^{\\prime})-F_{brk}(x^{\\prime})-(A+Bv_{x^{\\prime}}+{Cv_{x^{\\prime}}}^2)-mgsin(i(x^{\\prime}))\\Big] $$\nCelle-ci est ensuite simplifiée en considérant que malgré la pente le train se déplace sur un plan et en amalgamant \\(\\vec{e_x}\\) et \\(\\vec{e_x}^{\\prime}\\). La pente a toujours un impact sur le bilan des forces mais on considère que le train ne se déplace qu’horizontalement, ce qui donne l’équation simplifiée suivante :\n$$ a_{x}(t) = \\frac{1}{m}\\Big[F_{mot}(v_{x}, x)-F_{brk}(x)-(A+Bv_{x}+{Cv_{x}}^2)-mgsin(i(x))\\Big] $$\nRésolution La force motrice et la force de freinage dépendent de l’action du conducteur (il décide d’accélérer ou de freiner plus ou moins fort en fonction de la situation). Cette dépendance se traduit donc par une dépendance de ces deux forces à la position du train. La composante du poids dépend elle aussi de la position du train, car provenant directement des pentes et des virages situées sous ce dernier.\nDe plus, la force motrice dépend de la vitesse du train (selon la courbe effort vitesse) tout comme la résistance à l’avancement.\nCes différentes dépendances rendent impossible la résolution analytique de cette équation, et l’accélération du train à chaque instant doit être calculée par intégration numérique.\n","categories":"","description":"","excerpt":" La modélisation physique joue un rôle important dans le cœur de …","ref":"/fr/docs/explanation/running_time_calculation/physical_modeling/","tags":"","title":"Modélisation physique"},{"body":"La première chose à définir est comment un train se déplace sur l’infrastructure, sans prendre en compte les conflits pour l’instant.\nOn a besoin d’une manière de définir et d’énumérer les différents chemins possibles et de parcourir l’infrastructure, avec plusieurs contraintes :\nLe chemin doit être compatible avec le matériel roulant donné (électrification, gabarit, systèmes de signalisation) À n’importe quel point, on doit être en mesure d’accéder aux propriétés du chemin depuis le point de départ jusqu’au point considéré. Cela inclus les routes et les cantons. Dans certains cas, on doit savoir où le train ira après le point actuellement évalué (pour une détection de conflits correcte). Pour répondre à ce besoin, une classe InfraExplorer a été implémentée. Elle utilise les cantons (section de signal en signal) comme subdivision principale. Elle est composée de 3 sections : le canton courant, les prédécesseurs, et les cantons suivants.\nDans cet exemple, les flèches vertes sont les cantons précédents. Ce qui se produit dessus est considéré comme immuable.\nLa flèche rouge est le canton actuellement exploré. C’est à cet endroit que les simulations du train et de la signalisation sont effectuées, et que les conflits sont évités.\nLes flèches bleues sont les cantons suivants. Cette section n’est pas encore simulée, elle existe seulement pour savoir où le train ira ensuite. Dans cet exemple, elle indique que le signal en bas à droite peut être ignoré, seul le chemin du haut sera utilisé. Le chemin du bas sera évalué dans une autre instance de InfraExplorer.\nPlus de détails sur la classe et son interface sont présents sur la version anglaise de la page.\n","categories":"","description":"","excerpt":"La première chose à définir est comment un train se déplace sur …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/","tags":"","title":"Parcours de l'infrastructure"},{"body":" Physical modelling plays an important role in the OSRD core calculation. It allows us to simulate train traffic, and it must be as realistic as possible train traffic, and it must be as realistic as possible.\nForce review To calculate the displacement of the train over time, we must first calculate its speed at each instant. A simple way to obtain this speed is to calculate the acceleration. Thanks to the fundamental principle of dynamics, the acceleration of the train at each instant is directly dependent on the different forces applied to it: $$ \\sum \\vec{F}=m\\vec{a} $$\nTraction: The value of the traction force \\(F_{mot}\\) depends on several factors:\nthe rolling stock the speed of the train, \\(v^{\\prime}x\\) according to the effort-speed curve below: $$ {\\vec{F_{mot}}(v_{x^{\\prime}}, x^{\\prime})=F_{mot}(v_{x^{\\prime}}, x^{\\prime})\\vec{e_x^{\\prime}}} $$\nThe x axis represents the speed of the train in [km/h], the y axis the value of the traction force in [kN].\nthe action of the driver, who accelerates more or less strongly depending on where he is on his journey Braking : The value of the braking force \\(F_{brk}\\) also depends on the rolling stock and the driver’s action but has a constant value for a given rolling stock. In the current state of modelling, braking is either zero or at its maximum value. $$ \\vec{F_{brk}}(x^{\\prime})=-F_{brk}(x^{\\prime}){\\vec{e_{x^{\\prime}}}} $$\nA second approach to modelling braking is the so-called hourly approach, as it is used for hourly production at SNCF. In this case, the deceleration is fixed and the braking no longer depends on the different forces applied to the train. Typical deceleration values range from 0.4 to 0.7m/s².\nForward resistance: To model the forward resistance of the train, the Davis formula is used, which takes into account all the friction and aerodynamic resistance of the air. The value of the drag depends on the speed \\(v^{\\prime}_x\\). The coefficients \\(A\\), \\(B\\), et \\(C\\) depend on the rolling stock. $$ {\\vec{R}(v_{x^{\\prime}})}=-(A+Bv_{x^{\\prime}}+{Cv_{x^{\\prime}}}^2){\\vec{e_{x^{\\prime}}}} $$\nWeight (slopes + turns) : The weight force given by the product between the mass \\(m\\) of the train and the gravitational constant \\(g\\) is projected on the axes \\(\\vec{e_x}^{\\prime}\\) and \\(\\vec{e_y}^{\\prime}\\).For projection, we use the angle \\(i(x^{\\prime})\\), which is calculated from the slope angle \\(s(x^{\\prime})\\) corrected by a factor that takes into account the effect of the turning radius \\(r(x^{\\prime})\\). $$ \\vec{P(x^{\\prime})}=-mg\\vec{e_y}(x^{\\prime})= -mg\\Big[sin\\big(i(x^{\\prime})\\big){\\vec{e_{x^{\\prime}}}(x^{\\prime})}+cos\\big(i(x^{\\prime})\\big){\\vec{e_{{\\prime}}}(x^{\\prime})}\\Big] $$\n$$ i(x^{\\prime})= s(x^{\\prime})+\\frac{800m}{r(x^{\\prime})} $$\nGround Reaction : The ground reaction force simply compensates for the vertical component of the weight, but has no impact on the dynamics of the train as it has no component along the axis \\({\\vec{e_x}^{\\prime}}\\). $$ \\vec{R_{gnd}}=R_{gnd}{\\vec{e_{y^{\\prime}}}} $$\nForces balance The equation of the fundamental principle of dynamics projected onto the axis \\({\\vec{e_x}^{\\prime}}\\) (in the train frame of reference) gives the following scalar equation:\n$$ a_{x^{\\prime}}(t) = \\frac{1}{m}\\Big [F_{mot}(v_{x^{\\prime}}, x^{\\prime})-F_{brk}(x^{\\prime})-(A+Bv_{x^{\\prime}}+{Cv_{x^{\\prime}}}^2)-mgsin(i(x^{\\prime}))\\Big] $$\nThis is then simplified by considering that despite the gradient the train moves on a plane and by amalgamating \\(\\vec{e_x}\\) and \\(\\vec{e_x}^{\\prime}\\). The gradient still has an impact on the force balance, but it is assumed that the train is only moving horizontally, which gives the following simplified equation:\n$$ a_{x}(t) = \\frac{1}{m}\\Big[F_{mot}(v_{x}, x)-F_{brk}(x)-(A+Bv_{x}+{Cv_{x}}^2)-mgsin(i(x))\\Big] $$\nResolution The driving force and the braking force depend on the driver’s action (he decides to accelerate or brake more or less strongly depending on the situation). This dependence is reflected in the dependence of these two forces on the position of the train. The weight component is also dependent on the position of the train, as it comes directly from the slopes and bends below the train.\nIn addition, the driving force depends on the speed of the train (according to the speed effort curve) as does the resistance to forward motion. resistance.\nThese different dependencies make it impossible to solve this equation analytically, and the acceleration of the train at each moment must be calculated by numerical integration.\n","categories":"","description":"","excerpt":" Physical modelling plays an important role in the OSRD core …","ref":"/en/docs/explanation/running_time_calculation/physical_modeling/","tags":"","title":"Physical modeling"},{"body":"Il y a 3 principaux conteneurs déployés dans une configuration OSRD standard :\nGateway (inclut le frontend) : Sert le front-end, gère l’authentification et proxy les requêtes vers le backend. Editoast : Agit comme le backend qui interagit avec le front-end. Core : Gère les calculs et la logique métier, appelé par Editoast. Déploiement standard Le déploiement standard peut être représenté par le diagramme suivant.\nflowchart TD gw[\"gateway\"] front[\"fichiers statiques front-end\"] gw -- fichier local --\u003e front navigateur --\u003e gw gw -- HTTP --\u003e editoast editoast -- HTTP --\u003e core Les requêtes externes sont reçues par le gateway. Si le chemin demandé commence par /api, il sera transféré en utilisant HTTP vers editoast, sinon il servira un fichier avec le chemin demandé. Editoast atteint le core en utilisant HTTP si nécessaire.\nLe gateway n’est pas seulement un proxy inverse avec le bundle front-end inclus, il fournit également tous les mécanismes d’authentification : utilisant OIDC ou des tokens.\n","categories":"","description":"Comment les conteneurs fonctionnent ensemble et comment ils sont construits","excerpt":"Comment les conteneurs fonctionnent ensemble et comment ils sont …","ref":"/fr/docs/explanation/containers-architecture/","tags":"","title":"Architecture des conteneurs"},{"body":"Pour que l’outil STDCM fonctionne, il faut configurer l’environnement de recherche STDCM, une configuration stockée en base de données.\nLes champs configurables sont les suivants :\npub struct StdcmSearchEnvironment { pub infra_id: i64, pub electrical_profile_set_id: Option\u003ci64\u003e, pub work_schedule_group_id: Option\u003ci64\u003e, pub timetable_id: i64, pub search_window_begin: NaiveDateTime, pub search_window_end: NaiveDateTime, } Cette configuration est récupérée par le frontend afin que les bons objets et bornes temporelles soient utilisés de manière transparente par l’utilisateur.\nPour configurer cette environnement, vous pouvez soit :\nUtiliser l’API REST prévue à cet effet (voir l’openAPI d’editoast dans la section stdcm_search_environment) Utiliser le CLI editoast (exécutez editoast stdcm-search-env help pour plus d’informations) ","categories":"","description":"Comment configurer l'environnement de recherche STDCM","excerpt":"Comment configurer l'environnement de recherche STDCM","ref":"/fr/docs/guides/deploy/stdcm-search-env/","tags":"","title":"Configuration de l'environnement de recherche STDCM"},{"body":"There are 3 main containers deployed in a standard OSRD setup:\nGateway (includes the frontend): Serves the front end, handles authentication and proxies requests to the backend. Editoast: Acts as the backend that interacts with the front end. Core: Handles computation and business logic, called by Editoast. Standard deployment The standard deployment can be represented with the following diagram.\nflowchart TD gw[\"gateway\"] front[\"front-end static files\"] gw -- local file --\u003e front browser --\u003e gw gw -- HTTP --\u003e editoast editoast -- HTTP --\u003e core External requests are received by the gateway. If the path asked starts with /api it will be forwarded using HTTP to editoast, otherwise it will serve a file with the asked path. Editoast reach the core using HTTP if required.\nThe gateway is not only a reverse proxy with the front-end bundle included, it also provides all the authentication mechanisms: using OIDC or tokens.\n","categories":"","description":"How the containers works together and how they are built","excerpt":"How the containers works together and how they are built","ref":"/en/docs/explanation/containers-architecture/","tags":"","title":"Containers architecture"},{"body":"","categories":"","description":"Comment apporter sa pierre à l'édifice","excerpt":"Comment apporter sa pierre à l'édifice","ref":"/fr/docs/guides/contribute/","tags":"","title":"Contribuer à OSRD"},{"body":"","categories":"","description":"Learn about the how we work, and how you can work with us","excerpt":"Learn about the how we work, and how you can work with us","ref":"/en/docs/guides/contribute/","tags":"","title":"Contribute to OSRD"},{"body":"First of all, we recommend learning about the containers architecture of OSRD.\nWe will cover how to deploy OSRD within the following setups:\nUsing docker compose on a single node. Using helm on a kubernetes cluster. It is also possible to deploy each service of OSRD manually on a system, but we will not cover this topic within this guide.\nNB In order for the STDCM tool to function, you’ll need to setup the STDCM Search Environment, a configuration stored in database. See the dedicated page for more information. ","categories":"","description":"Learn how to deploy OSRD in various environments","excerpt":"Learn how to deploy OSRD in various environments","ref":"/en/docs/guides/deploy/","tags":"","title":"Deploy OSRD"},{"body":"Tout d’abord, nous recommandons de se familiariser sur l’architecture des conteneurs d’OSRD.\nNous allons couvrir comment déployer OSRD dans les configurations suivantes :\nUtiliser docker compose sur un seul nœud. Utiliser helm sur un cluster kubernetes. Il est également possible de déployer manuellement chaque service d’OSRD sur un système, mais nous ne couvrirons pas ce sujet dans ce guide.\nNB Pour que l’outil STDCM fonctionne, il faut configurer l’environnement de recherche STDCM, une configuration stockée en base de données. Consultez la page dédiée pour plus d’informations. ","categories":"","description":"Apprenez à déployer OSRD dans différents environnements","excerpt":"Apprenez à déployer OSRD dans différents environnements","ref":"/fr/docs/guides/deploy/","tags":"","title":"Déployer OSRD"},{"body":"The OSRD project includes a docker-compose.yml file designed to facilitate the deployment of a fully functional OSRD environment. Only intended for development purposes, this Docker Compose configuration could be adapted for quick, single-node deployments.\nDisclaimer This setup is designed for development only. For example no authentication is supported and the front-end is served in development mode (rebuilt on the fly). If you mean to deploy a production ready version of OSRD, please follow the Kubernetes-based deployment Prerequisites Before proceeding with the deployment, ensure that you have the following installed:\nDocker Docker Compose Configuration Overview The docker-compose.yml file defines the following services:\nPostgreSQL: A PostgreSQL database with PostGIS extension. Valkey: A Valkey server for caching. Core: The core OSRD service. Front: The front-end service for OSRD. Editoast: A OSRD service responsible for various editorial functions. Gateway: Serves as the gateway for the OSRD services. Wait-Healthy: A utility service to ensure all services are healthy before proceeding. Each service is configured with health checks, volume mounts and necessary environment variables.\nDeployment Steps Clone the Repository: First, clone the OSRD repository to your local machine. Configuration: The default configuration requires setting an environment variable for the Editoast service: ROOT_URL. It should be set to the URL pointing to the Editoast service through the gateway. For example, “http://your-domain.com/api\". You can also adjust other environment variables if needed. Build and Run: Navigate to the directory containing docker-compose.yml and run: docker-compose up --build This command builds the images and starts the services defined in the Docker Compose file.\nAccessing Services While all HTTP service are used through the gateway (http://localhost:4000), you can access directly each service using their exposed ports:\nPostgreSQL: Accessible on localhost:5432. Valkey: Accessible on localhost:6379. Core Service: Accessible on localhost:8080. Front-End: Accessible on localhost:3000. Editoast: Accessible on localhost:8090. Notes and Considerations This setup is designed for development and quick deployments. For production environments, additional considerations for security, scalability and reliability should be addressed. Ensure that the POSTGRES_PASSWORD and other sensitive credentials are securely managed, especially in production deployments. ","categories":"","description":"Using docker compose for single node deployment","excerpt":"Using docker compose for single node deployment","ref":"/en/docs/guides/deploy/docker-compose/","tags":"","title":"Docker Compose"},{"body":"Le projet OSRD inclut un fichier docker-compose.yml conçu pour faciliter le déploiement d’un environnement OSRD pleinement fonctionnel. Exclusivement destiné à des fins de développement, cette configuration Docker Compose pourrait être adaptée pour des déploiements rapides sur un seul nœud.\nAvertissement Cette configuration est prévue seulement à des fins de développement. Par exemple, aucune authentification n’est prise en charge et le front-end est déployé en mode développement (reconstruit à la volée). Si vous souhaitez déployer une version d’OSRD dédiée à un environment de production, veuillez suivre le déploiement via Kubernetes Prérequis Avant de procéder au déploiement, assurez-vous que vous avez installé :\nDocker Docker Compose Vue d’ensemble de la configuration Le fichier docker-compose.yml définit les services suivants :\nPostgreSQL : Une base de données PostgreSQL avec l’extension PostGIS. Valkey : Un serveur Valkey pour le cache. Core : Le service central OSRD. Front : Le service front-end pour OSRD. Editoast : Un service OSRD responsable de diverses fonctions d’édition. Gateway : Sert de passerelle pour les services OSRD. Wait-Healthy : Un service utilitaire pour s’assurer que tous les services sont sains avant de procéder. Chaque service est configuré avec des contrôles de santé, des montages de volumes et les variables d’environnement nécessaires.\nÉtapes du déploiement Cloner le dépôt : Tout d’abord, clonez le dépôt OSRD sur votre machine locale. Configuration : La configuration par défaut nécessite le renseignement d’une variable d’environnement pour le service Editoast: ROOT_URL. Il faut lui donner la valeur de l’URL qui pointe vers le service Editoast par la gateway. Par exemple “http://your-domain.com/api\". Vous pouvez également ajuster d’autres variables d’environnement si nécessaire. Construire et exécuter : Naviguez vers le répertoire contenant docker-compose.yml et exécutez : docker-compose up --build Cette commande construit les images et démarre les services définis dans le fichier Docker Compose.\nAccès aux services Bien que tous les services HTTP soient utilisés via la passerelle (http://localhost:4000), vous pouvez accéder directement à chaque service en utilisant leurs ports exposés :\nPostgreSQL : Accessible sur localhost:5432. Valkey : Accessible sur localhost:6379. Service Core : Accessible sur localhost:8080. Front-End : Accessible sur localhost:3000. Editoast : Accessible sur localhost:8090. Notes et considérations Cette configuration est conçue pour le développement et les déploiements rapides. Pour les environnements de production, des considérations supplémentaires en matière de sécurité, de scalabilité et de fiabilité doivent être abordées. Assurez-vous que le POSTGRES_PASSWORD et d’autres identifiants sensibles sont gérés en toute sécurité, en particulier dans les déploiements de production. ","categories":"","description":"Utiliser docker compose pour un déploiement sur un seul nœud","excerpt":"Utiliser docker compose pour un déploiement sur un seul nœud","ref":"/fr/docs/guides/deploy/docker-compose/","tags":"","title":"Docker Compose"},{"body":" This document is an annex to the main authorization design document\nThis design document is not intended to describe the exact editoast authorization API. The actual implementation may slightly differ. If major limitations were uncovered, please update this document.\nContext and requirements The following invariants were deemed worth validating:\n(high priority) role and privilege checks were performed (low priority) privilege checks are performed before changes are made / data is returned (low priority) access patterns match privilege checks Other design criterias have an impact:\n(high priority) misuse potential (high priority) usage complexity and developer experience (medium priority) ease of migration (low priority) static checks are prefered Data model Builtin roles First, we define an enum for all our builtin roles:\n#[derive(Roles, EnumSetType, Copy)] enum BuiltinRole { #[role(tag = \"infra:read\")] InfraRead, #[role(tag = \"infra:write\", implies = [InfraRead])] InfraWrite, #[role(tag = \"rolling-stock:read\")] RollingStockRead, #[role(tag = \"rolling-stock:write\", implies = [RollingStockRead])] RollingStockWrite, #[role(tag = \"timetable:read\")] TimetableRead, #[role(tag = \"timetable:write\", implies = [TimetableRead])] TimetableWrite, #[role(tag = \"operational-studies:read\", implies = [TimetableRead, InfraRead, RollingStockRead])] OperationalStudiesRead, #[role(tag = \"operational-studies:write\", implies = [OperationalStudiesRead, TimetableWrite])] OperationalStudiesWrite, } which could expand to:\n#[derive(EnumSetType, Copy)] enum BuiltinRole { InfraRead, InfraWrite, RollingStockRead, RollingStockWrite, TimetableRead, TimetableWrite, OperationalStudiesRead, OperationalStudiesWrite, } const ROLES: phf::Map\u003c\u0026'static str, BuiltinRole\u003e = phf::phf_map! { \"infra:read\" =\u003e Self::InfraRead, \"infra:write\" =\u003e Self::InfraWrite, \"rolling-stock:read\" =\u003e Self::RollingStockRead, \"rolling-stock:write\" =\u003e Self::RollingStockWrite, \"timetable:read\" =\u003e Self::TimetableRead, \"timetable:write\" =\u003e Self::TimetableWrite, \"operational-studies:read\" =\u003e Self::OperationalStudiesRead, \"operational-studies:write\" =\u003e Self::OperationalStudiesWrite, }; impl BuiltinRole { fn parse_tag(tag: \u0026str) -\u003e Option\u003cBuiltinRole\u003e { ROLES.get(tag) } fn tag(\u0026self) -\u003e \u0026'static str { match self { Self::InfraRead =\u003e \"infra:read\", Self::InfraWrite =\u003e \"infra:write\", Self::RollingStockRead =\u003e \"rolling-stock:read\", Self::RollingStockWrite =\u003e \"rolling-stock:write\", Self::TimetableRead =\u003e \"timetable:read\", Self::TimetableWrite =\u003e \"timetable:write\", Self::OperationalStudiesRead =\u003e \"operational-studies:read\", Self::OperationalStudiesWrite =\u003e \"operational-studies:write\", } } fn implies(\u0026self) -\u003e \u0026[Self] { match self { Self::InfraRead =\u003e \u0026[Self::InfraRead], Self::InfraWrite =\u003e \u0026[Self::InfraRead, Self::InfraWrite], Self::RollingStockRead =\u003e \u0026[Self::RollingStockRead], Self::RollingStockWrite =\u003e \u0026[Self::RollingStockRead, Self::RollingStockWrite], Self::TimetableRead =\u003e \u0026[Self::TimetableRead], Self::TimetableWrite =\u003e \u0026[Self::TimetableRead, Self::TimetableWrite], Self::OperationalStudiesRead =\u003e \u0026[Self::TimetableRead, Self::InfraRead, Self::RollingStockRead], Self::OperationalStudiesWrite =\u003e \u0026[Self::OperationalStudiesRead, Self::TimetableWrite], } } } Application roles Application roles are loaded from a yaml file at application startup:\napplication_roles: ops: name: \"DevOps\" description: \"Software engineers in charge of operating and maintaining the app\" implies: [admin] stdcm-customer: name: \"STDCM customer\" implies: [stdcm] operational-studies-customer: name: \"Operational studies customer\" implies: [operational-studies:read] operational-studies-analyse: name: \"Operational studies analyse\" implies: [operational-studies:write] Once loaded into editoast, app roles are resolved to a set of user roles:\ntype UserRoles = EnumSet\u003cBuiltinRole\u003e; struct AppRoleResolver(HashMap\u003cString, UserRoles\u003e); /// The API does not allow querying app roles, as it should have no impact on authorization: /// only the final resolved set of builtin roles matters. impl AppRoleResolver { fn load_from_config(\u0026path: Path) -\u003e Result\u003cSelf, E\u003e; fn resolve(\u0026self, app_role_tag: \u0026str) -\u003e Result\u003cUserRoles, E\u003e; } Resources and grants TODO: decide where to process implicit grants: database or editoast?\nenum ResourceType { Group, Project, Study, Scenario, Timetable, Infra, RollingStockCollection, } struct Grant { grant_id: u64, subject: SubjectId, privlvl: GrantPrivLvl, granted_by: UserId, granted_at: Timestamp, } async fn all_grants(conn, resource_type: ResourceType, resource_id: u64) -\u003e Vec\u003cGrant\u003e; async fn applicable_grants(conn, resource_type: ResourceType, resource_id: u64, subject_ids: Vec\u003cSubjectId\u003e) -\u003e Vec\u003cGrant\u003e; async fn revoke_grant(conn, resource_type: ResourceType, grant_id: u64); async fn update_grant(conn, resource_type: ResourceType, grant_id: u64, privlvl: GrantPrivLvl); Low level authorization API struct PrivCheck { resource_type: ResourceType, resource_id: u64, minimum_privlvl: EffectivePrivLvl, } /// The authorizer is injected into each request by a middleware. /// The middleware finds the user ID associated with the request. /// At the end of each request, it ensures roles and privileges were checked. struct Authorizer { user_id: u64, checked_roles: Option\u003cUserRoles\u003e, checked_privs: Option\u003cVec\u003cPrivCheck\u003e\u003e, }; impl FromRequest for Authorizer {} impl Authorizer { async fn check_roles( conn: \u0026mut DatabaseConnection, required_roles: \u0026[BuiltinRole], ) -\u003e Result\u003cbool, Error\u003e; async fn check_privs( conn: \u0026mut DatabaseConnection, required_privs: \u0026[PrivCheck], ) -\u003e Result\u003cbool, Error\u003e; } This API is then used as follows:\n#[post(\"/project/{project_id}/study/{study_id}/scenario\")] async fn create_scenario( path: Path\u003c(i64, i64)\u003e, authz: Authorizer, db_pool: web::Data\u003cDatabasePool\u003e, Json(form): Json\u003cScenarioCreateForm\u003e, ) -\u003e Result\u003cResponse, Error\u003e { let conn, db_pool.get().await; let (project_id, study_id) = path.into_inner(); // validate that study.scenario == scenario authz.check_roles(\u0026mut conn, \u0026[BuiltinRoles::OperationalStudiesWrite]).await?; authz.check_privs(\u0026mut conn, \u0026[(Study, study_id, Creator).into()]).await?; // create the object // ... Ok(...) } High level authorization API 🤔 Proposal: fully dynamic checks This proposal suggests dynamically enforcing all authorization invariants:\nrole and privilege checks were performed: The authorizer records all checks, and panics / logs an error if no check is made privilege checks are performed before changes are made / data is returned: checked database accesses (the default) cannot be made before commiting authorization checks. No more authorization check can be made after commiting. access patterns match privilege checks: Check database access functions ensure a prior check was made using the Authorizer’s check log. Each database access method thus gets two variants:\na checked variant (the default), which takes the Authorizer as a parameter. This variants panics if:\na resource is accessed before authorization checks are commited a resource is accessed without a prior authorizer check. an unchecked variant. its use should be limited to:\nfetching data for authorization checks updating modification dates #[post(\"/project/{project_id}/study/{study_id}/scenario\")] async fn create_scenario( path: Path\u003c(i64, i64)\u003e, authz: Authorizer, db_pool: web::Data\u003cDatabasePool\u003e, Json(form): Json\u003cScenarioCreateForm\u003e, ) -\u003e Result\u003cResponse, Error\u003e { let conn, db_pool.get().await; let (project_id, study_id) = path.into_inner(); // Check if the project and the study exist let (mut project, mut study) = check_project_study_conn(\u0026mut conn, project_id, study_id).await?; authz.check_roles(\u0026mut conn, \u0026[BuiltinRoles::OperationalStudiesWrite])?; authz.check_privs(\u0026mut conn, \u0026[(Study, study_id, Creator).into()])?; // all checks done, checked database accesses allowed authz.commit(); // ... // create the scenario let scenario: Scenario = data.into_scenario(study_id, timetable_id); let scenario = scenario.create(db_pool.clone(), \u0026authz).await?; // Update study last_modification field study.update_last_modified(conn).await?; // Update project last_modification field project.update_last_modified(conn).await?; // ... Ok(...) } Bonus proposal: require roles using macros TODO: check if this is worth keeping\nThen, we annotate each endpoint that require role restrictions with requires_roles:\n#[post(\"/scenario\")] #[requires_roles(BuiltinRoles::OperationalStudiesWrite)] async fn create_scenario( user: web::Header\u003cGwUserId\u003e, db_pool: web::Data\u003cDatabasePool\u003e ) -\u003e Result\u003cResponse, Error\u003e { todo!() } which may expand to something similar to:\nasync fn create_scenario( user: web::Header\u003cGwUserId\u003e, db_pool: web::Data\u003cDatabasePool\u003e ) -\u003e Result\u003cResponse, Error\u003e { { let conn = \u0026mut db_pool.get().await?; let required_roles = [BuiltinRoles::OperationalStudiesWrite]; if !editoast_models::check_roles(conn, \u0026user_id, \u0026required_roles).await? { return Err(403); } } async move { todo!() }.await } 🤔 Proposal: Static access control This proposal aims at improving the Authorizer descibed above by building on it a safety layer that encodes granted permissions into the type system.\nThis way, if access patterns do not match the privilege checks performed beforehand, the program will fail to compile and precisely pinpoint the privilege override as a type error.\nTo summarize, the Authorizer allows us to:\nPre-fetch the user of the request and its characteristics as a middleware Check their roles Maintain a log of authorization requests on specific ressources, and check if they hold Guarantees that no authorization will be granted passed a certain point (commit function) At the end of an endpoint, checks that permissions were granted or panic!s otherwise While all these checks are performed at runtime, those can be tested rather trivially in unit tests.\nHowever, the Authorizer cannot check that the endpoints actually respect the permission level they asked for when they access the DB. For example, an endpoint might ask for Read privileges on a Timetable, only to delete it afterwards. This is trivial to check if the privilege override happens in the same function, but it can be much more vicious if that happens conditionally, in another function, deep down the call stack. For the same reasons, refactoring code subject to authorizations becomes much more risky and error prone.\nHence, for both development and review experience, to ease writing and refactoring authorizing code, to be confident our system works, and for general peace of mind, we need a way to ensure that an endpoint won’t go beyond the privilege level it required for all of its code paths.\nWe can do that either statically or dynamically.\nDynamic access pattern checks Let’s say we keep the Authorizer as the high-level API for authorization. It holds a log of grants. Therefore, any DB operation that needs to be authorized must, in addition to the conn, take an Arc\u003cAuthorizer\u003e parameter and let the operation check that it’s indeed authorized. For example, every retrieve(conn, authorizer, id) operation would ask the authorizer the permission before querying the DB.\nThis approach works and has the benefit of being easy to understand, but does not provide any guarantee that the access paterns match the granted authorizations and that privilege override cannot happen. A way to ensure that would be to thoroughly test each endpoint and ensure that the DB accesses panic in expected situations. Doing so manually is extremely tedious and fragile in the long run, so let’s focus on automated tests. To make sure that, at any moment, each endpoint doesn’t override its privileges, we’d need a test for each releveant privilege level and for each code path accessing ressources. Admittedly this would be great, but:\nit heavily depends on test coverage (which we don’t have) to make sure no code path is left out, i.e. that no test is missing it’s unrealistic given the current state of things and how fast editoast changes tests would be extremely repetitive, and mistakes will happen the test suite of an endpoint now not only depends on what it should do, but also on how it should do it: i.e. to know how to test your endpoint, you need to know precisely what DB operations will be performed, under what conditions, on all code paths, and replicate that when refactoring code subject to authorization that’s shared across several endpoints, the tests of each of these endpoints would need to be examined to ensure no check goes missing unless we postpone the creation of these tests and accept a lower level of confidence in our system, even temporarily(TM), the authz migration would be slowed down significantly Or we could just accept the risk.\nOr we could statically ensure that no endpoint override its requested privileges, using the typesystem, and be sure that such issues can (almost) never arise.\nStatic checks The idea is to provide an high-level API for authorization, on top of the Authorizer. It encodes granted privileges into the typesystem. For example, for a request GET /timetable/42, the endpoint will ask from the Authorizer an Authz\u003cTimetable, Read\u003e object:\nlet timetable_authz: Authz\u003cTimetable, Read\u003e = authorizer.authorize(\u0026[42])?; The authorizer does two things here:\nChecks that the privilege level of the user allows them to Read on the timetable ID#42. Builds an Authz object that stores the ID#42 for later checks, which encodes in the type system that we have a Read authorization on some Timetable ressources. Then, after we authorizer.commit();, we can use the Authz to effectively request the timetable:\nlet timetable: Timetable = timetable_authz.retrieve(conn, 42)?; The Authz checks that the ID#42 is indeed authorized before forwarding the call the modelv2::Retrieve::retrieve function that performs the query. However, if by mistake we wrote:\nlet timetable = timetable_authz.delete(conn, 42)?; we’d get a compilation error such as Trait AuthorizedDelete is not implemented for Authz\u003cTimetable, Read\u003e, effectively preventing a privilege override statically.\nOn a more realistic example:\nimpl Scenario { fn remove( self, conn: \u0026mut DatabaseConnection, scenario_authz: Authz\u003cSelf, Delete\u003e, study_authz: Authz\u003cStudy, Update\u003e, ) -\u003e Result\u003c(), Error\u003e { // open transaction scenario_authz.delete(conn, self.id)?; let cs = Study::changeset().last_update(Datetime::now()); study_authz.update(conn, self.study_id, cs)?; Ok(()) } } This approach brings several advantages:\ncorrectness: the compiler will prevent any privilege override for us readability: if a function requires some form of authorization, it will show in its prototype ease of writing: we can’t write DB operations that ultimately wouldn’t be authorized, avoiding a potential full rewrite once we notice the problem (and linting is on our side to show problems early) more declarative: if you want to read an object, you ask for a Read permission, the system is then responsible for checking the privilege level and map that to a set of allowed permissions. This way we abstract a little over the hierarchy of privileges a ressource can have. ease of refactoring: thanks rustc ;) flexibility: since the Authz has a reference to the Authorizer, the API mixes well with more dynamic contexts (should we need that in the future) migration shouldn’t be too complex or costly since the Authz wraps the ModelV2 traits will require changes in the same areas that would be impacted by a dynamic checker, no more, no less (even in the dynamic context mentioned above we still need to pass the Arc\u003cAuthorizer\u003e down the call stack) contamination: admittedly, this API is slightly more contaminating than just passing an Arc\u003cAuthorizer\u003e everywhere. However, this issue is mitigated on several fronts: most endpoints in editoast either access the DB in the endpoint function itself, or in at most one or two function calls deep. So the contamination likely won’t spread far and the migration shouldn’t take much more time. if we notice that a DB call deep down the call stack requires an Authz\u003cT, _\u003e that we need to forward through many calls, it’s probably pathological of a bad architecture The following sections explore how to use this API:\nto define authorized ressources implement the effective privilege level logic to deal with complex ressources (here Study) which need custom authorization rules and that are not atomic (the budgets follow different rules than the rest of the metadata) to implement an endpoint that require different permissions (create_scenario) Actions We define all actions our Authz is able to expose at both type-level and at runtime (classic CRUD + Append for exploitation studies).\nmod action { struct Create; struct Read; struct Update; struct Delete; struct Append; enum Cruda { Create, Read, Update, Delete, Append, } trait AuthorizedAction { fn as_cruda() -\u003e Cruda; } impl AuthorizedAction for Create; impl AuthorizedAction for Read; impl AuthorizedAction for Update; impl AuthorizedAction for Delete; impl AuthorizedAction for Append; } The motivation behind this is that at usage, we don’t usually care about the privilege of a user over a ressource. We only care, if we’re about to read a ressource, whether the user has a privilege level high enough to do so.\nThe proposed paradigm here is to ask the permission to to an action over a ressource, and let the ressource definition module decide (using its own effective privilege hierarchy) whether the action is authorized or not.\nStandard and custom effective privileges We need to define the effective privilege level for each ressource. For most ressources, a classic Reader \u003c Writer \u003c Owner is enough. So we expose that by default, leaving the choice to each ressource to provide their own.\nWe also define an enum providing the origin of a privilege, which is a useful information for permission sharing.\n// built-in the authorization system #[derive(PartialOrd, PartialEq)] enum StandardPrivilegeLevel { Read, Write, Own, } enum StandardPrivilegeLevelOrigin { /// It's an explicit privilege User, /// The implicit privilege comes from a group the user belongs to Group, /// The implicit privilege is granted publicly (authz_grant_xyz.subject IS NULL) Public, } trait PrivilegeLevel: PartialOrd + PartialEq { type Origin; } impl PrivilegeLevel for StandardPrivilegeLevel { type Origin = StandardPrivilegeLevelOrigin; } Grant definition Then we need to associate to each grant in DB its effective privilege level and origin.\n// struct AuthzGrantInfra is a struct that models the table authz_grant_infra impl EffectiveGrant for AuthzGrantInfra { type EffectivePrivilegeLevel = StandardPrivilegeLevel; async fn fetch_grants( conn: \u0026mut DbConnection, subject: \u0026Subject, keys: \u0026[i64], ) -\u003e GrantMap\u003cSelf::EffectivePrivilegeLevel\u003e? { crate::tables::authz_grants_infra.filter(... } } where GrantMap\u003cPrivilegeLevel\u003e is an internal representation of a collection of grants (implicit and explicit) with some privilege level hierarchy (custom or not).\nRessource definition Each ressource is then associated to a model and a grant type. We also declare which actions are allowed based on how we want the model to be used given the effective privilege of the ressource in DB.\nThe RessourceType is necessary for the dynamic context of the underlying Authorizer.\nimpl Ressource for Infra { type Grant = AuthzGrantInfra; const TYPE: RessourceType = RessourceType::Infra; /// Returns None is the action is prohibited fn minimum_privilege_required(action: Cruda) -\u003e Option\u003cSelf::Grant::EffectivePrivilegeLevel\u003e { use Cruda::*; use StandardPrivilegeLevel as lvl; Some(match action { Read =\u003e lvl::Read, Create | Update | Append =\u003e lvl::Write, Delete =\u003e lvl::Own, }) } } And that’s it!\nThe rest of the mechanics are located within the authorization system.\nA more involved example: Studies //////// Privilege levels enum StudyPrivilegeLevel { ReadMetadata, // a scenario of the study has been shared Read, Append, // can only create scenarios Write, Own, } enum StudyPrivilegeLevelOrigin { User, Group, Project, // the implicit privilege comes from the user's grants on the study's project Public, } impl PrivilegeLevel for StudyPrivilegeLevel { type Origin = StudyPrivilegeLevelOrigin; } ///////// Effective grant retrieval impl EffectiveGrant for AuthzGrantStudy { type EffectivePrivilegeLevel = StudyrivilegeLevel; async fn fetch_grants( conn: \u0026mut DbConnection, subject: \u0026Subject, keys: \u0026[i64], ) -\u003e GrantMap\u003cSelf::EffectivePrivilegeLevel\u003e? { // We implement here the logic of implicit privileges where an owner // of a project is also owner of all its studies crate::tables::authz_grants_study .filter(...) .inner_join(crate::tables::study.on(...)) .inner_join(crate::tables::project.on(...)) .inner_join(crate::tables::authz_grants_project.on(...)) } } //////// Authorized ressources /// Budgets of the study (can be read and updated by owners) struct StudyBudgets { ... } impl Ressource for StudyBudgets { type Grant = AuthzGrantStudy; const TYPE: RessourceType = RessourceType::Study; fn minimum_privilege_required(action: Cruda) -\u003e Option\u003cStudyPrivilegeLevel\u003e { use Cruda::*; use StudyPrivilegeLevel as lvl; Some(match action { Read | Update =\u003e lvl::Own, _ =\u003e return None, }) } } /// Non-sensitive metadata available to users with privilege level MinimalMetadata (can only be read) struct StudyMetadata { ... } impl Ressource for StudyMetadata { type Grant = AuthzGrantStudy; const TYPE: RessourceType = RessourceType::Study; fn minimum_privilege_required(action: Cruda) -\u003e Option\u003cStudyPrivilegeLevel\u003e { use Cruda::*; use StudyPrivilegeLevel as lvl; Some(match action { Read =\u003e lvl::ReadMetadata, _ =\u003e return None, }) } } /// A full study (can be created, read, updated, appended and deleted) struct Study { ... } impl Ressource for Study { type Grant = AuthzGrantStudy; const TYPE: RessourceType = RessourceType::Study; fn minimum_privilege_required(action: Cruda) -\u003e Option\u003cStudyPrivilegeLevel\u003e { use Cruda::*; use StudyPrivilegeLevel as lvl; Some(match action { Read =\u003e lvl::Read, Append =\u003e lvl::Append, Create =\u003e lvl::Create, Update =\u003e lvl::Write, Delete =\u003e lvl::Own, }) } } Concrete endpoint definition #[post(\"/scenario\")] async fn create_scenario( authorizer: Arc\u003cAuthorizer\u003e, conn: DatabaseConnection, db_pool: web::Data\u003cDatabasePool\u003e, Json(form): Json\u003cScenarioCreateForm\u003e, path: Path\u003c(i64, i64)\u003e, authz: Authorizer, ) -\u003e Result\u003cResponse, Error\u003e { let conn, db_pool.get().await; let (project_id, study_id) = path.into_inner(); let ScenarioCreateForm { infra_id, timetable_id, .. } = \u0026form; authorizer.authorize_roles(\u0026mut conn, \u0026[BuiltinRoles::OperationalStudiesWrite]).await?; let _ = authorizer.authorize::\u003cTimetable, Read\u003e(\u0026mut conn, \u0026[timetable_id]).await?; let _ = authorizer.authorize::\u003cInfra, Read\u003e(\u0026mut conn, \u0026[infra_id]).await?; let study_authz: Authz\u003cStudy, Append\u003e = authorizer.authorize(\u0026mut conn, \u0026[study_id]).await?; authorizer.commit(); let response = conn.transaction(move |conn| async { let scenario: Scenario = study_authz.append(\u0026mut conn, form.into()).await?; scenario.into_response() }).await?; Ok(Json(response)) } ","categories":"","description":"","excerpt":" This document is an annex to the main authorization design document …","ref":"/en/docs/reference/design-docs/auth/editoast-internal-api/","tags":"","title":"Editoast internal authorization API"},{"body":"Description Chaque élément mobile, aiguille ou passage à niveau, a une liste d’états possibles. Ces états sont mutuellement exclusifs.\nDépendances statique une liste d’élements mobiles statique liste des états possibles de chaque élément mobile Opérations possibles observer un élément mobile verrouiller / déverrouiller un élément mobile bouger un élément mobile ","categories":"","description":"Gère l'état des organes de commande des aiguilles, passages à niveau, …","excerpt":"Gère l'état des organes de commande des aiguilles, passages à niveau, …","ref":"/fr/docs/reference/design-docs/interlocking/movable-elements/","tags":"","title":"Éléments mobiles"},{"body":"La Helm Chart du projet OSRD fournit une solution pour déployer les services OSRD dans un environnement Kubernetes de manière standardisée. Ce document décrit les options de configuration disponibles dans le Helm Chart.\nPrérequis Avant de procéder au déploiement, assurez-vous que vous avez installé :\nUn cluster Kubernetes opérationnel Une base de données PostgreSQL avec PostGIS Un serveur Valkey (utilisé pour le cache) Le serveur de tuiles Le serveur de tuiles est le composant responsable de la génération des tuiles cartographiques vectorielles. Il est recommandé de le séparer du Editoast standard lors de l’exécution d’une configuration de production, car Editoast ne peut pas être mis à l’échelle horizontalement (il est stateful).\nVous pouvez visualiser le déploiement recommandé ici :\nflowchart TD gw[\"gateway\"] front[\"fichier statiques front-end\"] gw -- fichier local --\u003e front navigateur --\u003e gw gw -- HTTP --\u003e editoast gw -- HTTP --\u003e tileserver-1 gw -- HTTP --\u003e tileserver-2 gw -- HTTP --\u003e tileserver-n... editoast -- HTTP --\u003e core Le Helm Chart utilise leHorizontalPodAutoscaler de Kubernetes pour lancer autant de serveurs de tuiles que nécessaire en fonction de la charge de travail.\nConfiguration de la Helm Chart (values) Le Helm Chart est configurable à travers les valeurs suivantes :\nService Core core : Configuration pour le service central OSRD. internalUrl : URL interne pour la communication entre services. image : Image Docker à utiliser. pullPolicy : Politique de récupération de l’image. replicaCount : Nombre de réplicas. service : Type de service et configuration des ports. resources, env, annotations, labels, nodeSelector, tolerations, affinity : Diverses options de déploiement Kubernetes. Service Editoast editoast : Configuration pour le service Editoast. Comprend des options similaires à core pour le déploiement Kubernetes. init : Configuration d’initialisation. Serveur de tuiles tileServer : Service Editoast spécialisé qui sert uniquement des tuiles cartographiques vectorielles. enabled : Définir sur true pour activer la fonctionnalité de serveur de tuiles. image : Image Docker à utiliser (généralement la même que Editoast). replicaCount : Nombre de réplicas, permettant la mise à l’échelle horizontale. hpa : Configuration de l’Horizontal Pod Autoscaler. Autres options standard de déploiement Kubernetes. Gateway gateway : Configuration pour le gateway OSRD. Comprend des options de service, d’ingress et d’autres options de déploiement Kubernetes. config : Configurations spécifiques pour l’authentification et les proxys de confiance. Déploiement Le chart est disponible dans le dépôt OCI ghcr. Vous pouvez trouver 2 versions de la chart :\nCharts stables : oci://ghcr.io/OpenRailAssociation/charts/osrd Charts de développement : oci://ghcr.io/OpenRailAssociation/charts/osrd-dev Pour déployer les services OSRD en utilisant Helm :\nConfigurer les valeurs : Ajustez les valeurs selon vos besoins de déploiement.\nInstaller le Chart : Utilisez la commande helm install pour installer la chart dans votre cluster Kubernetes.\nhelm install osrd oci://ghcr.io/OpenRailAssociation/charts/osrd -f values.yml ","categories":"","description":"Utilisation de Helm pour les déploiements Kubernetes","excerpt":"Utilisation de Helm pour les déploiements Kubernetes","ref":"/fr/docs/guides/deploy/kubernetes/","tags":"","title":"Kubernetes avec Helm"},{"body":"The OSRD project’s Helm Chart provides a flexible and efficient way to deploy OSRD services in a Kubernetes environment. This document outlines the configuration options available in the Helm Chart, focusing on each service component.\nPrerequisites Before proceeding with the deployment, ensure that you have the following installed:\nA Kubernetes cluster up and running A PostgreSQL database with PostGIS A Valkey server (used for caching) The tileserver Tileserver is the component responsible for generating vector map tiles. It is recommended to separate it from standard Editoast while running a production setup since Editoast cannot be scaled horizontally (it is stateful).\nYou can visualize the recommended deployment here:\nflowchart TD gw[\"gateway\"] front[\"front-end static files\"] gw -- local file --\u003e front browser --\u003e gw gw -- HTTP --\u003e editoast gw -- HTTP --\u003e tileserver-1 gw -- HTTP --\u003e tileserver-2 gw -- HTTP --\u003e tileserver-n... editoast -- HTTP --\u003e core The Helm chart leverages Kubernete’s HorizontalPodAutoscaler in order to spawn as much tileserver as required for the current workload.\nChart Values Overview The Helm Chart is configurable through the following values:\nCore Service core: Configuration for the core OSRD service. internalUrl: Internal URL for service communication. image: Docker image to use. pullPolicy: Image pull policy. replicaCount: Number of replicas. service: Service type and port configuration. resources, env, annotations, labels, nodeSelector, tolerations, affinity: Various Kubernetes deployment options. Editoast Service editoast: Configuration for the Editoast service. Includes similar options as core for Kubernetes deployment. init: Initialization configuration. Tile Server tileServer: Specialized Editoast service that serves only vector map tiles. enabled: Set to true to enable tile server functionality. image: Docker image to use (typically the same as Editoast). replicaCount: Number of replicas, allowing for horizontal scaling. hpa: Horizontal Pod Autoscaler configuration. Other standard Kubernetes deployment options. Gateway gateway: Configuration for the OSRD gateway. Includes service, ingress, and other Kubernetes deployment options. config: Specific configurations for authentication and trusted proxies. Deployment The chart is available at ghcr OCI repository. You can find 2 Helm charts:\nStable charts: oci://ghcr.io/OpenRailAssociation/charts/osrd Dev charts: oci://ghcr.io/OpenRailAssociation/charts/osrd-dev To deploy the OSRD services using this Helm Chart:\nConfigure Values: Adjust the values in the Helm Chart to suit your deployment needs.\nInstall Chart: Use Helm to install the chart into your Kubernetes cluster.\nhelm install osrd oci://ghcr.io/OpenRailAssociation/charts/osrd -f values.yml ","categories":"","description":"Using Helm for Kubernetes deployments","excerpt":"Using Helm for Kubernetes deployments","ref":"/en/docs/guides/deploy/kubernetes/","tags":"","title":"Kubernetes with Helm"},{"body":"Tout est présenté dans un site dédié https://design.osrd.fr\nUn « design system » est en cours d’élaboration.\n","categories":"","description":"Les couleurs, la police, les usages...","excerpt":"Les couleurs, la police, les usages...","ref":"/fr/docs/guides/design/","tags":"","title":"Le design d'OSRD"},{"body":"Vous pouvez télécharger chaque logo indépendamment en cliquant directement dessus, ou tous les logos compressés dans un fichier zip.\nIl est conseillé de bien choisir le logo à utiliser en fonction du fond sur lequel vous voulez l’afficher.\nLa modification, ajout ou suppression de l’ombrage autre que tel que présenté dans les logos ne sont pas autorisés (cela est valable plus globalement dans tout le design, le choix de mettre des ombres portées fait partie des réflexions de design, ce n’est pas un élément variable).\nOfficiel Officiel pour les fonds sombres Blanc Noir Favicons, logos seuls 🚫 Ce qu’on ne doit pas faire Trop petit (\u003c 16px de hauteur) Disproportion Changer la couleur du texte ou l’ombre portée Changer le sens Déformation ✅ Ce qu’on peut faire Modification de la couleur interne pour un évènement Utilisation seule du logo (sans le texte) Les couleurs Ces couleurs sont celles du logo, elles ne sont pas à confondre avec celles du design global de l’interface d’OSRD.\n#786ABF #C7B2DE\n","categories":"","description":"Le logo d'OSRD, ses variantes, et son usage","excerpt":"Le logo d'OSRD, ses variantes, et son usage","ref":"/fr/docs/guides/logo/","tags":"","title":"Le logo"},{"body":"You can download each logo independently by clicking directly on it, or all the logos compressed into a zip file.\nIt is advisable to carefully choose the logo you want to use, depending on the background on which you want to display it.\nModification, addition or deletion of the shading other than as presented in the logos are not authorised (this applies more generally throughout the design, the choice to use drop shadows is part of the design considerations, it is not a variable element).\nOfficial Official for dark backgrounds White Black Favicons, logo without text 🚫 What you can’t do Too small (\u003c 16px height) Disproportion Change the text colour or drop shadow Changing direction Deformation ✅ What you can do Changing the internal colour for a specific event Use of logo only (without text) Colors These colours are those of the logo and should not be confused with those of the overall design of the OSRD interface.\n#786ABF #C7B2DE\n","categories":"","description":"The OSRD logo, its variants, and its use","excerpt":"The OSRD logo, its variants, and its use","ref":"/en/docs/guides/logo/","tags":"","title":"Logo"},{"body":"Everything is presented on a dedicated website https://design.osrd.fr\nA “design system” is being developed.\n","categories":"","description":"Colours, fonts, uses...","excerpt":"Colours, fonts, uses...","ref":"/en/docs/guides/design/","tags":"","title":"OSRD's design"},{"body":" This work is pending implementation, and has not yet been adjusted to reflect potential required adjustments.\nAfter two years of extending a fairly simple simulation engine, it appeared that fundamental changes are required to meet expectations.\nSystem requirements The new system is expected to:\nhandle reactions to signaling handle rich train state (pantograph position, battery state) allow for different margin algorithms integrate driver behavior properties be easy to integrate with timetable v2 handle both: simulations of a full trip, with a complete known path, possibly following a schedule simulations where the path is discovered incrementally provide a low-level API, usable independently In the long-term, this system is also expected to:\nbe used to drive multi-train simulations handling switching rolling stock at stops Concepts flowchart TD subgraph Input InitTrainState[initial train state] PathPhysicsProps[path physics properties] AbstractDrivingInstructions[abstract driving instructions] TargetSchedule[target schedule] end DrivingInstructionCompiler([driving instruction compiler]) ConcreteDrivingInstructions[driving instructions + limits] ScheduleController([schedule controller]) DriverBehaviorModule([driver behavior module]) TargetSchedule --\u003e ScheduleController ScheduleController -- adjusts slowdown coefficient --\u003e DriverBehaviorModule AbstractDrivingInstructions --\u003e DrivingInstructionCompiler PathPhysicsProps --\u003e DrivingInstructionCompiler ScheduleController -- tracks train state --\u003e TrainSim DriverBehaviorModule -- makes decisions --\u003e TrainSim ConcreteDrivingInstructions --\u003e DriverBehaviorModule DrivingInstructionCompiler --\u003e ConcreteDrivingInstructions InitTrainState --\u003e ScheduleController TrainSim --\u003e SimResults TrainSim([train simulator]) SimResults[simulation result curve] Target schedule The target schedule is a list of target arrival times at points specified along the path. To respect the schedule, the train may have to not use its maximum traction.\nTrain state The train state is a vector of properties describing the train at a given point in time.\nposition speed position of pantographs driver reaction times ? battery state ? time elapsed since the last update Driving instructions Driving instructions model what the train has to do along its path. They are linked to conditions on their application, and can interact with each other. They are generated using domain constraints such as speed limits or stops.\nSee the dedicated page for more details.\nPath properties Path properties are the physical properties of the path, namely elevation, curves and electrification.\nDriver behavior module The driver behavior modules update the train state based on:\nthe current train state the path properties the driving instructions a slowdown coefficient (1 = no slowdown, 0 = full stop) The train state changes should be physically realistic.\nSee the dedicated page for more details.\nSchedule controller The schedule controller manages the slowdown coefficient given to the driver behavior module in order to respect the target schedule.\nIt adjusts the slowdown coefficient iteratively, using a dichotomous search, re-simulating the train behavior between two time-targeted points.\nSimulation results The output of the simulation is the list of train states at each time step.\nDesign overview The main idea of the new train simulator is to have a simulation which is computed step by step and not post-processed. This would ensure the physical consistency of the simulation.\nThe challenge is then to add ways to lose some time, in order to respect the target schedule.\nThis is done by iterating over the sections between two scheduled points, while adjusting a slowdown factor. This slowdown factor would be used to control how the driver behavior module would lose time while still being physically realistic.\nSee the driver behavior module dedicated page for more details.\nIn order to accommodate an infrastructure which could change with time (like signals), we introduce driving instructions. These instructions are generated from the path properties and the target schedule, and are used to update the train state. Instructions can be conditional, and can interact with each other.\nThe algorithm is described in detail in the dedicated page.\nDesign limits trains do not anticipate margin transitions: only the next target arrival time matters for finding the slowdown factor ","categories":"","description":"","excerpt":" This work is pending implementation, and has not yet been adjusted to …","ref":"/en/docs/reference/design-docs/train-sim-v3/overview/","tags":"","title":"Overview"},{"body":"Cette section documente le processus de création d’une publication d’OSRD.\n","categories":"","description":"Section sur les releases","excerpt":"Section sur les releases","ref":"/fr/docs/guides/release/","tags":"","title":"Publication"},{"body":"This section documents the process around creating a release of OSRD.\n","categories":"","description":"Release section","excerpt":"Release section","ref":"/en/docs/guides/release/","tags":"","title":"Release"},{"body":"Each signaling system has:\nA unique identifier (a string). Its signal state type, which enables deducing: The graphical representation of the signal How a train would react to the signal If the signal state constrains Movement Authority The signal parameter types, names and description, which enable front-end edition of signal parameters. The block and route conditions, which enable evaluating whether a signal delimits blocks or routes, given its parameters. { # unique identifier for the signaling system \"id\": \"BAL\", \"version\": \"1.0\", # the schema of the dynamic state of signals of this type \"signal_state\": [ {\"kind\": \"enum\", \"field_name\": \"aspect\", values: [\"VL\", \"A\", \"S\", \"C\"]}, {\"kind\": \"flag\", \"field_name\": \"ralen30\"}, {\"kind\": \"flag\", \"field_name\": \"ralen60\"}, {\"kind\": \"flag\", \"field_name\": \"ralen_rappel\"} ], # describes static properties of the signal \"signal_properties\": [ {\"kind\": \"flag\", \"field_name\": \"Nf\", \"display_name\": \"Non-franchissable\"}, {\"kind\": \"flag\", \"field_name\": \"has_ralen30\", \"default\": false, \"display_name\": \"Ralen 30\"}, {\"kind\": \"flag\", \"field_name\": \"has_rappel30\", \"default\": false, \"display_name\": \"Rappel 30\"}, {\"kind\": \"flag\", \"field_name\": \"has_ralen60\", \"default\": false, \"display_name\": \"Ralen 60\"}, {\"kind\": \"flag\", \"field_name\": \"has_rappel60\", \"default\": false, \"display_name\": \"Rappel 60\"} ], # describes dynamic properties of the signal. These can be set on a per-route basis \"signal_parameters\": [ {\"kind\": \"flag\", \"field_name\": \"short_block\", \"default\": false, \"display_name\": \"Short block\"}, {\"kind\": \"flag\", \"field_name\": \"rappel30\", \"default\": false, \"display_name\": \"Rappel 30\"}, {\"kind\": \"flag\", \"field_name\": \"rappel60\", \"default\": false, \"display_name\": \"Rappel 60\"} ], # these are C-like boolean expressions: # true, false, \u003cflag\u003e, \u003cenum\u003e == value, \u0026\u0026, || and ! can be used # used to evaluate whether a signal is a block boundary. Only properties can be used, not parameters. \"block_boundary_when\": \"true\", # used to evaluate whether a signal is a route boundary. Only properties can be used, not parameters. \"route_boundary_when\": \"Nf\", # A predicate used evaluate whether a signal state can make a train slow down. Used for naive conflict detection. \"constraining_ma_when\": \"aspect != VL\" } ","categories":"","description":"","excerpt":"Each signaling system has:\nA unique identifier (a string). Its signal …","ref":"/en/docs/reference/design-docs/signaling/signaling-systems/","tags":"","title":"Signaling systems"},{"body":"In order for the STDCM tool to function, you’ll need to setup the STDCM Search Environment, a configuration stored in database.\nThe configurable fields are as such:\npub struct StdcmSearchEnvironment { pub infra_id: i64, pub electrical_profile_set_id: Option\u003ci64\u003e, pub work_schedule_group_id: Option\u003ci64\u003e, pub timetable_id: i64, pub search_window_begin: NaiveDateTime, pub search_window_end: NaiveDateTime, } This configuration is queried by the frontend. That way, the right objects and time bounds are used transparently by the user.\nIn order to setup this config, you can either\nUse the provided REST API (see the editoast openAPI in the stdcm_search_environment section) Use the provided editoast cli (run editoast stdcm-search-env help for more information) ","categories":"","description":"How to configure the STDCM search environment","excerpt":"How to configure the STDCM search environment","ref":"/en/docs/guides/deploy/stdcm-search-env/","tags":"","title":"STDCM search environment configuration"},{"body":"Regardless of your operating system, docker requires linux to operate. When used on a different operating system, docker relies on virtual machines to build and run images.\nThere are two main types of docker installations:\ndocker engine is the usual docker command line application docker desktop is a GUI app that also manages virtualization Here’s what we suggest:\nIf you’re on linux, install docker engine using your package manager If you’re on MacOS / Windows, install docker desktop if you are allowed to If you’re on windows and want to get docker running within WSL, or can’t use docker desktop, follow the docker on WSL tutorial If you’re on MacOS and can’t use docker desktop, follow the MacOS colima tutorial Docker on WSL This install option is very useful, as it allows having a perfectly normal linux install of docker engine inside WSL, which can still be reached from windows.\nInstall WSL (If you had an old version of WSL, run wsl --upgrade) Get an operating system image from the microsoft store (for example, debian or ubuntu) Enable systemd support within the WSL VM Follow the regular linux install tutorial for docker If you have docker desktop installed, you can configure it to use WSL MacOS colima This procedure allows installing docker without relying on docker desktop. It uses colima for virtualizing linux.\nInstall homebrew brew install docker docker-compose colima Install the compose plugin: mkdir -p ~/.docker/cli-plugins \u0026\u0026 ln -sfn $(brew --prefix)/opt/docker-compose/bin/docker-compose ~/.docker/cli-plugins/docker-compose Configure colima: for apple silicon (M1/M2) macbooks: colima start --cpu 2 --memory 6 --arch aarch64 --vm-type=vz --vz-rosetta --mount-type=virtiofs for small infrastructures: colima start --cpu 2 --memory 4 for big infrastructures: colima start --cpu 2 --memory 6 brew services start colima to automatically start colima on startup Exit your terminal, open a new one You can now use docker CLI If you’re using rancher desktop, please either:\nuninstall the application select Manual in Preferences \u003e Application \u003e Environement If you get an error at rosetta startup, run colima delete and try again (the disk format is not compatible). Settings will be lost. If you get this error: error getting credentials - err: exec: \"docker-credential-osxkeychain\": executable file not found in $PATH\nOpen ~/.docker/config.json, and remove \"credsStore\": \"osxkeychain\"\n","categories":"","description":"","excerpt":"Regardless of your operating system, docker requires linux to operate. …","ref":"/en/docs/guides/contribute/install-docker/","tags":"","title":"Install docker"},{"body":"Peu importe votre système d’exploitation, docker requiert linux pour fonctionner. Lorsqu’utilisé sous un autre système d’exploitation, docker a besoin de machines virtuelles linux pour build et exécuter des images.\nIl y a deux types d’installation docker :\ndocker engine est l’application en ligne de commande docker desktop est une application graphique, qui gère aussi la virtualisation Voici nos suggestions :\nSi vous êtes sous linux, installez docker engine via votre gestionnaire de packet Si vous êtes sous MacOS / Windows, installez docker desktop si vous y êtes autorisés Si vous êtes sous windows, et voulez faire fonctionner docker sous WSL, ou ne pouvez pas utiliser docker desktop, suivez le guide docker sous WSL Si vous êtes sous MacOS, et vous ne pouvez pas utiliser docker desktop, suivez le guide colima pour MacOS Docker sous WSL Cette option d’installation est très utile, car elle permet de disposer d’une installation tout à fait normale de docker engine Linux à l’intérieur de WSL, qui reste accessible depuis Windows.\nInstallez WSL (Si vous avez une vieille version de WSL, lancez wsl --upgrade) Obtenez une image WSL depuis le store microsoft (par exemple, debian or ubuntu) Activez le support systemd depuis la VM WSL Suivez le tutoriel d’installation docker engine pour votre distribution WSL Si vous avez docker desktop installé, vous pouvez le configurer pour qu’il utilise WSL MacOS colima Cette procédure permet d’installer docker sans passer par docker desktop. Elle utilise colima comme solution de virtualisation.\nInstallez homebrew brew install docker docker-compose colima Installez le plugin compose : mkdir -p ~/.docker/cli-plugins \u0026\u0026 ln -sfn $(brew --prefix)/opt/docker-compose/bin/docker-compose ~/.docker/cli-plugins/docker-compose Configurez colima : pour des macbooks apple silicon (M1/M2) : colima start --cpu 2 --memory 6 --arch aarch64 --vm-type=vz --vz-rosetta --mount-type=virtiofs pour de petites infrastructures: colima start --cpu 2 --memory 4 pour de grosses infrastructures: colima start --cpu 2 --memory 6 brew services start colima pour lancer automatiquement colima au démarrage Quittez votre terminal, ouvrez-en un nouveau Vous pouvez maintenant utiliser docker CLI Si vous utiliser rancher desktop, veuillez soit:\ndéinstaller l’application sélectioner Manuel dans Préférences \u003e Application \u003e Environnement En cas d’erreur au démarrage avec Rosetta 2, lancez colima delete et réessayez (le format de disque n’est pas compatible). Les paramètres seront perdus. Si vous avez cette erreur: error getting credentials - err: exec: \"docker-credential-osxkeychain\": executable file not found in $PATH\nOuvrez ~/.docker/config.json, et enlevez \"credsStore\": \"osxkeychain\"\n","categories":"","description":"","excerpt":"Peu importe votre système d’exploitation, docker requiert linux pour …","ref":"/fr/docs/guides/contribute/install-docker/","tags":"","title":"Installer docker"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/blog/news/","tags":"","title":"News"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/blog/news/","tags":"","title":"News"},{"body":"Once we know what paths we can use, we need to know when they can actually be used.\nThe documentation of the conflict detection module explains how it’s done internally. Generally speaking, a train is in conflict when it has to slow down because of a signal. In our case, that means the solution would not be valid, we need to arrive later (or earlier) to see the signal when it’s not restrictive anymore.\nThe complex part is that we need to do the conflict detection incrementally Which means that:\nWhen running simulations up to t=x, we need to know all of the conflicts that happen before x, even if they’re indirectly caused by a signal seen at t \u003e x down the path. We need to know the conflicts and resource uses right as they start even if their end time can’t be defined yet. For that to be possible, we need to know where the train will go after the section that is being simulated (see infra exploration: we need some elements in the lookahead section).\nTo handle it, the conflict detection module returns an error when more lookahead is required. When it happens we extend it by cloning the infra explorer objets.\n","categories":"","description":"","excerpt":"Once we know what paths we can use, we need to know when they can …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/","tags":"","title":"Conflict detection"},{"body":"Maintenant qu’on sait quels chemins peuvent être utilisés, on doit déterminer à quel moment ces chemins sont libres.\nLa documentation (en anglais seulement) de la détection de conflits explique comment elle est réalisée en interne. Pour résumer, un train est en conflit avec un autre quand il observe un signal lui indiquant de ralentir. Dans notre cas, une solution où cette situation se produit est considérée comme invalide, le train doit arriver au signal donné plus tard (ou plus tôt) quand le signal n’est plus contraignant.\nCependant, la détection de conflit doit être réalisée de manière incrémentale, ce qui veut dire que :\nQuand une simulation est effectuée jusqu’à t=x, tous les conflits qui arrivent avant t=x doivent être connus, même s’ils sont indirectement provoqués par un signal vu à t \u003e x plus loin sur le chemin. Les conflits et utilisations de ressources doivent être identifiés dès qu’ils se produisent, même si le temps de fin d’utilisation n’est pas encore défini. Pour que ce soit possible, on doit être en mesure de savoir où le train ira après la section actuellement simulée (cf exploration de l’infrastructure )\nPour gérer ce cas, le module de détection de conflit peut renvoyer une erreur quand il est nécessaire d’avoir plus d’information sur la suite du chemin. Quand ce cas se produit, les objets InfraExplorer sont clonés pour étendre les chemins.\n","categories":"","description":"","excerpt":"Maintenant qu’on sait quels chemins peuvent être utilisés, on doit …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/","tags":"","title":"Détection de conflits"},{"body":"General principle The problem is still a pathfinding problem in a given graph. Once the problem is encoded as a graph search, it is possible to reuse our existing tools for this purpose.\nWe consider the product graph of position, time, and speed. This means that every graph element contains these 3 variables (among other things)\nEvery graph edge is computed using running-time calculation to get speed and positions as functions of time.\nGraphical representation Space is encoded with a graph that contains the physical infrastructure.\nIt is then “duplicated” at different times.\nThe nodes are then linked together in a way that reflects travel time.\nNotes The graph is constructed on the fly as it is explored. It is discretized in time, to evaluate which nodes have already been visited. We keep full accuracy of time values, but two nodes at the same place and close times are considered identical. Every edge is computed with a running time computation. Speed isn’t discretized or considered to check visited nodes, it’s only used to compute time. By default, the train always goes as fast as it can (while still following standard allowances). It only slows down when necessary. Example For example, with the following infrastructure, using the track graph: Exploring the solution graph can give the following result: ","categories":"","description":"","excerpt":"General principle The problem is still a pathfinding problem in a …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/","tags":"","title":"Encoding the solution space"},{"body":" Introduction La modélisation physique ayant montré que l’accélération du train était influencée par différents facteurs variant le long du trajet (pente, courbure, force de traction du moteur…), le calcul doit passer par une méthode d’intégration numérique. Le trajet est alors séparé en étapes suffisamment courtes pour considérer tous ces facteurs comme constants, ce qui permet cette fois ci d’utiliser l’équation du mouvement pour calculer le déplacement et la vitesse du train.\nLa méthode d’intégration numérique d’Euler est la plus simple pour effectuer ce genre de calcul, mais elle présente un certain nombre d’inconvénients. Cet article explique la méthode d’Euler, pourquoi elle ne convient pas aux besoins d’OSRD et quelle méthode d’intégration doit être utilisée à la place.\nLa méthode d’Euler La méthode d’Euler appliquée à l’intégration de l’équation du mouvement d’un train est :\n$$v(t+dt) = a(v(t), x(t))dt + v(t)$$\n$$x(t+dt) = \\frac{1}{2}a(v(t), x(t))dt^2 + v(t)dt + x(t)$$\n \nLes avantages de la méthode d’Euler La méthode d’Euler a pour avantages d’être très simple à implémenter et d’avoir un calcul plutôt rapide pour un pas de temps donné, en comparaison avec d’autres méthodes d’intégration numérique (voir annexe)\nLes inconvénients de la méthode d’Euler La méthode d’intégration d’Euler présente un certain nombre de problèmes pour OSRD :\nElle est relativement imprécise, et donc nécessite un faible pas de temps, ce qui génère beaucoup de données. En intégrant dans le temps, on ne connaît que les conditions du point de départ du pas d’intégration (pente, paramètres d’infrastructure, etc.) car on ne peut pas prédire précisément l’endroit où il se termine. On ne peut pas anticiper les futurs changements de directive : le train ne réagit qu’en comparant son état actuel à sa consigne au même instant. Pour illustrer c’est un peu comme si le conducteur était incapable de voir devant lui, alors que dans la réalité il anticipe en fonction des signaux, pentes, virages qu’il voit devant lui. La méthode Runge-Kutta 4 La méthode Runge-Kutta 4 appliquée à l’intégration de l’équation du mouvement d’un train est :\n$$v(t+dt) = v(t) + \\frac{1}{6}(k_1 + 2k_2 + 2k_3 + k_4)dt$$\nAvec :\n$$k_1 = a(v(t), x(t))$$\n$$k_2 = a\\Big(v(t+k_1\\frac{dt}{2}), x(t) + v(t)\\frac{dt}{2} + k_1\\frac{dt^2}{8}\\Big)$$\n$$k_3 = a\\Big(v(t+k_2\\frac{dt}{2}), x(t) + v(t)\\frac{dt}{2} + k_2\\frac{dt^2}{8}\\Big)$$\n$$k_4 = a\\Big(v(t+k_3dt), x(t) + v(t)dt + k_3\\frac{dt^2}{2}\\Big)$$\n \nLes avantages de la méthode de Runge Kutta 4 La méthode d’intégration de Runge Kutta 4 permet de répondre aux différents problèmes soulevés par celle d’Euler :\nElle permet d’anticiper les changements de directive au sein d’un pas de calcul, représentant ainsi davantage la réalité de conduite d’un train. Elle est plus précise pour le même temps de calcul (voir annexe), permettant des étapes d’intégration plus grandes, donc moins de points de données. Les inconvénients de la méthode de Runge Kutta 4 Le seul inconvénient notable de la méthode de Runge Kutta 4 rencontré pour l’instant est sa difficulté d’implémentation.\nLe choix de la méthode d’intégration pour OSRD Étude de la précision et de la vitesse de calcul Différentes méthodes d’intégration auraient pu remplacer l’intégration d’Euler de base dans l’algorithme d’OSRD. Afin de décider quelle méthode conviendrait le mieux, une étude sur la précision et la vitesse de calcul de différentes méthodes a été menée. Cette étude sert à comparé les méthodes suivantes :\nEuler Euler-Cauchy Runge-Kutta 4 Adams 2 Adams 3 Toutes les explications sur ces méthodes peuvent être trouvées dans ce document, et le code python utilisé pour la simulation est ici.\nLa simulation calcule la position et la vitesse d’un TGV accélérant sur une ligne droite plate.\nSimulations à pas de temps équivalent Une courbe de référence a été simulée en utilisant la méthode d’Euler avec un pas de temps de 0,1s, puis le même parcours a été simulé en utilisant les autres méthodes avec un pas de temps de 1s. Il est alors possible de comparer simplement chaque courbe à la courbe de référence, en calculant la valeur absolue de la différence à chaque point calculé. Voici l’erreur absolue résultante de la position du train sur sa distance parcourue :\nIl apparaît immédiatement que la méthode d’Euler est moins précise que les quatre autres d’environ un ordre de grandeur. Chaque courbe présente un pic où la précision est extrêmement élevée (erreur extrêmement faible), ce qui s’explique par le fait que toutes les courbes commencent légèrement au-dessus de la courbe de référence, la croisent en un point et finissent légèrement en dessous, ou vice versa.\nComme la précision n’est pas le seul indicateur important, le temps de calcul de chaque méthode a été mesuré. Voici ce que nous obtenons pour les mêmes paramètres d’entrée :\nMéthode d’intégration Temps de calcul (s) Euler 1.86 Euler-Cauchy 3.80 Runge-Kutta 4 7.01 Adams 2 3.43 Adams 3 5.27 Ainsi, Euler-Cauchy et Adams 2 sont environ deux fois plus lents que Euler, Adams 3 est environ trois fois plus lent, et RK4 est environ quatre fois plus lent. Ces résultats ont été vérifiés sur des simulations beaucoup plus longues, et les différents ratios sont maintenus.\nSimulation à temps de calcul équivalent Comme les temps de calcul de toutes les méthodes dépendent linéairement du pas de temps, il est relativement simple de comparer la précision pour un temps de calcul à peu près identique. En multipliant le pas de temps d’Euler-Cauchy et d’Adams 2 par 2, le pas de temps d’Adams 3 par 3, et le pas de temps de RK4 par 4, voici les courbes d’erreur absolue résultantes :\nEt voici les temps de calcul :\nMéthode d’intégration Temps de calcul (s) Euler 1.75 Euler-Cauchy 2.10 Runge-Kutta 4 1.95 Adams 2 1.91 Adams 3 1.99 Après un certain temps, RK4 tend à être la méthode la plus précise, légèrement plus précise que Euler-Cauchy, et toujours bien plus précise que la méthode d’Euler.\nConclusions de l’étude L’étude de la précision et de la vitesse de calcul présentée ci-dessus montre que RK4 et Euler-Cauchy seraient de bons candidats pour remplacer l’algorithme d’Euler dans OSRD : les deux sont rapides, précis, et pourraient remplacer la méthode d’Euler sans nécessiter de gros changements d’implémentation car ils ne font que des calculs au sein du pas de temps en cours de calcul. Il a été décidé qu’OSRD utiliserait la méthode Runge-Kutta 4 parce qu’elle est légèrement plus précise que Euler-Cauchy et que c’est une méthode bien connue pour ce type de calcul, donc très adaptée à un simulateur open-source.\n","categories":"","description":"","excerpt":" Introduction La modélisation physique ayant montré que l’accélération …","ref":"/fr/docs/explanation/running_time_calculation/numerical_integration/","tags":"","title":"Intégration numérique"},{"body":" Introduction Since physical modelling has shown that the acceleration of the train is influenced by various factors that vary along the route (gradient, curvature, engine traction force, etc.), the calculation must be carried out using a numerical integration method. The path is then separated into sufficiently short steps to consider all these factors as constant, which allows this time to use the equation of motion to calculate the displacement and speed of the train.\nEuler’s method of numerical integration is the simplest way of doing this, but it has a number of drawbacks. This article explains the Euler method, why it is not suitable for OSRD purposes and which integration method should be used instead.\nEuler’s method The Euler method applied to the integration of the equation of motion of a train is:\n$$v(t+dt) = a(v(t), x(t))dt + v(t)$$\n$$x(t+dt) = \\frac{1}{2}a(v(t), x(t))dt^2 + v(t)dt + x(t)$$\n \nAdvantages of Euler’s method The advantages of the Euler method are that it is very simple to implement and has a rather fast calculation for a given time step, compared to other numerical integration methods (see appendix)\nDisadvantages of the Euler’s method The Euler integration method presents a number of problems for OSRD:\nIt is relatively imprecise, and therefore requires a small time step, which generates a lot of data. With time integration, only the conditions at the starting point of the integration step (gradient, infrastructure parameters, etc.) are known, as one cannot predict precisely where it will end. We cannot anticipate future changes in the directive: the train only reacts by comparing its current state with its set point at the same time. To illustrate, it is as if the driver is unable to see ahead, whereas in reality he anticipates according to the signals, slopes and bends he sees ahead. Runge-Kutta’s 4 method The Runge-Kutta 4 method applied to the integration of the equation of motion of a train is:\n$$v(t+dt) = v(t) + \\frac{1}{6}(k_1 + 2k_2 + 2k_3 + k_4)dt$$\nWith:\n$$k_1 = a(v(t), x(t))$$\n$$k_2 = a\\Big(v(t+k_1\\frac{dt}{2}), x(t) + v(t)\\frac{dt}{2} + k_1\\frac{dt^2}{8}\\Big)$$\n$$k_3 = a\\Big(v(t+k_2\\frac{dt}{2}), x(t) + v(t)\\frac{dt}{2} + k_2\\frac{dt^2}{8}\\Big)$$\n$$k_4 = a\\Big(v(t+k_3dt), x(t) + v(t)dt + k_3\\frac{dt^2}{2}\\Big)$$\n \nAdvantages of Runge Kutta’s 4 method Runge Kutta’s method of integration 4 addresses the various problems raised by Euler’s method:\nIt allows the anticipation of directive changes within a calculation step, thus representing more accurately the reality of driving a train. It is more accurate for the same calculation time (see appendix), allowing for larger integration steps and therefore fewer data points. Disadvantages of Runge Kutta’s 4 method The only notable drawback of the Runge Kutta 4 method encountered so far is its difficulty of implementation.\nThe choice of integration method for OSRD Study of accuracy and speed of calculation Different integration methods could have replaced the basic Euler integration in the OSRD algorithm. In order to decide which method would be most suitable, a study of the accuracy and computational speed of different methods was carried out. This study compared the following methods:\nEuler Euler-Cauchy Runge-Kutta 4 Adams 2 Adams 3 All explanations of these methods can be found (in French) in this document, and the python code used for the simulation is here.\nThe simulation calculates the position and speed of a high-speed train accelerating on a flat straight line.\nEquivalent time step simulations A reference curve was simulated using the Euler method with a time step of 0.1s, then the same path was simulated using the other methods with a time step of 1s. It is then possible to simply compare each curve to the reference curve, by calculating the absolute value of the difference at each calculated point. The resulting absolute error of the train’s position over its distance travelled is as follows:\nIt is immediately apparent that the Euler method is less accurate than the other four by about an order of magnitude. Each curve has a peak where the accuracy is extremely high (extremely low error), which is explained by the fact that all curves start slightly above the reference curve, cross it at one point and end slightly below it, or vice versa.\nAs accuracy is not the only important indicator, the calculation time of each method was measured. This is what we get for the same input parameters:\nIntegration method Calculation time (s) Euler 1.86 Euler-Cauchy 3.80 Runge-Kutta 4 7.01 Adams 2 3.43 Adams 3 5.27 Thus, Euler-Cauchy and Adams 2 are about twice as slow as Euler, Adams 3 is about three times as slow, and RK4 is about four times as slow. These results have been verified on much longer simulations, and the different ratios are maintained.\nSimulation with equivalent calculation time As the computation times of all methods depend linearly on the time step, it is relatively simple to compare the accuracy for approximately the same computation time. Multiplying the time step of Euler-Cauchy and Adams 2 by 2, the time step of Adams 3 by 3, and the time step of RK4 by 4, here are the resulting absolute error curves:\nAnd here are the calculation times:\nIntegration method Calculation time (s) Euler 1.75 Euler-Cauchy 2.10 Runge-Kutta 4 1.95 Adams 2 1.91 Adams 3 1.99 After some time, RK4 tends to be the most accurate method, slightly more accurate than Euler-Cauchy, and still much more accurate than the Euler method.\nConclusions of the study The study of accuracy and computational speed presented above shows that RK4 and Euler-Cauchy would be good candidates to replace the Euler algorithm in OSRD: both are fast, accurate, and could replace the Euler method without requiring large implementation changes because they only compute within the current time step. It was decided that OSRD would use the Runge-Kutta 4 method because it is slightly more accurate than Euler-Cauchy and it is a well-known method for this type of calculation, so it is very suitable for an open-source simulator.\n","categories":"","description":"","excerpt":" Introduction Since physical modelling has shown that the acceleration …","ref":"/en/docs/explanation/running_time_calculation/numerical_integration/","tags":"","title":"Numerical integration"},{"body":"Principe général Le problème reste une recherche de graphe. En représentant l’espace de solution sous forme de graphe, il est possible de réutiliser nos outils déjà existants de recherche de chemin.\nLe graphe produit de la position, du temps, et de la vitesse est utilisé. Autrement dit, chaque élément du graphe contient (entre autres) ces 3 variables.\nChaque arête du graphe est calculée avec un calcul de marche pour connaître l’évolution de la vitesse et de la position dans le temps.\nReprésentation visuelle Le graphe de départ représente l’infrastructure physique\nIl est ensuite “dupliqué” à des temps différents\nPuis des nœuds sont reliés de manière à refléter le temps de parcours\nPrécisions Le graphe est construit au fil de l’exploration. Une discrétisation est faite au niveau du temps, uniquement pour évaluer ce qui a déjà été visité. Si le même emplacement est visité une seconde fois, il faut une certaine différence de temps pour estimer qu’il n’est pas déjà visité. Toutes les arêtes sont réalisées avec des calculs de marche La vitesse n’est pas discrétisée ni utilisée pour estimer quel emplacement est déjà visité, mais elle fait partie des calculs. Par défaut, tous les calculs sont faits en allant à la vitesse maximale. Les ralentissements sont ajoutés seulement quand ils sont nécessaires. Exemple Par exemple, avec l’infrastructure suivante en se basant sur le graphe des voies : Explorer le graphe des sillons possibles peut donner ce type de résultat : ","categories":"","description":"","excerpt":"Principe général Le problème reste une recherche de graphe. En …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/","tags":"","title":"Représentation de l'espace de solutions"},{"body":"Blocks The blocks have several attributes:\nA signaling system that corresponds to that displayed by its first signal. A path, which is a list of direction + detector pairs (just like route paths). An entry signal, (optional when the block starts from a buffer stop). Intermediate signals, if any (only used by systems with distant signals). An exit signal, (optional when the block ends at a buffer stop). The path is expressed from detector to detector so that it can be overlayed with the route graph.\nA few remarks:\nThere can be multiple blocks with the same path, as long as they have different signaling systems. Trains only use a block at a time, and ignore others. Blocks do not have a state: one can rely on the dynamic state of the zones that make it up. Blocks are used to figure out which signals protect which zones in a given context. Dependencies route graph. For each route: waypoints: List\u003cDiDetector\u003e signals: OrderedMap\u003cPosition, UnloadedSignal\u003e speed_limits: RangeMap\u003cPosition, SpeedLimit\u003e, including the logic for train category limits signaling systems drivers Signals Physical signal are made up of one or more logical signals, which are displayed as a single unit on the field. During simulation, logical signals are treated as separate signals.\nEach logical signal is associated with a signaling system, which defines if the signal transmits Movement Authority, speed limits, or both.\nLogical signals have one or more drivers. Signal drivers are responsible for computing signal state. Any given signal driver only works for a given pair of signaling systems, where the first one is displayed by the signal, and the second is the one displayed by the next signal.\nWhen a logical signal has an empty driver list, its content is deduced from neighboring signals.\nFor example, a BAL signal that is both a departure of the TVM block and a departure of the BAL block, it will have two drivers: BAL-BAL and BAL-TVM.\nAnnouncing speed limits When a signal announces a speed limit, it needs to be linked with a speed section object. This is meant to enable smooth transitions between the reaction to the announce signal, and the limit itself.\nIf multiple signals are involved in the announce process, only the one closest to the speed limit has to have this attribute set.\n{ # ... \"announce_speed_section\": \"${SPEED_SECTION_ID}\" # ... } Conditional parameters Some signal parameters vary depending on which route is set. On each signal, an arbitrary number of rules can be added. If the signal is last to announce a speed limit, it must be explicitly mentionned in the rule.\n{ # ... \"announce_speed_section\": \"${SPEED_SECTION_ID}\", \"default_parameters\": {\"short_block\": \"false\"}, \"conditional_parameters\": [ { \"on_route\": \"${ROUTE_ID}\", \"announce_speed_section\": \"${SPEED_SECTION_ID}\", \"parameters\": {\"rappel30\": \"true\", \"short_block\": \"true\"} } ] # ... } Signal parameter values are looked up in the following order:\nper route conditional parameters per signal default parameters (default_parameters) parameter default value, from the signaling system’s .signal_parameters[].default Serialized format The serialized / raw format is the user-editable description of a physical signal.\nRaw signals have a list of logical signals, which are independently simulated units sharing a common physical display. Each logical signal has:\na signaling system user-editable properties, as specified in the signaling system description a list of default parameters, which can get overriden per-route an optional announced speed section, which can get overriden per-route a list of allowed next signaling systems, which are used to load drivers For example, this signal encodes a BAL signal which:\nstarts both a BAL and a TVM block announces speed limit B on all routes except route A, where speed limit C is announced on route A, the block is shorter than usual { # signals must have location data. # this data is omitted as its format is irrelevant to how signals behave \"logical_signals\": [ { # the signaling system shown by the signal \"signaling_system\": \"BAL\", # the settings for this signal, as defined in the signaling system manifest \"properties\": {\"has_ralen30\": \"true\", \"Nf\": \"true\"}, # this signal can react to BAL or TVM signals # if the list is empty, the signal is assumed to be compatible with all following signaling systems \"next_signaling_systems\": [\"BAL\", \"TVM\"] \"announce_speed_section\": \"${SPEED_SECTION_B}\", \"default_parameters\": {\"rappel30\": \"true\", \"short_block\": \"false\"}, \"conditional_parameters\": [ { \"on_route\": \"${ROUTE_A}\", \"announce_speed_section\": \"${SPEED_SECTION_C}\", \"parameters\": {\"short_block\": \"true\"} } ] } ] } For example, this signal encodes a BAL signal which starts a BAL block, and shares its physical display / support with a BAPR signal starting a BAPR block:\n{ # signals must have location data. # this data is omitted as its format is irrelevant to how signals behave \"logical_signals\": [ { \"signaling_system\": \"BAL\", \"properties\": {\"has_ralen30\": \"true\", \"Nf\": \"true\"}, \"next_signaling_systems\": [\"BAL\"] }, { \"signaling_system\": \"BAPR\", \"properties\": {\"Nf\": \"true\", \"distant\": \"false\"}, \"next_signaling_systems\": [\"BAPR\"] } ] } Signal description strings Signal definitions need to be condensed into a shorter form, just to look up signal icons. In order to store this into MVT map tiles hassle free, it’s condensed down into a single string.\nIt looks something like that: BAL[Nf=true,ralen30=true]+BAPR[Nf=true,distant=false] It’s built as follows:\na list of logical signals, sorted by signaling system name, separated by + inside each logical signal, signal properties are sorted by name, enclosed in square brackets and separated by , Dependencies For signal state evaluation:\ntrain path in blocks portion of the path to evaluate drivers state of the zones in the section to evaluate ","categories":"","description":"","excerpt":"Blocks The blocks have several attributes:\nA signaling system that …","ref":"/en/docs/reference/design-docs/signaling/blocks-and-signals/","tags":"","title":"Blocks and signals"},{"body":" Introduction Cette page donne un exemple de la manière dont les formats de données sont utilisés pour décrire une infrastructure dans OSRD.\nÀ cette fin, prenons comme exemple l’infrastructure-jouet suivante :\nConseil Pour zoomer sur un diagramme, cliquez sur le bouton d’édition qui apparaît au survol de celui-ci. Ce diagramme est un aperçu de l’infrastructure avec les lignes et les stations uniquement.\nCette infrastructure ne se veut pas réaliste, mais plutôt destinée à illustrer le modèle de données d’OSRD. Cet exemple sera créé étape par étape et expliqué en cours de route.\nLe générateur d’infrastructures Dans le dépôt OSRD se trouve une bibliothèque python conçue pour aider à générer des infrastructures dans un format compris par OSRD.\nL’infrastructure discutée dans cette section peut être générée grâce au fichier small_infra.py. Pour en savoir plus sur les scripts de génération, vous pouvez consulter le README correspondant.\nVoies Sections de voie (Track Sections) Les premiers objets que nous devons définir sont les TrackSections. La plupart des autres objets sont positionnés par rapport à celles-ci.\nUne section de voie est une section de rail (sans aiguillages). On peut choisir de diviser les voies de son infrastructure en autant de sections qu’on le souhaite. Ici, nous avons choisi d’utiliser les sections de voie les plus longues possibles, ce qui signifie qu’entre deux aiguillages, il y a toujours une seule section de voie.\nLes sections de voie sont ce sur quoi les trains simulés roulent. Ils sont l’équivalent abstrait des sections de rails physiques. Les sections de voie sont bidirectionnelles.\nDans cet exemple, nous définissons deux voies pour la ligne entre les stations Ouest et Nord-Est. Nous avons également des voies de contournement aux stations Nord et Centre-Ouest pour plus de réalisme. Enfin, nous avons trois voies distinctes dans la station Ouest, puisqu’il s’agit d’une plaque tournante majeure dans notre infrastructure imaginaire.\nImportant Les TrackSections sont représentées par des flèches dans ce diagramme pour souligner le fait qu’elles ont un début et une fin. C’est important car les objets positionnés sur les sections de voie sont localisés en fonction de leur distance par rapport au début de leur section de voie.\nPar conséquent, pour placer un objet au début de sa section de voie, définissez sa position à 0. Pour le déplacer à la fin de sa section de voie, définissez sa position à la length de la section de voie.\nCes attributs sont nécessaires pour que la section de voie soit complète :\nlength : la longueur de la section de voie en mètres. geo : les coordonnées dans la réalité (geo pour géographique), au format GeoJSON. attributs cosmétiques : line_name, track_name, track_number qui sont utilisés pour indiquer le nom et les étiquettes qui ont été donnés aux voies / lignes dans la réalité. Pour toutes les sections de voies de notre infrastructure, les attributs geo se rapprochent beaucoup au schéma donné.\nPour la plupart des sections de voies, leur length est proportionnelle à ce que l’on peut voir sur le diagramme. Pour préserver la lisibilité, des exceptions ont été faites pour TA6, TA7, TD0 et TD1 (qui font 10km et 25km).\nNoeud Un Node représente un noeud dans l’infrastructure. Dans une simulation OSRD, un train ne peut passer d’une section de voie à une autre que si elles sont reliées par un noeud. Un noeud peut se présenter de deux manières différentes :\n1) Aiguillages\nLes aiguillages peuvent être vus comme une collection de liens de sections de voies, partitionnés en groupes. Chaque groupe représente un état de l’aiguillage. Passer d’un groupe à un autre peut prendre du temps, et au maximum un lien peut être prêt à être utilisé à la fois.\nDans le monde réel, les aiguillages ne sont pas uniques, mais plutôt des instances de modèles existants.\n2) Liens de sections de voies\nPour le moment, nous n’avons créé que des sections de voies, qui ne sont pas interconnectées (les données géospatiales ne sont pas utilisées pour déduire quelles voies sont connectées).\nLes link sont utilisés pour connecter deux sections de voie ensemble, tout comme un joint de soudure le ferait dans la vie réelle. Dans une simulation OSRD, un train ne peut passer d’une section de voie à une autre que si elles sont reliées par ce type de noeud, le link (ou par un autre NodeType).\nQue ce soit pour les aiguillages ou les liens de sections de voies, les liens et les groupes ne font pas partie du switch lui-même, mais d’un objet NodeType, qui est partagé par les aiguillages du même modèle.\nTypes de Noeud Les NodeTypes ont deux attributs obligatoires :\nports : Une liste de noms de ports. Un port est une extrémité du noeud qui peut être connecté à une section de voie. groups : Un table de correspondance entre le nom des groupes et les listes de branches (connexion entre 2 ports) qui caractérisent les différentes positions possibles du type de Noeud À tout moment, tous les noeuds ont un groupe actif, et peuvent avoir une branche active, qui appartient toujours au groupe actif. Pendant une simulation, le changement de branche active à l’intérieur d’un groupe est instantané, mais le changement de branche active entre les groupes prend un temps configurable. Ceci est dû au fait qu’un Noeud peut-être un objet physique (dans le cas des aiguillages), et que le changement de branche active peut impliquer le déplacement de certaines de ses parties. Les groups sont conçus pour représenter les différentes positions qu’un Noeud peut avoir. Chaque groupe contient les liens qui peuvent être utilisés dans la position du Noeud associé.\nDans le cas des aiguilles, la durée nécessaire pour changer de groupe est stockée à l’intérieur du Noeud, car elle peut varier en fonction de l’implémentation physique du modèle d’aiguillage.\nNos exemples utilisent actuellement cinq NodeTypes. Il est possible d’ajouter un type de noeud si nécessaire via le champ extended_node_type.\n1) Le lien entre deux sectionx de voies\nCelui-ci représente le lien entre deux sections de voies. Il possède deux ports : A et B.\nIl permet de créer un lien entre deux sections de voies tel que définis dans OSRD. Ce n’est pas un objet physique.\n2) L’aiguille\nL’omniprésent aiguillage en Y, qui peut être considéré comme la fusion de deux voies ou la séparation d’une voie.\nCe type d’aiguillage possède trois ports : A, B1 et B2.\nIl y a deux groupes, chacun avec une connexion dans leur liste : A_B1, qui connecte A à B1, et A_B2 qui connecte A à B2.\nAinsi, à tout moment (sauf lorsque l’aiguille bouge pour changer de groupe), un train peut aller de A à B1 ou de A à B2 mais jamais aux deux en même temps. Un train ne peut pas aller de B1 à B2.\nUne aiguille n’a que deux positions :\nA vers B1 A vers B2 3) L’aiguillage de croisement\nIl s’agit simplement de deux voies qui se croisent.\nCe type a quatre ports : A1, B1, A2 et B2.\nIl ne comporte qu’un seul groupe contenant deux connexions : A1 vers B1 et A2 vers B2. En effet, ce type d’aiguillage est passif : il n’a pas de pièces mobiles. Bien qu’il n’ait qu’un seul groupe, il est tout de même utilisé par la simulation pour faire respecter les réservations de route.\nVoici les deux connexions différentes que ce type d’aiguillage possède :\nA1 vers B1 A2 vers B2 4) L’aiguillage de croisement double\nCelui-ci ressemble plus à deux aiguilles dos à dos. Il possède quatre ports : A1, A2, B1 et B2.\nCependant, il comporte quatre groupes, chacun avec une connexion. Les quatre connexions possibles sont les suivantes :\nA1 vers B1 A1 vers B2 A2 vers B1 A2 vers B2 5) L’aiguillage de croisement simple\nCelui-ci ressemble plus à un mélange entre une aiguille simple et un croisement. Il possède quatre ports : A1, A2, B1 et B2.\nVoici les trois connexions que peut réaliser cet aiguillage :\nA1 vers B1 A1 vers B2 A2 vers B2 Retour aux noeuds Un Node possède trois attributs :\nnode_type : l’identifiant NodeType de ce noeud. ports : une correspondance entre les noms de port et les extrémités des sections de voie. group_change_delay : le temps qu’il faut pour changer le groupe de l’aiguillage qui est actif. Les noms des ports doivent correspondre aux ports du type du noeud choisi. Les extrémités de la section de voie peuvent être début ou fin, faites attention à choisir les bonnes.\nLa plupart des noeuds de notre exemple sont des noeuds habituels. Le chemin de la gare du Nord à la gare du Sud a deux aiguillages de croisement. Enfin, il y a un aiguillage de croisement double juste avant que la ligne principale ne se divise en lignes Nord-Est et Sud-Est.\nIl est important de noter que ces noeuds sont présents par défaut dans le code du projet. Seuls les extended_switch_type ajoutés par l’utilisateur apparaîtront dans le railjson.\nCourbes et pentes Les Courbes et les Pentes sont essentielles pour des simulations réalistes. Ces objets sont définis comme une plage entre une position de début (begin) et de fin (end) sur une section de voie. Si une courbe / pente s’étend sur plus d’une section de voie, elle doit être ajoutée à toutes les sections.\nLes valeurs des courbes / pentes sont constantes sur toute leur étendue. Pour des courbes / pentes variables, il faut créer plusieurs objets.\nLes valeurs de pente sont mesurées en mètres par kilomètres, et les valeurs de courbe sont mesurées en mètres (le rayon de la courbe).\nN’oubliez pas que la valeur begin doit toujours être inférieure à la valeur end. C’est pourquoi les valeurs de courbe/pente peuvent être négatives : une pente ascendante de 1 allant du décalage 10 à 0 est identique à une pente descendante de -1 allant des décalages 0 à 10. Dans le fichier small_infra.py, nous avons des pentes sur les sections de voie TA6, TA7, TD0 et TD1.\nIl y a également des courbes sur les sections de voie TE0, TE1, TE3 et TF1.\nEnclenchement Jusqu’à présent, tous les objets ont contribué à la topologie (forme) des voies. La topologie serait suffisante pour que les trains puissent naviguer sur le réseau, mais pas assez pour le faire en toute sécurité. pour assurer la sécurité, deux systèmes collaborent :\nL’enclenchement garantit que les trains sont autorisés à avancer La signalisation est le moyen par lequel l’enclenchement communique avec le train Détecteurs Ces objets sont utilisés pour créer des sections TVD (Track Vacancy Detection) : la zone de la voie située entre deux détecteurs est une section TVD. Lorsqu’un train rencontre un détecteur, la section dans laquelle il entre est occupée. La seule fonction des sections TVD est de localiser les trains.\nDans la réalité, les détecteurs peuvent être des compteurs d’essieux ou des circuits de voie par exemple.\nPour que cette méthode de localisation soit efficace, les détecteurs doivent être placés régulièrement le long de vos voies, pas trop nombreux pour des raisons de coût, mais pas trop peu, car les sections TVD seraient alors très grandes et les trains devraient être très éloignés les uns des autres pour être distingués, ce qui réduirait la capacité.\nIl y a souvent des détecteurs à proximité de tous les extrémités des aiguillages. De cette façon, l’enclenchement est averti presque immédiatement lorsqu’un aiguillage est libéré, qui est alors libre d’être utilisé à nouveau.\nPrenons l’exemple d’un aiguillage de croisement : si le train A le franchit du nord au sud et que le train B arrive pour le franchir de l’ouest à l’est, dès que le dernier wagon du train A a franchi l’aiguillage, B devrait pouvoir partir, puisque A se trouve maintenant sur une section de voie complètement indépendante. Dans OSRD, les détecteurs sont des objets ponctuels. Les attributs dont ils ont besoin sont leur id et leur localisation sur la voie (track et offset).\nLes carrés agglutinés représentent plusieurs détecteurs à la fois. En effet, certains tronçons de voie n’étant pas représentés sur toute leur longueur, nous n’avons pas pu représenter tous les détecteurs du tronçon de voie correspondant. Quelques notes :\nEntre certains points, nous n’avons ajouté qu’un seul détecteur (et non pas deux), car ils étaient très proches les uns des autres, et cela n’aurait eu aucun sens de créer une minuscule section TVD entre eux. Cette situation s’est produite sur des sections de voies (TA3, TA4, TA5, TF0 et TG3). Dans notre infrastructure, il y a relativement peu de sections de voie qui sont assez longues pour nécessiter plus de détecteurs que ceux liés aux aiguillages. Ce sont, TA6, TA7, TDO, TD1, TF1, TG1 et TH1. Par exemple, TD0, qui mesure 25 km, compte en fait 17 détecteurs au total. Butoirs (BufferStops) Les BufferStops sont des obstacles destinés à empêcher les trains de dérailler en bout des voies.\nDans notre infrastructure, il y a un butoir sur chaque section de voie qui est un cul-de-sac. Il y a donc 8 butoirs au total.\nAvec les détecteurs, ils définissent les limites des sections TVD (voir Détecteurs).\nItinéraires (Routes) Une Route est un itinéraire dans l’infrastructure. Un sillon est une séquence de routes. Les itinéraires sont utilisés pour réserver des sections de sillon avec l’enclenchement. Voir la documentation dédiée.\nIl est représenté avec les attributs suivants :\nentry_point et exit_point : Références de détecteurs ou de butées qui marquent le début et la fin de l’itinéraire. entry_point_direction : Direction à prendre sur la section de voie depuis entry_point pour commencer l’itinéraire. switches_direction : Un ensemble de directions à suivre lorsqu’on rencontre un aiguillage sur notre itinéraire, de manière à reconstituer cet itinéraire de entry_point jusqu’à exit_point. release_detectors : Lorsqu’un train franchit un détecteur de libération, les ressources réservées depuis le début de la route jusqu’à ce détecteur sont libérées. Signalisation Grâce à l’enclenchement, les trains sont localisés et autorisés à se déplacer. C’est un bon début, mais c’est inutile tant que les trains n’en sont pas informés. C’est là que les “signaux” entrent en jeu : les signaux réagissent aux enclenchements et peuvent être vus par les trains.\nLa façon dont les trains réagissent aux signaux dépend de l’aspect, du type de signal et du système de signalisation.\nVoici les attributs les plus importants des signaux :\nlinked_detector : Le détecteur lié. type_code : Le type de signal. direction : La direction qu’il protège, qui peut être simplement interprétée comme la façon dont il peut être vu par un train entrant (puisqu’il n’y a des feux que d’un côté…). La direction est relative à l’orientation de la section de voie. Des attributs cosmétiques comme angle_geo and side qui contrôlent la manière dont les signaux sont affichés dans le front-end. Voici une visualisation de comment on peut représenter un signal, et quelle direction il protège.\nLa manière dont les signaux sont disposés dépend fortement du système de signalisation et du gestionnaire de l’infrastructure.\nVoici les règles de base utilisées pour cet exemple d’infrastructure :\nNous ajoutons deux signaux d’espacement (un par direction) pour chaque détecteur qui découpe une longue section de TVD en plus petites sections. Les entrées d’aiguillage où un train pourrait devoir s’arrêter sont protégées par un signal (qui est situé à l’extérieur de la section TVD de l’aiguillage). Il doit être visible depuis la direction utilisée pour approcher l’aiguillage. Lorsqu’il y a plusieurs aiguillages dans une rangée, seul le premier a généralement besoin d’être protégé, car l’enclenchement est généralement conçu pour ne pas encourager les trains à s’arrêter au milieu des intersections. Notez que les détecteurs liés à au moins un signal ne sont pas représentés, car il n’y a pas de signaux sans détecteurs associés dans cet exemple.\nPour obtenir le id d’un détecteur lié à un signal, prenez le id du signal et remplacez S par D (par exemple SA0 -\u003e DA0).\nSur TA6, TA7, TD0 et TD1 nous n’avons pas pu représenter tous les signaux car ces sections de voie sont très longues et comportent de nombreux détecteurs, donc de nombreux signaux. Électrification Pour permettre à des trains électriques de circuler sur notre infrastructure, nous devons spécifier les parties de celle-ci qui sont électrifiées.\nCaténaires (Catenaries) Les Catenaries représentent les câbles d’alimentation qui alimentent les trains électriques. Ils sont représentés avec les attributs suivants :\nvoltage : Une chaîne de caractères représentant le type d’alimentation électrique utilisée pour l’électrification. track_ranges : Une liste de portions de sections de voie (TrackRanges) couvertes par cette caténaire. Une TrackRange est composée d’un identifiant de section de voie, d’une position begin et d’une position end. Dans notre exemple, nous avons deux Catenaries:\nUne avec voltage défini sur \"1500\", qui couvre uniquement TA0. Une avec voltage défini sur \"25000\", qui couvre tous les autres sauf TD1. Cela signifie que seuls les trains thermiques peuvent traverser la section de voie TD1.\nNotre exemple montre également que, contrairement à son homologue réel, une seule Catenary peut couvrir toute l’infrastructure.\nSections Neutres (NeutralSections) Dans certaines parties d’une infrastructure, les conducteurs de train sont sommés - principalement pour des raisons de sécurité - de couper l’alimentation électrique du train.\nPour représenter de telles parties, nous utilisons des NeutralSections. Elles sont représentées avec principalement les attributs suivants :\ntrack_ranges : Une liste de DirectedTrackRanges (portions de sections de voie associées à une direction) couvertes par cette section neutre. lower_pantograph : Un booléen indiquant si le pantographe du train doit être abaissé pendant la traversée de cette section. Dans notre exemple, nous avons trois NeutralSections : une à la jonction des caténaires \"1500\" et \"25000\", une sur TA6 et une sur TG1 et TG4.\nPour plus de détails sur le modèle, voir la page dédiée.\nDivers Points opérationnels (OperationalPoints) Le point operationnel est aussi connu sous le nom de Point Remarquable (PR). Un OperationalPoint est une collection de points (OperationalPointParts) d’intérêt.\nPar exemple, il peut être pratique (repère de conduite) de stocker l’emplacement des plateformes en tant que parties et de les regrouper par station dans des points opérationnels. De la même manière, un pont au-dessus des voies sera un OperationalPoint, mais il comportera plusieurs OperationPointParts, une à l’intersection de chaque voie.\nDans l’exemple de l’infrastructure, nous n’avons utilisé que des points opérationnels pour représenter les stations. Les parties de points opérationnels sont représentées par des diamants violets. Gardez à l’esprit qu’un seul point opérationnel peut contenir plusieurs parties.\nLimites de gabarit (Loading Gauge Limits) Cet objet s’apparente aux Pentes et aux Courbes : il couvre une plage de section de voie, avec une position de début (begin) et de fin (end). Il représente une restriction sur les trains qui peuvent circuler sur la plage donnée, par poids ou par type de train (fret ou passagers).\nNous n’en avons pas mis dans nos exemples.\nSections de vitesse (SpeedSections) Les SpeedSections représentent les limites de vitesse (en mètres par seconde) qui sont appliquées sur certaines parties des voies. Une SpeedSection peut s’étendre sur plusieurs sections de voie, et ne couvre pas nécessairement la totalité des sections de voie. Les sections de vitesse peuvent se chevaucher.\nDans notre exemple d’infrastructure, nous avons une section de vitesse couvrant l’ensemble de l’infrastructure, limitant la vitesse à 300 km/h. Sur une plus petite partie de l’infrastructure, nous avons appliqué des sections de vitesse plus restrictives.\n","categories":"","description":"Explique par l'exemple comment les données d'infrastructure sont structurées","excerpt":"Explique par l'exemple comment les données d'infrastructure sont …","ref":"/fr/docs/explanation/models/data-models-full-example/","tags":"","title":"Exemple d'infrastructure"},{"body":"Explanations discuss key topics and concepts at a fairly high level and provide useful background information and explanation.\n","categories":"","description":"Learn more about key concepts","excerpt":"Learn more about key concepts","ref":"/en/docs/explanation/","tags":"","title":"Explanations"},{"body":"Les explications abordent des thèmes et concepts clés d’un point de vue général et fournissent des informations et explications détaillées sur les éléments fondamentaux.\n","categories":"","description":"Comprendre les concepts clés","excerpt":"Comprendre les concepts clés","ref":"/fr/docs/explanation/","tags":"","title":"Explications"},{"body":" Introduction This page gives an example of how the data formats are used to describe an infrastructure in OSRD.\nFor this purpose, let’s take as an example the following toy infrastructure:\nTip To zoom in on diagrams, click on the edit button that appears when hovering over it. This diagram is an overview of the infrastructure with lines and stations only.\nThis infrastructure is not meant to be realistic, but rather meant to help illustrate OSRD’s data model. This example will be created step by step and explained along the way.\nThe infrastructure generator In the OSRD repository is a python library designed to help generate infrastructures in a format understood by OSRD.\nThe infrastructure discussed in this section can be generated thanks to small_infra.py file. To learn more about the generation scripts, you can check out the related README.\nTracks Track sections The first objects we need to define are TrackSections. Most other objects are positioned relative to track sections.\nA track section is a section of rail (switches not included). One can chose to divide the tracks of their infrastructure in as many track sections as they like. Here we chose to use the longest track sections possible, which means that between two switches there is always a single track section.\nTrack sections is what simulated trains roll onto. They are the abstract equivalent to physical rail sections. Track sections are bidirectional.\nIn this example, we define two tracks for the line between the West and North-East stations. We also have overpassing tracks at the North and Mid-West stations for added realism. Finally, we have three separate tracks in the West station, since it’s a major hub in our imaginary infrastructure.\nImportant TrackSections are represented as arrows in this diagram to stress the fact that they have a start and an end. It matters as objects positioned on track sections are located using their distance from the start of their track section.\nTherefore, to locate an object at the beginning of its track section, set its offset to 0. To move it to the end of its track section, set its offset to the length of the track section.\nThese attributes are required for the track section to be complete:\nlength: the length of the track section in meters. geo: the coordinates in real life (geo is for geographic), in the GeoJSON format. cosmetic attributes: line_name, track_name, track_number which are used to indicate the name and labels that were given to the tracks / lines in real life. For all track sections in our infrastructure, the geo attributes very much resemble the given diagram.\nFor most track sections, their length is proportional to what can be seen in the diagram. To preserve readability, exceptions were made for TA6, TA7, TD0 and TD1 (which are 10km and 25km).\nNode A Node represents a node in the infrastructure. In an OSRD simulation, a train can only move from one section of track to another if they are linked by a node.\nNode Types NodeTypes have two mandatory attributes:\nports: A list of port names. A port is an endpoint connected to a track section. groups: A mapping between group names and lists of branch (connection between 2 ports) that characterises the different possible positions of the node type At any time, all nodes have an active group, and may have an active branch, which always belongs to the active group. During a simulation, changing the active branch inside a group is instantaneous, but changing the active branch across groups (changing the active group) takes configurable time. This is because a node is a physical object, and changing active branch can involve moving parts of it. Groups are designed to represent the different positions that a node can have. Each group contains the branches that can be used in the associated node position.\nThe duration needed to change group is stored inside the Node, since it can vary depending on the physical implementation of the node.\nOur examples currently use five node types. Node types are just like other objects, and can easily be added as needed using extended_switch_type.\n1) Link\nThis one represents the link between two sections of track. It has two ports: A and B.\nIt is used in the OSRD model to create a link between two track sections. This is not a physical object.\n2) The Point Switch\nThe ubiquitous Y switch, which can be thought of as either two tracks merging, or one track splitting.\nThis node type has three ports: A, B1 and B2.\nThere are two groups, each with one connection in their list: A_B1, which connects A to B1, and A_B2 which connects A to B2.\nThus, at any given moment (except when the switch moves from one group to another), a train can go from A to B1 or from A to B2 but never to both at the same time. A train cannot go from B1 to B2.\nA Point Switch only has two positions:\nA to B1 A to B2 3) The Crossing\nThis is simply two tracks crossing each other.\nThis type has four ports: A1, B1, A2 et B2.\nIt has only one group containing two connections: A1 to B1 and A2 to B2. Indeed this kind of switch is passive: it has no moving parts. Despite having a single group, it is still used by the simulation to enforce route reservations.\nHere are the two different connections this switch type has:\nA1 to B1 A2 to B2 4) The Double slip switch\nThis one is more like two point switches back to back. It has four ports: A1, A2, B1 and B2.\nHowever, it has four groups, each with one connection. The four groups are represented in the following diagram:\nA1 to B1 A1 to B2 A2 to B1 A2 to B2 5) The Single slip switch\nThis one looks more like a cross between a single needle and a crossover. It has four ports: A1, A2, B1 and B2.\nHere are the three connections that can be made by this switch:\nA1 to B1 A1 to B2 A2 to B2 Back to nodes A Node has three attributes:\nnode_type: the identifier of the NodeType of this node. ports: a mapping from port names to track sections extremities. group_change_delay: the time it takes to change which group of the node is activated. The port names must match the ports of the node type chosen. The track section endpoints can be start or end, be careful to chose the appropriate ones.\nMost of our example’s nodes are regular point switches. The path from North station to South station has two cross switches. Finally, there is a double cross switch right before the main line splits into the North-East and South-East lines.\nIt is important to note that these node types are hard-coded into the project code. Only the extended_node_type added by the user will appear in the railjson.\nCurves and slopes Curves and Slopes are instrumental to realistic simulations. These objects are defined as a range between a begin and end offsets of one track section. If a curve / slope spans more than one track section, it has to be added to all of them.\nThe slope / curve values are constant on their entire range. For varying curves / slopes, one needs to create several objects.\nSlope values are measured in meters per kilometers, and the curve values are measured in meters (the radius of the curve).\nMind that the begin value should always be smaller than the end value. That is why the curve / slope values can be negative: an uphill slope of 1 going from offset 10 to 0 is the same as a downhill slope of -1 going from offsets 0 to 10. In the small_infra.py file, we have slopes on the track sections TA6, TA7, TD0 and TD1.\nThere are curves as well, on the track sections TE0, TE1, TE3 and TF1.\nInterlocking All objects so far contributed to track topology (shape). Topology would be enough for trains to navigate the network, but not enough to do so safely. to ensure safety, two systems collaborate:\nInterlocking ensures trains are allowed to move forward Signaling is the mean by which interlocking communicates with the train Detectors These objects are used to create TVD sections (Track Vacancy Detection section): the track area in between detectors is a TVD section. When a train runs into a detector, the section it is entering becomes occupied. The only function of TVD sections is to locate trains.\nIn real life, detectors can be axle counters or track circuits for example.\nFor this mean of location to be efficient, detectors need to be placed regularly along your tracks, not too many because of cost, but not too few, because then TVD sections would be very large and trains would need to be very far apart to be told apart, which reduces capacity.\nThere often are detectors close to all sides of switches. This way, interlocking is made aware pretty much immediately when a switch is cleared, which is then free to be used again.\nLet’s take a cross switch as an example: if train A is crossing it north to south and train B is coming to cross west to east, then as soon as train A’s last car has passed the crossing, B should be able to go, since A is now on a completely unrelated track section. In OSRD, detectors are point objects, so all the attributes it needs are its id, and track location (track and offset).\nThe clumped up squares represent many detectors at once. Indeed, because some track sections are not represented with their full length, we could not represent all the detectors on the corresponding track section. Some notes:\nBetween some points, we added only one detector (and not two), because they were really close together, and it would have made no sense to create a tiny TVDS between the two. This situation happened on track sections (TA3, TA4, TA5, TF0 and TG3). In our infrastructure, there is relatively few track sections which are long enough to require more detectors than just those related to switches. Namely, TA6, TA7, TDO, TD1, TF1, TG1 and TH1. For example TD0, which measures 25km, has in fact 17 detectors in total. Buffer stops BufferStops are obstacles designed to prevent trains from sliding off dead ends.\nIn our infrastructure, there is a buffer stop on each track section which has a loose end. There are therefore 8 buffer stops in total.\nTogether with detectors, they set the boundaries of TVD sections (see Detectors)\nRoutes A Route is an itinerary in the infrastructure. A train path is a sequence of routes. Routes are used to reserve section of path with the interlocking. See the dedicated documentation.\nIt is represented with the following attributes:\nentry_point and exit_point: references detectors or buffer stops which mark the beginning and the end of the Route. entry_point_direction : Direction on a track section to start the route from the entry_point. switches_direction : A set of directions to follow when we encounter a switch on our Route, to build this Route from entry_point to exit_point. release_detectors: When a train clears a release detector, resources reserved from the beginning of the route until this detector are released. Signaling Thanks to interlocking, trains are located and allowed to move. It’s a good start, but meaningless until trains are made aware of it. This is where Signals come into play: signals react to interlocking, and can be seen by trains.\nHow trains react to signals depends on the aspect, kind of signal, and signaling system.\nHere are the most important attributes for signals:\nlinked_detector: The linked detector. type_code: The type of signal. direction: The direction it protects, which can simply be interpreted as the way in which it can be seen by an incoming train (since there are lights only on one side…). Direction is relative to track section orientation. Cosmetic attributes like angle_geo or side which control the way in which the signals are displayed in the front-end. Here is a visualization of how one can represent a signal, and which direction it protects.\nThe way the signals are arranged is highly dependent on both signaling system and infrastructure manager.\nHere are the basic rules used for this example infrastructure:\nWe add two spacing signals (one per direction) for each detector that is cutting a long TVD section into smaller ones. Switch entries where a train might have to stop are protected by a signal (which is located outside of the switch TVD section). It must be visible from the direction used to approach the switch. When there are multiple switches in a row, only the first one usually needs protection, as interlocking is usually designed as not to encourage trains stopping in the middle of intersections. Note that detectors linked to at least one signal are not represented, as there are not signals without associated detectors in this example.\nTo get the id of a detector linked to a signal, take the signal’s id and replace S by D (e.g. SA0 -\u003e DA0).\nOn TA6, TA7, TD0 and TD1 we could not represent all signals because these track sections are very long and have many detectors, hence many signals. Electrification To allow electric trains to run on our infrastructure, we need to specify which parts of the infrastructure is electrified.\nCatenaries Catenaries are objects that represent the overhead wires that power electric trains. They are represented with the following attributes:\nvoltage: A string representing the type of power supply used for electrification track_ranges: A list of range of track sections (TrackRanges) covered by this catenary. A TrackRange is composed of a track section id, a begin offset and an end offset. In our example infrastructure, we have two Catenaries:\nOne with voltage set to \"1500\", which covers only TA0. One with voltage set to \"25000\", which covers all others except TD1. This means that only thermal trains can cross the TD1 track section.\nOur example also outlines that, unlike its real life counterpart, a single Catenary may cover the whole infrastructure.\nNeutral Sections In some parts of an infrastructure, the train drivers may be instructed - mainly for safety reasons - to cut the power supply to the train.\nTo represent such parts, we use NeutralSections. They are represented mainly with the following attributes:\ntrack_ranges: A list of DirectedTrackRanges (track ranges associated to a direction) which are covered by this neutral section. lower_pantograph: A boolean indicating whether the train’s pantograph should be lowered while in this section. In our example infrastructure, we have three NeutralSections: one at the junction of the \"1500\" and \"25000\" catenaries, one on TA6 and one on TG1 and TG4.\nFor more details about the model see the dedicated page.\nMiscellaneous Operational points Operational point is also known in French as “Point Remarquable” (PR). One OperationalPoint is a collection of points (OperationalPointParts) of interest.\nFor example, it may be convenient (reference point for train operation) to store the location of platforms as parts and group them by station in operational points. In the same way, a bridge over tracks will be one OperationalPoint, but it will have several OperationPointParts, one at the intersection of each track.\nIn the example infrastructure, we only used operational points to represent stations. Operational point parts are displayed as purple diamonds. Keep in mind a single operational point may contain multiple parts.\nLoading Gauge Limits These objects are akin to Slopes and Curves: it covers a range of track section, with a begin and an end offset. It represents a restriction on the trains that can travel on the given range, by weight or by train type (freight or passenger).\nWe did not put any in our examples.\nSpeed Sections The SpeedSections represent speed limits (in meters per second) that are applied on some parts of the tracks. One SpeedSection can span on several track sections, and do not necessarily cover the whole track sections. Speed sections can overlap.\nIn our example infrastructure, we have a speed section covering the whole infrastructure, limiting the speed to 300 km/h. On a smaller part of the infrastructure, we applied more restrictive speed sections.\n","categories":"","description":"Explains using an example how infrastructure data is structured","excerpt":"Explains using an example how infrastructure data is structured","ref":"/en/docs/explanation/models/data-models-full-example/","tags":"","title":"Infrastructure example"},{"body":"Description La couche de localisation permet à d’autres modules de simulation de suivre le déplacement du train dans l’infrastructure. L’infrastructure ferroviaire est découpée en régions appelées zones. Quand on train entre dans une zone, ce module permet d’en être notifié.\nLes zones (ou TVDSection / DetectionSection) sont des partitions physiques des voies :\ncapables de détecter la présence d’un train Exigences de conception il doit être possible de suivre les changements d’occupation d’une zone il devra être possible de suivre les déplacements d’un train il devra être possible d’implémenter un système de bloc mobile Dépendances statique une liste de zones Opérations Occuper une zone Libérer une zone Observer les changements d’occupation d’une zone ","categories":"","description":"Fournit les informations de position des trains sur le réseau","excerpt":"Fournit les informations de position des trains sur le réseau","ref":"/fr/docs/reference/design-docs/interlocking/location/","tags":"","title":"Localisation"},{"body":"","categories":"","description":"Ce qui est modélisé dans OSRD, et comment c'est modélisé","excerpt":"Ce qui est modélisé dans OSRD, et comment c'est modélisé","ref":"/fr/docs/explanation/models/","tags":"","title":"Modèles"},{"body":"","categories":"","description":"What is modeled in OSRD, and how it is modeled","excerpt":"What is modeled in OSRD, and how it is modeled","ref":"/en/docs/explanation/models/","tags":"","title":"Models"},{"body":"Physical object to model Introduction For a train to be able to run, it must either have an energy source on board (fuel, battery, hydrogen, …) or be supplied with energy throughout its journey.\nTo supply this energy, electrical cables are suspended above the tracks: the catenaries. The train then makes contact with these cables thanks to a conducting piece mounted on a mechanical arm: the pantograph.\nNeutral sections With this system it is difficult to ensure the electrical supply of a train continuously over the entire length of a line. On certain sections of track, it is necessary to cut the electrical supply of the train. These portions are called neutral sections.\nIndeed, in order to avoid energy losses along the catenaries, the current is supplied by several substations distributed along the tracks. Two portions of catenaries supplied by different substations must be electrically isolated to avoid short circuits.\nMoreover, the way the tracks are electrified (DC or not for example) can change according to the local uses and the time of installation. It is again necessary to electrically isolate the portions of tracks which are electrified differently. The train must also (except in particular cases) change its pantograph when the type of electrification changes.\nIn both cases, the driver is instructed to cut the train’s traction, and sometimes even to lower the pantograph.\nIn the French infrastructure, these zones are indicated by announcement, execution and end signs. They also carry the indication to lower the pantograph or not. The portions of track between the execution and end may not be electrified entirely, and may not even have a catenary (in this case the zone necessarily requires lowering the pantograph).\nREV (for reversible) signs are sometimes placed downstream of the end of zone signs. They are intended for trains that run with a pantograph at the rear of the train. These signs indicate that the driver can resume traction safely.\nAdditionally, it may sometimes be impossible on a short section of track to place a catenary or to raise the train’s pantograph. In this case the line is still considered electrified, and the area without electrification (passage under a bridge for example) is considered as a neutral section.\nRolling stock After passing through a neutral section, a train must resume traction. This is not immediate (a few seconds), and the necessary duration depends on the rolling stock.\nIn addition, the driver must, if necessary, lower his pantograph, which also takes time (a few tens of seconds) and also depends on the rolling stock.\nThus, the coasting imposed on the train extends outside the neutral section, since these system times are to be counted from the end of the neutral section.\nData model We have chosen to model the neutral sections as the space between the signs linked to it (and not as the precise zone where there is no catenary or where the catenary is not electrified).\nThis zone is directional, i.e. associated with a direction of travel, in order to be able to take into account different placements of signs according to the direction. The execution sign of a given direction is not necessarily placed at the same position as the end of zone sign of the opposite direction.\nFor a two-way track, a neutral section is therefore represented by two objects.\nThe schema is the following\n{ \"lower_pantograph\": boolean, \"track_ranges\": [ { \"track\": string, \"start\": number, \"end\": number, \"direction\": enum } ], \"announcement_track_ranges\": [ { \"track\": string, \"start\": number, \"end\": number, \"direction\": enum } ] } lower_pantograph: indicates whether the pantograph should be lowered in this section track_ranges: list of track sections ranges where the train must not traction announcement_track_ranges: list of track sections ranges between the announcement sign and the execution sign Display Map The zones displayed in the map correspond to the track_ranges of neutral sections, thus are between the execution and end signs of the zone. The color of the zone indicates whether the train must lower its pantograph in the zone or not.\nThe direction in which the zone applies is not represented.\nSimulation results In the linear display, it is always the area between EXE and FIN that is displayed.\nPathfinding Neutral sections are therefore portions of “non-electrified” track where an electric train can still run (but where it cannot traction).\nWhen searching for a path in the infrastructure, an electric train can travel through a track section that is not covered by the track_ranges of a catenary object (documentation to be written) only if it is covered by the track_ranges of a neutral section.\nSimulation In our simulation, we approximate the driver’s behavior as follows:\nThe coasting is started as soon as the train’s head passes the announcement sign The system times (pantograph reading and traction resumption) start as soon as the train’s head passes the end sign. In the current simulation, it is easier to use spatial integration bounds rather than temporal ones. We make the following approximation: when leaving the neutral section, we multiply the system times by the speed at the exit of the zone. The coasting is then extended over the obtained distance. This approximation is reasonable because the train’s inertia and the almost absence of friction guarantee that the speed varies little over this time interval.\nImprovements to be made Several aspects could be improved:\nWe do not model the REV signs, all trains therefore only have one pantograph at the front in our simulations. System times are approximated. The driver’s behavior is rather restrictive (coasting could start after the announcement sign). The display of the zones is limited: no representation of the direction or the announcement zones. These zones are not editable. ","categories":"","description":"Documentation about what they are and how they are implemented","excerpt":"Documentation about what they are and how they are implemented","ref":"/en/docs/explanation/models/neutral_sections/","tags":"","title":"Neutral Sections"},{"body":"The current implementation has a number of shortcomings making it pretty much impossible to evolve to meet current system requirements. It also has a number of less severe flaws, such as the over-reliance on floating point, especially for input and output.\nThe previous implementation cannot be changed to:\nreact to signaling, as constraints stay the same as the simulation evolves handle rich train state vectors, due to the way margins are implemented be usable for both incremental simulation and batch These limitations are the primary reasons for this redesign.\nMargins are defined as post-processing filter passes on simulation results. This has a number of undesirable side effects:\nmargin algorithms produce the final simulation results. They may produce physically unrealistic simulations results\nbecause margins are applied after the simulation, the simulation can’t adjust to impossible margin values. Thus the simulation fails instead of giving a “best effort” result.\nmargin algorithms have no choice but to piece together results of different simulations:\nengineering margins are defined such that their effect has to be entirely contained within their bounds. even though it’s a desirable property, it means that simulations become a multi-pass affair, with no obvious way of keeping train behavior consistent across passes and boundaries. this can only be done if the train state is entirely described by its location and speed, otherwise simulation results cannot be pieced together. piecing together simulation results is very hard to execute reliably, as there are many corner cases to be considered. the algorithm is quite brittle. how much time should be lost and where isn’t defined in a way that makes scheduled points implementation easy\nwhen a transition between two margin values occurs, slow downs occur before value changes, and speed ups after value changes. This is nice in theory, because it makes the graphs look nicer. The downside is that it makes margin values interdependent at each slow-down, as how much speed needs to be lost affects the time lost in the section.\nInput modeling With the previous implementation, the simulation takes sequence of constraint position and speed curves as an input (continuous in position, can be discontinuous in speed), and produces a continuous curve.\nThe output is fine, but the input is troublesome:\nbraking curves have to be part of constraint curves these constraint curves don’t have a direct match with actual constraints, such as speed limits, stops, or reaction to signal constraints cannot evolve over time, and cannot be interpreted differently depending on when the train reached these constraints constraints cannot overlap. the input is pre-processed to filter out obscured constraints ","categories":"","description":"","excerpt":"The current implementation has a number of shortcomings making it …","ref":"/en/docs/reference/design-docs/train-sim-v3/prior-art/","tags":"","title":"Prior art"},{"body":"Objet physique que l’on cherche à modéliser Introduction Pour qu’un train puisse circuler, il faut soit qu’il ait une source d’énergie à bord (fuel, batterie, hydrogène, …) soit qu’on l’alimente en énergie tout au long de son parcours.\nPour fournir cette énergie, des câbles électriques sont suspendus au dessus des voies: les caténaires. Le train assure ensuite un contact avec ces câbles grâce à un patin conducteur monté sur un bras mécanique: le pantographe.\nZones neutres Avec ce système il est difficile d’assurer l’alimentation électrique d’un train en continu sur toute la longueur d’une ligne: sur certaines portions de voie, il est nécessaire de couper l’alimentation électrique du train. Ce sont ces portions que l’on appelle zones neutres.\nEn effet, pour éviter les pertes énergétiques le long des caténaires, le courant est fourni par plusieurs sous-stations réparties le long des voies. Deux portions de caténaires alimentées par des sous-stations différentes doivent être isolées électriquement pour éviter les courts-circuits.\nPar ailleurs, la façon dont les voies sont électrifiées (courant continu ou non par exemple) peut changer selon les us locaux et l’époque d’installation. Il faut également isoler électriquement les portions de voies qui sont électrifiées différemment. Le train doit aussi (sauf cas particuliers) changer de pantographe lorsqu’il change de type d’électrification.\nDans ces deux cas on indique alors au conducteur de couper la traction du train, et parfois même d’en baisser le pantographe.\nDans l’infrastructure française, ces zones sont signalées par des panneaux d’annonce, d’exécution et de fin. Ces panneaux portent par ailleurs l’indication de baisser le pantographe ou non. Les portions de voies entre l’exécution et la fin peuvent ne pas être électrifiées entièrement, et même ne pas posséder de caténaire (dans ce cas la zone nécessite forcément de baisser le pantographe).\nParfois, des pancartes REV (pour réversible) sont placées en aval des panneaux de fin de zone. Elles sont destinées aux trains qui circulent avec un pantographe à l’arrière du train. Ces pancartes indiquent que le conducteur peut reprendre la traction en toute sécurité.\nPar ailleurs il peut parfois être impossible sur une courte portion de voie de placer une caténaire ou bien de lever le pantographe du train. Dans ce cas la ligne est tout de même considérée électrifiée, et la zone sans électrification (passage sous un pont par exemple) est considérée comme une zone neutre.\nMatériel roulant Après avoir traversé une zone neutre, un train doit reprendre la traction. Ce n’est pas immédiat (quelques secondes), et la durée nécessaire dépend du matériel roulant.\nIl doit également, le cas échéant, relever son pantographe, ce qui prend également du temps (quelques dizaines de secondes) et dépend également du matériel roulant.\nAinsi la marche sur l’erre imposée au train s’étend en dehors de la zone neutre, puisque ces temps systèmes sont à décompter à partir de la fin de la zone neutre.\nModèle de données Nous avons choisi de modéliser les zones neutres comme l’espace entre les panneaux liés à celle-ci (et non pas comme la zone précise où il n’y a pas de caténaire ou bien où la caténaire n’est pas électrifiée).\nCette zone est directionnelle, i.e. associée à un sens de circulation, pour pouvoir prendre en compte des placements de panneaux différents selon le sens. Le panneau d’exécution d’un sens donné n’est pas nécessairement placé à la même position que le panneau de fin de zone du sens opposé.\nPour une voie à double sens, une zone neutre est donc représentée par deux objets.\nLe schema est le suivant\n{ \"lower_pantograph\": boolean, \"track_ranges\": [ { \"track\": string, \"start\": number, \"end\": number, \"direction\": enum } ], \"announcement_track_ranges\": [ { \"track\": string, \"start\": number, \"end\": number, \"direction\": enum } ] } lower_pantograph : indique si le pantographe doit être baissé dans cette zone track_ranges : liste des portions de voie où le train ne doit pas tractionner announcement_track_ranges : liste des portions de voie entre le panneau d’annonce et le panneau d’exécution Affichage Cartographie Les zones affichées dans la cartographie correspondent aux track_ranges, donc entre les panneaux d’exécution et de fin de zone. La couleur de la zone indique si le train doit baisser son pantographe dans la zone ou non.\nLa direction dans laquelle la zone s’applique n’est pas représentée.\nRésultat de simulation Dans l’affichage linéaire, c’est toujours la zone entre EXE et FIN qui est affichée.\nRecherche d’itinéraire Les zones neutres sont donc des portions de voie “non électrifiées” où un train électrique peut tout de même circuler (mais où il ne peut pas tractionner).\nLors de la recherche de chemin dans l’infrastructure, une portion de voie qui n’est pas couverte par les track_ranges d’un objet caténaire (documentation à écrire) peut être empruntée par un train électrique seulement si elle est couverte par les track_ranges d’une zone neutre.\nSimulation Dans la simulation, nous approximons le comportement du conducteur de la façon suivante :\nLa marche sur l’erre est entamée dès que la tête du train passe le panneau d’annonce Le décompte des temps systèmes (relevé du pantographe et reprise de la traction) commence dès que la tête du train passe le panneau de fin. Dans la simulation actuelle, il est plus facile de manier des bornes d’intégration spatiales que temporelles. Nous effectuons l’approximation suivante: lors de la sortie de la zone neutre, on multiplie les temps systèmes par la vitesse en sortie de zone. La marche sur l’erre est alors prolongée de la distance obtenue. Cette approximation est raisonnable car l’inertie du train et la quasi-absence de frottement garantissent que la vitesse varie peu sur cet intervalle de temps.\nPotentielles améliorations Plusieurs points pourraient être améliorés :\nOn ne considère pas les pancartes REV, tous les trains ne possèdent donc qu’un pantographe à l’avant dans nos simulations. Les temps systèmes sont approximés. Le comportement conducteur est plutôt restrictif (la marche sur l’erre pourrait commencer après le panneau d’annonce). L’affichage des zones est limité: pas de représentation de la direction ou des zones d’annonce. Ces zones ne sont pas éditables. ","categories":"","description":"Documentation des zones neutres et de leur implémentation","excerpt":"Documentation des zones neutres et de leur implémentation","ref":"/fr/docs/explanation/models/neutral_sections/","tags":"","title":"Zones neutres"},{"body":"Ce module gère la recherche de solution.\nLes entrées et sorties sont fortement simplifiées et abstraites pour simplifier le problème au maximum et permettre des tests efficaces.\nPour décrire son fonctionnement en quelques phrases : l’espace de solutions est représenté sous forme d’un graphe qui encode le temps, la position et la vitesse. Une recherche de chemin est ensuite effectuée dans ce graphe pour trouver une solution. Le graphe est calculé au fil de son exploration.\nCe graphe peut d’une certaine manière être vu comme une forme d’arbre de décision, si différents chemins peuvent mener au même noeud.\n","categories":"","description":"","excerpt":"Ce module gère la recherche de solution.\nLes entrées et sorties sont …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/","tags":"","title":"Module de recherche de sillons"},{"body":"This module handles the search for solutions.\nTo reduce the problem to its simplest form and for easy and efficient testing, inputs and outputs are strongly simplified and abstracted.\nTo summarize its behavior: the solution space is described as a graph that encodes locations, time, and speed. A pathfinding is run on this graph to find a solution.\nThis graph could, in a way, be seen as a decision tree, but different paths can lead to the same node.\n","categories":"","description":"","excerpt":"This module handles the search for solutions.\nTo reduce the problem to …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/","tags":"","title":"Train slot search module"},{"body":"Le problème des discontinuités Au moment d’explorer une arête du graphe, on effectue un calcul de marche pour connaître l’évolution de la vitesse. Mais il n’est pas possible de voir plus loin que l’arête en question, ce qui est gênant pour calculer les courbes de freinages qui peuvent nécessiter de commencer à freiner plusieurs kilomètres avant l’arrivée.\nCet exemple illustre le problème : par défaut la première arête est explorée en allant à la vitesse maximale. C’est seulement en explorant la seconde arête que la destination devient visible, sans que la distance restante soit suffisante pour s’arrêter.\nLa solution : revenir en arrière Pour régler ce problème, lorsqu’une arête est générée avec une discontinuité dans les courbes de vitesse, l’algorithme revient sur les arêtes précédentes pour en créer des nouvelles qui incluent les décélérations.\nPour donner un exemple simplifié, sur un chemin de 4 routes où le train peut accélérer ou décélérer de 10km/h par route :\nPour que le train s’arrête à la fin de la route 4, il doit être au plus à 10km/h à la fin de la route 3. Une nouvelle arête est alors créée sur la route 3 qui finit à 10km/h. Une décélération est ensuite calculée à rebours de la fin de la route vers le début, jusqu’à retrouver la courbe d’origine (ou le début de l’arrête).\nDans cet exemple, la discontinuité a seulement été déplacée vers la transition entre les routes 2 et 3. Le procédé est ensuite réitéré sur la route 2, ce qui donne le résultat suivant :\nLes anciennes arêtes sont toujours présentes dans le graphe, elles peuvent mener à d’autres solutions.\n","categories":"","description":"","excerpt":"Le problème des discontinuités Au moment d’explorer une arête du …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/","tags":"","title":"Discontinuités et retours en arrière"},{"body":"The discontinuity problem When a new graph edge is visited, a simulation is run to evaluate its speed. But it is not possible to see beyond the current edge. This makes it difficult to compute braking curves, because they can span over several edges.\nThis example illustrates the problem: by default the first edge is explored by going at maximum speed. The destination is only visible once the second edge is visited, which doesn’t leave enough distance to stop.\nSolution : backtracking To solve this problem, when an edge is generated with a discontinuity in the speed envelopes, the algorithm goes back over the previous edges to create new ones that include the decelerations.\nTo give a simplified example, on a path of 4 edges where the train can accelerate or decelerate by 10km/h per edge:\nFor the train to stop at the end of route 4, it must be at most at 10km/h at the end of edge 3. A new edge is then created on edge 3, which ends at 10km/h. A deceleration is computed backwards from the end of the edge back to the start, until the original curve is met (or the start of the edge).\nIn this example, the discontinuity has only been moved to the transition between edges 2 and 3. The process is then repeated on edge 2, which gives the following result:\nOld edges are still present in the graph as they can lead to other solutions.\n","categories":"","description":"","excerpt":"The discontinuity problem When a new graph edge is visited, a …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/","tags":"","title":"Discontinuities and backtracking"},{"body":"The envelope system is an interface created specifically for the OSRD gait calculation. It allows you to manipulate different space/velocity curves, to slice them, to end them, to interpolate specific points, and to address many other needs necessary for the gait calculation.\nA specific interface in the OSRD Core service The envelope system is part of the core service of OSRD (see software architecture).\nIts main components are :\n1 - EnvelopePart: space/speed curve, defined as a sequence of points and having metadata indicating for example if it is an acceleration curve, a braking curve, a speed hold curve, etc.\n2 - Envelope: a list of end-to-end EnvelopeParts on which it is possible to perform certain operations:\ncheck for continuity in space (mandatory) and speed (optional) look for the minimum and/or maximum speed of the envelope cut a part of the envelope between two points in space perform a velocity interpolation at a certain position calculate the elapsed time between two positions in the envelope 3 - Overlays : system for adding more constrained (i.e. lower speed) EnvelopeParts to an existing envelope.\nGiven envelopes vs. calculated envelopes During the simulation, the train is supposed to follow certain speed instructions. These are modelled in OSRD by envelopes in the form of space/speed curves. Two types can be distinguished:\nEnvelopes from infrastructure and rolling stock data, such as maximum line speed and maximum train speed. Being input data for our calculation, they do not correspond to curves with a physical meaning, as they are not derived from the results of a real integration of the physical equations of motion. The envelopes result from real integration of the physical equations of motion. They correspond to a curve that is physically tenable by the train and also contain time information. A simple example to illustrate this difference: if we simulate a TER journey on a mountain line, one of the input data will be a maximum speed envelope of 160km/h, corresponding to the maximum speed of our TER. However, this envelope does not correspond to a physical reality, as it is possible that on certain sections the gradient is too steep for the train to be able to maintain this maximum speed of 160km/h. The calculated envelope will therefore show in this example a speed drop in the steepest areas, where the envelope given was perfectly flat.\nSimulation of several trains In the case of the simulation of many trains, the signalling system must ensure safety. The effect of signalling on the running calculation of a train is reproduced by superimposing dynamic envelopes on the static envelope. A new dynamic envelope is introduced for example when a signal closes. The train follows the static economic envelope superimposed on the dynamic envelopes, if any. In this simulation mode, a time check is performed against a theoretical time from the time information of the static economic envelope. If the train is late with respect to the scheduled time, it stops following the economic envelope and tries to go faster. Its space/speed curve will therefore be limited by the maximum effort envelope.\n","categories":"","description":"","excerpt":"The envelope system is an interface created specifically for the OSRD …","ref":"/en/docs/explanation/running_time_calculation/envelopes_system/","tags":"","title":"Envelopes system"},{"body":"Le système d’enveloppes est une interface créée spécifiquement pour le calcul de marche d’OSRD. Il permet de manipuler différentes courbes espace/vitesse, de les découper, de les mettre bout à bout, d’interpoler des points spécifiques, et d’adresser beaucoup d’autres besoins nécessaires au calcul de marche.\nUne interface spécifique dans le service OSRD Core Le système d’enveloppes fait partie du service core d’OSRD (voir l’architecture du logiciel).\nSes principaux composants sont :\n1 - EnvelopePart : courbe espace/vitesse, définie comme une séquence des points et possédant des métadonnées indiquant par exemple s’il s’agit d’une courbe d’accélération, de freinage, de maintien de vitesse, etc.\n2 - Envelope : liste d’EnvelopeParts mises bout-à-bout et sur laquelle il est possible d’effectuer certaines opérations :\nvérifier la continuité dans l’espace (obligatoire) et dans la vitesse (facultative) chercher la vitesse minimale et/ou maximale de l’enveloppe couper une partie de l’enveloppe entre deux points de l’espace effectuer une interpolation de vitesse à une certaine position calculer le temps écoulé entre deux positions de l’enveloppe 3 - Overlays : système permettant d’ajouter des EnvelopePart plus contraignantes (c’est-à-dire dont la vitesse est plus faible) à une enveloppe existante.\nEnveloppes données vs enveloppes calculées Pendant la simulation, le train est censé suivre certaines instructions de vitesse. Celles-ci sont modélisées dans OSRD par des enveloppes sous forme de courbes espace/vitesse. On en distingue deux types :\nLes enveloppes provenant des données d’infrastructure et de matériel roulant, comme la vitesse maximale de la ligne et la vitesse maximale du train. Etant des données d’entrée de notre calcul, elles ne correspondent pas à des courbes ayant un sens physique, car elles ne sont pas issues des résultats d’une intégration réelle des équations physiques du mouvement. Les enveloppes résultant d’une intégration réelle des équations du mouvement physique. Elles correspondent à une courbe physiquement tenable par le train et contiennent également des informations sur le temps. Un exemple simple pour illustrer cette différence : si l’on simule un trajet de TER sur une ligne de montagne, une des données d’entrée va être une enveloppe de vitesse maximale à 160km/h, correspondant à la vitesse maximale de notre TER. Mais cette enveloppe ne correspond pas à une réalité physique, car il se peut que sur certaines portions la rampe soit trop raide pour que le train arrive effectivement à maintenir cette vitesse maximale de 160km/h. L’enveloppe calculée présentera donc dans cet exemple un décrochage de vitesse dans les zones de fortes rampes, là où l’enveloppe donnée était parfaitement plate.\nSimulation de plusieurs trains Dans le cas de la simulation de nombreux trains, le système de signalisation doit assurer la sécurité. L’effet de la signalisation sur le calcul de marche d’un train est reproduit en superposant des enveloppes dynamiques à l’enveloppe statique. Une nouvelle enveloppe dynamique est introduite par exemple lorsqu’un signal se ferme. Le train suit l’enveloppe économique statique superposée aux enveloppes dynamiques, s’il y en a. Dans ce mode de simulation, un contrôle du temps est effectué par rapport à un temps théorique provenant de l’information temporelle de l’enveloppe économique statique. Si le train est en retard par rapport à l’heure prévue, il cesse de suivre l’enveloppe économique et essaie d’aller plus vite. Sa courbe espace/vitesse sera donc limitée par l’enveloppe d’effort maximum.\n","categories":"","description":"","excerpt":"Le système d’enveloppes est une interface créée spécifiquement pour le …","ref":"/fr/docs/explanation/running_time_calculation/envelopes_system/","tags":"","title":"Le système d'enveloppes"},{"body":"OSRD peut être utilisé pour effectuer deux types de calculs :\nCalcul de marche (standalone train simulation) : calcul du temps de parcours d’un train sur un trajet donné, effectué sans interaction entre le train et le système de signalisation. Simulation : calcul “dynamique” de plusieurs trains interagissant entre eux via le système de signalisation. 1 - Les données d’entrée Un calcul de marche est basé sur 5 entrées :\nL’infrastructure : Topologie des lignes et des voies, position des gares et bâtiments voyageurs, position et type des aiguilles, signaux, vitesses maximales de ligne, profil de ligne corrigée (pentes, rampes et virages). L’histogramme bleu est une représentation des déclivités en [‰] par position en [m]. Les déclivités sont positives pour les rampes et négatives pour les pentes.\nLa ligne orange représente le profil cumulé, c’est-à-dire l’altitude relative par rapport au point de départ.\nLa ligne bleue est une représentation des virages en termes de rayons des courbures en [m].\nLe matériel roulant : Dont les caractéristiques nécessaires pour effectuer la simulation sont représentées ci-dessous. La courbe orange, appelée courbe effort-vitesse du matériel, représente l’effort moteur maximal en fonction de la vitesse de circulation.\nLa longueur, la masse, et la vitesse max du train sont représentées en bas de l’encadré.\nL’horaire de départ permettant ensuite de calculer les horaires de passage aux différents points remarquables (dont gares).\nLes marges : Temps ajouté au trajet du train pour détendre sa marche (voir page sur les marges).\nLe pas de temps pour le calcul de l’intégration numérique. 2 - Les résultats Les résultats d’un calcul de marche peuvent se représenter sous différentes formes :\nLe graphique espace/temps (GET) : représente le parcours des trains dans l’espace et dans le temps, sous la forme de traits globalement diagonaux dont la pente est la vitesse. Les arrêts apparaissent sous la forme de plateaux horizontaux. Exemple de GET avec plusieurs trains espacés d’environ 30mn.\nL’axe x est l’horaire de passage du train, l’axe y est la position du train en [m].\nLa ligne bleue représente le calcul de marche le plus tendu pour le train, la ligne verte représente un calcul de marche détendu, dit « économique ».\nLes rectangles pleins entourant les trajets représentent les portions de la voie successivement reservées au passage du train (appelées cantons).\nLe graphique espace/vitesse (GEV) : représente le parcours d’un seul train, cette fois-ci en termes de vitesse. Les arrêts apparaissent donc sous forme de décrochages de la courbe jusqu’à zéro, suivis d’un réaccélération. L’axe x est la position du train en [m], l’axe y est la vitesse du train en [km/h] .\nLa ligne violette représente la vitesse maximale autorisée.\nLa ligne bleue représente la vitesse dans le cas du calcul de marche le plus tendu.\nLa ligne verte représente la vitesse dans le cas du calcul de marche « économique ».\nLes horaires de passage du train aux différents points remarquables ","categories":"","description":"","excerpt":"OSRD peut être utilisé pour effectuer deux types de calculs :\nCalcul …","ref":"/fr/docs/explanation/running_time_calculation/","tags":"","title":"Calcul de marche"},{"body":"Whether you would like to use OSRD, understand it or contribute, this is the right place!\n","categories":"","description":"","excerpt":"Whether you would like to use OSRD, understand it or contribute, this …","ref":"/en/docs/","tags":"","title":"Documentation"},{"body":"Vous souhaitez utiliser OSRD, y contribuer, ou simplement en comprendre le fonctionnement ? Cette documentation est pour vous !\n","categories":"","description":"","excerpt":"Vous souhaitez utiliser OSRD, y contribuer, ou simplement en …","ref":"/fr/docs/","tags":"","title":"Documentation"},{"body":"Driving instructions model what the train has to do, and under what conditions. Driving instructions are generated using domain constraints such as:\nunsignaled line speed limits permanent signaled speed limits temporary speed limits dynamic signaling: block / moving block dynamically signaled speed restrictions neutral zones stops margins There are two types of driving instructions:\nAbstract driving instructions model the high-level, rolling stock independent range of acceptable behavior: reach 30km/h at this location Concrete driving instructions model the specific range of acceptable behavior for a specific rolling stock, using limit curves: don’t go faster than this curve flowchart TD Constraint[constraint] AbstractDrivingInstruction[abstract driving instruction] ConcreteDrivingInstruction[concrete driving instruction] RollingStockIntegrator[rolling stock integrator] Compiler([compiler]) Constraint -- generates one or more --\u003e AbstractDrivingInstruction AbstractDrivingInstruction --\u003e Compiler RollingStockIntegrator --\u003e Compiler Compiler --\u003e ConcreteDrivingInstruction After reviewing the design document, the necessity to distinguish between abstract and concrete driving instructions was questioned.\nIndeed, it isn’t clear whether the limit curves are used for the driving instructions interpretation algorithm. If it isn’t, the computation of limit curves could be moved inside the driver behavior module.\nTODO: remove this message or fix the design document after implementation.\nInterpreting driving instructions During the simulation, driving instructions are partitioned into 4 sets:\nPENDING instructions may apply at some point in the future RECEIVED instructions aren’t enforced yet, but will be unless overridden ENFORCED instructions influence train behavior DISABLED instructions don’t ever have to be considered anymore. There are multiple ways instructions can be disabled: SKIPPED instructions were not received RETIRED instructions expired by themselves OVERRIDDEN instructions were removed by another instruction flowchart TD subgraph disabled skipped retired overridden end subgraph active received enforced end pending --\u003e received pending --\u003e skipped received --\u003e enforced received --\u003e overridden enforced --\u003e retired enforced --\u003e overridden These sets evolve as follows:\nwhen an integration steps overlaps a PENDING instruction’s received condition, it is RECEIVED and becomes a candidate to execution existing instructions may be OVERRIDDEN due to an override_on_received operation if an instruction cannot ever be received at any future simulation state, it transitions to the SKIPPED state when simulation state exceeds an instruction’s enforcement position, it becomes ENFORCED. Only enforced instructions influence train behavior. existing instructions may be OVERRIDDEN due to an override_on_enforced operation when simulation state exceeds an instruction’s retirement position, it becomes RETIRED Overrides When an instruction transitions to the RECEIVED or ENFORCED state, it can disable active instructions which match some metadata predicate. There are two metadata attributes which can be relied on for overrides:\nthe kind allows overriding previous instructions for a given domain, such as spacing or block signaled speed limits the rank can be used as a “freshness” or “priority” field. If two instructions overriding each other are received (such as when a train sees two signals), the rank allows deciding which instruction should be prioritized. This is required to implement a number of signaling features, as well as stops, where the stop instruction is overridden by the restart instruction.\nData model struct ReceivedCond { position_in: Option\u003cPosRange\u003e, time_in: Option\u003cTimeRange\u003e, } struct InstructionMetadata { // state transitions received_when: ReceivedCond, enforced_at: Position, retired_at: Option\u003cPosition\u003e, // instruction metadata, used by override filters. if an instruction // has no metadata nor retiring condition, it cannot be overridden. kind: Option\u003cInstructionKindId\u003e, // could be SPACING, SPEED_LIMIT rank: Option\u003cusize\u003e, // when the instruction transitions to a given state, // instructions matching any filter are overridden override_on_received: Vec\u003cOverrideFilter\u003e, override_on_enforced: Vec\u003cOverrideFilter\u003e, } enum AbstractInstruction { NeutralZone, SpeedTarget { at: Position, speed: Speed, } } enum ConcreteInstruction { NeutralZone, SpeedTarget { braking_curve: SpeedPosCurve, }, } struct OverrideFilter { kind: InstructionKindId, rank: Option\u003c(RankRelation, usize)\u003e, } enum RankRelation { LT, LE, EQ, GE, GT } Design decisions Lowering constraints to an intermediate representation Early on, we started making lists of what domain constraints can have an impact on train behavior. Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.\nThere’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:\neither treat each type of constraint as its own thing during the simulation abstract away constraints into a common representation, and then simulate that ❌ Distinct constraint types When we first started drafting architecture diagrams, the train simulation API directly took a bunch of constraint types as an input. It brought up a number of issues:\nthe high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types the domain of some of these interactions is very complex (block signaling) when simulating, it does not seem to matter why a constraint is there, only what to do about it We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.\n❌ Internal constraint types abstraction We then realized that abstracting over constraint types during simulation had immense benefits:\nit allows expressing requirements on what constraints need to be enforceable it greatly simplifies the process of validating constraint semantics: instead of having to validate interactions between every possible type of constraints, we only have to validate that the semantics of each constraint type can be transferred to the abstract constraint type We decided to explore the possibility of keeping constraint types distinct in the external API, but lowering these constraints into an intermediary representation internally. We found a number of downsides:\nthe public simulation API would still bear the complexity of dealing with many constraint types there would be a need to incrementally generate internal abstracted constraints to support the incremental API ✅ External constraint types abstraction We tried to improve over the previous proposal by moving the burden of converting many constraints into a common abstraction out of the simulation API.\nInstead of having many constraint types as an input, the simulation API takes a collection of a single abstract constraint type. The task of converting domain constraints to abstract driving instructions is left to the API user.\nWe found that doing so:\nreduces the API surface of the train simulation module decouples behavior from constraint types: if a new constraint type needs to be added, the simulation API only needs expansion if the expected behavior expected for this constraint isn’t part of the API. Interpreting driving instructions As the train progresses through the simulation, it reacts according to driving instructions which depend on more than the bare train physics state (position, time, and speed):\nthe behavior of a train on each block depends on the state of the last passed block signal if a train encounters a yellow light, then a red light, stops before the red light, and the red light turns green, the train may have to keep applying the driving instruction from the yellow signal until the green light is passed Thus, given:\nset of all possible driving instructions (alongside applicability metadata) the result of previous integration steps (which may be extended to hold metadata) There is a need to know what driving instructions are applicable to the current integration step.\nOverrides are a way of modeling instructions which disable previous ones. Here are some examples:\nif a driver watches a signal change state, its new aspect’s instruction might take precedence over the previous one as block signaling slows a train down, new signals can override instructions from previous signals, as they encode information that is more up to date We identified multiple filtering needs:\noverrides happen as a given kind of restriction is updated: SPACING instructions might override other SPACING instructions, but wish to leave other speed restrictions unaffected as multiple block signals can be visible at once, there’s a need to avoid overriding instructions of downstream signals with updates to upstream signals We quickly settled on adding a kind field, but had a lengthy discussion over how to discriminate upstream and downstream signals. We explored the following options:\n❌ adding source metadata, which was rejected as it does not address the issue of upstream / downstream ❌ adding identifiers to instructions, and overriding specific instructions, which was rejected as it makes instruction generation and processing more complex ✅ adding some kind of priority / rank field, which was adopted ","categories":"","description":"","excerpt":"Driving instructions model what the train has to do, and under what …","ref":"/en/docs/reference/design-docs/train-sim-v3/driving-instruction/","tags":"","title":"Driving instructions"},{"body":"Les guides pratiques sont des marches à suivre. Vous êtes guidés pas-à-pas dans la résolution de problèmes, ou dans des scénarios classiques. Les connaissances requises sont plus élevées que pour les tutoriels, et le fonctionnement d’OSRD doit être compris.\n","categories":"","description":"Marches à suivre pour des tâches classiques","excerpt":"Marches à suivre pour des tâches classiques","ref":"/fr/docs/guides/","tags":"","title":"Guides pratiques"},{"body":"How-to guides are recipes. They guide you through the steps involved in addressing key problems and use-cases. They are more advanced than tutorials and assume some knowledge of how OSRD works.\n","categories":"","description":"Recipes for addressing key problems and use-cases","excerpt":"Recipes for addressing key problems and use-cases","ref":"/en/docs/guides/","tags":"","title":"How-to Guides"},{"body":" Le mot réservation ici a pour sens réservation de la resource itinéraire, et non le sens commande plannifiée d’itinéraire Description Les zones (ou TVDSection / DetectionSection) sont des partitions physiques des voies :\ncapables de détecter la présence d’un train qui fournissent un service de réservation à l’usage des routes Chaque zone a un certain nombre de configurations différentes. Par exemple, une zone sans aiguille aura deux configurations :\nsens pair sens impair Une zone avec une aiguille aura 4 configurations possibles :\nsens pair voie principale sens impair voie principale sens pair voie déviation sens impair voie déviation Chaque zone ne peut être réservée que pour une configuration donnée à la fois, mais peut être réservée simultanément par plusieurs routes. Une zone ne peut changer de configuration que lorsqu’elle n’est pas réservée.\nEn discutant avec des experts métiers, vous entendrez parler d’enclenchements: le terme viens de l’époque où les postes de signalisations étaient entièrement mécaniques. Les enclenchements étaient alors des objets physiques qui empêchaient certaines configurations.\nUne conséquence de cet héritage historique et que beaucoup de règles ferroviaires sont exprimées par contraintes au lieu d’être exprimées par garanties. Un enclenchement, c’est une garantie qu’une situation particulière ne peut pas se produire.\nÉtat dynamique d’une zone enum ZoneState { /// A list of active reservations. /// Each reservation requires a particular configuration to be upheld. reservations: VecDeque\u003cZoneReservation\u003e, } struct ZoneReservation { /// The train which requires this reservation train: TrainHandle, // The configuration required for this reservation requirements: ZoneRequirements, /// The state of this reservation status: ZoneReservationStatus, } enum ZoneReservationStatus { /// In the process of being reserved, but not yet ready PRE_RESERVED, /// The train can arrive anytime RESERVED, /// The train is inside the zone OCCUPIED, /// The zone is pending release PENDING_RELEASE, } struct ZoneRequirements { entry: Option\u003cDirDetector\u003e, exit: Option\u003cDirDetector\u003e, movable_elements: Map\u003cMovableElement, MovableElementConfig\u003e, } impl ZoneState { /// Get the combined requirements for all the currently active reservations fn get_combined_requirements(\u0026self) -\u003e Option\u003cZoneRequirements\u003e { return self.reservations .map(|res| \u0026res.requirements) .reduce(|a, b| ZoneRequirements::combine(a, b)) } } Exigences de conception Les zones doivent pouvoir être verrouillées dans une configuration particulière. Il doit être possible pour plusieurs routes de partager une réservation de configuration. Il doit être possible d’observer l’évolution de statut d’une réservation. Il doit être possible de faire évoluer le statut d’une réservation. Dépendances statique les détecteurs qui délimitent chaque zone statique les aiguilles dans chaque zone dynamique capacité d’observer l’occupation des zones dynamique capacité d’actionner les éléments mobiles Opérations espacement: Observer l’état d’une zone routage: Verrouiller et déverrouiller la zone : permet d’obtenir un droit d’action. Toutes les opérations en écriture nécessitent d’avoir acquis le verrou. routage: Attendre que toutes les réservations d’une zone expirent routage: Pré-réserver une configuration de zone routage: Confirmer la réservation d’une zone routage: Attendre que la réservation de la zone soit occupée par son train routage: Relacher une réservation de zone ","categories":"","description":"Gère l'état de réservation des zones","excerpt":"Gère l'état de réservation des zones","ref":"/fr/docs/reference/design-docs/interlocking/reservation/","tags":"","title":"Reservation"},{"body":"OSRD can be used to perform two types of calculations:\nStandalone train simulation: calculation of the travel time of a train on a given route without interaction between the train and the signalling system. Simulation: “dynamic” calculation of several trains interacting with each other via the signalling system. 1 - The input data A running time calculation is based on 5 inputs:\nInfrastructure: Line and track topology, position of stations and passenger buildings, position and type of points, signals, maximum line speeds, corrected line profile (gradients, ramps and curves). The blue histogram is a representation of the gradients in [‰] per position in [m]. The gradients are positive for ramps and negative for slopes.\nThe orange line represents the cumulative profile, i.e. the relative altitude to the starting point.\nThe blue line is a representation of turns in terms of radii of curves in [m].\nThe rolling stock: The characteristics of which needed to perform the simulation are shown below. The orange curve, called the effort-speed curve, represents the maximum motor effort as a function of the speed of travel.\nThe length, mass, and maximum speed of the train are shown at the bottom of the box.\nThe departure time is then used to calculate the times of passage at the various points of interest (including stations).\nAllowances: Time added to the train’s journey to relax its running (see page on allowances).\nThe time step for the calculation of numerical integration. 2 - The results The results of a running time calculation can be represented in different forms:\nThe space/time graph (GET): represents the path of trains in space and time, in the form of generally diagonal lines whose slope is the speed. Stops are shown as horizontal plates. Example of a GET with several trains spaced about 30 minutes apart.\nThe x axis is the time of the train, the y axis is the position of the train in [m].\nThe blue line represents the most tense running calculation for the train, the green line represents a relaxed, so-called “economic” running calculation.\nThe solid rectangles surrounding the paths represent the portions of the track successively reserved for the train to pass (called blocks).\nThe space/speed graph (SSG): represents the journey of a single train, this time in terms of speed. Stops are therefore shown as a drop in the curve to zero, followed by a re-acceleration. The x axis is the train position in [m], the y axis is the train speed in [km/h].\nThe purple line represents the maximum permitted speed.\nThe blue line represents the speed in the case of the most stretched running calculation.\nThe green line represents the speed in the case of the “economic” travel calculation.\nThe timetable for the passage of the train at the various points of interest. ","categories":"","description":"","excerpt":"OSRD can be used to perform two types of calculations:\nStandalone …","ref":"/en/docs/explanation/running_time_calculation/","tags":"","title":"Running time calculation"},{"body":"Description Railway infrastructure has a surprising variety of speed limits:\nsome are known by the driver, and not announced at all some are announced by fixed signs regardless of where the train goes some are announced by fixed signs, depending on where the train path goes some are announced by dynamic signals regardless of where the train goes some are announced by dynamic signals, depending on where the train path goes Data model { # unique speed limit identifier \"id\": \"...\", # A list of routes the speed limit is enforced on. When empty # or missing, the speed limit is enforced regardless of the route. # # /!\\ When a speed section is announced by signals, the routes it is # announced on are automatically filled in /!\\ \"on_routes\": [\"${ROUTE_A}\", \"${ROUTE_B}\"] # \"on_routes\": null, # not conditional # \"on_routes\": [], # conditional # A speed limit in meters per second. \"speed_limit\": 30, # A map from train tag to speed limit override. If missing and # the speed limit is announced by a signal, this field is deduced # from the signal. \"speed_limit_by_tag\": {\"freight\": 20}, \"track_ranges\": [{\"track\": \"${TRACK_SECTION}\", \"begin\": 0, \"end\": 42, \"applicable_directions\": \"START_TO_STOP\"}], } Design considerations Where to put the speed limit value When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:\nonce in the signal itself once in the speed limit There are multiple ways this issue can be dealt with:\n✅ Mandatory speed limit value in the speed section Upsides:\nsimpler to implement, works even without train reactions to signals nor additional API Downsides:\nmore work on the side of users room for inconsistencies between the speed limit announced by signaling, and the effective speed limit ❌ Deduce the signal constraint from the speed limit This option was not explored much, as it was deemed awkward to deduce signal parameters from a speed limit value.\n❌ Deduce the speed limit from the signal Make the speed limit value optional, and deduce it from the signal itself. Speed limits per tag also have to be deduced if missing.\nUpsides:\nless work for users lessens the likelyhood of configuration mismatches Downsides:\nnot all signaling systems work well with this. It may be difficult to deduce the announced speed limit from a signal configuration, such as with TVM. speed limits have to be deduced, which increases implementation complexity How to link announce signals and speed limit area Speed limit announced by dynamic signaling often start being enforced at a specific location, which is distinct from the signal which announces the speed limit.\nTo allow for correct train reactions to this kind of limits, a link between the announce signal and the speed limit section has to be made at some point.\n❌ Automated matching of signals and speed sections Was not deemed realistic.\n❌ Explicit link from route to speed limit and signals Was deemed to be awkward, as signaling is currently built over interlocking. Referencing signaling from interlocking creates a circular dependency between the two schemas.\n❌ Explicit link from speed limit to signals Add a list of (route, signal) tuples to speed sections.\nUpside:\na link with the signal can be made with creating the speed section Downside:\nCreates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred. Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work. ❌ Inlining speed limit definitions into signals Introduces a new type of speed limit, which are announced by signals. These speed limits are directly defined within signal definitions.\n{ # ... \"conditional_parameters\": [ { \"on_route\": \"${ROUTE_ID}\", \"speed_section\": { \"speed_limit\": 42, \"begin\": {\"track\": \"a\", \"offset\": 10}, \"end\": {\"track\": \"b\", \"offset\": 15}, }, \"parameters\": {\"rappel30\": \"true\", \"short_block\": \"true\"} } ] # ... } Upsides:\nstraightforward infrastructure edition experience for speed sections announced by a single signal Downsides:\ncreates two separate kinds of speed limits: can cause code duplication could make later changes of the data model trickier it’s unclear whether the criterion used to make this partition is appropriate speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction) the cost of reversing this decision could be fairly high ✅ Explicit link from signal to speed section { # ... \"conditional_parameters\": [ { \"on_route\": \"${ROUTE_ID}\", \"announced_speed_section\": \"${SPEED_SECTION_ID}\", \"parameters\": {\"rappel30\": \"true\", \"short_block\": \"true\"} } ] # ... } Upsides:\nsingle unified way of declaring speed limits very close to the current implementation Downsides:\nadds a level of indirection between the signal and the speed section the edition front-end has to be smart enough to create / search speed sections from the signal edition menu Speed limits by route Some speed limits only apply so some routes. This relationship needs to be modeled:\nspeed limits could have a list of routes they apply on routes could have a list of speed limits they enforce the routes a speed limit apply on could be deduced from its announce signals, plus an explicit list of routes per speed section We took option 3.\n","categories":"","description":"Describes how speed limits work","excerpt":"Describes how speed limits work","ref":"/en/docs/reference/design-docs/signaling/speed-limits/","tags":"","title":"Speed limits"},{"body":"While exploring the graph, it is possible to end up in locations that would generate conflicts. They can be avoided by adding delay.\nShifting the departure time The departure time is defined as an interval in the module parameters: the train can leave at a given time, or up to x seconds later. Whenever possible, delay should be added by shifting the departure time.\nfor example : a train can leave between 10:00 et 11:00. Leaving at 10:00 would cause a conflict, the train actually needs to enter the destination station 15 minutes later. Making the train leave at 10:15 solves the problem.\nIn OSRD, this feature is handled by keeping track, for every edge, of the maximum duration by which we can delay the departure time. As long as this value is enough, conflicts are avoided this way.\nThis time shift is a value stored in every edge of the path. Once a path is found, the value is summed over the whole path. This is added to the departure time.\nFor example :\na train leaves between 10:00 and 11:00. The initial maximum time shift is 1:00. At some point, an edge becomes unavailable 20 minutes after the train passage. The value is now at 20 for any edge accessed from here. The departure time is then delayed by 5 minutes to avoid a conflict. The maximum time shift value is now at 15 minutes. This process is applied until the destination is found, or until no more delay can be added this way. Engineering allowances Once the maximum delay is at 0, the delay needs to be added between two points of the path.\nThe idea is the same as the one used to fix speed discontinuities: new edges are created, replacing the previous ones. The new edges have an engineering allowance, to add the delay where it is possible.\ncomputing an engineering allowance is a feature of the running-time calculation module. It adds a given delay between two points of a path, without affecting the speeds on the rest of the path.\nPost-processing We used to compute the engineering allowances during the graph exploration, but that process was far too expensive. We used to run binary searches on full simulations, which would sometimes go back for a long distance in the path.\nWhat we actually need is to know whether an engineering allowance is possible without causing any conflict. We can use heuristics here, as long as we’re on the conservative side: we can’t say that it’s possible if it isn’t, but missing solutions with extremely tight allowances isn’t a bad thing in our use cases.\nBut this change means that, once the solution is found, we can’t simply concatenate the simulation results. We need to run a full simulation, with actual engineering allowances, that avoid any conflict. This step has been merged with the one described on the standard allowance page, which is now run even when no standard allowance have been set.\n","categories":"","description":"","excerpt":"While exploring the graph, it is possible to end up in locations that …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/","tags":"","title":"Conflict avoidance"},{"body":"En explorant le graphe, il arrive souvent de tomber sur des situations qui mèneraient à des conflits. Il faut être en mesure de rajouter du délai pour les éviter.\nDécalage du temps de départ Dans les paramètres de l’algorithme, le temps de départ est donné sous la forme d’une fenêtre : un temps de départ au plus tôt et au plus tard. Tant que c’est possible, il est toujours préférable de décaler le temps de départ pour éviter les conflits.\nPar exemple : un train doit partir entre 10:00 et 11:00. En partant à 10:00, cela provoque un conflit, le train doit entrer en gare d’arrivée 15 minutes plus tard. Il suffit de faire partir le train à 10:15 pour régler le problème.\nDans OSRD, cette fonctionnalité est gérée en gardant une trace, à chaque arête, du décalage maximal du temps de départ qui pourra être ajouté sur la suite du parcours. Tant que cette valeur est suffisante, tous les conflits sont évités par ce moyen.\nLe décalage du temps de départ est une valeur stockée sur chaque arête et additionnée à la fin de la recherche de chemin.\nPar exemple :\nun train doit partir entre 10:00 et 11:00. La recherche commence avec un délai maximal de 1:00. Après quelques arêtes, une non-disponibilité est constatée 20 minutes après notre passage. La valeur passe donc à 20 minutes pour la suite du parcours. Le temps de départ est ensuite décalé de 5 minutes pour contourner un conflit, modifiant le décalage maximal à 15 minutes. Ce procédé continue jusqu’à arriver à la fin du trajet, ou jusqu’au point où il faut ajouter plus de délai. Marges de construction Quand la valeur de décalage maximal du temps de départ tombe à 0, il faut rajouter du délai entre deux points du parcours du train.\nLe principe est le même que pour régler les discontinuités de vitesse : le graphe est parcouru en arrière pour créer de nouvelles arêtes.\nLa marge de construction est une fonctionnalité du calcul de marche permettant d’ajouter un délai donné entre deux points du parcours.\nPost-processing Les marges de constructions étaient calculées pendant l’exploration du graph, mais ce procédé était trop couteux en temps de calcul. On effectuait des dichotomies sur des simulations qui pouvaient s’étendre sur des portions importantes du chemin.\nOn a seulement besoin de savoir si la marge de construction peut être réalisée sans provoquer de conflit. Des heuristiques peuvent être utilisées ici tant qu’on est plus restrictif que permissif : une marge impossible doit être identifiée comme telle, mais manquer une solution avec une marge extrêmement serrée n’est pas une mauvaise chose.\nMais avec ce changement, une fois qu’une solution est trouvée, il ne suffit plus de concaténer les résultats de simulation pour obtenir la simulation finale. On doit réaliser une simulation complète avec les vraies marges de construction qui évitent tout conflit. Cette étape se rejoint avec celle décrite pour les marges de régularité, qui est maintenant réalisée même sans marge de régularité spécifiée.\n","categories":"","description":"","excerpt":"En explorant le graphe, il arrive souvent de tomber sur des situations …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/","tags":"","title":"Contourner les conflits"},{"body":"Le calcul de marche dans OSRD est un processus à 4 étapes, utilisant chacune le système d’enveloppes :\nConstruction du profil de vitesse le plus restrictif Ajout des différentes courbes de freinage Ajout des différentes courbes d’accélération et vérification des courbes de vitesse constante Application de marge(s)  \nCalcul du profil de vitesse le plus restrictif Une première enveloppe est calculée au début de la simulation en regroupant toutes les limites de vitesse statiques :\nvitesse maximale de la ligne vitesse maximale du matériel roulant limitations temporaires de vitesse (en cas de travaux sur une ligne par exemple) limitations de vitesse par catégorie de train limitations de vitesse selon la charge du train limitations de vitesse correspondant à des panneaux de signalisation La longueur du train est également prise en compte pour s’assurer que le train n’accélère qu’une fois sa queue ayant quitté la zone de plus faible vitesse. Un décalage est alors appliqué à la courbe en pointillée rouge. L’enveloppe résultante (courbe noire) est appelée MRSP (Most Restricted Speed Profile) correspondant donc au profil de vitesse le plus restrictif. C’est sur cette enveloppe que seront calculées les étapes suivantes.\nLa ligne pointillée rouge représente la vitesse maximale autorisée en fonction de la position. La ligne noire représente le MRSP où la longueur du train a été prise en compte.\nIl est à noter que les différentes envelopeParts composant le MRSP sont des données d’entrée, elles ne correspondent donc pas à des courbes avec une réalité physique.\nCalcul du profil de vitesse maximale En partant du MRSP, toutes les courbes de freinage sont calculées grâce au système d’overlay (voir ici pour plus de détails sur les overlays), c’est-à-dire en créant des envelopeParts qui seront plus restrictives que le MRSP. La courbe ainsi obtenue est appelée Max Speed Profile (profil de vitesse maximale). Il s’agit de l’enveloppe de vitesse maximale du train, tenant compte de ses capacités de freinage.\nEtant donné que les courbes de freinage ont un point de fin imposé et que l’équation de freinage n’a pas de solution analytique, il est impossible de prédire leur point de départ. Les courbes de freinage sont donc calculées à rebours en partant de leur point cible, c’est-à-dire le point dans l’espace où une certaine limite de vitesse est imposée (vitesse cible finie) ou le point d’arrêt (vitesse cible nulle).\nPour des raisons historiques en production horaire, les courbes de freinages sont calculées avec une décélération forfaitaire, dite décélération horaire (typiquement ~0,5m/s²) sans prendre en compte les autres forces. Cette méthode a donc également été implémentée dans OSRD, permettant ainsi de calculer les freinages de deux manières différentes : avec ce taux horaire ou avec une force de freinage qui vient simplement s’ajouter aux autres forces.\nCalcul du profil d’effort maximal Pour chaque point correspondant à une augmentation de vitesse dans le MRSP ou à la fin d’une courbe de freinage d’arrêt, une courbe d’accélération est calculée. Les courbes d’accélération sont calculées en tenant compte de toutes les forces actives (force de traction, résistance à l’avancement, poids) et ont donc un sens physique.\nPour les envelopeParts dont le sens physique n’a pas encore été vérifié (qui à ce stade sont les phases de circulation à vitesse constante, provenant toujours du MRSP), une nouvelle intégration des équations de mouvement est effectuée. Ce dernier calcul est nécessaire pour prendre en compte d’éventuels décrochages de vitesse dans le cas où le train serait physiquement incapable de tenir sa vitesse, typiquement en présence de fortes rampes (voir cet exemple).\nL’enveloppe qui résulte de ces ajouts de courbes d’accélérations et de la vérification des plateaux de vitesse est appelée Max Effort Profile (profil d’effort maximal).\nA ce stade, l’enveloppe obtenue est continue et a un sens physique du début à fin. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum. Le calcul de marche obtenu s’appelle la marche de base. Elle correspond au trajet le plus rapide possible pour le matériel roulant donné sur le parcours donné.\nApplication de marge(s) Après avoir effectué le calcul de la marche de base (correspondant au Max Effort Profile dans OSRD), il est possible d’y appliquer des marges (allowances). Les marges sont des ajouts de temps supplémentaire au parcours du train. Elles servent notamment à lui permettre de rattraper son retard si besoin ou à d’autres besoins opérationnels (plus de détails sur les marges ici).\nUne nouvelle enveloppe Allowances est donc calculée grâce à des overlays pour distribuer la marge demandée par l’utilisateur sur l’enveloppe d’effort maximal calculée précédemment.\nDans le calcul de marche d’OSRD, il est possible de distribuer les marges d’une manière linéaire, en abaissant toutes les vitesses d’un certain facteur, ou économique, c’est-à-dire en minimisant la consommation d’énergie pendant le parcours du train.\n","categories":"","description":"","excerpt":"Le calcul de marche dans OSRD est un processus à 4 étapes, utilisant …","ref":"/fr/docs/explanation/running_time_calculation/pipeline/","tags":"","title":"Le processus de calcul de marche"},{"body":"The walk calculation in OSRD is a 4-step process, each using the envelopes system:\nConstruction of the most restrictive speed profile Addition of the different braking curves Adding the different acceleration curves and checking the constant speed curves Application of allowance(s)  \nCalculation of the Most Restricted Speed Profile (MRSP) A first envelope is calculated at the beginning of the simulation by grouping all static velocity limits:\nmaximum line speed maximum speed of rolling stock temporary speed limits (e.g. in case of works on a line) speed limits by train category speed limits according to train load speed limits corresponding to signposts The length of the train is also taken into account to ensure that the train does not accelerate until its tail leaves the slowest speed zone. An offset is then applied to the red dashed curve. The resulting envelope (black curve) is called the Most Restricted Speed Profile (MRSP). It is on this envelope that the following steps will be calculated.\nThe red dotted line represents the maximum permitted speed depending on the position. The black line represents the MRSP where the train length has been taken into account.\nIt should be noted that the different envelopeParts composing the MRSP are input data, so they do not correspond to curves with a physical reality.\nCalculation of the Max Speed Profile Starting from the MRSP, all braking curves are calculated using the overlay system (see here for more details on overlays), i.e. by creating envelopeParts which will be more restrictive than the MRSP. The resulting curve is called Max Speed Profile. This is the maximum speed envelope of the train, taking into account its braking capabilities.\nSince braking curves have an imposed end point and the braking equation has no analytical solution, it is impossible to predict their starting point. The braking curves are therefore calculated backwards from their target point, i.e. the point in space where a certain speed limit is imposed (finite target speed) or the stopping point (zero target speed).\nFor historical reasons in hourly production, braking curves are calculated at SNCF with a fixed deceleration, the so-called hourly deceleration (typically ~0.5m/s²) without taking into account the other forces. This method has therefore also been implemented in OSRD, allowing the calculation of braking in two different ways: with this hourly rate or with a braking force that is simply added to the other forces.\nCalculation of the Max Effort Profile For each point corresponding to an increase in speed in the MRSP or at the end of a stop braking curve, an acceleration curve is calculated. The acceleration curves are calculated taking into account all active forces (traction force, driving resistance, weight) and therefore have a physical meaning.\nFor envelopeParts whose physical meaning has not yet been verified (which at this stage are the constant speed running phases, always coming from the MRSP), a new integration of the equations of motion is performed. This last calculation is necessary to take into account possible speed stalls in case the train is physically unable to hold its speed, typically in the presence of steep ramps (see this example).\nThe envelope that results from the addition of the acceleration curves and the verification of the speed plates is called the Max Effort Profile.\nAt this stage, the resulting envelope is continuous and has a physical meaning from start to finish. The train accelerates to the maximum, runs as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum. The resulting travel calculation is called the basic running time. It corresponds to the fastest possible route for the given rolling stock on the given route.\nApplication of allowance(s) After the calculation of the basic run (corresponding to the Max Effort Profile in OSRD), it is possible to apply allowances. Allowances are additions of extra time to the train’s journey. They are used to allow the train to catch up if necessary or for other operational purposes (more details on allowances here).\nA new Allowances envelope is therefore calculated using overlays to distribute the allowance requested by the user over the maximum effort envelope calculated previously.\nIn the OSRD running calculation it is possible to distribute the allowances in a linear way, by lowering all speeds by a certain factor, or in an economic way, i.e. by minimising the energy consumption during the train run.\n","categories":"","description":"","excerpt":"The walk calculation in OSRD is a 4-step process, each using the …","ref":"/en/docs/explanation/running_time_calculation/pipeline/","tags":"","title":"Pipeline"},{"body":"Architecture documents are meant to help understand how OSRD works overall.\n","categories":"","description":"Learn more about OSRD architecture","excerpt":"Learn more about OSRD architecture","ref":"/en/docs/reference/architecture/","tags":"","title":"Architecture"},{"body":"Les documents d’architecture permettent de comprendre comment OSRD fonctionne globalement.\n","categories":"","description":"Détails lié à l'architecture de OSRD","excerpt":"Détails lié à l'architecture de OSRD","ref":"/fr/docs/reference/architecture/","tags":"","title":"Architecture"},{"body":"Design documents are meant to help understand and participate in designing software.\nEach design document describes a number of things about a piece of software:\nits goals its constraints how its inputs and outputs were modeled how it works ","categories":"","description":"Learn more about how the software was designed","excerpt":"Learn more about how the software was designed","ref":"/en/docs/reference/design-docs/","tags":"","title":"Design documents"},{"body":"Les documents de conceptions décrivent comment et pourquoi un composant logiciel a été conçu, de l’exposition du problème à la solution technique, en passant par le chemin pris pour y arriver.\n","categories":"","description":"Détails liés à la conceptions de solutions techniques","excerpt":"Détails liés à la conceptions de solutions techniques","ref":"/fr/docs/reference/design-docs/","tags":"","title":"Documents de conception"},{"body":"Design specs General pitch Driver behavior modules are responsible for making driving decisions. Its main responsibility, given the state of the train and an instruction, is to react to the instruction. This reaction is expressed as a new train state.\nTo perform this critical task, it needs access to additional context:\nthe physical properties of the path, which are used to make coasting decisions, and to model natural forces. a slowdown coefficient, which is used to adjust how much the train is slowed down compared to a full power simulation. The driver behavior modules are supposed to have different implementations, which would interpret the slow down coefficient differently.\nAPI One driver behavior module is instantiated per driving instruction. It takes at initialization:\na slowdown coefficient the driving instruction the path properties It has two public methods:\nenact_decision(current_state: TrainState, t: float) -\u003e (TrainState, float)\nWhich returns what the next train state would be if there was only this one instruction to follow, and the time delta to reach this state.\ntruncate_integration_step(current_state: TrainState, potential_state: TrainState, t: float, dt: float) -\u003e (TrainState, float)\nWhich returns a state and time delta which respects the instruction, and is as close as possible to the potential state.\nLoop At a given train state, we know which driving instructions are enforced.\nFor each enforced driving instruction, we query the corresponding driver behavior module.\nThis gives a set of different train states. From this, we coalesce a single train state which respects all instructions.\nTo do so, we:\nFind the states which are most constraining for “constraining properties” (speed and pantograph state). Most constraining state regarding speed is the one with the lowest acceleration (taking sign into account). Most constraining state regarding pantograph state is the one which sets the pantograph down the earliest. Interpolate the constraining states to the smallest dt they are associated with. Merge the constraining states into a single potential state: for speed, we take the lowest acceleration for pantograph state, we take the earliest pantograph state other properties should be identical Submit the potential state for truncation to all driver behavior modules, chaining the outputs of truncate_integration_step. There is a heavy underlying assumption that “constraining properties” can be combined in a new state which is valid. This underlies the step 3. It is not yet clear if this assumption will always be valid in the future.\nAlso: what component should be in charge of instantiating all the driver behavior modules with the right implementation ?\nHere is a schema summarizing the process:\nA short case for why step 4 is needed. Here the constraints are in red, and the next state chosen by the driver behavior modules are in black.\nIn this example, the most constraining state is A, since it’s the one which accelerates the least. However, it overshoots constraint B, thus we need to select the state which respects both constraints.\nDecision process Unifying driver behavior and margin distribution algorithms When this design project started, driver behavior was left completely undefined. We assumed that a set of driving instructions can be unambiguously interpreted given a starting point. This assumption was then decided to be relied on to search which margin speed ceiling yields expected arrival times.\nWe also knew this assumption to be false: there are many ways instructions can be interpreted. Worse yet, different use cases for OSRD have different needs:\nsome users might want to reproduce existing timetables, which exhibit naive driver behavior: aggressive accelerations, aggressive breaking behavior. some users want to evaluate the feasibility of timetables, and thus want somewhat realistic driver behavior, with less aggressive acceleration and cautious breaking behavior. To resolve this tension, we thought of adding support for pluggable driver behavior. Doing so, however, would create two ways a timetable can be loosened (loose time):\nlowering the margin speed ceiling making driver behavior less aggressive Let’s say we want to loosen the timetable by 1 minute on a given section. It could be achieved by:\nlowering the speed ceiling using margins while keeping aggressive driver behavior making driving behavior very conservative, but using no margins at all lowering the speed ceiling a little, and making driving behavior a little more conservative any other combination of the two factors This is an issue, as it might make simulation results unstable: because there possibly are many ways to achieve the requested schedule, it would be very challenging to reliably choose a solution which matches expectations.\n❌ We considered ignoring the issue, as driver behavior was initially out of the scope of this design project. We decided not to, as we expected the cost of making later changes to integrate driver behavior to be significant. ✅ We decided to avoid this shortcoming by making margin distribution part of driver behavior. Driver behavior modules are controlled by a slowdown coefficient between 0 (loose as much time as shall be achieved) and 1 (loose no time). Interfacing driver behavior, driving instructions, and numerical integration Driver behavior can be formally modeled as a local decision function f, which takes the state of the train as an input, including position and speed, and returns an acceleration.\nTo best integrate this acceleration over the given time step, it is best not to use only the acceleration at (t). Since it may vary a lot along [t, t+dt]. To approximate the acceleration within this interval, we would need a better estimator, using a numerical method such as RK4. Such estimator then needs to call f multiple times.\nA number of questions came up:\nshould numerical integration within the driver behavior module, or outside are driver behavior modules queried about their reaction to a specific instruction, or in general does the driver behavior module return decisions, or parameters used to make decisions (such as curves) if decisions are returned, is it a force, an acceleration, or a new state if a new state is returned, how to deal with heterogenous time steps do we check decisions for correctness? that is, if a decision causes the train to overshoot a limit curve, do we do anything? Do we have a single DBM for all driving instructions, or one per driving instruction? We identified that this API choice shouldn’t constrain the implementation. We decided to go the conservative route and have one DBM per driving instructions as it reduces the API surface and relieves DBM from the responsibility of finding the most restrictive instruction.\nHow do we prevent overshooting? We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).\nTo do so we could either:\nHave a way to short-circuit our integration scheme, to snap to target curves without overshooting. Accept oscillations around target curves (and thus overshooting). Setup a feedback loop mechanism to avoid overshooting. We decided that only the first option was desirable.\nThe design choices then are:\n❌ Make the DBM as close as possible to a decision function Then the DBM would not be aware of the time step it is called with, and would return an acceleration. Then the module should expose two methods:\nOne for taking decisions, akin to f.\nCalled several times depending on the integration method.\nOne for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves (for example MARECO which sets it’s own speed limits).\nCalled on the integration step results from this DBM, and the other DBMs integration step results.\n✅ The DBM returns a new state The module would then expose two methods:\nOne for taking decisions, which, given a train state and a desired/maximum time step, returns a new state (which does not overshoot) and a new current time.\nOne for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves (for example MARECO which sets it’s own speed limits).\nCalled only on other DBMs integration step results.\nHow do we combine the decisions from all DBMs? For each state property, find the most constraining value and dt. Find the smallest dt amongst constraining properties. Interpolate remaining properties to this dt, to build a provisional state. Submit this provisional state for truncation to all DBMs and take the truncation with the smallest dt. To understand how this algorithm is designed, we need to consider two example cases:\nFor steps 1 and 2: if a neutral zone and a breaking instruction overlap, both are most constraining to different state properties: the neutral zone affects pantograph state, and the breaking instruction affects speed. The final state has to be a combination of both. For step 3: We need to truncate integration steps to avoid overshoots, and thus avoid the need for feedback loops. Ideally, we want to truncate to the exact overshoot location. This overshoot location is not the same as the initial dt for the overshot constraint. Should truncate_integration_step depend on the driver behavior module? Yes: DBMs may use internal representations that the new state should not overshoot. For instance, when passed a driving instruction with a speed limit of 60km/h, a DBM wishing to lose time may reduce the speed to 50 km/h.\n","categories":"","description":"","excerpt":"Design specs General pitch Driver behavior modules are responsible for …","ref":"/en/docs/reference/design-docs/train-sim-v3/driver-behavior-modules/","tags":"","title":"Driver behavior modules"},{"body":"Une des ambitions d’OSRD est d’aider à la planification horaire à l’échelle européenne.\nPour atteindre cet objectif, OSRD doit tenir compte des spécificités locales en consultant et collaborant avec les compagnies ferroviaires et les gestionnaires d’infrastructure.\nEn échange de leur contribution, ces entreprises :\nProfitent des efforts de développement commun ; Peuvent se baser sur les outils communs pour créer les leurs1 ; Participent à la feuille de route et à la direction technique du projet à la mesure de leur contribution. OSRD est actuellement développé par:\nune équipe de développeurs à plein temps au sein de SNCF Réseau, grâce à un financement de SNCF Réseau, de l’Etat Français et de l’Union Européenne ; des contributeurs individuels. L’association Open Rail La association Open Rail est une association à but non lucratif en cours de création ayant pour objectif d’organiser le travail autour d’outils logiciels communs au monde du ferroviaire.\nTant qu’elles ne modifient pas les outils communs sans partager leurs améliorations, voir les détails de la license LGPLv3. ↩︎\n","categories":"","description":"Organisation et gouvernance d'OSRD","excerpt":"Organisation et gouvernance d'OSRD","ref":"/fr/about/governance/","tags":"","title":"Gouvernance"},{"body":"One of the ambitions of OSRD is to help with timetabling on a European scale.\nTo reach this goal, OSRD has to take local features into account by consulting and collaborating with railway companies and infrastructure operators.\nAnd by contributing to OSRD, these companies:\nProfit from all the common development efforts Can freely build on the common effort to achieve their own goals1 Participate in the roadmap and technical direction of the project to the extent of their contribution OSRD is currently developed by:\nA team of full-time developers at SNCF Réseau, financed by SNCF Réseau, the French state and the European Union Individual contributors The OpenRail association The OpenRail association is an upcoming non-profit committed to organizing cooperative work around railway software tools.\nAs long as they don’t modify the common tools without sharing their improvements. See the details of the LGPLv3 license. ↩︎\n","categories":"","description":"Governance and organization of OSRD","excerpt":"Governance and organization of OSRD","ref":"/en/about/governance/","tags":"","title":"Governance"},{"body":"Netzgrafik-Editor (NGE) is an open-source software that enables the creation, modification, and analysis of regular-interval timetable, at a macroscopic level of detail, developed by Swiss Federal Railways (SBB CFF FFS). See front-end and back-end repositories.\nOSRD (microscopic level of detail, trains scheduled once, based on a defined infrastructure, depicts a timetable) and NGE (macroscopic level of detail, regular-interval based train runs, no infrastructure, depicts a transportation plan) are semantically different, but close enough to make it work together. The compatibility between NGE and OSRD has been tested through a proof of concept, by running both pieces of software as separate services and without automated synchronization.\nThe idea is to give to OSRD a graphical tool to edit (create, update and delete train schedules from) a timetable from an operational study scenario, and get some insights on analytics at the same time. The second benefit of using both microscopic and macroscopic level of detail is that OSRD microscopic calculations can be propagated in NGE to enhance the level of detail of it.\nThe transversal objective of this feature is to make 2 open-source projects from 2 big infrastructure managers work along and cooperate with one another with the same goals.\n1 - Integration in OSRD Therefore, NGE is integrated in the operational studies section of OSRD, in an iframe. An alternative way to deal with the integration would have been to refactor NGE as web-components, thus easy to import in OSRD, but this solution has been abandoned, because of the quantity of refactoring that would have been needed. This iframe points to osrd-nge, a minimalist Angular app that embed the actual NGE app. It can also be seen as a wrapper of the actual NGE app. osrd-nge then customizes the actual NGE app with specific parameters and functionalities:\na standalone flag: to tell NGE to disable all back-end interactions (no database on NGE side) to tell NGE to disable some UI components (authentication, project management, versioning system view, etc.) implementation of a communication interface between OSRD and NGE (message_event, eventListener and postMessage). NGE is then able to get the OSRD timetable as soon as a change is made on OSRD side, and OSRD is able to get the changes made on NGE side.\nThe following diagram shows the workflow between the components.\n--- title: OSRD - NGE Sequence diagram --- sequenceDiagram autonumber OSRD (parent window)--\u003e\u003eOSRD (parent window): init web page OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") loop while synchronization is ON alt any modification in OSRD (parent window) OSRD (parent window)--\u003e\u003eOSRD (parent window): any modification OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") else any modification in NGE (osrd-nge iframe) NGE (osrd-nge iframe)--\u003e\u003eNGE (osrd-nge iframe): any modification \u003cbr\u003e(hooks) NGE (osrd-nge iframe)-\u003e\u003eOSRD (parent window): parent.window.postMessage(nge_action, \"*\") OSRD (parent window)--\u003e\u003eOSRD (parent window): convert NGE action into \u003cbr/\u003etimetable update OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") end end Since OSRD is the only source of truth (= data source), NGE has to be updated as the very last action, to be aligned with the timetable current state, and to get the updated microscopic calculations from OSRD.\nMore precisely, when a change is made in NGE:\n--- title: OSRD - NGE Communication when modification in NGE --- sequenceDiagram autonumber NGE (nge-app)--\u003eNGE (osrd-nge): osrd-nge listens on hooks \u003cbr\u003efrom nge-app NGE (osrd-nge)-\u003e\u003eNGE (osrd-nge): (eventListeners) \u003cbr\u003e callback triggered NGE (osrd-nge)-\u003e\u003eOSRD (front-end): (callback functions) \u003cbr\u003eparent.window.postMessage(nge_action, \"*\") OSRD (front-end)-\u003e\u003eOSRD (front-end): (eventListeners) \u003cbr\u003e convert nge_action \u003cbr\u003e into timetable update OSRD (front-end)-\u003e\u003eOSRD (back-end): call for update timetable OSRD (back-end)-\u003e\u003eOSRD (front-end): update timetable OSRD (front-end)-\u003e\u003e OSRD (front-end): convert timetable into \u003cbr\u003e nge_light_model OSRD (front-end)-\u003e\u003eNGE (osrd-nge): iframe.contentWindow.postMessage(nge_light_model, \"*\") NGE (osrd-nge)-\u003e\u003eNGE (osrd-nge): (eventListener) \u003cbr\u003e onLoad triggered NGE (osrd-nge)-\u003e\u003eNGE (nge-app): (callback function) \u003cbr\u003e onLoad(nge_light_model, ...) 2 - Converters To overpass the semantic differences and make the data models fit, 2 converters have to be implemented:\n[OSRD -\u003e NGE] a converter that transforms an OSRD timetable into an NGE model [OSRD \u003c- NGE] an event handler, that transforms NGE action into OSRD database update on timetable 3 - Open-source (cooperation / contribution) To make NGE compatible with OSRD, some changes have been requested (disable back-end, create hooks on events) and directly implemented in the official repository of NGE, with the agreement and help of NGE team.\nContributions for one project to another, from both sides, are valuable and will be entertained in the future.\nThis feature also shows that open-source cooperation is powerful and a huge gain of time in software development.\n","categories":"","description":"Open-source software developed by SBB CFF FFS and its integration in OSRD","excerpt":"Open-source software developed by SBB CFF FFS and its integration in …","ref":"/en/docs/explanation/netzgrafik-editor/","tags":"","title":"Netzgrafik-Editor"},{"body":"Netzgrafik-Editor (NGE) est un logiciel open-source qui permet la création, la modification et l’analyse d’horaires à intervalles réguliers, à un niveau de détail macroscopique, développé par les Chemins de Fer Fédéraux suisses (SBB CFF FFS). Voir les dépôts front-end et back-end\nOSRD (niveau de détail microscopique, trains à occurence unique, basé sur une infrastructure définie, représente une grille horaire) et NGE (niveau de détail macroscopique, courses de trains à intervalles réguliers, sans infrastructure, représente un plan de transport) sont sémantiquement différents, mais suffisamment proches pour fonctionner ensemble. La compatibilité entre NGE et OSRD a été testée à travers une preuve de concept, en exécutant les deux applications comme services distincts sans synchronisation automatisée.\nL’idée est de fournir à OSRD un outil graphique pour éditer (créer, mettre à jour et supprimer les horaires des trains) un horaire à partir d’un scénario d’étude opérationnelle, et obtenir en même temps des informations analytiques. Le deuxième avantage de l’utilisation des niveaux de détail microscopique et macroscopique est que les calculs microscopiques d’OSRD peuvent être propagés dans NGE pour améliorer son niveau de détail.\nL’objectif transversal de cette fonctionnalité est de faire collaborer deux projets open-source de deux grands gestionnaires d’infrastructure pour atteindre des objectifs communs.\n1 - Intégration dans OSRD Ainsi, NGE est intégré dans la section des études opérationnelles d’OSRD, dans un iframe. Une alternative pour répondre au problème d’intégration aurait été de refacto NGE en web-components, pour les importer facilement dans OSRD, mais cette solution a été abandonnée compte tenu de la quantité de refacto que cela représenterait. Cet iframe pointe vers osrd-nge, une application Angular minimaliste qui intègre l’application NGE réelle. Il peut également être vu comme un conteneur de l’application NGE réelle. osrd-nge personnalise ensuite l’application NGE réelle avec des paramètres et des fonctionnalités spécifiques :\nun drapeau standalone : pour indiquer à NGE de désactiver toutes les interactions back-end (pas de base de données côté NGE) pour indiquer à NGE de désactiver certains composants de l’interface utilisateur (authentification, gestion de projet, vue du système de versionnage, etc…) implémentation d’une interface de communication entre OSRD et NGE (message_event, eventListener and postMessage). NGE est alors capable d’obtenir la grille horaire OSRD dès qu’un changement est effectué du côté d’OSRD, et OSRD est capable d’obtenir les modifications effectuées du côté de NGE.\nLes diagrammes suivants montrent workflow entre les composants.\n--- title: OSRD - NGE Sequence diagram --- sequenceDiagram autonumber OSRD (parent window)--\u003e\u003eOSRD (parent window): initialisation de la page web OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") loop while synchronization is ON alt any modification in OSRD (parent window) OSRD (parent window)--\u003e\u003eOSRD (parent window): modification OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") else any modification in NGE (osrd-nge iframe) NGE (osrd-nge iframe)--\u003e\u003eNGE (osrd-nge iframe): modification \u003cbr\u003e(hooks) NGE (osrd-nge iframe)-\u003e\u003eOSRD (parent window): parent.window.postMessage(nge_action, \"*\") OSRD (parent window)--\u003e\u003eOSRD (parent window): convertion d'une action NGE en \u003cbr/\u003emodification de la grille horaire OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") end end Étant donné qu’OSRD est la seule source de vérité (= source de données), NGE doit être mis à jour en dernière action, pour être aligné avec l’état actuel de la grille horaire et obtenir les calculs microscopiques mis à jour d’OSRD.\nPlus précisément, lorsqu’un changement est effectué dans NGE :\n--- title: OSRD - NGE Communication when modification in NGE --- sequenceDiagram autonumber NGE (nge-app)--\u003eNGE (osrd-nge): osrd-nge écoute sur les hooks \u003cbr\u003ede nge-app NGE (osrd-nge)-\u003e\u003eNGE (osrd-nge): (eventListeners) \u003cbr\u003e callback déclenché NGE (osrd-nge)-\u003e\u003eOSRD (front-end): (callback functions) \u003cbr\u003eparent.window.postMessage(nge_action, \"*\") OSRD (front-end)-\u003e\u003eOSRD (front-end): (eventListeners) \u003cbr\u003e converti nge_action \u003cbr\u003e en modification de la grille horaire OSRD (front-end)-\u003e\u003eOSRD (back-end): appel pour modifier la grille horaire OSRD (back-end)-\u003e\u003eOSRD (front-end): modifie la grille horaire OSRD (front-end)-\u003e\u003e OSRD (front-end): converti la grille horaire en\u003cbr\u003e nge_light_model OSRD (front-end)-\u003e\u003eNGE (osrd-nge): iframe.contentWindow.postMessage(nge_light_model, \"*\") NGE (osrd-nge)-\u003e\u003eNGE (osrd-nge): (eventListener) \u003cbr\u003e onLoad déclenché NGE (osrd-nge)-\u003e\u003eNGE (nge-app): (callback function) \u003cbr\u003e onLoad(nge_light_model, ...) 2 - Convertisseurs Pour surpasser les différences sémantiques et adapter les modèles de données, deux convertisseurs doivent être implémentés :\n[OSRD -\u003e NGE] un convertisseur qui transforme une grille horaire OSRD en un modèle NGE [OSRD \u003c- NGE] un gestionnaire d’événements, qui transforme une action NGE en mise à jour de la base de données OSRD sur la grille horaire 3 - Open-source (coopération / contribution) Pour rendre NGE compatible avec OSRD, certaines modifications ont été demandées (désactivation du back-end, création de hooks sur les événements) et directement implémentées dans le répertoire officiel de NGE, avec l’accord et l’aide de l’équipe NGE.\nLes contributions d’un projet à l’autre, de part et d’autre, sont précieuses et seront encouragées à l’avenir.\nCette fonctionnalité montre également que la coopération open-source est puissante et constitue un gain de temps considérable dans le développement de logiciels.\n","categories":"","description":"Logiciel open-source développé par SBB CFF FFS et son intégration dans OSRD","excerpt":"Logiciel open-source développé par SBB CFF FFS et son intégration dans …","ref":"/fr/docs/explanation/netzgrafik-editor/","tags":"","title":"Netzgrafik-Editor"},{"body":"Le modèle de simulation définit le rôle et comportement des différents objets simulés au sein d’OSRD.\nCette modélisation est un compromis entre de multiples enjeux:\nfidélité de la simulation interprétabilité des résultats adaptabilité du modèle à différentes technologies et usages, que cela soit en terme de signalisation, de poste d’aiguillage, ou d’usage des données En particulier, certaines subtilités propres aux systèmes pratiques ont été sacrifiées sur l’autel de la compatibilité et de l’interprétabilité:\nun signal doit forcément s’addresser à un train en particulier: les signaux n’ont pas d’aspect par défaut; ils n’existent que pour être vus les itinéraires / routes sont formées à destination d’un train en particulier Ce document est une description du modèle de fonctionnement cible d’OSRD. Il a pour objectif de renseigner développeurs et experts métiers sur le fonctionnement du simulateur. Des changements y sont apportés au fil de l’évolution du projet.\nCe modèle est en cours d’implémentation\nArchitecture flowchart TD %%%% NODES train[Train] %% ↓ signaling[Signalisation] %% ↓ routing[Routage] ordering[Ordonnancement] %% ↓ reservation[Réservation] %% ↓ location[Localisation] movable-elements[\"Éléments mobiles\"] %%%% EDGES train -- réagit à --\u003e signaling train -- réclame les itinéraires --\u003e ordering ordering -- commande --\u003e routing signaling -- observe --\u003e reservation routing -- observe et réserve --\u003e reservation reservation -- observe --\u003e location reservation -- actionne --\u003e movable-elements train -- informe --\u003e location %%%% CLICKABLE LINKS click train href \"./train/\" _self click ordering href \"./ordering/\" _self click signaling href \"./signaling/\" _self click routing href \"./routing/\" _self click reservation href \"./reservation/\" _self click location href \"./location/\" _self click movable-elements href \"./movable-elements/\" _self Pistes d'évolution Gestion des overlaps Remerciements Par ordre alphabétique:\nChristophe Mémin Djamal Bellebia Gilles Dessagne Nathanaël Dias ","categories":"","description":"Décrit le fonctionnement du poste d'aiguillage virtuel","excerpt":"Décrit le fonctionnement du poste d'aiguillage virtuel","ref":"/fr/docs/reference/design-docs/interlocking/","tags":"","title":"Poste d'aiguillage"},{"body":"Les guides de référence technique contiennent des références techniques pour les API et autres aspects de la machinerie OSRD. Ils présentent son fonctionnement et la manière de l’exploiter en partant du principe que les concepts clés de base sont maîtrisés.\n","categories":"","description":"Machinerie interne et APIs","excerpt":"Machinerie interne et APIs","ref":"/fr/docs/reference/","tags":"","title":"Référence technique"},{"body":"Description Les routes ont pour responsabilité d’autoriser le déplacement des trains dans l’infrastructure. Elles doivent se terminer à un point où l’arrêt du train est prévu (en terme de signalisation, pas voyageur). Les routes sont assimilables à des itinéraires, ou à des suites d’itinéraires et d’installations de pleine voie. Les routes n’ont pas de lien direct avec le cantonnement et la signalisation. Elles nourrissent des informations sur la disponibilité des voies qui sont utilisées par le cantonnement et la signalisation. Une route est un chemin de détecteur en détecteur. Elle représente une portion de chemin qu’il est sûr pour un train d’emprunter. Les routes ont des points de libération, qui sont des détecteurs qui délimitent quand détruire l’itinéraire, ce qui permet d’implémenter transit souple, rigide, et entre-deux. Une route peut être à nouveau formée alors qu’un train est déjà en train de la parcourir. Cela permet à plusieurs trains de se suivre sur la même route. Cycle de vie d’une route Les routes n’ont pas d’état, mais leur commande donne lieu à une suite d’événements systématique :\nle système commande toutes les routes sur le trajet du train dans l’ordre, sans attendre la commande doit être acceptée par le régulateur lorsque le régulateur accepte la commande, la formation commence le droit d’action de chaque zone de la route est acquis, selon un ordre global en parallèle pour toutes les zones: si la zone n’est pas dans la configuration souhaitée: si elle est déjà réservée, attendre que les réservations expirent sinon, la mettre dans la configuration souhaitée en déplaçant les aiguilles pré-réserver la zone pour le passage du train le droit d’action de la zone est cédé une fois que la formation est terminée, la route est établie pour chaque zone, transformer la pré-réservation du train en réservation dès que la route est établie, un processus de destruction de la route commence pour chaque zone de la route donnant lieu à une libération attendre que le train quitte la zone (que la réservation passe de l’état OCCUPIED à l’état PENDING_RELEASE) libérer la réservation des zones du début de la route jusqu’à la zone actuelle Piste d'évolution Certains postes d’aiguillages ont un enclenchement entre itinéraires de sens contraire (affrontement) qui empêche l’activation d’une route en menant à une zone avec un transit en sens contraire. Il serait envisageable de réserver une zone supplémentaire à la fin du chemin protégé par la route, par sécurité. Piste d'évolution Certains itinéraires en gare ne permettent pas le partage du chemin par plusieurs trains Piste d'évolution En pratique, il pourrait être intéressant d’introduire une notion de route partielle afin de réduire le nombre de routes nécessaires: une route partielle est une portion de route qu’il n’est pas sûr d’activer indépendament. Exigences de conception Le système doit, indirectement ou directement:\npermettre à la signalisation de déterminer si une section de voie est prête à être empruntée. permettre l’ordonnancement des trains selon des critères configurables. permettre la destruction progressive (transit souple) de l’itinéraire après le passage du train. il doit être possible d’avoir plusieurs processus de commande actifs au même moment pour la même route, afin de supporter des trains qui se suivent Dépendances statique le chemin des routes de détecteur à détecteur\nstatique la position requise des aiguilles, par zone\nstatique les points de libération des zones (qui implémentent le transit souple / rigide)\ndynamique régulateur soumettre des commandes\ndynamique réservation acquérir et relacher un droit d’action par zone\ndynamique réservation attendre que les réservations d’une zone expirent\ndynamique éléments mobiles déplacer des aiguilles\ndynamique réservation pré-réserver une zone\ndynamique réservation promouvoir une pré-réservation en réservation\ndynamique réservation lors de la destruction de la route, attendre qu’une réservation passe en PENDING_RELEASE\ndynamique réservation libérer une réservation\nOpérations commander une route: démarre un processus asynchrone qui ne se terminera que lorsque la route aura été établie. Un processus de destruction doit démarrer dès que la route est établie. Notes de conception Ces notes permettent d’expliquer les décisions qui ont été prises, afin de pouvoir plus aisément les comprendre et évoluer.\nInformer la signalisation Sachant que:\nil peut y avoir beaucoup de zones partant d’un même point, il est préférable d’éviter de contraindre les signaux à observer une liste de routes il est potentiellement difficile d’associer un état clair à chaque route Il en ressort plusieurs manières d’informer la signalisation de la navigabilité des voies:\nsoit directement, en faisant observer à la signalisation les points d’entrée des routes. Si plusieurs routes partent du même endroit, elles partageraient un objet entrée: moins de complexité dans la couche de réservation, plus de complexité dans la couche de routage soit indirectement, via la couche de réservation des zones, qui auraient un état supplémentaire pour marquer leur navigabilité: moins de complexité dans la couche de routage, plus de complexité dans la couche de réservation avantage le processus d’activation des routes n’aurait pas besoin d’attendre l’arrivée du train, la couche de réservation s’en occuperait. avantage découplage entre routage et cantonnement / signalisation. La seconde option a été choisie, car :\nelle permet d’avoir un couplage moins fort entre la signalisation et les routes. elle évite aussi au processus d’activation des routes d’attendre le passage du train alors que la couche de réservation le fait déjà. Cycle de vie des routes et état des zones Plusieurs enjeux motivent le cycle de vie des routes et l’état des zones :\nd’une part, l’état des zones est au coeur de la détection de conflit : il doit être possible d’extraire d’une simulation d’un train seul ses besoins en ressources d’autre part, il faut qu’une simulation multi-train fonctionne correctement : le temps de déplacement des aiguilles selon la configuration actuellement en place, en particulier, est un point de friction important ","categories":"","description":"Gère le cycle des routes","excerpt":"Gère le cycle des routes","ref":"/fr/docs/reference/design-docs/interlocking/routing/","tags":"","title":"Routage"},{"body":"Technical reference guides contain technical reference for APIs and other aspects of OSRD’s machinery. They describe how it works and how to use it but assume that you have a basic understanding of key concepts.\n","categories":"","description":"Internal machinery and APIs","excerpt":"Internal machinery and APIs","ref":"/en/docs/reference/","tags":"","title":"Technical reference"},{"body":"\n","categories":"","description":"OSRD's data-flow diagram","excerpt":"OSRD's data-flow diagram","ref":"/en/docs/reference/architecture/data_flow/","tags":"","title":"Data-flow"},{"body":"\n","categories":"","description":"Schéma des flux des données d'osrd","excerpt":"Schéma des flux des données d'osrd","ref":"/fr/docs/reference/architecture/data_flow/","tags":"","title":"Flux des données"},{"body":"It is a multi-service architecture where several software components interact with each other. This choice was made to ensure the modularity of the code and to guarantee the exploitability of certain OSRD services by external applications.\nValkey is configured as maxmemory-policy=allkeys-lru (documentation) Osrdyne has multiple drivers to support: k8s docker process compose The gateway supports multiple authentication providers: OpenID Connect (OIDC) Bearer token Mock (for development purpose) Some editoast endpoints requires an InfraCache object which make them stateful. These endpoints are only used in the editoast-stateful service. Doing so most endpoints are run by a scalable service. Coming soon:\nAdapt editoast-stateful so editoast is fully scalable. ","categories":"","description":"OSRD's services architecture","excerpt":"OSRD's services architecture","ref":"/en/docs/reference/architecture/services/","tags":"","title":"Services"},{"body":"Description The signaling layer includes all signals, which respond to track occupancy and reservation. Signals can be of different types, and are modularly loaded. Only their behavior towards the state of the infrastructure and the train’s reaction to signaling matters.\nSignals are connected to each other by blocks. Blocks define paths permitted by signaling.\nGoals The signaling system is at the crossroads of many needs:\nit must allow for realistic signaling simulation in a multi-train simulation it must allow the conflict detection system to determine which resources are required for the train it must allow application users to edit and display signals it must allow for visualization of signals on a map it must allow for automated import from existing databases Design requirements: All static data:\nmust enable the front-end to display the signals must enable the infrastructure editor to configure signals must enable the back-end to simulate signals must be close to realistic industry models must allow for the modeling of composite signals, which carry several logical signals within a single physical signal To simulate signaling:\nblocks must be generated for both user convenience and pathfinding for each signal, its next compatible signal and protected zones must be deduced the minimum necessary information must be provided to the signaling modules for their operation enable using signaling modules without instantiating a complete simulation allow for signals to be loaded in any order, in parallel For speed limits:\nsome speed limits have to be enforced depending on the train path’s routes speed limits can be configured to have an impact on signaling ability to link the reaction of the train to a signal, and a speed limit Assumptions Each physical signal can be decomposed into a list of logical signals, all of which are associated with a signaling system. Blocks have a type. It is possible to compute, given a signal alone, its block and route delimiting properties. Blocks never cross route boundaries. Blocks which are not covered by routes do not exist, or can be ignored. At any time, trains only use one signaling system capable of transmitting movement authority. Speed limits change depending on which route is in use, and affect how signals behave Some speed limits have an impact on signaling, and some do not Either a speed limits differentiates per train category, or requires dynamic signaling, but not both Operations Instantiating a view creates a framework for observing signals Planning the path signals to the view the blocks that the train will traverse Observing a signal subscribe to the state of a signal (through the view) Passing a signal signals that a signal has been passed by the train (through the view) Research Questions Are there any blocks that overlap the end of a route? SNCF(Loïc): No. Are there any signals which rely on the state of the one after next signal? SNCF(Loïc): No. Are there signals that change behavior based on the active block in front of them? SNCF(Loïc): Yes, for slowdowns. Are there signals that are the start of blocks of different types? SNCF(Loïc): Yes. Can the behavior of a signal depend on which block is active after the end of the current block? SNCF(Loïc): Yes, with slowdowns or blinking yellow. Do some signaling systems need additional information in the blocks? SNCF(Loïc): Kind of, there are slowdowns, but it’s not specifically carried by the block. Is it nominal for a train to have multiple active signaling systems at the same time? SNCF(Loïc): No. are there any signals which depend on which route is set, but are not route delimiters? SNCF(Loïc): Yes, see Sémaphore Clignotant how do speed limits per train category and dynamic signaling interact? SNCF(Nicolas): There shouldn’t be any speed limit per category signaled by dynamic signaling are there any signals which depend on the state of multiple routes? SNCF(Loïc): No ","categories":"","description":"Describes the signaling model","excerpt":"Describes the signaling model","ref":"/en/docs/reference/design-docs/signaling/","tags":"","title":"Signaling"},{"body":" This document is a work in progress\nConflict detection is the process of looking for timetable conflicts. A timetable conflict is any predictable condition which disrupts planned operations. Planned operations can be disrupted if a train is slowed down, prevented from proceeding, or delayed.\nOne of the core features of OSRD is the ability to automatically detect some conflicts:\nspacing conflicts: insufficient spacing between trains sharing the same path routing conflicts: insufficient spacing between trains with intersecting paths Some other kinds of conflicts may be detected later on:\nmaintenance conflicts: planned maintenance disrupts the path of a train power delivery conflicts: combined power delivery requirements exceeds capacity Conflict detection relies on interlocking and signaling modeling and simulation to:\nfigure out what each actor requires to perform its duty undisturbed detect conflicting requirements Design constraints The primary design goals are as follows:\nenable threading new train paths into an existing timetable (see STDCM) produce conflicts which can be linked back to a root cause operate in way that can be visualized and interpreted scale to real world timetables: millions of yearly trains, tens of thousands of daily trains In addition to these goals, the following constraints apply:\nit must be possible to thread new train paths into timetables with existing conflicts it must not cause false-negatives: if no conflicts are detected, a multi-train simulation of the same timetable must not yield any slowdowns it cannot rely on data we do not have it has to enable later support of mobile block systems it has to rely on existing signaling and interlocking simulation it has to enable detecting conflicts regardless of the signaling system in use it has to support transitions between signaling systems it has to support conflicts between different signaling systems Conflict modeling Actors are objects which cause resources to be used:\ntrain paths (or someone / something on the behalf of the train) maintenance work Actors need resources to be available to proceed, such as:\nzones, which have one state per way to traverse it switches, which have one state per position station platforms, which could be used to prevent two large trains from occupying both sides of a tiny platform Actor emit resource requirements, which:\ndescribe the need of an actor for a resource, for a given time span describe what the resource is needed for detail how the resource is used, such as switch position, zone entry and exit Resource requirements can turn out to be either satisfied or conflicting with other requirements, depending on compatibility rules.\nCompatibility rules differ by requirement purpose and resource type. For example:\nspacing requirements are exclusive: simultaneous requirements for the same resource are conflicting zone and switch requirements are shareable: simultaneous requirements are satisfied if the resource configuration is identical For conflict detection to work, resource requirements have to be at least as extensive as what’s required to guarantee that a train path will not be disturbed.\nRouting conflicts Context For trains to proceed safely along their planned path:\nswitches have to be moved in the appropriate position level crossings have to activate risks of collision with other trains have to be mitigated In practice, the path of trains is partitioned into routes, which when set, ensure a train can safely follow the route.\nRoutes have the following lifestyle:\nAs a train approaches the start of one of its routes, it is called by an operator. If all resources required to safely use the route are available, switches and level crossings start to move. If a resources is not available, e.g. because another train has reserved a section of track, this process is delayed until all conditions are met. Once all resources are configured and reserved, the route is set and ready to be followed. Before that point, the entry of the route was protected by signaling, which prevented the train from moving past the entry point. As the train moves along the route, it is destroyed. When the tail of the trail releases key detectors along the route, resources before this detector are released, and can this be reserved by other routes. For a train to proceed through a route unimpeded, the following things have to happen:\nThe route has to be set before the train arrives, and before it is slowed down by signaling. The route has to be called, so that is it set in time. All resources required for the route to start setting at call time have to be available. Generating requirements struct RouteRequirement { route: RouteId, set_deadline: Time, zone_requirements: Vec\u003cRouteZoneRequirement\u003e, } struct RouteZoneRequirement { zone: ZoneId, entry_det: DirDetectorId, exit_det: DirDetectorId, release_time: Time, switches: Map\u003cSwitchId, SwitchConfigId\u003e, } Routing requirements are generated by the following algorithm:\nCompute the set deadline using signaling simulation. The set deadline is the point in time at which the train would be slowed down if the route were not set. For each zone in each route, simulate when it would be released, and thus not required anymore. Route overlaps are not yet supported.\nRequirement compatibility rules Requirement compatibility is evaluated for all RouteZoneRequirements, grouped by zone. Requirements A and B, ordered such that A.set_deadline \u003c= B.set_deadline, are compatible if and only if either:\ntheir active time span does not overlap, such that A.release_time \u003c= (B.set_deadline - activation_time), where the activation time is the delay required to reconfigure from A.switches to B.switches. (A.entry_det, A.exit_det, A.switches) == (B.entry_det, B.exit_det, B.switches) Spacing conflicts Context Even if interlocking mitigates some of the risks associated with operating trains, a major one is left out: head to tail collisions, caused by insufficient spacing.\nThis responsibility is handled by signaling, which conveys both interlocking and spacing constraints.\nSignaling helps trains slow down until the end of their movement authority, which is either:\nbehind the tail of the next train at the end of the last route set for this train Spacing requirements are emitted for zones which if occupied, would cause a slowdown, and zones occupied by the train\nGenerating requirements struct SpacingRequirement { zone: ZoneId, begin_time: Time, end_time: Time, } Every time the driver sees a signal, generate updated spacing requirements by calculating which zones, if occupied, would trigger a slowdown:\nstart by assuming the zone just after the head of the train is occupied until the train is not slowed down, move the occupied section one zone further away from the train Requirement compatibility rules Requirement compatibility is evaluated for all SpacingRequirements, grouped by zone.\nRequirements A and B are compatible if and only if their [begin_time, end_time] ranges do not overlap.\nIncremental requirement generation Routing requirements sequenceDiagram participant client as Client participant gen as Routing resource generator client -\u003e\u003e gen: initial path + train movement loop gen -\u003e\u003e client: prefix path extension needed client -\u003e\u003e gen: extra prefix path + train movement end gen -\u003e\u003e client: resource requirements After an initial path is given, the requirement generator can ask for more prefix path (before the start of the route). The client responds with:\nthe extra prefix path the movement of the train over time on the given prefix path If the initial path has multiple routes, the last route is the one resource requirements are emitted for.\nSpacing requirements sequenceDiagram participant client as Client participant gen as Spacing resource generator client -\u003e\u003e gen: initial path + train movement loop gen -\u003e\u003e client: postfix path extension needed client -\u003e\u003e gen: extra postfix path end gen -\u003e\u003e client: resource requirements After an initial path is given, the requirement generator can ask for more postfix path (before the start of the route).\nVisualizing requirements Full-page requirements diagram\n","categories":"","description":"Detect unrealistic timetables","excerpt":"Detect unrealistic timetables","ref":"/en/docs/reference/design-docs/conflict-detection/","tags":"","title":"Conflict detection"},{"body":" This work is pending implementation, and has not yet been adjusted to reflect potential required adjustments.\nThese articles describe the design of the new train simulation system.\nThis system should be simpler and more stable than the current one, and should enable more advanced features in the future.\n","categories":"","description":"Modeling and API design of train simulations","excerpt":"Modeling and API design of train simulations","ref":"/en/docs/reference/design-docs/train-sim-v3/","tags":"","title":"Train simulation v3"},{"body":" The purpose of allowances As explained in the calcul du Max Effort Profile, the basic running time represents the most stretched run normally achievable, i.e. the fastest possible run of the given equipment on the given route. The train accelerates to the maximum, travels as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum.\nThis basic run has a major disadvantage: if a train leaves 10 minutes late, it will arrive at best 10 minutes late, because by definition it is impossible for it to run faster than the basic run. Therefore, trains are scheduled with one or more allowances added. The allowances are a relaxation of the train’s route, an addition of time to the scheduled timetable, which inevitably results in a lowering of running speeds.\nA train running in basic gear is unable to catch up!\nAllowances types There are two types of allowances:\nThe regularity allowance: this is the additional time added to the basic running time to take account of the inaccuracy of speed measurement, to compensate for the consequences of external incidents that disrupt the theoretical run of trains, and to maintain the regularity of the traffic. The regularity allowance applies to the whole route, although its value may change at certain intervals. The construction allowance: this is the time added/removed on a specific interval, in addition to the regularity allowance, but this time for operational reasons (dodging another train, clearing a track more quickly, etc.) A basic running time with an added allowance of regularity gives what is known as a standard walk.\nAllowance distribution Since the addition of allowance results in lower speeds along the route, there are a number of possible routes. Indeed, there are an infinite number of solutions that result in the same journey time.\nAs a simple example, in order to reduce the running time of a train by 10% of its journey time, it is possible to extend any stop by the time equivalent to this 10%, just as it is possible to run at 1/1.1 = 90.9% of the train’s capacity over the entire route, or to run slower, but only at high speeds…\nThere are currently two algorithms for margin distribution in OSRD: linear and economic.\nLinear distribution Linear allowance distribution is simply lowering the speeds by the same factor over the area where the user applies the allowance. Here is an example of its application:\nThe advantage of this distribution is that the allowance is spread evenly over the entire journey. A train that is late on 30% of its journey will have 70% of its allowance for the remaining 70% of its journey.\nEconomic distribution The economic distribution of the allowance, presented in detail in this document (MARECO is an algorithm designed by the SNCF research department), consists of distributing the allowance in the most energy-efficient way possible. It is based on two principles:\na maximum speed, avoiding the most energy-intensive speeds run-on zones, located before braking and steep gradients, where the train runs with the engine off thanks to its inertia, allowing it to consume no energy during this period An example of economic walking. Above, the gradients/ramps encountered by the train. The areas of travel on the track are shown in blue.\n","categories":"","description":"","excerpt":" The purpose of allowances As explained in the calcul du Max Effort …","ref":"/en/docs/explanation/running_time_calculation/allowances/","tags":"","title":"Allowances"},{"body":" La raison d’être des marges Comme expliqué dans le calcul du Max Effort Profile, la marche de base représente la marche la plus tendue normalement réalisable, c’est-à-dire le trajet le plus rapide possible du matériel donné sur le parcours donné. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum.\nCette marche de base présente un inconvénient majeur : si un train part avec 10min de retard, il arrivera au mieux avec 10min de retard, car par définition il lui est impossible de rouler plus vite que la marche de base. Par conséquent, les trains sont programmés avec un ajout d’une ou de plusieurs marges. Les marges sont une détente du trajet du train, un ajout de temps à l’horaire prévu, qui se traduit inévitablement par un abaissement des vitesses de circulation.\nUn train circulant en marche de base est incapable de rattraper son retard !\nLe type de marge On distingue deux types de marges :\nLa marge de régularité : il s’agit du temps complémentaire ajouté à la marche de base pour tenir compte de l’imprécision de la mesure de la vitesse, pour pallier les conséquences des incidents extérieurs venant perturber la marche théorique des trains, et pour maintenir la régularité de la circulation. La marge de régularité s’applique sur l’ensemble du trajet, bien que sa valeur puisse changer sur certains intervalles. La marge de construction : il s’agit du temps ajouté / retiré sur un intervalle spécifique, en plus de la marge de régularité, mais cette fois pour des raisons opérationnelles (esquiver un autre train, libérer une voie plus rapidement, etc.) Une marche de base à laquelle on vient ajouter une marge de régularité donne ce que l’on appelle une marche type.\nLa distribution de la marge L’ajout de marge se traduisant par un abaissement des vitesses le long du trajet, plusieurs marches types sont possibles. En effet, il existe une infinité de solutions aboutissant au même temps de parcours.\nEn guise d’exemple simple, pour détendre la marche d’un train de 10% de son temps de parcours, il est possible de prolonger n’importe quel arrêt de l’équivalent en temps de ces 10%, tout comme il est possible de rouler à 1/1,1 = 90,9% des capacités du train sur l’ensemble du parcours, ou encore de rouler moins vite, mais seulement aux vitesses élevées…\nIl y a pour l’instant deux algorithmes de distribution de la marge dans OSRD : linéaire et économique.\nLa distribution linéaire La distribution de marge linéaire consiste simplement à abaisser les vitesses d’un même facteur sur la zone où l’utilisateur applique la marge. En voici un exemple d’application :\nCette distribution a pour avantage de répartir la marge de la même manière sur tout le trajet. Un train prenant du retard à 30% de son trajet disposera de 70% de sa marge pour les 70% de trajets restants.\nLa distribution économique La distribution économique de la marge, présentée en détail dans ce document (MARECO est un algorithme conçu par la direction de la recherche SNCF), consiste à répartir la marge de la manière la plus économe possible en énergie. Elle est basée sur deux principes :\nune vitesse plafond, évitant les vitesses les plus consommatrices en énergie des zones de marche sur l’erre, situées avant les freinages et les fortes pentes, où le train circule à moteur coupé grâce à son inertie, permettant de ne consommer aucune énergie pendant ce laps de temps Un exemple de marche économique. En haut, les pentes/rampes rencontrées par le train. Les zones de marche sur l’erre sont représentées en bleu.\n","categories":"","description":"","excerpt":" La raison d’être des marges Comme expliqué dans le calcul du Max …","ref":"/fr/docs/explanation/running_time_calculation/allowances/","tags":"","title":"Les marges"},{"body":"Une des fonctionnalités qui doit être supportée par STDCM est la marge de régularité. L’utilisateur doit pouvoir indiquer une valeur de marge, exprimée en fonction de la distance ou du temps de parcours, et cette marge doit être ajoutée au trajet.\nPar exemple : l’utilisateur peut indiquer une marge de 5 minutes au 100km. Sur un trajet de 42km, un trajet de 10 minutes au plus rapide doit maintenant durer 12 minutes et 6 secondes.\nLe problème se situe au niveau de la détection de conflits. En effet, ralentir le train décale l’ensemble du sillon dans le temps et augmente la capacité consommée. La marge doit donc être prise en compte pendant l’exploration pour détecter correctement les conflits.\nPour plus de difficulté, la marge doit suivre le modèle MARECO. La marge n’est pas répartie uniformément sur le trajet, mais selon un calcul qui nécessite de connaître l’ensemble du trajet.\nPendant l’exploration La principale implication de la marge de régularité est pendant l’exploration du graphe, quand on identifie les conflits. Les temps et les vitesses doivent être baissés linéairement pour prendre en compte les conflits au bon moment. La simulation au plus rapide doit tout de même être calculée car elle peut définir le temp supplémentaire.\nCe procédé n’est pas exact car il ignore la manière dont la marge est appliquée (en particulier pour MARECO). Mais à cette étape les temps exacts ne sont pas nécessaires, il est seulement nécessaire de savoir si une solution existe à ce temps approximatif.\nCe procédé inexact peut sembler être un problème, mais en pratique (pour la SNCF) les marges de régularités ont en fait une tolérance entre deux points arbitraires du chemin. Par exemple pour une marge indiquée à 5 minutes par 100km, une solution avec la marge entre 3 et 7 minutes entre deux PR serait acceptable. Cette tolérance ne sera pas encodée explicitement, mais elle permet de faire des approximations de quelques secondes pendant la recherche. Post-processing Une fois que le chemin est trouvé, il est nécessaire de faire une simulation finale pour appliquer correctement les marges. Le procédé est le suivant :\nPour certains points du chemin, le temps est fixé. C’est un paramètre d’entrée de la simulation qui appelle le module de marge. À l’initialisation, le temps est fixé à chaque point d’arrêt. Une simulation est réalisée. En cas de conflit, on s’intéresse au premier Un point est fixé à la position de ce conflit. Le temps de référence est celui considéré pendant l’exploration. Ce procédé est répété itérativement jusqu’à une absence de conflit ","categories":"","description":"","excerpt":"Une des fonctionnalités qui doit être supportée par STDCM est la marge …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/","tags":"","title":"Marge de régularité"},{"body":"The STDCM module must be usable with standard allowances. The user can set an allowance value, expressed either as a function of the running time or the travelled distance. This time must be added to the running time, so that it arrives later compared to its fastest possible running time.\nFor example: the user can set a margin of 5 minutes per 100km. On a 42km long path that would take 10 minutes at best, the train should arrive 12 minutes and 6 seconds after leaving.\nThis can cause problems to detect conflicts, as an allowance would move the end of the train slot to a later time. The allowance must be considered when we compute conflicts as the graph is explored.\nThe allowance must also follow the MARECO model: the extra time isn’t added evenly over the whole path, it is computed in a way that requires knowing the whole path. This is done to optimize the energy used by the train.\nDuring the exploration The main implication of the standard allowance is during the graph exploration, when we identify conflicts. It means that we need to scale down the speeds. We still need to compute the maximum speed simulations (as they define the extra time), but when identifying at which time we see a given signal, all speeds and times are scaled.\nThis process is not exact. It doesn’t properly account for the way the allowance is applied (especially for MARECO). But at this point we don’t need exact times, we just need to identify whether a solution would exist at this approximate time.\nThis slightly inexact process may seem like a problem, but in reality (for SNCF) standard allowances actually have some tolerance between arbitrary points on the path. e.g. if we should aim for 5 minutes per 100km, any value between 3 and 7 would be valid. The actual tolerance is not something we can or want to encode as they’re too many specificities, but it means we can be off by a few seconds. Post-processing The process to find the actual train simulation is as follows:\nWe define points at which the time is fixed, initialized at first with the time of each train stop. This is an input of the simulation and indirectly calls the standard allowance. If there are conflict, we try to remove the first one. We add a fixed time point at the location where that conflict happened. We use the time considered during the exploration (with linear scaling) as reference time. This process is repeated iteratively until no conflict is found. ","categories":"","description":"","excerpt":"The STDCM module must be usable with standard allowances. The user can …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/","tags":"","title":"Standard allowance"},{"body":"OSRD permet d’ajouter un nouveau train dans une grille horaire déjà établie, sans générer aucun conflit avec les autres trains. L’application directe de cette fonctionnalité est appelée la recherche de sillon de dernière minute.\nL’acronyme STDCM (Short Term Digital Capacity Management) est utilisé pour parler du concept en général.\n","categories":"","description":"","excerpt":"OSRD permet d’ajouter un nouveau train dans une grille horaire déjà …","ref":"/fr/docs/reference/design-docs/stdcm/","tags":"","title":"Recherche de sillons de dernière minute (STDCM)"},{"body":"OSRD can be used to find a slot for a train in an already established timetable, without causing conflicts with other trains.\nThe acronym STDCM (Short Term Digital Capacity Management) is used to describe this concept in general.\n","categories":"","description":"","excerpt":"OSRD can be used to find a slot for a train in an already established …","ref":"/en/docs/reference/design-docs/stdcm/","tags":"","title":"Search for last-minute train slots (STDCM)"},{"body":" Cette page est une ébauche, contribuez-y! Définition La couche d’ordonnancement a pour responsabilité d’établir l’ordre de commande des itinéraires, et par conséquent, l’ordre de passage des trains. La méthode exacte utilisée pour prendre cette décision n’importe pas, du moment qu’elle garantit que la simulation se termine (elle ne doit pas amener de trains en nez-à-nez, ou créer d’autres cas de figure de blocage).\nIl est possible d’implémenter un module d’ordonnancement via des tableaux d’ordre de succession des trains aux aiguilles.\nExigences de conception Il doit être possible de connecter n’importe quel algorithme d’ordonnancement Le module d’ordonnancement doit approuver les commandes de routes. Opérations train: Des itinéraires sont commandés pour chaque trains, aussi loin et aussi tôt que possible. L’approbation de la commande est soumise au régulateur, qui peut la retarder indéfiniment, selon des critères de son choix. ","categories":"","description":"Décide de l'ordre de formation des itinéraires","excerpt":"Décide de l'ordre de formation des itinéraires","ref":"/fr/docs/reference/design-docs/interlocking/ordering/","tags":"","title":"Ordonnancement"},{"body":"Cette page précise certains détails d’implémentation. Sa lecture n’est pas nécessaire pour comprendre les principes généraux, mais peut aider avant de se plonger dans le code.\nSTDCMEdgeBuilder Cette classe est utilisée pour simplifier la création d’instances de STDCMEdge, les arêtes du graphe. Celles-ci contiennent de nombreux attributs, la plupart pouvant être déterminés en fonction du contexte (comme le nœud précédent). La classe STDCMEdgeBuilder permet de rendre certains attributs optionnels et en calcule d’autres.\nUne fois instancié et paramétré, un EdgeBuilder a deux méthodes :\nCollection\u003cSTDCMEdge\u003e makeAllEdges() permet de créer toutes les arêtes possibles dans le contexte donné pour une route donnée. S’il y a plusieurs “ouvertures” entre des blocks d’occupation, une arête est créée par ouverture. Tous les conflits, leurs évitements et les attributs associés sont déterminés ici.\nSTDCMEdge findEdgeSameNextOccupancy(double timeNextOccupancy) : Cette méthode permet d’obtenir l’arête passant par une certaine “ouverture” (quand elle existe), identifiée ici par le temps de la prochaine occupation sur la route. Elle est utilisée à chaque fois qu’une arête doit être re-créée dans un contexte différent, comme pour appliquer une marge ou corriger une discontinuité. Elle appelle la méthode précédente.\nRecherche de chemin Evaluation des distances La fonction utilisée pour déterminer la distance (au sens de la recherche de chemin) détermine quel chemin sera privilégié. Le chemin obtenu sera toujours le plus court en fonction du critère donné.\nIci, deux paramètres sont utilisés : le temps de parcours total et l’heure de départ. Le second a un poids très faible par rapport au premier, pour sélectionner en priorité le chemin le plus rapide. Les détails du calcul sont indiqués dans les commentaires des méthodes concernées.\nHeuristiques L’algorithme de recherche de chemin dans le graphe est un A*, avec une heuristique basée sur les coordonnées géographiques.\nCependant, la géométrie des infrastructures générées sont arbitraires, elle ne correspond pas aux distances indiquées sur les voies. Il est donc possible que, sur ces infrastructures, les chemins obtenus ne soient pas les plus courts.\nIl est en théorie possible d’utiliser cette heuristique pour déterminer si le chemin en cours d’exploration pourra mener à une solution dont le temps de parcours ne dépasse pas le maximum. Mais pour la même raison, ajouter ce critère rend STDCM inutilisable sur les infrastructures générées. Plus de détails dans cette issue.\n","categories":"","description":"","excerpt":"Cette page précise certains détails d’implémentation. Sa lecture n’est …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/","tags":"","title":"Détails d'implémentation"},{"body":"This page is about implementation details. It isn’t necessary to understand general principles, but it helps before reading the code.\nSTDCMEdgeBuilder This refers to this class in the project.\nThis class is used to make it easier to create instances of STDCMEdge, the graph edges. Those contain many attributes, most of which can be determined from the context (e.g. the previous node). The STDCMEdgeBuilder class makes some parameters optional and automatically computes others.\nOnce instantiated and parametrized, an STDCMEdgeBuilder has two methods:\nmakeAllEdges(): Collection\u003cSTDCMEdge\u003e can be used to create all the possible edges in the given context for a given route. If there are several “openings” between occupancy blocks, one edge is instantiated for each opening. Every conflict, their avoidance, and their related attributes are handled here.\nfindEdgeSameNextOccupancy(double timeNextOccupancy): STDCMEdge?: This method is used to get the specific edges that uses a certain opening (when it exists), identified here with the time of the next occupancy block. It is called whenever a new edge must be re-created to replace an old one. It calls the previous method.\nPathfinding The methods mentioned here are defined in this class.\nCost function The function used to define pathfinding cost sets which path is used over another. The result is always the one that minimizes this cost (as long as the heuristic is admissible).\nHere, two parameters are used: total run time and departure time. The latter has a very small weight compared to the former, so that the fastest path is found. More details are explained in the documentation of those methods.\nHeuristics The algorithm used to find a path is an A*, with a heuristic based on geographical coordinates.\nHowever, the coordinates of generated infrastructures are arbitrary and don’t reflect the track distance. It means that, for the generated infrastructures, the path may not always be the shortest one.\nIt would be possible to use this heuristic to determine whether the current node can lead to a path that doesn’t take longer than the maximum allowed total run time. But for the same reason, adding this feature would break any STDCM test on generated infras. More details in this issue.\n","categories":"","description":"","excerpt":"This page is about implementation details. It isn’t necessary to …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/","tags":"","title":"Implementation details"},{"body":"RailJSON is the format used to describe a railway infrastructure, it’s described in its JSON schema.\nBelow are a list of REST APIs implemented by OSRD.\n","categories":"","description":"Programming interfaces specifications","excerpt":"Programming interfaces specifications","ref":"/en/docs/reference/apis/","tags":"","title":"APIs"},{"body":"Le format utilisé pour décrire une infrastructure ferroviaire est RailJSON, il est décrit dans son schéma JSON.\nCi-dessous se trouve une liste des APIs REST implémentées par OSRD.\n","categories":"","description":"Spécifications des interfaces de programmation","excerpt":"Spécifications des interfaces de programmation","ref":"/fr/docs/reference/apis/","tags":"","title":"APIs"},{"body":"\nLe projet a pour ambition de répondre à une large gamme de besoins autour de la planification ferroviaire :\nconception des plans de transport études d’exploitation gestion d’infrastructure production de sillons de dernière minute Conception des plans de transport La conception de plans de transport consiste à formuler une réponse1 aux schémas de dessertes2. OSRD fournit déjà un certain nombre de fonctionnalités utiles à cette fin :\nbase d’infrastructure ferroviaire à la voie base de données de matériel roulant possibilité de modifier l’infrastructure visualisation de grilles horaires application de différents types de marges sur les sillons, y compris une marge économique, qui minimise l’énergie consommée Les perspectives futures comprennent notamment :\nla détection automatique de conflits3 synthèse d’infrastructure à la ligne à partir d’infrastructure à la voie visualisation schématique du plan de transport module d’optimisation de la capacité en ligne, d’occupation de la voie en gare et de roulement matériel Études d’exploitation Les études d’exploitation permettent d’évaluer la capacité de l’infrastructure à répondre à la demande et de la mettre en cohérence avec les besoins de transport. Elles permettent de prendre des décisions d’investissements d’infrastructure publique éclairées.\nOSRD permet de répondre à ce besoin en :\nfournissant une base d’infrastructure ferroviaires à la voie fournissant une base de données de matériel roulant donnant la possibilité de modifier l’infrastructure existante et ajouter des installations permettant de visualiser les grilles horaires permettant d’appliquer différents types de marges sur les sillons, dont une répartition économique, qui minimise l’énergie consommée. fournissant un simulateur de signalisation Les perspectives futures comprennent notamment :\ndétection de conflits3 évaluation de la robustesse d’une grille horaire via un module de simulation stochastique calcul automatique de débit et capacité Gestion d’infrastructure Le traitement d’informations liées à l’infrastructure ferroviaire étant un besoin commun à toutes les fonctionnalités d’OSRD, un module dédié permet de :\nvisualiser sur une carte les différents types d’objets utilisables dans l’application éditer l’infrastructure ferroviaire rechercher des objets importer de nouvelles infrastructures4 Sillons de dernière minute Si une grande partie des sillons5 sont établis longtemps à l’avance, une proportion grandissante ne sont commandés que très peu de temps avant le départ souhaité du train, notament avec le développement du fret.\nIl faut par conséquent être capable de répondre non seulement rapidement (moins de 3 minutes) à ces demandes, mais aussi correctement, ce qui n’est pas possible sans automatisation.\nUne offre de sillon correcte doit répondre à de nombreux critères, notamment :\nprendre en compte les travaux sur l’infrastructure ne pas générer de conflits3 avec des sillons déjà établis, y compris en gare estimer de manière réaliste le comportement du train, et donc le moment auquel le train atteint ou quitte des endroits critiques Si certains outils automatisés sont capables de fournir des réponses aux demandes de sillons de dernière minute, aucun ne prend encore en compte tous ces critères, en particulier la gestion des conflits3 en gare.\nCet outil est en cours de développement, et devrait être disponible dans les années à venir.\nSous forme de plan d’exploitation ↩︎\nUn schéma de desserte est une demande d’offre de transport, qui comprend:\nla représentation des trains demandés leur itinéraire les arrêts à desservir  ↩︎ Un conflit se produit lorsque la circulation d’un train en gêne un autre ↩︎ ↩︎ ↩︎ ↩︎\nRailJSON est le format de fichier d’infrastructure utilisé par OSRD. Il est libre, documenté, conçu pour être agnostique au gestionnaire d’infrastructure, facile à générer et manipuler. ↩︎\nUn sillon est un droit de passage sur le réseau ferroviaire, inscrit dans l’espace et dans le temps. Il est vendu par un gestionnaire d’infrastructure (GI) à une entreprise ferroviaire (EF). ↩︎\n","categories":"","description":"Applications et axes directeurs","excerpt":"Applications et axes directeurs","ref":"/fr/about/use-case/","tags":"","title":"Cas d'utilisation"},{"body":"This wiki is meant to help software engineers have a deep understanding of railway systems.\nIt can only happen if content is added as needed. If something is missing, contribute!\n","categories":"","description":"International railway wiki","excerpt":"International railway wiki","ref":"/en/docs/railway-wiki/","tags":"","title":"Railway Wiki"},{"body":"\nDesign decisions Some major changes were made between our first version of the timetable and the new one:\nIsolate the timetable table. It can be used in a scenario or in other contexts Have a soft reference from train schedule to rolling stock (to be able to create a train schedule with unknown rolling stock) Consider path and simulation output as cache (that don’t require to be stored in DB) We can compute pathfinding without having to store data All input needed to compute a path is stored in the train schedule (we can recompute it if needed) All input needed to run a simulation is stored in the train schedule (we can recompute it if needed) Train schedule v2 Requirements front: easy to keep consistent during edition front: intermediate invalid states than can be reached during edition have to be encodable front: when deleting a waypoint that is referenced by margins, the position of the deleted waypoint within the path must be preserved until the situation is resolved import: path waypoint locations can be specified using UIC operational point codes import: support fixed scheduled arrival times at stops and arbitrary points import edition: train schedules must be self-contained: they cannot be described using the result of pathfinding or simulations Design decisions Path waypoints have an identity At some point in the design process, the question was raised of whether to reference location of stops and margin transitions by name, or by value. That is, should stops hold the index of the waypoint where the stop occurs, or a description of the location where the stop occurs?\nIt was decided to add identifiers to path waypoints, and to reference those identifiers where referencing a path location is needed. This has multiple upsides:\nyou can’t reference a location outside of the path when changing a waypoint’s location, for example from one station’s platform to another, no additional maintenant work is needed to keep the path consistent if a path goes to the same place multiple times, the identifier reference makes it clear which path location is referenced it makes keeping data consistent while editing easier, as all locations are kept in a single place Invalid train schedules and soft deletes If a user deletes a waypoint, what happens? Is it the front-end’s responsibility to only save valid schedules, or can invalid schedules be represented in the data model? We decided that it wasn’t just the front-end’s responsibility, as we want to be able to model inconsistent states, until the user comes back to fix it.\nOne key observation was that we do not want to lose the ability to locate within the path waypoints that were deleted, until all references are gone. How is the front-end supposed to display margin bounds or stops for a waypoint that’s gone, if it’s not there anymore?\nWe thus decided to add a deleted soft-delete flag to waypoints. When this flag is set, the back-end runs simulations on the path, but still allows saving it. Once all references to a deleted waypoint are gone, it can be removed from the path. The backend can deny train schedules with stale deleted waypoints.\nSeparating path and stops This decision was hard to make, as there are little factors influencing this decision. Two observations led us to this decision:\nwhen deleting a waypoint, the end user may want to preserve the associated stop. Making the separation clear in the data model helps with implementing this behavior correctly, if deemed relevant bundling stops into the path makes it harder to describe what fields path waypoints should have, and what should have a separate object and reference. It was decided that keeping path a simple list of Location, with no strings attached, made things a little clearer. No more engineering margins? In the legacy model, we had engineering margins. These margins had the property of being able to overlap. It was also possible to choose the distribution algorithm for each margin individually.\nWe asked users to comment on the difference and the usefulness of retaining these margins with scheduled points. The answer is that there is no fundamental difference, and that the additional flexibility offered by engineering margins makes no practical sense (overlap and choice of distribution…).\nArrival times are durations since departure time this allows shifting the departure time without having to change arrival times we don’t have to parse dates and compute date differences within a single trip We also discussed whether to use seconds or ISO 8601 durations. In the end, ISO 8601 was chosen, despite the simplicity of seconds:\nit preserves the user’s choice unit for specifying duration it interfaces nicely with the ISO 8601 departure time it does not suffer from potential integer-float serialization related precision loss Invalid and outdated train schedules Reasons for a train schedule to be invalid:\nInconsistent train schedule (contains deleted waypoint) Rolling stock not found Path waypoint not found The path cannot be found Reasons for a train schedule to be outdated:\nThe train path changed The train running time changed What we can do about outdated trains:\nNothing, they’re updated without notification We can notify the user that a train schedule is outdated: Nothing can be done except acknowledge the change We can not check what changed between the old and new version We can not know the cause of this change (RS, Infra, Algorithms…) Note: The outdated status is a nice to have feature (it won’t be implemented right now).\nCreation fields These fields are required at creation time, but cannot be changed afterwards. They are returned when the train schedule is queried.\ntimetable_id: 42 Modifiable fields train_name: \"ABC3615\" rolling_stock_name: R2D2 # labels are metadata. They're only used for display filtering labels: [\"tchou-tchou\", \"choo-choo\"] # used to select speed limits for simulation speed_limit_tag: \"MA100\" # the start time is an ISO 8601 datetime with timezone. it is not always the # same at the departure time, as there may be a stop at the starting point start_time: \"2023-12-21T08:51:11.914897+00:00\" path: - {id: a, uic: 87210} # Any operational point matching the given uic - {id: b, track: foo, offset: 10000} # 10m on track foo - {id: c, deleted: true, trigram: ABC} # Any operational point matching the trigram ABC - {id: d, operational_point: X} # A specified operational point # the algorithm used for distributing margins and scheduled times constraint_distribution: MARECO # or LINEAR # all durations and times are specified using ISO 8601 # we don't supports months and years duration since it's ambiguous # times are defined as time elapsed since start. Even if the attribute is omitted, # a scheduled point at the starting point is inferred to have departure=start_time # the \"locked\" flag is ignored by the backend. # # To specify signal's state on stop's arrival, you can use the \"reception_signal\" enum: # - OPEN: arrival on open signal, will reserve resource downstream of the signal. # - STOP: arrival on stop signal, will not reserve resource downstream of the signal # and will trigger safety speed on approach. # - SHORT_SLIP_STOP: arrival on stop signal with a short slip distance, # will not reserve resource downstream of the signal and will trigger safety # speed on approach as well as short slip distance speed. # This is used for cases where a movable element is placed shortly after the signal # and going beyond the signal would cause major problems. # This is used automatically for any stop before a buffer-stop. # This is also the default use for STDCM stops, as it is the most restrictive. schedule: - {at: a, stop_for: PT5M, locked: true} # inferred arrival to be equal to start_time - {at: b, arrival: PT10M, stop_for: PT5M} - {at: c, stop_for: PT5M} - {at: d, arrival: PT50M, locked: true, reception_signal: SHORT_SLIP_STOP} margins: # This example encodes the following margins: # a --- 5% --- b --- 3% --- c --- 4.5min/100km --- d # /!\\ all schedule points with either an arrival or departure time must also be # margin boundaries. departure and arrival waypoints are implicit boundaries. /!\\ # boundaries delimit margin sections. A list of N boundaries yields N + 1 sections. boundaries: [b, c] # the following units are supported: # - % means added percentage of the base simulation time # - min/100km means minutes per 100 kilometers values: [\"5%\", \"3%\", \"4.5min/100km\"] # train speed at simulation start, in meters per second. # must be zero if the train starts at a stop initial_speed: 2.5 power_restrictions: - {from: b, to: c, value: \"M1C1\"} comfort: AIR_CONDITIONING # or HEATING, default STANDARD options: # Should we use electrical profiles to select rolling stock speed effort curves use_electrical_profiles: true Combining margins and schedule Margins and scheduled points are two ways to add time constraints to a train’s schedule. Therefore, there must be a clear set of rules to figure out how these two interfaces interact.\nThe end goal is to make the target schedule and margins consistent with each other. This is achieved by:\ncomputing what the schedule would look like if only margins were applied compare that to the target schedule correct the margin schedule so that it matches the target schedule The path is partitioned as follows:\nknown time sections span between locations where the arrival time is known. If there are N such locations, there are N - 1 known time sections. In these sections, margins need to be adjusted to match the target schedule. If the arrival time at destination is unknown, the section from the last known arrival time point and the destination is called the relaxed time section has no bound. Margins can be applied directly. As margins cannot span known time section boundaries, each known time section can be further subdivided into margin sections. Margins cover the entire path.\nThe end goal is to find the target arrival time at the end of each margin section. This needs to be done while preserving consistency with the input schedule.\nNote that stops do not impact margin repartition. For example, the margin does not need to be proportionally distributed on each side of b.\nThe same goes for points with arrival time. They impact whether the margin is respected or not, but they do not force the margin to be proportionally distributed on each side of the point.\nThe final schedule is computed as follows:\nA base simulation is computed, without any time constraint (other than stops). It’s used to compute provisional margin values. Make a provisional time table, which ignores target arrival times but includes provisional margin values. For each known time section, compute the adjustment required to make the provisional schedule match the target schedule. Distribute this difference into the known time section’s margin sections, proportionally to margin section running time. After distributing the adjustment into margin sections, the final schedule should be compatible with the target schedule. Error handling Some errors may happen while building the timetable:\nif a known time section’s required adjustment is negative, a warning must be raised, as margins will have to be lowered if a margin section’s final running time is tighter than the base simulation, it cannot be achieved, and a warning should be raised Other errors can happen at runtime:\ntarget margin values can be too low, as transitions from high density margin to low margin section force the train to lose time after it has exited to high density margin section. target margin values can also be too high, as the train may not have time to slow down enough, or drive so slow as to be unacceptable. During simulation, if a target arrival time cannot be achieved, the rest of the schedule still stands.\nEndpoints Timetable POST /v2/timetable GET /v2/timetable/ # Paginated list timetable PUT /v2/timetable/ID DELETE /v2/timetable/ID GET /v2/timetable/ID # Timetable with list of train schedule ids attached to it Train Schedule POST /v2/timetable/ID/train_schedule # A batch creation GET /v2/train_schedule/ID PUT /v2/train_schedule/ID # Update a specific train schedule DELETE /v2/train_schedule # A batch deletion Path POST /v2/infra/ID/pathfinding/topo # Not required now can be move later POST /v2/infra/ID/pathfinding/blocks # takes a pathfinding result and a list of properties to extract POST /v2/infra/ID/path_properties?props[]=slopes\u0026props[]=gradients\u0026props[]=electrifications\u0026props[]=geometry\u0026props[]=operational_points GET /v2/train_schedule/ID/path?infra_id=42 # Retrieve the path from a train schedule Simulation results # Retrieve the list of conflict of the timetable (invalid trains are ignored) GET /v2/timetable/ID/conflicts?infra=N # Retrieve the space, speed and time curve of a given train GET /v2/train_schedule/ID/simulation?infra=N # Retrieves simulation information for a given train list. Useful for finding out whether pathfinding/simulation was successful. GET /v2/train_schedule/simulations_summary?infra=N\u0026ids[]=X\u0026ids[]=Y # Projects the space time curves and paths of a number of train schedules onto a given path POST /v2/train_schedule/project_path?infra=N\u0026ids[]=X\u0026ids[]=Y Frontend workflow The frontend shouldn’t wait minutes to display something to the user. When a timetable contains hundreds of trains it can take some time to simulate everything. The idea is to split requests into small batches.\nflowchart TB InfraLoaded[Check for infra to be loaded] RetrieveTimetable[Retrieve Timetable] RetrieveTrains[Retrieve TS2 payloads] SummarySimulation[[Summary simulation batch N:N+10]] TrainProjectionPath[Get selected train projection path] Projection[[Projection batch N-10:N]] TrainSimulation[Get selected train simulation] TrainPath[Get selected train path] TrainPathProperties[Get selected train path properties] DisplayGev(Display: GEV / Map /\\n Driver Schedule/ Linear / Output Table) DisplayGet(Display Space Time Chart) DisplayTrainList(Display train list) Conflicts(Compute and display conflicts) ProjectConflicts(Display conflicts in GET) InfraLoaded --\u003e|Wait| SummarySimulation InfraLoaded --\u003e|Wait| TrainProjectionPath InfraLoaded --\u003e|Wait| TrainPath TrainPath --\u003e|If found| TrainSimulation TrainPath --\u003e|If found| TrainPathProperties RetrieveTimetable --\u003e|Get train ids| RetrieveTrains RetrieveTrains ==\u003e|Sort trains and chunk it| SummarySimulation SummarySimulation ==\u003e|Wait for the previous batch| Projection SummarySimulation --\u003e|Gradually fill cards| DisplayTrainList TrainPathProperties --\u003e| | DisplayGev TrainSimulation --\u003e|If valid simulation| DisplayGev TrainProjectionPath --\u003e|Wait for the previous batch| Projection SummarySimulation -..-\u003e|If no projection train id| TrainProjectionPath Projection ==\u003e|Gradually fill| DisplayGet SummarySimulation --\u003e|Once everything is simulated| Conflicts Conflicts --\u003e ProjectConflicts ","categories":"","description":"Describes evolutions to the new **timetable** and **train schedule** models","excerpt":"Describes evolutions to the new **timetable** and **train schedule** …","ref":"/en/docs/reference/design-docs/timetable/","tags":"","title":"Timetable v2"},{"body":"\nOSRD is meant to fulfill a range of use-cases related to railway planning:\ntimetabling operation studies infrastructure management short term capacity management Timetabling Timetabling is about designing a transport service in order to meet the transit needs.\nOSRD addresses this by providing:\na track level railway infrastructure database a rolling stock database an infrastructure edition tool a timetabling tool train path allowances, including an allowance distribution which minimizes energy use Planned features include:\nautomated conflict detection1 line level infrastructure synthesis from track level infrastructure interactive timetable diagrams a throughput and rolling stock turnover optimizer Operation studies Operation studies assess the ability of infrastructures to meet demand, and balance infrastructure capacity with transportation needs. They enable informed public infrastructure investment decisions.\nOSRD addresses this need by providing:\na track level railway infrastructure database a rolling stock database an infrastructure edition tool a timetabling tool train path allowances, including an allowance distribution which minimizes energy use a signaling simulator Planned features include:\nautomated conflict detection1 automated timetable robustness assessment using stochastic simulation automated throughput analyzer Infrastructure management Processing railway infrastructure data is a requirement shared by all of OSRD’s features. Therefore, a dedicated module provides:\na customizable infrastructure map an infrastructure editor a search feature an import tool2 Short term capacity management Even though most train paths3 are allocated years before operations, a growing part is allocated shortly before the planned departure time. This change is largely due to growing demand for rail freight.\nThere is therefore a need for timely (less than 3 minutes) and correct answers, which cannot be achieved without automation.\nA correct train path must, among other things:\ntake planned infrastructure work into account avoid generating conflicts1 with planned trains, including inside stations realistically estimate train behavior, and thus when the train reaches or leaves critical locations Even though some tools can currently provide answers, none currently takes all of the above into account, especially station conflicts.\nThis tool is undergoing active development, and should be available within the coming years.\nA conflicts occurs when the movement of a train interferes with another ↩︎ ↩︎ ↩︎\nOSRD uses the RailJSON rail infrastructure file format. It is a free and documented format, designed to be infrastructure manager-agnostic, easy to generate and use. ↩︎\nA train paths is a right of way on the rail network, bounded in time and space. Train paths are sold by infrastructure managers to railway companies. ↩︎\n","categories":"","description":"Use cases related to rail transport planning","excerpt":"Use cases related to rail transport planning","ref":"/en/about/use-case/","tags":"","title":"Use cases"},{"body":"Ce wiki a pour objectif de rendre accessible aux développeurs des informations sur le monde ferroviaire.\nCela ne peut se produire que si le contenu est ajouté lorsque nécessaire. Si quelque chose manque, contribuez !\n","categories":"","description":"Wiki ferroviaire international","excerpt":"Wiki ferroviaire international","ref":"/fr/docs/railway-wiki/","tags":"","title":"Wiki Ferroviaire"},{"body":"Description Les contraintes sur ce qu’est un train sont relativement faibles. Il doit seulement avoir un identifiant, qui permet aux autres systèmes de garder des références vers des trains.\nExigences de conception Les trains occupent les zones. Les trains doivent être suivis pour préserver leur ordre de passage. Les trains ont pour responsabilité de demander les itinéraires devant eux. ","categories":"","description":"Représente un train dans la simulation","excerpt":"Représente un train dans la simulation","ref":"/fr/docs/reference/design-docs/interlocking/train/","tags":"","title":"Train"},{"body":"Context and requirements authentication (authn) is the process of figuring out a user’s identity. authorization (authz) is the process of figuring out whether a user can do something. This design project started as a result of a feature request coming from SNCF users and stakeholders. After some interviews, we believe the overall needs to be as follows:\ncontrolling access to features some users are supposed to only view results of operational studies some users only get access to part of the app not everyone can have access to the admin panel it could be nice to be able to roll experimental features out incrementaly controlling access to data some infrastructures shall only be changed by automated import jobs users might want to control who can mess with what they’re currently working on rolling stock, infrastructure and timetable data may be confidential Overall architecture flowchart LR subgraph gateway auth([authentication]) end subgraph editoast subgraph authorization roles([role check]) permissions([permission check]) end end subgraph decisions permit deny end request --\u003e auth --\u003e roles --\u003e permissions auth --\u003e deny roles --\u003e deny permissions --\u003e permit \u0026 deny Authentication The app’s backend is not responsible for authenticating the user: it gets all required information from gateway, the authenticating reverse proxy which stands between it and the front-end.\nat application start-up, the front-end redirects to the login page if the user is not logged in if the user is already authenticated, the gateway returns user metadata otherwise, the gateway initiates the authentication process, usually with OIDC. The implementation was designed to allow new backends to be added easily. once the user is authenticated, all requests to the backend can expect the following headers to be set: x-remote-user-identity contain a unique identifier for this identity. It can be thought of as an opaque provider_id/user_id tuple. x-remote-user-name contain a username When editoast receives a request, it has to match the remote user ID with a database user, creating it as needed.\ncreate table authn_subject( id bigserial generated always as identity primary key, ); create table authn_user( id bigint primary key references auth_subject on delete cascade, identity_id text not null, name text, ); create table authn_group( id bigint primary key references auth_subject on delete cascade, name text not null, ); -- add a trigger so that when a group is deleted, the associated authn_subject is deleted too -- add a trigger so that when a user is deleted, the associated authn_subject is deleted too create table authn_group_membership( user bigint references auth_user on delete cascade not null, group bigint references auth_group on delete cascade not null, unique (user, group), ); Group and role management API Users cannot be directly created. The authenticating reverse proxy is in charge of user management. role management is protected by the role:admin role. groups management is subject to permissions. Get information about a user GET /authn/me GET /authn/user/{user_id} { \"id\": 42, \"name\": \"Foo Bar\", \"groups\": [ {\"id\": 1, \"name\": \"A\"}, {\"id\": 2, \"name\": \"B\"} ], \"app_roles\": [\"ops\"], \"builtin_roles\": [\"infra:read\"] } Builtin roles are deduced from app roles, and thus cannot be directly edited.\nAdd roles to a user or group This endpoint can only be called if the user has the role:admin builtin role.\nPOST /authn/user/{user_id}/roles/add POST /authn/group/{group_id}/roles/add Takes a list of app roles:\n[\"ops\", \"stdcm\"] Remove roles from a user or group This endpoint can only be called if the user has the role:admin builtin role.\nPOST /authn/user/{user_id}/roles/remove Takes a list of app roles to remove:\n[\"ops\"] Create a group This endpoint can only be called if the user has the group:create builtin role. When a user creates a group, it becomes its owner.\nPOST /authn/group { \"name\": \"Foo\" \"app_roles\": [\"ops\"], } Returns the group ID.\nAdd users to a group Can only be called if the user has Writer access to the group.\nPOST /authn/group/{group_id}/add Takes a list of user IDs\n[1, 2, 3] Remove users from a group Can only be called if the user has Writer access to the group.\nPOST /authn/group/{group_id}/remove Takes a list of user IDs\n[1, 2, 3] Delete a group Can only be called if the user has Owner access to the group.\nDELETE /authn/group/{group_id} Authorization As shown in the overall architecture section, to determine if a subject is allowed to conduct an action on a ressource, two checks are performed:\nWe check that the roles of the subject allows the action. We check that the subject has the minimum privileges on the ressource(s) that are required to perform the action. Roles Subject can have any number of roles. Roles allow access to features. Roles do not give rights on specific objects.\nBoth the frontend and backend require some roles to be set to allow access to parts of the app. In the frontend, roles guard features, in the backend, roles guard endpoints or group of endpoints.\nThere are two types of roles:\nBuiltin roles are bundled with OSRD. Only builtin roles can be required by endpoints. These roles cannot directly be assigned to users. Application roles can be assigned to users. These roles are defined in a configuration file that editoast reads at startup. Here is an example of what builtin roles might look like:\nrole:admin allows assigning roles to users and groups group:create allows creating user groups infra:read allows access to the map viewer module infra:write implies infra:read. it allows access to the infrastructure editor. rolling-stock:read rolling-stock:write implies rolling-stock:read. Allows access to the rolling stock editor. timetable:read timetable:write implies timetable:read operational-studies:read allows read only access to operational studies. it implies infra:read, timetable:read and rolling-stock:read operational-studies:write allows write access to operational studies. it implies operational-studies:read and timetable:write stdcm implies infra:read, timetable:read and rolling-stock:read. it allows access to the short term path request module. admin gives access to the admin panel, and implies all other roles Given these builtin roles, application roles may look like:\noperational-studies-customer implies operational-studies:read operational-studies-analyst implies operational-studies:write stdcm-customer implies stdcm ops implies admin Roles are hierarchical. This is a necessity to ensure that, for example, if we are to introduce a new action related to scenarios, each subject with the role “exploitation studies” gets that new role automatically. We’d otherwise need to edit the appropriate existing roles.\nTheir hierarchy could ressemble:\n%%{init: {\"flowchart\": {\"defaultRenderer\": \"elk\"}} }%% flowchart TD subgraph application roles operational-studies-analyst operational-studies-customer end subgraph builtin roles rolling-stock:read rolling-stock:write infra:read infra:write timetable:read timetable:write operational-studies:read operational-studies:write end operational-studies-analyst --\u003e operational-studies:write operational-studies-customer --\u003e operational-studies:read infra:write --\u003e infra:read rolling-stock:write --\u003e rolling-stock:read operational-studies:read --\u003e infra:read \u0026 timetable:read \u0026 rolling-stock:read operational-studies:write --\u003e operational-studies:read \u0026 timetable:write timetable:write --\u003e timetable:read classDef app fill:#333,color:white,font-style:italic classDef builtin fill:#992233,color:white,font-style:bold class stdcm,exploitation,infra,project,study,scenario app class infra_read,infra_edit,infra_delete,project_create,study_delete,scenario_create,scenario_update builtin Permissions Permission checks are done by the backend, even though the frontend may use the effective privilege level of a user to decide whether to allow modifying / changing permissions for a given object.\nPermissions are checked per resource, after checking roles. A single request may involve multiple resources, and as such involve multiple permission checks.\nPermission checks are performed as follows:\nfor each request, before any resource is accessed, compute which resources need access and required privilege levels figure out, for the request’s user, its effective privilege level for every involved resource if the user’s privilege level does not meet expectations, raise an error before any change is made enum EffectivePrivLvl { Owner, // all operations allowed, including granting access and deleting the resource Writer, // can change the resource Creator, // can create new subresources Reader, // can read the resource MinimalMetadata, // is indirectly aware that the resource exists } trait Resource { #[must_use] fn get_privlvl(resource_pk: u64, user: \u0026UserIdentity) -\u003e EffectivePrivLvl; } The backend may therefore perform one or more privilege check per request:\npathfinding: Reader on the infrastructure displaying a timetable: Reader on each rolling stock batch train creation: Creator on the timetable conflict detection: Reader on the infrastructure Reader on the timetable Reader on every involved rolling stock simulation results: Reader on the infrastructure Reader on the rolling stock A grant is a right, given to a user or group on a specific resource. Users get privileges through grants. There are two types of grants:\nexplicit grants are explicitly attached to resources implicit grants automatically propagate explicit grants for objects which belong to a hierarchy: if a subject owns a project, it also owns all studies and scenarios if a subject can read a scenario, it knows the parent study and project exist Explicit grants can be edited from the frontend any user holding grants over a resource can add new ones when a resource is created, Owner is granted to the current user not all objects type can have explicit grants: train schedule inherit their timetable’s grants -- this type is the same as EffectivePrivLvl, except that MinimalMetadata is absent, -- as it cannot be granted directly. mere knowledge that an object exist can only be -- granted using implicit grants. create type grant_privlvl as enum ('Owner', 'Writer', 'Creator', 'Reader'); -- this table is a template, which other grant tables are -- designed to be created from. it must be kept empty. create table authz_template_grant( -- if subject is null, this grant applies to any subject subject bigint references authn_subject on delete cascade, grant grant_privlvl not null, granted_by bigint references authn_user on delete set null, granted_at timestamp not null default CURRENT_TIMESTAMP, ); -- these indices speed up cascade deletes create index on authz_template_grant(subject); create index on authz_template_grant(granted_by); -- create a new grant table for infrastructures create table authz_grant_EXAMPLE ( like authz_template_grant including all, resource bigint references EXAMPLE on delete cascade not null, unique nulls not distinct (resource, subject), ); -- raise an error if grants are inserted into the template create function authz_grant_insert_error() RETURNS trigger AS $err$ BEGIN RAISE EXCEPTION 'authz_grant is a template, which other grant ' 'tables are designed to inherit from. it must be kept empty.'; END; $err$ LANGUAGE plpgsql; create trigger before insert on authz_template_grant execute function authz_grant_insert_error(); Implicit grants Implicit grants only apply to the operational studies module, not timetables, infrastructures and rolling stocks. Implicit grants propagate explicit grants to related objects. There are two types of implicit grants:\nexplicit grants propagate downwards within hierarchies: Owner, Reader, Writer propagate as is, Creator is reduced to Reader MinimalMetadata propagates up within project hierarchies, so that read access to a study or scenario allows having the name and description of the parent project The following objects have implicit grants:\nproject gets MinimalMetadata if the user has any right on a child study or scenario study gets: MinimalMetadata if the user has any right on a child scenario Owner, Reader, Writer if the user has such right on the parent study. Creator is reduced to Reader. scenario gets Owner, Reader, Writer if the user has such right on the parent study or project. Creator is reduced to Reader. train-schedules have the same grants as their timetable Permission meta-model Get the privilege level of the current user GET /authz/{resource_type}/{resource_id}/privlvl Get all grants for a resource GET /authz/{resource_type}/{resource_id}/grants [ { \"subject\": {\"kind\": \"group\", \"id\": 42, \"name\": \"Bar\"}, \"implicit_grant\": \"Owner\", \"implicit_grant_source\": \"project\" }, { \"subject\": {\"kind\": \"user\", \"id\": 42, \"name\": \"Foo\"}, \"grant\": \"Writer\" }, { \"subject\": {\"kind\": \"user\", \"id\": 42, \"name\": \"Foo\"}, \"grant\": \"Writer\", \"implicit_grant\": \"MinimalMetadata\", \"implicit_grant_source\": \"project\" } ] Implicit grants cannot be edited, and are only displayed to inform the end user.\nAdd a new grant POST /authz/{resource_type}/{resource_id}/grants { \"subject_id\": 42, \"grant\": \"Writer\" } Change a grant PATCH /authz/{resource_type}/{resource_id}/grants/{grant_id} { \"grant\": \"Reader\" } Revoke a grant DELETE /authz/{resource_type}/{resource_id}/grants/{grant_id} Implementation plan Phase 1: ground work Back-end:\npass the proper headers from the reverse proxy to editoast implement the authn / authz model into the database get / create users on the fly using reverse proxy headers implement the role parsing and book-keeping (it can be parsed on startup and leaked into a static lifetime) implement a proof of concept for roles using role:admin and role management implement a proof of concept for permissions by implementing group management implement a middleware within editoast which: attaches a UserInfo object to each request ensures that role / permission checks were performed. Implement two modules: log on missing check, abort on missing check. injects which checks were performed into response headers so it can be tested introduce the concept of rolling stock collections to enable easier rolling stock permission checking write a migration guide to help OSRD developpers navigate the authorization APIs Front-end:\ntake into account builtin roles to decide which features to unlock design, validate and build a permission editor prepare graceful handling of 403s Phase 2: migration Back-end:\nincrementally migrate all endpoints, using the middleware to find missing checks switch the default action on missing permission check to abort Front-end:\nadd the permission editor to all relevant objects handle 403s, especially on scenarios, where read access on the timetable, infra, rolling stock collections and electrical profile is required Design decisions Simultaneous RBAC and ABAC RBAC: role based access control (users have roles, actions require roles) ABAC: attribute based access control (resources have attributes, user + actions require attributes). ACLs are a kind of ABAC.\nAfter staring at what users asked for and established authorization models allow, we figured out that while no one model is a good fit on its own:\njust RBAC would not allow fine grained, per object access control just ABAC would not allow guarding off access to entire features We decided that each authorization model could be used where it shows its strength:\nRBAC is used to authorize access to frontend features and backend endpoints ABAC is used to authorize actions on specific objects We found no success in our attempts to find a unifying model.\nNot using any policy language At first, we assumed that using a policy language would assist with correctly implementing authorization. After further consideration, we concluded that:\nno user asked for policy flexibility nor policy as code, and there does not seem to be any obvious use case not already covered by RBAC + ABAC the main policy language considered, cedar, makes it very awkward to implement single pass RBAC + ABAC the primary benefit of policy languages, policy flexibility, is still very much constrained by the data the policy engine is fed: for OSRD, feeding all grants, all users, all groups and all roles to the policy engine is not practical. we thus need filtering and careful modeling, which almost guarantees changes will be required if a new authz rule type were to be requested by a customer. Worse yet, these changes seem to require more effort than adapting the authz system if there were not policy language at all. as policy languages only deal with evaluating the policy, one can be introduced later if so desired No implicit grants for infra, timetable and rolling stock We felt like this feature would be hard to implement, and be likely to introduce confidentiality and performance issues:\nthese objects may not be part of any operational studies, or multiple operational studies implicit grants are hard to implement, and risk introducing vulnerabilities infra, timetable and rolling stock are likely to be confidential Instead, we plan to:\ndelay implementing this feature until we figure out if the lack thereof is an UX issue if deemed required, implement it by checking, within the permission editor, whether all users having access to a scenario can access associated data, and suggesting associated permission changes All resource types share the same permission management endpoints We considered two patterns for permission management endpoints:\na single set of endpoints for all resource types: /authz/{resource_type}/{resource_id}/grants/... separate set of endpoints per resource type: /v2/infra/{infra_id}/grants/... We found that:\nhaving separate set of endpoints per resource types brought extra back-end and front-end complexity the only constraint of unified permission management endpoints is that all resource types need globaly unique IDs the globaly unique ID constraint is less costly than the extra complexity of separate endpoints Dynamically enforce permission checks Ideally, there would be static checks enforcing permission checks. However, we found no completly fool proof way to statically do so.\nInstead, we decided that all permission checks will be registered with a middleware, which will either log or raise an error when a handler performs no check.\nduring local development, the middleware logs missing permission checks as errors during continuous integration checks and production deployments, the middleware aborts on missing checks ","categories":"","description":"","excerpt":"Context and requirements authentication (authn) is the process of …","ref":"/en/docs/reference/design-docs/auth/","tags":"","title":"Authentication and authorization"},{"body":"Loading Signal Parameters The first step of loading the signal is to characterize the signal in the signaling system. This step produces an object that describes the signal.\nDuring the loading of the signal:\nthe signaling system corresponding to the provided name is identified the signal properties and parameters are loaded and validated according to the signaling system spec the signal’s block and route delimiting properties are evaluated Loading the Signal Once signal parameters are loaded, drivers can be loaded. For each driver:\nThe driver implementation is identified from the (signaling_system, next_signaling_system) pair. It is verified that the signaling system outgoing from the driver corresponds to the one of the signal. It is verified that there is no existing driver for the incoming signaling system of the driver. This step produces a Map\u003cSignalingSystem, SignalDriver\u003e, where the signaling system is the one incoming to the signal. It then becomes possible to construct the loaded signal.\nConstructing Blocks The framework creates blocks between signals following the routes present in the infrastructure, and the block properties of the signals. Checks are made on the created block graph: it must always be possible to choose a block for each signal and each state of the infrastructure. Block validation The validation process helps to report invalid configurations in terms of signaling and blockage. The validation cases we want to support are:\nThe signaling system may want to validate, knowing if the block starts / ends on a buffer: the length of the block the spacing between the block signals, first signal excluded Each signal in the block may have specific information if it is a transition signal. Therefore, all signal drivers participate in the validation. In practice, there are two separate mechanisms to address these two needs:\nThe signaling system module is responsible for validating signaling within blocks. Signal drivers take care of validating transitions between blocks. extern fn report_warning(/* TODO */); extern fn report_error(/* TODO */); struct Block { startsAtBufferStop: bool, stopsAtBufferStop: bool, signalTypes: Vec\u003cSignalingSystemId\u003e, signalSettings: Vec\u003cSignalSettings\u003e, signalPositions: Vec\u003cDistance\u003e, length: Distance, } /// Runs in the signaling system module fn check_block( block: Block, ); /// Runs in the signal driver module fn check_signal( signal: SignalSettings, block: Block, // The partial block downstream of the signal - no signal can see backward ); Signal lifecycle Before a train startup:\nthe path a of the train can be expressed is given, both as routes and blocks the signal queue a train will encounter is established During the simulation:\nalong a train movement, the track occupation before it are synthesized when a train observes a signal, its state is evaluated Signal state evaluation Signals are modeled as an evaluation function, taking a view of the world and returning the signal state\nenum ZoneStatus { /** The zone is clear to be used by the train */ CLEAR, /** The zone is occupied by another train, but otherwise clear to use */ OCCUPIED, /** The zone is incompatible. There may be another train as well */ INCOMPATIBLE, } interface MAView { /** Combined status of the zones protected by the current signal */ val protectedZoneStatus: ZoneStatus val nextSignalState: SignalState val nextSignalSettings: SignalSettings } fun signal(maView: MAView?): SignalState { // ... } The view should allow access to the following data:\na synthetized view of zones downstream until the end of the train’s MA the block chain the state of downstream signals which belong to the current block chain Signaling view path The path along which the MAView and SpeedLimitView live is best expressed using blocks:\nblocks can be added to extend the view along the path of a train the view can be reduced by removing blocks, as the train passes by signals Simulation outside the train path Everything mentionned so far was designed to simulate signals between a train the end of its movement authority, as all others signals have no influence over the behavior of trains (they cannot be seen, or are disregarded by drivers).\nNevertheless, one may want to simulate and display the state of all signals at a given point in time, regardless of which signals are in use.\nSimulation rules are as follows:\nif a signal starts blocks which have differing paths, it is simulated as if it were at the end of a route if a signal starts blocks which all start the same path, it is simulated in the same view as the next signals in this path ","categories":"","description":"Tells the story of how signaling infrastructure is loaded and simulated on","excerpt":"Tells the story of how signaling infrastructure is loaded and …","ref":"/en/docs/reference/design-docs/signaling/simulation/","tags":"","title":"Simulation lifecycle"},{"body":"À compléter : ouvrez une issue en cas de mot manquant\nA ADV : Appareil de voie B BA : Block automatique BAL : Block automatique lumineux BAPR : Block automatique à permissivité restreinte BM : Block manuel BMCV : BM par circuit de voie BMVU : BM de voie unique C CAPI : Cantonnement assisté par informatique CC : Commande et contrôle COVIT : Contrôle de vitesse CT : Cantonnement téléphonique D DAAT : Dispositif d’arrêt automatique des trains DMI : Driver machine interface : dispositif qui permet la communication entre le système bord et le conducteur DV : Double voie E EOA : End of authority (fin d’autorisation de mouvement) EPSF : Établissement public de sécurité ferroviaire ETCS : European train control system (système européen de contrôle commande des trains) ERTMS : European rail traffic management system (système européen de gestion du trafic ferroviaire) EVC : European vital computer. (ordinateur européen de sécurité) : calculateur de bord qui supervise la marche du train en fonction des données sol et bord F FA : Fermeture automatique FS : Full supervision (supervision complète) : mode technique dans lequel le train est supervisé en vitesse et déplacement = marche normale attribuée au train G GI : Gestionnaire d’infrastructure GSM/GFU : Global system for mobile communication/Groupe fermé d’utilisateurs GSM-R : Global system for mobile communication railways (Système de communication téléphonique pour mobile dédié aux chemins de fer) GSM-R Data : Système de transmission de données entre les installations « sol » et les installations « bord » via le réseau GSM-R I ICS : Installations de circulation à contre-sens IPCS : Installations permanentes de contre-sens IS : Installation de sécurité ITCS : Installations temporaires de contre-sens J JRU : Juridical recording unit (Enregistreur des paramètres d’exploitation) K KVB : Contrôle de vitesse par balises L LEU : Line side electronic unit (codeur ERTMS) LGV : Ligne à grande vitesse LTV : Limitation temporaire de vitesse M MA : Movement authority : autorisation donnée à un train de circuler vers un point donné en tant que mouvement supervisé N Nf : Non franchissable NL : Non leading (non en tête) : Mode technique de circulation utilisé pour la double traction ou la pousse O OS : On sight (conduite à vue) : mode technique de circulation qui autorise le conducteur à s’avancer en marche à vue. En ETCS1, le mode OS accompagné du message textuel national « Voie de service » impose la marche en manoeuvre pour la réception sur voie de service P PI ETCS : Point d’information ETCS : constitué d’une ou plusieurs balises transmettant des informations vers le bord (par exemple PI avancé ou PI signal) PK : Point Kilométrique : position géographique basée sur un RK (Repère Kilométrique) PL : Pleine ligne PLD : Point limite de domaine : point où une transition entre ETCS et un autre système de signalisation a lieu PN : Passage à niveau PO : Point opérationnel : collection de points représentant un lieu d’intérêt, voir exemple. PR : Point remarquable : voir PO R RBC : Radio block center : système centralisé fonctionnant avec les enclenchements afin d’établir et de contrôler l’espacement et le mouvement des trains en envoyant et recevant des informations par radio en ETCS2 ou 3 RFN : Réseau Ferré National RK : Repère Kilométrique : bornes (physiques) placées sur une voie à distance régulière (environ un kilomètre les unes des autres mais pouvant varier) servant à se repérer sur une voie RST : Radio sol-train RT : Renseignement technique RV : Reversing (refoulement) : mode technique de circulation utilisé pour permettre au train de reculer d’urgence sans signaux ni ordre dans une zone prédéfinie. Ce mode n’est pas utilisé sur le RFN S SEL : Section d’électrification. La plus petite portion d’un caténaire pouvant être coupée pour travaux SGS : Système de gestion de la sécurité SH : Shunting (manoeuvre) : mode technique de circulation manoeuvre SN : System national : mode technique de circulation de niveau STM SR : Staff responsible (responsabilité agent) : mode technique de circulation utilisé dans les situations dégradées. Il est utilisable sous la responsabilité respective de l’agent-circulation et du conducteur SR : Système de repérage SRV : Système de repérage voie : métadonnées et anomalies (données correctives) permettant de faire des calculs de distance entre deux PKs sur une voie STM : Specific transmission module (Module spécifique de transmission) : ce dispositif permet à l’ETCS d’utiliser un système de signalisation national T TECS : Tableau lumineux d’entrée à contre sens TIV : Tableau indicateur de vitesse TIV : Tronçon d’itinéraire de voie (Track Section en anglais). TR : Trip : mode technique de circulation entraînant une application irréversible du freinage d’urgence par le système ETCS jusqu’à l’arrêt du train TSCS : Tableau lumineux de sortie à contre sens TVM : Transmission voie machine V VB : Voie banalisée VP : Voie principale VS : Voie de service VU : Voie unique VUT : Voie unique temporaire VUTP : Voie unique temporaire à caractère permanent Z ZEP : Zone élémentaire de protection : la plus petite portion de voie pouvant être fermée pour des travaux ","categories":"","description":"Glossaire thématique d'OSRD et du ferroviaire","excerpt":"Glossaire thématique d'OSRD et du ferroviaire","ref":"/fr/docs/railway-wiki/glossary/","tags":"","title":"Glossaire"},{"body":"Please open an issue if you’re missing a word\n","categories":"","description":"Glossary of OSRD and railway vocabulary","excerpt":"Glossary of OSRD and railway vocabulary","ref":"/en/docs/railway-wiki/glossary/","tags":"","title":"Glossary"},{"body":"TODO: create another document describing RPC interactions between core and editoast\nContext and requirements Without this proposal, editoast directly makes calls to core using http. Using k8s, if multiple core workers are started, requests are randomly distributed to core workers.\nThis architecture brings a number of issues:\nTo respond to a request, the core worker need to hold the request’s full infrastructure in memory. Workers do not have enough memory to hold all infrastructures in memory. Requests thus need to be routed to core workers specialized by infrastructure, which cannot be easily done using http. If too many requests are dispatched to a busy core worker, they will just time out. There is no easy way to scale up the number of workers to react to increased load. Because calls need to complete within the timeout of the client’s http requests, the system falls appart when latency increases due to load. This proposal intends to address these issues by introducing an RPC system which:\nmanages specialized workers automatically scales specialized workers Goals high priority the RPC protocol between editoast and core should be the same for development and production setups high priority requests are dispatched to specialized workers high priority the RPC system should be stateless and failure-resilient low priority the complexity of the local development setup should not increase Non-goals not a goal streaming events to the front-end not a goal reliable response processing not a goal caching Concepts flowchart TD client osrdyne worker-pool worker-group worker-group-queue worker worker-pool -- contains --\u003e worker-group worker-group -- contains and manages --\u003e worker client -- pub --\u003e worker-group-queue worker-group -- has a --\u003e worker-group-queue worker -- sub --\u003e worker-group-queue osrdyne -- manages --\u003e worker-pool osrdyne -- manages --\u003e worker-group osrdyne -- manages --\u003e worker-group-queue Client Clients submit RPC requests to the message queue. RPC requests are published using AMQP 0.9.1.\nFor example, editoast would be a client.\nWorker key Every submitted request includes a requested worker-key, as the message’s routing-key.\nThe key is what identifies which worker group will process the request.\nWorkers known their worker key at startup. All workers in a worker group have the same worker key. It is an arbitrary utf-8 string set by the client, whose meaning is not defined by the RPC protocol:\nIt could just be a way to have separate processing queues. In this case, workers may not care about what their is. There could be an extra layer of protocol between client and worker about how the key is meant to be interpreted Here are some examples of how such protocols may work:\nit could be the identifier of a resource to act upon: 42 it could be the identifiers of multiple resources: infra=42,timetable=24 it could even be, even though that’s probably not a good idea, random worker settings: log_level=debug Worker pools Worker pools are collections of workers of the same type, which can be specialized by key. osrdyne creates an exchange for each worker pool, where clients can submit requests.\nFor example, core would be a worker pool.\nWorker group Worker groups are collections of workers of the same pool and key, processing messages from the same queue. Worker groups are responsible for scaling the number of workers depending on queue length and processing rate.\nWorker groups are managed by osrdyne. osrdyne should support multiple worker group drivers:\na keda k8s driver a k8s autoscaler driver a docker driver a subprocess driver, where a single worker is started as a subprocess for each worker group a systemd template unit driver a noop driver, where workers have to be started manually For example, each core worker group handles a given infrastructure.\nWorker A worker is a server processing requests from its worker group queue. Worker have a key. For example, core workers are keyed by infrastructure.\nosrdyne manages all exchanges, policies, queues and bindings starts and stops worker groups as needed generates error responses if the worker group fails to respond Each osrdyne instance manages a worker pool. See the dedicated section.\nRPC protocol Client protocol Requests are submitted using AMQP 0.9.1’s basic.publish:\nAMQP field semantics exchange worker pool identifier routing-key requested key correlation-id an optional request id. The response will copy this field. reply-to property optional response queue mandatory true to ensure an error is returned if the message cannot be routed The body of the request will be dispatched to a worker of the requested pool and key. The request is guaranteed to be dispatched at least once\nThe response format is as follows:\nAMQP field semantics correlation-id the correlation ID from the request x-status property either ok, or the reason for dead lettering, taken from the request’s x-first-death-reason body optional response data Worker protocol When starting workers, the worker group driver provides:\nVariable name semantics WORKER_ID a unique identifier for this worker WORKER_KEY the worker key WORKER_POOL the name of the worker pool WORKER_REQUESTS_QUEUE the queue to consume work from WORKER_ACTIVITY_EXCHANGE the exchange to publish events to Workers then have to:\npublish a started activity report message subcribe to WORKER_REQUESTS_QUEUE using basic.consume for each request message: publish a request-received activity report message if the worker cannot process the request, it can request a requeue using basic.reject with requeue=true build and publish a response to the default exchange basic.ack the request Worker response protocol Responses are submitted using AMQP 0.9.1’s basic.publish:\nAMQP field semantics exchange worker pool identifier routing-key requested key reply-to property optional response queue Worker activity reports Workers report the following activity events:\nstarted: the worker is about to start processing requests request-received: a request was received AMQP field value exchange WORKER_ACTIVITY_EXCHANGE routing-key WORKER_KEY x-event property the event type Message passing architecture For a full reference of all exchanges and queues, see the exchanges and queues section\nMessage lifetime flowchart TD received processed received --\u003e requests received -- alternate exchange --\u003e orphans orphans -- controller starts worker group --\u003e requests requests -- dead letter --\u003e dlx dlx -- controller generates error --\u003e processed requests -- worker responds --\u003e processed Service architecture flowchart TD client subgraph RPC layer rabbitmq[RabbitMQ] osrdyne[osrdyne] end subgraph worker-group[worker group] worker end client -- enqueues --\u003e rabbitmq osrdyne -- sub orphan messages --\u003e rabbitmq osrdyne -- manages queues --\u003e rabbitmq osrdyne -- starts and stops --\u003e worker-group osrdyne -- sub activity events --\u003e rabbitmq worker -- sub requests --\u003e rabbitmq worker -- pub responses --\u003e rabbitmq worker -- pub activity events --\u003e rabbitmq osrdyne stops and starts worker groups following demand worker processes requests dequeued from rabbitmq Life of an RPC call In this example:\neditoast is the client it makes a request to the core worker pool the core worker pool is keyed on infrastructures Fast path Editoast publishes a request message to exchange=core with routing_key=42. If the message expects a reply, reply-to is set. If the core exchange already has binding for worker group 42, a worker picks up the request The worker processes the request, and uses the reply-to field to submit a response. The worker ACKs the request. Worker group startup These steps only occur if the worker group / queue has not yet started:\nIf there is no queue bound to routing key 42, the message is routed to the core-orphan-xchg exchange. This exchange is a fanout exchange with a single queue, where osrdyne processes messages. osrdyne processes the message: creates queue core-req-42, binds it to the core exchange on routing key 42 forward the message to exchange core ACK the original message once the original is forwarded start worker group core key 42 the worker group starts up and processes the request osrdyne architecture flowchart TD %% inputs activity-queue([activity queue]) orphan-queue([orphan queue]) dead-letter-queue([dead letter queue]) rabbitmq-api[RabbitMQ HTTP API] %% components orphan-processor[orphan processor] dead-letter-responder[dead letter responder] subgraph pool manager pool-state-tracker[pool state tracker] wgs-control-loop[worker groups control loop] req-queues-control-loop[request queues control loop] end wg-driver[worker group driver] %% outputs request-xchg([request exchange]) poison-inventory([poison request inventory]) response([response queue]) %% relations dead-letter-queue -- sub --\u003e dead-letter-responder --\u003e response \u0026 poison-inventory orphan-queue -- sub --\u003e orphan-processor -- forward --\u003e request-xchg orphan-processor -- request worker group start --\u003e pool-state-tracker orphan-processor -- wait for execution --\u003e req-queues-control-loop rabbitmq-api -- initial queue list --\u003e pool-state-tracker activity-queue -- worker activity --\u003e pool-state-tracker pool-state-tracker -- expected state --\u003e wgs-control-loop \u0026 req-queues-control-loop wgs-control-loop -- start / stop --\u003e wg-driver the pool manager is the most complex component of osrdyne. It is in charge of creating, deleting request queues, and deciding which worker groups should be running at any given time. To make such decisions, it needs:\nthe ability to list existing queues at startup, which is done using the RabbitMQ HTTP API worker activity events, to know which queues are active queue creation commands from the orphan processor The pool manager runs two control loops:\nthe worker groups control loop starts and stops worker groups using the worker group driver the request queues control loop creates and deletes request queues the orphan processor reacts to orphan messages by sending worker group start commands to the worker group manager\nthe dead letter responder:\nresponds errors to dead lettered messages following the worker protocol if a message is deemed to have caused repeated worker crashes, publish to the poison inventory On worker pool startup:\ncreate and bind all exchanges and queues configure the TTL, delivery timeout and delivery limit policies using the HTTP API start the orphan processsor, dead letter responder and worker group manager Exchanges and queues osrdyne creates a number of exchanges and queues. Most of the setup is done per worker pool, except for worker group request queues.\nWorker pool exchanges:\npool requests exchange {pool}-req-xchg, type direct: alternate exchange is {pool}-orphan-xchg dead letter exchange is {pool}-dl-xchg worker group request queues are bound to this exchange orphan exchange {pool}-orphan-xchg, type fanout dead letter exchange {pool}-dl-xchg, type fanout activity queue {pool}-activity-xchg, type fanout Worker pool queues:\ndead letter queue {pool}-dl, bound to {pool}-dl-xchg (exclusive) orphan queue {pool}-orphan, bound to {pool}-orphan-xchg (exclusive) worker activity queue {pool}-activity, bound to {pool}-activity-xchg poison queue {pool}-poison. Used to collect messages which could not be processed, supposedly due to worker crash Worker group queues:\nrequest queue {pool}-req-{key}, bound by key to {pool}-req-xchg Worker group manager The worker group manager has three internal components:\nthe pool state tracker tracks the expected status of worker groups the request queues control loop applies changes to worker group request queues the worker groups control loop applies changes to worker groups The state tracker assigns a 64 bit generation identifier to each expected state. The two control loops report the last synchronized state.\nWhen the orphan processor wants to start a worker group, it has to:\ntell the state tracker, which gives a generation identifier for the new expected state wait until the request queue control loop has caught up to this generation and has created the queue (which may be delayed due to networking issues) Pool state tracker stateDiagram-v2 Inactive --\u003e Active: received request Active --\u003e Unbound: unbind delay elapsed Unbound --\u003e Inactive: stop delay elapsed Unbound --\u003e Active: received request Two time constants govern how the expected state of worker groups evolves:\nUNBIND_DELAY delay until the queue transitions from Active to Unbound STOP_DELAY delay until the worker group is stopped The state tracker has the following API:\nenum WGStatus { Active, Unbound, } struct Generation(u64); struct PoolState { generation: Generation, wgs: im::OrdMap\u003cString, WGStatus\u003e, } trait PoolStateTracker { fn new(initial_worker_groups: Vec\u003cString\u003e) -\u003e Self; /// Require some worker group to be active. The extra lifetime adds active duration compared to the configured spooldown schedule. /// This allows the worker activity processor to debounce activity events without lowering the active time of worker groups. /// Returns the state generation where this worker group starts being active. async fn require_worker_group(\u0026self, key: \u0026str, extra_lifetime: Duration) -\u003e Generation; /// Subscribe to a stream of target pool state updates async fn subscribe(\u0026self) -\u003e tokio::sync::watch::Receiver\u003cPoolState\u003e; } Request queues control loop The request queue control loop takes care of creating, binding, unbinding and stopping request queues. It subscribes to the pool state tracker, and reacts to state changes.\nIt exposes the following API, which is used by the orphan processor to wait for updates to propagate:\nstruct ReqQueueStatus { expected: Option\u003cWGStatus\u003e, actual: Option\u003cWGStatus\u003e, } struct ReqQueuesState { generation: Generation, queues: im::OrdMap\u003cString, ReqQueueStatus\u003e, } trait RequestQueueControlLoop { fn new(target: tokio::sync::watch::Receiver\u003cPoolState\u003e) -\u003e Self; fn subscribe(\u0026self) -\u003e tokio::sync::watch::Receiver\u003cReqQueuesState\u003e; } it runs the following control loop:\nfetch the set of currently active request queues control loop: for each queue in expected and not in current: attempt to create the queue if successful, update the current set for each queue in current and not in expected: attempt to remove the queue, if empty and unused if successful, update the current set for each waiting orphan processor, release if the condition is met The control loop runs when current != expected, or when expected changes.\nWorker groups control loop osrdyne is responsible for starting and stopping worker groups following demand. It it NOT responsible for scaling the number of workers per worker group.\nosrdyne runs the following control loop:\nreceive the set of expected worker groups from the pool state tracker build the set of running worker groups: query running worker groups from the worker group driver. If this fails, log and continue to the next iteration of the control loop. make both sets converge: for each worker group in expected and not in running: use the docker / kubernetes API to start the worker group. This must be idempotent. do not retry 1 for each worker group in running and not in expected: use the docker / kubernetes API to attemps to stop the worker group. This must be idempotent. do not retry 1 Worker activity processor As the number of worker activity events could be very high, we may not want to forward all of these to the pool state tracker: if multiple messages are received within a short time span, only the first one is relevant. A separate actor can be used to receive and dedup activity messages, and forward a low bandwidth summary to the pool state tracker.\nFailure mode analysis The worker fails to parse a message This is an application layer error: the worker must respond, and indicate that something went wrong\nThe worker dies or stalls when processing a message RabbitMQ will wait until the message TTL expires, and re-queues it. A limit must be set on the number of times a message can be re-queued using a delivery-limit. When this limit is reached, the poison message is sent to the dead letter exchange, and the client times out.\nosrdyne fails to start If exchanges are not setup, the client cannot publish messages If the appropriate work group is operational, the fast path can proceed Otherwise, requests pile up in the orphan queue, and the client ends up timing out Invalid worker key Because the key is an arbitrary string set by the client, it has to be processed carefully:\nthe format is defined as a convention between the client and workers. If the format isn’t right, it is up to the worker to publish a response to the client. key validity conditions is also up to the worker: if the key is supposed to be some object ID, but the object does not exist, the worker needs to start up and respond Even if the key does not conform to the convention established between the client and the worker, the worker needs to start and respond to all requests.\nWorkers fails to start A per-queue message TTL should be set to avoid requests accumulating indefinitly.\nWorkers failing to start will cause:\nmessages to accumulate in the queue. when message TTL is reached, it will get transfered to the dead letter queue the client will time out awaiting a response Multiple ordyne daemons are started on the same pool It shouldn’t be an issue, as:\nall operations done on startup are idempotent before doing anything, the daemon has to start listening as an exclusive consumer of the dead letter and orphan queues Known limitations Latency, publisher confirms and reliability Without publisher confirms, networker or broken failure can result in message loss. However, publisher confirms add quite a bit of latency (about 200ms), as it ensures messages are persisted to disk if the queue is durable.\nWe should use publisher confirms for responses and orphan transfers, and leave the decision of whether to do it for requests to the client.\nAt least once semantics Most things in this protocol have at least once semantics if publisher confirms are used:\nrequest delivery to workers: if osrdyne is restarted while transfering an orphan to its destination, the orphan may be transfered twice response delivery to clients: if a worker takes slightly too long to ACK a message, but still responds, it may be requeued and re-processed, and thus responded to twice Design decisions Using RabbitMQ To implement this solution, we rely on a combination of features unique to RabbitMQ:\neach worker type needs a separate exchange and configuration when a message cannot be routed within a worker type’s exchange, it is redirected to an alternate exchange managed by the worker manager dead lettering is leveraged to generate protocol errors the worker manager uses the RabbitMQ HTTP API to list queues In addition to its attractive feature set, RabbitMQ has:\nvarious useful quality of life features, such as direct reply and per-message TTL long demonstrated its reliability multiple engineers on staff experienced with the tool Queues are created by osrdyne At some point, we explored the possibility of RPC clients creating queues. osrdyne would react to queue creation by starting workers. If the queue were to be unused for a while, osrdyne would stop workers and delete the queue.\nThis creates a race condition on queue deletion:\nosrdyne sees that the queue is empty the client ensures the queue is created osrdyne deletes the queue the client attempts to publish a message to the now deleted queue We thus decided to move the responsibility of queue management to the osrdyne, and implement a mechanism to ensure messages cannot be dropped due to a missing queue.\nosrdyne republishes orphan messages Initially, we though of a solution whereby osrdyne’s orphan processor uses dead lettering to send messages back to their original exchange. This is in fact a bad idea, as dead lettering inhibits per message TTL.\nInstead, the orphan processor has to proxy messages back to their original exchange. This proxying process can cause requests to get delivered multiple times to the target queue.\nosrdyne responds to dead lettered messages If a message is dead lettered for some reason (expired TTL, delivery limit, max queue length), we figured it would be best to give the client some idea that something went wrong.\nThe worker protocol thus has to allow the client to distinguish protocol errors from worker responses.\nMessages are only ACKed by workers once processed If messages are ACKed on reception:\nprocessing time is not limited by message timeout (which is arguably not a feature) the broker does not attempt re-delivery if the worker were to stop and not respond for some reason If messages are ACKed once processed:\nmessages whose processing time exceeds TTL will be re-queued, even if the worker is still processing the message. This can result in multiple responses being delivered. if the worker crashes or is stopped, the message will be re-queued We decided to rely on a delivery-limit policy to handle poison messages, and ACK messages once processed.\nReport worker activity using AMQP osrdyne needs to maintain queue usage statistics in order to know when worker groups can be stopped. At first, we considered having workers use valkey to store the timestamp of the last processed message for the queue. We decided against it as:\nit would mean the workers store a timestamp directly in database, read by a supervisor process. it’s a pretty bad design it adds an additional database to the RPC architecture, for little to no benefit compared to just using rabbitmq if one of the workers has its clock drift by more than the worker group expiration time compared to osrdyne, the worker group will get stopped any worker can get the pool deleted by forcing the timestamp to an old value it adds a failure mode: if osrdyne / workers are unable to reach valkey, weird bugs may ensue Instead, we decided to require worker to publish activity updates to a dedicated queue. This queue can be watched by osrdyne, which can use these events to know when to stop a worker group.\nMake worker group lifetime decisions in a separate actor The lifetime of worker groups is influenced by three types of asynchronous events:\nworker activity orphan requests worker group spooldown deadlines When the orphan processor gets a request, it needs to create the worker group’s request queue before it can proceed to forward the message.\nIf queues were created and deleted asynchronously when these events are received, it would introduce a race condition:\nthe orphan processor creates the queue the queue gets deleted because it expired at the same time the orphan processor forwards the message, which gets lost We found multiple solutions for this issue:\nprocess all asynchronous events in a single actor. This was not deemed viable because worker activity processing is work intensive, and orphan request processing is latency sensitive. having a single actor create and delete queues (the request queues control loop) and making the orphan processor wait until the control loop creates the queue Unbind the queue and wait before stopping workers In a previous design, we tried to delete work queue in one go. It created a race condition issue on queue deletion, caused by the fact ordyne does not get direct notifications of when messages are received on a work queue:\nwe decide to stop the worker group work is received on the queue, but we aren’t made aware as no worker is up we try to delete the queue, but cannot do so without loosing messages We could think of two fixes for this issue:\nimplement a two stage shutdown, where no work can get to the queue for a while before workers are stopped detect that the queue still has messages after workers have stopped, and start workers back up We decided to implement two stage worker group shutdown:\nif no activity is register for UNBIND_DELAY, unbind the work queue wait for a while to see if any worker picks up work from the queue and notifies osrdyne, which would rebind the queue if no orphan nor worker activity is registered for STOP_DELAY, stop workers and delete the queue The control loop is designed to make the state of all worker groups converge at once. Retrying convergence for one worker group adds latency to convergence for all worker groups. ↩︎ ↩︎\n","categories":"","description":"","excerpt":"TODO: create another document describing RPC interactions between core …","ref":"/en/docs/reference/design-docs/scalable-async-rpc/","tags":"","title":"Scalable async RPC"},{"body":"Open source is a software development practice, where the software’s source code1 :\nusually developed by multiple actors, in an open and transparent way free and available for all can be modified or used for derivative work by anyone can be freely distributed In practice, open source is both a legal framework for collaborative work, and a set of practices.\nOSRD and Open Source Applied to OSRD, Open Source has multiple avantages :\nthe algorithms and know-how developed with the project are free for all development cost and results are shared between actors it makes interoperability between software systems easier by helping make the landscape more homogeneous and standardized helps focus collaboration around common interests enables actors to tailor the software to their own interests enables researchers to contribute and benefit from the project it allows public actors to meet their transparency goals Using open source to enable industrial collaboration is not a new idea:\nBlender is a modelling, rendering and 3D animation software, which has recently become major point of industry collaboration for this industry Linux, a Windows alternative used by Google, Microsoft, Amazon, Apple, most websites, cloud platforms, mobile phones, routers, and more. All these companies rely on and contribute to Linux tremendously Android is the common base software for most phones. Phone manufacturers regularly contribute to android PostgreSQL, MySQL, SQLite and other open-source databases collectively dominate the database market. Any actor with special needs can improve an existing open-source tool rather than create a new one. Both Firefox and Chrome are Open Source Wordpress is the CMS which runs 43% of all websites. A flock of companies contribute to Wordpress and make extensions Odoo is a powerful modular ERP, which has a community not unlike Wordpress All these projects share the common property of being essential to a number of companies, without being part of what these companies sell.\nIt thus makes sense for these companies to collaborate with peers and competitors to build common tools, which makes exchanges easier and helps improve quality of service for all.\nProcesses These processes are not specific to open source: many companies work in a similar way. In practice, most open-source software is developed using a forge. Through this forge, developers and users can access the source code, report bugs, plan tasks, and integrate new changes to the code. Anyone can suggest a change, report a bug or plan a task.\nAll changes go through a peer review, not unlike those used by the scientific community. Reviewers are software developers most familiar with components affected by the change.\nChanges are integrated into the code base when everyone involved agrees to. Maintainers are responsible for keeping the project working and consistent. Maintainers are chosen among developers by developers. What motivates whether to integrate a change or not is technical viability: the goal of everyone involved is to maintain high level of service and quality standard.\nSource code is a set of text documents which describes how a piece of software works. It’s the result of the work of software developers. ↩︎\n","categories":"","description":"OSRD and Open Source","excerpt":"OSRD and Open Source","ref":"/en/about/opensource/","tags":"","title":"Open Source"},{"body":"L’open source est une pratique de développement logiciel, où le code source1 du logiciel est :\ngénéralement développé de manière ouverte et collaborative, par des acteurs variés accessible et gratuitement utilisable par tous tout le monde est libre de proposer un changement, ou créer un logiciel dérivé redistribuable par tous En pratique, l’open source est à la fois un cadre légal pour le travail collaboratif, et un ensemble de pratiques.\nApplication à OSRD Dans le contexte d’OSRD, ce modèle a de multiples avantages :\nles algorithmes et le savoir-faire développé est ouvert à tous les coûts de développement et résultats sont mutualisés entre les différents acteurs permet de faciliter l’interopérabilité entre systèmes d’information en facilitant la standardisation et l’uniformisation permet de catalyser la collaboration d’acteurs aux objectifs communs permet à chaque acteur d’adapter librement le logiciel à ses besoins il permet aux organismes de recherche publics de contribuer directement, et de profiter du projet il permet aux acteurs publics de répondre à leurs impératifs de transparence L’utilisation d’un projet open source comme catalyseur de collaboration industrielle a de nombreux antécédents :\nBlender est un outil de modélisation, rendu, et animation 3D très complet, qui est récemment devenu une plateforme de collaboration industrielle majeure pour l’industrie audiovisuelle Linux, une alternative à Windows qui équipe Google, Microsoft, Amazon, Apple, la plupart des sites internet, plateformes cloud, téléphones, routeurs, et bien plus. Toutes ces entreprises contribuent et se reposent énormément sur Linux Android est une base commune pour la majorité des téléphones vendus. Les fabriquants contribuent régulièrement à Android PostgreSQL, MySQL, SQLite et d’autres bases de donnée open source dominent collectivement ce marché. Un acteur aux besoins inédits peut contribuer à un outil open source plutôt qu’en créer un nouveau. À la fois Firefox et Chrome sont Open Source Wordpress est le CMS au coeur de 43% des sites internet en activité. Une armée d’entreprises contribuent et produisent des extensions Odoo est un ERP modulaire très complet, à la communauté similaire à Wordpress Toutes ces projets ont en commun d’être essentiel au business d’un grand nombre d’entreprises, sans pour autant être ce que l’entreprise commercialise.\nAinsi, ces entreprises décident de collaborer avec leurs pairs ou concurrents à des outils communs, afin de faciliter les échanges et d’améliorer la qualité de leur service.\nFonctionnement pratique Ce mode de fonctionnement n’est pas spécifique à l’open source : beaucoup d’entreprises adoptent un fonctionnement identique, à la différence près qu’il est maintenu privé. En pratique, les logiciels libre sont développés via une forge. Cette forge donne accès au code source, un outil de gestion des bugs / tâches, et un outil servant à intégrer des changements dans le code. Tout le monde peut proposer un changement, signaler un bug ou proposer une tâche.\nLes propositions de changement sont soumis à une revue par les pairs, semblables à celles de la communauté scientifique. Les individus en charge de la revue (les reviewers) sont ceux qui sont les plus familliers avec les composants affectés par le changement.\nLes changements sont intégrés par des mainteneurs sur la base du consensus entre reviewers. Les mainteneurs sont responsables de la cohérence technique du projet, et obtiennent cette position par consensus. L’intégration des changement n’est motivée que par leur viabilité technique : l’objectif des mainteneurs et reviewers est de s’assurer que le projet reste de bonne qualité.\nLe code source est un ensemble de documents texte qui définit comment fonctionne une application. C’est le produit du travail de développeurs logiciels. ↩︎\n","categories":"","description":"OSRD et l'Open Source","excerpt":"OSRD et l'Open Source","ref":"/fr/about/opensource/","tags":"","title":"Open Source"},{"body":"Cette section est destinée à exposer les principes généraux relatifs :\naux signaux aux régimes d’exploitation des lignes (à venir) aux différents systèmes d’espacement des trains La grande majorité des informations de cette section sont extraites du document pédagogique de l’Établissement Public de Sécurité Ferroviaire (EPSF) édité le 05 juillet 2017.\n","categories":"","description":"Les signaux, régimes d'exploitation des trains, et les systèmes d'espacement des trains","excerpt":"Les signaux, régimes d'exploitation des trains, et les systèmes …","ref":"/fr/docs/railway-wiki/signalling/","tags":"","title":"Signalisation"},{"body":"Open Data is the practice of making data public accessible under a permissive license. It is not the same as open source, which only applies to software.\nOpen data and open source have a symbiotic relationship : without open data, an open source railway software can only be used by industry insiders. Managing data access is hard, expensive, often not necessary, and reduces the availability of critical data.\nAlone, open data already brings a number of key benefits:\ncompanies can use open data in their products, which also promotes railway services researchers can study the data immediately, and can find the data by themselves Yet, open data used by an open source toolbox open up new prospects:\ncompanies and researchers can use the open source tools to analyse the data, which greatly reduces the barrier to entry by alleviating the need for custom or paid-for tools customers can use the toolbox to improve how they use railway services If multiple actors have open data exploitable by an open source tool, these datasets can be combined and used to provide and plan for common services.\nOSRD and Open Data having rolling stock and infrastructure open data enables anyone to simulate trains, study and evaluate the railway network having timetable open data enables anyone to study rail network usage ","categories":"","description":"OSRD and Open Data","excerpt":"OSRD and Open Data","ref":"/en/about/opendata/","tags":"","title":"Open Data"},{"body":"L’open data, c’est la pratique de rendre publiquement accessible des données sous une license permissive. C’est une pratique distincte de l’open source, qui ne s’applique qu’au logiciel.\nOpen data et open source ont une relation symbiotique : sans Open Data, un logiciel open source ferroviaire n’est utilisable que par des initiés. Gérer l’accès aux données est difficile, coûteux, souvent inutile, et réduit l’accessibilité de données pourtant essentielles.\nSeul, l’open data présente déjà un certain nombre d’avantages clés :\ndes entreprises peuvent utiliser ces données dans leur produit, ce qui promeut les services ferroviaires des chercheurs peuvent étudier les données sans démarche particulière, et découvrir eux-même les données disponibles Des données open data exploitées par une suite d’outils open source ouvrent de nouveaux horizons :\nles chercheurs et entreprises peuvent maintenant exploiter les données sans avoir à créer leurs propres outils, ou en acquérir par leurs propres moyens les clients de l’entreprise peuvent utiliser outils et données pour améliorer leur usage des services Si plusieurs acteurs mettent en open data des données exploitables par un même logiciel open source, il devient également possible de recouper les données et de fournir et plannifier des services communs.\nDans le cadre d’OSRD si les données de matériel roulant et d’infrastructure sont en open data, alors il est possible pour tous de simuler des trajets, d’étudier et évaluer le réseau ferroviaire si les données de grilles horaires sont accessibles en open data, alors il est possible pour tous d’étudier l’usage du réseau ","categories":"","description":"OSRD et l'Open Data","excerpt":"OSRD et l'Open Data","ref":"/fr/about/opendata/","tags":"","title":"Open Data"},{"body":"Here’s a list of the big features OSRD wants to support. The order of items depends on priority (the higher the item, the more valuable it is). This roadmap is spread over a couple of years.\nAdd ERTMS signaling system support. A fine-grained permission system. Support cyclic train schedule. Improving Netzgrafik-Editor integration. Send STDCM trains to external services for storage and processing. Create annual transport plan service. Support a linear referencing LRS commonly used in the railway industry. Usage of railway mileposts. Revamp the infrastructure editor. New dynamic simulator. Simulate a timetable on an infrastructure and observe generated delays. Versioning infrastructures. Revamp train simulation v3. If you’d like to push for one of these features, or if you have ideas for what OSRD could do in the future, don’t hesitate to join the project!\n","categories":"","description":"Macroscopic Roadmap","excerpt":"Macroscopic Roadmap","ref":"/en/about/roadmap/","tags":"","title":"Roadmap"},{"body":"Voici une liste des principales fonctionnalités que OSRD souhaite ajouter, par ordre de priorité. Cette feuille de route s’étale sur plusieurs années.\nAjout du système de signalisation [ERTMS] (https://fr.wikipedia.org/wiki/Syst%C3%A8me_europ%C3%A9en_de_gestion_du_trafic_ferroviaire). Système de permission fin. Support du cadencement des trains. Améliorer l’intégration de Netzgrafik-Editor. Envoyer des trains STDCM à des services externes pour stockage et traitement. Création d’un plan de transport annuel. Support d’un système de référencement linéaire LRS couramment utilisé dans l’industrie ferroviaire. Utilisation de point kilométrique. Refonte de l’éditeur d’infrastructure. Ajout d’un simulateur dynamique. Simuler une grille horaire sur une infrastructure et observer les retards générés. Gestion de version des infrastructures. Refonte du calcul de marche. Si vous souhaitez pousser l’une de ces fonctionnalités, ou si vous avez des idées sur ce que OSRD pourrait faire à l’avenir, n’hésitez pas à rejoindre le projet !\n","categories":"","description":"Roadmap macroscopique","excerpt":"Roadmap macroscopique","ref":"/fr/about/roadmap/","tags":"","title":"Roadmap"},{"body":"Les trains doivent circuler en toute sécurité. Les risques majeurs liés aux circulations ferroviaires sont les suivants :\nle rattrapage des trains qui circulent dans le même sens sur la même voie ; la prise en écharpe, c’est-à-dire la collision latérale de trains qui circulent sur des itinéraires convergents ; le nez à nez, c’est-à-dire la collision frontale de trains qui circulent en sens contraire sur la même voie ; le déraillement ; la collision avec un obstacle. On prévient ces risques notamment par :\nla mise en place d’une signalisation ; l’établissement d’un régime d’exploitation de la ligne (double voie, voie banalisée, voie unique) ; la mise en place d’un système d’espacement des trains ; la mise en oeuvre de procédures d’exploitation. D’autres dispositifs techniques contribuent également à couvrir ces risques tels que :\nles installations de sécurité, notamment les enclenchements des postes d’aiguillage ; le DAAT qui est un dispositif permettant d’assurer l’arrêt automatique des trains en cas de franchissement intempestif d’un point d’information avec signal d’arrêt fermé ; le KVB, le COVIT (TVM) sont des exemples de systèmes de contrôle de la vitesse, avec contrôle de franchissement des signaux non franchissables ; le système de contrôle commande des trains, intégré dans l’ETCS. La sécurité des circulations repose aussi sur le respect rigoureux des consignes et instructions opérationnelles par tous les agents concernés par la circulation des trains.\nCes procédures sont de la responsabilité des exploitants ferroviaires. Elles sont décrites dans le manuel du système de gestion de la sécurité (SGS) qu’ils établissent et qui fait l’objet d’une instruction par l’EPSF chargé de délivrer le certificat ou l’agrément de sécurité.\n","categories":"","description":"","excerpt":"Les trains doivent circuler en toute sécurité. Les risques majeurs …","ref":"/fr/docs/railway-wiki/signalling/risks/","tags":"","title":"Les risques ferroviaires"},{"body":"Principe Pour transmettre au conducteur des ordres et informations liées à la sécurité des circulations, il est fait usage de signaux. Ces signaux peuvent indiquer des informations relatives aux limites de vitesse, peuvent servir à garantir l’espacement des trains ou donner des indications diverses telles que l’accès à des voies de service, des ouvrages d’art à gabarit réduit, etc.\nLa signalisation à main La signalisation au sol La signalisation au sol est normalement implantée à gauche ou au-dessus de la voie concernée.\nSignaux de protection Les signaux de protection sont destinés à interdire l’accès à un itinéraire, à une aiguille, à un PN, etc. Ils sont généralement manœuvrés depuis des postes par des agents de SNCF Réseau.\nSignaux de cantonnement Les signaux de cantonnement sont destinés à assurer l’espacement des circulations de même sens.\nSur les sections de lignes équipées en block automatique (BA), les signaux de cantonnement se ferment automatiquement dès l’occupation du canton et restent fermés jusqu’à sa complète libération.\nSur les sections de lignes équipées en block manuel (BM), les signaux de cantonnement sont manœuvrés depuis des postes par des agents du service du GI chargé de la gestion des circulations.\nSignaux d’annonce d’arrêt Le carré, le sémaphore et le feu rouge clignotant sont normalement annoncés à distance par un avertissement qui peut lui-même être précédé, en signalisation lumineuse, par un feu jaune clignotant.\nToutefois, les signaux qui ne peuvent être abordés qu’en marche à vue ou en marche en manœuvre ne sont normalement pas annoncés (par exemple, le guidon d’arrêt). Il en est de même des signaux situés sur voie principale à la sortie des gares en impasse.\nSignaux d’indication de marche Le feu vert indique au conducteur que la circulation en marche normale est autorisée, si rien ne s’y oppose.\nSur les sections de ligne où la vitesse des trains est supérieure à 160 km/h, un feu vert clignotant précède généralement l’avertissement ou le feu jaune clignotant.\nSignaux de limitation de vitesse Ils limitent à un taux déterminé la vitesse des trains sur une partie de voie ou au franchissement de certains points particuliers (aiguille, traversée de gare, etc.).\nLes limitations permanentes de vitesse (en complément de celles pouvant figurer dans les RT) Sur des parties de voie par tableau indicateur de vitesse (TIV) ordinaire Au franchissement de certains points particuliers (exemple des aiguilles)\nRalentissement à 30 km/h en signalisation lumineuse Ralentissement à 60 km/h en signalisation lumineuse TIV mobiles Ces tableaux peuvent être lumineux ou mécaniques ; lorsqu’ils sont ouverts ils présentent une bande verticale blanche continue.\nSi cela est nécessaire, l’emplacement de l’aiguille (ou de la première aiguille dans le cas d’aiguilles successives) est repéré par un chevron pointe en bas.\nLes limitations temporaires de vitesse Cette signalisation s’applique sur des parties de voie (chantiers de travaux, etc.) sur lesquelles une limitation temporaire de vitesse doit être observée.\nSignaux indicateurs de direction Ils renseignent les conducteurs sur la direction géographique qui leur est donnée.\nSignaux caractéristiques de prescriptions particulières Ils renseignent les conducteurs sur des particularités.\nOn trouve :\ndes tableaux des pancartes la bande lumineuse jaune la croix de Saint-André (annulation des signaux) Exemples de tableaux Exemples de pancartes Bande lumineuse jaune horizontale La bande lumineuse jaune horizontale est utilisée en complément de l’avertissement. Elle indique au conducteur que son train est dirigé vers une voie à quai de courte longueur ou bien que sa longueur se trouve réduite.\nCroix de Saint-André (annulation des signaux) Signalisation de sortie de certains faisceaux ou groupes de voies convergentes Elle peut être constituée de :\nLa signalisation de cabine Sur les lignes à signalisation de cabine, le système transmet de manière continue (ou discontinue) en cabine de conduite des ordres et une consigne de vitesse associée éventuellement à une distance but. La signalisation de cabine peut être complétée par une signalisation au sol dans certains cas pour :\nrepérer les points à ne pas dépasser, par exemple : donner des ordres de traction électrique, des informations aux points d’entrée et de sortie du domaine de signalisation de cabine, etc. Des pancartes ou tableaux indiquent ces ordres et informations.\nCes repères, pancartes ou tableaux sont implantés :\nà gauche de la voie sur les plateformes à une seule voie ; côté piste, à l’extérieur sur les plateformes à deux voies ; dans le cas de plan de voie plus complexe, les pancartes ou tableaux sont fléchés. Nota : les repères ETCS et de la TVM ne sont pas fléchés du fait de leur graphisme indiquant la voie à laquelle ils s’adressent.\nPoint de transition de signalisation (entrée sur LGV, armement de la signalisation de cabine) Le point de transition de signalisation (tableau CAB), ainsi que l’armement de la signalisation de cabine, se situent à hauteur ou immédiatement en aval du dernier signal au sol (signal carré).\n","categories":"","description":"","excerpt":"Principe Pour transmettre au conducteur des ordres et informations …","ref":"/fr/docs/railway-wiki/signalling/signals/","tags":"","title":"Les signaux"},{"body":"Définition Ensemble des règles d’exploitation, c’est-à-dire des règles appliquées pour organiser et assurer le trafic, propres à une ligne en fonction des installations mises en œuvre pour en assurer l’exploitation.\nLes principaux régimes d’exploitation sont : la voie unique, la voie banalisée, la double voie.\nPrincipe Il ne faut pas confondre régime d’exploitation et nombre de voies sur une plateforme, car il existe des plateformes à 2 voies qui ne sont pas des « double voie », des plateformes à 3 ou 4 voies qui sont des « double voie », des plateformes à 1 seule voie qui ne sont pas des « voie unique ».\nLes appellations et définitions de ces régimes d’exploitation sont donc très importantes, car elles entraînent notamment des contraintes particulières de conduite que ce soit en situation normale ou dégradée (implantation des signaux, marche à vue ou règle spéciale de certains signaux par exemple).\nEn voie unique, l’organisation de la circulation des trains des deux sens sur une même voie génère un risque spécifique de nez à nez en plus du risque de rattrapage également présent sur les lignes à double voie.\nL’exploitation sous le régime de la « double voie » permet, par conception, d’éviter le risque de nez à nez, compte tenu de l’affectation des trains à un sens de circulation par voie. Cependant sur certaines lignes, la circulation des trains s’effectue selon l’un des deux régimes suivants : la voie unique ou la voie banalisée.\n","categories":"","description":"","excerpt":"Définition Ensemble des règles d’exploitation, c’est-à-dire des règles …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/","tags":"","title":"Les régimes d’exploitation des lignes"},{"body":"Définition Le système d’espacement des trains de même sens, est destiné à éviter les rattrapages et consiste à fractionner la ligne en plusieurs cantons dont l’entrée est protégée par un signal d’arrêt.\nPrincipe Compte tenu de leur masse importante, de leur vitesse élevée, de la faible adhérence rail-roue, les trains ont besoin d’une distance importante pour s’arrêter.\nDe ce fait, la distance nécessaire pour obtenir l’arrêt est généralement plus grande que la partie de voie visible par le conducteur. Dans ces conditions, le conducteur d’un train en marche ne voyant pas à temps la queue d’un train arrêté ou circulant à plus faible vitesse devant lui risquerait de le heurter.\nPour prévenir le risque de rattrapage : un dispositif d’espacement des trains appelé « cantonnement » est mis en place selon les principes suivants :\nla ligne est divisée en portions de voie appelées « cantons » l’entrée de chaque canton est normalement commandée par un signal un seul train est normalement admis dans chaque canton aucun train ne peut normalement pénétrer dans un canton occupé, du fait du maintien à la fermeture du signal d’entrée du canton durant tout le temps de son occupation Dans certains cas particuliers, la pénétration d’un train dans un canton occupé ainsi que les modalités de franchissement du signal d’entrée du canton sont prévues dans une procédure propre à chaque mode de cantonnement.\nLes différents modes de cantonnement On distingue :\nle cantonnement téléphonique le block manuel par appareils (BM) le block automatique : lumineux (BAL) ou à permissivité restreinte (BAPR) l’ETCS 1 généralement superposé à la signalisation au sol l’espacement sur lignes à grande vitesse (TVM, ETCS 2) Sur les sections de lignes équipées en cantonnement téléphonique ou en block manuel par appareils, les signaux de cantonnement sont manoeuvrés au sol ou depuis des postes par des agents du service du gestionnaire d’infrastructure (GI) chargé de la gestion des circulations dénommés « gardes ».\nSur les sections de lignes équipées en BAL ou BAPR, les signaux de cantonnement se ferment automatiquement dès l’occupation du canton et restent fermés jusqu’à sa complète libération.\nSur les sections de lignes à signalisation de cabine, équipées en TVM ou ETCS, les informations liées à l’espacement des trains sont données au conducteur automatiquement directement en cabine de conduite.\nPour déterminer le mode et le cas échéant les postes de cantonnement d’une section de ligne, il faut consulter les RT.\n","categories":"","description":"","excerpt":"Définition Le système d’espacement des trains de même sens, est …","ref":"/fr/docs/railway-wiki/signalling/spacing/","tags":"","title":"Les systèmes d'espacement des trains"},{"body":"Elles sont principalement exploitées selon les dispositions du régime général d’exploitation de la voie unique, certaines d’entre elles disposant d’un minimum d’équipement de signalisation sont désignées « voie unique à signalisation simplifiée ».\nD’autres lignes, peu fréquentées et fermées au service voyageur sont exploitées selon le régime de la voie unique à trafic restreint.\nIl existe aussi un régime d’exploitation en navette.\nEnfin d’autres lignes disposant d’installations de sécurité s’opposant notamment au nez à nez sont exploitées selon le régime de la voie banalisée.\n","categories":"","description":"","excerpt":"Elles sont principalement exploitées selon les dispositions du régime …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/","tags":"","title":"Les lignes à une seule voie"},{"body":"Définition Régime d’exploitation d’une ligne à deux voies (ou plus) dans lequel chaque voie est normalement affectée à la circulation des trains dans un sens déterminé.\nPrincipe Le risque de nez à nez Sur une ligne à deux voies, les circulations empruntent normalement la voie de gauche dans le sens de la marche (voie de droite sur les lignes désignées à la documentation d’exploitation).\nLa double voie est exploitée selon les modalités définies par SNCF Réseau qui prévoit que chaque agent du service de la gestion des circulations doit disposer en temps utile des informations nécessaires pour assurer le service de la circulation des trains, notamment les informations relatives à l’ordre théorique et réel de succession des trains, à l’horaire et aux voies de circulation des trains.\nDans certains cas, il peut être nécessaire (travaux, incidents, etc.) d’organiser la circulation des trains des deux sens sur une seule voie. Les circulations se déplaçant sur une voie en sens inverse du sens normal sont dites à « contresens » sur une installation de contre sens (ICS) ou sur une voie unique temporaire (VUT). Elles sont dites à « contre-voie » dans les autres cas.\nEn fonction des installations et équipements en place :\nutilisation d’installations qui s’opposent au nez à nez : installation de contre sens (ICS) : installations permanentes de contre sens (IPCS) ou installations temporaires de contresens (ITCS) ; voie unique temporaire à caractère permanent (VUTP) ; ou mise en place de procédures : voie unique temporaire (VUT) ; mouvement à contre voie. Le risque de rattrapage L’espacement est assuré selon les principes définis dans cette section. Sur une voie les signaux sont normalement implantés à gauche.\n","categories":"","description":"","excerpt":"Définition Régime d’exploitation d’une ligne à deux voies (ou plus) …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/","tags":"","title":"La double voie"},{"body":"Context The onboard computer of ETCS-enabled trains has to compute a number of position / speed curves. Here is how it works:\nbelow all the curves, the speed indicator is white above the indication curve, the speed indicator is yellow above the permitted curve, the speed indicator is orange above the warning curve, an alarm rings above the intervention curves, an emergency break intervention is triggered Inputs In order to compute any of these curves, a number of things are needed:\ntarget data (the destination of the braking curve, which can be EOA and SvL or LOA and MRSP) train data infrastructure data infrastructure manager constants standardized constants Train max speed length rotating mass T_traction_cutoff: the time it take to cut off traction braking model, either lambda or gamma: lambda (braking weight/mass) gamma (contant deceleration at a given speed) correction factors (k_dry and k_wet for gamma braking) for braking curves Infrastructure corrected gradients (it incorporates curvature) odometry balises location Processes Braking coefficients: A_brake_emergency is the expected emergency braking capability, without safety margins A_brake_safe is the emergency braking coefficient, with safety margins A_brake_service is the expected service braking capability, without safety margins Speed / distance targets EOA end of movement authority: the location until which the train is allowed to move SvL supervized location: the protected location Curves SBD supervised braking deceleration: intermediary result computed from EOA and A_brake_service EBD emergency braking deceleration: intermediary result computed from SvL and A_brake_safe All the curves below are cut below a given release speed:\nEBI (emergency break intervention) computed from EBD, shifted in position and space given rolling stock metadata SBI1 computed from SBD, shifted in time with Tbs1 SBI2 computed from SBD, shifted in time with Tbs2 FLOI (also called SBI, the intervention curve) the minimum of SBI1 and SBI2 WARNING (warning curve) computed as a shift of FLOI by Twarning PS (permitted speed curve): shift of WARNING by time Tdriver INDICATION is a shift of PS by time Tindication ","categories":"","description":"European Train Control System","excerpt":"European Train Control System","ref":"/en/docs/railway-wiki/signalling/spacing/ertms/etcs/","tags":"","title":"ETCS"},{"body":"Généralités ETCS est le système européen de contrôle commande des trains. La partie bord est interopérable. La partie sol peut être différente selon les pays tout en répondant aux mêmes objectifs de fonctionnalité.\nIl existe quatre niveaux différents dont deux sont en service : L’ETCS 1 et L’ETCS 2. L’ETCS 0 est interdit en France. L’ETCS 3 est encore à l’état de développement dans la plupart des pays de l’Union européenne.\nIl s’agit d’un système de signalisation de cabine et de contrôle de vitesse faisant appel aux trois composantes suivantes :\nsol : pour la gestion des circulations comprenant notamment l’espacement, la protection des points à protéger et des circulations bord : pour l’affichage des ordres et informations à destination du conducteur et le contrôle de la bonne exécution de ceux-ci, dénommé EUROCAB liaison : pour les échanges de données entre le sol et le bord : liaison ponctuelle unidirectionnelle du sol vers le bord par EURO BALISES, liaison radiotéléphonique continue et bidirectionnelle par GSM-R DATA pour ETCS2 dénommé EURORADIO. Sur le RFN, sont mis en oeuvre les niveaux d’exploitations suivants :\nL’ETCS1 sur certaines lignes parcourables jusqu’à 220 km/h. Il correspond à un système de signalisation de cabine, généralement superposé à la signalisation au sol existante, dont les informations entre le sol et le bord sont transmises ponctuellement par eurobalise.\nL’ETCS2 sur certaines lignes à grande vitesse. Il correspond à un système de signalisation de cabine dont les informations entre le sol et le bord sont transmises en temps utile ou cycliquement par liaison permanente GSM-R DATA.\nL’ETCS2 est un système qui ne nécessite pas la matérialisation des cantons sur le terrain.\nPréalablement à tout déplacement, les données relatives au train doivent être saisies ou paramétrées à bord. Ainsi, le système peut, à partir des données bord et sol, superviser le train, c’est-à-dire contrôler sa vitesse et ses déplacements et intervenir en cas de nécessité.\nLa détection d’une circulation sur une partie de voie est réalisée au moyen de circuits de voie ou de compteurs d’essieux. En ETCS2, la combinaison des équipements sol et bord est telle qu’elle ne nécessite, normalement, pas de signalisation complémentaire au sol.\nÉquipement bord Le bord est constitué d’un DMI, d’un EVC, de capteurs odométriques (de vitesse), d’antennes pour la lecture des PI ETCS, un modem GSM-R (Euroradio) pour ETCS2, d’une unité juridique d’enregistrement des paramètres d’exploitation, d’interfaces avec le train.\nLe DMI Le DMI est l’interface entre le conducteur et la machine. Il permet d’afficher les ordres et instructions en fonction des données sol et/ou bord. Le conducteur renseigne également le système par saisie de données.\nL’espacement des circulations et la protection des points dangereux se traduisent par l’affichage en temps utile d’une vitesse but et d’une distance but. La vitesse but doit être respectée par le conducteur au point défini par la distance but.\nEn « marche normale », le DMI indique au conducteur la vitesse autorisée qui ne doit pas être dépassée. Dans ce cas, il n’y a pas d’affichage de la distance but et de la vitesse but.\nUn secteur pouvant présenter différentes couleurs est utilisé pour indiquer les ordres de vitesse ou d’arrêt.\nEnfin, d’autres indications sont affichées telles que la signalisation de traction électrique, le niveau d’exploitation, le mode technique. Les changements d’indication au DMI peuvent être accompagnés d’indications sonores. Une zone en partie basse du DMI est également réservée pour l’affichage de messages textuels. Certaines informations complémentaires peuvent également être affichées par l’entreprise ferroviaire.\nDans cet exemple, le conducteur autorisé à circuler à 140 km/h maximum, circule à 125 km/h, il va devoir observer une phase de ralentissement afin de respecter la vitesse maxi de 100 km/h (vitesse But) à une distance de 2850 mètres (distance But).\nLe DMI utilise un code couleur, avec la signification suivante :\nblanc/gris clair/gris foncé : aucune action immédiate n’est exigée du conducteur jaune : le conducteur doit intervenir si la vitesse réelle est proche de la vitesse autorisée (risque de passer à la couleur orange en l’absence de réaction) orange : l’intervention est insuffisante (risque de passer à la couleur rouge en l’absence de réaction du conducteur) rouge : réaction trop tardive du conducteur, prise en charge par le système (peut revenir au jaune, au gris ou au blanc après une action appropriée) ETCS niveau 1 Transmission sol-bord Ce niveau utilise une transmission ponctuelle à l’aide de balises placées au pied des signaux et en amont. Ces balises (eurobalises) communiquent les données de signalisation au train.\nDétection des trains Le niveau 1 nécessite l’utilisation d’un système de détection des trains au sol (tel que des circuits de voie, compteurs d’essieux et autres). Toutes ces informations sont donc transmises ponctuellement au train. La cadence de l’information donnée pouvant être augmentée en jouant sur le nombre de balises, ou en installant une boucle (euroloop), équivalent d’une balise, mais longeant la ligne sur une certaine distance.\nETCS niveau 2 Transmission sol-bord Les données de signalisation sont transmises de manière permanente, via le réseau GSM-R. Le train communique constamment sa position (qu’il détermine avec un odomètre) au centre de contrôle qui lui communique en retour les actions à effectuer (vitesse, arrêt, etc.).\nDes eurobalises sont toujours présentes sur la voie pour recaler éventuellement l’odométrie embarquée.\nDétection des trains Un système de détection des trains au sol s’appuie sur l’existence des circuits de voie pour localiser un train aval sur un canton. Cette information est transmise au radio block center (RBC) qui gère ensuite l’espacement entre deux circulations. Le train suiveur reçoit une nouvelle autorisation de circulation par l’intermédiaire de la liaison radio GSM-R. Dès que le train aval libère un canton le poste central de commande reçoit l’information correspondante du sol qui est transmise par liaison radio au train suiveur.\nAvantage Le niveau 2 rend disponible quasi immédiatement une information « libératoire » pour le train suiveur et contribue ainsi à augmenter la fluidité. Cette immédiateté est la différence par rapport à la signalisation conventionnelle, où une demi-minute est parfois nécessaire pour libérer un aiguillage alors que le train est déjà bien loin.\nLes modes techniques Les modes techniques utilisés sur le RFN sont :\nMode FS : Conduite en supervision complète.\nToutes les données train et voie sont disponibles à bord.\nLe DMI affiche :\nla vitesse réelle du train et la vitesse autorisée lors de l’approche d’un EOA, d’un repère d’arrêt ETCS ou un heurtoir, la vitesse but et la distance but Le système « bord » supervise la vitesse, le déplacement du train, le respect de l’EOA matérialisé par un repère d’arrêt ETCS, un signal d’arrêt ou un heurtoir en ETCS1.\nMode OS : Conduite en marche à vue.\nToutes les données train et voie sont disponibles à bord sauf l’assurance de la libération de toute ou partie de la voie allouée au train.\nLe DMI affiche les mêmes indications qu’en mode FS.\nLe système « bord » assure également la supervision comme en mode FS.\nMode SR : Conduite sous la responsabilité des agents.\nCe mode technique est utilisé pour les situations dégradées et la procédure « Mise en service » lorsque le bord n’a pas reçu d’allocation de voie. Le système « bord » ne supervise que la vitesse du mode SR et le franchissement des repères d’arrêt ETCS et des signaux d’arrêt.\nMode SH : Circulation en manœuvre.\nCe mode technique est sélectionné par le conducteur pour les mouvements de manœuvre. Le système « bord » ne supervise que la vitesse du train.\nMode NL : Conduite d’un engin moteur non en tête du mouvement\nCe mode technique est utilisé en cas de pousse ou de double traction.\nProtection contre le rattrapage En mode FS, une vitesse autorisée affichée sans la présentation de l’EOA signifie « marche normale ».\nLa MA constituée d’un ou plusieurs cantons est allouée canton par canton, par ajout successif d’un canton. Si le canton en aval du dernier canton alloué est occupé le train doit être en mesure de s’arrêter avant l’entrée de ce canton. Le conducteur est alors avisé par une indication sonore au DMI.\nDès lors, les indications de conduite (vitesse but égale à 0 et une distance but) permettant de respecter la courbe de freinage sont affichées.\nLe conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.\n","categories":"","description":"European Train Control System","excerpt":"European Train Control System","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/etcs/","tags":"","title":"ETCS"},{"body":"1. Les installations permanentes de contresens (IPCS) Principe Certaines sections de ligne comportent des installations permanentes de contresens (IPCS). Ces installations accessibles sans arrêt des trains à l’entrée, permettent à tout moment la circulation des trains à contresens sans que les conducteurs en soient préavisés autrement que par la signalisation.\nLe risque de nez à nez Des enclenchements de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre.\nLe risque de rattrapage L’espacement des trains circulant dans le sens normal est assuré dans les conditions habituelles.\nL’espacement des trains à contresens est assuré automatiquement.\nAvis au conducteur Les sections de ligne équipées d’IPCS sont désignées aux RT.\nLa circulation (entrée et sortie) sur IPCS est indiquée au conducteur par la signalisation.\n2. Les installations temporaires de contresens (ITCS) Principe L’ITCS est un régime temporaire d’exploitation permettant en double voie de faire circuler sur une voie des trains en sens inverse du sens normal.\nCes installations, accessibles sans arrêt des trains à l’entrée, permettent à tout moment la circulation des trains à contresens. Elles sont installées en prévision de chantier de travaux qui vont nécessiter l’obstruction d’une des deux voies.\nLe risque de nez à nez Des enclenchements de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre.\nLes ITCS ont leurs extrémités dans les gares les plus rapprochées encadrant le chantier de travaux prévu ou bien dans des postes de pleine voie existants ou créés à cet effet, considérés dès lors comme des gares. Si le chantier se déplace, les extrémités de l’ITCS sont reportées au fur et à mesure de la progression du chantier par phases successives, chaque phase faisant l’objet d’une ITCS distincte.\nLe risque de rattrapage L’espacement des trains circulant dans le sens normal est assuré dans les conditions habituelles.\nL’espacement des trains à contresens est assuré automatiquement.\nAvis au conducteur Les informations nécessaires aux conducteurs sont fournies par le gestionnaire d’infrastructure aux entreprises ferroviaires. Les particularités de signalisation et d’exploitation de l’ITCS sont mentionnées.\nUn schéma adapté à ses besoins peut compléter ces informations.\nLa circulation (entrée et sortie) sur ITCS est indiquée au conducteur par la signalisation.\n3. Circulation à contresens sur une ICS L’entrée d’un parcours à contresens sur une ICS est repérée par un tableau lumineux d’entrée à contresens (TECS). Ce tableau, normalement éteint, est groupé avec le panneau qui porte le carré protégeant l’aiguille d’entrée.\nExemple d’entrée à contresens à 60 km/h sur une section de ligne où la circulation normale se fait à gauche\nLes signaux s’adressant aux conducteurs des trains circulant à contresens sont :\nimplantés à droite (disposition inverse sur les lignes où la circulation se fait normalement à droite) ; répétés sur les engins moteurs. Les ICS peuvent comporter à contresens un ou plusieurs cantons.\nLa sortie d’un parcours à contresens est repérée par un tableau lumineux de sortie de contresens (TSCS). Ce tableau est groupé avec le panneau qui porte le signal « carré » protégeant l’aiguille de sortie.\n","categories":"","description":"","excerpt":"1. Les installations permanentes de contresens (IPCS) Principe …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-direction-installations/","tags":"","title":"Les installations de contresens (ICS)"},{"body":"Définition Régime d’exploitation d’une ligne dans lequel les trains des deux sens circulent sur la même voie, les dispositions à prendre pour éviter la rencontre de deux trains de sens contraire ne sont pas automatiques, mais résultent de procédures à appliquer par les personnels affectés à la circulation des trains, voire par les personnels des trains dans certains cas de lignes faiblement équipées. Ces dispositions sont définies par le gestionnaire d’infrastructure.\nPrincipe Le risque de nez à nez Les documents horaires sont conçus en respectant des obligations fondamentales telles que le croisement obligatoire de deux trains en gare, qui permettent d’éviter le nez à nez pour les trains de sens contraires.\nCe risque est donc avant tout couvert par le respect de l’ordre normal de circulation des trains figurant aux documents horaires.\nEn effet, le principe d’exploitation d’une ligne à voie unique s’effectue selon des modalités définies par le gestionnaire d’infrastructure, qui prévoient notamment le respect absolu de l’ordre théorique de succession des trains et en conséquence de l’ordre chronologique d’occupation de la voie unique. Une circulation qui n’est pas à son ordre, ne peut occuper la voie unique sans procédure.\nEn cas de modification de l’ordre théorique (retard, train supprimé, etc.), des procédures permettent d’organiser le nouvel ordre de circulation des trains (procédures de reports de croisement, dépassements, etc.).\nLe respect des procédures reposant sur l’humain, certaines lignes sont équipées d’une « barrière » technique de sécurité le block manuel de voie unique (BMVU - voir 4.4.2.). Des moyens d’arrêt complémentaires (DAAT, GSM/GFU, RST, coupure d’urgence si la ligne est électrifiée, …) peuvent être utilisés ou mis en place afin de réduire les conséquences d’une erreur humaine. Le risque de rattrapage Le risque de collision par rattrapage est couvert par le mode de cantonnement. Les différents modes de cantonnement existants sont :\nle cantonnement téléphonique (Voir - 4.3.) ; le cantonnement assisté par informatique (CAPI - voir 4.3.) ; le cantonnement assisté par informatique initié en 1995 (CAPI 95 - voir 4.3.) ; le block manuel de voie unique (BMVU - voir 4.4.2.). ","categories":"","description":"","excerpt":"Définition Régime d’exploitation d’une ligne dans lequel les trains …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track/","tags":"","title":"La voie unique"},{"body":"","categories":"","description":"Global System for Mobiles - Railways","excerpt":"Global System for Mobiles - Railways","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/gsm-r/","tags":"","title":"GSM-R"},{"body":"Définition Certaines lignes à voie unique sont désignées à la documentation d’exploitation comme « Lignes à voie unique à signalisation simplifiée ». Par rapport au régime général de la voie unique, ce type de ligne se distingue par la mise en œuvre d’un minimum d’équipements. Ils se limitent à une pancarte « gare » à distance et à un repère d’entrée.\nPrincipe Le risque de nez à nez Elles sont exploitées selon les modalités du régime général d’exploitation de la voie unique (notamment le respect de l’ordre théorique de circulation).\nLeur fonctionnement repose en outre sur l’arrêt général des circulations dans toutes les gares.\nLe risque de rattrapage La gestion de l’espacement est assurée par le cantonnement téléphonique.\nIl n’y a aucune barrière technique de sécurité, toute erreur humaine peut avoir des conséquences graves. Des boucles de rattrapage peuvent permettre de pallier ces erreurs (DAAT, CAPI, GSM/GFU, RST, coupure d’urgence si la ligne est électrifiée, etc.).\n","categories":"","description":"","excerpt":"Définition Certaines lignes à voie unique sont désignées à la …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-simplified-signalling/","tags":"","title":"La voie unique à signalisation simplifiée (VUSS)"},{"body":"Principe Les installations de voie unique temporaire à caractère permanent (VUTP) permettent la circulation occasionnelle des trains des deux sens sur une seule voie, entre deux gares, sans arrêt à l’entrée et sans préavis aux conducteurs.\nLes sections de ligne équipées de VUTP sont désignées aux RT.\nLe risque de nez à nez Des enclenchements de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre.\nLe risque de rattrapage L’espacement des trains circulant dans le sens normal est assuré dans les conditions habituelles.\nL’espacement des trains à contresens est assuré automatiquement.\nCirculation à contresens L’entrée d’un parcours à contresens est repérée par un tableau VUT groupé avec le panneau qui porte le carré protégeant l’aiguille d’entrée.\nLa présentation du tableau VUT indique au conducteur :\nque le train est dirigé et est autorisé à s’engager à contresens ; qu’à partir de ce tableau, les signaux qui le concernent sont implantés à droite. Exemple d’entrée à 30 km/h sur VUTP\nLa vitesse limite à ne pas dépasser est fixée à 70 km/h.\nLa sortie du parcours à contresens est repérée par un tableau « FIN de VUT » groupé avec le panneau qui porte le signal carré protégeant l’aiguille de sortie.\nLa présentation du tableau « FIN de VUT » indique au conducteur :\nque le train est parvenu à la fin du parcours à contresens ; qu’à partir de ce tableau, les signaux qui le concernent sont implantés à gauche. ","categories":"","description":"","excerpt":"Principe Les installations de voie unique temporaire à caractère …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track-of-permanent-nature/","tags":"","title":"La voie unique temporaire à caractère permanent (VUTP)"},{"body":"","categories":"","description":"General Packet Radio Service","excerpt":"General Packet Radio Service","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/","tags":"","title":"GPRS"},{"body":"Principe Lorsqu’une cause quelconque (incident, exécution de travaux, etc.), interdit l’utilisation d’une voie et en l’absence d’installations permettant la circulation dans les deux sens en sécurité sur l’autre voie (ICS, voie banalisée), la circulation des trains est organisée par les agents du service de gestion des circulations situés aux extrémités selon des procédures adaptées.\nLa VUT est donc un régime temporaire d’exploitation permettant, sur une ligne à double voie non équipée d’installation de contresens, de faire circuler les trains des deux sens sur une seule et même voie.\nLes trains devant circuler à contre sens sont arrêtés à l’entrée.\nLa circulation sur la VUT dans les deux sens se fait selon le principe de la demande et de l’accord de voie entre agents du service de la gestion des circulations.\nLa vitesse limite à contre sens est de 70 km/h.\nLa sortie de la VUT est repérée soit :\npar un signal carré implanté à gauche, à droite ou au-dessus de la voie ; par un signal d’arrêt à main. Organisation La VUT est établie entre les deux changements de voies utilisables les plus rapprochés qui en constituent les extrémités.\nLa VUT est organisée par l’agent du service de la gestion des circulations qui expédie les trains à contresens sur cette voie (gare B dans l’exemple ci-dessous) et qui doit aviser ou faire aviser les agents intéressés : agents des postes, des PN gardés, agents travaillant sur la voie ou les caténaires.\nCirculation sur la VUT Le risque de nez à nez L’expédition de tout train sur la VUT est subordonnée à un accord de voie donné par l’agent du service de gestion des circulations de l’autre extrémité de la VUT à l’agent-du service de gestion des circulations qui doit expédier le train.\nLe risque de rattrapage Les trains de sens normal sont cantonnés dans les conditions habituelles.\nLes trains circulant à contresens sont cantonnés téléphoniquement dans les conditions prévues pour la voie unique (voir 4.3.).\nAvis au conducteur En sens normal : aucun avis n’est fait au conducteur, les trains circulent sans arrêt à l’entrée.\nÀ contre sens : le conducteur est arrêté à l’entrée de la VUT puis informé par écrit par l’agent du service de la gestion des circulations qu’il va circuler à contresens en VUT.\nCet ordre écrit reprend les points ou zones du parcours sur lesquels le conducteur doit appliquer des prescriptions particulières.\nEn effet, les installations et la signalisation ne sont généralement pas prévues pour les circulations en sens inverse du sens normal (PN, limitations de vitesse, etc.).\n","categories":"","description":"","excerpt":"Principe Lorsqu’une cause quelconque (incident, exécution de travaux, …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/","tags":"","title":"La voie unique temporaire (VUT)"},{"body":"Définition Ce régime concerne des lignes fermées au service voyageurs qui ne comportent normalement pas de signaux. Les règles concernant le régime général d’exploitation de la voie unique ne sont pas applicables et sont remplacées par des modalités particulières définies par le gestionnaire d’infrastructure.\nPrincipe Une consigne locale d’exploitation adaptée à chaque VUTR précise les caractéristiques d’exploitation comme la vitesse de la ligne, la signalisation, les établissements, les liaisons téléphoniques, les PN, etc.\nElle est complétée par un programme de circulation qui comporte les horaires des trains devant circuler et précise les dispositions particulières concernant chaque train (trains entre lesquels l’espacement doit être assuré, croisements, etc.).\nCes lignes ne comportent normalement pas de signaux, les limitations de vitesse à observer sur les aiguilles ainsi que les autres limitations permanentes de vitesse sont inscrites à la consigne locale d’exploitation de la ligne ; elles ne sont pas rappelées par des signaux sur le terrain.\nPar principe, la vitesse de circulation ne dépasse généralement pas 50 km/h.\nAucun enclenchement n’est prévu. Chaque ligne dépend d’un agent de SNCF Réseau dénommé « chef de ligne ». La sécurité des circulations est assurée par le chef de ligne et par les agents des trains.\nNota : Les VUTR ne sont pas définies dans les RT.\n","categories":"","description":"","excerpt":"Définition Ce régime concerne des lignes fermées au service voyageurs …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/","tags":"","title":"La voie unique à trafic restreint (VUTR)"},{"body":"","categories":"","description":"Futur Système de Communications Mobiles Ferroviaires","excerpt":"Futur Système de Communications Mobiles Ferroviaires","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/frmcs/","tags":"","title":"FRMCS"},{"body":"Principe Lorsqu’une cause quelconque (incident, secours, travaux inopinés de courte durée, etc.), interdit l’utilisation d’une voie, en l’absence d’installation permettant la circulation dans les deux sens sur l’autre voie (ICS, voie banalisée) et qu’il n’est pas envisagé d’organiser une VUT (par exemple, du fait que très peu de circulations seront concernées), la circulation d’un train n’empruntant pas le sens normal se fait alors à contre-voie sur la voie non interceptée. Les trains devant circuler à contre-voie sont arrêtés à l’entrée.\nLe mouvement à contre-voie peut être effectué :\nd’un point quelconque vers un point situé en amont (ces points pouvant être un point de pleine voie, une gare, un évitement télécommandé) ; à l’intérieur d’une gare. Organisation Mouvements à contre-voie à l’intérieur d’une gare Lorsqu’un mouvement à contre-voie doit être effectué à l’intérieur d’une gare, il est organisé à l’initiative de l’agent du service de gestion des circulations.\nLe conducteur est avisé par l’agent du service de la gestion des circulations qu’il doit effectuer un mouvement à contre-voie et que le mouvement s’effectue :\nsoit comme une manœuvre. Dans ce cas le conducteur sera renseigné et guidé par des signaux de manœuvre ; soit par la transmission d’un ordre écrit ou d’une dépêche. Autres mouvements à contre-voie d’une gare vers la gare en amont ou de la gare en avant vers un point de pleine voie L’agent chargé d’organiser ce mouvement à contre-voie est l’agent du service de gestion des circulations de la gare dans laquelle le mouvement a son origine. d’un point de pleine voie vers la gare en arrière L’agent chargé d’organiser ce mouvement à contre-voie est l’agent du service de gestion des circulations de la gare dans laquelle le mouvement se termine. Dans ces deux cas, l’agent du service de la gestion des circulations, après avoir obtenu l’assurance que la partie de voie à parcourir est libre et le restera, remet un ordre écrit ou transmet une dépêche au conducteur pour circuler à contre-voie. En pleine voie Le conducteur est responsable de ce mouvement, lorsqu’il prend l’initiative d’exécuter ce mouvement : à la suite d’une rupture d’attelage lorsque le train peut être reconstitué ; à la suite d’un léger dépassement du point d’arrêt habituel dans un établissement PL. Circulation à contre-voie Après arrêt du train, l’agent du service de la gestion des circulations, selon le cas, remet au conducteur un ordre écrit ou le transmet par dépêche. Cet ordre reprend les points ou zones du parcours sur lesquels le conducteur doit appliquer des prescriptions particulières.\nEn effet, les installations et la signalisation ne sont généralement pas prévues pour les circulations en sens inverse du sens normal (PN, limitations de vitesse, etc.).\nLorsque le conducteur est en tête du mouvement, la circulation s’effectue en marche à vue sur tout le parcours effectué à contre-voie (le conducteur peut rencontrer un obstacle non protégé).\nLorsque le conducteur n’est pas en tête, la circulation est guidée par des signaux de manœuvre.\nLa fin du parcours à contre voie est généralement repérée soit :\npar un signal carré ; par un signal d’arrêt à main. ","categories":"","description":"","excerpt":"Principe Lorsqu’une cause quelconque (incident, secours, travaux …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-track-movement/","tags":"","title":"Mouvement à contre-voie"},{"body":"Définition Régime d’exploitation d’une ligne sur laquelle la circulation d’un train ne peut être autorisée qu’après dégagement du train précédemment engagé, l’engagement et le dégagement se faisant au même point.\nPrincipe L’exploitation en navette consiste à n’autoriser la présence que d’une seule circulation sur la section de ligne concernée, cette circulation revenant à son point de départ, ce qui par conception limite les risques de collision de trains.\nToutefois, le programme peut inclure moyennant des procédures adaptées des mouvements de desserte, avec ou sans possibilité de garage (desserte origine terminus ou desserte en antenne).\nL’accès à la voie exploitée en navette est commandé par un signal muni du DAAT ou du KVB.\n","categories":"","description":"","excerpt":"Définition Régime d’exploitation d’une ligne sur laquelle la …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-shuttle/","tags":"","title":"L’exploitation en navette"},{"body":"","categories":"","description":"European Train Management Layer","excerpt":"European Train Management Layer","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/etml/","tags":"","title":"ETML"},{"body":"Définition Régime d’exploitation d’une ligne à une ou plusieurs voies parcourues par les trains des deux sens. Sur ces voies, des installations de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre. Sur les lignes à plusieurs voies banalisées, les trains d’un même sens peuvent circuler indifféremment sur l’une quelconque de ces voies.\nPrincipe Une voie banalisée peut être découpée en plusieurs intervalles (points entre lesquels il n’existe aucune possibilité de croisement ou dépassement).\nSur une voie, quel que soit le sens :\nles signaux sont normalement implantés à gauche ; le découpage éventuel d’un intervalle en cantons est identique. Le risque de nez à nez Les deux extrémités d’un intervalle de voie banalisée sont équipées de signaux d’arrêt non permissifs permettant d’arrêter et de retenir les trains se dirigeant vers l’intervalle. Elles sont reliées par un enclenchement entre itinéraires de sens contraires.\nLe risque de nez à nez est pris en charge notamment, par l’enclenchement entre itinéraires de sens contraire. Cet enclenchement agit directement sur le circuit de commande des signaux de protection donnant accès à l’intervalle. Il nécessite la mise en oeuvre de circuits de voie ou de compteurs d’essieux qui interviennent en outre dans le block automatique (cf. rattrapage ci-dessous).\nLes installations de sécurité s’opposent à l’expédition de deux trains de sens contraire dans le même intervalle. Cette interdiction est maintenue tant que l’intervalle est occupé.\nLe risque de rattrapage L’espacement est assuré automatiquement. En signalisation au sol, l’espacement des trains de même sens est assuré par le block automatique par l’intermédiaire de circuits de voie ou de compteur d’essieux. Selon l’importance du trafic, il peut s’agir de :\nBAPR : La longueur d’un canton de BAPR peut atteindre 15 km ou plus ; BAL : La longueur maximale d’un canton de BAL n’excède pas généralement 2,8 km ce qui permet un écoulement de trafic plus important. En signalisation de cabine, la TVM ou l’ETCS assurent l’espacement.\n","categories":"","description":"","excerpt":"Définition Régime d’exploitation d’une ligne à une ou plusieurs voies …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-two-ways/","tags":"","title":"La voie banalisée"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/blog/","tags":"","title":"Blog OSRD"},{"body":" Open Source Railway Designer À propos Github Une application web, open source, de conception d'infrastructure ferroviaire, d'horaires, d'analyse de capacité et bien plus ! Conception ferroviaire Modifiez l’infrastructure ferroviaire et les grilles horaires Analyse de capacité Détectez les conflits et visualisez la capacité Planning court-terme Ajoutez automatiquement de nouveaux trains dans une grille existante Développement Open source Tout le monde peut utiliser, redistribuer et développer OSRD Lire plus …\nGouvernance ouverte OSRD est conçu de manière partagée et publique, les décisions sont prises collégialement Lire plus …\nConçu pour l’interopérabilité Faites vos simulations à l’aide de formats d'infrastructure et de systèmes de signalisation sur mesure Sponsors ","categories":"","description":"","excerpt":" Open Source Railway Designer À propos Github Une application web, …","ref":"/fr/","tags":"","title":"OSRD"},{"body":"Le 13 décembre 2023, l’équipe OSRD a présenté ses premiers résultats lors d’une conférence.\nVoici la rediffusion des interventions :\nOuverture Présentations OpenRail ","categories":"","description":"","excerpt":"Le 13 décembre 2023, l’équipe OSRD a présenté ses premiers résultats …","ref":"/fr/blog/2023/12/13/presentation-osrd-1/","tags":"","title":"Présentation OSRD #1"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/blog/","tags":"","title":"OSRD Blog"},{"body":" Open Source Railway Designer About Github An open source web application for railway infrastructure design, capacity analysis, timetabling and more! Railway design Design railway infrastructure and timetables Capacity Analysis Detect conflicts and visualize capacity Short-term planning Automatically add new trains to an existing timetable Open source development Anyone can use, develop and distribute OSRD Read more …\nOpen governance OSRD is publicly designed, decisions are taken collectively Read more …\nDesigned for interoperability Make custom infrastructure formats and signaling systems work together Sponsors ","categories":"","description":"","excerpt":" Open Source Railway Designer About Github An open source web …","ref":"/en/","tags":"","title":"OSRD"},{"body":"Dreiländer hack, the annual meeting of German-speaking railway companies… but not only! On 29 and 30 June, the “Dreiländer hack” (the hackathon of the three countries) was held in Wien (Austria). Organised by DB (Germany), ÖBB (Austria) and SBB (Switzerland), this is an annual event dedicated to collaboration on shared railway-related challenges.\nWe were delighted to be invited to take part thanks to the OpenRail association, and this year’s theme being “Open Railways”, it would have been hard to refuse!\n24 hours to work together on a topic of common interest The 150 participants were divided into 16 working groups on a wide variety of topics such as:\nImagining a simple interface for ordering train paths (an important subject for the future of OSRD); Offering passenger information adapted to different disabilities; Optimizing the prioritisation of trains at junctions according to the number of passengers on board and on the platform (Motis project); Automatically identifying energy-consuming trains in storage; Calculating forecast maintenance dates from a historical database for each train component; Detecting speed measurement and GPS positioning errors on track inspection trains; Optimizing maintenance work to limit lost capacity; Facilitating passenger information with a GPT chatbot; Designing an easy-to-use display and ticketing interface for night trains across Europe. Challenge proposal by OSRD The challenge proposed by OSRD was to consolidate the railway data in OpenStreetMap, an open \u0026 collaborative database that we use as a source for railway infrastructure in Europe.\nThe objective was to develop an algorithm to identify 5 types of probable errors in the data:\nDisconnected tracks Suspicious switches Stations apart from tracks Weird angles Missing gauge info The subject was of interest and we formed a team of 10 people divided between the four participating companies. After a presentation of the challenge and of the OpenStreetMap data model, we looked for existing tools and chose to use Osmose, an open source application for detecting and displaying potential errors in OSM. We then split up to work on the 5 types of errors.\nFrom left to right: Christoph (DB), Klara (ÖBB), Frederik (SBB), Carl (SBB), Julius (DB), Jennifer (DB), Daniel (ÖBB), Céline (SNCF), Max (DB), Tristram (SNCF).\nResults After 24 hours of work, the result is an interactive map showing the various errors (click on the pictograms to show error details). You can find all the code that was produced on the OpenRail association’s GitHub.\nWe did not manage to integrate our analysers into Osmose within the allotted time, but that remains the target on which we’re going to continue working, so that all OpenStreetMap contributors can easily correct errors in railway data!\n","categories":"","description":"","excerpt":"Dreiländer hack, the annual meeting of German-speaking railway …","ref":"/en/blog/2023/07/19/osrd-at-dreil%C3%A4nder-hack-in-wien/","tags":"","title":"OSRD at Dreiländer Hack in Wien"},{"body":"Le Dreiländer hack, le rendez-vous des entreprises ferroviaires germanophones… mais pas que ! Les 29 et 30 juin derniers s’est tenu à Vienne (Autriche) le Dreiländer hack (le hackathon des trois pays). Organisé par Deutsche Bahn - DB (Allemagne), Österreichische Bundesbahnen - ÖBB (Autriche) et Schweizerische Bundesbahnen - SBB (Suisse), c’est un rendez-vous annuel dédié à la collaboration sur des problématiques ferroviaires communes.\nNous avons eu le plaisir d’être invité·es à participer dans le cadre de l’association OpenRail, et le thème de cette année étant “Open Railways” il aurait été difficile de refuser !\n24h pour travailler ensemble sur un sujet d’intérêt commun Les 150 participant·es se sont réparti·es en 16 groupes de travail sur des thèmes très variés tels que :\nImaginer une interface simple de commande de sillons (un sujet important pour l’avenir d’OSRD) ; Proposer de l’information voyageur adaptée aux différents handicaps ; Optimiser la priorisation des trains aux embranchements en fonction de l’affluence à bord et à quai (projet Motis) ; Identifier automatiquement des trains au garage qui consomment de l’énergie ; Calculer des dates de maintenance prévisionnelles à partir d’une base de données historique sur chaque composant du train ; Détecter des erreurs de mesure de vitesse et de positionnement GPS sur des trains d’inspection des voies ; Optimiser les chantiers de maintenance pour limiter la capacité perdue ; Faciliter l’information voyageurs avec un chatbot GPT ; Imaginer une interface de visualisation \u0026 de commande pour l’offre de trains de nuit au niveau européen facile à utiliser. Le challenge proposé par OSRD Le challenge proposé par OSRD visait à consolider les données ferroviaires présentes dans OpenStreetMap, une base de données ouverte \u0026 collaborative que nous utilisons comme source pour l’infrastructure ferroviaire en Europe.\nL’objectif était de développer un algorithme permettant d’identifier 5 types d’erreurs probables dans les données :\nVoies proches géographiquement mais non connectées topologiquement Aiguilles à plus de 3 branches Gares éloignées des voies Voies avec des angles trop importants Information d’écartement des voies manquante Le sujet a eu du succès et nous avons formé une équipe de 10 personnes réparties entre les quatre entreprises participantes. Après une présentation du challenge \u0026 du modèle de données d’OpenStreetMap, nous avons recherché des outils existant et avons choisi de nous appuyer sur Osmose, une application open source de détection et d’affichage d’erreurs potentielles dans OSM. Nous nous sommes ensuite réparti·es sur les 5 types d’erreurs.\nDe gauche à droite : Christoph (DB), Klara (ÖBB), Frederik (SBB), Carl (SBB), Julius (DB), Jennifer (DB), Daniel (ÖBB), Céline (SNCF), Max (DB), Tristram (SNCF).\nLes résultats Après 24h de travail le résultat est une carte interactive permettant d’afficher les différentes erreurs (cliquez sur les pictogrammes pour afficher le détail des erreurs). Vous pouvez retrouver tout le code qui a été produit sur le GitHub de l’association Open Rail.\nLe manque de temps imparti ne nous a malheureusement pas permis d’intégrer nos analyseurs dans Osmose, cependant cela reste notre priorité pour faire avancer les travaux des contributeurs et contributrices d’OpenStreetMap sur les données ferroviaires !\n","categories":"","description":"","excerpt":"Le Dreiländer hack, le rendez-vous des entreprises ferroviaires …","ref":"/fr/blog/2023/07/19/osrd-au-dreil%C3%A4nder-hack-%C3%A0-vienne/","tags":"","title":"OSRD au Dreiländer Hack à Vienne"},{"body":"Un I\u0026A prometteur Notre 5ème Inspect \u0026 Adapt a commencé avec la présentation de notre PI System demo de l’application OSRD, démontrant l’ensemble des travaux réalisés au cours de ce PI5 par nos équipes. À la suite de cette demo, l’atteinte de nos objectifs (engagés et non engagés) a été évaluée par nos partie-prenantes. Verdict : 113 % de réussite… Si, si, c’est possible 😉 !\nPlanification de notre 6ème Product Increment (PIP6) ! Après les traditionnelles séquences portant sur l’évolution de notre contexte de métier et technique, nous avons assisté à l’intervention de François Marchal, Responsable domaine numérique exploitation à la Digit, portant sur les enjeux du numérique au sein de SNCF Réseau et le rôle d’OSRD au sein de l’organisation.\nLe lendemain, Nathanaël Dias, Chargé d’étude exploitation ferroviaire, nous a présenté son métier, et le processus d’élaboration d’une étude exploitation. Il a insisté sur l’importance de partager les résultats et les travaux.\nAu cours du PIP, de nouvelles fonctionnalités ont été embarquées par les équipes, et transformées en objectifs à atteindre. Le travail a été planifié pour les 11 semaines à venir et les risques ont été évalués pour être minimisés.\nRendez-vous mi-juillet pour le 7ème PIP !\n","categories":"","description":"","excerpt":"Un I\u0026A prometteur Notre 5ème Inspect \u0026 Adapt a commencé avec la …","ref":"/fr/blog/2023/04/24/ia5-et-pip6-avril-2023/","tags":"","title":"I\u0026A5 et PIP6 - avril 2023 "},{"body":"DGEX Solutions Forum Here’s an extract from Loïc Hamelin’s talk at the DGEX Solutions forum, on the subject of search for last-minute train slots (STDCM).\nFirst of all, what is a train path? It’s the reservation of space/time on the network, by railway undertakings (RU) such as SNCF Voyageurs. These reservations are generally made years in advance (A-3). RUs can also make emergency requests for train paths (called last-minute paths), from A-1 to D-day. These requests are currently managed by ticket offices, and the paths are traced by hand. There is therefore a risk of human error, and requests are sometimes processed over several days.\nWhat do we offer? The OSRD software, in addition to featuring a rail simulator for timetable planning, will also enable last-minute path requests to be processed automatically! With just a few clicks, you’ll be able to submit a last-minute path request and get a response in a matter of seconds (3 minutes at most)!\nIf you’re interested in the #osrd project, please visit the osrd website and the GitHub repo, and the project is #opensource.\nMorgane Senejko’s LinkedIn post\n","categories":"","description":"","excerpt":"DGEX Solutions Forum Here’s an extract from Loïc Hamelin’s talk at the …","ref":"/en/blog/2023/04/12/dgex-solutions-forum/","tags":"","title":"DGEX Solutions Forum"},{"body":"Forum DGEX Solutions Voici un extrait de la conférence de Loïc Hamelin au forum DGEX Solutions , au sujet du calcul automatique de sillon de dernière minute.\nMais tout d’abord qu’est ce qu’un sillon ? Il s’agit de la réservation d’espace/temps sur le réseau, par les entreprises ferroviaires (EF), comme SNCF Voyageurs. Ces réservations se font généralement des années en amont (A-3). Les EF peuvent également faire des demandes de sillons en urgence (appelés sillons de dernière minute), de A-1 jusqu’au jour J. Ces demandes sont actuellement gérées par des guichets, et les sillons sont tracés à la main. Il y a donc un risque d’erreur humaine, et les demandes sont parfois traitées en plusieurs jours.\nQu’est ce que nous proposons ? Le logiciel OSRD, en plus de disposer d’un simulateur ferroviaire pour la planification des horaires, va également permettre de traiter les demandes de sillon de dernière minute de façon automatisée ! Il sera possible en seulement quelques clics d’exprimer une demande de sillon de dernière minute et obtenir une réponse en quelques secondes (tout au plus 3min) !\nSi le projet #osrd vous intéresse, n’hésitez pas à consulter le site web osrd et le repo GitHub, et le projet est #opensource.\nPost LinkedIn de Morgane Senejko\n","categories":"","description":"","excerpt":"Forum DGEX Solutions Voici un extrait de la conférence de Loïc Hamelin …","ref":"/fr/blog/2023/04/12/forum-dgex-solutions/","tags":"","title":"Forum DGEX Solutions"},{"body":"Forum DGEX Solutions Voici un extrait de la conférence de Loïc Hamelin au forum DGEX Solutions , au sujet du calcul automatique de sillon de dernière minute.\nMais tout d’abord qu’est ce qu’un sillon ? Il s’agit de la réservation d’espace/temps sur le réseau, par les entreprises ferroviaires (EF), comme SNCF Voyageurs. Ces réservations se font généralement des années en amont (A-3). Les EF peuvent également faire des demandes de sillons en urgence (appelés sillons de dernière minute), de A-1 jusqu’au jour J. Ces demandes sont actuellement gérées par des guichets, et les sillons sont tracés à la main. Il y a donc un risque d’erreur humaine, et les demandes sont parfois traitées en plusieurs jours.\nQu’est ce que nous proposons ? Le logiciel OSRD, en plus de disposer d’un simulateur ferroviaire pour la planification des horaires, va également permettre de traiter les demandes de sillon de dernière minute de façon automatisée ! Il sera possible en seulement quelques clics d’exprimer une demande de sillon de dernière minute et obtenir une réponse en quelques secondes (tout au plus 3min) !\nSi le projet #osrd vous intéresse, n’hésitez pas à consulter le site web osrd et le repo GitHub, et le projet est #opensource.\nPost LinkedIn de Morgane Senejko\n","categories":"","description":"","excerpt":"Forum DGEX Solutions Voici un extrait de la conférence de Loïc Hamelin …","ref":"/fr/blog/2023/04/12/forum-dgex-solutions/","tags":"","title":"Forum DGEX Solutions"},{"body":"I\u0026A février 2023 : ce qu’on retiendra ! L‘Inspect \u0026 Adapt est une cérémonie issue du framework d’agilité à l’échelle SAFe (Scaled Agile Framework), au cours de laquelle nous inspectons notre travail réalisé sur les 11 dernières semaines pour nous adapter en conséquence. Nous nous sommes donc réunis ce lundi 13 février pour clore le 4ème Increment de notre programme (PI 4).\nAprès avoir assisté à la demo de toutes les fonctionnalités développées par nos 3 équipes (PI system demo), nos parties prenantes ont pu évaluer l’atteinte de nos objectifs. Résultat : environ 80% de réussite.\nLancement de notre 5ème PIP ! Le Product Increment Planning (PIP) est une cérémonie au cours de laquelle les équipes se répartissent le backlog des nouvelles fonctionnalités et planifient leur travail sur les 11 prochaines semaines. Avant d’entamer le travail de planification en sous-groupe, Loïc Hamelin nous a présenté les évolutions du contexte business d’OSRD, retraçant les attentes de nos clients.\nDans la matinée du 15 février, Caroline Johnson, Directrice Solutions Numériques Exploitation chez SNCF Réseau, nous a présenté l’offre de service sur la DG-Num et a répondu à nos questions sur l’intégration prochaine de notre application dans le SI interne.\nA l’issue du PIP, nos business owners ont attribué une valeur, entre 1 et 10, à nos nouveaux objectifs de PI et les risques de programme ont été évalués.\n","categories":"","description":"","excerpt":"I\u0026A février 2023 : ce qu’on retiendra ! L‘Inspect \u0026 Adapt est une …","ref":"/fr/blog/2023/02/13/ia-et-pip-4-f%C3%A9vrier-2023/","tags":"","title":"I\u0026A et PIP 4 - février 2023"},{"body":"\nUne Devroom pour l’association Openrail Les 4 et 5 février se tenait le FOSDEM, l’évènement européen annuel incontournable pour la communauté open source. Tout au long de ces 2 jours à Bruxelles, les participants ont pu assister à une variété de conférences et ateliers portant sur les dernières tendances du logiciel libre et de l’open source. L’un des moments forts de l’événement était le lancement de la Devroom « Opening railways and open transport », portée par la toute nouvelle OpenRail association. Le programme OSRD a eu la chance d’ouvrir cette nouvelle room avec ST DCM.\n« Short-term digital capacity management » ou le challenge des sillons de dernière minute La conférence d’Eloi Charpentier, intitulée « automated short-term train planning in OSRD » présentait les réflexions issues de nos travaux sur la simulation de sillons de dernière minute. Ou comment permettre aux entreprises de fret ferroviaire d’obtenir des autorisations de circulation de dernière minute évitant les embouteillages sur le réseau, et d’avoir ainsi l’agilité indispensable pour concurrencer le transport routier ?\nSlides Vidéo Opendata et cartographie du réseau ferroviaire La présentation de Céline Durupt, “OpenStreetMap, one geographic database to rule them all?” abordait le sujet de l’opendata en matière de réseau ferroviaire. Sur la base d’une analyse européenne, Céline a présenté un plan d’actions pour partager la donnée ferroviaire via OSM et la rendre utilisable par OSRD.\nSlides Vidéo Rendez-vous l’année prochaine au FOSDEM 2024 avec des exemples concrets de collaboration et de nouveaux développements d’open source ferroviaire.\n","categories":"","description":"","excerpt":"\nUne Devroom pour l’association Openrail Les 4 et 5 février se tenait …","ref":"/fr/blog/2023/02/06/fosdem-2023-osrd-%C3%A9tait-pr%C3%A9sent/","tags":"","title":"Fosdem 2023 : OSRD était présent !"},{"body":"Hi ! My name is Céline, and I am on a mission to bring more open data into OSRD. To do so, I searched open data that can fit OSRD’s needs in every country of the European Union (+ Norway, United Kingdom and Switzerland).\nI have presented the main results of this study during a talk at the FOSDEM 2023 meeting, and you can see the replay on their website.\nIn this post I will go into details of the methodology I followed, feel free to contact me if you have any remarks or question :-)\nData download You can download the detailed data I created here. Update 11/03/23 : get the updated file here.\nAdded open data sources links for : Estonia, Czechia, Poland, Slovakia Added license detail pour : Sweden Added information on real-time position of trains for : Finland Special thanks to Christoph Breit \u0026 everyone that contributed by sending me links \u0026 info The file is composed of three tabs:\nEU-sources: links to download each country’s open data \u0026 info on license compatibility EU-data: data used to compare total track length between countries and source and to compute the “usability indicator” EU-epsg: EPSG code used for reprojecting geographical data for each country Compare total track length Calculate track length from open data Look for open data sources\nIf a source is found, look for data license\nCheck license compatibility with OpenStreetMap using OSM wiki and this blog post\nDownload open data\nLoad data into QGIS and reproject it based on the EU-epsg tab\nCalculate a new field using the following formula to get the length of each track in kilometers:\n\"length\" = $length / 1000 Report total length using the “Basic Statistics for Fields” tool\nLearn more about Inspire data model\nCalculate track length for OpenStreetMap data Download last OSM export from https://download.geofabrik.de/europe.html\nLoad lines data into QGIS\nSelect data using the “other_tags” field to select railway network:\n\"other_tags\" like '%\"railway\"=\u003e\"rail\"%' or \"other_tags\" like '%\"railway\"=\u003e\"narrow_gauge\"%' or \"other_tags\" like '%\"railway\"=\u003e\"light_rail\"%' Export selected objects and reproject the layer based on the EU-epsg tab\nCalculate a new field using the following formula to get the length of each track in kilometers:\n\"length\" = $length / 1000 Select electrified parts of the network using the “other_tages” field:\n\"other_tags\" like '%\"electrified\"=\u003e\"yes\"%' or \"other_tags\" like '%\"electrified\"=\u003e\"contact_line\"%' or \"other_tags\" like '%\"electrified\"=\u003e\"rail\"%' Report total length using the Basic Statistics for Fields tool\nLearn more about OpenStreetMap data model\nCalculate usability indicator List required and optional data For each data, indicate its availability using QGIS (Overpass Turbo can also be helpful to check OSM data) and the following scale : “Yes”: fully available “Partial”: not available everywhere on the country, or missing parts of the data “No”: not available Sum total required and optional data with Yes = 1; Partial = 0.5; No = 0 Generate indicator: “Good” if required=2 and optional\u003e2 “Okay” if required \u003e1 and optional \u003e=0 “Poor” if required=1 and optional \u003e2 “Not usable” else Map the result To show the indicator and license compatibility on a map, use the Eurostat borders datasets (for my presentation, I have used the 1:20 million scale and EPSG:3035) and join the table using countries names.\n","categories":"","description":"","excerpt":"Hi ! My name is Céline, and I am on a mission to bring more open data …","ref":"/en/blog/2023/02/03/openstreetmap-and-open-data-talk-at-fosdem-2023/","tags":"","title":"OpenStreetMap and open data talk at Fosdem 2023"},{"body":"Review cycle A code review is an iterative process. For a smooth review, it is imperative to correctly configure your github notifications.\nIt is advisable to configure OSRD repositories as “Participating and @mentions”. This allows you to be notified of activities only on issues and PRs in which you participate.\nMaintainers are automatically notified by the CODEOWNERS system. The author of a PR is responsible for advancing their PR through the review process and manually requesting maintainer feedback if necessary.\nsequenceDiagram actor A as PR author actor R as Reviewer/Maintainer A-\u003e\u003eR: Asks for a review, notifying some people R-\u003e\u003eA: Answers yes or no loop Loop between author and reviewer R--\u003e\u003eA: Comments, asks for changes A--\u003e\u003eR: Answers to comments or requested changes A--\u003e\u003eR: Makes necessary changes in dedicated \"fixups\" R--\u003e\u003eA: Reviews, tests changes, and comments again R--\u003e\u003eA: Resolves requested changes/conversations if ok end A-\u003e\u003eR: Rebase and apply fixups R-\u003e\u003eA: Checks commits history R-\u003e\u003eA: Approves or closes the PR Note left of R: \u0026 Merges if maintainer ","categories":"","description":"","excerpt":"Review cycle A code review is an iterative process. For a smooth …","ref":"/en/docs/guides/contribute/review-process/","tags":"","title":""},{"body":"Cycle de review Une revue de code est un processus itératif. Pour la fluidité d’une review, il est impératif de configurer correctement ses notifications github.\nIl est conseillé de configurer les dépôts OSRD en “Participating and @mentions”. Cela permet d’être notifié d’activités uniquement sur les issues et PR auxquelles vous participez.\nsequenceDiagram actor A as Auteur PR actor R as Reviewer/mainteneur A-\u003e\u003eR: Demande une review en notifiant spéciquement quelques personnes R-\u003e\u003eA: Répond à la demande par oui ou non loop Boucle entre auteur et reviewer R--\u003e\u003eA: Commente, demande des changements A--\u003e\u003eR: Répond à chaque commentaire/demande de changement A--\u003e\u003eR: Corrige le code si nécessaire dans des « fixups » dédiés R--\u003e\u003eA: Vérifie, teste, et commente à nouveau le code R--\u003e\u003eA: Résout les conversations/demandes de changement le cas échéant end A-\u003e\u003eR: Rebase si nécessaire R-\u003e\u003eA: Vérifie l'historique des commits R-\u003e\u003eA: Approuve ou ferme la PR Note left of R: Et fusionne si mainteneur Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).\n","categories":"","description":"","excerpt":"Cycle de review Une revue de code est un processus itératif. Pour la …","ref":"/fr/docs/guides/contribute/review-process/","tags":"","title":""},{"body":"OSRD est une suite d’outils ferroviaires pour différents cas d’utilisation. Ces outils sont basés sur la simulation de l’infrastructure ferroviaire ainsi que son analyse.\n","categories":"","description":"","excerpt":"OSRD est une suite d’outils ferroviaires pour différents cas …","ref":"/fr/about/","tags":"","title":"À propos"},{"body":"OSRD is a railway toolbox designed for multiple use cases. These tools have in common a reliance on railway infrastructure simulation and results analysis.\n","categories":"","description":"","excerpt":"OSRD is a railway toolbox designed for multiple use cases. These tools …","ref":"/en/about/","tags":"","title":"About"},{"body":"Principe Le block automatique se caractérise en block automatique lumineux (BAL) et en block automatique à permissivité restreinte (BAPR) par :\nle fonctionnement entièrement automatique des signaux de cantonnement dont le changement d’état (fermeture ou ouverture) est provoqué par le passage des circulations sans aucune intervention humaine ; l’état d’occupation de chaque canton, agissant directement sur le signal d’entrée correspondant est obtenu par le circuit de voie en BAL, généralement par un comptage d’essieu en BAPR. Le BAL permet un débit élevé des circulations sur la ligne. Fonctionnement d’un circuit de voie Un circuit de voie est principalement constitué de trois éléments :\nun émetteur, branché à l’une des extrémités de la zone. Il délivre un courant qui peut être de différente nature selon les types de circuit de voie (continu, impulsionnel, alternatif, etc.) ; une ligne de transmission, constituée par les deux files de rails ; un récepteur, branché à l’autre extrémité de la zone. Il assure le filtrage, l’amplification et la transformation du signal reçu via les rails, ce qui agit sur un relais appelé relais de voie. Les contacts de ce relais sont utilisés pour établir ou couper le circuit électrique du signal d’entrée du canton. Lorsqu’aucun véhicule n’est présent sur la zone délimitant le circuit de voie (voie libre), le signal délivré par l’émetteur parvient au récepteur à travers la ligne de transmission, et le relais de voie est excité. Le feu d’entrée du canton est à voie libre (cas 1 ci-dessous).\nLorsqu’un véhicule est présent, son premier essieu agit comme une faible résistance, appelée shunt, qui court-circuite la transmission. Dans ce cas, le niveau du signal parvenant au récepteur n’est plus suffisant et le relais de voie se désexcite, ce qui entraine la fermeture du signal d’entrée du canton (cas 2 ci-dessous).\nFonctionnement des compteurs d’essieux Un compteur d’essieux est un dispositif technique servant à détecter la présence d’une circulation sur une section, par comptage des essieux qui franchissent les détecteurs encadrant cette section.\nUn point de détection est installé à chaque extrémité de la section, et chaque fois qu’un essieu passe sur ce point au début de la section, un compteur s’incrémente. Quand le train passe sur le point de détection en fin de la section, le compteur décrémente. Si le nombre final est zéro, la section est présumée libre pour un deuxième train et le signal d’entrée du canton présentera l’indication « voie libre ».\n","categories":"","description":"Block Automatique","excerpt":"Block Automatique","ref":"/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/","tags":"","title":"BA"},{"body":"Le signal d’entrée du canton présente une indication liée à l’état d’occupation du ou des cantons suivants, selon les règles suivantes :\nindication d’arrêt lorsque le canton est occupé par au moins une portion du train annonce lorsque le canton suivant est occupé voie libre par défaut (sauf signaux Nf) La longueur maximale d’un canton est en principe de 2800 m. Elle est généralement de 1500 m sur les lignes parcourues à la vitesse maximale de 160 km/h.\nAvantages du BAL Le BAL offre un niveau élevé de sécurité et permet un débit important.\nLimites L’installation du BAL est très coûteuse, et son fonctionnement nécessite une garantie de contact électrique entre la roue et le rail.\nImplémentation Simuler correctement le système BAL nécessite de respecter les critères suivants :\nlorsque la tête du train pénètre dans un canton, le signal d’entrée de celui-ci passe en indication d’arrêt lorsque la queue du train libère un canton, son signal d’entrée passe en annonce lorsque la queue du train libère un canton, le signal d’entrée du canton précédent passe en voie libre les signaux présentent une voie libre par défaut, sauf les signaux Nf qui sont par défaut en indication d’arrêt ","categories":"","description":"Block Automatique Lumineux","excerpt":"Block Automatique Lumineux","ref":"/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bal/","tags":"","title":"BAL"},{"body":"Le signal d’entrée du canton est un signal qui présente une indication liée à l’état d’occupation du canton suivant (indication d’arrêt ou de voie libre). Sur certaines lignes l’occupation du canton n’est pas obtenue par le circuit de voie mais par un système de comptage d’essieux entrants et sortants.\nLes cantons sont beaucoup plus longs que le BAL (jusqu’à 15 km et plus) et par conséquent le débit est moins important.\nAvantages du BAPR Le BAPR offre un bon niveau de sécurité et il est moins coûteux que le BAL.\nLimites Ce type de block n’est adapté qu’aux lignes conventionnelles à trafic moyen compte tenu de l’espacement imposé entre 2 trains successifs.\n","categories":"","description":"Block Automatique à Permitivité Restreinte","excerpt":"Block Automatique à Permitivité Restreinte","ref":"/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bapr/","tags":"","title":"BAPR"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/categories/","tags":"","title":"Categories"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/categories/","tags":"","title":"Categories"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/docs/reference/apis/editoast/","tags":"","title":"Editoast"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/docs/reference/apis/editoast/","tags":"","title":"Editoast"},{"body":"Introduction L’ERTMS, pour European Rail Traffic Management System, est un système qui vise à harmoniser la signalisation ferroviaire en Europe.\nIl est composé de trois sous-systèmes :\nun système de signalisation : l’ETCS un système de communication : GSM-R / GPRS / FRMCS un système de gestion du traffic : l’ETML ","categories":"","description":"European Rail Traffic Management System","excerpt":"European Rail Traffic Management System","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/","tags":"","title":"ERTMS"},{"body":"","categories":"","description":"The European Train Control System, part of ERTMS","excerpt":"The European Train Control System, part of ERTMS","ref":"/en/docs/railway-wiki/signalling/spacing/ertms/","tags":"","title":"ETCS (ERTMS)"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/docs/reference/apis/gateway/","tags":"","title":"Gateway"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/docs/reference/apis/gateway/","tags":"","title":"Gateway"},{"body":"The team dedicated to OSRD within SNCF Réseau is always keen to hear from new profiles: if working on the project motivates you, send us a message on contact@osrd.fr!\n","categories":"","description":"","excerpt":"The team dedicated to OSRD within SNCF Réseau is always keen to hear …","ref":"/en/join-us/","tags":"","title":"Join us"},{"body":"L’équipe dédiée à OSRD au sein de SNCF Réseau est toujours intéressée par de nouveaux profils : si travailler sur le projet vous motive, envoyez-nous un message sur contact@osrd.fr !\n","categories":"","description":"","excerpt":"L’équipe dédiée à OSRD au sein de SNCF Réseau est toujours intéressée …","ref":"/fr/join-us/","tags":"","title":"Rejoignez-nous"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/search/","tags":"","title":"Search Results"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/tags/","tags":"","title":"Tags"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/tags/","tags":"","title":"Tags"}] \ No newline at end of file diff --git a/offline-search-index.e9842b231b04e10ba94e44ad11bfba07.json b/offline-search-index.e9842b231b04e10ba94e44ad11bfba07.json deleted file mode 100644 index 727b951c7..000000000 --- a/offline-search-index.e9842b231b04e10ba94e44ad11bfba07.json +++ /dev/null @@ -1 +0,0 @@ -[{"body":" Explain what you’re doing and why. Document new code with doc comments. Include clear, simple tests. Break work into digestible chunks. Take the time to pick good names. Avoid non well-known abbreviations. Control and consistency over 3rd party code reuse: Only add a dependency if it is absolutely necessary. Every dependency we add decreases our autonomy and consistency. We try to keep PRs bumping dependencies to a low number each week in each component, so grouping dependency bumps in a batch PR is a valid option (see component’s README.md). Don’t reinvent every wheel: as a counter to the previous point, don’t reinvent everything at all costs. If there is a dependency in the ecosystem that is the “de facto” standard, we should heavily consider using it. More code general recommendations in main repository CONTRIBUTING.md. Ask for any help that you need! Consult back-end conventions ‣\nConsult front-end conventions ‣\nContinue towards write code ‣\nContinue towards tests ‣\n","categories":"","description":"Please read this first!","excerpt":"Please read this first!","ref":"/en/docs/guides/contribute/contribute-code/general-principles/","tags":"","title":"General principles"},{"body":"First off, thanks for taking the time to contribute!\nThe following chapters are a set of guidelines for contributing to OSRD. These guidelines are mostly not strict rules, it’s probably fine to do things slightly differently. If you have already contributed to open source projects before, you probably won’t be surprised. If you have not, it will probably help a lot!\nCommunicate Chatting with other contributors is a great way to speed things up:\nCreate an issue to discuss your contribution project. Inquire Just like with any project, changes rely on past work. Before making changes, it is best to learn about what’s already there:\nread technical documentation read the existing source code related to your project chat with developers who last worked on areas you are interested in Continue towards initial set-up ‣\n","categories":"","description":"An introduction to contributing to OSRD","excerpt":"An introduction to contributing to OSRD","ref":"/en/docs/guides/contribute/preamble/","tags":"","title":"Preamble"},{"body":"Déjà, merci de prendre le temps de contribuer !\nSi les sections suivantes forment un guide du contributeur, ce n’est pas pour autant un ensemble de règles strictes. En fait, si vous avez déjà contribué à des gros projets open-source, la suite ne sera pas surprenante. Dans le cas contraire, elle vous sera probablement très utile !\nCommuniquer Vous pouvez gagner du temps en discutant de votre projet de contribution avec les autres contributeurs :\nCréez une issue pour avoir un endroit pour discuter de votre contribution. Se renseigner Comme dans tout projet, chaque changement repose sur ce qui a été fait par le passé. Avant d’apporter un changement, renseignez-vous sur l’existant :\nVous pouvez lire la documentation technique Il est préférable de lire le code source de l’application en rapport avec votre projet Vous pouvez contacter les derniers développeurs à avoir travaillé sur les zones du code en rapport avec votre projet Continuer vers la mise en place ‣\n","categories":"","description":"Quelques premières informations importantes.","excerpt":"Quelques premières informations importantes.","ref":"/fr/docs/guides/contribute/preamble/","tags":"","title":"Avant toutes choses"},{"body":" Expliquez ce que vous faites et pourquoi. Documentez le nouveau code. Ajoutez des tests clairs et simples. Décomposez le travail en morceaux intelligibles. Prenez le temps de choisir de bons noms. Évitez les abréviations peu connues. Contrôle et cohérence de la réutilisation du code de tiers : une dépendance est ajoutée seulement si elle est absolument nécessaire. Chaque dépendance ajoutée diminue notre autonomie et notre cohérence. Nous essayons de limiter à un petit nombre les PRs de mise à jour des dépendances chaque semaine dans chaque composant, donc regrouper les montées de version dans une même PR est une bonne option (reportez-vous au README.md de chaque composant). Ne pas réinventer la roue : en opposition au point précédent, ne réinventez pas tout à tout prix. S’il existe une dépendance dans l’écosystème qui est le standard « de facto », nous devrions fortement envisager de l’utiliser. Plus de code et de recommandations générales dans le dépôt principal CONTRIBUTING.md. Demandez toute l’aide dont vous avez besoin ! Consulter les conventions pour le back-end ‣\nConsulter les conventions pour le front-end ‣\nContinuer vers l’écriture de code ‣\nContinuer vers l’écriture de tests ‣\n","categories":"","description":"À lire en premier !","excerpt":"À lire en premier !","ref":"/fr/docs/guides/contribute/contribute-code/general-principles/","tags":"","title":"Principes généraux"},{"body":"Python Python code is used for some packages and integration testing.\nFollow the Zen of Python. Code is linted with flake8. Code is formatted with Black. Imports are sorted with Isort. Python tests are written using pytest. Typing is checked using pytype. Rust As a reference for our API development we are using the Rust API guidelines. Generally, these should be followed. Prefer granular imports over glob imports like diesel::*. Tests are written with the built-in testing framework. Use the documentation example to know how to phrase and format your documentation. Use consistent comment style: /// doc comments belong above #[derive(Trait)] invocations. // comments should generally go above the line in question, rather than in-line. Start comments with capital letters. End them with a period if they are sentence-like. Use comments to organize long and complex stretches of code that can’t sensibly be refactored into separate functions. Code is linted with clippy. Code is formatted with fmt. Java Code is formatted with checkstyle. ","categories":"","description":"Coding style guide and best practices for back-end","excerpt":"Coding style guide and best practices for back-end","ref":"/en/docs/guides/contribute/contribute-code/backend-conventions/","tags":"","title":"Back-end conventions"},{"body":"Python Le code Python est utilisé pour certains paquets et pour les tests d’intégration.\nSuivez le Zen of Python. Le code est linté avec flake8. Le code est formaté avec Black. Les imports sont triées avec Isort. Les tests sont écrits avec pytest. Les types sont vérifiés avec pytype. Rust Comme référence pour le développement de notre API, nous utilisons les Rust API guidelines. D’une manière générale, il convient de les respecter. Préférer les importations granulaires aux importations globales comme diesel::*. Les tests sont écrits avec le framework de base. Utilisez l’exemple de documentation pour savoir comment formuler et formater votre documentation. Utilisez un style de commentaire cohérent : /// les commentaires de la documentation sont au-dessus des invocations #[derive(Trait)]. Les commentaires // doivent généralement être placés au-dessus de la ligne en question, plutôt qu’en ligne. Les commentaires commencent par des lettres majuscules. Terminez-les par un point s’ils ressemblent à une phrase. Utilisez les commentaires pour organiser des portions de code longues et complexes qui ne peuvent être raisonnablement remaniées en fonctions distinctes. Le code est linté avec clippy. Le code est formaté avec fmt. Java Le code est formaté avec checkstyle. ","categories":"","description":"Conventions de codes et bonnes pratiques pour le back-end","excerpt":"Conventions de codes et bonnes pratiques pour le back-end","ref":"/fr/docs/guides/contribute/contribute-code/backend-conventions/","tags":"","title":"Conventions back-end"},{"body":"Nous utilisons ReactJS et tous les fichiers doivent être écrits en Typescript.\nLe code est linté avec eslint, et formaté avec prettier.\nNomenclature Les applications (osrd eex, osrd stdcm, éditeur infra, éditeur matériel) proposent des vues (gestion des projets, gestions des études, etc.) liées à des modules (projet, étude, etc.) qui contiennent les composants.\nCes vues sont constituées de composants et sous-composants tous issus des modules. En plus de contenir les fichiers de vues des applications, elles peuvent contenir un répertoire scripts qui propose des scripts liés à ces vues. Les vues déterminent la logique et l’accès au store.\nLes modules sont des collections de composants rattachés à un objet (un scénario, un matériel roulant, un TrainSchedule). Ils contiennent :\nun répertoire components qui héberge tous les composants un répertoire styles optionnel par module pour le style des composants en scss un répertoire assets optionnel par module (qui contient les assets, de jeux de données par défaut par ex, spécifiques au module) un fichier reducers optionnel par module un fichier types optionnel par module un fichier consts optionnel par module Un répertoire assets (qui contient les images et autre fichiers).\nEnfin, un répertoire common qui propose :\nun répertoire utils pour les fonctions utilitaires communes à l’ensemble du projet un fichier types pour les types communs à l’ensemble du projet un fichier consts pour les constantes communes à l’ensemble du projet Principes d’implémentation Routage \u0026 SLUG Rédaction en cours\nprojects/{nom du projet}/studies/{nom de l'étude}/scenarios/{nom du scenario}\nStyles \u0026 SCSS ATTENTION : en CSS/React, le scope d’une classe ne dépend pas de l’endroit où le fichier est importé mais est valide pour toute l’application. Si vous importez un fichier scss au fin fond d’un composant (ce que nous déconseillons fortement par ailleurs), ses classes seront disponibles pour toute l’application et peuvent donc provoquer des effets de bord. Vous pouvez utiliser les CSS modules pour éviter les conflits.\nIl est donc très recommandé de pouvoir facilement suivre l’arborescence des applications, vues, modules et composants également au sein du code SCSS, et notamment imbriquer les noms de classes pour éviter les effets de bord, le compilateur se chargera de fabriquer la hiérarchie nécessaire.\nSi par exemple nous avons un composant rollingStockSelector qui propose une liste de matériel rollingStockList représentés par des cartes rollingStockCard contenant une image représentant le matériel roulant rollingStockImg nous devrions avoir la structure SCSS suivante :\n.rollinStockSelector { .rollingStockList { .rollingStockCard { .rollingStockImg { width: 5rem; height: auto; } } } } Ainsi, on a la garantie que l’image contenue dans la carte de matériel roulant héritera bien des bonnes propriétés css .rollinStockSelector.rollingStockList.rollingStockCard.rollingStockImg.\nCSS Modules Les CSS modules permettent de scoper les styles CSS à un composant spécifique, évitant ainsi les conflits de noms de classe globaux.\nVite prend en charge nativement les CSS modules. Assurez-vous que votre fichier CSS a l’extension .module.css. Par exemple, styles.module.css.\nUtilisation des CSS modules dans les composants Créez un fichier SCSS avec l’extension .module.scss : /* MyComponent.module.scss */ .container { background-color: white; } .title { font-size: 24px; color: #333; } Utilisez les classes dans votre composant React : Vite transforme les classes en objets qui contiennent les classes hashées (exemple _container_h3d8bg) et les utilise au moment de la génération du bundle, rendant ainsi les classes uniques.\nimport React from \"react\"; import styles from \"./MyComponent.module.scss\"; export function MyComponent() { return ( \u003cdiv className={styles.container}\u003e \u003ch1 className={styles[\"title\"]}\u003eMon Titre\u003c/h1\u003e \u003c/div\u003e ); } Pour plus d’information, vous pouvez regarder la documentation de vite.js\nNoms de classes, utilisation de cx() Les classes sont ajoutées les unes à la suite des autres, normalement, dans la propriété className=\"\".\nCependant, quand cela est nécessaire — tests pour l’utilisation d’une classe, concaténation, etc. — nous utilisons la bibliothèque classnames qui préconise l’usage suivant :\n\u003cdiv className=\"rollingStockSelector\"\u003e \u003cdiv className=\"rollingStockList\"\u003e \u003cdiv className=\"rollingStockCard w-100 my-2\"\u003e \u003cimg className={cx(\"rollingStockImg\", \"m-2\", \"p-1\", \"bg-white\", { valid: isValid(), selected: rollingStockID === selectedRollingStockID, })} /\u003e \u003c/div\u003e \u003c/div\u003e \u003c/div\u003e Les classes sont séparées chacune dans un string et les opérations booléennes ou autres sont réalisées dans un objet qui retournera — ou pas — le nom de propriété comme nom de classe à utiliser dans le CSS.\nStore/Redux Tout ce qui est selector est géré par la vue et passé en props aux composants et sous-composants.\nPar conséquent les appels au store en lecture et en écriture doivent être passés un niveau de la vue, en irrigant par des props et states les composants proposées par la vue.\nRTK Utiliser les endpoints générés à partir des fichiers openapi.yaml pour consommer le backend.\nFonctionnement du cache dans RTK Query Lorsque de la donnée est récupérée depuis le back, RTK va mettre cette donnée en cache dans le store. Si le même endpoint est appelé avec les même paramètres, RTK va réutiliser la donnée dans le cache plutôt que de rappeler le back.\nDans le store, vous verrez cette clé editoastApi qui contient la donnée en cache de tous les endpoints editoast :\nIci par exemple l’endpoint getProjects a été appelé.\nRTK stocke le nom de l’endpoint, ainsi que les paramètres d’appel, pour former une clé unique nomDuEndpoint({ paramètres }). (ici getProjects({\"ordering\":\"LastModifiedDesc\",\"pageSize\":1000})).\n{ 'getProjectsByProjectIdStudiesAndStudyId({\"projectId\":13,\"studyId\":16})': { status :\"fulfilled\", etc… }, 'getProjectsByProjectIdStudiesAndStudyId({\"projectId\":13,\"studyId\":14})': { … } } Dans ce deuxième exemple, le même endpoint a été appelé avec le même paramètre projectId, mais un paramètre studyId différent.\nSérialisation des clés dans le cache Les string utilisées comme clé dans le cache sont à peu de choses près l’objet paramètre passé à la moulinette JSON.stringify que transforme un object JS en string (donc sérialisé).\nNormalement La sérialisation ne conserve pas l’ordre des clés des objets. Par exemple, JSON.stringify ne produira pas la même string avec ces deux objets: { a: 1, b: 2 } et { b: 2, a: 1 }.\nRTK va optimiser la mise en cache en faisant en sorte que le résultat d’un appel avec {\"projectId\":13,\"studyId\":16} ou {\"studyId\":16, \"projectId\":13} soient stockées dans la même clé dans le cache.\nPour voir le fonctionnement en détail, voici le code de cette fonction de sérialisation :\nFonction de sérialisation RTK const defaultSerializeQueryArgs: SerializeQueryArgs\u003cany\u003e = ({ endpointName, queryArgs, }) =\u003e { let serialized = '' const cached = cache?.get(queryArgs) if (typeof cached === 'string') { serialized = cached } else { const stringified = JSON.stringify(queryArgs, (key, value) =\u003e isPlainObject(value) ? Object.keys(value) .sort() // les clés sont remises dans l’ordre ici .reduce\u003cany\u003e((acc, key) =\u003e { acc[key] = (value as any)[key] return acc }, {}) : value ) if (isPlainObject(queryArgs)) { cache?.set(queryArgs, stringified) } serialized = stringified } // Sort the object keys before stringifying, to prevent useQuery({ a: 1, b: 2 }) having a different cache key than useQuery({ b: 2, a: 1 }) return `${endpointName}(${serialized})` } Souscriptions à la donnée Dans la terminologie de RTK query, Lorsqu’un composant react appelle un endpoint défini dans RTK Query, il souscrit à la donnée.\nRTK compte le nombre de référence à la même paire (endpoint,{paramètres}). Lorsque deux composants souscrivent à la même donnée. Ils partagent la même clé dans le cache.\nimport { osrdEditoastApi } from \"./api.ts\"; function Component1() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(1); return \u003cdiv\u003e...\u003c/div\u003e; } function Component2() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(2); return \u003cdiv\u003e...\u003c/div\u003e; } function Component3() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(3); return \u003cdiv\u003e...\u003c/div\u003e; } function Component4() { // component subscribes to the *same* data as ComponentThree, // as it has the same query parameters const { data } = osrdEditoastApi.useGetXQuery(3); return \u003cdiv\u003e...\u003c/div\u003e; } Ici Component3 et Component4 ne vont générer qu’un seul appel vers le back. Ils souscrivent à la même donnée (même endpoint et même paramètre 3). Ils vont partager la même clé dans le cache.\nAu total ici il y aura trois appels vers le back, avec les paramètres 1, 2, 3.\nTant qu’il existe au moins un composant react monté, qui appelle le hook osrdEditoastApi.endpoints.getProjectsByProjectId.useQuery par exemple, la donnée sera conservée dans le cache.\nDès que le dernier composant est démonté, la donnée est supprimée du cache au bout de 60 secondes (valeur par défaut).\nTraduction de l’application La traduction de l’application est effectuée sur Transifex. La langue par défaut est le français. A noter que si l’on doit corriger une traduction, il est recommandé de passer par Transifex. En revanche, si on ajoute une nouvelle clé de traduction, celle-ci peut être ajoutée dans le code directement, dans toutes les langues disponibles.\nLois et éléments importants Aucun composant ne doit détenir la responsabilité de mise à jour de la donnée qu’il utilise Seules les vues contiennent les sélecteurs du store, donnés ensuite en props aux composants du module lié à la vue.\nLe SCSS n’est pas scopé Un fichier .scss enfoui dans l’arborescence ne vous garantit pas que les classes contenues soient seulement accessibles à cet endroit, y compris par import react (formellement interdit au passage : vous devez utiliser l’import SCSS), toutes les classes déclarées sont accessibles partout.\nPréférez un choix judicieux de nom de classe racine pour un module donné et utilisez l’arborescence possible dans le fichier SCSS.\nLes imports doivent être triés d’une certaine manière ESLint est configuré pour trier automatiquement les imports en 4 groupes, chacun trié alphabétiquement :\nReact Librairies externes Fichiers internes en chemin absolu Fichiers internes en chemin relatif Chacun de ces groupes est séparé par une ligne vide.\nESLint déclenchera un avertissement si ces recommandations ne sont pas respectées.\nLes liens des imports doivent être absolus Vous devez utiliser le chemin complet pour tous vos imports.\nLe chemin peut être relatif seulement si le fichier à importer est dans le même répertoire.\nTypeScript import \u0026 export ESLint et Typescript sont configurés pour imposer l’import type pour un import de type.\nCeci permet de :\nAutomatiquement ajouter type devant l’import quand on ajoute un type avec l’autocomplétion dans un fichier. Afficher 2 erreurs de chacun de ces packages demandant d’ajouter type devant l’import si vous ne l’avez pas fait. Lorsque qu’un import ou un export ne comporte que des types, il faut l’indiquer par le mot clé type.\nexport type { Direction, DirectionalTrackRange as TrackRange }; import type { typedEntries, ValueOf } from \"utils/types\"; Quand un import ne contient pas que des types, il sera agencé de cette manière, par ordre alphabétique.\nimport { osrdEditoastApi, type ScenarioCreateForm, } from \"common/api/osrdEditoastApi\"; Cette pratique permet de :\nAméliorer les performances et le travail d’analyse du compilateur et du linter. Rendre ces déclarations plus lisibles, on voit clairement ce qu’on est en train d’importer. Éviter des cycles de dépendances : L’erreur disparaît avec le mot clé type\nAlléger le bundle final (tous les types disparaissent à la compilation). ","categories":"","description":"Conventions de codes et bonnes pratiques pour le front-end","excerpt":"Conventions de codes et bonnes pratiques pour le front-end","ref":"/fr/docs/guides/contribute/contribute-code/frontend-conventions/","tags":"","title":"Conventions front-end"},{"body":"We use ReactJS and all files must be written in Typescript.\nThe code is linted with eslint, and formatted with prettier.\nNomenclature The applications (osrd eex, osrd stdcm, infra editor, rolling-stock editor) offer views (project management, study management, etc.) linked to modules (project, study, etc.) which contain the components.\nThese views are made up of components and sub-components all derived from the modules. In addition to containing the views files for the applications, they may also contain a scripts directory which offers scripts related to these views. The views determine the logic and access to the store.\nModules are collections of components attached to an object (a scenario, a rolling stock, a TrainSchedule). They contain :\na components directory hosting all components an optional styles directory per module for styling components in scss an optional assets directory per module (which contains assets, e.g. default datasets, specific to the module) an optional reducers file per module an optional types file per module an optional consts file per module An assets directory (containing images and other files).\nLast but not least, a common directory offering :\na utils directory for utility functions common to the entire project a types file for types common to the entire project a consts file for constants common to the entire project Implementation principles Routing \u0026 SLUG In progress\nprojects/{nom du projet}/studies/{nom de l'étude}/scenarios/{nom du scenario}\nStyles \u0026 SCSS WARNING: in CSS/React, the scope of a class does not depend on where the file is imported, but is valid for the entire application. If you import an scss file in the depths of a component (which we strongly advise against), its classes will be available to the whole application and may therefore cause side effects.\nIt is therefore highly recommended to be able to easily follow the tree structure of applications, views, modules and components also within the SCSS code, and in particular to nest class names to avoid edge effects, as the compiler will take care of making the necessary hierarchy.\nIf, for example, we have a rollingStockSelector component which proposes a list of rolling stock rollingStockList represented by rollingStockCard containing an image representing the rolling stock rollingStockImg we should have the following SCSS structure:\n.rollinStockSelector { .rollingStockList { .rollingStockCard { .rollingStockImg { width: 5rem; height: auto; } } } } This ensures that the image contained in the rolling stock card inherits the correct css properties .rollinStockSelector.rollingStockList.rollingStockCard.rollingStockImg.\nCSS Modules CSS modules allow scoping CSS styles to a specific component, thereby avoiding conflicts with global class names.\nVite natively supports CSS modules. Ensure that your CSS file has the .module.css extension, for example, styles.module.css.\nUsing CSS Modules in Components Create an SCSS file with the .module.scss extension: /* MyComponent.module.scss */ .container { background-color: white; } .title { font-size: 24px; color: #333; } Use the classes in your React component: Vite transforms classes into objects that contain hashed classes (e.g., _container_h3d8bg) and uses them during bundle generation, making the classes unique.\nimport React from \"react\"; import styles from \"./MyComponent.module.scss\"; export function MyComponent() { return ( \u003cdiv className={styles.container}\u003e \u003ch1 className={styles[\"title\"]}\u003eMy Title\u003c/h1\u003e \u003c/div\u003e ); } For more information, you can refer to the Vite.js documentation.\nClass names, using cx(). Classes are normally added one after the other, in the className=\"\" property.\nHowever, when necessary - class usage tests, concatenation, etc. - we use the classnames library, which recommends the following usage:\n\u003cdiv className=\"rollingStockSelector\"\u003e \u003cdiv className=\"rollingStockList\"\u003e \u003cdiv className=\"rollingStockCard w-100 my-2\"\u003e \u003cimg className={cx(\"rollingStockImg\", \"m-2\", \"p-1\", \"bg-white\", { valid: isValid(), selected: rollingStockID === selectedRollingStockID, })} /\u003e \u003c/div\u003e \u003c/div\u003e \u003c/div\u003e Classes are separated each in a string and Boolean or other operations are performed in an object that will return - or not - the property name as the class name to be used in CSS.\nStore/Redux Everything that is selector is managed by the view and passed as props to components and sub-components.\nConsequently, read and write calls to the store must be made at view level, irrigating the components proposed by the view with props and states.\nRTK Use generated endpoints from openapi.yaml files to consume the backend.\nOperation of RTK Query cache When the data is retrieved from the back, RTK is caching it into the store. If the same endpoint is called again with same parameters, RTK will use the cache data instead of making a new call to the back.\nIn the store, you will see the editoastApi key containing the cached data of all editoast endpoints:\nHere for example, the getProjects endpoint is called.\nRTK stores the endpoint’s name, as well as the call’s parameters, to form an unique key nomDuEndpoint({ paramètres }). (here getProjects({\"ordering\":\"LastModifiedDesc\",\"pageSize\":1000})).\n{ 'getProjectsByProjectIdStudiesAndStudyId({\"projectId\":13,\"studyId\":16})': { status :\"fulfilled\", etc… }, 'getProjectsByProjectIdStudiesAndStudyId({\"projectId\":13,\"studyId\":14})': { … } } In this second example, the same endpoint has been called with the ssame projectId parameter, but a different studyId parameter.\nSerialization of keys in the cache The strings used as keys in the cache are essentially the parameter object passed through the JSON.stringify function, which converts a JS object into a string (thus serialized).\nNormally, serialization does not preserve the order of object keys. For example, JSON.stringify will not produce the same string with these two objects: { a: 1, b: 2 } and { b: 2, a: 1 }.\nRTK will optimize caching by ensuring that the result of a call with {\"projectId\":13,\"studyId\":16} or {\"studyId\":16, \"projectId\":13} is stored under the same key in the cache.\nTo see the detailed operation, here is the code for this serialization function:\nRTK Serialization Function const defaultSerializeQueryArgs: SerializeQueryArgs\u003cany\u003e = ({ endpointName, queryArgs, }) =\u003e { let serialized = '' const cached = cache?.get(queryArgs) if (typeof cached === 'string') { serialized = cached } else { const stringified = JSON.stringify(queryArgs, (key, value) =\u003e isPlainObject(value) ? Object.keys(value) .sort() // keys are reordered here .reduce\u003cany\u003e((acc, key) =\u003e { acc[key] = (value as any)[key] return acc }, {}) : value ) if (isPlainObject(queryArgs)) { cache?.set(queryArgs, stringified) } serialized = stringified } // Sort the object keys before stringifying, to prevent useQuery({ a: 1, b: 2 }) having a different cache key than useQuery({ b: 2, a: 1 }) return `${endpointName}(${serialized})` } Data subscription In RTK Query terminology, when a React component calls an endpoint defined in RTK Query, it subscribes to the data.\nRTK counts the number of references to the same pair (endpoint, {parameters}). When two components subscribe to the same data, they share the same key in the cache.\nimport { osrdEditoastApi } from \"./api.ts\"; function Component1() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(1); return \u003cdiv\u003e...\u003c/div\u003e; } function Component2() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(2); return \u003cdiv\u003e...\u003c/div\u003e; } function Component3() { // component subscribes to the data const { data } = osrdEditoastApi.useGetXQuery(3); return \u003cdiv\u003e...\u003c/div\u003e; } function Component4() { // component subscribes to the *same* data as ComponentThree, // as it has the same query parameters const { data } = osrdEditoastApi.useGetXQuery(3); return \u003cdiv\u003e...\u003c/div\u003e; } Here, Component3 and Component4 will generate only one call to the backend. They subscribe to the same data (same endpoint and same parameter 3). They will share the same key in the cache.\nIn total, there will be three calls to the backend here, with parameters 1, 2, and 3.\nAs long as at least one mounted React component calls the osrdEditoastApi.endpoints.getProjectsByProjectId.useQuery hook, for example, the data will be retained in the cache.\nOnce the last component is unmounted, the data is removed from the cache after 60 seconds (default value).\nTranslation Application translation is performed on Transifex. The default language is French. If you add a new translation key, it can be added directly to the code, in all available languages. Please note that if you need to correct a translation, we recommend that you use Transifex, to avoid any conflict.\nRules and important elements No component should be responsible for updating the data it uses Only views contain the store selectors, which are then given as props to the components of the module linked to the view.\nSCSS is not scoped A .scss file buried in the tree structure doesn’t guarantee that the classes it contains can only be accessed there, even by importing react (formally forbidden by the way: you must use SCSS import), all declared classes are accessible everywhere.\nPrefer a judicious choice of root class name for a given module, and use the tree structure available in the SCSS file.\nImports must follow a specific order ESLint is setup to automatically sort imports in four import groups, each of them sorted in alphabetical order :\nReact External libraries Internal absolute path files Internal relative path files Each of these groups will be separated by an empty line.\nESLint will trigger a warning if you don’t follow these guidelines.\nImport links must be absolute You must use the full path for all your imports.\nImport links can be relative only if the file to be imported is in the same directory.\nTypeScript import \u0026 export ESLint and Typescript are setup to enforce typed imports for an exported type.\nThis current setup allows to :\nAuto typing the import when using a type in a file with autocompletion. Getting 2 errors from each package asking to use type import if you didn’t. When an import or export contains only types, indicate it with the type keyword.\nexport type { Direction, DirectionalTrackRange as TrackRange }; import type { typedEntries, ValueOf } from \"utils/types\"; When an import contains not only types, it will be structured like below, in alphabetical order.\nimport { osrdEditoastApi, type ScenarioCreateForm, } from \"common/api/osrdEditoastApi\"; This allows to:\nImprove the performance and analysis process of the compiler and the linter. Make these declarations more readable; we can clearly see what we are importing. Avoid dependency cycles: The error disappears with the type keyword\nMake final bundle lighter (all types disappear at compilation) ","categories":"","description":"Coding style guide and best practices for front-end","excerpt":"Coding style guide and best practices for front-end","ref":"/en/docs/guides/contribute/contribute-code/frontend-conventions/","tags":"","title":"Front-end conventions"},{"body":"La licence des contributions de code Tout le code du dépot OSRD est mis à disposition sous la licence LGPLv3. En contribuant du code, vous acceptez la redistribution de votre contribution sous cette license.\nLa licence LGPL interdit de modifier OSRD sans publier le code source de l’application modifiée : profitez du travail des autres, et laissez les autres profiter de votre travail !\nCette contrainte n’est pas contagieuse à travers les API : Il est possible d’utiliser OSRD comme bibliothèque, framework ou serveur pour s’interfacer avec des composants propriétaires. N’hésitez pas à proposer des changements pour répondre à vos besoins.\nMise en place La plupart des développeurs OSRD utilisent Linux (y compris WSL). Vous pouvez utiliser Windows ou MacOS, mais pourriez rencontrer quelques problèmes. Obtenir le code source Installer git1 Ouvrir un terminal2 dans le dossier qui contiendra le code source d’OSRD git clone https://github.com/OpenRailAssociation/osrd.git Lancer l’application Docker est un outil qui réduit considérablement la préparation nécessaire pour travailler sur OSRD:\ntélécharger le dernier build de développement : docker compose pull démarrer OSRD : docker compose up compiler et démarrer OSRD: docker compose up --build review une PR avec les images compilées par la CI: TAG=pr-XXXXX docker compose up --no-build --pull always Pour commencer :\nInstaller docker Suivre le README d’OSRD. Continuer vers la contribution au code ‣\nSous Linux, utilisez le gestionnaire de packet (comme apt) ↩︎\nSous Windows, ouvrez Git Bash ↩︎\n","categories":"","description":"Comment mettre en place l'environnement de développement ? Qu'implique notre licence ?","excerpt":"Comment mettre en place l'environnement de développement ? Qu'implique …","ref":"/fr/docs/guides/contribute/license-and-set-up/","tags":"","title":"Licence et mise en place"},{"body":"License of code contributions The source code of OSRD is available under the LGPLv3 license. By contributing to the codebase, you consent to the distribution of your changes under the project’s license.\nLGPLv3 forbids modifying source code without sharing the changes under the same license: use other people’s work, and share yours!\nThis constraint does not propagate through APIs: You can use OSRD as a library, framework or API server to interface with proprietary software. Please suggest changes if you need new interfaces.\nSet things up Most OSRD developers use Linux (incl. WSL). Windows and MacOS should work too, but you may run into some issues. Get the source code Install git.1 Open a terminal2 in the folder where the source code of OSRD will be located Run git clone https://github.com/OpenRailAssociation/osrd.git Launch the application Docker is a tool which greatly reduces the amount of setup required to work on OSRD:\ndownload the latest development build: docker compose pull start OSRD: docker compose up build and start OSRD: docker compose up --build review a PR using CI built images: TAG=pr-XXXXX docker compose up --no-build --pull always To get started:\nInstall docker Follow OSRD’s README. Continue towards code contribution ‣\nUnder Linux, use the package manager (such as apt) ↩︎\nUnder Windows, open Git Bash ↩︎\n","categories":"","description":"How to set up your development environment? What does our license involve?","excerpt":"How to set up your development environment? What does our license …","ref":"/en/docs/guides/contribute/license-and-set-up/","tags":"","title":"License and set-up"},{"body":"Ce chapitre décrit le processus aboutissant à l’intégration de code au sein du projet. Si vous avez besoin d’aide, ouvrez une issue ou envoyez un message instantané.\nL’application OSRD est divisée en plusieurs services écrits dans plusieurs langues. Nous essayons de suivre les bonnes pratiques générales en matière de code et de respecter les spécificités de chaque langage lorsque cela est nécessaire.\n","categories":"","description":"Apporter des modifications au code d'OSRD","excerpt":"Apporter des modifications au code d'OSRD","ref":"/fr/docs/guides/contribute/contribute-code/","tags":"","title":"Contribuer au code"},{"body":"This chapter is about the process of integrating changes into the common code base. If you need help at any stage, open an issue or message us.\nOSRD application is split in multiple services written in several languages. We try to follow general code best practices and follow each language specificities when required.\n","categories":"","description":"Integrate changes into OSRD","excerpt":"Integrate changes into OSRD","ref":"/en/docs/guides/contribute/contribute-code/","tags":"","title":"Contribute code"},{"body":" Si vous n’être pas un habitué de Git, suivez ce tutoriel\nCréez une branche\nSi vous comptez contribuer régulièrement, vous pouvez demander accès au dépot principal. Sinon, créez un fork.\nAjoutez des changements sur votre branche\nEssayez de découper votre travail en étapes macroscopiques, et sauvegardez vos changements dans un commit à la fin de chaque étape. Essayez de suivre les conventions du projet.\nConservez votre branche à jour\ngit switch \u003cyour_branch\u003e git fetch git rebase origin/dev Continuer vers le style des commits ‣\n","categories":"","description":"Apporter des modifications au code d'OSRD","excerpt":"Apporter des modifications au code d'OSRD","ref":"/fr/docs/guides/contribute/contribute-code/write-code/","tags":"","title":"Écrire du code"},{"body":" If you are not used to Git, follow this tutorial\nCreate a branch\nIf you intend to contribute regularly, you can request access to the main repository. Otherwise, create a fork.\nAdd changes to your branch\nBefore you start working, try to split your work into macroscopic steps. At the end of each stop, save your changes into a commit. Try to make commits of logical and atomic units. Try to follow style conventions.\nKeep your branch up-to-date\ngit switch \u003cyour_branch\u003e git fetch git rebase origin/dev Continue towards commit style ‣\n","categories":"","description":"Integrate changes into OSRD","excerpt":"Integrate changes into OSRD","ref":"/en/docs/guides/contribute/contribute-code/write-code/","tags":"","title":"Write code"},{"body":"Commit style The overall format for git commits is as follows:\ncomponent1, component2: imperative description of the change Detailed or technical description of the change and what motivates it, if it is not entirely obvious from the title. the commit message, just like the code, must be in english (only ASCII characters for the title) there can be multiple components separated by : in case of hierarchical relationships, with , otherwise components are lower-case, using -, _ or . if necessary the imperative description of the change begins with a lower-case verb the title must not contain any link (# is forbidden) Ideally:\nthe title should be self-explanatory: no need to read anything else to understand it the commit title is all lower-case the title is clear to a reader not familiar with the code the body of the commit contains a detailled description of the change An automated check is performed to enforce as much as possible this formating. Counter-examples of commit titles To be avoided entirely:\ncomponent: update ./some/file.ext: specify the update itself rather than the file, the files are technical elements welcome in the body of the commit component: fix #42: specify the problem fixed in the title, links (to issue, etc.) are very welcome in commit’s body wip: describe the work (and finish it) Welcome to ease review, but do not merge:\nfixup! previous commit: an autosquash must be run before the merge Revert \"previous commit of the same PR\": both commits must be dropped before merging The Developer Certificate of Origin (DCO) All of OSRD’s projects use the DCO (Developer Certificate of Origin) to address legal matters. The DCO helps confirm that you have the rights to the code you contribute. For more on the history and purpose of the DCO, you can read The Developer Certificate of Origin by Roscoe A. Bartlett.\nTo comply with the DCO, all commits must include a Signed-off-by line.\nHow to sign a commit using git in a shell ? To sign off a commit, simply add the -s flags to your git commit command, like so:\ngit commit -s -m \"Your commit message\" This also applies when using the git revert command.\nHow to do sign a commit using git in Visual Studio Code (VS Code) ? Now, go in Files -\u003e Preferences -\u003e Settings, search for and activate the Always Sign Off setting.\nFinally, when you’ll commit your changes via the VS Code interface, your commits will automaticaly be signed-off.\nContinue towards sharing your changes ‣\n","categories":"","description":"A few advises and rules about commit messages","excerpt":"A few advises and rules about commit messages","ref":"/en/docs/guides/contribute/contribute-code/commit-conventions/","tags":"","title":"Commit conventions"},{"body":"Style de commits Le format général des commits est le suivant :\ncomposant1, composant2: description du changement à l'impératif Description détaillée ou technique du contenu et de la motivation du changement, si le titre n'est pas complètement évident. le message comme le code doit être en anglais (seulement des caractères ASCII pour le titre) il peut y avoir plusieurs composants, séparés par des : quand il y a une relation hiérarchique, ou des , sinon les composants sont en minuscule, avec éventuellement -, _ ou . la description du changement à l’impératif commence par un verbe en minuscule le titre ne doit pas comporter de lien (# est interdit) Idéalement :\nle titre doit être autonome : pas besoin de lire autre chose pour le comprendre le titre du commit est entièrement en minuscule le titre est clair pour une personne étrangère au code le corps du commit contient une description du changement Une vérification automatique est effectuée pour vérifier autant que possible ce formatage. Contre-exemples de titres de commit A éviter absolument:\ncomponent: update ./some/file.ext : préciser la mise à jour en question plutôt que le fichier, les fichiers sont des éléments techniques bienvenus dans le corps du commit component: fix #42 : préciser le problème corrigé, les liens (vers l’issue, etc.) sont encouragés dans le corps du commit wip : décrire le travail (et le finir) Bienvenus pour faciliter la relecture, mais ne pas merger:\nfixup! previous commit : un autosquash devra être lancé avant le merge Revert \"previous commit of the same PR\" : les deux commits devront être retirés avant merge Le Developer Certificate of Origin (DCO) Tous les projets d’OSRD utilisent le DCO (certificat du développeur d’orgine) pour des raisons légales. Le DCO permet de confirmer que vous avez les droits sur le code que vous contribuez. Pour en savoir plus sur l’histoire et l’objectif du DCO, vous pouvez lire The Developer Certificate of Origin de Roscoe A. Bartlett.\nPour se conformer au DCO, tous les commits doivent inclure une ligne Signed-off-by.\nComment signer un commit avec Git dans un terminal ? Pour signer un commit, il suffit d’ajouter l’option -s à votre commande git commit, comme ceci :\ngit commit -s -m \"Your commit message\" Cela s’applique également lors de l’utilisation de la commande git revert.\nComment signer un commit avec Git dans Visual Studio Code (VS Code) ? Allez dans Fichiers -\u003e Préférences -\u003e Paramètres, puis recherchez et activez le paramètre Always Sign Off.\nEnsuite, lorsque vous ferez un commit via l’interface de VS Code, ils seront automatiquement signés.\nContinuer vers le partage des changements ‣\n","categories":"","description":"Quelques bonnes pratiques et règles pour les messages de commits","excerpt":"Quelques bonnes pratiques et règles pour les messages de commits","ref":"/fr/docs/guides/contribute/contribute-code/commit-conventions/","tags":"","title":"Conventions de commits"},{"body":"The reviewer/maintainer undertakes to carry out the review quickly, and is also responsible for closing request changes, check commit history and quickly merge the pull request if allowed.\nWe propose you a few tips and recommendations that we think are relevant to a human, relevant and rewarding code review for all contributors:\nHow to Make Your Code Reviewer Fall in Love with You? by Michael Lynch. How to Do Code Reviews Like a Human? by Michael Lynch. Review cycle A code review is an iterative process. For a smooth review, it is imperative to correctly configure your github notifications.\nIt is advisable to configure OSRD repositories as “Participating and @mentions”. This allows you to be notified of activities only on issues and PRs in which you participate.\nMaintainers are automatically notified by the CODEOWNERS system. The author of a PR is responsible for advancing their PR through the review process and manually requesting maintainer feedback if necessary.\nsequenceDiagram actor A as PR author actor R as Reviewer/Maintainer A-\u003e\u003eR: Asks for a review, notifying some people R-\u003e\u003eA: Answers yes or no loop Loop between author and reviewer R--\u003e\u003eA: Comments, asks for changes A--\u003e\u003eR: Answers to comments or requested changes A--\u003e\u003eR: Makes necessary changes in dedicated \"fixups\" R--\u003e\u003eA: Reviews, tests changes, and comments again R--\u003e\u003eA: Resolves requested changes/conversations if ok end A-\u003e\u003eR: Rebase and apply fixups R-\u003e\u003eA: Checks commits history R-\u003e\u003eA: Approves or closes the PR Note left of R: \u0026 Merges if maintainer The code review pyramid Script for testing a PR When reviewing a PR, it is useful to test the changes by starting an instance of the OSRD app based on the PR branch.\nA script is available to spin up a separate and dedicated app instance using the PR number. The script uses the Docker images already built by the CI and launches the app, running in isolation. This allows you to run both instances simultaneously without conflicts (ideal for comparing changes, for example).\nAdditionally, you can specify a database backup, which the script will load directly into the app.\nThe app will be launched on the 4001 port. You can access it at: http://localhost:4001/\nAvailable Commands: ./scripts/pr-tests-compose.sh 8914 up: Downloads the CI-generated images for PR #8914 and launches the application. ./scripts/pr-tests-compose.sh 8914 up-and-load-backup ./path_to_backup: Downloads the images for PR #8914, restores data from the provided backup, and starts the application. ./scripts/pr-tests-compose.sh down: Shuts down the test application instance for PR #8914. ./scripts/pr-tests-compose.sh down-and-clean: Shuts down the test instance and cleans all the instance’s docker volumes (PG data, Valkey cache, RabbitMQ) to prevent any side-effects. Accessing Services: Apart from the frontend server, all localhost services are available on localhost, with a minor port adjustment (to avoid conflicts with the dev environment): for a list of common ports, have a look at the dedicated docker-compose file.\n","categories":"","description":"How to give useful feedback","excerpt":"How to give useful feedback","ref":"/en/docs/guides/contribute/code-review/","tags":"","title":"Review process"},{"body":"Le reviewer/mainteneur s’engage à effectuer la revue de code rapidement, c’est aussi à lui qu’appartient de fermer les « request changes », de bien vérifier l’historique des commits, et de fusionner la « pull request » s’il en a les droits.\nNous vous soumettons quelques conseils et recommandations qui nous semblent pertinentes pour une revue de code humaine, pertinente et enrichissante pour tous ses contributeurs :\nHow to Make Your Code Reviewer Fall in Love with You? par Michael Lynch. How to Do Code Reviews Like a Human? par Michael Lynch. Cycle de review Une revue de code est un processus itératif. Pour la fluidité d’une review, il est impératif de configurer correctement ses notifications github.\nIl est conseillé de configurer les dépôts OSRD en “Participating and @mentions”. Cela permet d’être notifié d’activités uniquement sur les issues et PR auxquelles vous participez.\nsequenceDiagram actor A as Auteur PR actor R as Reviewer/mainteneur A-\u003e\u003eR: Demande une review en notifiant spéciquement quelques personnes R-\u003e\u003eA: Répond à la demande par oui ou non loop Boucle entre auteur et reviewer R--\u003e\u003eA: Commente, demande des changements A--\u003e\u003eR: Répond à chaque commentaire/demande de changement A--\u003e\u003eR: Corrige le code si nécessaire dans des « fixups » dédiés R--\u003e\u003eA: Vérifie, teste, et commente à nouveau le code R--\u003e\u003eA: Résout les conversations/demandes de changement le cas échéant end A-\u003e\u003eR: Rebase si nécessaire R-\u003e\u003eA: Vérifie l'historique des commits R-\u003e\u003eA: Approuve ou ferme la PR Note left of R: Et fusionne si mainteneur Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).\nLa pyramide de la revue de code Script pour le test d’une PR Lors de la revue d’une PR, il est utile de tester les changements en démarrant une instance de l’application OSRD basée sur la branche de la PR.\nUn script est disponible pour lancer automatiquement une instance séparée et dédiée de l’application en utilisant le numéro de la PR. Le script utilise les images Docker déjà construites par la CI et lance l’application de manière isolée. Cela permet d’exécuter les deux instances en parallèle, sans conflits (idéal pour comparer les modifications, par exemple).\nDe plus, vous pouvez fournir une sauvegarde de la base de données, que le script chargera directement dans l’application.\nL’application sera lancée sur le port 4001. Vous pouvez y accéder en suivant : http://localhost:4001/\nCommandes Disponibles : ./scripts/pr-tests-compose.sh 8914 up : Télécharge les images CI générées pour la PR #8914 et lance l’application. ./scripts/pr-tests-compose.sh 8914 up-and-load-backup ./path_to_backup : Télécharge les images pour la PR #8914, restaure les données à partir de la sauvegarde spécifiée, et démarre l’application. ./scripts/pr-tests-compose.sh down : Arrête l’instance de test de l’application pour la PR #8914. ./scripts/pr-tests-compose.sh down-and-clean : Arrête l’instance de test et nettoie l’ensemble des volumes docker de l’instance (base de donnée PG, cache Valkey, RabbitMQ) pour éviter tout effet de bord. Accès aux Services : À l’exception du serveur frontend, tous les services sont disponibles sur localhost, avec un léger ajustement de port (pour éviter les conflits avec l’environnement de développement) : pour la liste des ports, reportez-vous au fichier docker compose dédié.\n","categories":"","description":"Comment faire des retours constructifs","excerpt":"Comment faire des retours constructifs","ref":"/fr/docs/guides/contribute/code-review/","tags":"","title":"Revue de code"},{"body":"L’auteur d’une pull request (PR) est responsable de son « cycle de vie ». Il se charge de contacter les différents acteurs, de suivre la revue de code, répondre aux commentaires et corriger le code suite à la revue de code (vous pouvez également consulter la page dédiée à la revue de code).\nEn cas de PR conséquente, ne pas hésiter à solliciter plusieurs reviewers qui pourront s’organiser, voire de faire la review ensemble, reviewers et auteur.\nOuvrez une pull request Une fois que vos changements sont prêts, il est temps de proposer de les intégrer à la branche dev. Cela se fait dans l’interface web de Github.\nSi possible :\nFaites des PRs d’unités logiques et atomiques également (évitez de mélanger le refactoring, les nouvelles fonctionnalités et la correction de bugs en même temps). Ajoutez une description aux PR pour expliquer ce qu’elles font et pourquoi. Aidez le relecteur en suivant les conseils donnés dans l’article de mtlynch. Ajoutez les balises area:\u003caffected_area\u003e pour montrer quelle partie de l’application a été impactée. Cela peut être fait via l’interface web. Prenez en compte les retours Une fois que votre PR est ouverte, d’autres contributeurs doivent donner leur avis sur votre proposition :\nN’importe qui peut donner son avis. Il est nécessaire d’obtenir l’approbation d’un contributeur familier avec le code. Il est d’usage de prendre en compte tous les commentaires critiques. Les commentaires sont souvent écrits dans un style plutôt direct, dans le souci de collaborer efficacement vers une solution acceptable par tous. Une fois que tous les commentaires ont été pris en compte, un mainteneur intègre le changement. Sur les PR conséquentes et vouées à évoluer dans le temps, conserver les corrections suite à la relecture dans des commits séparés facilite le travail de relecture. En cas de rebase et de relectures multiples par la même personne ils sont le moyen d’économiser une nouvelle relecture complète (demandez de l’aide au besoin) :\nAjoutez des commits de fixup, amend, squash ou reword à l’aide de la documentation dédiée à git commit. Fusionnez automatiquement les corrections dans les commits originaux de votre PR et vérifier le résultat , à l’aide de git rebase -i --autosquash origin/dev (juste avant le merge et une fois les relectures terminées). Poussez vos changements avec git push --force-with-lease car vous ne poussez pas seulement de nouveaux commits, mais bien un changement des commits existants. N’hésitez pas à relancer vos interlocuteurs, plusieurs fois si besoin est : vous êtes responsable de la vie de votre pull request. Cycle de review Une revue de code est un processus itératif. Pour la fluidité d’une review, il est impératif de configurer correctement ses notifications github.\nIl est conseillé de configurer les dépôts OSRD en “Participating and @mentions”. Cela permet d’être notifié d’activités uniquement sur les issues et PR auxquelles vous participez.\nsequenceDiagram actor A as Auteur PR actor R as Reviewer/mainteneur A-\u003e\u003eR: Demande une review en notifiant spéciquement quelques personnes R-\u003e\u003eA: Répond à la demande par oui ou non loop Boucle entre auteur et reviewer R--\u003e\u003eA: Commente, demande des changements A--\u003e\u003eR: Répond à chaque commentaire/demande de changement A--\u003e\u003eR: Corrige le code si nécessaire dans des « fixups » dédiés R--\u003e\u003eA: Vérifie, teste, et commente à nouveau le code R--\u003e\u003eA: Résout les conversations/demandes de changement le cas échéant end A-\u003e\u003eR: Rebase si nécessaire R-\u003e\u003eA: Vérifie l'historique des commits R-\u003e\u003eA: Approuve ou ferme la PR Note left of R: Et fusionne si mainteneur Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).\nContinuer enfin vers les tests ‣\n","categories":"","description":"Comment soumettre votre code pour qu'il soit vérifié ?","excerpt":"Comment soumettre votre code pour qu'il soit vérifié ?","ref":"/fr/docs/guides/contribute/contribute-code/share-changes/","tags":"","title":"Partagez vos changements"},{"body":"Please report anything you deem significant!\nOur bug tracking platform is github, so you have to register to report bugs.\nFollow this link and pick whatever template fits the best.\nBugs Bug must have a correct description and the bug’s issue template must be filled carefully. Bug must be tagged with (for team members): kind:bug one or several area:\u003caffected_area\u003e if possible, if the affected area is not known leave it blank it will be added later by another team member. one severity:\u003cbug_severity\u003e if possible, if severity is not known leave it blank it will be added later by another team member. severity:minor: User can still use the feature. severity:major: User sometimes can’t use the feature. severity:critical: User can’t use the feature. OSRD team members can change issues’ tags (severity, area, kind, …). You may leave a comment to explain changes. If you are working on a bug or plan to work on a bug, assign yourself to the bug. PRs solving bugs should add a regression tests to ensure that bug will not be back in the future. ","categories":"","description":"Report a bug or suggest an enhancement","excerpt":"Report a bug or suggest an enhancement","ref":"/en/docs/guides/contribute/bug-reports/","tags":"","title":"Report issues"},{"body":"The author of a pull request (PR) is responsible for its “life cycle”. He is responsible for contacting the various parties involved, following the review, responding to comments and correcting the code following review (you could also check dedicated page about code review).\nIn the case of a large PR, don’t hesitate to ask several reviewers to organize themselves, or even to carry out the review together, reviewers and author.\nOpen a pull request Once your changes are ready, you have to request integration with the dev branch.\nIf possible:\nMake PR of logical and atomic units too (avoid mixing refactoring, new features and bug fix at the same time). Add a description to PRs to explain what they do and why. Help the reviewer by following advice given in mtlynch article. Add tags area:\u003caffected_area\u003e to show which part of the application have been impacted. It can be done through the web interface. Take feedback into account Once your PR is open, other contributors can review your changes:\nAny user can review your changes. Your code has to be approved by a contributor familiar with the code. All users are expected to take comments into account. Comments tend to be written in an open and direct manner. The intent is to efficiently collaborate towards a solution we all agree on. Once all discussions are resolved, a maintainer integrates the change. For large PRs that are bound to evolve over time, keeping corrections during review in separate commits helps reviewers. In the case of multiple reviews by the same person, this can save full re-review (ask for help if necessary):\nAdd fixup, amend, squash or reword commits using the git commit documentation. Automatically merge corrections into the original commits of your PR and check the result, using git rebase -i --autosquash origin/dev (just before the merge and once review process is complete). Push your changes with git push --force-with-lease because you are not just pushing new commits, you are pushing changes to existing commits. If you believe somebody forgot to review / merge your change, please speak out, multiple times if needs be. Review cycle A code review is an iterative process. For a smooth review, it is imperative to correctly configure your github notifications.\nIt is advisable to configure OSRD repositories as “Participating and @mentions”. This allows you to be notified of activities only on issues and PRs in which you participate.\nMaintainers are automatically notified by the CODEOWNERS system. The author of a PR is responsible for advancing their PR through the review process and manually requesting maintainer feedback if necessary.\nsequenceDiagram actor A as PR author actor R as Reviewer/Maintainer A-\u003e\u003eR: Asks for a review, notifying some people R-\u003e\u003eA: Answers yes or no loop Loop between author and reviewer R--\u003e\u003eA: Comments, asks for changes A--\u003e\u003eR: Answers to comments or requested changes A--\u003e\u003eR: Makes necessary changes in dedicated \"fixups\" R--\u003e\u003eA: Reviews, tests changes, and comments again R--\u003e\u003eA: Resolves requested changes/conversations if ok end A-\u003e\u003eR: Rebase and apply fixups R-\u003e\u003eA: Checks commits history R-\u003e\u003eA: Approves or closes the PR Note left of R: \u0026 Merges if maintainer Finally continue towards tests ‣\n","categories":"","description":"How to submit your code modifications for review?","excerpt":"How to submit your code modifications for review?","ref":"/en/docs/guides/contribute/contribute-code/share-changes/","tags":"","title":"Share your changes"},{"body":"N’hésitez pas à signaler tout ce qui vous semble important !\nNotre outil de suivi des bugs est github. Il est nécessaire de s’inscrire pour signaler un bug.\nSuivez ce lien et choisissez le modèle qui correspond à votre cas de figure.\nBugs Le bug doit avoir une description correcte et le modèle du bug doit être rempli avec soin. Le bug doit être étiqueté avec (pour les membres de l’équipe) : kind:bug une ou plusieurs area:\u003caffected_area\u003e si possible (si la zone affectée n’est pas connue, laissez-la vide et elle sera ajoutée plus tard par un autre membre de l’équipe). un severity:\u003cbug_severity\u003e si possible (si la sévérité n’est pas connue, laissez-la vide et elle sera ajoutée plus tard par un autre membre de l’équipe). severity:minor : L’utilisateur peut encore utiliser la fonctionnalité. severity:major : L’utilisateur ne peut parfois pas utiliser la fonctionnalité. severity:critical : L’utilisateur ne peut pas utiliser la fonctionnalité. Les membres de l’équipe OSRD peuvent modifier les étiquettes des problèmes (gravité, domaine, type, …). Vous pouvez laisser un commentaire pour expliquer les changements. Si vous travaillez sur un bug ou planifiez de travailler sur un bug, assignez vous au bug. Les PRs qui résolvent des bugs doivent ajouter des tests de régression pour s’assurer que le bug ne reviendra pas dans le futur. ","categories":"","description":"Comment signaler un bug ou suggérer une amélioration","excerpt":"Comment signaler un bug ou suggérer une amélioration","ref":"/fr/docs/guides/contribute/bug-reports/","tags":"","title":"Signaler des problèmes"},{"body":"Back-end Integration tests are written with pytest in the /tests folder. Each route described in the openapi.yaml files must have an integration test. The test must check both the format and content of valid and invalid responses. Front-end The functional writing of the tests is carried out with the Product Owners, and the developers choose a technical implementation that precisely meets the needs expressed and fits in with the recommendations presented here.\nWe use Playwright to write end-to-end tests, and vitest to write unit tests.\nThe browsers tested are currently Firefox and Chromium.\nBasic principles Tests must be short (1min max) and go straight to the point. Arbitrary timeouts are outlawed; a test must systematically wait for a specific event. It is possible to use polling (retry an action - a click for example - after a certain time) proposed in the Playwright’s API. All tests must be parallelizable. Tests must not point to or wait for text elements from the translation, prefer the DOM tree structure or place specific id. We’re not testing the data, but the application and its functionality. Data-specific tests should be developed in parallel. Data The data tested must be public data. The data required (infrastructure and rolling stock) for the tests are offered in the application’s json files, injected at the start of each test and deleted at the end, regardless of its result or how it is stopped, including with CTRL+C.\nThis is done by API calls in typescript before launching the actual test.\nThe data tested is the same, both locally and via continuous integration.\nAtomicity of a test Each test must be atomic: it is self-sufficient and cannot be divided.\nA test will target a single feature or component, provided it is not too large. A test will not test an entire module or application; it will necessarily be a set of tests, in order to preserve test atomicity.\nIf a test needs elements to be created or added, these operations must be carried out by API calls in typescript upstream of the test, as is done for adding data. These elements must be deleted at the end of the test, regardless of the result or how it is stopped, including by CTRL+C.\nThis allows tests to be parallelized.\nHowever, in certain cases where it is relevant, a test may contain several clearly explained and justified test subdivisions (several test() in a single describe()).\nExample of a test The requirement: “We want to test the addition of a train to a timetable”.\nadd the test infrastructure and rolling stock to the database by API calls. create project, study and scenario with choice of test infrastructure by API calls. start the test, clicking on “add one or more trains” until the presence of the trains in the timetable is verified the test passes, fails or is stopped, the project, study and scenario are deleted, along with the test rolling stock and infrastructure by API calls. NB: the test will not test all the possibilities offered by the addition of trains; this should be a specific test which would test the response of the interface for all scenarios without adding trains.\nContinue towards write code ‣\n","categories":"","description":"Recommandations for testing purpose","excerpt":"Recommandations for testing purpose","ref":"/en/docs/guides/contribute/contribute-code/tests/","tags":"","title":"Tests"},{"body":"Back-end Les tests d’intégration sont écrits avec pytest dans le dossier /tests. Chaque route décrite dans les fichiers openapi.yaml doit avoir un test d’intégration. Le test doit vérifier à la fois le format et le contenu des réponses valides et invalides. Front-end L’écriture fonctionnelle des tests est réalisée avec les Product Owners, et les développeurs choisissent une implémentation technique qui répond précisément aux besoins exprimés et qui s’intègre dans les recommandations présentes ici.\nNous utilisons Playwright pour écrire les tests bout en bout, et vitest pour écrire les tests unitaires.\nLes navigateurs testés sont pour l’instant Firefox et Chromium.\nPrincipes de base Les tests doivent être courts (1min max) et aller droit au but. Les timeout arbitraires sont proscrits, un test doit systématiquement attendre un évènement spécifique. Il est possible d’utiliser le polling (retenter une action — un clic par exemple — au bout d’un certain temps) proposé dans l’API de Playwright. Les tests doivent tous pouvoir être parallélisables. Les tests ne doivent pas pointer/attendre des éléments de texte issus de la traduction, préférer l’arborescence du DOM ou encore placer des id spécifiques. On ne teste pas les données mais l’application et ses fonctionnalités. Des tests spécifiques aux données sont à élaborer par ailleurs. Données Les données testées doivent impérativement être des données publiques. Les données nécessaires (infrastructure et matériel) aux tests sont proposées dans des fichiers json de l’application, injectées au début de chaque test et effacées à la fin peu importe son résultat ou la manière d’être stoppé, y compris par CTRL+C.\nCela se fait par des appels API en typescript avant de lancer le test à proprement parler.\nLes données testées sont les mêmes en local ou via l’intégration continue.\nAtomicité d’un test Chaque test doit être atomique : il se suffit à lui même et ne peut pas être divisé.\nUn test va cibler une fonctionnalité ou un composant, si ce dernier n’est pas trop gros. Un test ne testera pas tout un module ou tout une application, ce sera forcément un ensemble de tests afin de préserver l’atomicité des tests.\nSi un test a besoin que des éléments soient créés ou ajoutés, ces opérations doivent être opérées par des appels API en typescript en amont du test, à l’instar de ce qui est fait pour l’ajout de données. Ces éléments doivent être supprimés à l’issue du test, peu importe son résultat ou la manière d’être stoppé, y compris par CTRL+C.\nCela permettra notamment la parallélisation des tests.\nUn test peut cependant, dans certains cas de figure où cela est pertinent, contenir plusieurs sous-divisions de test, clairement explicitées, et justifiées (plusieurs test() dans un seul describe()).\nExemple de test Le besoin : « nous voulons tester l’ajout d’un train dans une grille horaire ».\najouter l’infrastructure et le matériel roulant de test dans la base de données par appels API créer projet, étude et scénario avec choix de l’infra de test par appels API début du test qui clique sur « ajouter un ou plusieurs trains » jusqu’à la vérification de la présence des trains dans la grille horaire le test a réussi, a échoué, ou est stoppé, le projet, l’étude et le scénario sont effacés, ainsi que le matériel roulant et et l’infrastructure de test par appels API NB : le test ne va pas tester toutes les possibilités offertes par l’ajout de trains, cela relève d’un test spécifique qui testerait la réponse de l’interface pour tous les cas de figure sans ajouter de trains.\nContinuer vers l’écriture de code ‣\n","categories":"","description":"Recommandations pour les tests","excerpt":"Recommandations pour les tests","ref":"/fr/docs/guides/contribute/contribute-code/tests/","tags":"","title":"Tests"},{"body":"Some definitions:\nCapacity Capacity, in this context, is the ability to reserve infrastructure elements to allow the passage of a train.\nCapacity is expressed in both space and time: the reservation of an element can block a specific zone that becomes inaccessible to other trains, and this reservation lasts for a given time interval.\nIt can be displayed on a chart, with the time on the horizontal axis and the distance traveled on the vertical axis.\nExample of a space-time chart displaying the passage of a train.\nThe colors here represent aspects of the signals, but display a consumption of the capacity as well: when these blocks overlap for two trains, they conflict.\nThere is a conflict between two trains when they reserve the same object at the same time, in incompatible configurations.\nExample of a space-time graph with a conflict: the second train is faster than the first one, they are in conflict at the end of the path, when the rectangles overlap.\nWhen simulating this timetable, the second train would be slowed down by the yellow signals, caused by the presence of the first train.\nTrain slots A train slot corresponds to a capacity reservation for the passage of a train. It is fixed in space and time: the departure time and the path taken are known. On the space-time charts in this page, a train slot corresponds to the set of blocks displayed for a train.\nNote: in English-speaking countries, these are often simply called “train paths”. But in this context, this name would be ambiguous with the physical path taken by the train.\nThe usual procedure is for the infrastructure manager (e.g. SNCF Réseau) to offers train slots for sale to railway companies (e.g. SNCF Voyageurs).\nAt a given date before the scheduled day of operation, all the train paths are allocated. But there may be enough capacity to fit more trains. Trains can fit between scheduled slots, when they are sufficiently far apart or have not found a buyer.\nThe remaining capacity after the allocation of train paths is called residual capacity. This section explains how OSRD looks for train slots in this residual capacity.\n","categories":"","description":"","excerpt":"Some definitions:\nCapacity Capacity, in this context, is the ability …","ref":"/en/docs/reference/design-docs/stdcm/domain_context/","tags":"","title":"Business context"},{"body":"Quelques définitions :\nLa capacité La capacité, dans ce contexte, correspond à la possibilité de réserver des éléments d’infrastructure pour permettre le passage d’un train.\nLa capacité s’exprime en fonction de l’espace et du temps : la réservation d’un élément peut bloquer une zone précise qui devient inaccessible aux autres trains, et cette réservation se fait sur un intervalle de temps.\nOn peut la représenter sur un graphique, avec le temps en abscisse et la distance parcourue sur un chemin en ordonnée.\nExemple d’un graphique espace-temps montrant le passage d’un train.\nLes couleurs représentent ici les aspects des signaux, mais montrent également une consommation de la capacité : quand ces blocs se superposent pour deux trains, ils sont en conflit.\nDeux trains d’une grille horaire sont en conflit quand ils réservent en même temps un même objet, dans des configurations incompatibles.\nExemple d’un graphique espace-temps avec conflit : le second train est plus rapide que le premier, ils sont en conflit sur la fin du trajet, quand les rectangles se superposent.\nEn essayant de simuler cette grille horaire, le second train serait ralentis par des signaux indiquant de ralentir, provoqués par la présence du premier train.\nLa consommation de capacité est souvent représentée sous la forme de rectangles car, dans les systèmes de signalisation les plus simples, il s’agit de réservations d’une zone fixe dans l’espace pendant un intervalle de temps donné.\nLes sillons horaires Un sillon correspond à une réservation de capacité pour le passage d’un train. Il est fixé dans l’espace et dans le temps : le temps de départ et le chemin emprunté sont connus. Sur les graphiques espace-temps de cette page, un sillon correspond à l’ensemble des blocs pour un train.\nDans un fonctionnement habituel, le gestionnaire d’infrastructure (ex : SNCF Réseau) propose des sillons à la vente pour les entreprises ferroviaires (ex : SNCF Voyageurs).\nÀ une date donnée avant le jour de circulation prévu, tous les sillons sont attribués. Mais il peut rester assez de capacité pour faire rouler plus de trains. Il est possible de placer des trains entre les sillons déjà établis, quand ces derniers sont suffisamment espacés ou n’ont pas trouvé d’acheteurs.\nLa capacité restante après l’attribution des sillons est appelée la capacité résiduelle. Le problème traité ici est la recherche de sillons dans celle-ci.\n","categories":"","description":"","excerpt":"Quelques définitions :\nLa capacité La capacité, dans ce contexte, …","ref":"/fr/docs/reference/design-docs/stdcm/domain_context/","tags":"","title":"Contexte métier"},{"body":"The first thing we need to define is how we move through the infrastructure, without dealing with conflicts yet.\nWe need a way to define and enumerate the different possible paths and explore the infrastructure graph, with several constraints:\nThe path must be compatible with the given rolling stock (loading gauge / electrification / signaling system) At any point, we need to access path properties from its start up to the considered point. This includes block and route lists. We sometimes need to know where the train will go after the point currently being evaluated, for proper conflict detection To do this, we have defined the class InfraExplorer. It uses blocks (sections from signal to signal) as a main subdivision. It has 3 sections: the current block, predecessors, and a “lookahead”.\nIn this example, the green arrows are the predecessor blocks. What happens there is considered to be immutable.\nThe red arrow is the current block. This is where we run train and signaling simulations, and where we deal with conflicts.\nThe blue arrows are part of the lookahead. This section hasn’t been simulated yet, its only purpose is to know in advance where the train will go next. In this example, it would tell us that the bottom right signal can be ignored entirely. The top path is the path being currently evaluated. The bottom section of the path will be evaluated in a different and already instanciated InfraExplorer\nThe InfraExplorer is manipulated with two main functions (the accessors have been removed here for clarity):\ninterface InfraExplorer { /** * Clone the current object and extend the lookahead by one route, for each route starting at * the current end of the lookahead section. The current instance is not modified. */ fun cloneAndExtendLookahead(): Collection\u003cInfraExplorer\u003e /** * Move the current block by one, following the lookahead section. Can only be called when the * lookahead isn't empty. */ fun moveForward(): InfraExplorer } cloneAndExtendLookahead() is the method that actually enumerates the different paths, returning clones for each possibility. It’s called when we need a more precise lookahead to properly identify conflicts, or when it’s empty and we need to move forward.\nA variation of this class can also keep track of the train simulation and time information (called InfraExplorerWithEnvelope). This is the version that is actually used to explore the infrastructure.\n","categories":"","description":"","excerpt":"The first thing we need to define is how we move through the …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/","tags":"","title":"Infrastructure exploration"},{"body":" La modélisation physique joue un rôle important dans le cœur de calcul d’OSRD. C’est elle qui nous permet de simuler la circulation des trains, et elle doit être aussi réaliste que possible.\nBilan des forces Pour calculer le déplacement du train au cours du temps, il faut d’abord calculer sa vitesse à chaque instant. Une manière simple d’obtenir cette vitesse est de passer par le calcul de l’accélération. Grâce au principe fondamental de la dynamique, l’accélération du train à chaque instant est directement dépendant des différentes forces qui lui sont appliquées : $$ \\sum \\vec{F}=m\\vec{a} $$\nTraction : La valeur de la force de traction \\(F_{mot}\\) dépend de plusieurs facteurs :\ndu matériel roulant de la vitesse du train \\(v^{\\prime}x\\), selon la courbe effort-vitesse ci-dessous : $$ {\\vec{F_{mot}}(v_{x^{\\prime}}, x^{\\prime})=F_{mot}(v_{x^{\\prime}}, x^{\\prime})\\vec{e_x^{\\prime}}} $$\nL’axe x représente la vitesse du train en [km/h], l’axe y, la valeur de la force de traction en [kN].\nde l’action du conducteur, qui accélère plus ou moins fort en fonction de l’endroit où il se trouve sur son trajet Freinage : La valeur de la force de freinage \\(F_{brk}\\) dépend elle aussi du matériel roulant et de l’action du conducteur mais possède une valeur constante pour un matériel donné. Dans l’état actuel de la modélisation, le freinage est soit nul, soit à sa valeur maximale. $$ \\vec{F_{brk}}(x^{\\prime})=-F_{brk}(x^{\\prime}){\\vec{e_{x^{\\prime}}}} $$\nUne seconde approche de la modélisation du freinage est l’approche dite horaire, car utilisée pour la production horaire à la SNCF. Dans ce cas, la décélération est fixe et le freinage ne dépend plus des différentes forces appliquées au train. Les valeurs de décélération typiques vont de 0.4 à 0.7m/s².\nRésistance à l’avancement : Pour modéliser la résistance à l’avancement du train on utilise la formule de Davis qui prend en compte tous les frottements et la résistance aérodynamique de l’air. La valeur de la résistance à l’avancement dépend de la vitesse \\(v^{\\prime}_x\\). Les coefficients \\(A\\), \\(B\\), et \\(C\\) dépendent du matériel roulant. $$ {\\vec{R}(v_{x^{\\prime}})}=-(A+Bv_{x^{\\prime}}+{Cv_{x^{\\prime}}}^2){\\vec{e_{x^{\\prime}}}} $$\nPoids (pentes + virages) : La force du poids donnée par le produit entre la masse \\(m\\) du train et la constante gravitationnelle \\(g\\) est projetée sur les axes \\(\\vec{e_x}^{\\prime}\\) et \\(\\vec{e_y}^{\\prime}\\).Pour la projection, on utilise l’angle \\(i(x^{\\prime})\\), qui est calculé à partir de l’angle de déclivité \\(s(x^{\\prime})\\) corrigé par un facteur qui prend en compte l’effet du rayon de virage \\(r(x^{\\prime})\\). $$ \\vec{P(x^{\\prime})}=-mg\\vec{e_y}(x^{\\prime})= -mg\\Big[sin\\big(i(x^{\\prime})\\big){\\vec{e_{x^{\\prime}}}(x^{\\prime})}+cos\\big(i(x^{\\prime})\\big){\\vec{e_{{\\prime}}}(x^{\\prime})}\\Big] $$\n$$ i(x^{\\prime})= s(x^{\\prime})+\\frac{800m}{r(x^{\\prime})} $$\nRéaction du sol : La force de réaction du sol compense simplement la composante verticale du poids, mais n’a pas d’impact sur la dynamique du train car elle n’a aucune composante selon l’axe \\({\\vec{e_x}^{\\prime}}\\). $$ \\vec{R_{gnd}}=R_{gnd}{\\vec{e_{y^{\\prime}}}} $$\nEquilibre des forces L’équation du principe fondamental de la dynamique projetée sur l’axe \\({\\vec{e_x}^{\\prime}}\\) (dans le référentiel du train) donne l’équation scalaire suivante :\n$$ a_{x^{\\prime}}(t) = \\frac{1}{m}\\Big [F_{mot}(v_{x^{\\prime}}, x^{\\prime})-F_{brk}(x^{\\prime})-(A+Bv_{x^{\\prime}}+{Cv_{x^{\\prime}}}^2)-mgsin(i(x^{\\prime}))\\Big] $$\nCelle-ci est ensuite simplifiée en considérant que malgré la pente le train se déplace sur un plan et en amalgamant \\(\\vec{e_x}\\) et \\(\\vec{e_x}^{\\prime}\\). La pente a toujours un impact sur le bilan des forces mais on considère que le train ne se déplace qu’horizontalement, ce qui donne l’équation simplifiée suivante :\n$$ a_{x}(t) = \\frac{1}{m}\\Big[F_{mot}(v_{x}, x)-F_{brk}(x)-(A+Bv_{x}+{Cv_{x}}^2)-mgsin(i(x))\\Big] $$\nRésolution La force motrice et la force de freinage dépendent de l’action du conducteur (il décide d’accélérer ou de freiner plus ou moins fort en fonction de la situation). Cette dépendance se traduit donc par une dépendance de ces deux forces à la position du train. La composante du poids dépend elle aussi de la position du train, car provenant directement des pentes et des virages situées sous ce dernier.\nDe plus, la force motrice dépend de la vitesse du train (selon la courbe effort vitesse) tout comme la résistance à l’avancement.\nCes différentes dépendances rendent impossible la résolution analytique de cette équation, et l’accélération du train à chaque instant doit être calculée par intégration numérique.\n","categories":"","description":"","excerpt":" La modélisation physique joue un rôle important dans le cœur de …","ref":"/fr/docs/explanation/running_time_calculation/physical_modeling/","tags":"","title":"Modélisation physique"},{"body":"La première chose à définir est comment un train se déplace sur l’infrastructure, sans prendre en compte les conflits pour l’instant.\nOn a besoin d’une manière de définir et d’énumérer les différents chemins possibles et de parcourir l’infrastructure, avec plusieurs contraintes :\nLe chemin doit être compatible avec le matériel roulant donné (électrification, gabarit, systèmes de signalisation) À n’importe quel point, on doit être en mesure d’accéder aux propriétés du chemin depuis le point de départ jusqu’au point considéré. Cela inclus les routes et les cantons. Dans certains cas, on doit savoir où le train ira après le point actuellement évalué (pour une détection de conflits correcte). Pour répondre à ce besoin, une classe InfraExplorer a été implémentée. Elle utilise les cantons (section de signal en signal) comme subdivision principale. Elle est composée de 3 sections : le canton courant, les prédécesseurs, et les cantons suivants.\nDans cet exemple, les flèches vertes sont les cantons précédents. Ce qui se produit dessus est considéré comme immuable.\nLa flèche rouge est le canton actuellement exploré. C’est à cet endroit que les simulations du train et de la signalisation sont effectuées, et que les conflits sont évités.\nLes flèches bleues sont les cantons suivants. Cette section n’est pas encore simulée, elle existe seulement pour savoir où le train ira ensuite. Dans cet exemple, elle indique que le signal en bas à droite peut être ignoré, seul le chemin du haut sera utilisé. Le chemin du bas sera évalué dans une autre instance de InfraExplorer.\nPlus de détails sur la classe et son interface sont présents sur la version anglaise de la page.\n","categories":"","description":"","excerpt":"La première chose à définir est comment un train se déplace sur …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/infrastructure_exploration/","tags":"","title":"Parcours de l'infrastructure"},{"body":" Physical modelling plays an important role in the OSRD core calculation. It allows us to simulate train traffic, and it must be as realistic as possible train traffic, and it must be as realistic as possible.\nForce review To calculate the displacement of the train over time, we must first calculate its speed at each instant. A simple way to obtain this speed is to calculate the acceleration. Thanks to the fundamental principle of dynamics, the acceleration of the train at each instant is directly dependent on the different forces applied to it: $$ \\sum \\vec{F}=m\\vec{a} $$\nTraction: The value of the traction force \\(F_{mot}\\) depends on several factors:\nthe rolling stock the speed of the train, \\(v^{\\prime}x\\) according to the effort-speed curve below: $$ {\\vec{F_{mot}}(v_{x^{\\prime}}, x^{\\prime})=F_{mot}(v_{x^{\\prime}}, x^{\\prime})\\vec{e_x^{\\prime}}} $$\nThe x axis represents the speed of the train in [km/h], the y axis the value of the traction force in [kN].\nthe action of the driver, who accelerates more or less strongly depending on where he is on his journey Braking : The value of the braking force \\(F_{brk}\\) also depends on the rolling stock and the driver’s action but has a constant value for a given rolling stock. In the current state of modelling, braking is either zero or at its maximum value. $$ \\vec{F_{brk}}(x^{\\prime})=-F_{brk}(x^{\\prime}){\\vec{e_{x^{\\prime}}}} $$\nA second approach to modelling braking is the so-called hourly approach, as it is used for hourly production at SNCF. In this case, the deceleration is fixed and the braking no longer depends on the different forces applied to the train. Typical deceleration values range from 0.4 to 0.7m/s².\nForward resistance: To model the forward resistance of the train, the Davis formula is used, which takes into account all the friction and aerodynamic resistance of the air. The value of the drag depends on the speed \\(v^{\\prime}_x\\). The coefficients \\(A\\), \\(B\\), et \\(C\\) depend on the rolling stock. $$ {\\vec{R}(v_{x^{\\prime}})}=-(A+Bv_{x^{\\prime}}+{Cv_{x^{\\prime}}}^2){\\vec{e_{x^{\\prime}}}} $$\nWeight (slopes + turns) : The weight force given by the product between the mass \\(m\\) of the train and the gravitational constant \\(g\\) is projected on the axes \\(\\vec{e_x}^{\\prime}\\) and \\(\\vec{e_y}^{\\prime}\\).For projection, we use the angle \\(i(x^{\\prime})\\), which is calculated from the slope angle \\(s(x^{\\prime})\\) corrected by a factor that takes into account the effect of the turning radius \\(r(x^{\\prime})\\). $$ \\vec{P(x^{\\prime})}=-mg\\vec{e_y}(x^{\\prime})= -mg\\Big[sin\\big(i(x^{\\prime})\\big){\\vec{e_{x^{\\prime}}}(x^{\\prime})}+cos\\big(i(x^{\\prime})\\big){\\vec{e_{{\\prime}}}(x^{\\prime})}\\Big] $$\n$$ i(x^{\\prime})= s(x^{\\prime})+\\frac{800m}{r(x^{\\prime})} $$\nGround Reaction : The ground reaction force simply compensates for the vertical component of the weight, but has no impact on the dynamics of the train as it has no component along the axis \\({\\vec{e_x}^{\\prime}}\\). $$ \\vec{R_{gnd}}=R_{gnd}{\\vec{e_{y^{\\prime}}}} $$\nForces balance The equation of the fundamental principle of dynamics projected onto the axis \\({\\vec{e_x}^{\\prime}}\\) (in the train frame of reference) gives the following scalar equation:\n$$ a_{x^{\\prime}}(t) = \\frac{1}{m}\\Big [F_{mot}(v_{x^{\\prime}}, x^{\\prime})-F_{brk}(x^{\\prime})-(A+Bv_{x^{\\prime}}+{Cv_{x^{\\prime}}}^2)-mgsin(i(x^{\\prime}))\\Big] $$\nThis is then simplified by considering that despite the gradient the train moves on a plane and by amalgamating \\(\\vec{e_x}\\) and \\(\\vec{e_x}^{\\prime}\\). The gradient still has an impact on the force balance, but it is assumed that the train is only moving horizontally, which gives the following simplified equation:\n$$ a_{x}(t) = \\frac{1}{m}\\Big[F_{mot}(v_{x}, x)-F_{brk}(x)-(A+Bv_{x}+{Cv_{x}}^2)-mgsin(i(x))\\Big] $$\nResolution The driving force and the braking force depend on the driver’s action (he decides to accelerate or brake more or less strongly depending on the situation). This dependence is reflected in the dependence of these two forces on the position of the train. The weight component is also dependent on the position of the train, as it comes directly from the slopes and bends below the train.\nIn addition, the driving force depends on the speed of the train (according to the speed effort curve) as does the resistance to forward motion. resistance.\nThese different dependencies make it impossible to solve this equation analytically, and the acceleration of the train at each moment must be calculated by numerical integration.\n","categories":"","description":"","excerpt":" Physical modelling plays an important role in the OSRD core …","ref":"/en/docs/explanation/running_time_calculation/physical_modeling/","tags":"","title":"Physical modeling"},{"body":"Il y a 3 principaux conteneurs déployés dans une configuration OSRD standard :\nGateway (inclut le frontend) : Sert le front-end, gère l’authentification et proxy les requêtes vers le backend. Editoast : Agit comme le backend qui interagit avec le front-end. Core : Gère les calculs et la logique métier, appelé par Editoast. Déploiement standard Le déploiement standard peut être représenté par le diagramme suivant.\nflowchart TD gw[\"gateway\"] front[\"fichiers statiques front-end\"] gw -- fichier local --\u003e front navigateur --\u003e gw gw -- HTTP --\u003e editoast editoast -- HTTP --\u003e core Les requêtes externes sont reçues par le gateway. Si le chemin demandé commence par /api, il sera transféré en utilisant HTTP vers editoast, sinon il servira un fichier avec le chemin demandé. Editoast atteint le core en utilisant HTTP si nécessaire.\nLe gateway n’est pas seulement un proxy inverse avec le bundle front-end inclus, il fournit également tous les mécanismes d’authentification : utilisant OIDC ou des tokens.\n","categories":"","description":"Comment les conteneurs fonctionnent ensemble et comment ils sont construits","excerpt":"Comment les conteneurs fonctionnent ensemble et comment ils sont …","ref":"/fr/docs/explanation/containers-architecture/","tags":"","title":"Architecture des conteneurs"},{"body":"Pour que l’outil STDCM fonctionne, il faut configurer l’environnement de recherche STDCM, une configuration stockée en base de données.\nLes champs configurables sont les suivants :\npub struct StdcmSearchEnvironment { pub infra_id: i64, pub electrical_profile_set_id: Option\u003ci64\u003e, pub work_schedule_group_id: Option\u003ci64\u003e, pub timetable_id: i64, pub search_window_begin: NaiveDateTime, pub search_window_end: NaiveDateTime, } Cette configuration est récupérée par le frontend afin que les bons objets et bornes temporelles soient utilisés de manière transparente par l’utilisateur.\nPour configurer cette environnement, vous pouvez soit :\nUtiliser l’API REST prévue à cet effet (voir l’openAPI d’editoast dans la section stdcm_search_environment) Utiliser le CLI editoast (exécutez editoast stdcm-search-env help pour plus d’informations) ","categories":"","description":"Comment configurer l'environnement de recherche STDCM","excerpt":"Comment configurer l'environnement de recherche STDCM","ref":"/fr/docs/guides/deploy/stdcm-search-env/","tags":"","title":"Configuration de l'environnement de recherche STDCM"},{"body":"There are 3 main containers deployed in a standard OSRD setup:\nGateway (includes the frontend): Serves the front end, handles authentication and proxies requests to the backend. Editoast: Acts as the backend that interacts with the front end. Core: Handles computation and business logic, called by Editoast. Standard deployment The standard deployment can be represented with the following diagram.\nflowchart TD gw[\"gateway\"] front[\"front-end static files\"] gw -- local file --\u003e front browser --\u003e gw gw -- HTTP --\u003e editoast editoast -- HTTP --\u003e core External requests are received by the gateway. If the path asked starts with /api it will be forwarded using HTTP to editoast, otherwise it will serve a file with the asked path. Editoast reach the core using HTTP if required.\nThe gateway is not only a reverse proxy with the front-end bundle included, it also provides all the authentication mechanisms: using OIDC or tokens.\n","categories":"","description":"How the containers works together and how they are built","excerpt":"How the containers works together and how they are built","ref":"/en/docs/explanation/containers-architecture/","tags":"","title":"Containers architecture"},{"body":"","categories":"","description":"Comment apporter sa pierre à l'édifice","excerpt":"Comment apporter sa pierre à l'édifice","ref":"/fr/docs/guides/contribute/","tags":"","title":"Contribuer à OSRD"},{"body":"","categories":"","description":"Learn about the how we work, and how you can work with us","excerpt":"Learn about the how we work, and how you can work with us","ref":"/en/docs/guides/contribute/","tags":"","title":"Contribute to OSRD"},{"body":"First of all, we recommend learning about the containers architecture of OSRD.\nWe will cover how to deploy OSRD within the following setups:\nUsing docker compose on a single node. Using helm on a kubernetes cluster. It is also possible to deploy each service of OSRD manually on a system, but we will not cover this topic within this guide.\nNB In order for the STDCM tool to function, you’ll need to setup the STDCM Search Environment, a configuration stored in database. See the dedicated page for more information. ","categories":"","description":"Learn how to deploy OSRD in various environments","excerpt":"Learn how to deploy OSRD in various environments","ref":"/en/docs/guides/deploy/","tags":"","title":"Deploy OSRD"},{"body":"Tout d’abord, nous recommandons de se familiariser sur l’architecture des conteneurs d’OSRD.\nNous allons couvrir comment déployer OSRD dans les configurations suivantes :\nUtiliser docker compose sur un seul nœud. Utiliser helm sur un cluster kubernetes. Il est également possible de déployer manuellement chaque service d’OSRD sur un système, mais nous ne couvrirons pas ce sujet dans ce guide.\nNB Pour que l’outil STDCM fonctionne, il faut configurer l’environnement de recherche STDCM, une configuration stockée en base de données. Consultez la page dédiée pour plus d’informations. ","categories":"","description":"Apprenez à déployer OSRD dans différents environnements","excerpt":"Apprenez à déployer OSRD dans différents environnements","ref":"/fr/docs/guides/deploy/","tags":"","title":"Déployer OSRD"},{"body":"The OSRD project includes a docker-compose.yml file designed to facilitate the deployment of a fully functional OSRD environment. Only intended for development purposes, this Docker Compose configuration could be adapted for quick, single-node deployments.\nDisclaimer This setup is designed for development only. For example no authentication is supported and the front-end is served in development mode (rebuilt on the fly). If you mean to deploy a production ready version of OSRD, please follow the Kubernetes-based deployment Prerequisites Before proceeding with the deployment, ensure that you have the following installed:\nDocker Docker Compose Configuration Overview The docker-compose.yml file defines the following services:\nPostgreSQL: A PostgreSQL database with PostGIS extension. Valkey: A Valkey server for caching. Core: The core OSRD service. Front: The front-end service for OSRD. Editoast: A OSRD service responsible for various editorial functions. Gateway: Serves as the gateway for the OSRD services. Wait-Healthy: A utility service to ensure all services are healthy before proceeding. Each service is configured with health checks, volume mounts and necessary environment variables.\nDeployment Steps Clone the Repository: First, clone the OSRD repository to your local machine. Configuration: The default configuration requires setting an environment variable for the Editoast service: ROOT_URL. It should be set to the URL pointing to the Editoast service through the gateway. For example, “http://your-domain.com/api\". You can also adjust other environment variables if needed. Build and Run: Navigate to the directory containing docker-compose.yml and run: docker-compose up --build This command builds the images and starts the services defined in the Docker Compose file.\nAccessing Services While all HTTP service are used through the gateway (http://localhost:4000), you can access directly each service using their exposed ports:\nPostgreSQL: Accessible on localhost:5432. Valkey: Accessible on localhost:6379. Core Service: Accessible on localhost:8080. Front-End: Accessible on localhost:3000. Editoast: Accessible on localhost:8090. Notes and Considerations This setup is designed for development and quick deployments. For production environments, additional considerations for security, scalability and reliability should be addressed. Ensure that the POSTGRES_PASSWORD and other sensitive credentials are securely managed, especially in production deployments. ","categories":"","description":"Using docker compose for single node deployment","excerpt":"Using docker compose for single node deployment","ref":"/en/docs/guides/deploy/docker-compose/","tags":"","title":"Docker Compose"},{"body":"Le projet OSRD inclut un fichier docker-compose.yml conçu pour faciliter le déploiement d’un environnement OSRD pleinement fonctionnel. Exclusivement destiné à des fins de développement, cette configuration Docker Compose pourrait être adaptée pour des déploiements rapides sur un seul nœud.\nAvertissement Cette configuration est prévue seulement à des fins de développement. Par exemple, aucune authentification n’est prise en charge et le front-end est déployé en mode développement (reconstruit à la volée). Si vous souhaitez déployer une version d’OSRD dédiée à un environment de production, veuillez suivre le déploiement via Kubernetes Prérequis Avant de procéder au déploiement, assurez-vous que vous avez installé :\nDocker Docker Compose Vue d’ensemble de la configuration Le fichier docker-compose.yml définit les services suivants :\nPostgreSQL : Une base de données PostgreSQL avec l’extension PostGIS. Valkey : Un serveur Valkey pour le cache. Core : Le service central OSRD. Front : Le service front-end pour OSRD. Editoast : Un service OSRD responsable de diverses fonctions d’édition. Gateway : Sert de passerelle pour les services OSRD. Wait-Healthy : Un service utilitaire pour s’assurer que tous les services sont sains avant de procéder. Chaque service est configuré avec des contrôles de santé, des montages de volumes et les variables d’environnement nécessaires.\nÉtapes du déploiement Cloner le dépôt : Tout d’abord, clonez le dépôt OSRD sur votre machine locale. Configuration : La configuration par défaut nécessite le renseignement d’une variable d’environnement pour le service Editoast: ROOT_URL. Il faut lui donner la valeur de l’URL qui pointe vers le service Editoast par la gateway. Par exemple “http://your-domain.com/api\". Vous pouvez également ajuster d’autres variables d’environnement si nécessaire. Construire et exécuter : Naviguez vers le répertoire contenant docker-compose.yml et exécutez : docker-compose up --build Cette commande construit les images et démarre les services définis dans le fichier Docker Compose.\nAccès aux services Bien que tous les services HTTP soient utilisés via la passerelle (http://localhost:4000), vous pouvez accéder directement à chaque service en utilisant leurs ports exposés :\nPostgreSQL : Accessible sur localhost:5432. Valkey : Accessible sur localhost:6379. Service Core : Accessible sur localhost:8080. Front-End : Accessible sur localhost:3000. Editoast : Accessible sur localhost:8090. Notes et considérations Cette configuration est conçue pour le développement et les déploiements rapides. Pour les environnements de production, des considérations supplémentaires en matière de sécurité, de scalabilité et de fiabilité doivent être abordées. Assurez-vous que le POSTGRES_PASSWORD et d’autres identifiants sensibles sont gérés en toute sécurité, en particulier dans les déploiements de production. ","categories":"","description":"Utiliser docker compose pour un déploiement sur un seul nœud","excerpt":"Utiliser docker compose pour un déploiement sur un seul nœud","ref":"/fr/docs/guides/deploy/docker-compose/","tags":"","title":"Docker Compose"},{"body":" This document is an annex to the main authorization design document\nThis design document is not intended to describe the exact editoast authorization API. The actual implementation may slightly differ. If major limitations were uncovered, please update this document.\nContext and requirements The following invariants were deemed worth validating:\n(high priority) role and privilege checks were performed (low priority) privilege checks are performed before changes are made / data is returned (low priority) access patterns match privilege checks Other design criterias have an impact:\n(high priority) misuse potential (high priority) usage complexity and developer experience (medium priority) ease of migration (low priority) static checks are prefered Data model Builtin roles First, we define an enum for all our builtin roles:\n#[derive(Roles, EnumSetType, Copy)] enum BuiltinRole { #[role(tag = \"infra:read\")] InfraRead, #[role(tag = \"infra:write\", implies = [InfraRead])] InfraWrite, #[role(tag = \"rolling-stock:read\")] RollingStockRead, #[role(tag = \"rolling-stock:write\", implies = [RollingStockRead])] RollingStockWrite, #[role(tag = \"timetable:read\")] TimetableRead, #[role(tag = \"timetable:write\", implies = [TimetableRead])] TimetableWrite, #[role(tag = \"operational-studies:read\", implies = [TimetableRead, InfraRead, RollingStockRead])] OperationalStudiesRead, #[role(tag = \"operational-studies:write\", implies = [OperationalStudiesRead, TimetableWrite])] OperationalStudiesWrite, } which could expand to:\n#[derive(EnumSetType, Copy)] enum BuiltinRole { InfraRead, InfraWrite, RollingStockRead, RollingStockWrite, TimetableRead, TimetableWrite, OperationalStudiesRead, OperationalStudiesWrite, } const ROLES: phf::Map\u003c\u0026'static str, BuiltinRole\u003e = phf::phf_map! { \"infra:read\" =\u003e Self::InfraRead, \"infra:write\" =\u003e Self::InfraWrite, \"rolling-stock:read\" =\u003e Self::RollingStockRead, \"rolling-stock:write\" =\u003e Self::RollingStockWrite, \"timetable:read\" =\u003e Self::TimetableRead, \"timetable:write\" =\u003e Self::TimetableWrite, \"operational-studies:read\" =\u003e Self::OperationalStudiesRead, \"operational-studies:write\" =\u003e Self::OperationalStudiesWrite, }; impl BuiltinRole { fn parse_tag(tag: \u0026str) -\u003e Option\u003cBuiltinRole\u003e { ROLES.get(tag) } fn tag(\u0026self) -\u003e \u0026'static str { match self { Self::InfraRead =\u003e \"infra:read\", Self::InfraWrite =\u003e \"infra:write\", Self::RollingStockRead =\u003e \"rolling-stock:read\", Self::RollingStockWrite =\u003e \"rolling-stock:write\", Self::TimetableRead =\u003e \"timetable:read\", Self::TimetableWrite =\u003e \"timetable:write\", Self::OperationalStudiesRead =\u003e \"operational-studies:read\", Self::OperationalStudiesWrite =\u003e \"operational-studies:write\", } } fn implies(\u0026self) -\u003e \u0026[Self] { match self { Self::InfraRead =\u003e \u0026[Self::InfraRead], Self::InfraWrite =\u003e \u0026[Self::InfraRead, Self::InfraWrite], Self::RollingStockRead =\u003e \u0026[Self::RollingStockRead], Self::RollingStockWrite =\u003e \u0026[Self::RollingStockRead, Self::RollingStockWrite], Self::TimetableRead =\u003e \u0026[Self::TimetableRead], Self::TimetableWrite =\u003e \u0026[Self::TimetableRead, Self::TimetableWrite], Self::OperationalStudiesRead =\u003e \u0026[Self::TimetableRead, Self::InfraRead, Self::RollingStockRead], Self::OperationalStudiesWrite =\u003e \u0026[Self::OperationalStudiesRead, Self::TimetableWrite], } } } Application roles Application roles are loaded from a yaml file at application startup:\napplication_roles: ops: name: \"DevOps\" description: \"Software engineers in charge of operating and maintaining the app\" implies: [admin] stdcm-customer: name: \"STDCM customer\" implies: [stdcm] operational-studies-customer: name: \"Operational studies customer\" implies: [operational-studies:read] operational-studies-analyse: name: \"Operational studies analyse\" implies: [operational-studies:write] Once loaded into editoast, app roles are resolved to a set of user roles:\ntype UserRoles = EnumSet\u003cBuiltinRole\u003e; struct AppRoleResolver(HashMap\u003cString, UserRoles\u003e); /// The API does not allow querying app roles, as it should have no impact on authorization: /// only the final resolved set of builtin roles matters. impl AppRoleResolver { fn load_from_config(\u0026path: Path) -\u003e Result\u003cSelf, E\u003e; fn resolve(\u0026self, app_role_tag: \u0026str) -\u003e Result\u003cUserRoles, E\u003e; } Resources and grants TODO: decide where to process implicit grants: database or editoast?\nenum ResourceType { Group, Project, Study, Scenario, Timetable, Infra, RollingStockCollection, } struct Grant { grant_id: u64, subject: SubjectId, privlvl: GrantPrivLvl, granted_by: UserId, granted_at: Timestamp, } async fn all_grants(conn, resource_type: ResourceType, resource_id: u64) -\u003e Vec\u003cGrant\u003e; async fn applicable_grants(conn, resource_type: ResourceType, resource_id: u64, subject_ids: Vec\u003cSubjectId\u003e) -\u003e Vec\u003cGrant\u003e; async fn revoke_grant(conn, resource_type: ResourceType, grant_id: u64); async fn update_grant(conn, resource_type: ResourceType, grant_id: u64, privlvl: GrantPrivLvl); Low level authorization API struct PrivCheck { resource_type: ResourceType, resource_id: u64, minimum_privlvl: EffectivePrivLvl, } /// The authorizer is injected into each request by a middleware. /// The middleware finds the user ID associated with the request. /// At the end of each request, it ensures roles and privileges were checked. struct Authorizer { user_id: u64, checked_roles: Option\u003cUserRoles\u003e, checked_privs: Option\u003cVec\u003cPrivCheck\u003e\u003e, }; impl FromRequest for Authorizer {} impl Authorizer { async fn check_roles( conn: \u0026mut DatabaseConnection, required_roles: \u0026[BuiltinRole], ) -\u003e Result\u003cbool, Error\u003e; async fn check_privs( conn: \u0026mut DatabaseConnection, required_privs: \u0026[PrivCheck], ) -\u003e Result\u003cbool, Error\u003e; } This API is then used as follows:\n#[post(\"/project/{project_id}/study/{study_id}/scenario\")] async fn create_scenario( path: Path\u003c(i64, i64)\u003e, authz: Authorizer, db_pool: web::Data\u003cDatabasePool\u003e, Json(form): Json\u003cScenarioCreateForm\u003e, ) -\u003e Result\u003cResponse, Error\u003e { let conn, db_pool.get().await; let (project_id, study_id) = path.into_inner(); // validate that study.scenario == scenario authz.check_roles(\u0026mut conn, \u0026[BuiltinRoles::OperationalStudiesWrite]).await?; authz.check_privs(\u0026mut conn, \u0026[(Study, study_id, Creator).into()]).await?; // create the object // ... Ok(...) } High level authorization API 🤔 Proposal: fully dynamic checks This proposal suggests dynamically enforcing all authorization invariants:\nrole and privilege checks were performed: The authorizer records all checks, and panics / logs an error if no check is made privilege checks are performed before changes are made / data is returned: checked database accesses (the default) cannot be made before commiting authorization checks. No more authorization check can be made after commiting. access patterns match privilege checks: Check database access functions ensure a prior check was made using the Authorizer’s check log. Each database access method thus gets two variants:\na checked variant (the default), which takes the Authorizer as a parameter. This variants panics if:\na resource is accessed before authorization checks are commited a resource is accessed without a prior authorizer check. an unchecked variant. its use should be limited to:\nfetching data for authorization checks updating modification dates #[post(\"/project/{project_id}/study/{study_id}/scenario\")] async fn create_scenario( path: Path\u003c(i64, i64)\u003e, authz: Authorizer, db_pool: web::Data\u003cDatabasePool\u003e, Json(form): Json\u003cScenarioCreateForm\u003e, ) -\u003e Result\u003cResponse, Error\u003e { let conn, db_pool.get().await; let (project_id, study_id) = path.into_inner(); // Check if the project and the study exist let (mut project, mut study) = check_project_study_conn(\u0026mut conn, project_id, study_id).await?; authz.check_roles(\u0026mut conn, \u0026[BuiltinRoles::OperationalStudiesWrite])?; authz.check_privs(\u0026mut conn, \u0026[(Study, study_id, Creator).into()])?; // all checks done, checked database accesses allowed authz.commit(); // ... // create the scenario let scenario: Scenario = data.into_scenario(study_id, timetable_id); let scenario = scenario.create(db_pool.clone(), \u0026authz).await?; // Update study last_modification field study.update_last_modified(conn).await?; // Update project last_modification field project.update_last_modified(conn).await?; // ... Ok(...) } Bonus proposal: require roles using macros TODO: check if this is worth keeping\nThen, we annotate each endpoint that require role restrictions with requires_roles:\n#[post(\"/scenario\")] #[requires_roles(BuiltinRoles::OperationalStudiesWrite)] async fn create_scenario( user: web::Header\u003cGwUserId\u003e, db_pool: web::Data\u003cDatabasePool\u003e ) -\u003e Result\u003cResponse, Error\u003e { todo!() } which may expand to something similar to:\nasync fn create_scenario( user: web::Header\u003cGwUserId\u003e, db_pool: web::Data\u003cDatabasePool\u003e ) -\u003e Result\u003cResponse, Error\u003e { { let conn = \u0026mut db_pool.get().await?; let required_roles = [BuiltinRoles::OperationalStudiesWrite]; if !editoast_models::check_roles(conn, \u0026user_id, \u0026required_roles).await? { return Err(403); } } async move { todo!() }.await } 🤔 Proposal: Static access control This proposal aims at improving the Authorizer descibed above by building on it a safety layer that encodes granted permissions into the type system.\nThis way, if access patterns do not match the privilege checks performed beforehand, the program will fail to compile and precisely pinpoint the privilege override as a type error.\nTo summarize, the Authorizer allows us to:\nPre-fetch the user of the request and its characteristics as a middleware Check their roles Maintain a log of authorization requests on specific ressources, and check if they hold Guarantees that no authorization will be granted passed a certain point (commit function) At the end of an endpoint, checks that permissions were granted or panic!s otherwise While all these checks are performed at runtime, those can be tested rather trivially in unit tests.\nHowever, the Authorizer cannot check that the endpoints actually respect the permission level they asked for when they access the DB. For example, an endpoint might ask for Read privileges on a Timetable, only to delete it afterwards. This is trivial to check if the privilege override happens in the same function, but it can be much more vicious if that happens conditionally, in another function, deep down the call stack. For the same reasons, refactoring code subject to authorizations becomes much more risky and error prone.\nHence, for both development and review experience, to ease writing and refactoring authorizing code, to be confident our system works, and for general peace of mind, we need a way to ensure that an endpoint won’t go beyond the privilege level it required for all of its code paths.\nWe can do that either statically or dynamically.\nDynamic access pattern checks Let’s say we keep the Authorizer as the high-level API for authorization. It holds a log of grants. Therefore, any DB operation that needs to be authorized must, in addition to the conn, take an Arc\u003cAuthorizer\u003e parameter and let the operation check that it’s indeed authorized. For example, every retrieve(conn, authorizer, id) operation would ask the authorizer the permission before querying the DB.\nThis approach works and has the benefit of being easy to understand, but does not provide any guarantee that the access paterns match the granted authorizations and that privilege override cannot happen. A way to ensure that would be to thoroughly test each endpoint and ensure that the DB accesses panic in expected situations. Doing so manually is extremely tedious and fragile in the long run, so let’s focus on automated tests. To make sure that, at any moment, each endpoint doesn’t override its privileges, we’d need a test for each releveant privilege level and for each code path accessing ressources. Admittedly this would be great, but:\nit heavily depends on test coverage (which we don’t have) to make sure no code path is left out, i.e. that no test is missing it’s unrealistic given the current state of things and how fast editoast changes tests would be extremely repetitive, and mistakes will happen the test suite of an endpoint now not only depends on what it should do, but also on how it should do it: i.e. to know how to test your endpoint, you need to know precisely what DB operations will be performed, under what conditions, on all code paths, and replicate that when refactoring code subject to authorization that’s shared across several endpoints, the tests of each of these endpoints would need to be examined to ensure no check goes missing unless we postpone the creation of these tests and accept a lower level of confidence in our system, even temporarily(TM), the authz migration would be slowed down significantly Or we could just accept the risk.\nOr we could statically ensure that no endpoint override its requested privileges, using the typesystem, and be sure that such issues can (almost) never arise.\nStatic checks The idea is to provide an high-level API for authorization, on top of the Authorizer. It encodes granted privileges into the typesystem. For example, for a request GET /timetable/42, the endpoint will ask from the Authorizer an Authz\u003cTimetable, Read\u003e object:\nlet timetable_authz: Authz\u003cTimetable, Read\u003e = authorizer.authorize(\u0026[42])?; The authorizer does two things here:\nChecks that the privilege level of the user allows them to Read on the timetable ID#42. Builds an Authz object that stores the ID#42 for later checks, which encodes in the type system that we have a Read authorization on some Timetable ressources. Then, after we authorizer.commit();, we can use the Authz to effectively request the timetable:\nlet timetable: Timetable = timetable_authz.retrieve(conn, 42)?; The Authz checks that the ID#42 is indeed authorized before forwarding the call the modelv2::Retrieve::retrieve function that performs the query. However, if by mistake we wrote:\nlet timetable = timetable_authz.delete(conn, 42)?; we’d get a compilation error such as Trait AuthorizedDelete is not implemented for Authz\u003cTimetable, Read\u003e, effectively preventing a privilege override statically.\nOn a more realistic example:\nimpl Scenario { fn remove( self, conn: \u0026mut DatabaseConnection, scenario_authz: Authz\u003cSelf, Delete\u003e, study_authz: Authz\u003cStudy, Update\u003e, ) -\u003e Result\u003c(), Error\u003e { // open transaction scenario_authz.delete(conn, self.id)?; let cs = Study::changeset().last_update(Datetime::now()); study_authz.update(conn, self.study_id, cs)?; Ok(()) } } This approach brings several advantages:\ncorrectness: the compiler will prevent any privilege override for us readability: if a function requires some form of authorization, it will show in its prototype ease of writing: we can’t write DB operations that ultimately wouldn’t be authorized, avoiding a potential full rewrite once we notice the problem (and linting is on our side to show problems early) more declarative: if you want to read an object, you ask for a Read permission, the system is then responsible for checking the privilege level and map that to a set of allowed permissions. This way we abstract a little over the hierarchy of privileges a ressource can have. ease of refactoring: thanks rustc ;) flexibility: since the Authz has a reference to the Authorizer, the API mixes well with more dynamic contexts (should we need that in the future) migration shouldn’t be too complex or costly since the Authz wraps the ModelV2 traits will require changes in the same areas that would be impacted by a dynamic checker, no more, no less (even in the dynamic context mentioned above we still need to pass the Arc\u003cAuthorizer\u003e down the call stack) contamination: admittedly, this API is slightly more contaminating than just passing an Arc\u003cAuthorizer\u003e everywhere. However, this issue is mitigated on several fronts: most endpoints in editoast either access the DB in the endpoint function itself, or in at most one or two function calls deep. So the contamination likely won’t spread far and the migration shouldn’t take much more time. if we notice that a DB call deep down the call stack requires an Authz\u003cT, _\u003e that we need to forward through many calls, it’s probably pathological of a bad architecture The following sections explore how to use this API:\nto define authorized ressources implement the effective privilege level logic to deal with complex ressources (here Study) which need custom authorization rules and that are not atomic (the budgets follow different rules than the rest of the metadata) to implement an endpoint that require different permissions (create_scenario) Actions We define all actions our Authz is able to expose at both type-level and at runtime (classic CRUD + Append for exploitation studies).\nmod action { struct Create; struct Read; struct Update; struct Delete; struct Append; enum Cruda { Create, Read, Update, Delete, Append, } trait AuthorizedAction { fn as_cruda() -\u003e Cruda; } impl AuthorizedAction for Create; impl AuthorizedAction for Read; impl AuthorizedAction for Update; impl AuthorizedAction for Delete; impl AuthorizedAction for Append; } The motivation behind this is that at usage, we don’t usually care about the privilege of a user over a ressource. We only care, if we’re about to read a ressource, whether the user has a privilege level high enough to do so.\nThe proposed paradigm here is to ask the permission to to an action over a ressource, and let the ressource definition module decide (using its own effective privilege hierarchy) whether the action is authorized or not.\nStandard and custom effective privileges We need to define the effective privilege level for each ressource. For most ressources, a classic Reader \u003c Writer \u003c Owner is enough. So we expose that by default, leaving the choice to each ressource to provide their own.\nWe also define an enum providing the origin of a privilege, which is a useful information for permission sharing.\n// built-in the authorization system #[derive(PartialOrd, PartialEq)] enum StandardPrivilegeLevel { Read, Write, Own, } enum StandardPrivilegeLevelOrigin { /// It's an explicit privilege User, /// The implicit privilege comes from a group the user belongs to Group, /// The implicit privilege is granted publicly (authz_grant_xyz.subject IS NULL) Public, } trait PrivilegeLevel: PartialOrd + PartialEq { type Origin; } impl PrivilegeLevel for StandardPrivilegeLevel { type Origin = StandardPrivilegeLevelOrigin; } Grant definition Then we need to associate to each grant in DB its effective privilege level and origin.\n// struct AuthzGrantInfra is a struct that models the table authz_grant_infra impl EffectiveGrant for AuthzGrantInfra { type EffectivePrivilegeLevel = StandardPrivilegeLevel; async fn fetch_grants( conn: \u0026mut DbConnection, subject: \u0026Subject, keys: \u0026[i64], ) -\u003e GrantMap\u003cSelf::EffectivePrivilegeLevel\u003e? { crate::tables::authz_grants_infra.filter(... } } where GrantMap\u003cPrivilegeLevel\u003e is an internal representation of a collection of grants (implicit and explicit) with some privilege level hierarchy (custom or not).\nRessource definition Each ressource is then associated to a model and a grant type. We also declare which actions are allowed based on how we want the model to be used given the effective privilege of the ressource in DB.\nThe RessourceType is necessary for the dynamic context of the underlying Authorizer.\nimpl Ressource for Infra { type Grant = AuthzGrantInfra; const TYPE: RessourceType = RessourceType::Infra; /// Returns None is the action is prohibited fn minimum_privilege_required(action: Cruda) -\u003e Option\u003cSelf::Grant::EffectivePrivilegeLevel\u003e { use Cruda::*; use StandardPrivilegeLevel as lvl; Some(match action { Read =\u003e lvl::Read, Create | Update | Append =\u003e lvl::Write, Delete =\u003e lvl::Own, }) } } And that’s it!\nThe rest of the mechanics are located within the authorization system.\nA more involved example: Studies //////// Privilege levels enum StudyPrivilegeLevel { ReadMetadata, // a scenario of the study has been shared Read, Append, // can only create scenarios Write, Own, } enum StudyPrivilegeLevelOrigin { User, Group, Project, // the implicit privilege comes from the user's grants on the study's project Public, } impl PrivilegeLevel for StudyPrivilegeLevel { type Origin = StudyPrivilegeLevelOrigin; } ///////// Effective grant retrieval impl EffectiveGrant for AuthzGrantStudy { type EffectivePrivilegeLevel = StudyrivilegeLevel; async fn fetch_grants( conn: \u0026mut DbConnection, subject: \u0026Subject, keys: \u0026[i64], ) -\u003e GrantMap\u003cSelf::EffectivePrivilegeLevel\u003e? { // We implement here the logic of implicit privileges where an owner // of a project is also owner of all its studies crate::tables::authz_grants_study .filter(...) .inner_join(crate::tables::study.on(...)) .inner_join(crate::tables::project.on(...)) .inner_join(crate::tables::authz_grants_project.on(...)) } } //////// Authorized ressources /// Budgets of the study (can be read and updated by owners) struct StudyBudgets { ... } impl Ressource for StudyBudgets { type Grant = AuthzGrantStudy; const TYPE: RessourceType = RessourceType::Study; fn minimum_privilege_required(action: Cruda) -\u003e Option\u003cStudyPrivilegeLevel\u003e { use Cruda::*; use StudyPrivilegeLevel as lvl; Some(match action { Read | Update =\u003e lvl::Own, _ =\u003e return None, }) } } /// Non-sensitive metadata available to users with privilege level MinimalMetadata (can only be read) struct StudyMetadata { ... } impl Ressource for StudyMetadata { type Grant = AuthzGrantStudy; const TYPE: RessourceType = RessourceType::Study; fn minimum_privilege_required(action: Cruda) -\u003e Option\u003cStudyPrivilegeLevel\u003e { use Cruda::*; use StudyPrivilegeLevel as lvl; Some(match action { Read =\u003e lvl::ReadMetadata, _ =\u003e return None, }) } } /// A full study (can be created, read, updated, appended and deleted) struct Study { ... } impl Ressource for Study { type Grant = AuthzGrantStudy; const TYPE: RessourceType = RessourceType::Study; fn minimum_privilege_required(action: Cruda) -\u003e Option\u003cStudyPrivilegeLevel\u003e { use Cruda::*; use StudyPrivilegeLevel as lvl; Some(match action { Read =\u003e lvl::Read, Append =\u003e lvl::Append, Create =\u003e lvl::Create, Update =\u003e lvl::Write, Delete =\u003e lvl::Own, }) } } Concrete endpoint definition #[post(\"/scenario\")] async fn create_scenario( authorizer: Arc\u003cAuthorizer\u003e, conn: DatabaseConnection, db_pool: web::Data\u003cDatabasePool\u003e, Json(form): Json\u003cScenarioCreateForm\u003e, path: Path\u003c(i64, i64)\u003e, authz: Authorizer, ) -\u003e Result\u003cResponse, Error\u003e { let conn, db_pool.get().await; let (project_id, study_id) = path.into_inner(); let ScenarioCreateForm { infra_id, timetable_id, .. } = \u0026form; authorizer.authorize_roles(\u0026mut conn, \u0026[BuiltinRoles::OperationalStudiesWrite]).await?; let _ = authorizer.authorize::\u003cTimetable, Read\u003e(\u0026mut conn, \u0026[timetable_id]).await?; let _ = authorizer.authorize::\u003cInfra, Read\u003e(\u0026mut conn, \u0026[infra_id]).await?; let study_authz: Authz\u003cStudy, Append\u003e = authorizer.authorize(\u0026mut conn, \u0026[study_id]).await?; authorizer.commit(); let response = conn.transaction(move |conn| async { let scenario: Scenario = study_authz.append(\u0026mut conn, form.into()).await?; scenario.into_response() }).await?; Ok(Json(response)) } ","categories":"","description":"","excerpt":" This document is an annex to the main authorization design document …","ref":"/en/docs/reference/design-docs/auth/editoast-internal-api/","tags":"","title":"Editoast internal authorization API"},{"body":"Description Chaque élément mobile, aiguille ou passage à niveau, a une liste d’états possibles. Ces états sont mutuellement exclusifs.\nDépendances statique une liste d’élements mobiles statique liste des états possibles de chaque élément mobile Opérations possibles observer un élément mobile verrouiller / déverrouiller un élément mobile bouger un élément mobile ","categories":"","description":"Gère l'état des organes de commande des aiguilles, passages à niveau, …","excerpt":"Gère l'état des organes de commande des aiguilles, passages à niveau, …","ref":"/fr/docs/reference/design-docs/interlocking/movable-elements/","tags":"","title":"Éléments mobiles"},{"body":"La Helm Chart du projet OSRD fournit une solution pour déployer les services OSRD dans un environnement Kubernetes de manière standardisée. Ce document décrit les options de configuration disponibles dans le Helm Chart.\nPrérequis Avant de procéder au déploiement, assurez-vous que vous avez installé :\nUn cluster Kubernetes opérationnel Une base de données PostgreSQL avec PostGIS Un serveur Valkey (utilisé pour le cache) Le serveur de tuiles Le serveur de tuiles est le composant responsable de la génération des tuiles cartographiques vectorielles. Il est recommandé de le séparer du Editoast standard lors de l’exécution d’une configuration de production, car Editoast ne peut pas être mis à l’échelle horizontalement (il est stateful).\nVous pouvez visualiser le déploiement recommandé ici :\nflowchart TD gw[\"gateway\"] front[\"fichier statiques front-end\"] gw -- fichier local --\u003e front navigateur --\u003e gw gw -- HTTP --\u003e editoast gw -- HTTP --\u003e tileserver-1 gw -- HTTP --\u003e tileserver-2 gw -- HTTP --\u003e tileserver-n... editoast -- HTTP --\u003e core Le Helm Chart utilise leHorizontalPodAutoscaler de Kubernetes pour lancer autant de serveurs de tuiles que nécessaire en fonction de la charge de travail.\nConfiguration de la Helm Chart (values) Le Helm Chart est configurable à travers les valeurs suivantes :\nService Core core : Configuration pour le service central OSRD. internalUrl : URL interne pour la communication entre services. image : Image Docker à utiliser. pullPolicy : Politique de récupération de l’image. replicaCount : Nombre de réplicas. service : Type de service et configuration des ports. resources, env, annotations, labels, nodeSelector, tolerations, affinity : Diverses options de déploiement Kubernetes. Service Editoast editoast : Configuration pour le service Editoast. Comprend des options similaires à core pour le déploiement Kubernetes. init : Configuration d’initialisation. Serveur de tuiles tileServer : Service Editoast spécialisé qui sert uniquement des tuiles cartographiques vectorielles. enabled : Définir sur true pour activer la fonctionnalité de serveur de tuiles. image : Image Docker à utiliser (généralement la même que Editoast). replicaCount : Nombre de réplicas, permettant la mise à l’échelle horizontale. hpa : Configuration de l’Horizontal Pod Autoscaler. Autres options standard de déploiement Kubernetes. Gateway gateway : Configuration pour le gateway OSRD. Comprend des options de service, d’ingress et d’autres options de déploiement Kubernetes. config : Configurations spécifiques pour l’authentification et les proxys de confiance. Déploiement Le chart est disponible dans le dépôt OCI ghcr. Vous pouvez trouver 2 versions de la chart :\nCharts stables : oci://ghcr.io/OpenRailAssociation/charts/osrd Charts de développement : oci://ghcr.io/OpenRailAssociation/charts/osrd-dev Pour déployer les services OSRD en utilisant Helm :\nConfigurer les valeurs : Ajustez les valeurs selon vos besoins de déploiement.\nInstaller le Chart : Utilisez la commande helm install pour installer la chart dans votre cluster Kubernetes.\nhelm install osrd oci://ghcr.io/OpenRailAssociation/charts/osrd -f values.yml ","categories":"","description":"Utilisation de Helm pour les déploiements Kubernetes","excerpt":"Utilisation de Helm pour les déploiements Kubernetes","ref":"/fr/docs/guides/deploy/kubernetes/","tags":"","title":"Kubernetes avec Helm"},{"body":"The OSRD project’s Helm Chart provides a flexible and efficient way to deploy OSRD services in a Kubernetes environment. This document outlines the configuration options available in the Helm Chart, focusing on each service component.\nPrerequisites Before proceeding with the deployment, ensure that you have the following installed:\nA Kubernetes cluster up and running A PostgreSQL database with PostGIS A Valkey server (used for caching) The tileserver Tileserver is the component responsible for generating vector map tiles. It is recommended to separate it from standard Editoast while running a production setup since Editoast cannot be scaled horizontally (it is stateful).\nYou can visualize the recommended deployment here:\nflowchart TD gw[\"gateway\"] front[\"front-end static files\"] gw -- local file --\u003e front browser --\u003e gw gw -- HTTP --\u003e editoast gw -- HTTP --\u003e tileserver-1 gw -- HTTP --\u003e tileserver-2 gw -- HTTP --\u003e tileserver-n... editoast -- HTTP --\u003e core The Helm chart leverages Kubernete’s HorizontalPodAutoscaler in order to spawn as much tileserver as required for the current workload.\nChart Values Overview The Helm Chart is configurable through the following values:\nCore Service core: Configuration for the core OSRD service. internalUrl: Internal URL for service communication. image: Docker image to use. pullPolicy: Image pull policy. replicaCount: Number of replicas. service: Service type and port configuration. resources, env, annotations, labels, nodeSelector, tolerations, affinity: Various Kubernetes deployment options. Editoast Service editoast: Configuration for the Editoast service. Includes similar options as core for Kubernetes deployment. init: Initialization configuration. Tile Server tileServer: Specialized Editoast service that serves only vector map tiles. enabled: Set to true to enable tile server functionality. image: Docker image to use (typically the same as Editoast). replicaCount: Number of replicas, allowing for horizontal scaling. hpa: Horizontal Pod Autoscaler configuration. Other standard Kubernetes deployment options. Gateway gateway: Configuration for the OSRD gateway. Includes service, ingress, and other Kubernetes deployment options. config: Specific configurations for authentication and trusted proxies. Deployment The chart is available at ghcr OCI repository. You can find 2 Helm charts:\nStable charts: oci://ghcr.io/OpenRailAssociation/charts/osrd Dev charts: oci://ghcr.io/OpenRailAssociation/charts/osrd-dev To deploy the OSRD services using this Helm Chart:\nConfigure Values: Adjust the values in the Helm Chart to suit your deployment needs.\nInstall Chart: Use Helm to install the chart into your Kubernetes cluster.\nhelm install osrd oci://ghcr.io/OpenRailAssociation/charts/osrd -f values.yml ","categories":"","description":"Using Helm for Kubernetes deployments","excerpt":"Using Helm for Kubernetes deployments","ref":"/en/docs/guides/deploy/kubernetes/","tags":"","title":"Kubernetes with Helm"},{"body":"Tout est présenté dans un site dédié https://design.osrd.fr\nUn « design system » est en cours d’élaboration.\n","categories":"","description":"Les couleurs, la police, les usages...","excerpt":"Les couleurs, la police, les usages...","ref":"/fr/docs/guides/design/","tags":"","title":"Le design d'OSRD"},{"body":"Vous pouvez télécharger chaque logo indépendamment en cliquant directement dessus, ou tous les logos compressés dans un fichier zip.\nIl est conseillé de bien choisir le logo à utiliser en fonction du fond sur lequel vous voulez l’afficher.\nLa modification, ajout ou suppression de l’ombrage autre que tel que présenté dans les logos ne sont pas autorisés (cela est valable plus globalement dans tout le design, le choix de mettre des ombres portées fait partie des réflexions de design, ce n’est pas un élément variable).\nOfficiel Officiel pour les fonds sombres Blanc Noir Favicons, logos seuls 🚫 Ce qu’on ne doit pas faire Trop petit (\u003c 16px de hauteur) Disproportion Changer la couleur du texte ou l’ombre portée Changer le sens Déformation ✅ Ce qu’on peut faire Modification de la couleur interne pour un évènement Utilisation seule du logo (sans le texte) Les couleurs Ces couleurs sont celles du logo, elles ne sont pas à confondre avec celles du design global de l’interface d’OSRD.\n#786ABF #C7B2DE\n","categories":"","description":"Le logo d'OSRD, ses variantes, et son usage","excerpt":"Le logo d'OSRD, ses variantes, et son usage","ref":"/fr/docs/guides/logo/","tags":"","title":"Le logo"},{"body":"You can download each logo independently by clicking directly on it, or all the logos compressed into a zip file.\nIt is advisable to carefully choose the logo you want to use, depending on the background on which you want to display it.\nModification, addition or deletion of the shading other than as presented in the logos are not authorised (this applies more generally throughout the design, the choice to use drop shadows is part of the design considerations, it is not a variable element).\nOfficial Official for dark backgrounds White Black Favicons, logo without text 🚫 What you can’t do Too small (\u003c 16px height) Disproportion Change the text colour or drop shadow Changing direction Deformation ✅ What you can do Changing the internal colour for a specific event Use of logo only (without text) Colors These colours are those of the logo and should not be confused with those of the overall design of the OSRD interface.\n#786ABF #C7B2DE\n","categories":"","description":"The OSRD logo, its variants, and its use","excerpt":"The OSRD logo, its variants, and its use","ref":"/en/docs/guides/logo/","tags":"","title":"Logo"},{"body":"Everything is presented on a dedicated website https://design.osrd.fr\nA “design system” is being developed.\n","categories":"","description":"Colours, fonts, uses...","excerpt":"Colours, fonts, uses...","ref":"/en/docs/guides/design/","tags":"","title":"OSRD's design"},{"body":" This work is pending implementation, and has not yet been adjusted to reflect potential required adjustments.\nAfter two years of extending a fairly simple simulation engine, it appeared that fundamental changes are required to meet expectations.\nSystem requirements The new system is expected to:\nhandle reactions to signaling handle rich train state (pantograph position, battery state) allow for different margin algorithms integrate driver behavior properties be easy to integrate with timetable v2 handle both: simulations of a full trip, with a complete known path, possibly following a schedule simulations where the path is discovered incrementally provide a low-level API, usable independently In the long-term, this system is also expected to:\nbe used to drive multi-train simulations handling switching rolling stock at stops Concepts flowchart TD subgraph Input InitTrainState[initial train state] PathPhysicsProps[path physics properties] AbstractDrivingInstructions[abstract driving instructions] TargetSchedule[target schedule] end DrivingInstructionCompiler([driving instruction compiler]) ConcreteDrivingInstructions[driving instructions + limits] ScheduleController([schedule controller]) DriverBehaviorModule([driver behavior module]) TargetSchedule --\u003e ScheduleController ScheduleController -- adjusts slowdown coefficient --\u003e DriverBehaviorModule AbstractDrivingInstructions --\u003e DrivingInstructionCompiler PathPhysicsProps --\u003e DrivingInstructionCompiler ScheduleController -- tracks train state --\u003e TrainSim DriverBehaviorModule -- makes decisions --\u003e TrainSim ConcreteDrivingInstructions --\u003e DriverBehaviorModule DrivingInstructionCompiler --\u003e ConcreteDrivingInstructions InitTrainState --\u003e ScheduleController TrainSim --\u003e SimResults TrainSim([train simulator]) SimResults[simulation result curve] Target schedule The target schedule is a list of target arrival times at points specified along the path. To respect the schedule, the train may have to not use its maximum traction.\nTrain state The train state is a vector of properties describing the train at a given point in time.\nposition speed position of pantographs driver reaction times ? battery state ? time elapsed since the last update Driving instructions Driving instructions model what the train has to do along its path. They are linked to conditions on their application, and can interact with each other. They are generated using domain constraints such as speed limits or stops.\nSee the dedicated page for more details.\nPath properties Path properties are the physical properties of the path, namely elevation, curves and electrification.\nDriver behavior module The driver behavior modules update the train state based on:\nthe current train state the path properties the driving instructions a slowdown coefficient (1 = no slowdown, 0 = full stop) The train state changes should be physically realistic.\nSee the dedicated page for more details.\nSchedule controller The schedule controller manages the slowdown coefficient given to the driver behavior module in order to respect the target schedule.\nIt adjusts the slowdown coefficient iteratively, using a dichotomous search, re-simulating the train behavior between two time-targeted points.\nSimulation results The output of the simulation is the list of train states at each time step.\nDesign overview The main idea of the new train simulator is to have a simulation which is computed step by step and not post-processed. This would ensure the physical consistency of the simulation.\nThe challenge is then to add ways to lose some time, in order to respect the target schedule.\nThis is done by iterating over the sections between two scheduled points, while adjusting a slowdown factor. This slowdown factor would be used to control how the driver behavior module would lose time while still being physically realistic.\nSee the driver behavior module dedicated page for more details.\nIn order to accommodate an infrastructure which could change with time (like signals), we introduce driving instructions. These instructions are generated from the path properties and the target schedule, and are used to update the train state. Instructions can be conditional, and can interact with each other.\nThe algorithm is described in detail in the dedicated page.\nDesign limits trains do not anticipate margin transitions: only the next target arrival time matters for finding the slowdown factor ","categories":"","description":"","excerpt":" This work is pending implementation, and has not yet been adjusted to …","ref":"/en/docs/reference/design-docs/train-sim-v3/overview/","tags":"","title":"Overview"},{"body":"All OSRD releases are accessible here\nThe process for creating a new release is as follows:\nWe always release on a tested version of the application (staging branch) git switch staging \u0026\u0026 git pull Create a git annotated tag We are using the semantic versioning git tag -a vx.y.z with the message Release x.y.z (most of the time use the latest version and increment the patch version) git push --tags Create a github release Draft a new github release here Select the created tag Generate the releases notes Rename the release like so: “Version x.y.z” Check the “Set as a pre-release” box Apply the changelog format Then you can publish the release or save the draft if you want to come back later A github action should be triggered automatically. Post the link of the created release on matrix. Suggest that the developers review the release. Changelog format Use the following structure: ## What's Changed ### Features :tada: ### Code refactoring :recycle: ### Bug fixes :bug: ## New Contributors \u003c!-- Copy from the generated release notes --\u003e ... \u003c!-- Copy from the generated release notes --\u003e **Full Changelog**: ... Partition the different pull requests Merge or group PR when it make sense. Examples: Bump of dependencies PR (merge) Multi part PR (merge) One big feature implemented by multiple PR (group) Reword PR title. It should be comprehensible to an external collaborator ","categories":"","description":"How to make a release","excerpt":"How to make a release","ref":"/en/docs/guides/release/","tags":"","title":"Release"},{"body":"Each signaling system has:\nA unique identifier (a string). Its signal state type, which enables deducing: The graphical representation of the signal How a train would react to the signal If the signal state constrains Movement Authority The signal parameter types, names and description, which enable front-end edition of signal parameters. The block and route conditions, which enable evaluating whether a signal delimits blocks or routes, given its parameters. { # unique identifier for the signaling system \"id\": \"BAL\", \"version\": \"1.0\", # the schema of the dynamic state of signals of this type \"signal_state\": [ {\"kind\": \"enum\", \"field_name\": \"aspect\", values: [\"VL\", \"A\", \"S\", \"C\"]}, {\"kind\": \"flag\", \"field_name\": \"ralen30\"}, {\"kind\": \"flag\", \"field_name\": \"ralen60\"}, {\"kind\": \"flag\", \"field_name\": \"ralen_rappel\"} ], # describes static properties of the signal \"signal_properties\": [ {\"kind\": \"flag\", \"field_name\": \"Nf\", \"display_name\": \"Non-franchissable\"}, {\"kind\": \"flag\", \"field_name\": \"has_ralen30\", \"default\": false, \"display_name\": \"Ralen 30\"}, {\"kind\": \"flag\", \"field_name\": \"has_rappel30\", \"default\": false, \"display_name\": \"Rappel 30\"}, {\"kind\": \"flag\", \"field_name\": \"has_ralen60\", \"default\": false, \"display_name\": \"Ralen 60\"}, {\"kind\": \"flag\", \"field_name\": \"has_rappel60\", \"default\": false, \"display_name\": \"Rappel 60\"} ], # describes dynamic properties of the signal. These can be set on a per-route basis \"signal_parameters\": [ {\"kind\": \"flag\", \"field_name\": \"short_block\", \"default\": false, \"display_name\": \"Short block\"}, {\"kind\": \"flag\", \"field_name\": \"rappel30\", \"default\": false, \"display_name\": \"Rappel 30\"}, {\"kind\": \"flag\", \"field_name\": \"rappel60\", \"default\": false, \"display_name\": \"Rappel 60\"} ], # these are C-like boolean expressions: # true, false, \u003cflag\u003e, \u003cenum\u003e == value, \u0026\u0026, || and ! can be used # used to evaluate whether a signal is a block boundary. Only properties can be used, not parameters. \"block_boundary_when\": \"true\", # used to evaluate whether a signal is a route boundary. Only properties can be used, not parameters. \"route_boundary_when\": \"Nf\", # A predicate used evaluate whether a signal state can make a train slow down. Used for naive conflict detection. \"constraining_ma_when\": \"aspect != VL\" } ","categories":"","description":"","excerpt":"Each signaling system has:\nA unique identifier (a string). Its signal …","ref":"/en/docs/reference/design-docs/signaling/signaling-systems/","tags":"","title":"Signaling systems"},{"body":"In order for the STDCM tool to function, you’ll need to setup the STDCM Search Environment, a configuration stored in database.\nThe configurable fields are as such:\npub struct StdcmSearchEnvironment { pub infra_id: i64, pub electrical_profile_set_id: Option\u003ci64\u003e, pub work_schedule_group_id: Option\u003ci64\u003e, pub timetable_id: i64, pub search_window_begin: NaiveDateTime, pub search_window_end: NaiveDateTime, } This configuration is queried by the frontend. That way, the right objects and time bounds are used transparently by the user.\nIn order to setup this config, you can either\nUse the provided REST API (see the editoast openAPI in the stdcm_search_environment section) Use the provided editoast cli (run editoast stdcm-search-env help for more information) ","categories":"","description":"How to configure the STDCM search environment","excerpt":"How to configure the STDCM search environment","ref":"/en/docs/guides/deploy/stdcm-search-env/","tags":"","title":"STDCM search environment configuration"},{"body":"Regardless of your operating system, docker requires linux to operate. When used on a different operating system, docker relies on virtual machines to build and run images.\nThere are two main types of docker installations:\ndocker engine is the usual docker command line application docker desktop is a GUI app that also manages virtualization Here’s what we suggest:\nIf you’re on linux, install docker engine using your package manager If you’re on MacOS / Windows, install docker desktop if you are allowed to If you’re on windows and want to get docker running within WSL, or can’t use docker desktop, follow the docker on WSL tutorial If you’re on MacOS and can’t use docker desktop, follow the MacOS colima tutorial Docker on WSL This install option is very useful, as it allows having a perfectly normal linux install of docker engine inside WSL, which can still be reached from windows.\nInstall WSL (If you had an old version of WSL, run wsl --upgrade) Get an operating system image from the microsoft store (for example, debian or ubuntu) Enable systemd support within the WSL VM Follow the regular linux install tutorial for docker If you have docker desktop installed, you can configure it to use WSL MacOS colima This procedure allows installing docker without relying on docker desktop. It uses colima for virtualizing linux.\nInstall homebrew brew install docker docker-compose colima Install the compose plugin: mkdir -p ~/.docker/cli-plugins \u0026\u0026 ln -sfn $(brew --prefix)/opt/docker-compose/bin/docker-compose ~/.docker/cli-plugins/docker-compose Configure colima: for apple silicon (M1/M2) macbooks: colima start --cpu 2 --memory 6 --arch aarch64 --vm-type=vz --vz-rosetta --mount-type=virtiofs for small infrastructures: colima start --cpu 2 --memory 4 for big infrastructures: colima start --cpu 2 --memory 6 brew services start colima to automatically start colima on startup Exit your terminal, open a new one You can now use docker CLI If you’re using rancher desktop, please either:\nuninstall the application select Manual in Preferences \u003e Application \u003e Environement If you get an error at rosetta startup, run colima delete and try again (the disk format is not compatible). Settings will be lost. If you get this error: error getting credentials - err: exec: \"docker-credential-osxkeychain\": executable file not found in $PATH\nOpen ~/.docker/config.json, and remove \"credsStore\": \"osxkeychain\"\n","categories":"","description":"","excerpt":"Regardless of your operating system, docker requires linux to operate. …","ref":"/en/docs/guides/contribute/install-docker/","tags":"","title":"Install docker"},{"body":"Peu importe votre système d’exploitation, docker requiert linux pour fonctionner. Lorsqu’utilisé sous un autre système d’exploitation, docker a besoin de machines virtuelles linux pour build et exécuter des images.\nIl y a deux types d’installation docker :\ndocker engine est l’application en ligne de commande docker desktop est une application graphique, qui gère aussi la virtualisation Voici nos suggestions :\nSi vous êtes sous linux, installez docker engine via votre gestionnaire de packet Si vous êtes sous MacOS / Windows, installez docker desktop si vous y êtes autorisés Si vous êtes sous windows, et voulez faire fonctionner docker sous WSL, ou ne pouvez pas utiliser docker desktop, suivez le guide docker sous WSL Si vous êtes sous MacOS, et vous ne pouvez pas utiliser docker desktop, suivez le guide colima pour MacOS Docker sous WSL Cette option d’installation est très utile, car elle permet de disposer d’une installation tout à fait normale de docker engine Linux à l’intérieur de WSL, qui reste accessible depuis Windows.\nInstallez WSL (Si vous avez une vieille version de WSL, lancez wsl --upgrade) Obtenez une image WSL depuis le store microsoft (par exemple, debian or ubuntu) Activez le support systemd depuis la VM WSL Suivez le tutoriel d’installation docker engine pour votre distribution WSL Si vous avez docker desktop installé, vous pouvez le configurer pour qu’il utilise WSL MacOS colima Cette procédure permet d’installer docker sans passer par docker desktop. Elle utilise colima comme solution de virtualisation.\nInstallez homebrew brew install docker docker-compose colima Installez le plugin compose : mkdir -p ~/.docker/cli-plugins \u0026\u0026 ln -sfn $(brew --prefix)/opt/docker-compose/bin/docker-compose ~/.docker/cli-plugins/docker-compose Configurez colima : pour des macbooks apple silicon (M1/M2) : colima start --cpu 2 --memory 6 --arch aarch64 --vm-type=vz --vz-rosetta --mount-type=virtiofs pour de petites infrastructures: colima start --cpu 2 --memory 4 pour de grosses infrastructures: colima start --cpu 2 --memory 6 brew services start colima pour lancer automatiquement colima au démarrage Quittez votre terminal, ouvrez-en un nouveau Vous pouvez maintenant utiliser docker CLI Si vous utiliser rancher desktop, veuillez soit:\ndéinstaller l’application sélectioner Manuel dans Préférences \u003e Application \u003e Environnement En cas d’erreur au démarrage avec Rosetta 2, lancez colima delete et réessayez (le format de disque n’est pas compatible). Les paramètres seront perdus. Si vous avez cette erreur: error getting credentials - err: exec: \"docker-credential-osxkeychain\": executable file not found in $PATH\nOuvrez ~/.docker/config.json, et enlevez \"credsStore\": \"osxkeychain\"\n","categories":"","description":"","excerpt":"Peu importe votre système d’exploitation, docker requiert linux pour …","ref":"/fr/docs/guides/contribute/install-docker/","tags":"","title":"Installer docker"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/blog/news/","tags":"","title":"News"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/blog/news/","tags":"","title":"News"},{"body":"Once we know what paths we can use, we need to know when they can actually be used.\nThe documentation of the conflict detection module explains how it’s done internally. Generally speaking, a train is in conflict when it has to slow down because of a signal. In our case, that means the solution would not be valid, we need to arrive later (or earlier) to see the signal when it’s not restrictive anymore.\nThe complex part is that we need to do the conflict detection incrementally Which means that:\nWhen running simulations up to t=x, we need to know all of the conflicts that happen before x, even if they’re indirectly caused by a signal seen at t \u003e x down the path. We need to know the conflicts and resource uses right as they start even if their end time can’t be defined yet. For that to be possible, we need to know where the train will go after the section that is being simulated (see infra exploration: we need some elements in the lookahead section).\nTo handle it, the conflict detection module returns an error when more lookahead is required. When it happens we extend it by cloning the infra explorer objets.\n","categories":"","description":"","excerpt":"Once we know what paths we can use, we need to know when they can …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/","tags":"","title":"Conflict detection"},{"body":"Maintenant qu’on sait quels chemins peuvent être utilisés, on doit déterminer à quel moment ces chemins sont libres.\nLa documentation (en anglais seulement) de la détection de conflits explique comment elle est réalisée en interne. Pour résumer, un train est en conflit avec un autre quand il observe un signal lui indiquant de ralentir. Dans notre cas, une solution où cette situation se produit est considérée comme invalide, le train doit arriver au signal donné plus tard (ou plus tôt) quand le signal n’est plus contraignant.\nCependant, la détection de conflit doit être réalisée de manière incrémentale, ce qui veut dire que :\nQuand une simulation est effectuée jusqu’à t=x, tous les conflits qui arrivent avant t=x doivent être connus, même s’ils sont indirectement provoqués par un signal vu à t \u003e x plus loin sur le chemin. Les conflits et utilisations de ressources doivent être identifiés dès qu’ils se produisent, même si le temps de fin d’utilisation n’est pas encore défini. Pour que ce soit possible, on doit être en mesure de savoir où le train ira après la section actuellement simulée (cf exploration de l’infrastructure )\nPour gérer ce cas, le module de détection de conflit peut renvoyer une erreur quand il est nécessaire d’avoir plus d’information sur la suite du chemin. Quand ce cas se produit, les objets InfraExplorer sont clonés pour étendre les chemins.\n","categories":"","description":"","excerpt":"Maintenant qu’on sait quels chemins peuvent être utilisés, on doit …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_detection/","tags":"","title":"Détection de conflits"},{"body":"General principle The problem is still a pathfinding problem in a given graph. Once the problem is encoded as a graph search, it is possible to reuse our existing tools for this purpose.\nWe consider the product graph of position, time, and speed. This means that every graph element contains these 3 variables (among other things)\nEvery graph edge is computed using running-time calculation to get speed and positions as functions of time.\nGraphical representation Space is encoded with a graph that contains the physical infrastructure.\nIt is then “duplicated” at different times.\nThe nodes are then linked together in a way that reflects travel time.\nNotes The graph is constructed on the fly as it is explored. It is discretized in time, to evaluate which nodes have already been visited. We keep full accuracy of time values, but two nodes at the same place and close times are considered identical. Every edge is computed with a running time computation. Speed isn’t discretized or considered to check visited nodes, it’s only used to compute time. By default, the train always goes as fast as it can (while still following standard allowances). It only slows down when necessary. Example For example, with the following infrastructure, using the track graph: Exploring the solution graph can give the following result: ","categories":"","description":"","excerpt":"General principle The problem is still a pathfinding problem in a …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/","tags":"","title":"Encoding the solution space"},{"body":" Introduction La modélisation physique ayant montré que l’accélération du train était influencée par différents facteurs variant le long du trajet (pente, courbure, force de traction du moteur…), le calcul doit passer par une méthode d’intégration numérique. Le trajet est alors séparé en étapes suffisamment courtes pour considérer tous ces facteurs comme constants, ce qui permet cette fois ci d’utiliser l’équation du mouvement pour calculer le déplacement et la vitesse du train.\nLa méthode d’intégration numérique d’Euler est la plus simple pour effectuer ce genre de calcul, mais elle présente un certain nombre d’inconvénients. Cet article explique la méthode d’Euler, pourquoi elle ne convient pas aux besoins d’OSRD et quelle méthode d’intégration doit être utilisée à la place.\nLa méthode d’Euler La méthode d’Euler appliquée à l’intégration de l’équation du mouvement d’un train est :\n$$v(t+dt) = a(v(t), x(t))dt + v(t)$$\n$$x(t+dt) = \\frac{1}{2}a(v(t), x(t))dt^2 + v(t)dt + x(t)$$\n \nLes avantages de la méthode d’Euler La méthode d’Euler a pour avantages d’être très simple à implémenter et d’avoir un calcul plutôt rapide pour un pas de temps donné, en comparaison avec d’autres méthodes d’intégration numérique (voir annexe)\nLes inconvénients de la méthode d’Euler La méthode d’intégration d’Euler présente un certain nombre de problèmes pour OSRD :\nElle est relativement imprécise, et donc nécessite un faible pas de temps, ce qui génère beaucoup de données. En intégrant dans le temps, on ne connaît que les conditions du point de départ du pas d’intégration (pente, paramètres d’infrastructure, etc.) car on ne peut pas prédire précisément l’endroit où il se termine. On ne peut pas anticiper les futurs changements de directive : le train ne réagit qu’en comparant son état actuel à sa consigne au même instant. Pour illustrer c’est un peu comme si le conducteur était incapable de voir devant lui, alors que dans la réalité il anticipe en fonction des signaux, pentes, virages qu’il voit devant lui. La méthode Runge-Kutta 4 La méthode Runge-Kutta 4 appliquée à l’intégration de l’équation du mouvement d’un train est :\n$$v(t+dt) = v(t) + \\frac{1}{6}(k_1 + 2k_2 + 2k_3 + k_4)dt$$\nAvec :\n$$k_1 = a(v(t), x(t))$$\n$$k_2 = a\\Big(v(t+k_1\\frac{dt}{2}), x(t) + v(t)\\frac{dt}{2} + k_1\\frac{dt^2}{8}\\Big)$$\n$$k_3 = a\\Big(v(t+k_2\\frac{dt}{2}), x(t) + v(t)\\frac{dt}{2} + k_2\\frac{dt^2}{8}\\Big)$$\n$$k_4 = a\\Big(v(t+k_3dt), x(t) + v(t)dt + k_3\\frac{dt^2}{2}\\Big)$$\n \nLes avantages de la méthode de Runge Kutta 4 La méthode d’intégration de Runge Kutta 4 permet de répondre aux différents problèmes soulevés par celle d’Euler :\nElle permet d’anticiper les changements de directive au sein d’un pas de calcul, représentant ainsi davantage la réalité de conduite d’un train. Elle est plus précise pour le même temps de calcul (voir annexe), permettant des étapes d’intégration plus grandes, donc moins de points de données. Les inconvénients de la méthode de Runge Kutta 4 Le seul inconvénient notable de la méthode de Runge Kutta 4 rencontré pour l’instant est sa difficulté d’implémentation.\nLe choix de la méthode d’intégration pour OSRD Étude de la précision et de la vitesse de calcul Différentes méthodes d’intégration auraient pu remplacer l’intégration d’Euler de base dans l’algorithme d’OSRD. Afin de décider quelle méthode conviendrait le mieux, une étude sur la précision et la vitesse de calcul de différentes méthodes a été menée. Cette étude sert à comparé les méthodes suivantes :\nEuler Euler-Cauchy Runge-Kutta 4 Adams 2 Adams 3 Toutes les explications sur ces méthodes peuvent être trouvées dans ce document, et le code python utilisé pour la simulation est ici.\nLa simulation calcule la position et la vitesse d’un TGV accélérant sur une ligne droite plate.\nSimulations à pas de temps équivalent Une courbe de référence a été simulée en utilisant la méthode d’Euler avec un pas de temps de 0,1s, puis le même parcours a été simulé en utilisant les autres méthodes avec un pas de temps de 1s. Il est alors possible de comparer simplement chaque courbe à la courbe de référence, en calculant la valeur absolue de la différence à chaque point calculé. Voici l’erreur absolue résultante de la position du train sur sa distance parcourue :\nIl apparaît immédiatement que la méthode d’Euler est moins précise que les quatre autres d’environ un ordre de grandeur. Chaque courbe présente un pic où la précision est extrêmement élevée (erreur extrêmement faible), ce qui s’explique par le fait que toutes les courbes commencent légèrement au-dessus de la courbe de référence, la croisent en un point et finissent légèrement en dessous, ou vice versa.\nComme la précision n’est pas le seul indicateur important, le temps de calcul de chaque méthode a été mesuré. Voici ce que nous obtenons pour les mêmes paramètres d’entrée :\nMéthode d’intégration Temps de calcul (s) Euler 1.86 Euler-Cauchy 3.80 Runge-Kutta 4 7.01 Adams 2 3.43 Adams 3 5.27 Ainsi, Euler-Cauchy et Adams 2 sont environ deux fois plus lents que Euler, Adams 3 est environ trois fois plus lent, et RK4 est environ quatre fois plus lent. Ces résultats ont été vérifiés sur des simulations beaucoup plus longues, et les différents ratios sont maintenus.\nSimulation à temps de calcul équivalent Comme les temps de calcul de toutes les méthodes dépendent linéairement du pas de temps, il est relativement simple de comparer la précision pour un temps de calcul à peu près identique. En multipliant le pas de temps d’Euler-Cauchy et d’Adams 2 par 2, le pas de temps d’Adams 3 par 3, et le pas de temps de RK4 par 4, voici les courbes d’erreur absolue résultantes :\nEt voici les temps de calcul :\nMéthode d’intégration Temps de calcul (s) Euler 1.75 Euler-Cauchy 2.10 Runge-Kutta 4 1.95 Adams 2 1.91 Adams 3 1.99 Après un certain temps, RK4 tend à être la méthode la plus précise, légèrement plus précise que Euler-Cauchy, et toujours bien plus précise que la méthode d’Euler.\nConclusions de l’étude L’étude de la précision et de la vitesse de calcul présentée ci-dessus montre que RK4 et Euler-Cauchy seraient de bons candidats pour remplacer l’algorithme d’Euler dans OSRD : les deux sont rapides, précis, et pourraient remplacer la méthode d’Euler sans nécessiter de gros changements d’implémentation car ils ne font que des calculs au sein du pas de temps en cours de calcul. Il a été décidé qu’OSRD utiliserait la méthode Runge-Kutta 4 parce qu’elle est légèrement plus précise que Euler-Cauchy et que c’est une méthode bien connue pour ce type de calcul, donc très adaptée à un simulateur open-source.\n","categories":"","description":"","excerpt":" Introduction La modélisation physique ayant montré que l’accélération …","ref":"/fr/docs/explanation/running_time_calculation/numerical_integration/","tags":"","title":"Intégration numérique"},{"body":" Introduction Since physical modelling has shown that the acceleration of the train is influenced by various factors that vary along the route (gradient, curvature, engine traction force, etc.), the calculation must be carried out using a numerical integration method. The path is then separated into sufficiently short steps to consider all these factors as constant, which allows this time to use the equation of motion to calculate the displacement and speed of the train.\nEuler’s method of numerical integration is the simplest way of doing this, but it has a number of drawbacks. This article explains the Euler method, why it is not suitable for OSRD purposes and which integration method should be used instead.\nEuler’s method The Euler method applied to the integration of the equation of motion of a train is:\n$$v(t+dt) = a(v(t), x(t))dt + v(t)$$\n$$x(t+dt) = \\frac{1}{2}a(v(t), x(t))dt^2 + v(t)dt + x(t)$$\n \nAdvantages of Euler’s method The advantages of the Euler method are that it is very simple to implement and has a rather fast calculation for a given time step, compared to other numerical integration methods (see appendix)\nDisadvantages of the Euler’s method The Euler integration method presents a number of problems for OSRD:\nIt is relatively imprecise, and therefore requires a small time step, which generates a lot of data. With time integration, only the conditions at the starting point of the integration step (gradient, infrastructure parameters, etc.) are known, as one cannot predict precisely where it will end. We cannot anticipate future changes in the directive: the train only reacts by comparing its current state with its set point at the same time. To illustrate, it is as if the driver is unable to see ahead, whereas in reality he anticipates according to the signals, slopes and bends he sees ahead. Runge-Kutta’s 4 method The Runge-Kutta 4 method applied to the integration of the equation of motion of a train is:\n$$v(t+dt) = v(t) + \\frac{1}{6}(k_1 + 2k_2 + 2k_3 + k_4)dt$$\nWith:\n$$k_1 = a(v(t), x(t))$$\n$$k_2 = a\\Big(v(t+k_1\\frac{dt}{2}), x(t) + v(t)\\frac{dt}{2} + k_1\\frac{dt^2}{8}\\Big)$$\n$$k_3 = a\\Big(v(t+k_2\\frac{dt}{2}), x(t) + v(t)\\frac{dt}{2} + k_2\\frac{dt^2}{8}\\Big)$$\n$$k_4 = a\\Big(v(t+k_3dt), x(t) + v(t)dt + k_3\\frac{dt^2}{2}\\Big)$$\n \nAdvantages of Runge Kutta’s 4 method Runge Kutta’s method of integration 4 addresses the various problems raised by Euler’s method:\nIt allows the anticipation of directive changes within a calculation step, thus representing more accurately the reality of driving a train. It is more accurate for the same calculation time (see appendix), allowing for larger integration steps and therefore fewer data points. Disadvantages of Runge Kutta’s 4 method The only notable drawback of the Runge Kutta 4 method encountered so far is its difficulty of implementation.\nThe choice of integration method for OSRD Study of accuracy and speed of calculation Different integration methods could have replaced the basic Euler integration in the OSRD algorithm. In order to decide which method would be most suitable, a study of the accuracy and computational speed of different methods was carried out. This study compared the following methods:\nEuler Euler-Cauchy Runge-Kutta 4 Adams 2 Adams 3 All explanations of these methods can be found (in French) in this document, and the python code used for the simulation is here.\nThe simulation calculates the position and speed of a high-speed train accelerating on a flat straight line.\nEquivalent time step simulations A reference curve was simulated using the Euler method with a time step of 0.1s, then the same path was simulated using the other methods with a time step of 1s. It is then possible to simply compare each curve to the reference curve, by calculating the absolute value of the difference at each calculated point. The resulting absolute error of the train’s position over its distance travelled is as follows:\nIt is immediately apparent that the Euler method is less accurate than the other four by about an order of magnitude. Each curve has a peak where the accuracy is extremely high (extremely low error), which is explained by the fact that all curves start slightly above the reference curve, cross it at one point and end slightly below it, or vice versa.\nAs accuracy is not the only important indicator, the calculation time of each method was measured. This is what we get for the same input parameters:\nIntegration method Calculation time (s) Euler 1.86 Euler-Cauchy 3.80 Runge-Kutta 4 7.01 Adams 2 3.43 Adams 3 5.27 Thus, Euler-Cauchy and Adams 2 are about twice as slow as Euler, Adams 3 is about three times as slow, and RK4 is about four times as slow. These results have been verified on much longer simulations, and the different ratios are maintained.\nSimulation with equivalent calculation time As the computation times of all methods depend linearly on the time step, it is relatively simple to compare the accuracy for approximately the same computation time. Multiplying the time step of Euler-Cauchy and Adams 2 by 2, the time step of Adams 3 by 3, and the time step of RK4 by 4, here are the resulting absolute error curves:\nAnd here are the calculation times:\nIntegration method Calculation time (s) Euler 1.75 Euler-Cauchy 2.10 Runge-Kutta 4 1.95 Adams 2 1.91 Adams 3 1.99 After some time, RK4 tends to be the most accurate method, slightly more accurate than Euler-Cauchy, and still much more accurate than the Euler method.\nConclusions of the study The study of accuracy and computational speed presented above shows that RK4 and Euler-Cauchy would be good candidates to replace the Euler algorithm in OSRD: both are fast, accurate, and could replace the Euler method without requiring large implementation changes because they only compute within the current time step. It was decided that OSRD would use the Runge-Kutta 4 method because it is slightly more accurate than Euler-Cauchy and it is a well-known method for this type of calculation, so it is very suitable for an open-source simulator.\n","categories":"","description":"","excerpt":" Introduction Since physical modelling has shown that the acceleration …","ref":"/en/docs/explanation/running_time_calculation/numerical_integration/","tags":"","title":"Numerical integration"},{"body":"Principe général Le problème reste une recherche de graphe. En représentant l’espace de solution sous forme de graphe, il est possible de réutiliser nos outils déjà existants de recherche de chemin.\nLe graphe produit de la position, du temps, et de la vitesse est utilisé. Autrement dit, chaque élément du graphe contient (entre autres) ces 3 variables.\nChaque arête du graphe est calculée avec un calcul de marche pour connaître l’évolution de la vitesse et de la position dans le temps.\nReprésentation visuelle Le graphe de départ représente l’infrastructure physique\nIl est ensuite “dupliqué” à des temps différents\nPuis des nœuds sont reliés de manière à refléter le temps de parcours\nPrécisions Le graphe est construit au fil de l’exploration. Une discrétisation est faite au niveau du temps, uniquement pour évaluer ce qui a déjà été visité. Si le même emplacement est visité une seconde fois, il faut une certaine différence de temps pour estimer qu’il n’est pas déjà visité. Toutes les arêtes sont réalisées avec des calculs de marche La vitesse n’est pas discrétisée ni utilisée pour estimer quel emplacement est déjà visité, mais elle fait partie des calculs. Par défaut, tous les calculs sont faits en allant à la vitesse maximale. Les ralentissements sont ajoutés seulement quand ils sont nécessaires. Exemple Par exemple, avec l’infrastructure suivante en se basant sur le graphe des voies : Explorer le graphe des sillons possibles peut donner ce type de résultat : ","categories":"","description":"","excerpt":"Principe général Le problème reste une recherche de graphe. En …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/graph_representation/","tags":"","title":"Représentation de l'espace de solutions"},{"body":"Blocks The blocks have several attributes:\nA signaling system that corresponds to that displayed by its first signal. A path, which is a list of direction + detector pairs (just like route paths). An entry signal, (optional when the block starts from a buffer stop). Intermediate signals, if any (only used by systems with distant signals). An exit signal, (optional when the block ends at a buffer stop). The path is expressed from detector to detector so that it can be overlayed with the route graph.\nA few remarks:\nThere can be multiple blocks with the same path, as long as they have different signaling systems. Trains only use a block at a time, and ignore others. Blocks do not have a state: one can rely on the dynamic state of the zones that make it up. Blocks are used to figure out which signals protect which zones in a given context. Dependencies route graph. For each route: waypoints: List\u003cDiDetector\u003e signals: OrderedMap\u003cPosition, UnloadedSignal\u003e speed_limits: RangeMap\u003cPosition, SpeedLimit\u003e, including the logic for train category limits signaling systems drivers Signals Physical signal are made up of one or more logical signals, which are displayed as a single unit on the field. During simulation, logical signals are treated as separate signals.\nEach logical signal is associated with a signaling system, which defines if the signal transmits Movement Authority, speed limits, or both.\nLogical signals have one or more drivers. Signal drivers are responsible for computing signal state. Any given signal driver only works for a given pair of signaling systems, where the first one is displayed by the signal, and the second is the one displayed by the next signal.\nWhen a logical signal has an empty driver list, its content is deduced from neighboring signals.\nFor example, a BAL signal that is both a departure of the TVM block and a departure of the BAL block, it will have two drivers: BAL-BAL and BAL-TVM.\nAnnouncing speed limits When a signal announces a speed limit, it needs to be linked with a speed section object. This is meant to enable smooth transitions between the reaction to the announce signal, and the limit itself.\nIf multiple signals are involved in the announce process, only the one closest to the speed limit has to have this attribute set.\n{ # ... \"announce_speed_section\": \"${SPEED_SECTION_ID}\" # ... } Conditional parameters Some signal parameters vary depending on which route is set. On each signal, an arbitrary number of rules can be added. If the signal is last to announce a speed limit, it must be explicitly mentionned in the rule.\n{ # ... \"announce_speed_section\": \"${SPEED_SECTION_ID}\", \"default_parameters\": {\"short_block\": \"false\"}, \"conditional_parameters\": [ { \"on_route\": \"${ROUTE_ID}\", \"announce_speed_section\": \"${SPEED_SECTION_ID}\", \"parameters\": {\"rappel30\": \"true\", \"short_block\": \"true\"} } ] # ... } Signal parameter values are looked up in the following order:\nper route conditional parameters per signal default parameters (default_parameters) parameter default value, from the signaling system’s .signal_parameters[].default Serialized format The serialized / raw format is the user-editable description of a physical signal.\nRaw signals have a list of logical signals, which are independently simulated units sharing a common physical display. Each logical signal has:\na signaling system user-editable properties, as specified in the signaling system description a list of default parameters, which can get overriden per-route an optional announced speed section, which can get overriden per-route a list of allowed next signaling systems, which are used to load drivers For example, this signal encodes a BAL signal which:\nstarts both a BAL and a TVM block announces speed limit B on all routes except route A, where speed limit C is announced on route A, the block is shorter than usual { # signals must have location data. # this data is omitted as its format is irrelevant to how signals behave \"logical_signals\": [ { # the signaling system shown by the signal \"signaling_system\": \"BAL\", # the settings for this signal, as defined in the signaling system manifest \"properties\": {\"has_ralen30\": \"true\", \"Nf\": \"true\"}, # this signal can react to BAL or TVM signals # if the list is empty, the signal is assumed to be compatible with all following signaling systems \"next_signaling_systems\": [\"BAL\", \"TVM\"] \"announce_speed_section\": \"${SPEED_SECTION_B}\", \"default_parameters\": {\"rappel30\": \"true\", \"short_block\": \"false\"}, \"conditional_parameters\": [ { \"on_route\": \"${ROUTE_A}\", \"announce_speed_section\": \"${SPEED_SECTION_C}\", \"parameters\": {\"short_block\": \"true\"} } ] } ] } For example, this signal encodes a BAL signal which starts a BAL block, and shares its physical display / support with a BAPR signal starting a BAPR block:\n{ # signals must have location data. # this data is omitted as its format is irrelevant to how signals behave \"logical_signals\": [ { \"signaling_system\": \"BAL\", \"properties\": {\"has_ralen30\": \"true\", \"Nf\": \"true\"}, \"next_signaling_systems\": [\"BAL\"] }, { \"signaling_system\": \"BAPR\", \"properties\": {\"Nf\": \"true\", \"distant\": \"false\"}, \"next_signaling_systems\": [\"BAPR\"] } ] } Signal description strings Signal definitions need to be condensed into a shorter form, just to look up signal icons. In order to store this into MVT map tiles hassle free, it’s condensed down into a single string.\nIt looks something like that: BAL[Nf=true,ralen30=true]+BAPR[Nf=true,distant=false] It’s built as follows:\na list of logical signals, sorted by signaling system name, separated by + inside each logical signal, signal properties are sorted by name, enclosed in square brackets and separated by , Dependencies For signal state evaluation:\ntrain path in blocks portion of the path to evaluate drivers state of the zones in the section to evaluate ","categories":"","description":"","excerpt":"Blocks The blocks have several attributes:\nA signaling system that …","ref":"/en/docs/reference/design-docs/signaling/blocks-and-signals/","tags":"","title":"Blocks and signals"},{"body":" Introduction Cette page donne un exemple de la manière dont les formats de données sont utilisés pour décrire une infrastructure dans OSRD.\nÀ cette fin, prenons comme exemple l’infrastructure-jouet suivante :\nConseil Pour zoomer sur un diagramme, cliquez sur le bouton d’édition qui apparaît au survol de celui-ci. Ce diagramme est un aperçu de l’infrastructure avec les lignes et les stations uniquement.\nCette infrastructure ne se veut pas réaliste, mais plutôt destinée à illustrer le modèle de données d’OSRD. Cet exemple sera créé étape par étape et expliqué en cours de route.\nLe générateur d’infrastructures Dans le dépôt OSRD se trouve une bibliothèque python conçue pour aider à générer des infrastructures dans un format compris par OSRD.\nL’infrastructure discutée dans cette section peut être générée grâce au fichier small_infra.py. Pour en savoir plus sur les scripts de génération, vous pouvez consulter le README correspondant.\nVoies Sections de voie (Track Sections) Les premiers objets que nous devons définir sont les TrackSections. La plupart des autres objets sont positionnés par rapport à celles-ci.\nUne section de voie est une section de rail (sans aiguillages). On peut choisir de diviser les voies de son infrastructure en autant de sections qu’on le souhaite. Ici, nous avons choisi d’utiliser les sections de voie les plus longues possibles, ce qui signifie qu’entre deux aiguillages, il y a toujours une seule section de voie.\nLes sections de voie sont ce sur quoi les trains simulés roulent. Ils sont l’équivalent abstrait des sections de rails physiques. Les sections de voie sont bidirectionnelles.\nDans cet exemple, nous définissons deux voies pour la ligne entre les stations Ouest et Nord-Est. Nous avons également des voies de contournement aux stations Nord et Centre-Ouest pour plus de réalisme. Enfin, nous avons trois voies distinctes dans la station Ouest, puisqu’il s’agit d’une plaque tournante majeure dans notre infrastructure imaginaire.\nImportant Les TrackSections sont représentées par des flèches dans ce diagramme pour souligner le fait qu’elles ont un début et une fin. C’est important car les objets positionnés sur les sections de voie sont localisés en fonction de leur distance par rapport au début de leur section de voie.\nPar conséquent, pour placer un objet au début de sa section de voie, définissez sa position à 0. Pour le déplacer à la fin de sa section de voie, définissez sa position à la length de la section de voie.\nCes attributs sont nécessaires pour que la section de voie soit complète :\nlength : la longueur de la section de voie en mètres. geo : les coordonnées dans la réalité (geo pour géographique), au format GeoJSON. attributs cosmétiques : line_name, track_name, track_number qui sont utilisés pour indiquer le nom et les étiquettes qui ont été donnés aux voies / lignes dans la réalité. Pour toutes les sections de voies de notre infrastructure, les attributs geo se rapprochent beaucoup au schéma donné.\nPour la plupart des sections de voies, leur length est proportionnelle à ce que l’on peut voir sur le diagramme. Pour préserver la lisibilité, des exceptions ont été faites pour TA6, TA7, TD0 et TD1 (qui font 10km et 25km).\nNoeud Un Node représente un noeud dans l’infrastructure. Dans une simulation OSRD, un train ne peut passer d’une section de voie à une autre que si elles sont reliées par un noeud. Un noeud peut se présenter de deux manières différentes :\n1) Aiguillages\nLes aiguillages peuvent être vus comme une collection de liens de sections de voies, partitionnés en groupes. Chaque groupe représente un état de l’aiguillage. Passer d’un groupe à un autre peut prendre du temps, et au maximum un lien peut être prêt à être utilisé à la fois.\nDans le monde réel, les aiguillages ne sont pas uniques, mais plutôt des instances de modèles existants.\n2) Liens de sections de voies\nPour le moment, nous n’avons créé que des sections de voies, qui ne sont pas interconnectées (les données géospatiales ne sont pas utilisées pour déduire quelles voies sont connectées).\nLes link sont utilisés pour connecter deux sections de voie ensemble, tout comme un joint de soudure le ferait dans la vie réelle. Dans une simulation OSRD, un train ne peut passer d’une section de voie à une autre que si elles sont reliées par ce type de noeud, le link (ou par un autre NodeType).\nQue ce soit pour les aiguillages ou les liens de sections de voies, les liens et les groupes ne font pas partie du switch lui-même, mais d’un objet NodeType, qui est partagé par les aiguillages du même modèle.\nTypes de Noeud Les NodeTypes ont deux attributs obligatoires :\nports : Une liste de noms de ports. Un port est une extrémité du noeud qui peut être connecté à une section de voie. groups : Un table de correspondance entre le nom des groupes et les listes de branches (connexion entre 2 ports) qui caractérisent les différentes positions possibles du type de Noeud À tout moment, tous les noeuds ont un groupe actif, et peuvent avoir une branche active, qui appartient toujours au groupe actif. Pendant une simulation, le changement de branche active à l’intérieur d’un groupe est instantané, mais le changement de branche active entre les groupes prend un temps configurable. Ceci est dû au fait qu’un Noeud peut-être un objet physique (dans le cas des aiguillages), et que le changement de branche active peut impliquer le déplacement de certaines de ses parties. Les groups sont conçus pour représenter les différentes positions qu’un Noeud peut avoir. Chaque groupe contient les liens qui peuvent être utilisés dans la position du Noeud associé.\nDans le cas des aiguilles, la durée nécessaire pour changer de groupe est stockée à l’intérieur du Noeud, car elle peut varier en fonction de l’implémentation physique du modèle d’aiguillage.\nNos exemples utilisent actuellement cinq NodeTypes. Il est possible d’ajouter un type de noeud si nécessaire via le champ extended_node_type.\n1) Le lien entre deux sectionx de voies\nCelui-ci représente le lien entre deux sections de voies. Il possède deux ports : A et B.\nIl permet de créer un lien entre deux sections de voies tel que définis dans OSRD. Ce n’est pas un objet physique.\n2) L’aiguille\nL’omniprésent aiguillage en Y, qui peut être considéré comme la fusion de deux voies ou la séparation d’une voie.\nCe type d’aiguillage possède trois ports : A, B1 et B2.\nIl y a deux groupes, chacun avec une connexion dans leur liste : A_B1, qui connecte A à B1, et A_B2 qui connecte A à B2.\nAinsi, à tout moment (sauf lorsque l’aiguille bouge pour changer de groupe), un train peut aller de A à B1 ou de A à B2 mais jamais aux deux en même temps. Un train ne peut pas aller de B1 à B2.\nUne aiguille n’a que deux positions :\nA vers B1 A vers B2 3) L’aiguillage de croisement\nIl s’agit simplement de deux voies qui se croisent.\nCe type a quatre ports : A1, B1, A2 et B2.\nIl ne comporte qu’un seul groupe contenant deux connexions : A1 vers B1 et A2 vers B2. En effet, ce type d’aiguillage est passif : il n’a pas de pièces mobiles. Bien qu’il n’ait qu’un seul groupe, il est tout de même utilisé par la simulation pour faire respecter les réservations de route.\nVoici les deux connexions différentes que ce type d’aiguillage possède :\nA1 vers B1 A2 vers B2 4) L’aiguillage de croisement double\nCelui-ci ressemble plus à deux aiguilles dos à dos. Il possède quatre ports : A1, A2, B1 et B2.\nCependant, il comporte quatre groupes, chacun avec une connexion. Les quatre connexions possibles sont les suivantes :\nA1 vers B1 A1 vers B2 A2 vers B1 A2 vers B2 5) L’aiguillage de croisement simple\nCelui-ci ressemble plus à un mélange entre une aiguille simple et un croisement. Il possède quatre ports : A1, A2, B1 et B2.\nVoici les trois connexions que peut réaliser cet aiguillage :\nA1 vers B1 A1 vers B2 A2 vers B2 Retour aux noeuds Un Node possède trois attributs :\nnode_type : l’identifiant NodeType de ce noeud. ports : une correspondance entre les noms de port et les extrémités des sections de voie. group_change_delay : le temps qu’il faut pour changer le groupe de l’aiguillage qui est actif. Les noms des ports doivent correspondre aux ports du type du noeud choisi. Les extrémités de la section de voie peuvent être début ou fin, faites attention à choisir les bonnes.\nLa plupart des noeuds de notre exemple sont des noeuds habituels. Le chemin de la gare du Nord à la gare du Sud a deux aiguillages de croisement. Enfin, il y a un aiguillage de croisement double juste avant que la ligne principale ne se divise en lignes Nord-Est et Sud-Est.\nIl est important de noter que ces noeuds sont présents par défaut dans le code du projet. Seuls les extended_switch_type ajoutés par l’utilisateur apparaîtront dans le railjson.\nCourbes et pentes Les Courbes et les Pentes sont essentielles pour des simulations réalistes. Ces objets sont définis comme une plage entre une position de début (begin) et de fin (end) sur une section de voie. Si une courbe / pente s’étend sur plus d’une section de voie, elle doit être ajoutée à toutes les sections.\nLes valeurs des courbes / pentes sont constantes sur toute leur étendue. Pour des courbes / pentes variables, il faut créer plusieurs objets.\nLes valeurs de pente sont mesurées en mètres par kilomètres, et les valeurs de courbe sont mesurées en mètres (le rayon de la courbe).\nN’oubliez pas que la valeur begin doit toujours être inférieure à la valeur end. C’est pourquoi les valeurs de courbe/pente peuvent être négatives : une pente ascendante de 1 allant du décalage 10 à 0 est identique à une pente descendante de -1 allant des décalages 0 à 10. Dans le fichier small_infra.py, nous avons des pentes sur les sections de voie TA6, TA7, TD0 et TD1.\nIl y a également des courbes sur les sections de voie TE0, TE1, TE3 et TF1.\nEnclenchement Jusqu’à présent, tous les objets ont contribué à la topologie (forme) des voies. La topologie serait suffisante pour que les trains puissent naviguer sur le réseau, mais pas assez pour le faire en toute sécurité. pour assurer la sécurité, deux systèmes collaborent :\nL’enclenchement garantit que les trains sont autorisés à avancer La signalisation est le moyen par lequel l’enclenchement communique avec le train Détecteurs Ces objets sont utilisés pour créer des sections TVD (Track Vacancy Detection) : la zone de la voie située entre deux détecteurs est une section TVD. Lorsqu’un train rencontre un détecteur, la section dans laquelle il entre est occupée. La seule fonction des sections TVD est de localiser les trains.\nDans la réalité, les détecteurs peuvent être des compteurs d’essieux ou des circuits de voie par exemple.\nPour que cette méthode de localisation soit efficace, les détecteurs doivent être placés régulièrement le long de vos voies, pas trop nombreux pour des raisons de coût, mais pas trop peu, car les sections TVD seraient alors très grandes et les trains devraient être très éloignés les uns des autres pour être distingués, ce qui réduirait la capacité.\nIl y a souvent des détecteurs à proximité de tous les extrémités des aiguillages. De cette façon, l’enclenchement est averti presque immédiatement lorsqu’un aiguillage est libéré, qui est alors libre d’être utilisé à nouveau.\nPrenons l’exemple d’un aiguillage de croisement : si le train A le franchit du nord au sud et que le train B arrive pour le franchir de l’ouest à l’est, dès que le dernier wagon du train A a franchi l’aiguillage, B devrait pouvoir partir, puisque A se trouve maintenant sur une section de voie complètement indépendante. Dans OSRD, les détecteurs sont des objets ponctuels. Les attributs dont ils ont besoin sont leur id et leur localisation sur la voie (track et offset).\nLes carrés agglutinés représentent plusieurs détecteurs à la fois. En effet, certains tronçons de voie n’étant pas représentés sur toute leur longueur, nous n’avons pas pu représenter tous les détecteurs du tronçon de voie correspondant. Quelques notes :\nEntre certains points, nous n’avons ajouté qu’un seul détecteur (et non pas deux), car ils étaient très proches les uns des autres, et cela n’aurait eu aucun sens de créer une minuscule section TVD entre eux. Cette situation s’est produite sur des sections de voies (TA3, TA4, TA5, TF0 et TG3). Dans notre infrastructure, il y a relativement peu de sections de voie qui sont assez longues pour nécessiter plus de détecteurs que ceux liés aux aiguillages. Ce sont, TA6, TA7, TDO, TD1, TF1, TG1 et TH1. Par exemple, TD0, qui mesure 25 km, compte en fait 17 détecteurs au total. Butoirs (BufferStops) Les BufferStops sont des obstacles destinés à empêcher les trains de dérailler en bout des voies.\nDans notre infrastructure, il y a un butoir sur chaque section de voie qui est un cul-de-sac. Il y a donc 8 butoirs au total.\nAvec les détecteurs, ils définissent les limites des sections TVD (voir Détecteurs).\nItinéraires (Routes) Une Route est un itinéraire dans l’infrastructure. Un sillon est une séquence de routes. Les itinéraires sont utilisés pour réserver des sections de sillon avec l’enclenchement. Voir la documentation dédiée.\nIl est représenté avec les attributs suivants :\nentry_point et exit_point : Références de détecteurs ou de butées qui marquent le début et la fin de l’itinéraire. entry_point_direction : Direction à prendre sur la section de voie depuis entry_point pour commencer l’itinéraire. switches_direction : Un ensemble de directions à suivre lorsqu’on rencontre un aiguillage sur notre itinéraire, de manière à reconstituer cet itinéraire de entry_point jusqu’à exit_point. release_detectors : Lorsqu’un train franchit un détecteur de libération, les ressources réservées depuis le début de la route jusqu’à ce détecteur sont libérées. Signalisation Grâce à l’enclenchement, les trains sont localisés et autorisés à se déplacer. C’est un bon début, mais c’est inutile tant que les trains n’en sont pas informés. C’est là que les “signaux” entrent en jeu : les signaux réagissent aux enclenchements et peuvent être vus par les trains.\nLa façon dont les trains réagissent aux signaux dépend de l’aspect, du type de signal et du système de signalisation.\nVoici les attributs les plus importants des signaux :\nlinked_detector : Le détecteur lié. type_code : Le type de signal. direction : La direction qu’il protège, qui peut être simplement interprétée comme la façon dont il peut être vu par un train entrant (puisqu’il n’y a des feux que d’un côté…). La direction est relative à l’orientation de la section de voie. Des attributs cosmétiques comme angle_geo and side qui contrôlent la manière dont les signaux sont affichés dans le front-end. Voici une visualisation de comment on peut représenter un signal, et quelle direction il protège.\nLa manière dont les signaux sont disposés dépend fortement du système de signalisation et du gestionnaire de l’infrastructure.\nVoici les règles de base utilisées pour cet exemple d’infrastructure :\nNous ajoutons deux signaux d’espacement (un par direction) pour chaque détecteur qui découpe une longue section de TVD en plus petites sections. Les entrées d’aiguillage où un train pourrait devoir s’arrêter sont protégées par un signal (qui est situé à l’extérieur de la section TVD de l’aiguillage). Il doit être visible depuis la direction utilisée pour approcher l’aiguillage. Lorsqu’il y a plusieurs aiguillages dans une rangée, seul le premier a généralement besoin d’être protégé, car l’enclenchement est généralement conçu pour ne pas encourager les trains à s’arrêter au milieu des intersections. Notez que les détecteurs liés à au moins un signal ne sont pas représentés, car il n’y a pas de signaux sans détecteurs associés dans cet exemple.\nPour obtenir le id d’un détecteur lié à un signal, prenez le id du signal et remplacez S par D (par exemple SA0 -\u003e DA0).\nSur TA6, TA7, TD0 et TD1 nous n’avons pas pu représenter tous les signaux car ces sections de voie sont très longues et comportent de nombreux détecteurs, donc de nombreux signaux. Électrification Pour permettre à des trains électriques de circuler sur notre infrastructure, nous devons spécifier les parties de celle-ci qui sont électrifiées.\nCaténaires (Catenaries) Les Catenaries représentent les câbles d’alimentation qui alimentent les trains électriques. Ils sont représentés avec les attributs suivants :\nvoltage : Une chaîne de caractères représentant le type d’alimentation électrique utilisée pour l’électrification. track_ranges : Une liste de portions de sections de voie (TrackRanges) couvertes par cette caténaire. Une TrackRange est composée d’un identifiant de section de voie, d’une position begin et d’une position end. Dans notre exemple, nous avons deux Catenaries:\nUne avec voltage défini sur \"1500\", qui couvre uniquement TA0. Une avec voltage défini sur \"25000\", qui couvre tous les autres sauf TD1. Cela signifie que seuls les trains thermiques peuvent traverser la section de voie TD1.\nNotre exemple montre également que, contrairement à son homologue réel, une seule Catenary peut couvrir toute l’infrastructure.\nSections Neutres (NeutralSections) Dans certaines parties d’une infrastructure, les conducteurs de train sont sommés - principalement pour des raisons de sécurité - de couper l’alimentation électrique du train.\nPour représenter de telles parties, nous utilisons des NeutralSections. Elles sont représentées avec principalement les attributs suivants :\ntrack_ranges : Une liste de DirectedTrackRanges (portions de sections de voie associées à une direction) couvertes par cette section neutre. lower_pantograph : Un booléen indiquant si le pantographe du train doit être abaissé pendant la traversée de cette section. Dans notre exemple, nous avons trois NeutralSections : une à la jonction des caténaires \"1500\" et \"25000\", une sur TA6 et une sur TG1 et TG4.\nPour plus de détails sur le modèle, voir la page dédiée.\nDivers Points opérationnels (OperationalPoints) Le point operationnel est aussi connu sous le nom de Point Remarquable (PR). Un OperationalPoint est une collection de points (OperationalPointParts) d’intérêt.\nPar exemple, il peut être pratique (repère de conduite) de stocker l’emplacement des plateformes en tant que parties et de les regrouper par station dans des points opérationnels. De la même manière, un pont au-dessus des voies sera un OperationalPoint, mais il comportera plusieurs OperationPointParts, une à l’intersection de chaque voie.\nDans l’exemple de l’infrastructure, nous n’avons utilisé que des points opérationnels pour représenter les stations. Les parties de points opérationnels sont représentées par des diamants violets. Gardez à l’esprit qu’un seul point opérationnel peut contenir plusieurs parties.\nLimites de gabarit (Loading Gauge Limits) Cet objet s’apparente aux Pentes et aux Courbes : il couvre une plage de section de voie, avec une position de début (begin) et de fin (end). Il représente une restriction sur les trains qui peuvent circuler sur la plage donnée, par poids ou par type de train (fret ou passagers).\nNous n’en avons pas mis dans nos exemples.\nSections de vitesse (SpeedSections) Les SpeedSections représentent les limites de vitesse (en mètres par seconde) qui sont appliquées sur certaines parties des voies. Une SpeedSection peut s’étendre sur plusieurs sections de voie, et ne couvre pas nécessairement la totalité des sections de voie. Les sections de vitesse peuvent se chevaucher.\nDans notre exemple d’infrastructure, nous avons une section de vitesse couvrant l’ensemble de l’infrastructure, limitant la vitesse à 300 km/h. Sur une plus petite partie de l’infrastructure, nous avons appliqué des sections de vitesse plus restrictives.\n","categories":"","description":"Explique par l'exemple comment les données d'infrastructure sont structurées","excerpt":"Explique par l'exemple comment les données d'infrastructure sont …","ref":"/fr/docs/explanation/models/data-models-full-example/","tags":"","title":"Exemple d'infrastructure"},{"body":"Explanations discuss key topics and concepts at a fairly high level and provide useful background information and explanation.\n","categories":"","description":"Learn more about key concepts","excerpt":"Learn more about key concepts","ref":"/en/docs/explanation/","tags":"","title":"Explanations"},{"body":"Les explications abordent des thèmes et concepts clés d’un point de vue général et fournissent des informations et explications détaillées sur les éléments fondamentaux.\n","categories":"","description":"Comprendre les concepts clés","excerpt":"Comprendre les concepts clés","ref":"/fr/docs/explanation/","tags":"","title":"Explications"},{"body":" Introduction This page gives an example of how the data formats are used to describe an infrastructure in OSRD.\nFor this purpose, let’s take as an example the following toy infrastructure:\nTip To zoom in on diagrams, click on the edit button that appears when hovering over it. This diagram is an overview of the infrastructure with lines and stations only.\nThis infrastructure is not meant to be realistic, but rather meant to help illustrate OSRD’s data model. This example will be created step by step and explained along the way.\nThe infrastructure generator In the OSRD repository is a python library designed to help generate infrastructures in a format understood by OSRD.\nThe infrastructure discussed in this section can be generated thanks to small_infra.py file. To learn more about the generation scripts, you can check out the related README.\nTracks Track sections The first objects we need to define are TrackSections. Most other objects are positioned relative to track sections.\nA track section is a section of rail (switches not included). One can chose to divide the tracks of their infrastructure in as many track sections as they like. Here we chose to use the longest track sections possible, which means that between two switches there is always a single track section.\nTrack sections is what simulated trains roll onto. They are the abstract equivalent to physical rail sections. Track sections are bidirectional.\nIn this example, we define two tracks for the line between the West and North-East stations. We also have overpassing tracks at the North and Mid-West stations for added realism. Finally, we have three separate tracks in the West station, since it’s a major hub in our imaginary infrastructure.\nImportant TrackSections are represented as arrows in this diagram to stress the fact that they have a start and an end. It matters as objects positioned on track sections are located using their distance from the start of their track section.\nTherefore, to locate an object at the beginning of its track section, set its offset to 0. To move it to the end of its track section, set its offset to the length of the track section.\nThese attributes are required for the track section to be complete:\nlength: the length of the track section in meters. geo: the coordinates in real life (geo is for geographic), in the GeoJSON format. cosmetic attributes: line_name, track_name, track_number which are used to indicate the name and labels that were given to the tracks / lines in real life. For all track sections in our infrastructure, the geo attributes very much resemble the given diagram.\nFor most track sections, their length is proportional to what can be seen in the diagram. To preserve readability, exceptions were made for TA6, TA7, TD0 and TD1 (which are 10km and 25km).\nNode A Node represents a node in the infrastructure. In an OSRD simulation, a train can only move from one section of track to another if they are linked by a node.\nNode Types NodeTypes have two mandatory attributes:\nports: A list of port names. A port is an endpoint connected to a track section. groups: A mapping between group names and lists of branch (connection between 2 ports) that characterises the different possible positions of the node type At any time, all nodes have an active group, and may have an active branch, which always belongs to the active group. During a simulation, changing the active branch inside a group is instantaneous, but changing the active branch across groups (changing the active group) takes configurable time. This is because a node is a physical object, and changing active branch can involve moving parts of it. Groups are designed to represent the different positions that a node can have. Each group contains the branches that can be used in the associated node position.\nThe duration needed to change group is stored inside the Node, since it can vary depending on the physical implementation of the node.\nOur examples currently use five node types. Node types are just like other objects, and can easily be added as needed using extended_switch_type.\n1) Link\nThis one represents the link between two sections of track. It has two ports: A and B.\nIt is used in the OSRD model to create a link between two track sections. This is not a physical object.\n2) The Point Switch\nThe ubiquitous Y switch, which can be thought of as either two tracks merging, or one track splitting.\nThis node type has three ports: A, B1 and B2.\nThere are two groups, each with one connection in their list: A_B1, which connects A to B1, and A_B2 which connects A to B2.\nThus, at any given moment (except when the switch moves from one group to another), a train can go from A to B1 or from A to B2 but never to both at the same time. A train cannot go from B1 to B2.\nA Point Switch only has two positions:\nA to B1 A to B2 3) The Crossing\nThis is simply two tracks crossing each other.\nThis type has four ports: A1, B1, A2 et B2.\nIt has only one group containing two connections: A1 to B1 and A2 to B2. Indeed this kind of switch is passive: it has no moving parts. Despite having a single group, it is still used by the simulation to enforce route reservations.\nHere are the two different connections this switch type has:\nA1 to B1 A2 to B2 4) The Double slip switch\nThis one is more like two point switches back to back. It has four ports: A1, A2, B1 and B2.\nHowever, it has four groups, each with one connection. The four groups are represented in the following diagram:\nA1 to B1 A1 to B2 A2 to B1 A2 to B2 5) The Single slip switch\nThis one looks more like a cross between a single needle and a crossover. It has four ports: A1, A2, B1 and B2.\nHere are the three connections that can be made by this switch:\nA1 to B1 A1 to B2 A2 to B2 Back to nodes A Node has three attributes:\nnode_type: the identifier of the NodeType of this node. ports: a mapping from port names to track sections extremities. group_change_delay: the time it takes to change which group of the node is activated. The port names must match the ports of the node type chosen. The track section endpoints can be start or end, be careful to chose the appropriate ones.\nMost of our example’s nodes are regular point switches. The path from North station to South station has two cross switches. Finally, there is a double cross switch right before the main line splits into the North-East and South-East lines.\nIt is important to note that these node types are hard-coded into the project code. Only the extended_node_type added by the user will appear in the railjson.\nCurves and slopes Curves and Slopes are instrumental to realistic simulations. These objects are defined as a range between a begin and end offsets of one track section. If a curve / slope spans more than one track section, it has to be added to all of them.\nThe slope / curve values are constant on their entire range. For varying curves / slopes, one needs to create several objects.\nSlope values are measured in meters per kilometers, and the curve values are measured in meters (the radius of the curve).\nMind that the begin value should always be smaller than the end value. That is why the curve / slope values can be negative: an uphill slope of 1 going from offset 10 to 0 is the same as a downhill slope of -1 going from offsets 0 to 10. In the small_infra.py file, we have slopes on the track sections TA6, TA7, TD0 and TD1.\nThere are curves as well, on the track sections TE0, TE1, TE3 and TF1.\nInterlocking All objects so far contributed to track topology (shape). Topology would be enough for trains to navigate the network, but not enough to do so safely. to ensure safety, two systems collaborate:\nInterlocking ensures trains are allowed to move forward Signaling is the mean by which interlocking communicates with the train Detectors These objects are used to create TVD sections (Track Vacancy Detection section): the track area in between detectors is a TVD section. When a train runs into a detector, the section it is entering becomes occupied. The only function of TVD sections is to locate trains.\nIn real life, detectors can be axle counters or track circuits for example.\nFor this mean of location to be efficient, detectors need to be placed regularly along your tracks, not too many because of cost, but not too few, because then TVD sections would be very large and trains would need to be very far apart to be told apart, which reduces capacity.\nThere often are detectors close to all sides of switches. This way, interlocking is made aware pretty much immediately when a switch is cleared, which is then free to be used again.\nLet’s take a cross switch as an example: if train A is crossing it north to south and train B is coming to cross west to east, then as soon as train A’s last car has passed the crossing, B should be able to go, since A is now on a completely unrelated track section. In OSRD, detectors are point objects, so all the attributes it needs are its id, and track location (track and offset).\nThe clumped up squares represent many detectors at once. Indeed, because some track sections are not represented with their full length, we could not represent all the detectors on the corresponding track section. Some notes:\nBetween some points, we added only one detector (and not two), because they were really close together, and it would have made no sense to create a tiny TVDS between the two. This situation happened on track sections (TA3, TA4, TA5, TF0 and TG3). In our infrastructure, there is relatively few track sections which are long enough to require more detectors than just those related to switches. Namely, TA6, TA7, TDO, TD1, TF1, TG1 and TH1. For example TD0, which measures 25km, has in fact 17 detectors in total. Buffer stops BufferStops are obstacles designed to prevent trains from sliding off dead ends.\nIn our infrastructure, there is a buffer stop on each track section which has a loose end. There are therefore 8 buffer stops in total.\nTogether with detectors, they set the boundaries of TVD sections (see Detectors)\nRoutes A Route is an itinerary in the infrastructure. A train path is a sequence of routes. Routes are used to reserve section of path with the interlocking. See the dedicated documentation.\nIt is represented with the following attributes:\nentry_point and exit_point: references detectors or buffer stops which mark the beginning and the end of the Route. entry_point_direction : Direction on a track section to start the route from the entry_point. switches_direction : A set of directions to follow when we encounter a switch on our Route, to build this Route from entry_point to exit_point. release_detectors: When a train clears a release detector, resources reserved from the beginning of the route until this detector are released. Signaling Thanks to interlocking, trains are located and allowed to move. It’s a good start, but meaningless until trains are made aware of it. This is where Signals come into play: signals react to interlocking, and can be seen by trains.\nHow trains react to signals depends on the aspect, kind of signal, and signaling system.\nHere are the most important attributes for signals:\nlinked_detector: The linked detector. type_code: The type of signal. direction: The direction it protects, which can simply be interpreted as the way in which it can be seen by an incoming train (since there are lights only on one side…). Direction is relative to track section orientation. Cosmetic attributes like angle_geo or side which control the way in which the signals are displayed in the front-end. Here is a visualization of how one can represent a signal, and which direction it protects.\nThe way the signals are arranged is highly dependent on both signaling system and infrastructure manager.\nHere are the basic rules used for this example infrastructure:\nWe add two spacing signals (one per direction) for each detector that is cutting a long TVD section into smaller ones. Switch entries where a train might have to stop are protected by a signal (which is located outside of the switch TVD section). It must be visible from the direction used to approach the switch. When there are multiple switches in a row, only the first one usually needs protection, as interlocking is usually designed as not to encourage trains stopping in the middle of intersections. Note that detectors linked to at least one signal are not represented, as there are not signals without associated detectors in this example.\nTo get the id of a detector linked to a signal, take the signal’s id and replace S by D (e.g. SA0 -\u003e DA0).\nOn TA6, TA7, TD0 and TD1 we could not represent all signals because these track sections are very long and have many detectors, hence many signals. Electrification To allow electric trains to run on our infrastructure, we need to specify which parts of the infrastructure is electrified.\nCatenaries Catenaries are objects that represent the overhead wires that power electric trains. They are represented with the following attributes:\nvoltage: A string representing the type of power supply used for electrification track_ranges: A list of range of track sections (TrackRanges) covered by this catenary. A TrackRange is composed of a track section id, a begin offset and an end offset. In our example infrastructure, we have two Catenaries:\nOne with voltage set to \"1500\", which covers only TA0. One with voltage set to \"25000\", which covers all others except TD1. This means that only thermal trains can cross the TD1 track section.\nOur example also outlines that, unlike its real life counterpart, a single Catenary may cover the whole infrastructure.\nNeutral Sections In some parts of an infrastructure, the train drivers may be instructed - mainly for safety reasons - to cut the power supply to the train.\nTo represent such parts, we use NeutralSections. They are represented mainly with the following attributes:\ntrack_ranges: A list of DirectedTrackRanges (track ranges associated to a direction) which are covered by this neutral section. lower_pantograph: A boolean indicating whether the train’s pantograph should be lowered while in this section. In our example infrastructure, we have three NeutralSections: one at the junction of the \"1500\" and \"25000\" catenaries, one on TA6 and one on TG1 and TG4.\nFor more details about the model see the dedicated page.\nMiscellaneous Operational points Operational point is also known in French as “Point Remarquable” (PR). One OperationalPoint is a collection of points (OperationalPointParts) of interest.\nFor example, it may be convenient (reference point for train operation) to store the location of platforms as parts and group them by station in operational points. In the same way, a bridge over tracks will be one OperationalPoint, but it will have several OperationPointParts, one at the intersection of each track.\nIn the example infrastructure, we only used operational points to represent stations. Operational point parts are displayed as purple diamonds. Keep in mind a single operational point may contain multiple parts.\nLoading Gauge Limits These objects are akin to Slopes and Curves: it covers a range of track section, with a begin and an end offset. It represents a restriction on the trains that can travel on the given range, by weight or by train type (freight or passenger).\nWe did not put any in our examples.\nSpeed Sections The SpeedSections represent speed limits (in meters per second) that are applied on some parts of the tracks. One SpeedSection can span on several track sections, and do not necessarily cover the whole track sections. Speed sections can overlap.\nIn our example infrastructure, we have a speed section covering the whole infrastructure, limiting the speed to 300 km/h. On a smaller part of the infrastructure, we applied more restrictive speed sections.\n","categories":"","description":"Explains using an example how infrastructure data is structured","excerpt":"Explains using an example how infrastructure data is structured","ref":"/en/docs/explanation/models/data-models-full-example/","tags":"","title":"Infrastructure example"},{"body":"Description La couche de localisation permet à d’autres modules de simulation de suivre le déplacement du train dans l’infrastructure. L’infrastructure ferroviaire est découpée en régions appelées zones. Quand on train entre dans une zone, ce module permet d’en être notifié.\nLes zones (ou TVDSection / DetectionSection) sont des partitions physiques des voies :\ncapables de détecter la présence d’un train Exigences de conception il doit être possible de suivre les changements d’occupation d’une zone il devra être possible de suivre les déplacements d’un train il devra être possible d’implémenter un système de bloc mobile Dépendances statique une liste de zones Opérations Occuper une zone Libérer une zone Observer les changements d’occupation d’une zone ","categories":"","description":"Fournit les informations de position des trains sur le réseau","excerpt":"Fournit les informations de position des trains sur le réseau","ref":"/fr/docs/reference/design-docs/interlocking/location/","tags":"","title":"Localisation"},{"body":"","categories":"","description":"Ce qui est modélisé dans OSRD, et comment c'est modélisé","excerpt":"Ce qui est modélisé dans OSRD, et comment c'est modélisé","ref":"/fr/docs/explanation/models/","tags":"","title":"Modèles"},{"body":"","categories":"","description":"What is modeled in OSRD, and how it is modeled","excerpt":"What is modeled in OSRD, and how it is modeled","ref":"/en/docs/explanation/models/","tags":"","title":"Models"},{"body":"Physical object to model Introduction For a train to be able to run, it must either have an energy source on board (fuel, battery, hydrogen, …) or be supplied with energy throughout its journey.\nTo supply this energy, electrical cables are suspended above the tracks: the catenaries. The train then makes contact with these cables thanks to a conducting piece mounted on a mechanical arm: the pantograph.\nNeutral sections With this system it is difficult to ensure the electrical supply of a train continuously over the entire length of a line. On certain sections of track, it is necessary to cut the electrical supply of the train. These portions are called neutral sections.\nIndeed, in order to avoid energy losses along the catenaries, the current is supplied by several substations distributed along the tracks. Two portions of catenaries supplied by different substations must be electrically isolated to avoid short circuits.\nMoreover, the way the tracks are electrified (DC or not for example) can change according to the local uses and the time of installation. It is again necessary to electrically isolate the portions of tracks which are electrified differently. The train must also (except in particular cases) change its pantograph when the type of electrification changes.\nIn both cases, the driver is instructed to cut the train’s traction, and sometimes even to lower the pantograph.\nIn the French infrastructure, these zones are indicated by announcement, execution and end signs. They also carry the indication to lower the pantograph or not. The portions of track between the execution and end may not be electrified entirely, and may not even have a catenary (in this case the zone necessarily requires lowering the pantograph).\nREV (for reversible) signs are sometimes placed downstream of the end of zone signs. They are intended for trains that run with a pantograph at the rear of the train. These signs indicate that the driver can resume traction safely.\nAdditionally, it may sometimes be impossible on a short section of track to place a catenary or to raise the train’s pantograph. In this case the line is still considered electrified, and the area without electrification (passage under a bridge for example) is considered as a neutral section.\nRolling stock After passing through a neutral section, a train must resume traction. This is not immediate (a few seconds), and the necessary duration depends on the rolling stock.\nIn addition, the driver must, if necessary, lower his pantograph, which also takes time (a few tens of seconds) and also depends on the rolling stock.\nThus, the coasting imposed on the train extends outside the neutral section, since these system times are to be counted from the end of the neutral section.\nData model We have chosen to model the neutral sections as the space between the signs linked to it (and not as the precise zone where there is no catenary or where the catenary is not electrified).\nThis zone is directional, i.e. associated with a direction of travel, in order to be able to take into account different placements of signs according to the direction. The execution sign of a given direction is not necessarily placed at the same position as the end of zone sign of the opposite direction.\nFor a two-way track, a neutral section is therefore represented by two objects.\nThe schema is the following\n{ \"lower_pantograph\": boolean, \"track_ranges\": [ { \"track\": string, \"start\": number, \"end\": number, \"direction\": enum } ], \"announcement_track_ranges\": [ { \"track\": string, \"start\": number, \"end\": number, \"direction\": enum } ] } lower_pantograph: indicates whether the pantograph should be lowered in this section track_ranges: list of track sections ranges where the train must not traction announcement_track_ranges: list of track sections ranges between the announcement sign and the execution sign Display Map The zones displayed in the map correspond to the track_ranges of neutral sections, thus are between the execution and end signs of the zone. The color of the zone indicates whether the train must lower its pantograph in the zone or not.\nThe direction in which the zone applies is not represented.\nSimulation results In the linear display, it is always the area between EXE and FIN that is displayed.\nPathfinding Neutral sections are therefore portions of “non-electrified” track where an electric train can still run (but where it cannot traction).\nWhen searching for a path in the infrastructure, an electric train can travel through a track section that is not covered by the track_ranges of a catenary object (documentation to be written) only if it is covered by the track_ranges of a neutral section.\nSimulation In our simulation, we approximate the driver’s behavior as follows:\nThe coasting is started as soon as the train’s head passes the announcement sign The system times (pantograph reading and traction resumption) start as soon as the train’s head passes the end sign. In the current simulation, it is easier to use spatial integration bounds rather than temporal ones. We make the following approximation: when leaving the neutral section, we multiply the system times by the speed at the exit of the zone. The coasting is then extended over the obtained distance. This approximation is reasonable because the train’s inertia and the almost absence of friction guarantee that the speed varies little over this time interval.\nImprovements to be made Several aspects could be improved:\nWe do not model the REV signs, all trains therefore only have one pantograph at the front in our simulations. System times are approximated. The driver’s behavior is rather restrictive (coasting could start after the announcement sign). The display of the zones is limited: no representation of the direction or the announcement zones. These zones are not editable. ","categories":"","description":"Documentation about what they are and how they are implemented","excerpt":"Documentation about what they are and how they are implemented","ref":"/en/docs/explanation/models/neutral_sections/","tags":"","title":"Neutral Sections"},{"body":"The current implementation has a number of shortcomings making it pretty much impossible to evolve to meet current system requirements. It also has a number of less severe flaws, such as the over-reliance on floating point, especially for input and output.\nThe previous implementation cannot be changed to:\nreact to signaling, as constraints stay the same as the simulation evolves handle rich train state vectors, due to the way margins are implemented be usable for both incremental simulation and batch These limitations are the primary reasons for this redesign.\nMargins are defined as post-processing filter passes on simulation results. This has a number of undesirable side effects:\nmargin algorithms produce the final simulation results. They may produce physically unrealistic simulations results\nbecause margins are applied after the simulation, the simulation can’t adjust to impossible margin values. Thus the simulation fails instead of giving a “best effort” result.\nmargin algorithms have no choice but to piece together results of different simulations:\nengineering margins are defined such that their effect has to be entirely contained within their bounds. even though it’s a desirable property, it means that simulations become a multi-pass affair, with no obvious way of keeping train behavior consistent across passes and boundaries. this can only be done if the train state is entirely described by its location and speed, otherwise simulation results cannot be pieced together. piecing together simulation results is very hard to execute reliably, as there are many corner cases to be considered. the algorithm is quite brittle. how much time should be lost and where isn’t defined in a way that makes scheduled points implementation easy\nwhen a transition between two margin values occurs, slow downs occur before value changes, and speed ups after value changes. This is nice in theory, because it makes the graphs look nicer. The downside is that it makes margin values interdependent at each slow-down, as how much speed needs to be lost affects the time lost in the section.\nInput modeling With the previous implementation, the simulation takes sequence of constraint position and speed curves as an input (continuous in position, can be discontinuous in speed), and produces a continuous curve.\nThe output is fine, but the input is troublesome:\nbraking curves have to be part of constraint curves these constraint curves don’t have a direct match with actual constraints, such as speed limits, stops, or reaction to signal constraints cannot evolve over time, and cannot be interpreted differently depending on when the train reached these constraints constraints cannot overlap. the input is pre-processed to filter out obscured constraints ","categories":"","description":"","excerpt":"The current implementation has a number of shortcomings making it …","ref":"/en/docs/reference/design-docs/train-sim-v3/prior-art/","tags":"","title":"Prior art"},{"body":"Objet physique que l’on cherche à modéliser Introduction Pour qu’un train puisse circuler, il faut soit qu’il ait une source d’énergie à bord (fuel, batterie, hydrogène, …) soit qu’on l’alimente en énergie tout au long de son parcours.\nPour fournir cette énergie, des câbles électriques sont suspendus au dessus des voies: les caténaires. Le train assure ensuite un contact avec ces câbles grâce à un patin conducteur monté sur un bras mécanique: le pantographe.\nZones neutres Avec ce système il est difficile d’assurer l’alimentation électrique d’un train en continu sur toute la longueur d’une ligne: sur certaines portions de voie, il est nécessaire de couper l’alimentation électrique du train. Ce sont ces portions que l’on appelle zones neutres.\nEn effet, pour éviter les pertes énergétiques le long des caténaires, le courant est fourni par plusieurs sous-stations réparties le long des voies. Deux portions de caténaires alimentées par des sous-stations différentes doivent être isolées électriquement pour éviter les courts-circuits.\nPar ailleurs, la façon dont les voies sont électrifiées (courant continu ou non par exemple) peut changer selon les us locaux et l’époque d’installation. Il faut également isoler électriquement les portions de voies qui sont électrifiées différemment. Le train doit aussi (sauf cas particuliers) changer de pantographe lorsqu’il change de type d’électrification.\nDans ces deux cas on indique alors au conducteur de couper la traction du train, et parfois même d’en baisser le pantographe.\nDans l’infrastructure française, ces zones sont signalées par des panneaux d’annonce, d’exécution et de fin. Ces panneaux portent par ailleurs l’indication de baisser le pantographe ou non. Les portions de voies entre l’exécution et la fin peuvent ne pas être électrifiées entièrement, et même ne pas posséder de caténaire (dans ce cas la zone nécessite forcément de baisser le pantographe).\nParfois, des pancartes REV (pour réversible) sont placées en aval des panneaux de fin de zone. Elles sont destinées aux trains qui circulent avec un pantographe à l’arrière du train. Ces pancartes indiquent que le conducteur peut reprendre la traction en toute sécurité.\nPar ailleurs il peut parfois être impossible sur une courte portion de voie de placer une caténaire ou bien de lever le pantographe du train. Dans ce cas la ligne est tout de même considérée électrifiée, et la zone sans électrification (passage sous un pont par exemple) est considérée comme une zone neutre.\nMatériel roulant Après avoir traversé une zone neutre, un train doit reprendre la traction. Ce n’est pas immédiat (quelques secondes), et la durée nécessaire dépend du matériel roulant.\nIl doit également, le cas échéant, relever son pantographe, ce qui prend également du temps (quelques dizaines de secondes) et dépend également du matériel roulant.\nAinsi la marche sur l’erre imposée au train s’étend en dehors de la zone neutre, puisque ces temps systèmes sont à décompter à partir de la fin de la zone neutre.\nModèle de données Nous avons choisi de modéliser les zones neutres comme l’espace entre les panneaux liés à celle-ci (et non pas comme la zone précise où il n’y a pas de caténaire ou bien où la caténaire n’est pas électrifiée).\nCette zone est directionnelle, i.e. associée à un sens de circulation, pour pouvoir prendre en compte des placements de panneaux différents selon le sens. Le panneau d’exécution d’un sens donné n’est pas nécessairement placé à la même position que le panneau de fin de zone du sens opposé.\nPour une voie à double sens, une zone neutre est donc représentée par deux objets.\nLe schema est le suivant\n{ \"lower_pantograph\": boolean, \"track_ranges\": [ { \"track\": string, \"start\": number, \"end\": number, \"direction\": enum } ], \"announcement_track_ranges\": [ { \"track\": string, \"start\": number, \"end\": number, \"direction\": enum } ] } lower_pantograph : indique si le pantographe doit être baissé dans cette zone track_ranges : liste des portions de voie où le train ne doit pas tractionner announcement_track_ranges : liste des portions de voie entre le panneau d’annonce et le panneau d’exécution Affichage Cartographie Les zones affichées dans la cartographie correspondent aux track_ranges, donc entre les panneaux d’exécution et de fin de zone. La couleur de la zone indique si le train doit baisser son pantographe dans la zone ou non.\nLa direction dans laquelle la zone s’applique n’est pas représentée.\nRésultat de simulation Dans l’affichage linéaire, c’est toujours la zone entre EXE et FIN qui est affichée.\nRecherche d’itinéraire Les zones neutres sont donc des portions de voie “non électrifiées” où un train électrique peut tout de même circuler (mais où il ne peut pas tractionner).\nLors de la recherche de chemin dans l’infrastructure, une portion de voie qui n’est pas couverte par les track_ranges d’un objet caténaire (documentation à écrire) peut être empruntée par un train électrique seulement si elle est couverte par les track_ranges d’une zone neutre.\nSimulation Dans la simulation, nous approximons le comportement du conducteur de la façon suivante :\nLa marche sur l’erre est entamée dès que la tête du train passe le panneau d’annonce Le décompte des temps systèmes (relevé du pantographe et reprise de la traction) commence dès que la tête du train passe le panneau de fin. Dans la simulation actuelle, il est plus facile de manier des bornes d’intégration spatiales que temporelles. Nous effectuons l’approximation suivante: lors de la sortie de la zone neutre, on multiplie les temps systèmes par la vitesse en sortie de zone. La marche sur l’erre est alors prolongée de la distance obtenue. Cette approximation est raisonnable car l’inertie du train et la quasi-absence de frottement garantissent que la vitesse varie peu sur cet intervalle de temps.\nPotentielles améliorations Plusieurs points pourraient être améliorés :\nOn ne considère pas les pancartes REV, tous les trains ne possèdent donc qu’un pantographe à l’avant dans nos simulations. Les temps systèmes sont approximés. Le comportement conducteur est plutôt restrictif (la marche sur l’erre pourrait commencer après le panneau d’annonce). L’affichage des zones est limité: pas de représentation de la direction ou des zones d’annonce. Ces zones ne sont pas éditables. ","categories":"","description":"Documentation des zones neutres et de leur implémentation","excerpt":"Documentation des zones neutres et de leur implémentation","ref":"/fr/docs/explanation/models/neutral_sections/","tags":"","title":"Zones neutres"},{"body":"Ce module gère la recherche de solution.\nLes entrées et sorties sont fortement simplifiées et abstraites pour simplifier le problème au maximum et permettre des tests efficaces.\nPour décrire son fonctionnement en quelques phrases : l’espace de solutions est représenté sous forme d’un graphe qui encode le temps, la position et la vitesse. Une recherche de chemin est ensuite effectuée dans ce graphe pour trouver une solution. Le graphe est calculé au fil de son exploration.\nCe graphe peut d’une certaine manière être vu comme une forme d’arbre de décision, si différents chemins peuvent mener au même noeud.\n","categories":"","description":"","excerpt":"Ce module gère la recherche de solution.\nLes entrées et sorties sont …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/","tags":"","title":"Module de recherche de sillons"},{"body":"This module handles the search for solutions.\nTo reduce the problem to its simplest form and for easy and efficient testing, inputs and outputs are strongly simplified and abstracted.\nTo summarize its behavior: the solution space is described as a graph that encodes locations, time, and speed. A pathfinding is run on this graph to find a solution.\nThis graph could, in a way, be seen as a decision tree, but different paths can lead to the same node.\n","categories":"","description":"","excerpt":"This module handles the search for solutions.\nTo reduce the problem to …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/","tags":"","title":"Train slot search module"},{"body":"Le problème des discontinuités Au moment d’explorer une arête du graphe, on effectue un calcul de marche pour connaître l’évolution de la vitesse. Mais il n’est pas possible de voir plus loin que l’arête en question, ce qui est gênant pour calculer les courbes de freinages qui peuvent nécessiter de commencer à freiner plusieurs kilomètres avant l’arrivée.\nCet exemple illustre le problème : par défaut la première arête est explorée en allant à la vitesse maximale. C’est seulement en explorant la seconde arête que la destination devient visible, sans que la distance restante soit suffisante pour s’arrêter.\nLa solution : revenir en arrière Pour régler ce problème, lorsqu’une arête est générée avec une discontinuité dans les courbes de vitesse, l’algorithme revient sur les arêtes précédentes pour en créer des nouvelles qui incluent les décélérations.\nPour donner un exemple simplifié, sur un chemin de 4 routes où le train peut accélérer ou décélérer de 10km/h par route :\nPour que le train s’arrête à la fin de la route 4, il doit être au plus à 10km/h à la fin de la route 3. Une nouvelle arête est alors créée sur la route 3 qui finit à 10km/h. Une décélération est ensuite calculée à rebours de la fin de la route vers le début, jusqu’à retrouver la courbe d’origine (ou le début de l’arrête).\nDans cet exemple, la discontinuité a seulement été déplacée vers la transition entre les routes 2 et 3. Le procédé est ensuite réitéré sur la route 2, ce qui donne le résultat suivant :\nLes anciennes arêtes sont toujours présentes dans le graphe, elles peuvent mener à d’autres solutions.\n","categories":"","description":"","excerpt":"Le problème des discontinuités Au moment d’explorer une arête du …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/","tags":"","title":"Discontinuités et retours en arrière"},{"body":"The discontinuity problem When a new graph edge is visited, a simulation is run to evaluate its speed. But it is not possible to see beyond the current edge. This makes it difficult to compute braking curves, because they can span over several edges.\nThis example illustrates the problem: by default the first edge is explored by going at maximum speed. The destination is only visible once the second edge is visited, which doesn’t leave enough distance to stop.\nSolution : backtracking To solve this problem, when an edge is generated with a discontinuity in the speed envelopes, the algorithm goes back over the previous edges to create new ones that include the decelerations.\nTo give a simplified example, on a path of 4 edges where the train can accelerate or decelerate by 10km/h per edge:\nFor the train to stop at the end of route 4, it must be at most at 10km/h at the end of edge 3. A new edge is then created on edge 3, which ends at 10km/h. A deceleration is computed backwards from the end of the edge back to the start, until the original curve is met (or the start of the edge).\nIn this example, the discontinuity has only been moved to the transition between edges 2 and 3. The process is then repeated on edge 2, which gives the following result:\nOld edges are still present in the graph as they can lead to other solutions.\n","categories":"","description":"","excerpt":"The discontinuity problem When a new graph edge is visited, a …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/backtracking/","tags":"","title":"Discontinuities and backtracking"},{"body":"The envelope system is an interface created specifically for the OSRD gait calculation. It allows you to manipulate different space/velocity curves, to slice them, to end them, to interpolate specific points, and to address many other needs necessary for the gait calculation.\nA specific interface in the OSRD Core service The envelope system is part of the core service of OSRD (see software architecture).\nIts main components are :\n1 - EnvelopePart: space/speed curve, defined as a sequence of points and having metadata indicating for example if it is an acceleration curve, a braking curve, a speed hold curve, etc.\n2 - Envelope: a list of end-to-end EnvelopeParts on which it is possible to perform certain operations:\ncheck for continuity in space (mandatory) and speed (optional) look for the minimum and/or maximum speed of the envelope cut a part of the envelope between two points in space perform a velocity interpolation at a certain position calculate the elapsed time between two positions in the envelope 3 - Overlays : system for adding more constrained (i.e. lower speed) EnvelopeParts to an existing envelope.\nGiven envelopes vs. calculated envelopes During the simulation, the train is supposed to follow certain speed instructions. These are modelled in OSRD by envelopes in the form of space/speed curves. Two types can be distinguished:\nEnvelopes from infrastructure and rolling stock data, such as maximum line speed and maximum train speed. Being input data for our calculation, they do not correspond to curves with a physical meaning, as they are not derived from the results of a real integration of the physical equations of motion. The envelopes result from real integration of the physical equations of motion. They correspond to a curve that is physically tenable by the train and also contain time information. A simple example to illustrate this difference: if we simulate a TER journey on a mountain line, one of the input data will be a maximum speed envelope of 160km/h, corresponding to the maximum speed of our TER. However, this envelope does not correspond to a physical reality, as it is possible that on certain sections the gradient is too steep for the train to be able to maintain this maximum speed of 160km/h. The calculated envelope will therefore show in this example a speed drop in the steepest areas, where the envelope given was perfectly flat.\nSimulation of several trains In the case of the simulation of many trains, the signalling system must ensure safety. The effect of signalling on the running calculation of a train is reproduced by superimposing dynamic envelopes on the static envelope. A new dynamic envelope is introduced for example when a signal closes. The train follows the static economic envelope superimposed on the dynamic envelopes, if any. In this simulation mode, a time check is performed against a theoretical time from the time information of the static economic envelope. If the train is late with respect to the scheduled time, it stops following the economic envelope and tries to go faster. Its space/speed curve will therefore be limited by the maximum effort envelope.\n","categories":"","description":"","excerpt":"The envelope system is an interface created specifically for the OSRD …","ref":"/en/docs/explanation/running_time_calculation/envelopes_system/","tags":"","title":"Envelopes system"},{"body":"Le système d’enveloppes est une interface créée spécifiquement pour le calcul de marche d’OSRD. Il permet de manipuler différentes courbes espace/vitesse, de les découper, de les mettre bout à bout, d’interpoler des points spécifiques, et d’adresser beaucoup d’autres besoins nécessaires au calcul de marche.\nUne interface spécifique dans le service OSRD Core Le système d’enveloppes fait partie du service core d’OSRD (voir l’architecture du logiciel).\nSes principaux composants sont :\n1 - EnvelopePart : courbe espace/vitesse, définie comme une séquence des points et possédant des métadonnées indiquant par exemple s’il s’agit d’une courbe d’accélération, de freinage, de maintien de vitesse, etc.\n2 - Envelope : liste d’EnvelopeParts mises bout-à-bout et sur laquelle il est possible d’effectuer certaines opérations :\nvérifier la continuité dans l’espace (obligatoire) et dans la vitesse (facultative) chercher la vitesse minimale et/ou maximale de l’enveloppe couper une partie de l’enveloppe entre deux points de l’espace effectuer une interpolation de vitesse à une certaine position calculer le temps écoulé entre deux positions de l’enveloppe 3 - Overlays : système permettant d’ajouter des EnvelopePart plus contraignantes (c’est-à-dire dont la vitesse est plus faible) à une enveloppe existante.\nEnveloppes données vs enveloppes calculées Pendant la simulation, le train est censé suivre certaines instructions de vitesse. Celles-ci sont modélisées dans OSRD par des enveloppes sous forme de courbes espace/vitesse. On en distingue deux types :\nLes enveloppes provenant des données d’infrastructure et de matériel roulant, comme la vitesse maximale de la ligne et la vitesse maximale du train. Etant des données d’entrée de notre calcul, elles ne correspondent pas à des courbes ayant un sens physique, car elles ne sont pas issues des résultats d’une intégration réelle des équations physiques du mouvement. Les enveloppes résultant d’une intégration réelle des équations du mouvement physique. Elles correspondent à une courbe physiquement tenable par le train et contiennent également des informations sur le temps. Un exemple simple pour illustrer cette différence : si l’on simule un trajet de TER sur une ligne de montagne, une des données d’entrée va être une enveloppe de vitesse maximale à 160km/h, correspondant à la vitesse maximale de notre TER. Mais cette enveloppe ne correspond pas à une réalité physique, car il se peut que sur certaines portions la rampe soit trop raide pour que le train arrive effectivement à maintenir cette vitesse maximale de 160km/h. L’enveloppe calculée présentera donc dans cet exemple un décrochage de vitesse dans les zones de fortes rampes, là où l’enveloppe donnée était parfaitement plate.\nSimulation de plusieurs trains Dans le cas de la simulation de nombreux trains, le système de signalisation doit assurer la sécurité. L’effet de la signalisation sur le calcul de marche d’un train est reproduit en superposant des enveloppes dynamiques à l’enveloppe statique. Une nouvelle enveloppe dynamique est introduite par exemple lorsqu’un signal se ferme. Le train suit l’enveloppe économique statique superposée aux enveloppes dynamiques, s’il y en a. Dans ce mode de simulation, un contrôle du temps est effectué par rapport à un temps théorique provenant de l’information temporelle de l’enveloppe économique statique. Si le train est en retard par rapport à l’heure prévue, il cesse de suivre l’enveloppe économique et essaie d’aller plus vite. Sa courbe espace/vitesse sera donc limitée par l’enveloppe d’effort maximum.\n","categories":"","description":"","excerpt":"Le système d’enveloppes est une interface créée spécifiquement pour le …","ref":"/fr/docs/explanation/running_time_calculation/envelopes_system/","tags":"","title":"Le système d'enveloppes"},{"body":"OSRD peut être utilisé pour effectuer deux types de calculs :\nCalcul de marche (standalone train simulation) : calcul du temps de parcours d’un train sur un trajet donné, effectué sans interaction entre le train et le système de signalisation. Simulation : calcul “dynamique” de plusieurs trains interagissant entre eux via le système de signalisation. 1 - Les données d’entrée Un calcul de marche est basé sur 5 entrées :\nL’infrastructure : Topologie des lignes et des voies, position des gares et bâtiments voyageurs, position et type des aiguilles, signaux, vitesses maximales de ligne, profil de ligne corrigée (pentes, rampes et virages). L’histogramme bleu est une représentation des déclivités en [‰] par position en [m]. Les déclivités sont positives pour les rampes et négatives pour les pentes.\nLa ligne orange représente le profil cumulé, c’est-à-dire l’altitude relative par rapport au point de départ.\nLa ligne bleue est une représentation des virages en termes de rayons des courbures en [m].\nLe matériel roulant : Dont les caractéristiques nécessaires pour effectuer la simulation sont représentées ci-dessous. La courbe orange, appelée courbe effort-vitesse du matériel, représente l’effort moteur maximal en fonction de la vitesse de circulation.\nLa longueur, la masse, et la vitesse max du train sont représentées en bas de l’encadré.\nL’horaire de départ permettant ensuite de calculer les horaires de passage aux différents points remarquables (dont gares).\nLes marges : Temps ajouté au trajet du train pour détendre sa marche (voir page sur les marges).\nLe pas de temps pour le calcul de l’intégration numérique. 2 - Les résultats Les résultats d’un calcul de marche peuvent se représenter sous différentes formes :\nLe graphique espace/temps (GET) : représente le parcours des trains dans l’espace et dans le temps, sous la forme de traits globalement diagonaux dont la pente est la vitesse. Les arrêts apparaissent sous la forme de plateaux horizontaux. Exemple de GET avec plusieurs trains espacés d’environ 30mn.\nL’axe x est l’horaire de passage du train, l’axe y est la position du train en [m].\nLa ligne bleue représente le calcul de marche le plus tendu pour le train, la ligne verte représente un calcul de marche détendu, dit « économique ».\nLes rectangles pleins entourant les trajets représentent les portions de la voie successivement reservées au passage du train (appelées cantons).\nLe graphique espace/vitesse (GEV) : représente le parcours d’un seul train, cette fois-ci en termes de vitesse. Les arrêts apparaissent donc sous forme de décrochages de la courbe jusqu’à zéro, suivis d’un réaccélération. L’axe x est la position du train en [m], l’axe y est la vitesse du train en [km/h] .\nLa ligne violette représente la vitesse maximale autorisée.\nLa ligne bleue représente la vitesse dans le cas du calcul de marche le plus tendu.\nLa ligne verte représente la vitesse dans le cas du calcul de marche « économique ».\nLes horaires de passage du train aux différents points remarquables ","categories":"","description":"","excerpt":"OSRD peut être utilisé pour effectuer deux types de calculs :\nCalcul …","ref":"/fr/docs/explanation/running_time_calculation/","tags":"","title":"Calcul de marche"},{"body":"Whether you would like to use OSRD, understand it or contribute, this is the right place!\n","categories":"","description":"","excerpt":"Whether you would like to use OSRD, understand it or contribute, this …","ref":"/en/docs/","tags":"","title":"Documentation"},{"body":"Vous souhaitez utiliser OSRD, y contribuer, ou simplement en comprendre le fonctionnement ? Cette documentation est pour vous !\n","categories":"","description":"","excerpt":"Vous souhaitez utiliser OSRD, y contribuer, ou simplement en …","ref":"/fr/docs/","tags":"","title":"Documentation"},{"body":"Driving instructions model what the train has to do, and under what conditions. Driving instructions are generated using domain constraints such as:\nunsignaled line speed limits permanent signaled speed limits temporary speed limits dynamic signaling: block / moving block dynamically signaled speed restrictions neutral zones stops margins There are two types of driving instructions:\nAbstract driving instructions model the high-level, rolling stock independent range of acceptable behavior: reach 30km/h at this location Concrete driving instructions model the specific range of acceptable behavior for a specific rolling stock, using limit curves: don’t go faster than this curve flowchart TD Constraint[constraint] AbstractDrivingInstruction[abstract driving instruction] ConcreteDrivingInstruction[concrete driving instruction] RollingStockIntegrator[rolling stock integrator] Compiler([compiler]) Constraint -- generates one or more --\u003e AbstractDrivingInstruction AbstractDrivingInstruction --\u003e Compiler RollingStockIntegrator --\u003e Compiler Compiler --\u003e ConcreteDrivingInstruction After reviewing the design document, the necessity to distinguish between abstract and concrete driving instructions was questioned.\nIndeed, it isn’t clear whether the limit curves are used for the driving instructions interpretation algorithm. If it isn’t, the computation of limit curves could be moved inside the driver behavior module.\nTODO: remove this message or fix the design document after implementation.\nInterpreting driving instructions During the simulation, driving instructions are partitioned into 4 sets:\nPENDING instructions may apply at some point in the future RECEIVED instructions aren’t enforced yet, but will be unless overridden ENFORCED instructions influence train behavior DISABLED instructions don’t ever have to be considered anymore. There are multiple ways instructions can be disabled: SKIPPED instructions were not received RETIRED instructions expired by themselves OVERRIDDEN instructions were removed by another instruction flowchart TD subgraph disabled skipped retired overridden end subgraph active received enforced end pending --\u003e received pending --\u003e skipped received --\u003e enforced received --\u003e overridden enforced --\u003e retired enforced --\u003e overridden These sets evolve as follows:\nwhen an integration steps overlaps a PENDING instruction’s received condition, it is RECEIVED and becomes a candidate to execution existing instructions may be OVERRIDDEN due to an override_on_received operation if an instruction cannot ever be received at any future simulation state, it transitions to the SKIPPED state when simulation state exceeds an instruction’s enforcement position, it becomes ENFORCED. Only enforced instructions influence train behavior. existing instructions may be OVERRIDDEN due to an override_on_enforced operation when simulation state exceeds an instruction’s retirement position, it becomes RETIRED Overrides When an instruction transitions to the RECEIVED or ENFORCED state, it can disable active instructions which match some metadata predicate. There are two metadata attributes which can be relied on for overrides:\nthe kind allows overriding previous instructions for a given domain, such as spacing or block signaled speed limits the rank can be used as a “freshness” or “priority” field. If two instructions overriding each other are received (such as when a train sees two signals), the rank allows deciding which instruction should be prioritized. This is required to implement a number of signaling features, as well as stops, where the stop instruction is overridden by the restart instruction.\nData model struct ReceivedCond { position_in: Option\u003cPosRange\u003e, time_in: Option\u003cTimeRange\u003e, } struct InstructionMetadata { // state transitions received_when: ReceivedCond, enforced_at: Position, retired_at: Option\u003cPosition\u003e, // instruction metadata, used by override filters. if an instruction // has no metadata nor retiring condition, it cannot be overridden. kind: Option\u003cInstructionKindId\u003e, // could be SPACING, SPEED_LIMIT rank: Option\u003cusize\u003e, // when the instruction transitions to a given state, // instructions matching any filter are overridden override_on_received: Vec\u003cOverrideFilter\u003e, override_on_enforced: Vec\u003cOverrideFilter\u003e, } enum AbstractInstruction { NeutralZone, SpeedTarget { at: Position, speed: Speed, } } enum ConcreteInstruction { NeutralZone, SpeedTarget { braking_curve: SpeedPosCurve, }, } struct OverrideFilter { kind: InstructionKindId, rank: Option\u003c(RankRelation, usize)\u003e, } enum RankRelation { LT, LE, EQ, GE, GT } Design decisions Lowering constraints to an intermediate representation Early on, we started making lists of what domain constraints can have an impact on train behavior. Meanwhile, to simulate train behavior, we figured out that we need to know which constraints apply at any given time.\nThere’s a fundamental tension between these two design constraints, which can be resolved in one of two ways:\neither treat each type of constraint as its own thing during the simulation abstract away constraints into a common representation, and then simulate that ❌ Distinct constraint types When we first started drafting architecture diagrams, the train simulation API directly took a bunch of constraint types as an input. It brought up a number of issues:\nthe high diversity of constraint types makes it almost impossible to describe all interactions between all constraint types the domain of some of these interactions is very complex (block signaling) when simulating, it does not seem to matter why a constraint is there, only what to do about it We couldn’t find clear benefits to dragging distinctions between constraint types deep into the implementation.\n❌ Internal constraint types abstraction We then realized that abstracting over constraint types during simulation had immense benefits:\nit allows expressing requirements on what constraints need to be enforceable it greatly simplifies the process of validating constraint semantics: instead of having to validate interactions between every possible type of constraints, we only have to validate that the semantics of each constraint type can be transferred to the abstract constraint type We decided to explore the possibility of keeping constraint types distinct in the external API, but lowering these constraints into an intermediary representation internally. We found a number of downsides:\nthe public simulation API would still bear the complexity of dealing with many constraint types there would be a need to incrementally generate internal abstracted constraints to support the incremental API ✅ External constraint types abstraction We tried to improve over the previous proposal by moving the burden of converting many constraints into a common abstraction out of the simulation API.\nInstead of having many constraint types as an input, the simulation API takes a collection of a single abstract constraint type. The task of converting domain constraints to abstract driving instructions is left to the API user.\nWe found that doing so:\nreduces the API surface of the train simulation module decouples behavior from constraint types: if a new constraint type needs to be added, the simulation API only needs expansion if the expected behavior expected for this constraint isn’t part of the API. Interpreting driving instructions As the train progresses through the simulation, it reacts according to driving instructions which depend on more than the bare train physics state (position, time, and speed):\nthe behavior of a train on each block depends on the state of the last passed block signal if a train encounters a yellow light, then a red light, stops before the red light, and the red light turns green, the train may have to keep applying the driving instruction from the yellow signal until the green light is passed Thus, given:\nset of all possible driving instructions (alongside applicability metadata) the result of previous integration steps (which may be extended to hold metadata) There is a need to know what driving instructions are applicable to the current integration step.\nOverrides are a way of modeling instructions which disable previous ones. Here are some examples:\nif a driver watches a signal change state, its new aspect’s instruction might take precedence over the previous one as block signaling slows a train down, new signals can override instructions from previous signals, as they encode information that is more up to date We identified multiple filtering needs:\noverrides happen as a given kind of restriction is updated: SPACING instructions might override other SPACING instructions, but wish to leave other speed restrictions unaffected as multiple block signals can be visible at once, there’s a need to avoid overriding instructions of downstream signals with updates to upstream signals We quickly settled on adding a kind field, but had a lengthy discussion over how to discriminate upstream and downstream signals. We explored the following options:\n❌ adding source metadata, which was rejected as it does not address the issue of upstream / downstream ❌ adding identifiers to instructions, and overriding specific instructions, which was rejected as it makes instruction generation and processing more complex ✅ adding some kind of priority / rank field, which was adopted ","categories":"","description":"","excerpt":"Driving instructions model what the train has to do, and under what …","ref":"/en/docs/reference/design-docs/train-sim-v3/driving-instruction/","tags":"","title":"Driving instructions"},{"body":"Les guides pratiques sont des marches à suivre. Vous êtes guidés pas-à-pas dans la résolution de problèmes, ou dans des scénarios classiques. Les connaissances requises sont plus élevées que pour les tutoriels, et le fonctionnement d’OSRD doit être compris.\n","categories":"","description":"Marches à suivre pour des tâches classiques","excerpt":"Marches à suivre pour des tâches classiques","ref":"/fr/docs/guides/","tags":"","title":"Guides pratiques"},{"body":"How-to guides are recipes. They guide you through the steps involved in addressing key problems and use-cases. They are more advanced than tutorials and assume some knowledge of how OSRD works.\n","categories":"","description":"Recipes for addressing key problems and use-cases","excerpt":"Recipes for addressing key problems and use-cases","ref":"/en/docs/guides/","tags":"","title":"How-to Guides"},{"body":" Le mot réservation ici a pour sens réservation de la resource itinéraire, et non le sens commande plannifiée d’itinéraire Description Les zones (ou TVDSection / DetectionSection) sont des partitions physiques des voies :\ncapables de détecter la présence d’un train qui fournissent un service de réservation à l’usage des routes Chaque zone a un certain nombre de configurations différentes. Par exemple, une zone sans aiguille aura deux configurations :\nsens pair sens impair Une zone avec une aiguille aura 4 configurations possibles :\nsens pair voie principale sens impair voie principale sens pair voie déviation sens impair voie déviation Chaque zone ne peut être réservée que pour une configuration donnée à la fois, mais peut être réservée simultanément par plusieurs routes. Une zone ne peut changer de configuration que lorsqu’elle n’est pas réservée.\nEn discutant avec des experts métiers, vous entendrez parler d’enclenchements: le terme viens de l’époque où les postes de signalisations étaient entièrement mécaniques. Les enclenchements étaient alors des objets physiques qui empêchaient certaines configurations.\nUne conséquence de cet héritage historique et que beaucoup de règles ferroviaires sont exprimées par contraintes au lieu d’être exprimées par garanties. Un enclenchement, c’est une garantie qu’une situation particulière ne peut pas se produire.\nÉtat dynamique d’une zone enum ZoneState { /// A list of active reservations. /// Each reservation requires a particular configuration to be upheld. reservations: VecDeque\u003cZoneReservation\u003e, } struct ZoneReservation { /// The train which requires this reservation train: TrainHandle, // The configuration required for this reservation requirements: ZoneRequirements, /// The state of this reservation status: ZoneReservationStatus, } enum ZoneReservationStatus { /// In the process of being reserved, but not yet ready PRE_RESERVED, /// The train can arrive anytime RESERVED, /// The train is inside the zone OCCUPIED, /// The zone is pending release PENDING_RELEASE, } struct ZoneRequirements { entry: Option\u003cDirDetector\u003e, exit: Option\u003cDirDetector\u003e, movable_elements: Map\u003cMovableElement, MovableElementConfig\u003e, } impl ZoneState { /// Get the combined requirements for all the currently active reservations fn get_combined_requirements(\u0026self) -\u003e Option\u003cZoneRequirements\u003e { return self.reservations .map(|res| \u0026res.requirements) .reduce(|a, b| ZoneRequirements::combine(a, b)) } } Exigences de conception Les zones doivent pouvoir être verrouillées dans une configuration particulière. Il doit être possible pour plusieurs routes de partager une réservation de configuration. Il doit être possible d’observer l’évolution de statut d’une réservation. Il doit être possible de faire évoluer le statut d’une réservation. Dépendances statique les détecteurs qui délimitent chaque zone statique les aiguilles dans chaque zone dynamique capacité d’observer l’occupation des zones dynamique capacité d’actionner les éléments mobiles Opérations espacement: Observer l’état d’une zone routage: Verrouiller et déverrouiller la zone : permet d’obtenir un droit d’action. Toutes les opérations en écriture nécessitent d’avoir acquis le verrou. routage: Attendre que toutes les réservations d’une zone expirent routage: Pré-réserver une configuration de zone routage: Confirmer la réservation d’une zone routage: Attendre que la réservation de la zone soit occupée par son train routage: Relacher une réservation de zone ","categories":"","description":"Gère l'état de réservation des zones","excerpt":"Gère l'état de réservation des zones","ref":"/fr/docs/reference/design-docs/interlocking/reservation/","tags":"","title":"Reservation"},{"body":"OSRD can be used to perform two types of calculations:\nStandalone train simulation: calculation of the travel time of a train on a given route without interaction between the train and the signalling system. Simulation: “dynamic” calculation of several trains interacting with each other via the signalling system. 1 - The input data A running time calculation is based on 5 inputs:\nInfrastructure: Line and track topology, position of stations and passenger buildings, position and type of points, signals, maximum line speeds, corrected line profile (gradients, ramps and curves). The blue histogram is a representation of the gradients in [‰] per position in [m]. The gradients are positive for ramps and negative for slopes.\nThe orange line represents the cumulative profile, i.e. the relative altitude to the starting point.\nThe blue line is a representation of turns in terms of radii of curves in [m].\nThe rolling stock: The characteristics of which needed to perform the simulation are shown below. The orange curve, called the effort-speed curve, represents the maximum motor effort as a function of the speed of travel.\nThe length, mass, and maximum speed of the train are shown at the bottom of the box.\nThe departure time is then used to calculate the times of passage at the various points of interest (including stations).\nAllowances: Time added to the train’s journey to relax its running (see page on allowances).\nThe time step for the calculation of numerical integration. 2 - The results The results of a running time calculation can be represented in different forms:\nThe space/time graph (GET): represents the path of trains in space and time, in the form of generally diagonal lines whose slope is the speed. Stops are shown as horizontal plates. Example of a GET with several trains spaced about 30 minutes apart.\nThe x axis is the time of the train, the y axis is the position of the train in [m].\nThe blue line represents the most tense running calculation for the train, the green line represents a relaxed, so-called “economic” running calculation.\nThe solid rectangles surrounding the paths represent the portions of the track successively reserved for the train to pass (called blocks).\nThe space/speed graph (SSG): represents the journey of a single train, this time in terms of speed. Stops are therefore shown as a drop in the curve to zero, followed by a re-acceleration. The x axis is the train position in [m], the y axis is the train speed in [km/h].\nThe purple line represents the maximum permitted speed.\nThe blue line represents the speed in the case of the most stretched running calculation.\nThe green line represents the speed in the case of the “economic” travel calculation.\nThe timetable for the passage of the train at the various points of interest. ","categories":"","description":"","excerpt":"OSRD can be used to perform two types of calculations:\nStandalone …","ref":"/en/docs/explanation/running_time_calculation/","tags":"","title":"Running time calculation"},{"body":"Description Railway infrastructure has a surprising variety of speed limits:\nsome are known by the driver, and not announced at all some are announced by fixed signs regardless of where the train goes some are announced by fixed signs, depending on where the train path goes some are announced by dynamic signals regardless of where the train goes some are announced by dynamic signals, depending on where the train path goes Data model { # unique speed limit identifier \"id\": \"...\", # A list of routes the speed limit is enforced on. When empty # or missing, the speed limit is enforced regardless of the route. # # /!\\ When a speed section is announced by signals, the routes it is # announced on are automatically filled in /!\\ \"on_routes\": [\"${ROUTE_A}\", \"${ROUTE_B}\"] # \"on_routes\": null, # not conditional # \"on_routes\": [], # conditional # A speed limit in meters per second. \"speed_limit\": 30, # A map from train tag to speed limit override. If missing and # the speed limit is announced by a signal, this field is deduced # from the signal. \"speed_limit_by_tag\": {\"freight\": 20}, \"track_ranges\": [{\"track\": \"${TRACK_SECTION}\", \"begin\": 0, \"end\": 42, \"applicable_directions\": \"START_TO_STOP\"}], } Design considerations Where to put the speed limit value When a speed limit is announced by dynamic signaling, we may be in a position where speed limit value is duplicated:\nonce in the signal itself once in the speed limit There are multiple ways this issue can be dealt with:\n✅ Mandatory speed limit value in the speed section Upsides:\nsimpler to implement, works even without train reactions to signals nor additional API Downsides:\nmore work on the side of users room for inconsistencies between the speed limit announced by signaling, and the effective speed limit ❌ Deduce the signal constraint from the speed limit This option was not explored much, as it was deemed awkward to deduce signal parameters from a speed limit value.\n❌ Deduce the speed limit from the signal Make the speed limit value optional, and deduce it from the signal itself. Speed limits per tag also have to be deduced if missing.\nUpsides:\nless work for users lessens the likelyhood of configuration mismatches Downsides:\nnot all signaling systems work well with this. It may be difficult to deduce the announced speed limit from a signal configuration, such as with TVM. speed limits have to be deduced, which increases implementation complexity How to link announce signals and speed limit area Speed limit announced by dynamic signaling often start being enforced at a specific location, which is distinct from the signal which announces the speed limit.\nTo allow for correct train reactions to this kind of limits, a link between the announce signal and the speed limit section has to be made at some point.\n❌ Automated matching of signals and speed sections Was not deemed realistic.\n❌ Explicit link from route to speed limit and signals Was deemed to be awkward, as signaling is currently built over interlocking. Referencing signaling from interlocking creates a circular dependency between the two schemas.\n❌ Explicit link from speed limit to signals Add a list of (route, signal) tuples to speed sections.\nUpside:\na link with the signal can be made with creating the speed section Downside:\nCreates a dependency loop between speed limits and signaling. Part of the parsing of speed limit has to be deferred. Signals parameters also have to be set per route, which is done in the signal. Having per-route options on both sides doubles the work. ❌ Inlining speed limit definitions into signals Introduces a new type of speed limit, which are announced by signals. These speed limits are directly defined within signal definitions.\n{ # ... \"conditional_parameters\": [ { \"on_route\": \"${ROUTE_ID}\", \"speed_section\": { \"speed_limit\": 42, \"begin\": {\"track\": \"a\", \"offset\": 10}, \"end\": {\"track\": \"b\", \"offset\": 15}, }, \"parameters\": {\"rappel30\": \"true\", \"short_block\": \"true\"} } ] # ... } Upsides:\nstraightforward infrastructure edition experience for speed sections announced by a single signal Downsides:\ncreates two separate kinds of speed limits: can cause code duplication could make later changes of the data model trickier it’s unclear whether the criterion used to make this partition is appropriate speed sections created directly inside signals can only be announced by a single signal, which could be an issue for speed sections which apply to very large areas, and are announced by multiple signals (such as one for each direction) the cost of reversing this decision could be fairly high ✅ Explicit link from signal to speed section { # ... \"conditional_parameters\": [ { \"on_route\": \"${ROUTE_ID}\", \"announced_speed_section\": \"${SPEED_SECTION_ID}\", \"parameters\": {\"rappel30\": \"true\", \"short_block\": \"true\"} } ] # ... } Upsides:\nsingle unified way of declaring speed limits very close to the current implementation Downsides:\nadds a level of indirection between the signal and the speed section the edition front-end has to be smart enough to create / search speed sections from the signal edition menu Speed limits by route Some speed limits only apply so some routes. This relationship needs to be modeled:\nspeed limits could have a list of routes they apply on routes could have a list of speed limits they enforce the routes a speed limit apply on could be deduced from its announce signals, plus an explicit list of routes per speed section We took option 3.\n","categories":"","description":"Describes how speed limits work","excerpt":"Describes how speed limits work","ref":"/en/docs/reference/design-docs/signaling/speed-limits/","tags":"","title":"Speed limits"},{"body":"While exploring the graph, it is possible to end up in locations that would generate conflicts. They can be avoided by adding delay.\nShifting the departure time The departure time is defined as an interval in the module parameters: the train can leave at a given time, or up to x seconds later. Whenever possible, delay should be added by shifting the departure time.\nfor example : a train can leave between 10:00 et 11:00. Leaving at 10:00 would cause a conflict, the train actually needs to enter the destination station 15 minutes later. Making the train leave at 10:15 solves the problem.\nIn OSRD, this feature is handled by keeping track, for every edge, of the maximum duration by which we can delay the departure time. As long as this value is enough, conflicts are avoided this way.\nThis time shift is a value stored in every edge of the path. Once a path is found, the value is summed over the whole path. This is added to the departure time.\nFor example :\na train leaves between 10:00 and 11:00. The initial maximum time shift is 1:00. At some point, an edge becomes unavailable 20 minutes after the train passage. The value is now at 20 for any edge accessed from here. The departure time is then delayed by 5 minutes to avoid a conflict. The maximum time shift value is now at 15 minutes. This process is applied until the destination is found, or until no more delay can be added this way. Engineering allowances Once the maximum delay is at 0, the delay needs to be added between two points of the path.\nThe idea is the same as the one used to fix speed discontinuities: new edges are created, replacing the previous ones. The new edges have an engineering allowance, to add the delay where it is possible.\ncomputing an engineering allowance is a feature of the running-time calculation module. It adds a given delay between two points of a path, without affecting the speeds on the rest of the path.\nPost-processing We used to compute the engineering allowances during the graph exploration, but that process was far too expensive. We used to run binary searches on full simulations, which would sometimes go back for a long distance in the path.\nWhat we actually need is to know whether an engineering allowance is possible without causing any conflict. We can use heuristics here, as long as we’re on the conservative side: we can’t say that it’s possible if it isn’t, but missing solutions with extremely tight allowances isn’t a bad thing in our use cases.\nBut this change means that, once the solution is found, we can’t simply concatenate the simulation results. We need to run a full simulation, with actual engineering allowances, that avoid any conflict. This step has been merged with the one described on the standard allowance page, which is now run even when no standard allowance have been set.\n","categories":"","description":"","excerpt":"While exploring the graph, it is possible to end up in locations that …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/","tags":"","title":"Conflict avoidance"},{"body":"En explorant le graphe, il arrive souvent de tomber sur des situations qui mèneraient à des conflits. Il faut être en mesure de rajouter du délai pour les éviter.\nDécalage du temps de départ Dans les paramètres de l’algorithme, le temps de départ est donné sous la forme d’une fenêtre : un temps de départ au plus tôt et au plus tard. Tant que c’est possible, il est toujours préférable de décaler le temps de départ pour éviter les conflits.\nPar exemple : un train doit partir entre 10:00 et 11:00. En partant à 10:00, cela provoque un conflit, le train doit entrer en gare d’arrivée 15 minutes plus tard. Il suffit de faire partir le train à 10:15 pour régler le problème.\nDans OSRD, cette fonctionnalité est gérée en gardant une trace, à chaque arête, du décalage maximal du temps de départ qui pourra être ajouté sur la suite du parcours. Tant que cette valeur est suffisante, tous les conflits sont évités par ce moyen.\nLe décalage du temps de départ est une valeur stockée sur chaque arête et additionnée à la fin de la recherche de chemin.\nPar exemple :\nun train doit partir entre 10:00 et 11:00. La recherche commence avec un délai maximal de 1:00. Après quelques arêtes, une non-disponibilité est constatée 20 minutes après notre passage. La valeur passe donc à 20 minutes pour la suite du parcours. Le temps de départ est ensuite décalé de 5 minutes pour contourner un conflit, modifiant le décalage maximal à 15 minutes. Ce procédé continue jusqu’à arriver à la fin du trajet, ou jusqu’au point où il faut ajouter plus de délai. Marges de construction Quand la valeur de décalage maximal du temps de départ tombe à 0, il faut rajouter du délai entre deux points du parcours du train.\nLe principe est le même que pour régler les discontinuités de vitesse : le graphe est parcouru en arrière pour créer de nouvelles arêtes.\nLa marge de construction est une fonctionnalité du calcul de marche permettant d’ajouter un délai donné entre deux points du parcours.\nPost-processing Les marges de constructions étaient calculées pendant l’exploration du graph, mais ce procédé était trop couteux en temps de calcul. On effectuait des dichotomies sur des simulations qui pouvaient s’étendre sur des portions importantes du chemin.\nOn a seulement besoin de savoir si la marge de construction peut être réalisée sans provoquer de conflit. Des heuristiques peuvent être utilisées ici tant qu’on est plus restrictif que permissif : une marge impossible doit être identifiée comme telle, mais manquer une solution avec une marge extrêmement serrée n’est pas une mauvaise chose.\nMais avec ce changement, une fois qu’une solution est trouvée, il ne suffit plus de concaténer les résultats de simulation pour obtenir la simulation finale. On doit réaliser une simulation complète avec les vraies marges de construction qui évitent tout conflit. Cette étape se rejoint avec celle décrite pour les marges de régularité, qui est maintenant réalisée même sans marge de régularité spécifiée.\n","categories":"","description":"","excerpt":"En explorant le graphe, il arrive souvent de tomber sur des situations …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/conflict_avoidance/","tags":"","title":"Contourner les conflits"},{"body":"Le calcul de marche dans OSRD est un processus à 4 étapes, utilisant chacune le système d’enveloppes :\nConstruction du profil de vitesse le plus restrictif Ajout des différentes courbes de freinage Ajout des différentes courbes d’accélération et vérification des courbes de vitesse constante Application de marge(s)  \nCalcul du profil de vitesse le plus restrictif Une première enveloppe est calculée au début de la simulation en regroupant toutes les limites de vitesse statiques :\nvitesse maximale de la ligne vitesse maximale du matériel roulant limitations temporaires de vitesse (en cas de travaux sur une ligne par exemple) limitations de vitesse par catégorie de train limitations de vitesse selon la charge du train limitations de vitesse correspondant à des panneaux de signalisation La longueur du train est également prise en compte pour s’assurer que le train n’accélère qu’une fois sa queue ayant quitté la zone de plus faible vitesse. Un décalage est alors appliqué à la courbe en pointillée rouge. L’enveloppe résultante (courbe noire) est appelée MRSP (Most Restricted Speed Profile) correspondant donc au profil de vitesse le plus restrictif. C’est sur cette enveloppe que seront calculées les étapes suivantes.\nLa ligne pointillée rouge représente la vitesse maximale autorisée en fonction de la position. La ligne noire représente le MRSP où la longueur du train a été prise en compte.\nIl est à noter que les différentes envelopeParts composant le MRSP sont des données d’entrée, elles ne correspondent donc pas à des courbes avec une réalité physique.\nCalcul du profil de vitesse maximale En partant du MRSP, toutes les courbes de freinage sont calculées grâce au système d’overlay (voir ici pour plus de détails sur les overlays), c’est-à-dire en créant des envelopeParts qui seront plus restrictives que le MRSP. La courbe ainsi obtenue est appelée Max Speed Profile (profil de vitesse maximale). Il s’agit de l’enveloppe de vitesse maximale du train, tenant compte de ses capacités de freinage.\nEtant donné que les courbes de freinage ont un point de fin imposé et que l’équation de freinage n’a pas de solution analytique, il est impossible de prédire leur point de départ. Les courbes de freinage sont donc calculées à rebours en partant de leur point cible, c’est-à-dire le point dans l’espace où une certaine limite de vitesse est imposée (vitesse cible finie) ou le point d’arrêt (vitesse cible nulle).\nPour des raisons historiques en production horaire, les courbes de freinages sont calculées avec une décélération forfaitaire, dite décélération horaire (typiquement ~0,5m/s²) sans prendre en compte les autres forces. Cette méthode a donc également été implémentée dans OSRD, permettant ainsi de calculer les freinages de deux manières différentes : avec ce taux horaire ou avec une force de freinage qui vient simplement s’ajouter aux autres forces.\nCalcul du profil d’effort maximal Pour chaque point correspondant à une augmentation de vitesse dans le MRSP ou à la fin d’une courbe de freinage d’arrêt, une courbe d’accélération est calculée. Les courbes d’accélération sont calculées en tenant compte de toutes les forces actives (force de traction, résistance à l’avancement, poids) et ont donc un sens physique.\nPour les envelopeParts dont le sens physique n’a pas encore été vérifié (qui à ce stade sont les phases de circulation à vitesse constante, provenant toujours du MRSP), une nouvelle intégration des équations de mouvement est effectuée. Ce dernier calcul est nécessaire pour prendre en compte d’éventuels décrochages de vitesse dans le cas où le train serait physiquement incapable de tenir sa vitesse, typiquement en présence de fortes rampes (voir cet exemple).\nL’enveloppe qui résulte de ces ajouts de courbes d’accélérations et de la vérification des plateaux de vitesse est appelée Max Effort Profile (profil d’effort maximal).\nA ce stade, l’enveloppe obtenue est continue et a un sens physique du début à fin. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum. Le calcul de marche obtenu s’appelle la marche de base. Elle correspond au trajet le plus rapide possible pour le matériel roulant donné sur le parcours donné.\nApplication de marge(s) Après avoir effectué le calcul de la marche de base (correspondant au Max Effort Profile dans OSRD), il est possible d’y appliquer des marges (allowances). Les marges sont des ajouts de temps supplémentaire au parcours du train. Elles servent notamment à lui permettre de rattraper son retard si besoin ou à d’autres besoins opérationnels (plus de détails sur les marges ici).\nUne nouvelle enveloppe Allowances est donc calculée grâce à des overlays pour distribuer la marge demandée par l’utilisateur sur l’enveloppe d’effort maximal calculée précédemment.\nDans le calcul de marche d’OSRD, il est possible de distribuer les marges d’une manière linéaire, en abaissant toutes les vitesses d’un certain facteur, ou économique, c’est-à-dire en minimisant la consommation d’énergie pendant le parcours du train.\n","categories":"","description":"","excerpt":"Le calcul de marche dans OSRD est un processus à 4 étapes, utilisant …","ref":"/fr/docs/explanation/running_time_calculation/pipeline/","tags":"","title":"Le processus de calcul de marche"},{"body":"The walk calculation in OSRD is a 4-step process, each using the envelopes system:\nConstruction of the most restrictive speed profile Addition of the different braking curves Adding the different acceleration curves and checking the constant speed curves Application of allowance(s)  \nCalculation of the Most Restricted Speed Profile (MRSP) A first envelope is calculated at the beginning of the simulation by grouping all static velocity limits:\nmaximum line speed maximum speed of rolling stock temporary speed limits (e.g. in case of works on a line) speed limits by train category speed limits according to train load speed limits corresponding to signposts The length of the train is also taken into account to ensure that the train does not accelerate until its tail leaves the slowest speed zone. An offset is then applied to the red dashed curve. The resulting envelope (black curve) is called the Most Restricted Speed Profile (MRSP). It is on this envelope that the following steps will be calculated.\nThe red dotted line represents the maximum permitted speed depending on the position. The black line represents the MRSP where the train length has been taken into account.\nIt should be noted that the different envelopeParts composing the MRSP are input data, so they do not correspond to curves with a physical reality.\nCalculation of the Max Speed Profile Starting from the MRSP, all braking curves are calculated using the overlay system (see here for more details on overlays), i.e. by creating envelopeParts which will be more restrictive than the MRSP. The resulting curve is called Max Speed Profile. This is the maximum speed envelope of the train, taking into account its braking capabilities.\nSince braking curves have an imposed end point and the braking equation has no analytical solution, it is impossible to predict their starting point. The braking curves are therefore calculated backwards from their target point, i.e. the point in space where a certain speed limit is imposed (finite target speed) or the stopping point (zero target speed).\nFor historical reasons in hourly production, braking curves are calculated at SNCF with a fixed deceleration, the so-called hourly deceleration (typically ~0.5m/s²) without taking into account the other forces. This method has therefore also been implemented in OSRD, allowing the calculation of braking in two different ways: with this hourly rate or with a braking force that is simply added to the other forces.\nCalculation of the Max Effort Profile For each point corresponding to an increase in speed in the MRSP or at the end of a stop braking curve, an acceleration curve is calculated. The acceleration curves are calculated taking into account all active forces (traction force, driving resistance, weight) and therefore have a physical meaning.\nFor envelopeParts whose physical meaning has not yet been verified (which at this stage are the constant speed running phases, always coming from the MRSP), a new integration of the equations of motion is performed. This last calculation is necessary to take into account possible speed stalls in case the train is physically unable to hold its speed, typically in the presence of steep ramps (see this example).\nThe envelope that results from the addition of the acceleration curves and the verification of the speed plates is called the Max Effort Profile.\nAt this stage, the resulting envelope is continuous and has a physical meaning from start to finish. The train accelerates to the maximum, runs as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum. The resulting travel calculation is called the basic running time. It corresponds to the fastest possible route for the given rolling stock on the given route.\nApplication of allowance(s) After the calculation of the basic run (corresponding to the Max Effort Profile in OSRD), it is possible to apply allowances. Allowances are additions of extra time to the train’s journey. They are used to allow the train to catch up if necessary or for other operational purposes (more details on allowances here).\nA new Allowances envelope is therefore calculated using overlays to distribute the allowance requested by the user over the maximum effort envelope calculated previously.\nIn the OSRD running calculation it is possible to distribute the allowances in a linear way, by lowering all speeds by a certain factor, or in an economic way, i.e. by minimising the energy consumption during the train run.\n","categories":"","description":"","excerpt":"The walk calculation in OSRD is a 4-step process, each using the …","ref":"/en/docs/explanation/running_time_calculation/pipeline/","tags":"","title":"Pipeline"},{"body":"Architecture documents are meant to help understand how OSRD works overall.\n","categories":"","description":"Learn more about OSRD architecture","excerpt":"Learn more about OSRD architecture","ref":"/en/docs/reference/architecture/","tags":"","title":"Architecture"},{"body":"Les documents d’architecture permettent de comprendre comment OSRD fonctionne globalement.\n","categories":"","description":"Détails lié à l'architecture de OSRD","excerpt":"Détails lié à l'architecture de OSRD","ref":"/fr/docs/reference/architecture/","tags":"","title":"Architecture"},{"body":"Design documents are meant to help understand and participate in designing software.\nEach design document describes a number of things about a piece of software:\nits goals its constraints how its inputs and outputs were modeled how it works ","categories":"","description":"Learn more about how the software was designed","excerpt":"Learn more about how the software was designed","ref":"/en/docs/reference/design-docs/","tags":"","title":"Design documents"},{"body":"Les documents de conceptions décrivent comment et pourquoi un composant logiciel a été conçu, de l’exposition du problème à la solution technique, en passant par le chemin pris pour y arriver.\n","categories":"","description":"Détails liés à la conceptions de solutions techniques","excerpt":"Détails liés à la conceptions de solutions techniques","ref":"/fr/docs/reference/design-docs/","tags":"","title":"Documents de conception"},{"body":"Design specs General pitch Driver behavior modules are responsible for making driving decisions. Its main responsibility, given the state of the train and an instruction, is to react to the instruction. This reaction is expressed as a new train state.\nTo perform this critical task, it needs access to additional context:\nthe physical properties of the path, which are used to make coasting decisions, and to model natural forces. a slowdown coefficient, which is used to adjust how much the train is slowed down compared to a full power simulation. The driver behavior modules are supposed to have different implementations, which would interpret the slow down coefficient differently.\nAPI One driver behavior module is instantiated per driving instruction. It takes at initialization:\na slowdown coefficient the driving instruction the path properties It has two public methods:\nenact_decision(current_state: TrainState, t: float) -\u003e (TrainState, float)\nWhich returns what the next train state would be if there was only this one instruction to follow, and the time delta to reach this state.\ntruncate_integration_step(current_state: TrainState, potential_state: TrainState, t: float, dt: float) -\u003e (TrainState, float)\nWhich returns a state and time delta which respects the instruction, and is as close as possible to the potential state.\nLoop At a given train state, we know which driving instructions are enforced.\nFor each enforced driving instruction, we query the corresponding driver behavior module.\nThis gives a set of different train states. From this, we coalesce a single train state which respects all instructions.\nTo do so, we:\nFind the states which are most constraining for “constraining properties” (speed and pantograph state). Most constraining state regarding speed is the one with the lowest acceleration (taking sign into account). Most constraining state regarding pantograph state is the one which sets the pantograph down the earliest. Interpolate the constraining states to the smallest dt they are associated with. Merge the constraining states into a single potential state: for speed, we take the lowest acceleration for pantograph state, we take the earliest pantograph state other properties should be identical Submit the potential state for truncation to all driver behavior modules, chaining the outputs of truncate_integration_step. There is a heavy underlying assumption that “constraining properties” can be combined in a new state which is valid. This underlies the step 3. It is not yet clear if this assumption will always be valid in the future.\nAlso: what component should be in charge of instantiating all the driver behavior modules with the right implementation ?\nHere is a schema summarizing the process:\nA short case for why step 4 is needed. Here the constraints are in red, and the next state chosen by the driver behavior modules are in black.\nIn this example, the most constraining state is A, since it’s the one which accelerates the least. However, it overshoots constraint B, thus we need to select the state which respects both constraints.\nDecision process Unifying driver behavior and margin distribution algorithms When this design project started, driver behavior was left completely undefined. We assumed that a set of driving instructions can be unambiguously interpreted given a starting point. This assumption was then decided to be relied on to search which margin speed ceiling yields expected arrival times.\nWe also knew this assumption to be false: there are many ways instructions can be interpreted. Worse yet, different use cases for OSRD have different needs:\nsome users might want to reproduce existing timetables, which exhibit naive driver behavior: aggressive accelerations, aggressive breaking behavior. some users want to evaluate the feasibility of timetables, and thus want somewhat realistic driver behavior, with less aggressive acceleration and cautious breaking behavior. To resolve this tension, we thought of adding support for pluggable driver behavior. Doing so, however, would create two ways a timetable can be loosened (loose time):\nlowering the margin speed ceiling making driver behavior less aggressive Let’s say we want to loosen the timetable by 1 minute on a given section. It could be achieved by:\nlowering the speed ceiling using margins while keeping aggressive driver behavior making driving behavior very conservative, but using no margins at all lowering the speed ceiling a little, and making driving behavior a little more conservative any other combination of the two factors This is an issue, as it might make simulation results unstable: because there possibly are many ways to achieve the requested schedule, it would be very challenging to reliably choose a solution which matches expectations.\n❌ We considered ignoring the issue, as driver behavior was initially out of the scope of this design project. We decided not to, as we expected the cost of making later changes to integrate driver behavior to be significant. ✅ We decided to avoid this shortcoming by making margin distribution part of driver behavior. Driver behavior modules are controlled by a slowdown coefficient between 0 (loose as much time as shall be achieved) and 1 (loose no time). Interfacing driver behavior, driving instructions, and numerical integration Driver behavior can be formally modeled as a local decision function f, which takes the state of the train as an input, including position and speed, and returns an acceleration.\nTo best integrate this acceleration over the given time step, it is best not to use only the acceleration at (t). Since it may vary a lot along [t, t+dt]. To approximate the acceleration within this interval, we would need a better estimator, using a numerical method such as RK4. Such estimator then needs to call f multiple times.\nA number of questions came up:\nshould numerical integration within the driver behavior module, or outside are driver behavior modules queried about their reaction to a specific instruction, or in general does the driver behavior module return decisions, or parameters used to make decisions (such as curves) if decisions are returned, is it a force, an acceleration, or a new state if a new state is returned, how to deal with heterogenous time steps do we check decisions for correctness? that is, if a decision causes the train to overshoot a limit curve, do we do anything? Do we have a single DBM for all driving instructions, or one per driving instruction? We identified that this API choice shouldn’t constrain the implementation. We decided to go the conservative route and have one DBM per driving instructions as it reduces the API surface and relieves DBM from the responsibility of finding the most restrictive instruction.\nHow do we prevent overshooting? We identified that DBMs need the ability to follow internal target curves (distinct from limit curves).\nTo do so we could either:\nHave a way to short-circuit our integration scheme, to snap to target curves without overshooting. Accept oscillations around target curves (and thus overshooting). Setup a feedback loop mechanism to avoid overshooting. We decided that only the first option was desirable.\nThe design choices then are:\n❌ Make the DBM as close as possible to a decision function Then the DBM would not be aware of the time step it is called with, and would return an acceleration. Then the module should expose two methods:\nOne for taking decisions, akin to f.\nCalled several times depending on the integration method.\nOne for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves (for example MARECO which sets it’s own speed limits).\nCalled on the integration step results from this DBM, and the other DBMs integration step results.\n✅ The DBM returns a new state The module would then expose two methods:\nOne for taking decisions, which, given a train state and a desired/maximum time step, returns a new state (which does not overshoot) and a new current time.\nOne for correcting an integration step (i.e. a time step and a new state), if it happened to overshoot its internal goal curves (for example MARECO which sets it’s own speed limits).\nCalled only on other DBMs integration step results.\nHow do we combine the decisions from all DBMs? For each state property, find the most constraining value and dt. Find the smallest dt amongst constraining properties. Interpolate remaining properties to this dt, to build a provisional state. Submit this provisional state for truncation to all DBMs and take the truncation with the smallest dt. To understand how this algorithm is designed, we need to consider two example cases:\nFor steps 1 and 2: if a neutral zone and a breaking instruction overlap, both are most constraining to different state properties: the neutral zone affects pantograph state, and the breaking instruction affects speed. The final state has to be a combination of both. For step 3: We need to truncate integration steps to avoid overshoots, and thus avoid the need for feedback loops. Ideally, we want to truncate to the exact overshoot location. This overshoot location is not the same as the initial dt for the overshot constraint. Should truncate_integration_step depend on the driver behavior module? Yes: DBMs may use internal representations that the new state should not overshoot. For instance, when passed a driving instruction with a speed limit of 60km/h, a DBM wishing to lose time may reduce the speed to 50 km/h.\n","categories":"","description":"","excerpt":"Design specs General pitch Driver behavior modules are responsible for …","ref":"/en/docs/reference/design-docs/train-sim-v3/driver-behavior-modules/","tags":"","title":"Driver behavior modules"},{"body":"Une des ambitions d’OSRD est d’aider à la planification horaire à l’échelle européenne.\nPour atteindre cet objectif, OSRD doit tenir compte des spécificités locales en consultant et collaborant avec les compagnies ferroviaires et les gestionnaires d’infrastructure.\nEn échange de leur contribution, ces entreprises :\nProfitent des efforts de développement commun ; Peuvent se baser sur les outils communs pour créer les leurs1 ; Participent à la feuille de route et à la direction technique du projet à la mesure de leur contribution. OSRD est actuellement développé par:\nune équipe de développeurs à plein temps au sein de SNCF Réseau, grâce à un financement de SNCF Réseau, de l’Etat Français et de l’Union Européenne ; des contributeurs individuels. L’association Open Rail La association Open Rail est une association à but non lucratif en cours de création ayant pour objectif d’organiser le travail autour d’outils logiciels communs au monde du ferroviaire.\nTant qu’elles ne modifient pas les outils communs sans partager leurs améliorations, voir les détails de la license LGPLv3. ↩︎\n","categories":"","description":"Organisation et gouvernance d'OSRD","excerpt":"Organisation et gouvernance d'OSRD","ref":"/fr/about/governance/","tags":"","title":"Gouvernance"},{"body":"One of the ambitions of OSRD is to help with timetabling on a European scale.\nTo reach this goal, OSRD has to take local features into account by consulting and collaborating with railway companies and infrastructure operators.\nAnd by contributing to OSRD, these companies:\nProfit from all the common development efforts Can freely build on the common effort to achieve their own goals1 Participate in the roadmap and technical direction of the project to the extent of their contribution OSRD is currently developed by:\nA team of full-time developers at SNCF Réseau, financed by SNCF Réseau, the French state and the European Union Individual contributors The OpenRail association The OpenRail association is an upcoming non-profit committed to organizing cooperative work around railway software tools.\nAs long as they don’t modify the common tools without sharing their improvements. See the details of the LGPLv3 license. ↩︎\n","categories":"","description":"Governance and organization of OSRD","excerpt":"Governance and organization of OSRD","ref":"/en/about/governance/","tags":"","title":"Governance"},{"body":"Netzgrafik-Editor (NGE) is an open-source software that enables the creation, modification, and analysis of regular-interval timetable, at a macroscopic level of detail, developed by Swiss Federal Railways (SBB CFF FFS). See front-end and back-end repositories.\nOSRD (microscopic level of detail, trains scheduled once, based on a defined infrastructure, depicts a timetable) and NGE (macroscopic level of detail, regular-interval based train runs, no infrastructure, depicts a transportation plan) are semantically different, but close enough to make it work together. The compatibility between NGE and OSRD has been tested through a proof of concept, by running both pieces of software as separate services and without automated synchronization.\nThe idea is to give to OSRD a graphical tool to edit (create, update and delete train schedules from) a timetable from an operational study scenario, and get some insights on analytics at the same time. The second benefit of using both microscopic and macroscopic level of detail is that OSRD microscopic calculations can be propagated in NGE to enhance the level of detail of it.\nThe transversal objective of this feature is to make 2 open-source projects from 2 big infrastructure managers work along and cooperate with one another with the same goals.\n1 - Integration in OSRD Therefore, NGE is integrated in the operational studies section of OSRD, in an iframe. An alternative way to deal with the integration would have been to refactor NGE as web-components, thus easy to import in OSRD, but this solution has been abandoned, because of the quantity of refactoring that would have been needed. This iframe points to osrd-nge, a minimalist Angular app that embed the actual NGE app. It can also be seen as a wrapper of the actual NGE app. osrd-nge then customizes the actual NGE app with specific parameters and functionalities:\na standalone flag: to tell NGE to disable all back-end interactions (no database on NGE side) to tell NGE to disable some UI components (authentication, project management, versioning system view, etc.) implementation of a communication interface between OSRD and NGE (message_event, eventListener and postMessage). NGE is then able to get the OSRD timetable as soon as a change is made on OSRD side, and OSRD is able to get the changes made on NGE side.\nThe following diagram shows the workflow between the components.\n--- title: OSRD - NGE Sequence diagram --- sequenceDiagram autonumber OSRD (parent window)--\u003e\u003eOSRD (parent window): init web page OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") loop while synchronization is ON alt any modification in OSRD (parent window) OSRD (parent window)--\u003e\u003eOSRD (parent window): any modification OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") else any modification in NGE (osrd-nge iframe) NGE (osrd-nge iframe)--\u003e\u003eNGE (osrd-nge iframe): any modification \u003cbr\u003e(hooks) NGE (osrd-nge iframe)-\u003e\u003eOSRD (parent window): parent.window.postMessage(nge_action, \"*\") OSRD (parent window)--\u003e\u003eOSRD (parent window): convert NGE action into \u003cbr/\u003etimetable update OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") end end Since OSRD is the only source of truth (= data source), NGE has to be updated as the very last action, to be aligned with the timetable current state, and to get the updated microscopic calculations from OSRD.\nMore precisely, when a change is made in NGE:\n--- title: OSRD - NGE Communication when modification in NGE --- sequenceDiagram autonumber NGE (nge-app)--\u003eNGE (osrd-nge): osrd-nge listens on hooks \u003cbr\u003efrom nge-app NGE (osrd-nge)-\u003e\u003eNGE (osrd-nge): (eventListeners) \u003cbr\u003e callback triggered NGE (osrd-nge)-\u003e\u003eOSRD (front-end): (callback functions) \u003cbr\u003eparent.window.postMessage(nge_action, \"*\") OSRD (front-end)-\u003e\u003eOSRD (front-end): (eventListeners) \u003cbr\u003e convert nge_action \u003cbr\u003e into timetable update OSRD (front-end)-\u003e\u003eOSRD (back-end): call for update timetable OSRD (back-end)-\u003e\u003eOSRD (front-end): update timetable OSRD (front-end)-\u003e\u003e OSRD (front-end): convert timetable into \u003cbr\u003e nge_light_model OSRD (front-end)-\u003e\u003eNGE (osrd-nge): iframe.contentWindow.postMessage(nge_light_model, \"*\") NGE (osrd-nge)-\u003e\u003eNGE (osrd-nge): (eventListener) \u003cbr\u003e onLoad triggered NGE (osrd-nge)-\u003e\u003eNGE (nge-app): (callback function) \u003cbr\u003e onLoad(nge_light_model, ...) 2 - Converters To overpass the semantic differences and make the data models fit, 2 converters have to be implemented:\n[OSRD -\u003e NGE] a converter that transforms an OSRD timetable into an NGE model [OSRD \u003c- NGE] an event handler, that transforms NGE action into OSRD database update on timetable 3 - Open-source (cooperation / contribution) To make NGE compatible with OSRD, some changes have been requested (disable back-end, create hooks on events) and directly implemented in the official repository of NGE, with the agreement and help of NGE team.\nContributions for one project to another, from both sides, are valuable and will be entertained in the future.\nThis feature also shows that open-source cooperation is powerful and a huge gain of time in software development.\n","categories":"","description":"Open-source software developed by SBB CFF FFS and its integration in OSRD","excerpt":"Open-source software developed by SBB CFF FFS and its integration in …","ref":"/en/docs/explanation/netzgrafik-editor/","tags":"","title":"Netzgrafik-Editor"},{"body":"Netzgrafik-Editor (NGE) est un logiciel open-source qui permet la création, la modification et l’analyse d’horaires à intervalles réguliers, à un niveau de détail macroscopique, développé par les Chemins de Fer Fédéraux suisses (SBB CFF FFS). Voir les dépôts front-end et back-end\nOSRD (niveau de détail microscopique, trains à occurence unique, basé sur une infrastructure définie, représente une grille horaire) et NGE (niveau de détail macroscopique, courses de trains à intervalles réguliers, sans infrastructure, représente un plan de transport) sont sémantiquement différents, mais suffisamment proches pour fonctionner ensemble. La compatibilité entre NGE et OSRD a été testée à travers une preuve de concept, en exécutant les deux applications comme services distincts sans synchronisation automatisée.\nL’idée est de fournir à OSRD un outil graphique pour éditer (créer, mettre à jour et supprimer les horaires des trains) un horaire à partir d’un scénario d’étude opérationnelle, et obtenir en même temps des informations analytiques. Le deuxième avantage de l’utilisation des niveaux de détail microscopique et macroscopique est que les calculs microscopiques d’OSRD peuvent être propagés dans NGE pour améliorer son niveau de détail.\nL’objectif transversal de cette fonctionnalité est de faire collaborer deux projets open-source de deux grands gestionnaires d’infrastructure pour atteindre des objectifs communs.\n1 - Intégration dans OSRD Ainsi, NGE est intégré dans la section des études opérationnelles d’OSRD, dans un iframe. Une alternative pour répondre au problème d’intégration aurait été de refacto NGE en web-components, pour les importer facilement dans OSRD, mais cette solution a été abandonnée compte tenu de la quantité de refacto que cela représenterait. Cet iframe pointe vers osrd-nge, une application Angular minimaliste qui intègre l’application NGE réelle. Il peut également être vu comme un conteneur de l’application NGE réelle. osrd-nge personnalise ensuite l’application NGE réelle avec des paramètres et des fonctionnalités spécifiques :\nun drapeau standalone : pour indiquer à NGE de désactiver toutes les interactions back-end (pas de base de données côté NGE) pour indiquer à NGE de désactiver certains composants de l’interface utilisateur (authentification, gestion de projet, vue du système de versionnage, etc…) implémentation d’une interface de communication entre OSRD et NGE (message_event, eventListener and postMessage). NGE est alors capable d’obtenir la grille horaire OSRD dès qu’un changement est effectué du côté d’OSRD, et OSRD est capable d’obtenir les modifications effectuées du côté de NGE.\nLes diagrammes suivants montrent workflow entre les composants.\n--- title: OSRD - NGE Sequence diagram --- sequenceDiagram autonumber OSRD (parent window)--\u003e\u003eOSRD (parent window): initialisation de la page web OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") loop while synchronization is ON alt any modification in OSRD (parent window) OSRD (parent window)--\u003e\u003eOSRD (parent window): modification OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") else any modification in NGE (osrd-nge iframe) NGE (osrd-nge iframe)--\u003e\u003eNGE (osrd-nge iframe): modification \u003cbr\u003e(hooks) NGE (osrd-nge iframe)-\u003e\u003eOSRD (parent window): parent.window.postMessage(nge_action, \"*\") OSRD (parent window)--\u003e\u003eOSRD (parent window): convertion d'une action NGE en \u003cbr/\u003emodification de la grille horaire OSRD (parent window)-\u003e\u003eNGE (osrd-nge iframe): iframe.contentWindow.postMessage(nge_light_model, \"*\") end end Étant donné qu’OSRD est la seule source de vérité (= source de données), NGE doit être mis à jour en dernière action, pour être aligné avec l’état actuel de la grille horaire et obtenir les calculs microscopiques mis à jour d’OSRD.\nPlus précisément, lorsqu’un changement est effectué dans NGE :\n--- title: OSRD - NGE Communication when modification in NGE --- sequenceDiagram autonumber NGE (nge-app)--\u003eNGE (osrd-nge): osrd-nge écoute sur les hooks \u003cbr\u003ede nge-app NGE (osrd-nge)-\u003e\u003eNGE (osrd-nge): (eventListeners) \u003cbr\u003e callback déclenché NGE (osrd-nge)-\u003e\u003eOSRD (front-end): (callback functions) \u003cbr\u003eparent.window.postMessage(nge_action, \"*\") OSRD (front-end)-\u003e\u003eOSRD (front-end): (eventListeners) \u003cbr\u003e converti nge_action \u003cbr\u003e en modification de la grille horaire OSRD (front-end)-\u003e\u003eOSRD (back-end): appel pour modifier la grille horaire OSRD (back-end)-\u003e\u003eOSRD (front-end): modifie la grille horaire OSRD (front-end)-\u003e\u003e OSRD (front-end): converti la grille horaire en\u003cbr\u003e nge_light_model OSRD (front-end)-\u003e\u003eNGE (osrd-nge): iframe.contentWindow.postMessage(nge_light_model, \"*\") NGE (osrd-nge)-\u003e\u003eNGE (osrd-nge): (eventListener) \u003cbr\u003e onLoad déclenché NGE (osrd-nge)-\u003e\u003eNGE (nge-app): (callback function) \u003cbr\u003e onLoad(nge_light_model, ...) 2 - Convertisseurs Pour surpasser les différences sémantiques et adapter les modèles de données, deux convertisseurs doivent être implémentés :\n[OSRD -\u003e NGE] un convertisseur qui transforme une grille horaire OSRD en un modèle NGE [OSRD \u003c- NGE] un gestionnaire d’événements, qui transforme une action NGE en mise à jour de la base de données OSRD sur la grille horaire 3 - Open-source (coopération / contribution) Pour rendre NGE compatible avec OSRD, certaines modifications ont été demandées (désactivation du back-end, création de hooks sur les événements) et directement implémentées dans le répertoire officiel de NGE, avec l’accord et l’aide de l’équipe NGE.\nLes contributions d’un projet à l’autre, de part et d’autre, sont précieuses et seront encouragées à l’avenir.\nCette fonctionnalité montre également que la coopération open-source est puissante et constitue un gain de temps considérable dans le développement de logiciels.\n","categories":"","description":"Logiciel open-source développé par SBB CFF FFS et son intégration dans OSRD","excerpt":"Logiciel open-source développé par SBB CFF FFS et son intégration dans …","ref":"/fr/docs/explanation/netzgrafik-editor/","tags":"","title":"Netzgrafik-Editor"},{"body":"Le modèle de simulation définit le rôle et comportement des différents objets simulés au sein d’OSRD.\nCette modélisation est un compromis entre de multiples enjeux:\nfidélité de la simulation interprétabilité des résultats adaptabilité du modèle à différentes technologies et usages, que cela soit en terme de signalisation, de poste d’aiguillage, ou d’usage des données En particulier, certaines subtilités propres aux systèmes pratiques ont été sacrifiées sur l’autel de la compatibilité et de l’interprétabilité:\nun signal doit forcément s’addresser à un train en particulier: les signaux n’ont pas d’aspect par défaut; ils n’existent que pour être vus les itinéraires / routes sont formées à destination d’un train en particulier Ce document est une description du modèle de fonctionnement cible d’OSRD. Il a pour objectif de renseigner développeurs et experts métiers sur le fonctionnement du simulateur. Des changements y sont apportés au fil de l’évolution du projet.\nCe modèle est en cours d’implémentation\nArchitecture flowchart TD %%%% NODES train[Train] %% ↓ signaling[Signalisation] %% ↓ routing[Routage] ordering[Ordonnancement] %% ↓ reservation[Réservation] %% ↓ location[Localisation] movable-elements[\"Éléments mobiles\"] %%%% EDGES train -- réagit à --\u003e signaling train -- réclame les itinéraires --\u003e ordering ordering -- commande --\u003e routing signaling -- observe --\u003e reservation routing -- observe et réserve --\u003e reservation reservation -- observe --\u003e location reservation -- actionne --\u003e movable-elements train -- informe --\u003e location %%%% CLICKABLE LINKS click train href \"./train/\" _self click ordering href \"./ordering/\" _self click signaling href \"./signaling/\" _self click routing href \"./routing/\" _self click reservation href \"./reservation/\" _self click location href \"./location/\" _self click movable-elements href \"./movable-elements/\" _self Pistes d'évolution Gestion des overlaps Remerciements Par ordre alphabétique:\nChristophe Mémin Djamal Bellebia Gilles Dessagne Nathanaël Dias ","categories":"","description":"Décrit le fonctionnement du poste d'aiguillage virtuel","excerpt":"Décrit le fonctionnement du poste d'aiguillage virtuel","ref":"/fr/docs/reference/design-docs/interlocking/","tags":"","title":"Poste d'aiguillage"},{"body":"Les guides de référence technique contiennent des références techniques pour les API et autres aspects de la machinerie OSRD. Ils présentent son fonctionnement et la manière de l’exploiter en partant du principe que les concepts clés de base sont maîtrisés.\n","categories":"","description":"Machinerie interne et APIs","excerpt":"Machinerie interne et APIs","ref":"/fr/docs/reference/","tags":"","title":"Référence technique"},{"body":"Description Les routes ont pour responsabilité d’autoriser le déplacement des trains dans l’infrastructure. Elles doivent se terminer à un point où l’arrêt du train est prévu (en terme de signalisation, pas voyageur). Les routes sont assimilables à des itinéraires, ou à des suites d’itinéraires et d’installations de pleine voie. Les routes n’ont pas de lien direct avec le cantonnement et la signalisation. Elles nourrissent des informations sur la disponibilité des voies qui sont utilisées par le cantonnement et la signalisation. Une route est un chemin de détecteur en détecteur. Elle représente une portion de chemin qu’il est sûr pour un train d’emprunter. Les routes ont des points de libération, qui sont des détecteurs qui délimitent quand détruire l’itinéraire, ce qui permet d’implémenter transit souple, rigide, et entre-deux. Une route peut être à nouveau formée alors qu’un train est déjà en train de la parcourir. Cela permet à plusieurs trains de se suivre sur la même route. Cycle de vie d’une route Les routes n’ont pas d’état, mais leur commande donne lieu à une suite d’événements systématique :\nle système commande toutes les routes sur le trajet du train dans l’ordre, sans attendre la commande doit être acceptée par le régulateur lorsque le régulateur accepte la commande, la formation commence le droit d’action de chaque zone de la route est acquis, selon un ordre global en parallèle pour toutes les zones: si la zone n’est pas dans la configuration souhaitée: si elle est déjà réservée, attendre que les réservations expirent sinon, la mettre dans la configuration souhaitée en déplaçant les aiguilles pré-réserver la zone pour le passage du train le droit d’action de la zone est cédé une fois que la formation est terminée, la route est établie pour chaque zone, transformer la pré-réservation du train en réservation dès que la route est établie, un processus de destruction de la route commence pour chaque zone de la route donnant lieu à une libération attendre que le train quitte la zone (que la réservation passe de l’état OCCUPIED à l’état PENDING_RELEASE) libérer la réservation des zones du début de la route jusqu’à la zone actuelle Piste d'évolution Certains postes d’aiguillages ont un enclenchement entre itinéraires de sens contraire (affrontement) qui empêche l’activation d’une route en menant à une zone avec un transit en sens contraire. Il serait envisageable de réserver une zone supplémentaire à la fin du chemin protégé par la route, par sécurité. Piste d'évolution Certains itinéraires en gare ne permettent pas le partage du chemin par plusieurs trains Piste d'évolution En pratique, il pourrait être intéressant d’introduire une notion de route partielle afin de réduire le nombre de routes nécessaires: une route partielle est une portion de route qu’il n’est pas sûr d’activer indépendament. Exigences de conception Le système doit, indirectement ou directement:\npermettre à la signalisation de déterminer si une section de voie est prête à être empruntée. permettre l’ordonnancement des trains selon des critères configurables. permettre la destruction progressive (transit souple) de l’itinéraire après le passage du train. il doit être possible d’avoir plusieurs processus de commande actifs au même moment pour la même route, afin de supporter des trains qui se suivent Dépendances statique le chemin des routes de détecteur à détecteur\nstatique la position requise des aiguilles, par zone\nstatique les points de libération des zones (qui implémentent le transit souple / rigide)\ndynamique régulateur soumettre des commandes\ndynamique réservation acquérir et relacher un droit d’action par zone\ndynamique réservation attendre que les réservations d’une zone expirent\ndynamique éléments mobiles déplacer des aiguilles\ndynamique réservation pré-réserver une zone\ndynamique réservation promouvoir une pré-réservation en réservation\ndynamique réservation lors de la destruction de la route, attendre qu’une réservation passe en PENDING_RELEASE\ndynamique réservation libérer une réservation\nOpérations commander une route: démarre un processus asynchrone qui ne se terminera que lorsque la route aura été établie. Un processus de destruction doit démarrer dès que la route est établie. Notes de conception Ces notes permettent d’expliquer les décisions qui ont été prises, afin de pouvoir plus aisément les comprendre et évoluer.\nInformer la signalisation Sachant que:\nil peut y avoir beaucoup de zones partant d’un même point, il est préférable d’éviter de contraindre les signaux à observer une liste de routes il est potentiellement difficile d’associer un état clair à chaque route Il en ressort plusieurs manières d’informer la signalisation de la navigabilité des voies:\nsoit directement, en faisant observer à la signalisation les points d’entrée des routes. Si plusieurs routes partent du même endroit, elles partageraient un objet entrée: moins de complexité dans la couche de réservation, plus de complexité dans la couche de routage soit indirectement, via la couche de réservation des zones, qui auraient un état supplémentaire pour marquer leur navigabilité: moins de complexité dans la couche de routage, plus de complexité dans la couche de réservation avantage le processus d’activation des routes n’aurait pas besoin d’attendre l’arrivée du train, la couche de réservation s’en occuperait. avantage découplage entre routage et cantonnement / signalisation. La seconde option a été choisie, car :\nelle permet d’avoir un couplage moins fort entre la signalisation et les routes. elle évite aussi au processus d’activation des routes d’attendre le passage du train alors que la couche de réservation le fait déjà. Cycle de vie des routes et état des zones Plusieurs enjeux motivent le cycle de vie des routes et l’état des zones :\nd’une part, l’état des zones est au coeur de la détection de conflit : il doit être possible d’extraire d’une simulation d’un train seul ses besoins en ressources d’autre part, il faut qu’une simulation multi-train fonctionne correctement : le temps de déplacement des aiguilles selon la configuration actuellement en place, en particulier, est un point de friction important ","categories":"","description":"Gère le cycle des routes","excerpt":"Gère le cycle des routes","ref":"/fr/docs/reference/design-docs/interlocking/routing/","tags":"","title":"Routage"},{"body":"Technical reference guides contain technical reference for APIs and other aspects of OSRD’s machinery. They describe how it works and how to use it but assume that you have a basic understanding of key concepts.\n","categories":"","description":"Internal machinery and APIs","excerpt":"Internal machinery and APIs","ref":"/en/docs/reference/","tags":"","title":"Technical reference"},{"body":"\n","categories":"","description":"OSRD's data-flow diagram","excerpt":"OSRD's data-flow diagram","ref":"/en/docs/reference/architecture/data_flow/","tags":"","title":"Data-flow"},{"body":"\n","categories":"","description":"Schéma des flux des données d'osrd","excerpt":"Schéma des flux des données d'osrd","ref":"/fr/docs/reference/architecture/data_flow/","tags":"","title":"Flux des données"},{"body":"It is a multi-service architecture where several software components interact with each other. This choice was made to ensure the modularity of the code and to guarantee the exploitability of certain OSRD services by external applications.\nValkey is configured as maxmemory-policy=allkeys-lru (documentation) Osrdyne has multiple drivers to support: k8s docker process compose The gateway supports multiple authentication providers: OpenID Connect (OIDC) Bearer token Mock (for development purpose) Some editoast endpoints requires an InfraCache object which make them stateful. These endpoints are only used in the editoast-stateful service. Doing so most endpoints are run by a scalable service. Coming soon:\nAdapt editoast-stateful so editoast is fully scalable. ","categories":"","description":"OSRD's services architecture","excerpt":"OSRD's services architecture","ref":"/en/docs/reference/architecture/services/","tags":"","title":"Services"},{"body":"Description The signaling layer includes all signals, which respond to track occupancy and reservation. Signals can be of different types, and are modularly loaded. Only their behavior towards the state of the infrastructure and the train’s reaction to signaling matters.\nSignals are connected to each other by blocks. Blocks define paths permitted by signaling.\nGoals The signaling system is at the crossroads of many needs:\nit must allow for realistic signaling simulation in a multi-train simulation it must allow the conflict detection system to determine which resources are required for the train it must allow application users to edit and display signals it must allow for visualization of signals on a map it must allow for automated import from existing databases Design requirements: All static data:\nmust enable the front-end to display the signals must enable the infrastructure editor to configure signals must enable the back-end to simulate signals must be close to realistic industry models must allow for the modeling of composite signals, which carry several logical signals within a single physical signal To simulate signaling:\nblocks must be generated for both user convenience and pathfinding for each signal, its next compatible signal and protected zones must be deduced the minimum necessary information must be provided to the signaling modules for their operation enable using signaling modules without instantiating a complete simulation allow for signals to be loaded in any order, in parallel For speed limits:\nsome speed limits have to be enforced depending on the train path’s routes speed limits can be configured to have an impact on signaling ability to link the reaction of the train to a signal, and a speed limit Assumptions Each physical signal can be decomposed into a list of logical signals, all of which are associated with a signaling system. Blocks have a type. It is possible to compute, given a signal alone, its block and route delimiting properties. Blocks never cross route boundaries. Blocks which are not covered by routes do not exist, or can be ignored. At any time, trains only use one signaling system capable of transmitting movement authority. Speed limits change depending on which route is in use, and affect how signals behave Some speed limits have an impact on signaling, and some do not Either a speed limits differentiates per train category, or requires dynamic signaling, but not both Operations Instantiating a view creates a framework for observing signals Planning the path signals to the view the blocks that the train will traverse Observing a signal subscribe to the state of a signal (through the view) Passing a signal signals that a signal has been passed by the train (through the view) Research Questions Are there any blocks that overlap the end of a route? SNCF(Loïc): No. Are there any signals which rely on the state of the one after next signal? SNCF(Loïc): No. Are there signals that change behavior based on the active block in front of them? SNCF(Loïc): Yes, for slowdowns. Are there signals that are the start of blocks of different types? SNCF(Loïc): Yes. Can the behavior of a signal depend on which block is active after the end of the current block? SNCF(Loïc): Yes, with slowdowns or blinking yellow. Do some signaling systems need additional information in the blocks? SNCF(Loïc): Kind of, there are slowdowns, but it’s not specifically carried by the block. Is it nominal for a train to have multiple active signaling systems at the same time? SNCF(Loïc): No. are there any signals which depend on which route is set, but are not route delimiters? SNCF(Loïc): Yes, see Sémaphore Clignotant how do speed limits per train category and dynamic signaling interact? SNCF(Nicolas): There shouldn’t be any speed limit per category signaled by dynamic signaling are there any signals which depend on the state of multiple routes? SNCF(Loïc): No ","categories":"","description":"Describes the signaling model","excerpt":"Describes the signaling model","ref":"/en/docs/reference/design-docs/signaling/","tags":"","title":"Signaling"},{"body":" This document is a work in progress\nConflict detection is the process of looking for timetable conflicts. A timetable conflict is any predictable condition which disrupts planned operations. Planned operations can be disrupted if a train is slowed down, prevented from proceeding, or delayed.\nOne of the core features of OSRD is the ability to automatically detect some conflicts:\nspacing conflicts: insufficient spacing between trains sharing the same path routing conflicts: insufficient spacing between trains with intersecting paths Some other kinds of conflicts may be detected later on:\nmaintenance conflicts: planned maintenance disrupts the path of a train power delivery conflicts: combined power delivery requirements exceeds capacity Conflict detection relies on interlocking and signaling modeling and simulation to:\nfigure out what each actor requires to perform its duty undisturbed detect conflicting requirements Design constraints The primary design goals are as follows:\nenable threading new train paths into an existing timetable (see STDCM) produce conflicts which can be linked back to a root cause operate in way that can be visualized and interpreted scale to real world timetables: millions of yearly trains, tens of thousands of daily trains In addition to these goals, the following constraints apply:\nit must be possible to thread new train paths into timetables with existing conflicts it must not cause false-negatives: if no conflicts are detected, a multi-train simulation of the same timetable must not yield any slowdowns it cannot rely on data we do not have it has to enable later support of mobile block systems it has to rely on existing signaling and interlocking simulation it has to enable detecting conflicts regardless of the signaling system in use it has to support transitions between signaling systems it has to support conflicts between different signaling systems Conflict modeling Actors are objects which cause resources to be used:\ntrain paths (or someone / something on the behalf of the train) maintenance work Actors need resources to be available to proceed, such as:\nzones, which have one state per way to traverse it switches, which have one state per position station platforms, which could be used to prevent two large trains from occupying both sides of a tiny platform Actor emit resource requirements, which:\ndescribe the need of an actor for a resource, for a given time span describe what the resource is needed for detail how the resource is used, such as switch position, zone entry and exit Resource requirements can turn out to be either satisfied or conflicting with other requirements, depending on compatibility rules.\nCompatibility rules differ by requirement purpose and resource type. For example:\nspacing requirements are exclusive: simultaneous requirements for the same resource are conflicting zone and switch requirements are shareable: simultaneous requirements are satisfied if the resource configuration is identical For conflict detection to work, resource requirements have to be at least as extensive as what’s required to guarantee that a train path will not be disturbed.\nRouting conflicts Context For trains to proceed safely along their planned path:\nswitches have to be moved in the appropriate position level crossings have to activate risks of collision with other trains have to be mitigated In practice, the path of trains is partitioned into routes, which when set, ensure a train can safely follow the route.\nRoutes have the following lifestyle:\nAs a train approaches the start of one of its routes, it is called by an operator. If all resources required to safely use the route are available, switches and level crossings start to move. If a resources is not available, e.g. because another train has reserved a section of track, this process is delayed until all conditions are met. Once all resources are configured and reserved, the route is set and ready to be followed. Before that point, the entry of the route was protected by signaling, which prevented the train from moving past the entry point. As the train moves along the route, it is destroyed. When the tail of the trail releases key detectors along the route, resources before this detector are released, and can this be reserved by other routes. For a train to proceed through a route unimpeded, the following things have to happen:\nThe route has to be set before the train arrives, and before it is slowed down by signaling. The route has to be called, so that is it set in time. All resources required for the route to start setting at call time have to be available. Generating requirements struct RouteRequirement { route: RouteId, set_deadline: Time, zone_requirements: Vec\u003cRouteZoneRequirement\u003e, } struct RouteZoneRequirement { zone: ZoneId, entry_det: DirDetectorId, exit_det: DirDetectorId, release_time: Time, switches: Map\u003cSwitchId, SwitchConfigId\u003e, } Routing requirements are generated by the following algorithm:\nCompute the set deadline using signaling simulation. The set deadline is the point in time at which the train would be slowed down if the route were not set. For each zone in each route, simulate when it would be released, and thus not required anymore. Route overlaps are not yet supported.\nRequirement compatibility rules Requirement compatibility is evaluated for all RouteZoneRequirements, grouped by zone. Requirements A and B, ordered such that A.set_deadline \u003c= B.set_deadline, are compatible if and only if either:\ntheir active time span does not overlap, such that A.release_time \u003c= (B.set_deadline - activation_time), where the activation time is the delay required to reconfigure from A.switches to B.switches. (A.entry_det, A.exit_det, A.switches) == (B.entry_det, B.exit_det, B.switches) Spacing conflicts Context Even if interlocking mitigates some of the risks associated with operating trains, a major one is left out: head to tail collisions, caused by insufficient spacing.\nThis responsibility is handled by signaling, which conveys both interlocking and spacing constraints.\nSignaling helps trains slow down until the end of their movement authority, which is either:\nbehind the tail of the next train at the end of the last route set for this train Spacing requirements are emitted for zones which if occupied, would cause a slowdown, and zones occupied by the train\nGenerating requirements struct SpacingRequirement { zone: ZoneId, begin_time: Time, end_time: Time, } Every time the driver sees a signal, generate updated spacing requirements by calculating which zones, if occupied, would trigger a slowdown:\nstart by assuming the zone just after the head of the train is occupied until the train is not slowed down, move the occupied section one zone further away from the train Requirement compatibility rules Requirement compatibility is evaluated for all SpacingRequirements, grouped by zone.\nRequirements A and B are compatible if and only if their [begin_time, end_time] ranges do not overlap.\nIncremental requirement generation Routing requirements sequenceDiagram participant client as Client participant gen as Routing resource generator client -\u003e\u003e gen: initial path + train movement loop gen -\u003e\u003e client: prefix path extension needed client -\u003e\u003e gen: extra prefix path + train movement end gen -\u003e\u003e client: resource requirements After an initial path is given, the requirement generator can ask for more prefix path (before the start of the route). The client responds with:\nthe extra prefix path the movement of the train over time on the given prefix path If the initial path has multiple routes, the last route is the one resource requirements are emitted for.\nSpacing requirements sequenceDiagram participant client as Client participant gen as Spacing resource generator client -\u003e\u003e gen: initial path + train movement loop gen -\u003e\u003e client: postfix path extension needed client -\u003e\u003e gen: extra postfix path end gen -\u003e\u003e client: resource requirements After an initial path is given, the requirement generator can ask for more postfix path (before the start of the route).\nVisualizing requirements Full-page requirements diagram\n","categories":"","description":"Detect unrealistic timetables","excerpt":"Detect unrealistic timetables","ref":"/en/docs/reference/design-docs/conflict-detection/","tags":"","title":"Conflict detection"},{"body":" This work is pending implementation, and has not yet been adjusted to reflect potential required adjustments.\nThese articles describe the design of the new train simulation system.\nThis system should be simpler and more stable than the current one, and should enable more advanced features in the future.\n","categories":"","description":"Modeling and API design of train simulations","excerpt":"Modeling and API design of train simulations","ref":"/en/docs/reference/design-docs/train-sim-v3/","tags":"","title":"Train simulation v3"},{"body":" The purpose of allowances As explained in the calcul du Max Effort Profile, the basic running time represents the most stretched run normally achievable, i.e. the fastest possible run of the given equipment on the given route. The train accelerates to the maximum, travels as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum.\nThis basic run has a major disadvantage: if a train leaves 10 minutes late, it will arrive at best 10 minutes late, because by definition it is impossible for it to run faster than the basic run. Therefore, trains are scheduled with one or more allowances added. The allowances are a relaxation of the train’s route, an addition of time to the scheduled timetable, which inevitably results in a lowering of running speeds.\nA train running in basic gear is unable to catch up!\nAllowances types There are two types of allowances:\nThe regularity allowance: this is the additional time added to the basic running time to take account of the inaccuracy of speed measurement, to compensate for the consequences of external incidents that disrupt the theoretical run of trains, and to maintain the regularity of the traffic. The regularity allowance applies to the whole route, although its value may change at certain intervals. The construction allowance: this is the time added/removed on a specific interval, in addition to the regularity allowance, but this time for operational reasons (dodging another train, clearing a track more quickly, etc.) A basic running time with an added allowance of regularity gives what is known as a standard walk.\nAllowance distribution Since the addition of allowance results in lower speeds along the route, there are a number of possible routes. Indeed, there are an infinite number of solutions that result in the same journey time.\nAs a simple example, in order to reduce the running time of a train by 10% of its journey time, it is possible to extend any stop by the time equivalent to this 10%, just as it is possible to run at 1/1.1 = 90.9% of the train’s capacity over the entire route, or to run slower, but only at high speeds…\nThere are currently two algorithms for margin distribution in OSRD: linear and economic.\nLinear distribution Linear allowance distribution is simply lowering the speeds by the same factor over the area where the user applies the allowance. Here is an example of its application:\nThe advantage of this distribution is that the allowance is spread evenly over the entire journey. A train that is late on 30% of its journey will have 70% of its allowance for the remaining 70% of its journey.\nEconomic distribution The economic distribution of the allowance, presented in detail in this document (MARECO is an algorithm designed by the SNCF research department), consists of distributing the allowance in the most energy-efficient way possible. It is based on two principles:\na maximum speed, avoiding the most energy-intensive speeds run-on zones, located before braking and steep gradients, where the train runs with the engine off thanks to its inertia, allowing it to consume no energy during this period An example of economic walking. Above, the gradients/ramps encountered by the train. The areas of travel on the track are shown in blue.\n","categories":"","description":"","excerpt":" The purpose of allowances As explained in the calcul du Max Effort …","ref":"/en/docs/explanation/running_time_calculation/allowances/","tags":"","title":"Allowances"},{"body":" La raison d’être des marges Comme expliqué dans le calcul du Max Effort Profile, la marche de base représente la marche la plus tendue normalement réalisable, c’est-à-dire le trajet le plus rapide possible du matériel donné sur le parcours donné. Le train accélère au maximum, roule aussi vite que possible en fonction des différentes limites de vitesse et de ses capacités motrices, et freine au maximum.\nCette marche de base présente un inconvénient majeur : si un train part avec 10min de retard, il arrivera au mieux avec 10min de retard, car par définition il lui est impossible de rouler plus vite que la marche de base. Par conséquent, les trains sont programmés avec un ajout d’une ou de plusieurs marges. Les marges sont une détente du trajet du train, un ajout de temps à l’horaire prévu, qui se traduit inévitablement par un abaissement des vitesses de circulation.\nUn train circulant en marche de base est incapable de rattraper son retard !\nLe type de marge On distingue deux types de marges :\nLa marge de régularité : il s’agit du temps complémentaire ajouté à la marche de base pour tenir compte de l’imprécision de la mesure de la vitesse, pour pallier les conséquences des incidents extérieurs venant perturber la marche théorique des trains, et pour maintenir la régularité de la circulation. La marge de régularité s’applique sur l’ensemble du trajet, bien que sa valeur puisse changer sur certains intervalles. La marge de construction : il s’agit du temps ajouté / retiré sur un intervalle spécifique, en plus de la marge de régularité, mais cette fois pour des raisons opérationnelles (esquiver un autre train, libérer une voie plus rapidement, etc.) Une marche de base à laquelle on vient ajouter une marge de régularité donne ce que l’on appelle une marche type.\nLa distribution de la marge L’ajout de marge se traduisant par un abaissement des vitesses le long du trajet, plusieurs marches types sont possibles. En effet, il existe une infinité de solutions aboutissant au même temps de parcours.\nEn guise d’exemple simple, pour détendre la marche d’un train de 10% de son temps de parcours, il est possible de prolonger n’importe quel arrêt de l’équivalent en temps de ces 10%, tout comme il est possible de rouler à 1/1,1 = 90,9% des capacités du train sur l’ensemble du parcours, ou encore de rouler moins vite, mais seulement aux vitesses élevées…\nIl y a pour l’instant deux algorithmes de distribution de la marge dans OSRD : linéaire et économique.\nLa distribution linéaire La distribution de marge linéaire consiste simplement à abaisser les vitesses d’un même facteur sur la zone où l’utilisateur applique la marge. En voici un exemple d’application :\nCette distribution a pour avantage de répartir la marge de la même manière sur tout le trajet. Un train prenant du retard à 30% de son trajet disposera de 70% de sa marge pour les 70% de trajets restants.\nLa distribution économique La distribution économique de la marge, présentée en détail dans ce document (MARECO est un algorithme conçu par la direction de la recherche SNCF), consiste à répartir la marge de la manière la plus économe possible en énergie. Elle est basée sur deux principes :\nune vitesse plafond, évitant les vitesses les plus consommatrices en énergie des zones de marche sur l’erre, situées avant les freinages et les fortes pentes, où le train circule à moteur coupé grâce à son inertie, permettant de ne consommer aucune énergie pendant ce laps de temps Un exemple de marche économique. En haut, les pentes/rampes rencontrées par le train. Les zones de marche sur l’erre sont représentées en bleu.\n","categories":"","description":"","excerpt":" La raison d’être des marges Comme expliqué dans le calcul du Max …","ref":"/fr/docs/explanation/running_time_calculation/allowances/","tags":"","title":"Les marges"},{"body":"Une des fonctionnalités qui doit être supportée par STDCM est la marge de régularité. L’utilisateur doit pouvoir indiquer une valeur de marge, exprimée en fonction de la distance ou du temps de parcours, et cette marge doit être ajoutée au trajet.\nPar exemple : l’utilisateur peut indiquer une marge de 5 minutes au 100km. Sur un trajet de 42km, un trajet de 10 minutes au plus rapide doit maintenant durer 12 minutes et 6 secondes.\nLe problème se situe au niveau de la détection de conflits. En effet, ralentir le train décale l’ensemble du sillon dans le temps et augmente la capacité consommée. La marge doit donc être prise en compte pendant l’exploration pour détecter correctement les conflits.\nPour plus de difficulté, la marge doit suivre le modèle MARECO. La marge n’est pas répartie uniformément sur le trajet, mais selon un calcul qui nécessite de connaître l’ensemble du trajet.\nPendant l’exploration La principale implication de la marge de régularité est pendant l’exploration du graphe, quand on identifie les conflits. Les temps et les vitesses doivent être baissés linéairement pour prendre en compte les conflits au bon moment. La simulation au plus rapide doit tout de même être calculée car elle peut définir le temp supplémentaire.\nCe procédé n’est pas exact car il ignore la manière dont la marge est appliquée (en particulier pour MARECO). Mais à cette étape les temps exacts ne sont pas nécessaires, il est seulement nécessaire de savoir si une solution existe à ce temps approximatif.\nCe procédé inexact peut sembler être un problème, mais en pratique (pour la SNCF) les marges de régularités ont en fait une tolérance entre deux points arbitraires du chemin. Par exemple pour une marge indiquée à 5 minutes par 100km, une solution avec la marge entre 3 et 7 minutes entre deux PR serait acceptable. Cette tolérance ne sera pas encodée explicitement, mais elle permet de faire des approximations de quelques secondes pendant la recherche. Post-processing Une fois que le chemin est trouvé, il est nécessaire de faire une simulation finale pour appliquer correctement les marges. Le procédé est le suivant :\nPour certains points du chemin, le temps est fixé. C’est un paramètre d’entrée de la simulation qui appelle le module de marge. À l’initialisation, le temps est fixé à chaque point d’arrêt. Une simulation est réalisée. En cas de conflit, on s’intéresse au premier Un point est fixé à la position de ce conflit. Le temps de référence est celui considéré pendant l’exploration. Ce procédé est répété itérativement jusqu’à une absence de conflit ","categories":"","description":"","excerpt":"Une des fonctionnalités qui doit être supportée par STDCM est la marge …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/","tags":"","title":"Marge de régularité"},{"body":"The STDCM module must be usable with standard allowances. The user can set an allowance value, expressed either as a function of the running time or the travelled distance. This time must be added to the running time, so that it arrives later compared to its fastest possible running time.\nFor example: the user can set a margin of 5 minutes per 100km. On a 42km long path that would take 10 minutes at best, the train should arrive 12 minutes and 6 seconds after leaving.\nThis can cause problems to detect conflicts, as an allowance would move the end of the train slot to a later time. The allowance must be considered when we compute conflicts as the graph is explored.\nThe allowance must also follow the MARECO model: the extra time isn’t added evenly over the whole path, it is computed in a way that requires knowing the whole path. This is done to optimize the energy used by the train.\nDuring the exploration The main implication of the standard allowance is during the graph exploration, when we identify conflicts. It means that we need to scale down the speeds. We still need to compute the maximum speed simulations (as they define the extra time), but when identifying at which time we see a given signal, all speeds and times are scaled.\nThis process is not exact. It doesn’t properly account for the way the allowance is applied (especially for MARECO). But at this point we don’t need exact times, we just need to identify whether a solution would exist at this approximate time.\nThis slightly inexact process may seem like a problem, but in reality (for SNCF) standard allowances actually have some tolerance between arbitrary points on the path. e.g. if we should aim for 5 minutes per 100km, any value between 3 and 7 would be valid. The actual tolerance is not something we can or want to encode as they’re too many specificities, but it means we can be off by a few seconds. Post-processing The process to find the actual train simulation is as follows:\nWe define points at which the time is fixed, initialized at first with the time of each train stop. This is an input of the simulation and indirectly calls the standard allowance. If there are conflict, we try to remove the first one. We add a fixed time point at the location where that conflict happened. We use the time considered during the exploration (with linear scaling) as reference time. This process is repeated iteratively until no conflict is found. ","categories":"","description":"","excerpt":"The STDCM module must be usable with standard allowances. The user can …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/standard_allowance/","tags":"","title":"Standard allowance"},{"body":"OSRD permet d’ajouter un nouveau train dans une grille horaire déjà établie, sans générer aucun conflit avec les autres trains. L’application directe de cette fonctionnalité est appelée la recherche de sillon de dernière minute.\nL’acronyme STDCM (Short Term Digital Capacity Management) est utilisé pour parler du concept en général.\n","categories":"","description":"","excerpt":"OSRD permet d’ajouter un nouveau train dans une grille horaire déjà …","ref":"/fr/docs/reference/design-docs/stdcm/","tags":"","title":"Recherche de sillons de dernière minute (STDCM)"},{"body":"OSRD can be used to find a slot for a train in an already established timetable, without causing conflicts with other trains.\nThe acronym STDCM (Short Term Digital Capacity Management) is used to describe this concept in general.\n","categories":"","description":"","excerpt":"OSRD can be used to find a slot for a train in an already established …","ref":"/en/docs/reference/design-docs/stdcm/","tags":"","title":"Search for last-minute train slots (STDCM)"},{"body":" Cette page est une ébauche, contribuez-y! Définition La couche d’ordonnancement a pour responsabilité d’établir l’ordre de commande des itinéraires, et par conséquent, l’ordre de passage des trains. La méthode exacte utilisée pour prendre cette décision n’importe pas, du moment qu’elle garantit que la simulation se termine (elle ne doit pas amener de trains en nez-à-nez, ou créer d’autres cas de figure de blocage).\nIl est possible d’implémenter un module d’ordonnancement via des tableaux d’ordre de succession des trains aux aiguilles.\nExigences de conception Il doit être possible de connecter n’importe quel algorithme d’ordonnancement Le module d’ordonnancement doit approuver les commandes de routes. Opérations train: Des itinéraires sont commandés pour chaque trains, aussi loin et aussi tôt que possible. L’approbation de la commande est soumise au régulateur, qui peut la retarder indéfiniment, selon des critères de son choix. ","categories":"","description":"Décide de l'ordre de formation des itinéraires","excerpt":"Décide de l'ordre de formation des itinéraires","ref":"/fr/docs/reference/design-docs/interlocking/ordering/","tags":"","title":"Ordonnancement"},{"body":"Cette page précise certains détails d’implémentation. Sa lecture n’est pas nécessaire pour comprendre les principes généraux, mais peut aider avant de se plonger dans le code.\nSTDCMEdgeBuilder Cette classe est utilisée pour simplifier la création d’instances de STDCMEdge, les arêtes du graphe. Celles-ci contiennent de nombreux attributs, la plupart pouvant être déterminés en fonction du contexte (comme le nœud précédent). La classe STDCMEdgeBuilder permet de rendre certains attributs optionnels et en calcule d’autres.\nUne fois instancié et paramétré, un EdgeBuilder a deux méthodes :\nCollection\u003cSTDCMEdge\u003e makeAllEdges() permet de créer toutes les arêtes possibles dans le contexte donné pour une route donnée. S’il y a plusieurs “ouvertures” entre des blocks d’occupation, une arête est créée par ouverture. Tous les conflits, leurs évitements et les attributs associés sont déterminés ici.\nSTDCMEdge findEdgeSameNextOccupancy(double timeNextOccupancy) : Cette méthode permet d’obtenir l’arête passant par une certaine “ouverture” (quand elle existe), identifiée ici par le temps de la prochaine occupation sur la route. Elle est utilisée à chaque fois qu’une arête doit être re-créée dans un contexte différent, comme pour appliquer une marge ou corriger une discontinuité. Elle appelle la méthode précédente.\nRecherche de chemin Evaluation des distances La fonction utilisée pour déterminer la distance (au sens de la recherche de chemin) détermine quel chemin sera privilégié. Le chemin obtenu sera toujours le plus court en fonction du critère donné.\nIci, deux paramètres sont utilisés : le temps de parcours total et l’heure de départ. Le second a un poids très faible par rapport au premier, pour sélectionner en priorité le chemin le plus rapide. Les détails du calcul sont indiqués dans les commentaires des méthodes concernées.\nHeuristiques L’algorithme de recherche de chemin dans le graphe est un A*, avec une heuristique basée sur les coordonnées géographiques.\nCependant, la géométrie des infrastructures générées sont arbitraires, elle ne correspond pas aux distances indiquées sur les voies. Il est donc possible que, sur ces infrastructures, les chemins obtenus ne soient pas les plus courts.\nIl est en théorie possible d’utiliser cette heuristique pour déterminer si le chemin en cours d’exploration pourra mener à une solution dont le temps de parcours ne dépasse pas le maximum. Mais pour la même raison, ajouter ce critère rend STDCM inutilisable sur les infrastructures générées. Plus de détails dans cette issue.\n","categories":"","description":"","excerpt":"Cette page précise certains détails d’implémentation. Sa lecture n’est …","ref":"/fr/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/","tags":"","title":"Détails d'implémentation"},{"body":"This page is about implementation details. It isn’t necessary to understand general principles, but it helps before reading the code.\nSTDCMEdgeBuilder This refers to this class in the project.\nThis class is used to make it easier to create instances of STDCMEdge, the graph edges. Those contain many attributes, most of which can be determined from the context (e.g. the previous node). The STDCMEdgeBuilder class makes some parameters optional and automatically computes others.\nOnce instantiated and parametrized, an STDCMEdgeBuilder has two methods:\nmakeAllEdges(): Collection\u003cSTDCMEdge\u003e can be used to create all the possible edges in the given context for a given route. If there are several “openings” between occupancy blocks, one edge is instantiated for each opening. Every conflict, their avoidance, and their related attributes are handled here.\nfindEdgeSameNextOccupancy(double timeNextOccupancy): STDCMEdge?: This method is used to get the specific edges that uses a certain opening (when it exists), identified here with the time of the next occupancy block. It is called whenever a new edge must be re-created to replace an old one. It calls the previous method.\nPathfinding The methods mentioned here are defined in this class.\nCost function The function used to define pathfinding cost sets which path is used over another. The result is always the one that minimizes this cost (as long as the heuristic is admissible).\nHere, two parameters are used: total run time and departure time. The latter has a very small weight compared to the former, so that the fastest path is found. More details are explained in the documentation of those methods.\nHeuristics The algorithm used to find a path is an A*, with a heuristic based on geographical coordinates.\nHowever, the coordinates of generated infrastructures are arbitrary and don’t reflect the track distance. It means that, for the generated infrastructures, the path may not always be the shortest one.\nIt would be possible to use this heuristic to determine whether the current node can lead to a path that doesn’t take longer than the maximum allowed total run time. But for the same reason, adding this feature would break any STDCM test on generated infras. More details in this issue.\n","categories":"","description":"","excerpt":"This page is about implementation details. It isn’t necessary to …","ref":"/en/docs/reference/design-docs/stdcm/pathfinding_module/implementation_details/","tags":"","title":"Implementation details"},{"body":"RailJSON is the format used to describe a railway infrastructure, it’s described in its JSON schema.\nBelow are a list of REST APIs implemented by OSRD.\n","categories":"","description":"Programming interfaces specifications","excerpt":"Programming interfaces specifications","ref":"/en/docs/reference/apis/","tags":"","title":"APIs"},{"body":"Le format utilisé pour décrire une infrastructure ferroviaire est RailJSON, il est décrit dans son schéma JSON.\nCi-dessous se trouve une liste des APIs REST implémentées par OSRD.\n","categories":"","description":"Spécifications des interfaces de programmation","excerpt":"Spécifications des interfaces de programmation","ref":"/fr/docs/reference/apis/","tags":"","title":"APIs"},{"body":"\nLe projet a pour ambition de répondre à une large gamme de besoins autour de la planification ferroviaire :\nconception des plans de transport études d’exploitation gestion d’infrastructure production de sillons de dernière minute Conception des plans de transport La conception de plans de transport consiste à formuler une réponse1 aux schémas de dessertes2. OSRD fournit déjà un certain nombre de fonctionnalités utiles à cette fin :\nbase d’infrastructure ferroviaire à la voie base de données de matériel roulant possibilité de modifier l’infrastructure visualisation de grilles horaires application de différents types de marges sur les sillons, y compris une marge économique, qui minimise l’énergie consommée Les perspectives futures comprennent notamment :\nla détection automatique de conflits3 synthèse d’infrastructure à la ligne à partir d’infrastructure à la voie visualisation schématique du plan de transport module d’optimisation de la capacité en ligne, d’occupation de la voie en gare et de roulement matériel Études d’exploitation Les études d’exploitation permettent d’évaluer la capacité de l’infrastructure à répondre à la demande et de la mettre en cohérence avec les besoins de transport. Elles permettent de prendre des décisions d’investissements d’infrastructure publique éclairées.\nOSRD permet de répondre à ce besoin en :\nfournissant une base d’infrastructure ferroviaires à la voie fournissant une base de données de matériel roulant donnant la possibilité de modifier l’infrastructure existante et ajouter des installations permettant de visualiser les grilles horaires permettant d’appliquer différents types de marges sur les sillons, dont une répartition économique, qui minimise l’énergie consommée. fournissant un simulateur de signalisation Les perspectives futures comprennent notamment :\ndétection de conflits3 évaluation de la robustesse d’une grille horaire via un module de simulation stochastique calcul automatique de débit et capacité Gestion d’infrastructure Le traitement d’informations liées à l’infrastructure ferroviaire étant un besoin commun à toutes les fonctionnalités d’OSRD, un module dédié permet de :\nvisualiser sur une carte les différents types d’objets utilisables dans l’application éditer l’infrastructure ferroviaire rechercher des objets importer de nouvelles infrastructures4 Sillons de dernière minute Si une grande partie des sillons5 sont établis longtemps à l’avance, une proportion grandissante ne sont commandés que très peu de temps avant le départ souhaité du train, notament avec le développement du fret.\nIl faut par conséquent être capable de répondre non seulement rapidement (moins de 3 minutes) à ces demandes, mais aussi correctement, ce qui n’est pas possible sans automatisation.\nUne offre de sillon correcte doit répondre à de nombreux critères, notamment :\nprendre en compte les travaux sur l’infrastructure ne pas générer de conflits3 avec des sillons déjà établis, y compris en gare estimer de manière réaliste le comportement du train, et donc le moment auquel le train atteint ou quitte des endroits critiques Si certains outils automatisés sont capables de fournir des réponses aux demandes de sillons de dernière minute, aucun ne prend encore en compte tous ces critères, en particulier la gestion des conflits3 en gare.\nCet outil est en cours de développement, et devrait être disponible dans les années à venir.\nSous forme de plan d’exploitation ↩︎\nUn schéma de desserte est une demande d’offre de transport, qui comprend:\nla représentation des trains demandés leur itinéraire les arrêts à desservir  ↩︎ Un conflit se produit lorsque la circulation d’un train en gêne un autre ↩︎ ↩︎ ↩︎ ↩︎\nRailJSON est le format de fichier d’infrastructure utilisé par OSRD. Il est libre, documenté, conçu pour être agnostique au gestionnaire d’infrastructure, facile à générer et manipuler. ↩︎\nUn sillon est un droit de passage sur le réseau ferroviaire, inscrit dans l’espace et dans le temps. Il est vendu par un gestionnaire d’infrastructure (GI) à une entreprise ferroviaire (EF). ↩︎\n","categories":"","description":"Applications et axes directeurs","excerpt":"Applications et axes directeurs","ref":"/fr/about/use-case/","tags":"","title":"Cas d'utilisation"},{"body":"This wiki is meant to help software engineers have a deep understanding of railway systems.\nIt can only happen if content is added as needed. If something is missing, contribute!\n","categories":"","description":"International railway wiki","excerpt":"International railway wiki","ref":"/en/docs/railway-wiki/","tags":"","title":"Railway Wiki"},{"body":"\nDesign decisions Some major changes were made between our first version of the timetable and the new one:\nIsolate the timetable table. It can be used in a scenario or in other contexts Have a soft reference from train schedule to rolling stock (to be able to create a train schedule with unknown rolling stock) Consider path and simulation output as cache (that don’t require to be stored in DB) We can compute pathfinding without having to store data All input needed to compute a path is stored in the train schedule (we can recompute it if needed) All input needed to run a simulation is stored in the train schedule (we can recompute it if needed) Train schedule v2 Requirements front: easy to keep consistent during edition front: intermediate invalid states than can be reached during edition have to be encodable front: when deleting a waypoint that is referenced by margins, the position of the deleted waypoint within the path must be preserved until the situation is resolved import: path waypoint locations can be specified using UIC operational point codes import: support fixed scheduled arrival times at stops and arbitrary points import edition: train schedules must be self-contained: they cannot be described using the result of pathfinding or simulations Design decisions Path waypoints have an identity At some point in the design process, the question was raised of whether to reference location of stops and margin transitions by name, or by value. That is, should stops hold the index of the waypoint where the stop occurs, or a description of the location where the stop occurs?\nIt was decided to add identifiers to path waypoints, and to reference those identifiers where referencing a path location is needed. This has multiple upsides:\nyou can’t reference a location outside of the path when changing a waypoint’s location, for example from one station’s platform to another, no additional maintenant work is needed to keep the path consistent if a path goes to the same place multiple times, the identifier reference makes it clear which path location is referenced it makes keeping data consistent while editing easier, as all locations are kept in a single place Invalid train schedules and soft deletes If a user deletes a waypoint, what happens? Is it the front-end’s responsibility to only save valid schedules, or can invalid schedules be represented in the data model? We decided that it wasn’t just the front-end’s responsibility, as we want to be able to model inconsistent states, until the user comes back to fix it.\nOne key observation was that we do not want to lose the ability to locate within the path waypoints that were deleted, until all references are gone. How is the front-end supposed to display margin bounds or stops for a waypoint that’s gone, if it’s not there anymore?\nWe thus decided to add a deleted soft-delete flag to waypoints. When this flag is set, the back-end runs simulations on the path, but still allows saving it. Once all references to a deleted waypoint are gone, it can be removed from the path. The backend can deny train schedules with stale deleted waypoints.\nSeparating path and stops This decision was hard to make, as there are little factors influencing this decision. Two observations led us to this decision:\nwhen deleting a waypoint, the end user may want to preserve the associated stop. Making the separation clear in the data model helps with implementing this behavior correctly, if deemed relevant bundling stops into the path makes it harder to describe what fields path waypoints should have, and what should have a separate object and reference. It was decided that keeping path a simple list of Location, with no strings attached, made things a little clearer. No more engineering margins? In the legacy model, we had engineering margins. These margins had the property of being able to overlap. It was also possible to choose the distribution algorithm for each margin individually.\nWe asked users to comment on the difference and the usefulness of retaining these margins with scheduled points. The answer is that there is no fundamental difference, and that the additional flexibility offered by engineering margins makes no practical sense (overlap and choice of distribution…).\nArrival times are durations since departure time this allows shifting the departure time without having to change arrival times we don’t have to parse dates and compute date differences within a single trip We also discussed whether to use seconds or ISO 8601 durations. In the end, ISO 8601 was chosen, despite the simplicity of seconds:\nit preserves the user’s choice unit for specifying duration it interfaces nicely with the ISO 8601 departure time it does not suffer from potential integer-float serialization related precision loss Invalid and outdated train schedules Reasons for a train schedule to be invalid:\nInconsistent train schedule (contains deleted waypoint) Rolling stock not found Path waypoint not found The path cannot be found Reasons for a train schedule to be outdated:\nThe train path changed The train running time changed What we can do about outdated trains:\nNothing, they’re updated without notification We can notify the user that a train schedule is outdated: Nothing can be done except acknowledge the change We can not check what changed between the old and new version We can not know the cause of this change (RS, Infra, Algorithms…) Note: The outdated status is a nice to have feature (it won’t be implemented right now).\nCreation fields These fields are required at creation time, but cannot be changed afterwards. They are returned when the train schedule is queried.\ntimetable_id: 42 Modifiable fields train_name: \"ABC3615\" rolling_stock_name: R2D2 # labels are metadata. They're only used for display filtering labels: [\"tchou-tchou\", \"choo-choo\"] # used to select speed limits for simulation speed_limit_tag: \"MA100\" # the start time is an ISO 8601 datetime with timezone. it is not always the # same at the departure time, as there may be a stop at the starting point start_time: \"2023-12-21T08:51:11.914897+00:00\" path: - {id: a, uic: 87210} # Any operational point matching the given uic - {id: b, track: foo, offset: 10000} # 10m on track foo - {id: c, deleted: true, trigram: ABC} # Any operational point matching the trigram ABC - {id: d, operational_point: X} # A specified operational point # the algorithm used for distributing margins and scheduled times constraint_distribution: MARECO # or LINEAR # all durations and times are specified using ISO 8601 # we don't supports months and years duration since it's ambiguous # times are defined as time elapsed since start. Even if the attribute is omitted, # a scheduled point at the starting point is inferred to have departure=start_time # the \"locked\" flag is ignored by the backend. # # To specify signal's state on stop's arrival, you can use the \"reception_signal\" enum: # - OPEN: arrival on open signal, will reserve resource downstream of the signal. # - STOP: arrival on stop signal, will not reserve resource downstream of the signal # and will trigger safety speed on approach. # - SHORT_SLIP_STOP: arrival on stop signal with a short slip distance, # will not reserve resource downstream of the signal and will trigger safety # speed on approach as well as short slip distance speed. # This is used for cases where a movable element is placed shortly after the signal # and going beyond the signal would cause major problems. # This is used automatically for any stop before a buffer-stop. # This is also the default use for STDCM stops, as it is the most restrictive. schedule: - {at: a, stop_for: PT5M, locked: true} # inferred arrival to be equal to start_time - {at: b, arrival: PT10M, stop_for: PT5M} - {at: c, stop_for: PT5M} - {at: d, arrival: PT50M, locked: true, reception_signal: SHORT_SLIP_STOP} margins: # This example encodes the following margins: # a --- 5% --- b --- 3% --- c --- 4.5min/100km --- d # /!\\ all schedule points with either an arrival or departure time must also be # margin boundaries. departure and arrival waypoints are implicit boundaries. /!\\ # boundaries delimit margin sections. A list of N boundaries yields N + 1 sections. boundaries: [b, c] # the following units are supported: # - % means added percentage of the base simulation time # - min/100km means minutes per 100 kilometers values: [\"5%\", \"3%\", \"4.5min/100km\"] # train speed at simulation start, in meters per second. # must be zero if the train starts at a stop initial_speed: 2.5 power_restrictions: - {from: b, to: c, value: \"M1C1\"} comfort: AIR_CONDITIONING # or HEATING, default STANDARD options: # Should we use electrical profiles to select rolling stock speed effort curves use_electrical_profiles: true Combining margins and schedule Margins and scheduled points are two ways to add time constraints to a train’s schedule. Therefore, there must be a clear set of rules to figure out how these two interfaces interact.\nThe end goal is to make the target schedule and margins consistent with each other. This is achieved by:\ncomputing what the schedule would look like if only margins were applied compare that to the target schedule correct the margin schedule so that it matches the target schedule The path is partitioned as follows:\nknown time sections span between locations where the arrival time is known. If there are N such locations, there are N - 1 known time sections. In these sections, margins need to be adjusted to match the target schedule. If the arrival time at destination is unknown, the section from the last known arrival time point and the destination is called the relaxed time section has no bound. Margins can be applied directly. As margins cannot span known time section boundaries, each known time section can be further subdivided into margin sections. Margins cover the entire path.\nThe end goal is to find the target arrival time at the end of each margin section. This needs to be done while preserving consistency with the input schedule.\nNote that stops do not impact margin repartition. For example, the margin does not need to be proportionally distributed on each side of b.\nThe same goes for points with arrival time. They impact whether the margin is respected or not, but they do not force the margin to be proportionally distributed on each side of the point.\nThe final schedule is computed as follows:\nA base simulation is computed, without any time constraint (other than stops). It’s used to compute provisional margin values. Make a provisional time table, which ignores target arrival times but includes provisional margin values. For each known time section, compute the adjustment required to make the provisional schedule match the target schedule. Distribute this difference into the known time section’s margin sections, proportionally to margin section running time. After distributing the adjustment into margin sections, the final schedule should be compatible with the target schedule. Error handling Some errors may happen while building the timetable:\nif a known time section’s required adjustment is negative, a warning must be raised, as margins will have to be lowered if a margin section’s final running time is tighter than the base simulation, it cannot be achieved, and a warning should be raised Other errors can happen at runtime:\ntarget margin values can be too low, as transitions from high density margin to low margin section force the train to lose time after it has exited to high density margin section. target margin values can also be too high, as the train may not have time to slow down enough, or drive so slow as to be unacceptable. During simulation, if a target arrival time cannot be achieved, the rest of the schedule still stands.\nEndpoints Timetable POST /v2/timetable GET /v2/timetable/ # Paginated list timetable PUT /v2/timetable/ID DELETE /v2/timetable/ID GET /v2/timetable/ID # Timetable with list of train schedule ids attached to it Train Schedule POST /v2/timetable/ID/train_schedule # A batch creation GET /v2/train_schedule/ID PUT /v2/train_schedule/ID # Update a specific train schedule DELETE /v2/train_schedule # A batch deletion Path POST /v2/infra/ID/pathfinding/topo # Not required now can be move later POST /v2/infra/ID/pathfinding/blocks # takes a pathfinding result and a list of properties to extract POST /v2/infra/ID/path_properties?props[]=slopes\u0026props[]=gradients\u0026props[]=electrifications\u0026props[]=geometry\u0026props[]=operational_points GET /v2/train_schedule/ID/path?infra_id=42 # Retrieve the path from a train schedule Simulation results # Retrieve the list of conflict of the timetable (invalid trains are ignored) GET /v2/timetable/ID/conflicts?infra=N # Retrieve the space, speed and time curve of a given train GET /v2/train_schedule/ID/simulation?infra=N # Retrieves simulation information for a given train list. Useful for finding out whether pathfinding/simulation was successful. GET /v2/train_schedule/simulations_summary?infra=N\u0026ids[]=X\u0026ids[]=Y # Projects the space time curves and paths of a number of train schedules onto a given path POST /v2/train_schedule/project_path?infra=N\u0026ids[]=X\u0026ids[]=Y Frontend workflow The frontend shouldn’t wait minutes to display something to the user. When a timetable contains hundreds of trains it can take some time to simulate everything. The idea is to split requests into small batches.\nflowchart TB InfraLoaded[Check for infra to be loaded] RetrieveTimetable[Retrieve Timetable] RetrieveTrains[Retrieve TS2 payloads] SummarySimulation[[Summary simulation batch N:N+10]] TrainProjectionPath[Get selected train projection path] Projection[[Projection batch N-10:N]] TrainSimulation[Get selected train simulation] TrainPath[Get selected train path] TrainPathProperties[Get selected train path properties] DisplayGev(Display: GEV / Map /\\n Driver Schedule/ Linear / Output Table) DisplayGet(Display Space Time Chart) DisplayTrainList(Display train list) Conflicts(Compute and display conflicts) ProjectConflicts(Display conflicts in GET) InfraLoaded --\u003e|Wait| SummarySimulation InfraLoaded --\u003e|Wait| TrainProjectionPath InfraLoaded --\u003e|Wait| TrainPath TrainPath --\u003e|If found| TrainSimulation TrainPath --\u003e|If found| TrainPathProperties RetrieveTimetable --\u003e|Get train ids| RetrieveTrains RetrieveTrains ==\u003e|Sort trains and chunk it| SummarySimulation SummarySimulation ==\u003e|Wait for the previous batch| Projection SummarySimulation --\u003e|Gradually fill cards| DisplayTrainList TrainPathProperties --\u003e| | DisplayGev TrainSimulation --\u003e|If valid simulation| DisplayGev TrainProjectionPath --\u003e|Wait for the previous batch| Projection SummarySimulation -..-\u003e|If no projection train id| TrainProjectionPath Projection ==\u003e|Gradually fill| DisplayGet SummarySimulation --\u003e|Once everything is simulated| Conflicts Conflicts --\u003e ProjectConflicts ","categories":"","description":"Describes evolutions to the new **timetable** and **train schedule** models","excerpt":"Describes evolutions to the new **timetable** and **train schedule** …","ref":"/en/docs/reference/design-docs/timetable/","tags":"","title":"Timetable v2"},{"body":"\nOSRD is meant to fulfill a range of use-cases related to railway planning:\ntimetabling operation studies infrastructure management short term capacity management Timetabling Timetabling is about designing a transport service in order to meet the transit needs.\nOSRD addresses this by providing:\na track level railway infrastructure database a rolling stock database an infrastructure edition tool a timetabling tool train path allowances, including an allowance distribution which minimizes energy use Planned features include:\nautomated conflict detection1 line level infrastructure synthesis from track level infrastructure interactive timetable diagrams a throughput and rolling stock turnover optimizer Operation studies Operation studies assess the ability of infrastructures to meet demand, and balance infrastructure capacity with transportation needs. They enable informed public infrastructure investment decisions.\nOSRD addresses this need by providing:\na track level railway infrastructure database a rolling stock database an infrastructure edition tool a timetabling tool train path allowances, including an allowance distribution which minimizes energy use a signaling simulator Planned features include:\nautomated conflict detection1 automated timetable robustness assessment using stochastic simulation automated throughput analyzer Infrastructure management Processing railway infrastructure data is a requirement shared by all of OSRD’s features. Therefore, a dedicated module provides:\na customizable infrastructure map an infrastructure editor a search feature an import tool2 Short term capacity management Even though most train paths3 are allocated years before operations, a growing part is allocated shortly before the planned departure time. This change is largely due to growing demand for rail freight.\nThere is therefore a need for timely (less than 3 minutes) and correct answers, which cannot be achieved without automation.\nA correct train path must, among other things:\ntake planned infrastructure work into account avoid generating conflicts1 with planned trains, including inside stations realistically estimate train behavior, and thus when the train reaches or leaves critical locations Even though some tools can currently provide answers, none currently takes all of the above into account, especially station conflicts.\nThis tool is undergoing active development, and should be available within the coming years.\nA conflicts occurs when the movement of a train interferes with another ↩︎ ↩︎ ↩︎\nOSRD uses the RailJSON rail infrastructure file format. It is a free and documented format, designed to be infrastructure manager-agnostic, easy to generate and use. ↩︎\nA train paths is a right of way on the rail network, bounded in time and space. Train paths are sold by infrastructure managers to railway companies. ↩︎\n","categories":"","description":"Use cases related to rail transport planning","excerpt":"Use cases related to rail transport planning","ref":"/en/about/use-case/","tags":"","title":"Use cases"},{"body":"Ce wiki a pour objectif de rendre accessible aux développeurs des informations sur le monde ferroviaire.\nCela ne peut se produire que si le contenu est ajouté lorsque nécessaire. Si quelque chose manque, contribuez !\n","categories":"","description":"Wiki ferroviaire international","excerpt":"Wiki ferroviaire international","ref":"/fr/docs/railway-wiki/","tags":"","title":"Wiki Ferroviaire"},{"body":"Description Les contraintes sur ce qu’est un train sont relativement faibles. Il doit seulement avoir un identifiant, qui permet aux autres systèmes de garder des références vers des trains.\nExigences de conception Les trains occupent les zones. Les trains doivent être suivis pour préserver leur ordre de passage. Les trains ont pour responsabilité de demander les itinéraires devant eux. ","categories":"","description":"Représente un train dans la simulation","excerpt":"Représente un train dans la simulation","ref":"/fr/docs/reference/design-docs/interlocking/train/","tags":"","title":"Train"},{"body":"Context and requirements authentication (authn) is the process of figuring out a user’s identity. authorization (authz) is the process of figuring out whether a user can do something. This design project started as a result of a feature request coming from SNCF users and stakeholders. After some interviews, we believe the overall needs to be as follows:\ncontrolling access to features some users are supposed to only view results of operational studies some users only get access to part of the app not everyone can have access to the admin panel it could be nice to be able to roll experimental features out incrementaly controlling access to data some infrastructures shall only be changed by automated import jobs users might want to control who can mess with what they’re currently working on rolling stock, infrastructure and timetable data may be confidential Overall architecture flowchart LR subgraph gateway auth([authentication]) end subgraph editoast subgraph authorization roles([role check]) permissions([permission check]) end end subgraph decisions permit deny end request --\u003e auth --\u003e roles --\u003e permissions auth --\u003e deny roles --\u003e deny permissions --\u003e permit \u0026 deny Authentication The app’s backend is not responsible for authenticating the user: it gets all required information from gateway, the authenticating reverse proxy which stands between it and the front-end.\nat application start-up, the front-end redirects to the login page if the user is not logged in if the user is already authenticated, the gateway returns user metadata otherwise, the gateway initiates the authentication process, usually with OIDC. The implementation was designed to allow new backends to be added easily. once the user is authenticated, all requests to the backend can expect the following headers to be set: x-remote-user-identity contain a unique identifier for this identity. It can be thought of as an opaque provider_id/user_id tuple. x-remote-user-name contain a username When editoast receives a request, it has to match the remote user ID with a database user, creating it as needed.\ncreate table authn_subject( id bigserial generated always as identity primary key, ); create table authn_user( id bigint primary key references auth_subject on delete cascade, identity_id text not null, name text, ); create table authn_group( id bigint primary key references auth_subject on delete cascade, name text not null, ); -- add a trigger so that when a group is deleted, the associated authn_subject is deleted too -- add a trigger so that when a user is deleted, the associated authn_subject is deleted too create table authn_group_membership( user bigint references auth_user on delete cascade not null, group bigint references auth_group on delete cascade not null, unique (user, group), ); Group and role management API Users cannot be directly created. The authenticating reverse proxy is in charge of user management. role management is protected by the role:admin role. groups management is subject to permissions. Get information about a user GET /authn/me GET /authn/user/{user_id} { \"id\": 42, \"name\": \"Foo Bar\", \"groups\": [ {\"id\": 1, \"name\": \"A\"}, {\"id\": 2, \"name\": \"B\"} ], \"app_roles\": [\"ops\"], \"builtin_roles\": [\"infra:read\"] } Builtin roles are deduced from app roles, and thus cannot be directly edited.\nAdd roles to a user or group This endpoint can only be called if the user has the role:admin builtin role.\nPOST /authn/user/{user_id}/roles/add POST /authn/group/{group_id}/roles/add Takes a list of app roles:\n[\"ops\", \"stdcm\"] Remove roles from a user or group This endpoint can only be called if the user has the role:admin builtin role.\nPOST /authn/user/{user_id}/roles/remove Takes a list of app roles to remove:\n[\"ops\"] Create a group This endpoint can only be called if the user has the group:create builtin role. When a user creates a group, it becomes its owner.\nPOST /authn/group { \"name\": \"Foo\" \"app_roles\": [\"ops\"], } Returns the group ID.\nAdd users to a group Can only be called if the user has Writer access to the group.\nPOST /authn/group/{group_id}/add Takes a list of user IDs\n[1, 2, 3] Remove users from a group Can only be called if the user has Writer access to the group.\nPOST /authn/group/{group_id}/remove Takes a list of user IDs\n[1, 2, 3] Delete a group Can only be called if the user has Owner access to the group.\nDELETE /authn/group/{group_id} Authorization As shown in the overall architecture section, to determine if a subject is allowed to conduct an action on a ressource, two checks are performed:\nWe check that the roles of the subject allows the action. We check that the subject has the minimum privileges on the ressource(s) that are required to perform the action. Roles Subject can have any number of roles. Roles allow access to features. Roles do not give rights on specific objects.\nBoth the frontend and backend require some roles to be set to allow access to parts of the app. In the frontend, roles guard features, in the backend, roles guard endpoints or group of endpoints.\nThere are two types of roles:\nBuiltin roles are bundled with OSRD. Only builtin roles can be required by endpoints. These roles cannot directly be assigned to users. Application roles can be assigned to users. These roles are defined in a configuration file that editoast reads at startup. Here is an example of what builtin roles might look like:\nrole:admin allows assigning roles to users and groups group:create allows creating user groups infra:read allows access to the map viewer module infra:write implies infra:read. it allows access to the infrastructure editor. rolling-stock:read rolling-stock:write implies rolling-stock:read. Allows access to the rolling stock editor. timetable:read timetable:write implies timetable:read operational-studies:read allows read only access to operational studies. it implies infra:read, timetable:read and rolling-stock:read operational-studies:write allows write access to operational studies. it implies operational-studies:read and timetable:write stdcm implies infra:read, timetable:read and rolling-stock:read. it allows access to the short term path request module. admin gives access to the admin panel, and implies all other roles Given these builtin roles, application roles may look like:\noperational-studies-customer implies operational-studies:read operational-studies-analyst implies operational-studies:write stdcm-customer implies stdcm ops implies admin Roles are hierarchical. This is a necessity to ensure that, for example, if we are to introduce a new action related to scenarios, each subject with the role “exploitation studies” gets that new role automatically. We’d otherwise need to edit the appropriate existing roles.\nTheir hierarchy could ressemble:\n%%{init: {\"flowchart\": {\"defaultRenderer\": \"elk\"}} }%% flowchart TD subgraph application roles operational-studies-analyst operational-studies-customer end subgraph builtin roles rolling-stock:read rolling-stock:write infra:read infra:write timetable:read timetable:write operational-studies:read operational-studies:write end operational-studies-analyst --\u003e operational-studies:write operational-studies-customer --\u003e operational-studies:read infra:write --\u003e infra:read rolling-stock:write --\u003e rolling-stock:read operational-studies:read --\u003e infra:read \u0026 timetable:read \u0026 rolling-stock:read operational-studies:write --\u003e operational-studies:read \u0026 timetable:write timetable:write --\u003e timetable:read classDef app fill:#333,color:white,font-style:italic classDef builtin fill:#992233,color:white,font-style:bold class stdcm,exploitation,infra,project,study,scenario app class infra_read,infra_edit,infra_delete,project_create,study_delete,scenario_create,scenario_update builtin Permissions Permission checks are done by the backend, even though the frontend may use the effective privilege level of a user to decide whether to allow modifying / changing permissions for a given object.\nPermissions are checked per resource, after checking roles. A single request may involve multiple resources, and as such involve multiple permission checks.\nPermission checks are performed as follows:\nfor each request, before any resource is accessed, compute which resources need access and required privilege levels figure out, for the request’s user, its effective privilege level for every involved resource if the user’s privilege level does not meet expectations, raise an error before any change is made enum EffectivePrivLvl { Owner, // all operations allowed, including granting access and deleting the resource Writer, // can change the resource Creator, // can create new subresources Reader, // can read the resource MinimalMetadata, // is indirectly aware that the resource exists } trait Resource { #[must_use] fn get_privlvl(resource_pk: u64, user: \u0026UserIdentity) -\u003e EffectivePrivLvl; } The backend may therefore perform one or more privilege check per request:\npathfinding: Reader on the infrastructure displaying a timetable: Reader on each rolling stock batch train creation: Creator on the timetable conflict detection: Reader on the infrastructure Reader on the timetable Reader on every involved rolling stock simulation results: Reader on the infrastructure Reader on the rolling stock A grant is a right, given to a user or group on a specific resource. Users get privileges through grants. There are two types of grants:\nexplicit grants are explicitly attached to resources implicit grants automatically propagate explicit grants for objects which belong to a hierarchy: if a subject owns a project, it also owns all studies and scenarios if a subject can read a scenario, it knows the parent study and project exist Explicit grants can be edited from the frontend any user holding grants over a resource can add new ones when a resource is created, Owner is granted to the current user not all objects type can have explicit grants: train schedule inherit their timetable’s grants -- this type is the same as EffectivePrivLvl, except that MinimalMetadata is absent, -- as it cannot be granted directly. mere knowledge that an object exist can only be -- granted using implicit grants. create type grant_privlvl as enum ('Owner', 'Writer', 'Creator', 'Reader'); -- this table is a template, which other grant tables are -- designed to be created from. it must be kept empty. create table authz_template_grant( -- if subject is null, this grant applies to any subject subject bigint references authn_subject on delete cascade, grant grant_privlvl not null, granted_by bigint references authn_user on delete set null, granted_at timestamp not null default CURRENT_TIMESTAMP, ); -- these indices speed up cascade deletes create index on authz_template_grant(subject); create index on authz_template_grant(granted_by); -- create a new grant table for infrastructures create table authz_grant_EXAMPLE ( like authz_template_grant including all, resource bigint references EXAMPLE on delete cascade not null, unique nulls not distinct (resource, subject), ); -- raise an error if grants are inserted into the template create function authz_grant_insert_error() RETURNS trigger AS $err$ BEGIN RAISE EXCEPTION 'authz_grant is a template, which other grant ' 'tables are designed to inherit from. it must be kept empty.'; END; $err$ LANGUAGE plpgsql; create trigger before insert on authz_template_grant execute function authz_grant_insert_error(); Implicit grants Implicit grants only apply to the operational studies module, not timetables, infrastructures and rolling stocks. Implicit grants propagate explicit grants to related objects. There are two types of implicit grants:\nexplicit grants propagate downwards within hierarchies: Owner, Reader, Writer propagate as is, Creator is reduced to Reader MinimalMetadata propagates up within project hierarchies, so that read access to a study or scenario allows having the name and description of the parent project The following objects have implicit grants:\nproject gets MinimalMetadata if the user has any right on a child study or scenario study gets: MinimalMetadata if the user has any right on a child scenario Owner, Reader, Writer if the user has such right on the parent study. Creator is reduced to Reader. scenario gets Owner, Reader, Writer if the user has such right on the parent study or project. Creator is reduced to Reader. train-schedules have the same grants as their timetable Permission meta-model Get the privilege level of the current user GET /authz/{resource_type}/{resource_id}/privlvl Get all grants for a resource GET /authz/{resource_type}/{resource_id}/grants [ { \"subject\": {\"kind\": \"group\", \"id\": 42, \"name\": \"Bar\"}, \"implicit_grant\": \"Owner\", \"implicit_grant_source\": \"project\" }, { \"subject\": {\"kind\": \"user\", \"id\": 42, \"name\": \"Foo\"}, \"grant\": \"Writer\" }, { \"subject\": {\"kind\": \"user\", \"id\": 42, \"name\": \"Foo\"}, \"grant\": \"Writer\", \"implicit_grant\": \"MinimalMetadata\", \"implicit_grant_source\": \"project\" } ] Implicit grants cannot be edited, and are only displayed to inform the end user.\nAdd a new grant POST /authz/{resource_type}/{resource_id}/grants { \"subject_id\": 42, \"grant\": \"Writer\" } Change a grant PATCH /authz/{resource_type}/{resource_id}/grants/{grant_id} { \"grant\": \"Reader\" } Revoke a grant DELETE /authz/{resource_type}/{resource_id}/grants/{grant_id} Implementation plan Phase 1: ground work Back-end:\npass the proper headers from the reverse proxy to editoast implement the authn / authz model into the database get / create users on the fly using reverse proxy headers implement the role parsing and book-keeping (it can be parsed on startup and leaked into a static lifetime) implement a proof of concept for roles using role:admin and role management implement a proof of concept for permissions by implementing group management implement a middleware within editoast which: attaches a UserInfo object to each request ensures that role / permission checks were performed. Implement two modules: log on missing check, abort on missing check. injects which checks were performed into response headers so it can be tested introduce the concept of rolling stock collections to enable easier rolling stock permission checking write a migration guide to help OSRD developpers navigate the authorization APIs Front-end:\ntake into account builtin roles to decide which features to unlock design, validate and build a permission editor prepare graceful handling of 403s Phase 2: migration Back-end:\nincrementally migrate all endpoints, using the middleware to find missing checks switch the default action on missing permission check to abort Front-end:\nadd the permission editor to all relevant objects handle 403s, especially on scenarios, where read access on the timetable, infra, rolling stock collections and electrical profile is required Design decisions Simultaneous RBAC and ABAC RBAC: role based access control (users have roles, actions require roles) ABAC: attribute based access control (resources have attributes, user + actions require attributes). ACLs are a kind of ABAC.\nAfter staring at what users asked for and established authorization models allow, we figured out that while no one model is a good fit on its own:\njust RBAC would not allow fine grained, per object access control just ABAC would not allow guarding off access to entire features We decided that each authorization model could be used where it shows its strength:\nRBAC is used to authorize access to frontend features and backend endpoints ABAC is used to authorize actions on specific objects We found no success in our attempts to find a unifying model.\nNot using any policy language At first, we assumed that using a policy language would assist with correctly implementing authorization. After further consideration, we concluded that:\nno user asked for policy flexibility nor policy as code, and there does not seem to be any obvious use case not already covered by RBAC + ABAC the main policy language considered, cedar, makes it very awkward to implement single pass RBAC + ABAC the primary benefit of policy languages, policy flexibility, is still very much constrained by the data the policy engine is fed: for OSRD, feeding all grants, all users, all groups and all roles to the policy engine is not practical. we thus need filtering and careful modeling, which almost guarantees changes will be required if a new authz rule type were to be requested by a customer. Worse yet, these changes seem to require more effort than adapting the authz system if there were not policy language at all. as policy languages only deal with evaluating the policy, one can be introduced later if so desired No implicit grants for infra, timetable and rolling stock We felt like this feature would be hard to implement, and be likely to introduce confidentiality and performance issues:\nthese objects may not be part of any operational studies, or multiple operational studies implicit grants are hard to implement, and risk introducing vulnerabilities infra, timetable and rolling stock are likely to be confidential Instead, we plan to:\ndelay implementing this feature until we figure out if the lack thereof is an UX issue if deemed required, implement it by checking, within the permission editor, whether all users having access to a scenario can access associated data, and suggesting associated permission changes All resource types share the same permission management endpoints We considered two patterns for permission management endpoints:\na single set of endpoints for all resource types: /authz/{resource_type}/{resource_id}/grants/... separate set of endpoints per resource type: /v2/infra/{infra_id}/grants/... We found that:\nhaving separate set of endpoints per resource types brought extra back-end and front-end complexity the only constraint of unified permission management endpoints is that all resource types need globaly unique IDs the globaly unique ID constraint is less costly than the extra complexity of separate endpoints Dynamically enforce permission checks Ideally, there would be static checks enforcing permission checks. However, we found no completly fool proof way to statically do so.\nInstead, we decided that all permission checks will be registered with a middleware, which will either log or raise an error when a handler performs no check.\nduring local development, the middleware logs missing permission checks as errors during continuous integration checks and production deployments, the middleware aborts on missing checks ","categories":"","description":"","excerpt":"Context and requirements authentication (authn) is the process of …","ref":"/en/docs/reference/design-docs/auth/","tags":"","title":"Authentication and authorization"},{"body":"Loading Signal Parameters The first step of loading the signal is to characterize the signal in the signaling system. This step produces an object that describes the signal.\nDuring the loading of the signal:\nthe signaling system corresponding to the provided name is identified the signal properties and parameters are loaded and validated according to the signaling system spec the signal’s block and route delimiting properties are evaluated Loading the Signal Once signal parameters are loaded, drivers can be loaded. For each driver:\nThe driver implementation is identified from the (signaling_system, next_signaling_system) pair. It is verified that the signaling system outgoing from the driver corresponds to the one of the signal. It is verified that there is no existing driver for the incoming signaling system of the driver. This step produces a Map\u003cSignalingSystem, SignalDriver\u003e, where the signaling system is the one incoming to the signal. It then becomes possible to construct the loaded signal.\nConstructing Blocks The framework creates blocks between signals following the routes present in the infrastructure, and the block properties of the signals. Checks are made on the created block graph: it must always be possible to choose a block for each signal and each state of the infrastructure. Block validation The validation process helps to report invalid configurations in terms of signaling and blockage. The validation cases we want to support are:\nThe signaling system may want to validate, knowing if the block starts / ends on a buffer: the length of the block the spacing between the block signals, first signal excluded Each signal in the block may have specific information if it is a transition signal. Therefore, all signal drivers participate in the validation. In practice, there are two separate mechanisms to address these two needs:\nThe signaling system module is responsible for validating signaling within blocks. Signal drivers take care of validating transitions between blocks. extern fn report_warning(/* TODO */); extern fn report_error(/* TODO */); struct Block { startsAtBufferStop: bool, stopsAtBufferStop: bool, signalTypes: Vec\u003cSignalingSystemId\u003e, signalSettings: Vec\u003cSignalSettings\u003e, signalPositions: Vec\u003cDistance\u003e, length: Distance, } /// Runs in the signaling system module fn check_block( block: Block, ); /// Runs in the signal driver module fn check_signal( signal: SignalSettings, block: Block, // The partial block downstream of the signal - no signal can see backward ); Signal lifecycle Before a train startup:\nthe path a of the train can be expressed is given, both as routes and blocks the signal queue a train will encounter is established During the simulation:\nalong a train movement, the track occupation before it are synthesized when a train observes a signal, its state is evaluated Signal state evaluation Signals are modeled as an evaluation function, taking a view of the world and returning the signal state\nenum ZoneStatus { /** The zone is clear to be used by the train */ CLEAR, /** The zone is occupied by another train, but otherwise clear to use */ OCCUPIED, /** The zone is incompatible. There may be another train as well */ INCOMPATIBLE, } interface MAView { /** Combined status of the zones protected by the current signal */ val protectedZoneStatus: ZoneStatus val nextSignalState: SignalState val nextSignalSettings: SignalSettings } fun signal(maView: MAView?): SignalState { // ... } The view should allow access to the following data:\na synthetized view of zones downstream until the end of the train’s MA the block chain the state of downstream signals which belong to the current block chain Signaling view path The path along which the MAView and SpeedLimitView live is best expressed using blocks:\nblocks can be added to extend the view along the path of a train the view can be reduced by removing blocks, as the train passes by signals Simulation outside the train path Everything mentionned so far was designed to simulate signals between a train the end of its movement authority, as all others signals have no influence over the behavior of trains (they cannot be seen, or are disregarded by drivers).\nNevertheless, one may want to simulate and display the state of all signals at a given point in time, regardless of which signals are in use.\nSimulation rules are as follows:\nif a signal starts blocks which have differing paths, it is simulated as if it were at the end of a route if a signal starts blocks which all start the same path, it is simulated in the same view as the next signals in this path ","categories":"","description":"Tells the story of how signaling infrastructure is loaded and simulated on","excerpt":"Tells the story of how signaling infrastructure is loaded and …","ref":"/en/docs/reference/design-docs/signaling/simulation/","tags":"","title":"Simulation lifecycle"},{"body":"À compléter : ouvrez une issue en cas de mot manquant\nA ADV : Appareil de voie B BA : Block automatique BAL : Block automatique lumineux BAPR : Block automatique à permissivité restreinte BM : Block manuel BMCV : BM par circuit de voie BMVU : BM de voie unique C CAPI : Cantonnement assisté par informatique CC : Commande et contrôle COVIT : Contrôle de vitesse CT : Cantonnement téléphonique D DAAT : Dispositif d’arrêt automatique des trains DMI : Driver machine interface : dispositif qui permet la communication entre le système bord et le conducteur DV : Double voie E EOA : End of authority (fin d’autorisation de mouvement) EPSF : Établissement public de sécurité ferroviaire ETCS : European train control system (système européen de contrôle commande des trains) ERTMS : European rail traffic management system (système européen de gestion du trafic ferroviaire) EVC : European vital computer. (ordinateur européen de sécurité) : calculateur de bord qui supervise la marche du train en fonction des données sol et bord F FA : Fermeture automatique FS : Full supervision (supervision complète) : mode technique dans lequel le train est supervisé en vitesse et déplacement = marche normale attribuée au train G GI : Gestionnaire d’infrastructure GSM/GFU : Global system for mobile communication/Groupe fermé d’utilisateurs GSM-R : Global system for mobile communication railways (Système de communication téléphonique pour mobile dédié aux chemins de fer) GSM-R Data : Système de transmission de données entre les installations « sol » et les installations « bord » via le réseau GSM-R I ICS : Installations de circulation à contre-sens IPCS : Installations permanentes de contre-sens IS : Installation de sécurité ITCS : Installations temporaires de contre-sens J JRU : Juridical recording unit (Enregistreur des paramètres d’exploitation) K KVB : Contrôle de vitesse par balises L LEU : Line side electronic unit (codeur ERTMS) LGV : Ligne à grande vitesse LTV : Limitation temporaire de vitesse M MA : Movement authority : autorisation donnée à un train de circuler vers un point donné en tant que mouvement supervisé N Nf : Non franchissable NL : Non leading (non en tête) : Mode technique de circulation utilisé pour la double traction ou la pousse O OS : On sight (conduite à vue) : mode technique de circulation qui autorise le conducteur à s’avancer en marche à vue. En ETCS1, le mode OS accompagné du message textuel national « Voie de service » impose la marche en manoeuvre pour la réception sur voie de service P PI ETCS : Point d’information ETCS : constitué d’une ou plusieurs balises transmettant des informations vers le bord (par exemple PI avancé ou PI signal) PK : Point Kilométrique : position géographique basée sur un RK (Repère Kilométrique) PL : Pleine ligne PLD : Point limite de domaine : point où une transition entre ETCS et un autre système de signalisation a lieu PN : Passage à niveau PO : Point opérationnel : collection de points représentant un lieu d’intérêt, voir exemple. PR : Point remarquable : voir PO R RBC : Radio block center : système centralisé fonctionnant avec les enclenchements afin d’établir et de contrôler l’espacement et le mouvement des trains en envoyant et recevant des informations par radio en ETCS2 ou 3 RFN : Réseau Ferré National RK : Repère Kilométrique : bornes (physiques) placées sur une voie à distance régulière (environ un kilomètre les unes des autres mais pouvant varier) servant à se repérer sur une voie RST : Radio sol-train RT : Renseignement technique RV : Reversing (refoulement) : mode technique de circulation utilisé pour permettre au train de reculer d’urgence sans signaux ni ordre dans une zone prédéfinie. Ce mode n’est pas utilisé sur le RFN S SEL : Section d’électrification. La plus petite portion d’un caténaire pouvant être coupée pour travaux SGS : Système de gestion de la sécurité SH : Shunting (manoeuvre) : mode technique de circulation manoeuvre SN : System national : mode technique de circulation de niveau STM SR : Staff responsible (responsabilité agent) : mode technique de circulation utilisé dans les situations dégradées. Il est utilisable sous la responsabilité respective de l’agent-circulation et du conducteur SR : Système de repérage SRV : Système de repérage voie : métadonnées et anomalies (données correctives) permettant de faire des calculs de distance entre deux PKs sur une voie STM : Specific transmission module (Module spécifique de transmission) : ce dispositif permet à l’ETCS d’utiliser un système de signalisation national T TECS : Tableau lumineux d’entrée à contre sens TIV : Tableau indicateur de vitesse TIV : Tronçon d’itinéraire de voie (Track Section en anglais). TR : Trip : mode technique de circulation entraînant une application irréversible du freinage d’urgence par le système ETCS jusqu’à l’arrêt du train TSCS : Tableau lumineux de sortie à contre sens TVM : Transmission voie machine V VB : Voie banalisée VP : Voie principale VS : Voie de service VU : Voie unique VUT : Voie unique temporaire VUTP : Voie unique temporaire à caractère permanent Z ZEP : Zone élémentaire de protection : la plus petite portion de voie pouvant être fermée pour des travaux ","categories":"","description":"Glossaire thématique d'OSRD et du ferroviaire","excerpt":"Glossaire thématique d'OSRD et du ferroviaire","ref":"/fr/docs/railway-wiki/glossary/","tags":"","title":"Glossaire"},{"body":"Please open an issue if you’re missing a word\n","categories":"","description":"Glossary of OSRD and railway vocabulary","excerpt":"Glossary of OSRD and railway vocabulary","ref":"/en/docs/railway-wiki/glossary/","tags":"","title":"Glossary"},{"body":"TODO: create another document describing RPC interactions between core and editoast\nContext and requirements Without this proposal, editoast directly makes calls to core using http. Using k8s, if multiple core workers are started, requests are randomly distributed to core workers.\nThis architecture brings a number of issues:\nTo respond to a request, the core worker need to hold the request’s full infrastructure in memory. Workers do not have enough memory to hold all infrastructures in memory. Requests thus need to be routed to core workers specialized by infrastructure, which cannot be easily done using http. If too many requests are dispatched to a busy core worker, they will just time out. There is no easy way to scale up the number of workers to react to increased load. Because calls need to complete within the timeout of the client’s http requests, the system falls appart when latency increases due to load. This proposal intends to address these issues by introducing an RPC system which:\nmanages specialized workers automatically scales specialized workers Goals high priority the RPC protocol between editoast and core should be the same for development and production setups high priority requests are dispatched to specialized workers high priority the RPC system should be stateless and failure-resilient low priority the complexity of the local development setup should not increase Non-goals not a goal streaming events to the front-end not a goal reliable response processing not a goal caching Concepts flowchart TD client osrdyne worker-pool worker-group worker-group-queue worker worker-pool -- contains --\u003e worker-group worker-group -- contains and manages --\u003e worker client -- pub --\u003e worker-group-queue worker-group -- has a --\u003e worker-group-queue worker -- sub --\u003e worker-group-queue osrdyne -- manages --\u003e worker-pool osrdyne -- manages --\u003e worker-group osrdyne -- manages --\u003e worker-group-queue Client Clients submit RPC requests to the message queue. RPC requests are published using AMQP 0.9.1.\nFor example, editoast would be a client.\nWorker key Every submitted request includes a requested worker-key, as the message’s routing-key.\nThe key is what identifies which worker group will process the request.\nWorkers known their worker key at startup. All workers in a worker group have the same worker key. It is an arbitrary utf-8 string set by the client, whose meaning is not defined by the RPC protocol:\nIt could just be a way to have separate processing queues. In this case, workers may not care about what their is. There could be an extra layer of protocol between client and worker about how the key is meant to be interpreted Here are some examples of how such protocols may work:\nit could be the identifier of a resource to act upon: 42 it could be the identifiers of multiple resources: infra=42,timetable=24 it could even be, even though that’s probably not a good idea, random worker settings: log_level=debug Worker pools Worker pools are collections of workers of the same type, which can be specialized by key. osrdyne creates an exchange for each worker pool, where clients can submit requests.\nFor example, core would be a worker pool.\nWorker group Worker groups are collections of workers of the same pool and key, processing messages from the same queue. Worker groups are responsible for scaling the number of workers depending on queue length and processing rate.\nWorker groups are managed by osrdyne. osrdyne should support multiple worker group drivers:\na keda k8s driver a k8s autoscaler driver a docker driver a subprocess driver, where a single worker is started as a subprocess for each worker group a systemd template unit driver a noop driver, where workers have to be started manually For example, each core worker group handles a given infrastructure.\nWorker A worker is a server processing requests from its worker group queue. Worker have a key. For example, core workers are keyed by infrastructure.\nosrdyne manages all exchanges, policies, queues and bindings starts and stops worker groups as needed generates error responses if the worker group fails to respond Each osrdyne instance manages a worker pool. See the dedicated section.\nRPC protocol Client protocol Requests are submitted using AMQP 0.9.1’s basic.publish:\nAMQP field semantics exchange worker pool identifier routing-key requested key correlation-id an optional request id. The response will copy this field. reply-to property optional response queue mandatory true to ensure an error is returned if the message cannot be routed The body of the request will be dispatched to a worker of the requested pool and key. The request is guaranteed to be dispatched at least once\nThe response format is as follows:\nAMQP field semantics correlation-id the correlation ID from the request x-status property either ok, or the reason for dead lettering, taken from the request’s x-first-death-reason body optional response data Worker protocol When starting workers, the worker group driver provides:\nVariable name semantics WORKER_ID a unique identifier for this worker WORKER_KEY the worker key WORKER_POOL the name of the worker pool WORKER_REQUESTS_QUEUE the queue to consume work from WORKER_ACTIVITY_EXCHANGE the exchange to publish events to Workers then have to:\npublish a started activity report message subcribe to WORKER_REQUESTS_QUEUE using basic.consume for each request message: publish a request-received activity report message if the worker cannot process the request, it can request a requeue using basic.reject with requeue=true build and publish a response to the default exchange basic.ack the request Worker response protocol Responses are submitted using AMQP 0.9.1’s basic.publish:\nAMQP field semantics exchange worker pool identifier routing-key requested key reply-to property optional response queue Worker activity reports Workers report the following activity events:\nstarted: the worker is about to start processing requests request-received: a request was received AMQP field value exchange WORKER_ACTIVITY_EXCHANGE routing-key WORKER_KEY x-event property the event type Message passing architecture For a full reference of all exchanges and queues, see the exchanges and queues section\nMessage lifetime flowchart TD received processed received --\u003e requests received -- alternate exchange --\u003e orphans orphans -- controller starts worker group --\u003e requests requests -- dead letter --\u003e dlx dlx -- controller generates error --\u003e processed requests -- worker responds --\u003e processed Service architecture flowchart TD client subgraph RPC layer rabbitmq[RabbitMQ] osrdyne[osrdyne] end subgraph worker-group[worker group] worker end client -- enqueues --\u003e rabbitmq osrdyne -- sub orphan messages --\u003e rabbitmq osrdyne -- manages queues --\u003e rabbitmq osrdyne -- starts and stops --\u003e worker-group osrdyne -- sub activity events --\u003e rabbitmq worker -- sub requests --\u003e rabbitmq worker -- pub responses --\u003e rabbitmq worker -- pub activity events --\u003e rabbitmq osrdyne stops and starts worker groups following demand worker processes requests dequeued from rabbitmq Life of an RPC call In this example:\neditoast is the client it makes a request to the core worker pool the core worker pool is keyed on infrastructures Fast path Editoast publishes a request message to exchange=core with routing_key=42. If the message expects a reply, reply-to is set. If the core exchange already has binding for worker group 42, a worker picks up the request The worker processes the request, and uses the reply-to field to submit a response. The worker ACKs the request. Worker group startup These steps only occur if the worker group / queue has not yet started:\nIf there is no queue bound to routing key 42, the message is routed to the core-orphan-xchg exchange. This exchange is a fanout exchange with a single queue, where osrdyne processes messages. osrdyne processes the message: creates queue core-req-42, binds it to the core exchange on routing key 42 forward the message to exchange core ACK the original message once the original is forwarded start worker group core key 42 the worker group starts up and processes the request osrdyne architecture flowchart TD %% inputs activity-queue([activity queue]) orphan-queue([orphan queue]) dead-letter-queue([dead letter queue]) rabbitmq-api[RabbitMQ HTTP API] %% components orphan-processor[orphan processor] dead-letter-responder[dead letter responder] subgraph pool manager pool-state-tracker[pool state tracker] wgs-control-loop[worker groups control loop] req-queues-control-loop[request queues control loop] end wg-driver[worker group driver] %% outputs request-xchg([request exchange]) poison-inventory([poison request inventory]) response([response queue]) %% relations dead-letter-queue -- sub --\u003e dead-letter-responder --\u003e response \u0026 poison-inventory orphan-queue -- sub --\u003e orphan-processor -- forward --\u003e request-xchg orphan-processor -- request worker group start --\u003e pool-state-tracker orphan-processor -- wait for execution --\u003e req-queues-control-loop rabbitmq-api -- initial queue list --\u003e pool-state-tracker activity-queue -- worker activity --\u003e pool-state-tracker pool-state-tracker -- expected state --\u003e wgs-control-loop \u0026 req-queues-control-loop wgs-control-loop -- start / stop --\u003e wg-driver the pool manager is the most complex component of osrdyne. It is in charge of creating, deleting request queues, and deciding which worker groups should be running at any given time. To make such decisions, it needs:\nthe ability to list existing queues at startup, which is done using the RabbitMQ HTTP API worker activity events, to know which queues are active queue creation commands from the orphan processor The pool manager runs two control loops:\nthe worker groups control loop starts and stops worker groups using the worker group driver the request queues control loop creates and deletes request queues the orphan processor reacts to orphan messages by sending worker group start commands to the worker group manager\nthe dead letter responder:\nresponds errors to dead lettered messages following the worker protocol if a message is deemed to have caused repeated worker crashes, publish to the poison inventory On worker pool startup:\ncreate and bind all exchanges and queues configure the TTL, delivery timeout and delivery limit policies using the HTTP API start the orphan processsor, dead letter responder and worker group manager Exchanges and queues osrdyne creates a number of exchanges and queues. Most of the setup is done per worker pool, except for worker group request queues.\nWorker pool exchanges:\npool requests exchange {pool}-req-xchg, type direct: alternate exchange is {pool}-orphan-xchg dead letter exchange is {pool}-dl-xchg worker group request queues are bound to this exchange orphan exchange {pool}-orphan-xchg, type fanout dead letter exchange {pool}-dl-xchg, type fanout activity queue {pool}-activity-xchg, type fanout Worker pool queues:\ndead letter queue {pool}-dl, bound to {pool}-dl-xchg (exclusive) orphan queue {pool}-orphan, bound to {pool}-orphan-xchg (exclusive) worker activity queue {pool}-activity, bound to {pool}-activity-xchg poison queue {pool}-poison. Used to collect messages which could not be processed, supposedly due to worker crash Worker group queues:\nrequest queue {pool}-req-{key}, bound by key to {pool}-req-xchg Worker group manager The worker group manager has three internal components:\nthe pool state tracker tracks the expected status of worker groups the request queues control loop applies changes to worker group request queues the worker groups control loop applies changes to worker groups The state tracker assigns a 64 bit generation identifier to each expected state. The two control loops report the last synchronized state.\nWhen the orphan processor wants to start a worker group, it has to:\ntell the state tracker, which gives a generation identifier for the new expected state wait until the request queue control loop has caught up to this generation and has created the queue (which may be delayed due to networking issues) Pool state tracker stateDiagram-v2 Inactive --\u003e Active: received request Active --\u003e Unbound: unbind delay elapsed Unbound --\u003e Inactive: stop delay elapsed Unbound --\u003e Active: received request Two time constants govern how the expected state of worker groups evolves:\nUNBIND_DELAY delay until the queue transitions from Active to Unbound STOP_DELAY delay until the worker group is stopped The state tracker has the following API:\nenum WGStatus { Active, Unbound, } struct Generation(u64); struct PoolState { generation: Generation, wgs: im::OrdMap\u003cString, WGStatus\u003e, } trait PoolStateTracker { fn new(initial_worker_groups: Vec\u003cString\u003e) -\u003e Self; /// Require some worker group to be active. The extra lifetime adds active duration compared to the configured spooldown schedule. /// This allows the worker activity processor to debounce activity events without lowering the active time of worker groups. /// Returns the state generation where this worker group starts being active. async fn require_worker_group(\u0026self, key: \u0026str, extra_lifetime: Duration) -\u003e Generation; /// Subscribe to a stream of target pool state updates async fn subscribe(\u0026self) -\u003e tokio::sync::watch::Receiver\u003cPoolState\u003e; } Request queues control loop The request queue control loop takes care of creating, binding, unbinding and stopping request queues. It subscribes to the pool state tracker, and reacts to state changes.\nIt exposes the following API, which is used by the orphan processor to wait for updates to propagate:\nstruct ReqQueueStatus { expected: Option\u003cWGStatus\u003e, actual: Option\u003cWGStatus\u003e, } struct ReqQueuesState { generation: Generation, queues: im::OrdMap\u003cString, ReqQueueStatus\u003e, } trait RequestQueueControlLoop { fn new(target: tokio::sync::watch::Receiver\u003cPoolState\u003e) -\u003e Self; fn subscribe(\u0026self) -\u003e tokio::sync::watch::Receiver\u003cReqQueuesState\u003e; } it runs the following control loop:\nfetch the set of currently active request queues control loop: for each queue in expected and not in current: attempt to create the queue if successful, update the current set for each queue in current and not in expected: attempt to remove the queue, if empty and unused if successful, update the current set for each waiting orphan processor, release if the condition is met The control loop runs when current != expected, or when expected changes.\nWorker groups control loop osrdyne is responsible for starting and stopping worker groups following demand. It it NOT responsible for scaling the number of workers per worker group.\nosrdyne runs the following control loop:\nreceive the set of expected worker groups from the pool state tracker build the set of running worker groups: query running worker groups from the worker group driver. If this fails, log and continue to the next iteration of the control loop. make both sets converge: for each worker group in expected and not in running: use the docker / kubernetes API to start the worker group. This must be idempotent. do not retry 1 for each worker group in running and not in expected: use the docker / kubernetes API to attemps to stop the worker group. This must be idempotent. do not retry 1 Worker activity processor As the number of worker activity events could be very high, we may not want to forward all of these to the pool state tracker: if multiple messages are received within a short time span, only the first one is relevant. A separate actor can be used to receive and dedup activity messages, and forward a low bandwidth summary to the pool state tracker.\nFailure mode analysis The worker fails to parse a message This is an application layer error: the worker must respond, and indicate that something went wrong\nThe worker dies or stalls when processing a message RabbitMQ will wait until the message TTL expires, and re-queues it. A limit must be set on the number of times a message can be re-queued using a delivery-limit. When this limit is reached, the poison message is sent to the dead letter exchange, and the client times out.\nosrdyne fails to start If exchanges are not setup, the client cannot publish messages If the appropriate work group is operational, the fast path can proceed Otherwise, requests pile up in the orphan queue, and the client ends up timing out Invalid worker key Because the key is an arbitrary string set by the client, it has to be processed carefully:\nthe format is defined as a convention between the client and workers. If the format isn’t right, it is up to the worker to publish a response to the client. key validity conditions is also up to the worker: if the key is supposed to be some object ID, but the object does not exist, the worker needs to start up and respond Even if the key does not conform to the convention established between the client and the worker, the worker needs to start and respond to all requests.\nWorkers fails to start A per-queue message TTL should be set to avoid requests accumulating indefinitly.\nWorkers failing to start will cause:\nmessages to accumulate in the queue. when message TTL is reached, it will get transfered to the dead letter queue the client will time out awaiting a response Multiple ordyne daemons are started on the same pool It shouldn’t be an issue, as:\nall operations done on startup are idempotent before doing anything, the daemon has to start listening as an exclusive consumer of the dead letter and orphan queues Known limitations Latency, publisher confirms and reliability Without publisher confirms, networker or broken failure can result in message loss. However, publisher confirms add quite a bit of latency (about 200ms), as it ensures messages are persisted to disk if the queue is durable.\nWe should use publisher confirms for responses and orphan transfers, and leave the decision of whether to do it for requests to the client.\nAt least once semantics Most things in this protocol have at least once semantics if publisher confirms are used:\nrequest delivery to workers: if osrdyne is restarted while transfering an orphan to its destination, the orphan may be transfered twice response delivery to clients: if a worker takes slightly too long to ACK a message, but still responds, it may be requeued and re-processed, and thus responded to twice Design decisions Using RabbitMQ To implement this solution, we rely on a combination of features unique to RabbitMQ:\neach worker type needs a separate exchange and configuration when a message cannot be routed within a worker type’s exchange, it is redirected to an alternate exchange managed by the worker manager dead lettering is leveraged to generate protocol errors the worker manager uses the RabbitMQ HTTP API to list queues In addition to its attractive feature set, RabbitMQ has:\nvarious useful quality of life features, such as direct reply and per-message TTL long demonstrated its reliability multiple engineers on staff experienced with the tool Queues are created by osrdyne At some point, we explored the possibility of RPC clients creating queues. osrdyne would react to queue creation by starting workers. If the queue were to be unused for a while, osrdyne would stop workers and delete the queue.\nThis creates a race condition on queue deletion:\nosrdyne sees that the queue is empty the client ensures the queue is created osrdyne deletes the queue the client attempts to publish a message to the now deleted queue We thus decided to move the responsibility of queue management to the osrdyne, and implement a mechanism to ensure messages cannot be dropped due to a missing queue.\nosrdyne republishes orphan messages Initially, we though of a solution whereby osrdyne’s orphan processor uses dead lettering to send messages back to their original exchange. This is in fact a bad idea, as dead lettering inhibits per message TTL.\nInstead, the orphan processor has to proxy messages back to their original exchange. This proxying process can cause requests to get delivered multiple times to the target queue.\nosrdyne responds to dead lettered messages If a message is dead lettered for some reason (expired TTL, delivery limit, max queue length), we figured it would be best to give the client some idea that something went wrong.\nThe worker protocol thus has to allow the client to distinguish protocol errors from worker responses.\nMessages are only ACKed by workers once processed If messages are ACKed on reception:\nprocessing time is not limited by message timeout (which is arguably not a feature) the broker does not attempt re-delivery if the worker were to stop and not respond for some reason If messages are ACKed once processed:\nmessages whose processing time exceeds TTL will be re-queued, even if the worker is still processing the message. This can result in multiple responses being delivered. if the worker crashes or is stopped, the message will be re-queued We decided to rely on a delivery-limit policy to handle poison messages, and ACK messages once processed.\nReport worker activity using AMQP osrdyne needs to maintain queue usage statistics in order to know when worker groups can be stopped. At first, we considered having workers use valkey to store the timestamp of the last processed message for the queue. We decided against it as:\nit would mean the workers store a timestamp directly in database, read by a supervisor process. it’s a pretty bad design it adds an additional database to the RPC architecture, for little to no benefit compared to just using rabbitmq if one of the workers has its clock drift by more than the worker group expiration time compared to osrdyne, the worker group will get stopped any worker can get the pool deleted by forcing the timestamp to an old value it adds a failure mode: if osrdyne / workers are unable to reach valkey, weird bugs may ensue Instead, we decided to require worker to publish activity updates to a dedicated queue. This queue can be watched by osrdyne, which can use these events to know when to stop a worker group.\nMake worker group lifetime decisions in a separate actor The lifetime of worker groups is influenced by three types of asynchronous events:\nworker activity orphan requests worker group spooldown deadlines When the orphan processor gets a request, it needs to create the worker group’s request queue before it can proceed to forward the message.\nIf queues were created and deleted asynchronously when these events are received, it would introduce a race condition:\nthe orphan processor creates the queue the queue gets deleted because it expired at the same time the orphan processor forwards the message, which gets lost We found multiple solutions for this issue:\nprocess all asynchronous events in a single actor. This was not deemed viable because worker activity processing is work intensive, and orphan request processing is latency sensitive. having a single actor create and delete queues (the request queues control loop) and making the orphan processor wait until the control loop creates the queue Unbind the queue and wait before stopping workers In a previous design, we tried to delete work queue in one go. It created a race condition issue on queue deletion, caused by the fact ordyne does not get direct notifications of when messages are received on a work queue:\nwe decide to stop the worker group work is received on the queue, but we aren’t made aware as no worker is up we try to delete the queue, but cannot do so without loosing messages We could think of two fixes for this issue:\nimplement a two stage shutdown, where no work can get to the queue for a while before workers are stopped detect that the queue still has messages after workers have stopped, and start workers back up We decided to implement two stage worker group shutdown:\nif no activity is register for UNBIND_DELAY, unbind the work queue wait for a while to see if any worker picks up work from the queue and notifies osrdyne, which would rebind the queue if no orphan nor worker activity is registered for STOP_DELAY, stop workers and delete the queue The control loop is designed to make the state of all worker groups converge at once. Retrying convergence for one worker group adds latency to convergence for all worker groups. ↩︎ ↩︎\n","categories":"","description":"","excerpt":"TODO: create another document describing RPC interactions between core …","ref":"/en/docs/reference/design-docs/scalable-async-rpc/","tags":"","title":"Scalable async RPC"},{"body":"Open source is a software development practice, where the software’s source code1 :\nusually developed by multiple actors, in an open and transparent way free and available for all can be modified or used for derivative work by anyone can be freely distributed In practice, open source is both a legal framework for collaborative work, and a set of practices.\nOSRD and Open Source Applied to OSRD, Open Source has multiple avantages :\nthe algorithms and know-how developed with the project are free for all development cost and results are shared between actors it makes interoperability between software systems easier by helping make the landscape more homogeneous and standardized helps focus collaboration around common interests enables actors to tailor the software to their own interests enables researchers to contribute and benefit from the project it allows public actors to meet their transparency goals Using open source to enable industrial collaboration is not a new idea:\nBlender is a modelling, rendering and 3D animation software, which has recently become major point of industry collaboration for this industry Linux, a Windows alternative used by Google, Microsoft, Amazon, Apple, most websites, cloud platforms, mobile phones, routers, and more. All these companies rely on and contribute to Linux tremendously Android is the common base software for most phones. Phone manufacturers regularly contribute to android PostgreSQL, MySQL, SQLite and other open-source databases collectively dominate the database market. Any actor with special needs can improve an existing open-source tool rather than create a new one. Both Firefox and Chrome are Open Source Wordpress is the CMS which runs 43% of all websites. A flock of companies contribute to Wordpress and make extensions Odoo is a powerful modular ERP, which has a community not unlike Wordpress All these projects share the common property of being essential to a number of companies, without being part of what these companies sell.\nIt thus makes sense for these companies to collaborate with peers and competitors to build common tools, which makes exchanges easier and helps improve quality of service for all.\nProcesses These processes are not specific to open source: many companies work in a similar way. In practice, most open-source software is developed using a forge. Through this forge, developers and users can access the source code, report bugs, plan tasks, and integrate new changes to the code. Anyone can suggest a change, report a bug or plan a task.\nAll changes go through a peer review, not unlike those used by the scientific community. Reviewers are software developers most familiar with components affected by the change.\nChanges are integrated into the code base when everyone involved agrees to. Maintainers are responsible for keeping the project working and consistent. Maintainers are chosen among developers by developers. What motivates whether to integrate a change or not is technical viability: the goal of everyone involved is to maintain high level of service and quality standard.\nSource code is a set of text documents which describes how a piece of software works. It’s the result of the work of software developers. ↩︎\n","categories":"","description":"OSRD and Open Source","excerpt":"OSRD and Open Source","ref":"/en/about/opensource/","tags":"","title":"Open Source"},{"body":"L’open source est une pratique de développement logiciel, où le code source1 du logiciel est :\ngénéralement développé de manière ouverte et collaborative, par des acteurs variés accessible et gratuitement utilisable par tous tout le monde est libre de proposer un changement, ou créer un logiciel dérivé redistribuable par tous En pratique, l’open source est à la fois un cadre légal pour le travail collaboratif, et un ensemble de pratiques.\nApplication à OSRD Dans le contexte d’OSRD, ce modèle a de multiples avantages :\nles algorithmes et le savoir-faire développé est ouvert à tous les coûts de développement et résultats sont mutualisés entre les différents acteurs permet de faciliter l’interopérabilité entre systèmes d’information en facilitant la standardisation et l’uniformisation permet de catalyser la collaboration d’acteurs aux objectifs communs permet à chaque acteur d’adapter librement le logiciel à ses besoins il permet aux organismes de recherche publics de contribuer directement, et de profiter du projet il permet aux acteurs publics de répondre à leurs impératifs de transparence L’utilisation d’un projet open source comme catalyseur de collaboration industrielle a de nombreux antécédents :\nBlender est un outil de modélisation, rendu, et animation 3D très complet, qui est récemment devenu une plateforme de collaboration industrielle majeure pour l’industrie audiovisuelle Linux, une alternative à Windows qui équipe Google, Microsoft, Amazon, Apple, la plupart des sites internet, plateformes cloud, téléphones, routeurs, et bien plus. Toutes ces entreprises contribuent et se reposent énormément sur Linux Android est une base commune pour la majorité des téléphones vendus. Les fabriquants contribuent régulièrement à Android PostgreSQL, MySQL, SQLite et d’autres bases de donnée open source dominent collectivement ce marché. Un acteur aux besoins inédits peut contribuer à un outil open source plutôt qu’en créer un nouveau. À la fois Firefox et Chrome sont Open Source Wordpress est le CMS au coeur de 43% des sites internet en activité. Une armée d’entreprises contribuent et produisent des extensions Odoo est un ERP modulaire très complet, à la communauté similaire à Wordpress Toutes ces projets ont en commun d’être essentiel au business d’un grand nombre d’entreprises, sans pour autant être ce que l’entreprise commercialise.\nAinsi, ces entreprises décident de collaborer avec leurs pairs ou concurrents à des outils communs, afin de faciliter les échanges et d’améliorer la qualité de leur service.\nFonctionnement pratique Ce mode de fonctionnement n’est pas spécifique à l’open source : beaucoup d’entreprises adoptent un fonctionnement identique, à la différence près qu’il est maintenu privé. En pratique, les logiciels libre sont développés via une forge. Cette forge donne accès au code source, un outil de gestion des bugs / tâches, et un outil servant à intégrer des changements dans le code. Tout le monde peut proposer un changement, signaler un bug ou proposer une tâche.\nLes propositions de changement sont soumis à une revue par les pairs, semblables à celles de la communauté scientifique. Les individus en charge de la revue (les reviewers) sont ceux qui sont les plus familliers avec les composants affectés par le changement.\nLes changements sont intégrés par des mainteneurs sur la base du consensus entre reviewers. Les mainteneurs sont responsables de la cohérence technique du projet, et obtiennent cette position par consensus. L’intégration des changement n’est motivée que par leur viabilité technique : l’objectif des mainteneurs et reviewers est de s’assurer que le projet reste de bonne qualité.\nLe code source est un ensemble de documents texte qui définit comment fonctionne une application. C’est le produit du travail de développeurs logiciels. ↩︎\n","categories":"","description":"OSRD et l'Open Source","excerpt":"OSRD et l'Open Source","ref":"/fr/about/opensource/","tags":"","title":"Open Source"},{"body":"Cette section est destinée à exposer les principes généraux relatifs :\naux signaux aux régimes d’exploitation des lignes (à venir) aux différents systèmes d’espacement des trains La grande majorité des informations de cette section sont extraites du document pédagogique de l’Établissement Public de Sécurité Ferroviaire (EPSF) édité le 05 juillet 2017.\n","categories":"","description":"Les signaux, régimes d'exploitation des trains, et les systèmes d'espacement des trains","excerpt":"Les signaux, régimes d'exploitation des trains, et les systèmes …","ref":"/fr/docs/railway-wiki/signalling/","tags":"","title":"Signalisation"},{"body":"Open Data is the practice of making data public accessible under a permissive license. It is not the same as open source, which only applies to software.\nOpen data and open source have a symbiotic relationship : without open data, an open source railway software can only be used by industry insiders. Managing data access is hard, expensive, often not necessary, and reduces the availability of critical data.\nAlone, open data already brings a number of key benefits:\ncompanies can use open data in their products, which also promotes railway services researchers can study the data immediately, and can find the data by themselves Yet, open data used by an open source toolbox open up new prospects:\ncompanies and researchers can use the open source tools to analyse the data, which greatly reduces the barrier to entry by alleviating the need for custom or paid-for tools customers can use the toolbox to improve how they use railway services If multiple actors have open data exploitable by an open source tool, these datasets can be combined and used to provide and plan for common services.\nOSRD and Open Data having rolling stock and infrastructure open data enables anyone to simulate trains, study and evaluate the railway network having timetable open data enables anyone to study rail network usage ","categories":"","description":"OSRD and Open Data","excerpt":"OSRD and Open Data","ref":"/en/about/opendata/","tags":"","title":"Open Data"},{"body":"L’open data, c’est la pratique de rendre publiquement accessible des données sous une license permissive. C’est une pratique distincte de l’open source, qui ne s’applique qu’au logiciel.\nOpen data et open source ont une relation symbiotique : sans Open Data, un logiciel open source ferroviaire n’est utilisable que par des initiés. Gérer l’accès aux données est difficile, coûteux, souvent inutile, et réduit l’accessibilité de données pourtant essentielles.\nSeul, l’open data présente déjà un certain nombre d’avantages clés :\ndes entreprises peuvent utiliser ces données dans leur produit, ce qui promeut les services ferroviaires des chercheurs peuvent étudier les données sans démarche particulière, et découvrir eux-même les données disponibles Des données open data exploitées par une suite d’outils open source ouvrent de nouveaux horizons :\nles chercheurs et entreprises peuvent maintenant exploiter les données sans avoir à créer leurs propres outils, ou en acquérir par leurs propres moyens les clients de l’entreprise peuvent utiliser outils et données pour améliorer leur usage des services Si plusieurs acteurs mettent en open data des données exploitables par un même logiciel open source, il devient également possible de recouper les données et de fournir et plannifier des services communs.\nDans le cadre d’OSRD si les données de matériel roulant et d’infrastructure sont en open data, alors il est possible pour tous de simuler des trajets, d’étudier et évaluer le réseau ferroviaire si les données de grilles horaires sont accessibles en open data, alors il est possible pour tous d’étudier l’usage du réseau ","categories":"","description":"OSRD et l'Open Data","excerpt":"OSRD et l'Open Data","ref":"/fr/about/opendata/","tags":"","title":"Open Data"},{"body":"Here’s a list of the big features OSRD wants to support. The order of items depends on priority (the higher the item, the more valuable it is). This roadmap is spread over a couple of years.\nAdd ERTMS signaling system support. A fine-grained permission system. Support cyclic train schedule. Improving Netzgrafik-Editor integration. Send STDCM trains to external services for storage and processing. Create annual transport plan service. Support a linear referencing LRS commonly used in the railway industry. Usage of railway mileposts. Revamp the infrastructure editor. New dynamic simulator. Simulate a timetable on an infrastructure and observe generated delays. Versioning infrastructures. Revamp train simulation v3. If you’d like to push for one of these features, or if you have ideas for what OSRD could do in the future, don’t hesitate to join the project!\n","categories":"","description":"Macroscopic Roadmap","excerpt":"Macroscopic Roadmap","ref":"/en/about/roadmap/","tags":"","title":"Roadmap"},{"body":"Voici une liste des principales fonctionnalités que OSRD souhaite ajouter, par ordre de priorité. Cette feuille de route s’étale sur plusieurs années.\nAjout du système de signalisation [ERTMS] (https://fr.wikipedia.org/wiki/Syst%C3%A8me_europ%C3%A9en_de_gestion_du_trafic_ferroviaire). Système de permission fin. Support du cadencement des trains. Améliorer l’intégration de Netzgrafik-Editor. Envoyer des trains STDCM à des services externes pour stockage et traitement. Création d’un plan de transport annuel. Support d’un système de référencement linéaire LRS couramment utilisé dans l’industrie ferroviaire. Utilisation de point kilométrique. Refonte de l’éditeur d’infrastructure. Ajout d’un simulateur dynamique. Simuler une grille horaire sur une infrastructure et observer les retards générés. Gestion de version des infrastructures. Refonte du calcul de marche. Si vous souhaitez pousser l’une de ces fonctionnalités, ou si vous avez des idées sur ce que OSRD pourrait faire à l’avenir, n’hésitez pas à rejoindre le projet !\n","categories":"","description":"Roadmap macroscopique","excerpt":"Roadmap macroscopique","ref":"/fr/about/roadmap/","tags":"","title":"Roadmap"},{"body":"Les trains doivent circuler en toute sécurité. Les risques majeurs liés aux circulations ferroviaires sont les suivants :\nle rattrapage des trains qui circulent dans le même sens sur la même voie ; la prise en écharpe, c’est-à-dire la collision latérale de trains qui circulent sur des itinéraires convergents ; le nez à nez, c’est-à-dire la collision frontale de trains qui circulent en sens contraire sur la même voie ; le déraillement ; la collision avec un obstacle. On prévient ces risques notamment par :\nla mise en place d’une signalisation ; l’établissement d’un régime d’exploitation de la ligne (double voie, voie banalisée, voie unique) ; la mise en place d’un système d’espacement des trains ; la mise en oeuvre de procédures d’exploitation. D’autres dispositifs techniques contribuent également à couvrir ces risques tels que :\nles installations de sécurité, notamment les enclenchements des postes d’aiguillage ; le DAAT qui est un dispositif permettant d’assurer l’arrêt automatique des trains en cas de franchissement intempestif d’un point d’information avec signal d’arrêt fermé ; le KVB, le COVIT (TVM) sont des exemples de systèmes de contrôle de la vitesse, avec contrôle de franchissement des signaux non franchissables ; le système de contrôle commande des trains, intégré dans l’ETCS. La sécurité des circulations repose aussi sur le respect rigoureux des consignes et instructions opérationnelles par tous les agents concernés par la circulation des trains.\nCes procédures sont de la responsabilité des exploitants ferroviaires. Elles sont décrites dans le manuel du système de gestion de la sécurité (SGS) qu’ils établissent et qui fait l’objet d’une instruction par l’EPSF chargé de délivrer le certificat ou l’agrément de sécurité.\n","categories":"","description":"","excerpt":"Les trains doivent circuler en toute sécurité. Les risques majeurs …","ref":"/fr/docs/railway-wiki/signalling/risks/","tags":"","title":"Les risques ferroviaires"},{"body":"Principe Pour transmettre au conducteur des ordres et informations liées à la sécurité des circulations, il est fait usage de signaux. Ces signaux peuvent indiquer des informations relatives aux limites de vitesse, peuvent servir à garantir l’espacement des trains ou donner des indications diverses telles que l’accès à des voies de service, des ouvrages d’art à gabarit réduit, etc.\nLa signalisation à main La signalisation au sol La signalisation au sol est normalement implantée à gauche ou au-dessus de la voie concernée.\nSignaux de protection Les signaux de protection sont destinés à interdire l’accès à un itinéraire, à une aiguille, à un PN, etc. Ils sont généralement manœuvrés depuis des postes par des agents de SNCF Réseau.\nSignaux de cantonnement Les signaux de cantonnement sont destinés à assurer l’espacement des circulations de même sens.\nSur les sections de lignes équipées en block automatique (BA), les signaux de cantonnement se ferment automatiquement dès l’occupation du canton et restent fermés jusqu’à sa complète libération.\nSur les sections de lignes équipées en block manuel (BM), les signaux de cantonnement sont manœuvrés depuis des postes par des agents du service du GI chargé de la gestion des circulations.\nSignaux d’annonce d’arrêt Le carré, le sémaphore et le feu rouge clignotant sont normalement annoncés à distance par un avertissement qui peut lui-même être précédé, en signalisation lumineuse, par un feu jaune clignotant.\nToutefois, les signaux qui ne peuvent être abordés qu’en marche à vue ou en marche en manœuvre ne sont normalement pas annoncés (par exemple, le guidon d’arrêt). Il en est de même des signaux situés sur voie principale à la sortie des gares en impasse.\nSignaux d’indication de marche Le feu vert indique au conducteur que la circulation en marche normale est autorisée, si rien ne s’y oppose.\nSur les sections de ligne où la vitesse des trains est supérieure à 160 km/h, un feu vert clignotant précède généralement l’avertissement ou le feu jaune clignotant.\nSignaux de limitation de vitesse Ils limitent à un taux déterminé la vitesse des trains sur une partie de voie ou au franchissement de certains points particuliers (aiguille, traversée de gare, etc.).\nLes limitations permanentes de vitesse (en complément de celles pouvant figurer dans les RT) Sur des parties de voie par tableau indicateur de vitesse (TIV) ordinaire Au franchissement de certains points particuliers (exemple des aiguilles)\nRalentissement à 30 km/h en signalisation lumineuse Ralentissement à 60 km/h en signalisation lumineuse TIV mobiles Ces tableaux peuvent être lumineux ou mécaniques ; lorsqu’ils sont ouverts ils présentent une bande verticale blanche continue.\nSi cela est nécessaire, l’emplacement de l’aiguille (ou de la première aiguille dans le cas d’aiguilles successives) est repéré par un chevron pointe en bas.\nLes limitations temporaires de vitesse Cette signalisation s’applique sur des parties de voie (chantiers de travaux, etc.) sur lesquelles une limitation temporaire de vitesse doit être observée.\nSignaux indicateurs de direction Ils renseignent les conducteurs sur la direction géographique qui leur est donnée.\nSignaux caractéristiques de prescriptions particulières Ils renseignent les conducteurs sur des particularités.\nOn trouve :\ndes tableaux des pancartes la bande lumineuse jaune la croix de Saint-André (annulation des signaux) Exemples de tableaux Exemples de pancartes Bande lumineuse jaune horizontale La bande lumineuse jaune horizontale est utilisée en complément de l’avertissement. Elle indique au conducteur que son train est dirigé vers une voie à quai de courte longueur ou bien que sa longueur se trouve réduite.\nCroix de Saint-André (annulation des signaux) Signalisation de sortie de certains faisceaux ou groupes de voies convergentes Elle peut être constituée de :\nLa signalisation de cabine Sur les lignes à signalisation de cabine, le système transmet de manière continue (ou discontinue) en cabine de conduite des ordres et une consigne de vitesse associée éventuellement à une distance but. La signalisation de cabine peut être complétée par une signalisation au sol dans certains cas pour :\nrepérer les points à ne pas dépasser, par exemple : donner des ordres de traction électrique, des informations aux points d’entrée et de sortie du domaine de signalisation de cabine, etc. Des pancartes ou tableaux indiquent ces ordres et informations.\nCes repères, pancartes ou tableaux sont implantés :\nà gauche de la voie sur les plateformes à une seule voie ; côté piste, à l’extérieur sur les plateformes à deux voies ; dans le cas de plan de voie plus complexe, les pancartes ou tableaux sont fléchés. Nota : les repères ETCS et de la TVM ne sont pas fléchés du fait de leur graphisme indiquant la voie à laquelle ils s’adressent.\nPoint de transition de signalisation (entrée sur LGV, armement de la signalisation de cabine) Le point de transition de signalisation (tableau CAB), ainsi que l’armement de la signalisation de cabine, se situent à hauteur ou immédiatement en aval du dernier signal au sol (signal carré).\n","categories":"","description":"","excerpt":"Principe Pour transmettre au conducteur des ordres et informations …","ref":"/fr/docs/railway-wiki/signalling/signals/","tags":"","title":"Les signaux"},{"body":"Définition Ensemble des règles d’exploitation, c’est-à-dire des règles appliquées pour organiser et assurer le trafic, propres à une ligne en fonction des installations mises en œuvre pour en assurer l’exploitation.\nLes principaux régimes d’exploitation sont : la voie unique, la voie banalisée, la double voie.\nPrincipe Il ne faut pas confondre régime d’exploitation et nombre de voies sur une plateforme, car il existe des plateformes à 2 voies qui ne sont pas des « double voie », des plateformes à 3 ou 4 voies qui sont des « double voie », des plateformes à 1 seule voie qui ne sont pas des « voie unique ».\nLes appellations et définitions de ces régimes d’exploitation sont donc très importantes, car elles entraînent notamment des contraintes particulières de conduite que ce soit en situation normale ou dégradée (implantation des signaux, marche à vue ou règle spéciale de certains signaux par exemple).\nEn voie unique, l’organisation de la circulation des trains des deux sens sur une même voie génère un risque spécifique de nez à nez en plus du risque de rattrapage également présent sur les lignes à double voie.\nL’exploitation sous le régime de la « double voie » permet, par conception, d’éviter le risque de nez à nez, compte tenu de l’affectation des trains à un sens de circulation par voie. Cependant sur certaines lignes, la circulation des trains s’effectue selon l’un des deux régimes suivants : la voie unique ou la voie banalisée.\n","categories":"","description":"","excerpt":"Définition Ensemble des règles d’exploitation, c’est-à-dire des règles …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/","tags":"","title":"Les régimes d’exploitation des lignes"},{"body":"Définition Le système d’espacement des trains de même sens, est destiné à éviter les rattrapages et consiste à fractionner la ligne en plusieurs cantons dont l’entrée est protégée par un signal d’arrêt.\nPrincipe Compte tenu de leur masse importante, de leur vitesse élevée, de la faible adhérence rail-roue, les trains ont besoin d’une distance importante pour s’arrêter.\nDe ce fait, la distance nécessaire pour obtenir l’arrêt est généralement plus grande que la partie de voie visible par le conducteur. Dans ces conditions, le conducteur d’un train en marche ne voyant pas à temps la queue d’un train arrêté ou circulant à plus faible vitesse devant lui risquerait de le heurter.\nPour prévenir le risque de rattrapage : un dispositif d’espacement des trains appelé « cantonnement » est mis en place selon les principes suivants :\nla ligne est divisée en portions de voie appelées « cantons » l’entrée de chaque canton est normalement commandée par un signal un seul train est normalement admis dans chaque canton aucun train ne peut normalement pénétrer dans un canton occupé, du fait du maintien à la fermeture du signal d’entrée du canton durant tout le temps de son occupation Dans certains cas particuliers, la pénétration d’un train dans un canton occupé ainsi que les modalités de franchissement du signal d’entrée du canton sont prévues dans une procédure propre à chaque mode de cantonnement.\nLes différents modes de cantonnement On distingue :\nle cantonnement téléphonique le block manuel par appareils (BM) le block automatique : lumineux (BAL) ou à permissivité restreinte (BAPR) l’ETCS 1 généralement superposé à la signalisation au sol l’espacement sur lignes à grande vitesse (TVM, ETCS 2) Sur les sections de lignes équipées en cantonnement téléphonique ou en block manuel par appareils, les signaux de cantonnement sont manoeuvrés au sol ou depuis des postes par des agents du service du gestionnaire d’infrastructure (GI) chargé de la gestion des circulations dénommés « gardes ».\nSur les sections de lignes équipées en BAL ou BAPR, les signaux de cantonnement se ferment automatiquement dès l’occupation du canton et restent fermés jusqu’à sa complète libération.\nSur les sections de lignes à signalisation de cabine, équipées en TVM ou ETCS, les informations liées à l’espacement des trains sont données au conducteur automatiquement directement en cabine de conduite.\nPour déterminer le mode et le cas échéant les postes de cantonnement d’une section de ligne, il faut consulter les RT.\n","categories":"","description":"","excerpt":"Définition Le système d’espacement des trains de même sens, est …","ref":"/fr/docs/railway-wiki/signalling/spacing/","tags":"","title":"Les systèmes d'espacement des trains"},{"body":"Elles sont principalement exploitées selon les dispositions du régime général d’exploitation de la voie unique, certaines d’entre elles disposant d’un minimum d’équipement de signalisation sont désignées « voie unique à signalisation simplifiée ».\nD’autres lignes, peu fréquentées et fermées au service voyageur sont exploitées selon le régime de la voie unique à trafic restreint.\nIl existe aussi un régime d’exploitation en navette.\nEnfin d’autres lignes disposant d’installations de sécurité s’opposant notamment au nez à nez sont exploitées selon le régime de la voie banalisée.\n","categories":"","description":"","excerpt":"Elles sont principalement exploitées selon les dispositions du régime …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/","tags":"","title":"Les lignes à une seule voie"},{"body":"Définition Régime d’exploitation d’une ligne à deux voies (ou plus) dans lequel chaque voie est normalement affectée à la circulation des trains dans un sens déterminé.\nPrincipe Le risque de nez à nez Sur une ligne à deux voies, les circulations empruntent normalement la voie de gauche dans le sens de la marche (voie de droite sur les lignes désignées à la documentation d’exploitation).\nLa double voie est exploitée selon les modalités définies par SNCF Réseau qui prévoit que chaque agent du service de la gestion des circulations doit disposer en temps utile des informations nécessaires pour assurer le service de la circulation des trains, notamment les informations relatives à l’ordre théorique et réel de succession des trains, à l’horaire et aux voies de circulation des trains.\nDans certains cas, il peut être nécessaire (travaux, incidents, etc.) d’organiser la circulation des trains des deux sens sur une seule voie. Les circulations se déplaçant sur une voie en sens inverse du sens normal sont dites à « contresens » sur une installation de contre sens (ICS) ou sur une voie unique temporaire (VUT). Elles sont dites à « contre-voie » dans les autres cas.\nEn fonction des installations et équipements en place :\nutilisation d’installations qui s’opposent au nez à nez : installation de contre sens (ICS) : installations permanentes de contre sens (IPCS) ou installations temporaires de contresens (ITCS) ; voie unique temporaire à caractère permanent (VUTP) ; ou mise en place de procédures : voie unique temporaire (VUT) ; mouvement à contre voie. Le risque de rattrapage L’espacement est assuré selon les principes définis dans cette section. Sur une voie les signaux sont normalement implantés à gauche.\n","categories":"","description":"","excerpt":"Définition Régime d’exploitation d’une ligne à deux voies (ou plus) …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/","tags":"","title":"La double voie"},{"body":"Context The onboard computer of ETCS-enabled trains has to compute a number of position / speed curves. Here is how it works:\nbelow all the curves, the speed indicator is white above the indication curve, the speed indicator is yellow above the permitted curve, the speed indicator is orange above the warning curve, an alarm rings above the intervention curves, an emergency break intervention is triggered Inputs In order to compute any of these curves, a number of things are needed:\ntarget data (the destination of the braking curve, which can be EOA and SvL or LOA and MRSP) train data infrastructure data infrastructure manager constants standardized constants Train max speed length rotating mass T_traction_cutoff: the time it take to cut off traction braking model, either lambda or gamma: lambda (braking weight/mass) gamma (contant deceleration at a given speed) correction factors (k_dry and k_wet for gamma braking) for braking curves Infrastructure corrected gradients (it incorporates curvature) odometry balises location Processes Braking coefficients: A_brake_emergency is the expected emergency braking capability, without safety margins A_brake_safe is the emergency braking coefficient, with safety margins A_brake_service is the expected service braking capability, without safety margins Speed / distance targets EOA end of movement authority: the location until which the train is allowed to move SvL supervized location: the protected location Curves SBD supervised braking deceleration: intermediary result computed from EOA and A_brake_service EBD emergency braking deceleration: intermediary result computed from SvL and A_brake_safe All the curves below are cut below a given release speed:\nEBI (emergency break intervention) computed from EBD, shifted in position and space given rolling stock metadata SBI1 computed from SBD, shifted in time with Tbs1 SBI2 computed from SBD, shifted in time with Tbs2 FLOI (also called SBI, the intervention curve) the minimum of SBI1 and SBI2 WARNING (warning curve) computed as a shift of FLOI by Twarning PS (permitted speed curve): shift of WARNING by time Tdriver INDICATION is a shift of PS by time Tindication ","categories":"","description":"European Train Control System","excerpt":"European Train Control System","ref":"/en/docs/railway-wiki/signalling/spacing/ertms/etcs/","tags":"","title":"ETCS"},{"body":"Généralités ETCS est le système européen de contrôle commande des trains. La partie bord est interopérable. La partie sol peut être différente selon les pays tout en répondant aux mêmes objectifs de fonctionnalité.\nIl existe quatre niveaux différents dont deux sont en service : L’ETCS 1 et L’ETCS 2. L’ETCS 0 est interdit en France. L’ETCS 3 est encore à l’état de développement dans la plupart des pays de l’Union européenne.\nIl s’agit d’un système de signalisation de cabine et de contrôle de vitesse faisant appel aux trois composantes suivantes :\nsol : pour la gestion des circulations comprenant notamment l’espacement, la protection des points à protéger et des circulations bord : pour l’affichage des ordres et informations à destination du conducteur et le contrôle de la bonne exécution de ceux-ci, dénommé EUROCAB liaison : pour les échanges de données entre le sol et le bord : liaison ponctuelle unidirectionnelle du sol vers le bord par EURO BALISES, liaison radiotéléphonique continue et bidirectionnelle par GSM-R DATA pour ETCS2 dénommé EURORADIO. Sur le RFN, sont mis en oeuvre les niveaux d’exploitations suivants :\nL’ETCS1 sur certaines lignes parcourables jusqu’à 220 km/h. Il correspond à un système de signalisation de cabine, généralement superposé à la signalisation au sol existante, dont les informations entre le sol et le bord sont transmises ponctuellement par eurobalise.\nL’ETCS2 sur certaines lignes à grande vitesse. Il correspond à un système de signalisation de cabine dont les informations entre le sol et le bord sont transmises en temps utile ou cycliquement par liaison permanente GSM-R DATA.\nL’ETCS2 est un système qui ne nécessite pas la matérialisation des cantons sur le terrain.\nPréalablement à tout déplacement, les données relatives au train doivent être saisies ou paramétrées à bord. Ainsi, le système peut, à partir des données bord et sol, superviser le train, c’est-à-dire contrôler sa vitesse et ses déplacements et intervenir en cas de nécessité.\nLa détection d’une circulation sur une partie de voie est réalisée au moyen de circuits de voie ou de compteurs d’essieux. En ETCS2, la combinaison des équipements sol et bord est telle qu’elle ne nécessite, normalement, pas de signalisation complémentaire au sol.\nÉquipement bord Le bord est constitué d’un DMI, d’un EVC, de capteurs odométriques (de vitesse), d’antennes pour la lecture des PI ETCS, un modem GSM-R (Euroradio) pour ETCS2, d’une unité juridique d’enregistrement des paramètres d’exploitation, d’interfaces avec le train.\nLe DMI Le DMI est l’interface entre le conducteur et la machine. Il permet d’afficher les ordres et instructions en fonction des données sol et/ou bord. Le conducteur renseigne également le système par saisie de données.\nL’espacement des circulations et la protection des points dangereux se traduisent par l’affichage en temps utile d’une vitesse but et d’une distance but. La vitesse but doit être respectée par le conducteur au point défini par la distance but.\nEn « marche normale », le DMI indique au conducteur la vitesse autorisée qui ne doit pas être dépassée. Dans ce cas, il n’y a pas d’affichage de la distance but et de la vitesse but.\nUn secteur pouvant présenter différentes couleurs est utilisé pour indiquer les ordres de vitesse ou d’arrêt.\nEnfin, d’autres indications sont affichées telles que la signalisation de traction électrique, le niveau d’exploitation, le mode technique. Les changements d’indication au DMI peuvent être accompagnés d’indications sonores. Une zone en partie basse du DMI est également réservée pour l’affichage de messages textuels. Certaines informations complémentaires peuvent également être affichées par l’entreprise ferroviaire.\nDans cet exemple, le conducteur autorisé à circuler à 140 km/h maximum, circule à 125 km/h, il va devoir observer une phase de ralentissement afin de respecter la vitesse maxi de 100 km/h (vitesse But) à une distance de 2850 mètres (distance But).\nLe DMI utilise un code couleur, avec la signification suivante :\nblanc/gris clair/gris foncé : aucune action immédiate n’est exigée du conducteur jaune : le conducteur doit intervenir si la vitesse réelle est proche de la vitesse autorisée (risque de passer à la couleur orange en l’absence de réaction) orange : l’intervention est insuffisante (risque de passer à la couleur rouge en l’absence de réaction du conducteur) rouge : réaction trop tardive du conducteur, prise en charge par le système (peut revenir au jaune, au gris ou au blanc après une action appropriée) ETCS niveau 1 Transmission sol-bord Ce niveau utilise une transmission ponctuelle à l’aide de balises placées au pied des signaux et en amont. Ces balises (eurobalises) communiquent les données de signalisation au train.\nDétection des trains Le niveau 1 nécessite l’utilisation d’un système de détection des trains au sol (tel que des circuits de voie, compteurs d’essieux et autres). Toutes ces informations sont donc transmises ponctuellement au train. La cadence de l’information donnée pouvant être augmentée en jouant sur le nombre de balises, ou en installant une boucle (euroloop), équivalent d’une balise, mais longeant la ligne sur une certaine distance.\nETCS niveau 2 Transmission sol-bord Les données de signalisation sont transmises de manière permanente, via le réseau GSM-R. Le train communique constamment sa position (qu’il détermine avec un odomètre) au centre de contrôle qui lui communique en retour les actions à effectuer (vitesse, arrêt, etc.).\nDes eurobalises sont toujours présentes sur la voie pour recaler éventuellement l’odométrie embarquée.\nDétection des trains Un système de détection des trains au sol s’appuie sur l’existence des circuits de voie pour localiser un train aval sur un canton. Cette information est transmise au radio block center (RBC) qui gère ensuite l’espacement entre deux circulations. Le train suiveur reçoit une nouvelle autorisation de circulation par l’intermédiaire de la liaison radio GSM-R. Dès que le train aval libère un canton le poste central de commande reçoit l’information correspondante du sol qui est transmise par liaison radio au train suiveur.\nAvantage Le niveau 2 rend disponible quasi immédiatement une information « libératoire » pour le train suiveur et contribue ainsi à augmenter la fluidité. Cette immédiateté est la différence par rapport à la signalisation conventionnelle, où une demi-minute est parfois nécessaire pour libérer un aiguillage alors que le train est déjà bien loin.\nLes modes techniques Les modes techniques utilisés sur le RFN sont :\nMode FS : Conduite en supervision complète.\nToutes les données train et voie sont disponibles à bord.\nLe DMI affiche :\nla vitesse réelle du train et la vitesse autorisée lors de l’approche d’un EOA, d’un repère d’arrêt ETCS ou un heurtoir, la vitesse but et la distance but Le système « bord » supervise la vitesse, le déplacement du train, le respect de l’EOA matérialisé par un repère d’arrêt ETCS, un signal d’arrêt ou un heurtoir en ETCS1.\nMode OS : Conduite en marche à vue.\nToutes les données train et voie sont disponibles à bord sauf l’assurance de la libération de toute ou partie de la voie allouée au train.\nLe DMI affiche les mêmes indications qu’en mode FS.\nLe système « bord » assure également la supervision comme en mode FS.\nMode SR : Conduite sous la responsabilité des agents.\nCe mode technique est utilisé pour les situations dégradées et la procédure « Mise en service » lorsque le bord n’a pas reçu d’allocation de voie. Le système « bord » ne supervise que la vitesse du mode SR et le franchissement des repères d’arrêt ETCS et des signaux d’arrêt.\nMode SH : Circulation en manœuvre.\nCe mode technique est sélectionné par le conducteur pour les mouvements de manœuvre. Le système « bord » ne supervise que la vitesse du train.\nMode NL : Conduite d’un engin moteur non en tête du mouvement\nCe mode technique est utilisé en cas de pousse ou de double traction.\nProtection contre le rattrapage En mode FS, une vitesse autorisée affichée sans la présentation de l’EOA signifie « marche normale ».\nLa MA constituée d’un ou plusieurs cantons est allouée canton par canton, par ajout successif d’un canton. Si le canton en aval du dernier canton alloué est occupé le train doit être en mesure de s’arrêter avant l’entrée de ce canton. Le conducteur est alors avisé par une indication sonore au DMI.\nDès lors, les indications de conduite (vitesse but égale à 0 et une distance but) permettant de respecter la courbe de freinage sont affichées.\nLe conducteur doit ralentir de façon à être en mesure de s’arrêter avant l’EOA, tout en respectant la vitesse autorisée.\n","categories":"","description":"European Train Control System","excerpt":"European Train Control System","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/etcs/","tags":"","title":"ETCS"},{"body":"1. Les installations permanentes de contresens (IPCS) Principe Certaines sections de ligne comportent des installations permanentes de contresens (IPCS). Ces installations accessibles sans arrêt des trains à l’entrée, permettent à tout moment la circulation des trains à contresens sans que les conducteurs en soient préavisés autrement que par la signalisation.\nLe risque de nez à nez Des enclenchements de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre.\nLe risque de rattrapage L’espacement des trains circulant dans le sens normal est assuré dans les conditions habituelles.\nL’espacement des trains à contresens est assuré automatiquement.\nAvis au conducteur Les sections de ligne équipées d’IPCS sont désignées aux RT.\nLa circulation (entrée et sortie) sur IPCS est indiquée au conducteur par la signalisation.\n2. Les installations temporaires de contresens (ITCS) Principe L’ITCS est un régime temporaire d’exploitation permettant en double voie de faire circuler sur une voie des trains en sens inverse du sens normal.\nCes installations, accessibles sans arrêt des trains à l’entrée, permettent à tout moment la circulation des trains à contresens. Elles sont installées en prévision de chantier de travaux qui vont nécessiter l’obstruction d’une des deux voies.\nLe risque de nez à nez Des enclenchements de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre.\nLes ITCS ont leurs extrémités dans les gares les plus rapprochées encadrant le chantier de travaux prévu ou bien dans des postes de pleine voie existants ou créés à cet effet, considérés dès lors comme des gares. Si le chantier se déplace, les extrémités de l’ITCS sont reportées au fur et à mesure de la progression du chantier par phases successives, chaque phase faisant l’objet d’une ITCS distincte.\nLe risque de rattrapage L’espacement des trains circulant dans le sens normal est assuré dans les conditions habituelles.\nL’espacement des trains à contresens est assuré automatiquement.\nAvis au conducteur Les informations nécessaires aux conducteurs sont fournies par le gestionnaire d’infrastructure aux entreprises ferroviaires. Les particularités de signalisation et d’exploitation de l’ITCS sont mentionnées.\nUn schéma adapté à ses besoins peut compléter ces informations.\nLa circulation (entrée et sortie) sur ITCS est indiquée au conducteur par la signalisation.\n3. Circulation à contresens sur une ICS L’entrée d’un parcours à contresens sur une ICS est repérée par un tableau lumineux d’entrée à contresens (TECS). Ce tableau, normalement éteint, est groupé avec le panneau qui porte le carré protégeant l’aiguille d’entrée.\nExemple d’entrée à contresens à 60 km/h sur une section de ligne où la circulation normale se fait à gauche\nLes signaux s’adressant aux conducteurs des trains circulant à contresens sont :\nimplantés à droite (disposition inverse sur les lignes où la circulation se fait normalement à droite) ; répétés sur les engins moteurs. Les ICS peuvent comporter à contresens un ou plusieurs cantons.\nLa sortie d’un parcours à contresens est repérée par un tableau lumineux de sortie de contresens (TSCS). Ce tableau est groupé avec le panneau qui porte le signal « carré » protégeant l’aiguille de sortie.\n","categories":"","description":"","excerpt":"1. Les installations permanentes de contresens (IPCS) Principe …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-direction-installations/","tags":"","title":"Les installations de contresens (ICS)"},{"body":"Définition Régime d’exploitation d’une ligne dans lequel les trains des deux sens circulent sur la même voie, les dispositions à prendre pour éviter la rencontre de deux trains de sens contraire ne sont pas automatiques, mais résultent de procédures à appliquer par les personnels affectés à la circulation des trains, voire par les personnels des trains dans certains cas de lignes faiblement équipées. Ces dispositions sont définies par le gestionnaire d’infrastructure.\nPrincipe Le risque de nez à nez Les documents horaires sont conçus en respectant des obligations fondamentales telles que le croisement obligatoire de deux trains en gare, qui permettent d’éviter le nez à nez pour les trains de sens contraires.\nCe risque est donc avant tout couvert par le respect de l’ordre normal de circulation des trains figurant aux documents horaires.\nEn effet, le principe d’exploitation d’une ligne à voie unique s’effectue selon des modalités définies par le gestionnaire d’infrastructure, qui prévoient notamment le respect absolu de l’ordre théorique de succession des trains et en conséquence de l’ordre chronologique d’occupation de la voie unique. Une circulation qui n’est pas à son ordre, ne peut occuper la voie unique sans procédure.\nEn cas de modification de l’ordre théorique (retard, train supprimé, etc.), des procédures permettent d’organiser le nouvel ordre de circulation des trains (procédures de reports de croisement, dépassements, etc.).\nLe respect des procédures reposant sur l’humain, certaines lignes sont équipées d’une « barrière » technique de sécurité le block manuel de voie unique (BMVU - voir 4.4.2.). Des moyens d’arrêt complémentaires (DAAT, GSM/GFU, RST, coupure d’urgence si la ligne est électrifiée, …) peuvent être utilisés ou mis en place afin de réduire les conséquences d’une erreur humaine. Le risque de rattrapage Le risque de collision par rattrapage est couvert par le mode de cantonnement. Les différents modes de cantonnement existants sont :\nle cantonnement téléphonique (Voir - 4.3.) ; le cantonnement assisté par informatique (CAPI - voir 4.3.) ; le cantonnement assisté par informatique initié en 1995 (CAPI 95 - voir 4.3.) ; le block manuel de voie unique (BMVU - voir 4.4.2.). ","categories":"","description":"","excerpt":"Définition Régime d’exploitation d’une ligne dans lequel les trains …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track/","tags":"","title":"La voie unique"},{"body":"","categories":"","description":"Global System for Mobiles - Railways","excerpt":"Global System for Mobiles - Railways","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/gsm-r/","tags":"","title":"GSM-R"},{"body":"Définition Certaines lignes à voie unique sont désignées à la documentation d’exploitation comme « Lignes à voie unique à signalisation simplifiée ». Par rapport au régime général de la voie unique, ce type de ligne se distingue par la mise en œuvre d’un minimum d’équipements. Ils se limitent à une pancarte « gare » à distance et à un repère d’entrée.\nPrincipe Le risque de nez à nez Elles sont exploitées selon les modalités du régime général d’exploitation de la voie unique (notamment le respect de l’ordre théorique de circulation).\nLeur fonctionnement repose en outre sur l’arrêt général des circulations dans toutes les gares.\nLe risque de rattrapage La gestion de l’espacement est assurée par le cantonnement téléphonique.\nIl n’y a aucune barrière technique de sécurité, toute erreur humaine peut avoir des conséquences graves. Des boucles de rattrapage peuvent permettre de pallier ces erreurs (DAAT, CAPI, GSM/GFU, RST, coupure d’urgence si la ligne est électrifiée, etc.).\n","categories":"","description":"","excerpt":"Définition Certaines lignes à voie unique sont désignées à la …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-simplified-signalling/","tags":"","title":"La voie unique à signalisation simplifiée (VUSS)"},{"body":"Principe Les installations de voie unique temporaire à caractère permanent (VUTP) permettent la circulation occasionnelle des trains des deux sens sur une seule voie, entre deux gares, sans arrêt à l’entrée et sans préavis aux conducteurs.\nLes sections de ligne équipées de VUTP sont désignées aux RT.\nLe risque de nez à nez Des enclenchements de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre.\nLe risque de rattrapage L’espacement des trains circulant dans le sens normal est assuré dans les conditions habituelles.\nL’espacement des trains à contresens est assuré automatiquement.\nCirculation à contresens L’entrée d’un parcours à contresens est repérée par un tableau VUT groupé avec le panneau qui porte le carré protégeant l’aiguille d’entrée.\nLa présentation du tableau VUT indique au conducteur :\nque le train est dirigé et est autorisé à s’engager à contresens ; qu’à partir de ce tableau, les signaux qui le concernent sont implantés à droite. Exemple d’entrée à 30 km/h sur VUTP\nLa vitesse limite à ne pas dépasser est fixée à 70 km/h.\nLa sortie du parcours à contresens est repérée par un tableau « FIN de VUT » groupé avec le panneau qui porte le signal carré protégeant l’aiguille de sortie.\nLa présentation du tableau « FIN de VUT » indique au conducteur :\nque le train est parvenu à la fin du parcours à contresens ; qu’à partir de ce tableau, les signaux qui le concernent sont implantés à gauche. ","categories":"","description":"","excerpt":"Principe Les installations de voie unique temporaire à caractère …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track-of-permanent-nature/","tags":"","title":"La voie unique temporaire à caractère permanent (VUTP)"},{"body":"","categories":"","description":"General Packet Radio Service","excerpt":"General Packet Radio Service","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/gprs/","tags":"","title":"GPRS"},{"body":"Principe Lorsqu’une cause quelconque (incident, exécution de travaux, etc.), interdit l’utilisation d’une voie et en l’absence d’installations permettant la circulation dans les deux sens en sécurité sur l’autre voie (ICS, voie banalisée), la circulation des trains est organisée par les agents du service de gestion des circulations situés aux extrémités selon des procédures adaptées.\nLa VUT est donc un régime temporaire d’exploitation permettant, sur une ligne à double voie non équipée d’installation de contresens, de faire circuler les trains des deux sens sur une seule et même voie.\nLes trains devant circuler à contre sens sont arrêtés à l’entrée.\nLa circulation sur la VUT dans les deux sens se fait selon le principe de la demande et de l’accord de voie entre agents du service de la gestion des circulations.\nLa vitesse limite à contre sens est de 70 km/h.\nLa sortie de la VUT est repérée soit :\npar un signal carré implanté à gauche, à droite ou au-dessus de la voie ; par un signal d’arrêt à main. Organisation La VUT est établie entre les deux changements de voies utilisables les plus rapprochés qui en constituent les extrémités.\nLa VUT est organisée par l’agent du service de la gestion des circulations qui expédie les trains à contresens sur cette voie (gare B dans l’exemple ci-dessous) et qui doit aviser ou faire aviser les agents intéressés : agents des postes, des PN gardés, agents travaillant sur la voie ou les caténaires.\nCirculation sur la VUT Le risque de nez à nez L’expédition de tout train sur la VUT est subordonnée à un accord de voie donné par l’agent du service de gestion des circulations de l’autre extrémité de la VUT à l’agent-du service de gestion des circulations qui doit expédier le train.\nLe risque de rattrapage Les trains de sens normal sont cantonnés dans les conditions habituelles.\nLes trains circulant à contresens sont cantonnés téléphoniquement dans les conditions prévues pour la voie unique (voir 4.3.).\nAvis au conducteur En sens normal : aucun avis n’est fait au conducteur, les trains circulent sans arrêt à l’entrée.\nÀ contre sens : le conducteur est arrêté à l’entrée de la VUT puis informé par écrit par l’agent du service de la gestion des circulations qu’il va circuler à contresens en VUT.\nCet ordre écrit reprend les points ou zones du parcours sur lesquels le conducteur doit appliquer des prescriptions particulières.\nEn effet, les installations et la signalisation ne sont généralement pas prévues pour les circulations en sens inverse du sens normal (PN, limitations de vitesse, etc.).\n","categories":"","description":"","excerpt":"Principe Lorsqu’une cause quelconque (incident, exécution de travaux, …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/temporary-single-track/","tags":"","title":"La voie unique temporaire (VUT)"},{"body":"Définition Ce régime concerne des lignes fermées au service voyageurs qui ne comportent normalement pas de signaux. Les règles concernant le régime général d’exploitation de la voie unique ne sont pas applicables et sont remplacées par des modalités particulières définies par le gestionnaire d’infrastructure.\nPrincipe Une consigne locale d’exploitation adaptée à chaque VUTR précise les caractéristiques d’exploitation comme la vitesse de la ligne, la signalisation, les établissements, les liaisons téléphoniques, les PN, etc.\nElle est complétée par un programme de circulation qui comporte les horaires des trains devant circuler et précise les dispositions particulières concernant chaque train (trains entre lesquels l’espacement doit être assuré, croisements, etc.).\nCes lignes ne comportent normalement pas de signaux, les limitations de vitesse à observer sur les aiguilles ainsi que les autres limitations permanentes de vitesse sont inscrites à la consigne locale d’exploitation de la ligne ; elles ne sont pas rappelées par des signaux sur le terrain.\nPar principe, la vitesse de circulation ne dépasse généralement pas 50 km/h.\nAucun enclenchement n’est prévu. Chaque ligne dépend d’un agent de SNCF Réseau dénommé « chef de ligne ». La sécurité des circulations est assurée par le chef de ligne et par les agents des trains.\nNota : Les VUTR ne sont pas définies dans les RT.\n","categories":"","description":"","excerpt":"Définition Ce régime concerne des lignes fermées au service voyageurs …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-with-restricted-traffic/","tags":"","title":"La voie unique à trafic restreint (VUTR)"},{"body":"","categories":"","description":"Futur Système de Communications Mobiles Ferroviaires","excerpt":"Futur Système de Communications Mobiles Ferroviaires","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/frmcs/","tags":"","title":"FRMCS"},{"body":"Principe Lorsqu’une cause quelconque (incident, secours, travaux inopinés de courte durée, etc.), interdit l’utilisation d’une voie, en l’absence d’installation permettant la circulation dans les deux sens sur l’autre voie (ICS, voie banalisée) et qu’il n’est pas envisagé d’organiser une VUT (par exemple, du fait que très peu de circulations seront concernées), la circulation d’un train n’empruntant pas le sens normal se fait alors à contre-voie sur la voie non interceptée. Les trains devant circuler à contre-voie sont arrêtés à l’entrée.\nLe mouvement à contre-voie peut être effectué :\nd’un point quelconque vers un point situé en amont (ces points pouvant être un point de pleine voie, une gare, un évitement télécommandé) ; à l’intérieur d’une gare. Organisation Mouvements à contre-voie à l’intérieur d’une gare Lorsqu’un mouvement à contre-voie doit être effectué à l’intérieur d’une gare, il est organisé à l’initiative de l’agent du service de gestion des circulations.\nLe conducteur est avisé par l’agent du service de la gestion des circulations qu’il doit effectuer un mouvement à contre-voie et que le mouvement s’effectue :\nsoit comme une manœuvre. Dans ce cas le conducteur sera renseigné et guidé par des signaux de manœuvre ; soit par la transmission d’un ordre écrit ou d’une dépêche. Autres mouvements à contre-voie d’une gare vers la gare en amont ou de la gare en avant vers un point de pleine voie L’agent chargé d’organiser ce mouvement à contre-voie est l’agent du service de gestion des circulations de la gare dans laquelle le mouvement a son origine. d’un point de pleine voie vers la gare en arrière L’agent chargé d’organiser ce mouvement à contre-voie est l’agent du service de gestion des circulations de la gare dans laquelle le mouvement se termine. Dans ces deux cas, l’agent du service de la gestion des circulations, après avoir obtenu l’assurance que la partie de voie à parcourir est libre et le restera, remet un ordre écrit ou transmet une dépêche au conducteur pour circuler à contre-voie. En pleine voie Le conducteur est responsable de ce mouvement, lorsqu’il prend l’initiative d’exécuter ce mouvement : à la suite d’une rupture d’attelage lorsque le train peut être reconstitué ; à la suite d’un léger dépassement du point d’arrêt habituel dans un établissement PL. Circulation à contre-voie Après arrêt du train, l’agent du service de la gestion des circulations, selon le cas, remet au conducteur un ordre écrit ou le transmet par dépêche. Cet ordre reprend les points ou zones du parcours sur lesquels le conducteur doit appliquer des prescriptions particulières.\nEn effet, les installations et la signalisation ne sont généralement pas prévues pour les circulations en sens inverse du sens normal (PN, limitations de vitesse, etc.).\nLorsque le conducteur est en tête du mouvement, la circulation s’effectue en marche à vue sur tout le parcours effectué à contre-voie (le conducteur peut rencontrer un obstacle non protégé).\nLorsque le conducteur n’est pas en tête, la circulation est guidée par des signaux de manœuvre.\nLa fin du parcours à contre voie est généralement repérée soit :\npar un signal carré ; par un signal d’arrêt à main. ","categories":"","description":"","excerpt":"Principe Lorsqu’une cause quelconque (incident, secours, travaux …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/double-track-lines/opposite-track-movement/","tags":"","title":"Mouvement à contre-voie"},{"body":"Définition Régime d’exploitation d’une ligne sur laquelle la circulation d’un train ne peut être autorisée qu’après dégagement du train précédemment engagé, l’engagement et le dégagement se faisant au même point.\nPrincipe L’exploitation en navette consiste à n’autoriser la présence que d’une seule circulation sur la section de ligne concernée, cette circulation revenant à son point de départ, ce qui par conception limite les risques de collision de trains.\nToutefois, le programme peut inclure moyennant des procédures adaptées des mouvements de desserte, avec ou sans possibilité de garage (desserte origine terminus ou desserte en antenne).\nL’accès à la voie exploitée en navette est commandé par un signal muni du DAAT ou du KVB.\n","categories":"","description":"","excerpt":"Définition Régime d’exploitation d’une ligne sur laquelle la …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-shuttle/","tags":"","title":"L’exploitation en navette"},{"body":"","categories":"","description":"European Train Management Layer","excerpt":"European Train Management Layer","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/etml/","tags":"","title":"ETML"},{"body":"Définition Régime d’exploitation d’une ligne à une ou plusieurs voies parcourues par les trains des deux sens. Sur ces voies, des installations de sécurité s’opposent à l’expédition de deux trains de sens contraire à la rencontre l’un de l’autre. Sur les lignes à plusieurs voies banalisées, les trains d’un même sens peuvent circuler indifféremment sur l’une quelconque de ces voies.\nPrincipe Une voie banalisée peut être découpée en plusieurs intervalles (points entre lesquels il n’existe aucune possibilité de croisement ou dépassement).\nSur une voie, quel que soit le sens :\nles signaux sont normalement implantés à gauche ; le découpage éventuel d’un intervalle en cantons est identique. Le risque de nez à nez Les deux extrémités d’un intervalle de voie banalisée sont équipées de signaux d’arrêt non permissifs permettant d’arrêter et de retenir les trains se dirigeant vers l’intervalle. Elles sont reliées par un enclenchement entre itinéraires de sens contraires.\nLe risque de nez à nez est pris en charge notamment, par l’enclenchement entre itinéraires de sens contraire. Cet enclenchement agit directement sur le circuit de commande des signaux de protection donnant accès à l’intervalle. Il nécessite la mise en oeuvre de circuits de voie ou de compteurs d’essieux qui interviennent en outre dans le block automatique (cf. rattrapage ci-dessous).\nLes installations de sécurité s’opposent à l’expédition de deux trains de sens contraire dans le même intervalle. Cette interdiction est maintenue tant que l’intervalle est occupé.\nLe risque de rattrapage L’espacement est assuré automatiquement. En signalisation au sol, l’espacement des trains de même sens est assuré par le block automatique par l’intermédiaire de circuits de voie ou de compteur d’essieux. Selon l’importance du trafic, il peut s’agir de :\nBAPR : La longueur d’un canton de BAPR peut atteindre 15 km ou plus ; BAL : La longueur maximale d’un canton de BAL n’excède pas généralement 2,8 km ce qui permet un écoulement de trafic plus important. En signalisation de cabine, la TVM ou l’ETCS assurent l’espacement.\n","categories":"","description":"","excerpt":"Définition Régime d’exploitation d’une ligne à une ou plusieurs voies …","ref":"/fr/docs/railway-wiki/signalling/operation-modes/single-track-lines/single-track-two-ways/","tags":"","title":"La voie banalisée"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/blog/","tags":"","title":"Blog OSRD"},{"body":" Open Source Railway Designer À propos Github Une application web, open source, de conception d'infrastructure ferroviaire, d'horaires, d'analyse de capacité et bien plus ! Conception ferroviaire Modifiez l’infrastructure ferroviaire et les grilles horaires Analyse de capacité Détectez les conflits et visualisez la capacité Planning court-terme Ajoutez automatiquement de nouveaux trains dans une grille existante Développement Open source Tout le monde peut utiliser, redistribuer et développer OSRD Lire plus …\nGouvernance ouverte OSRD est conçu de manière partagée et publique, les décisions sont prises collégialement Lire plus …\nConçu pour l’interopérabilité Faites vos simulations à l’aide de formats d'infrastructure et de systèmes de signalisation sur mesure Sponsors ","categories":"","description":"","excerpt":" Open Source Railway Designer À propos Github Une application web, …","ref":"/fr/","tags":"","title":"OSRD"},{"body":"Le 13 décembre 2023, l’équipe OSRD a présenté ses premiers résultats lors d’une conférence.\nVoici la rediffusion des interventions :\nOuverture Présentations OpenRail ","categories":"","description":"","excerpt":"Le 13 décembre 2023, l’équipe OSRD a présenté ses premiers résultats …","ref":"/fr/blog/2023/12/13/presentation-osrd-1/","tags":"","title":"Présentation OSRD #1"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/blog/","tags":"","title":"OSRD Blog"},{"body":" Open Source Railway Designer About Github An open source web application for railway infrastructure design, capacity analysis, timetabling and more! Railway design Design railway infrastructure and timetables Capacity Analysis Detect conflicts and visualize capacity Short-term planning Automatically add new trains to an existing timetable Open source development Anyone can use, develop and distribute OSRD Read more …\nOpen governance OSRD is publicly designed, decisions are taken collectively Read more …\nDesigned for interoperability Make custom infrastructure formats and signaling systems work together Sponsors ","categories":"","description":"","excerpt":" Open Source Railway Designer About Github An open source web …","ref":"/en/","tags":"","title":"OSRD"},{"body":"Dreiländer hack, the annual meeting of German-speaking railway companies… but not only! On 29 and 30 June, the “Dreiländer hack” (the hackathon of the three countries) was held in Wien (Austria). Organised by DB (Germany), ÖBB (Austria) and SBB (Switzerland), this is an annual event dedicated to collaboration on shared railway-related challenges.\nWe were delighted to be invited to take part thanks to the OpenRail association, and this year’s theme being “Open Railways”, it would have been hard to refuse!\n24 hours to work together on a topic of common interest The 150 participants were divided into 16 working groups on a wide variety of topics such as:\nImagining a simple interface for ordering train paths (an important subject for the future of OSRD); Offering passenger information adapted to different disabilities; Optimizing the prioritisation of trains at junctions according to the number of passengers on board and on the platform (Motis project); Automatically identifying energy-consuming trains in storage; Calculating forecast maintenance dates from a historical database for each train component; Detecting speed measurement and GPS positioning errors on track inspection trains; Optimizing maintenance work to limit lost capacity; Facilitating passenger information with a GPT chatbot; Designing an easy-to-use display and ticketing interface for night trains across Europe. Challenge proposal by OSRD The challenge proposed by OSRD was to consolidate the railway data in OpenStreetMap, an open \u0026 collaborative database that we use as a source for railway infrastructure in Europe.\nThe objective was to develop an algorithm to identify 5 types of probable errors in the data:\nDisconnected tracks Suspicious switches Stations apart from tracks Weird angles Missing gauge info The subject was of interest and we formed a team of 10 people divided between the four participating companies. After a presentation of the challenge and of the OpenStreetMap data model, we looked for existing tools and chose to use Osmose, an open source application for detecting and displaying potential errors in OSM. We then split up to work on the 5 types of errors.\nFrom left to right: Christoph (DB), Klara (ÖBB), Frederik (SBB), Carl (SBB), Julius (DB), Jennifer (DB), Daniel (ÖBB), Céline (SNCF), Max (DB), Tristram (SNCF).\nResults After 24 hours of work, the result is an interactive map showing the various errors (click on the pictograms to show error details). You can find all the code that was produced on the OpenRail association’s GitHub.\nWe did not manage to integrate our analysers into Osmose within the allotted time, but that remains the target on which we’re going to continue working, so that all OpenStreetMap contributors can easily correct errors in railway data!\n","categories":"","description":"","excerpt":"Dreiländer hack, the annual meeting of German-speaking railway …","ref":"/en/blog/2023/07/19/osrd-at-dreil%C3%A4nder-hack-in-wien/","tags":"","title":"OSRD at Dreiländer Hack in Wien"},{"body":"Le Dreiländer hack, le rendez-vous des entreprises ferroviaires germanophones… mais pas que ! Les 29 et 30 juin derniers s’est tenu à Vienne (Autriche) le Dreiländer hack (le hackathon des trois pays). Organisé par Deutsche Bahn - DB (Allemagne), Österreichische Bundesbahnen - ÖBB (Autriche) et Schweizerische Bundesbahnen - SBB (Suisse), c’est un rendez-vous annuel dédié à la collaboration sur des problématiques ferroviaires communes.\nNous avons eu le plaisir d’être invité·es à participer dans le cadre de l’association OpenRail, et le thème de cette année étant “Open Railways” il aurait été difficile de refuser !\n24h pour travailler ensemble sur un sujet d’intérêt commun Les 150 participant·es se sont réparti·es en 16 groupes de travail sur des thèmes très variés tels que :\nImaginer une interface simple de commande de sillons (un sujet important pour l’avenir d’OSRD) ; Proposer de l’information voyageur adaptée aux différents handicaps ; Optimiser la priorisation des trains aux embranchements en fonction de l’affluence à bord et à quai (projet Motis) ; Identifier automatiquement des trains au garage qui consomment de l’énergie ; Calculer des dates de maintenance prévisionnelles à partir d’une base de données historique sur chaque composant du train ; Détecter des erreurs de mesure de vitesse et de positionnement GPS sur des trains d’inspection des voies ; Optimiser les chantiers de maintenance pour limiter la capacité perdue ; Faciliter l’information voyageurs avec un chatbot GPT ; Imaginer une interface de visualisation \u0026 de commande pour l’offre de trains de nuit au niveau européen facile à utiliser. Le challenge proposé par OSRD Le challenge proposé par OSRD visait à consolider les données ferroviaires présentes dans OpenStreetMap, une base de données ouverte \u0026 collaborative que nous utilisons comme source pour l’infrastructure ferroviaire en Europe.\nL’objectif était de développer un algorithme permettant d’identifier 5 types d’erreurs probables dans les données :\nVoies proches géographiquement mais non connectées topologiquement Aiguilles à plus de 3 branches Gares éloignées des voies Voies avec des angles trop importants Information d’écartement des voies manquante Le sujet a eu du succès et nous avons formé une équipe de 10 personnes réparties entre les quatre entreprises participantes. Après une présentation du challenge \u0026 du modèle de données d’OpenStreetMap, nous avons recherché des outils existant et avons choisi de nous appuyer sur Osmose, une application open source de détection et d’affichage d’erreurs potentielles dans OSM. Nous nous sommes ensuite réparti·es sur les 5 types d’erreurs.\nDe gauche à droite : Christoph (DB), Klara (ÖBB), Frederik (SBB), Carl (SBB), Julius (DB), Jennifer (DB), Daniel (ÖBB), Céline (SNCF), Max (DB), Tristram (SNCF).\nLes résultats Après 24h de travail le résultat est une carte interactive permettant d’afficher les différentes erreurs (cliquez sur les pictogrammes pour afficher le détail des erreurs). Vous pouvez retrouver tout le code qui a été produit sur le GitHub de l’association Open Rail.\nLe manque de temps imparti ne nous a malheureusement pas permis d’intégrer nos analyseurs dans Osmose, cependant cela reste notre priorité pour faire avancer les travaux des contributeurs et contributrices d’OpenStreetMap sur les données ferroviaires !\n","categories":"","description":"","excerpt":"Le Dreiländer hack, le rendez-vous des entreprises ferroviaires …","ref":"/fr/blog/2023/07/19/osrd-au-dreil%C3%A4nder-hack-%C3%A0-vienne/","tags":"","title":"OSRD au Dreiländer Hack à Vienne"},{"body":"Un I\u0026A prometteur Notre 5ème Inspect \u0026 Adapt a commencé avec la présentation de notre PI System demo de l’application OSRD, démontrant l’ensemble des travaux réalisés au cours de ce PI5 par nos équipes. À la suite de cette demo, l’atteinte de nos objectifs (engagés et non engagés) a été évaluée par nos partie-prenantes. Verdict : 113 % de réussite… Si, si, c’est possible 😉 !\nPlanification de notre 6ème Product Increment (PIP6) ! Après les traditionnelles séquences portant sur l’évolution de notre contexte de métier et technique, nous avons assisté à l’intervention de François Marchal, Responsable domaine numérique exploitation à la Digit, portant sur les enjeux du numérique au sein de SNCF Réseau et le rôle d’OSRD au sein de l’organisation.\nLe lendemain, Nathanaël Dias, Chargé d’étude exploitation ferroviaire, nous a présenté son métier, et le processus d’élaboration d’une étude exploitation. Il a insisté sur l’importance de partager les résultats et les travaux.\nAu cours du PIP, de nouvelles fonctionnalités ont été embarquées par les équipes, et transformées en objectifs à atteindre. Le travail a été planifié pour les 11 semaines à venir et les risques ont été évalués pour être minimisés.\nRendez-vous mi-juillet pour le 7ème PIP !\n","categories":"","description":"","excerpt":"Un I\u0026A prometteur Notre 5ème Inspect \u0026 Adapt a commencé avec la …","ref":"/fr/blog/2023/04/24/ia5-et-pip6-avril-2023/","tags":"","title":"I\u0026A5 et PIP6 - avril 2023 "},{"body":"DGEX Solutions Forum Here’s an extract from Loïc Hamelin’s talk at the DGEX Solutions forum, on the subject of search for last-minute train slots (STDCM).\nFirst of all, what is a train path? It’s the reservation of space/time on the network, by railway undertakings (RU) such as SNCF Voyageurs. These reservations are generally made years in advance (A-3). RUs can also make emergency requests for train paths (called last-minute paths), from A-1 to D-day. These requests are currently managed by ticket offices, and the paths are traced by hand. There is therefore a risk of human error, and requests are sometimes processed over several days.\nWhat do we offer? The OSRD software, in addition to featuring a rail simulator for timetable planning, will also enable last-minute path requests to be processed automatically! With just a few clicks, you’ll be able to submit a last-minute path request and get a response in a matter of seconds (3 minutes at most)!\nIf you’re interested in the #osrd project, please visit the osrd website and the GitHub repo, and the project is #opensource.\nMorgane Senejko’s LinkedIn post\n","categories":"","description":"","excerpt":"DGEX Solutions Forum Here’s an extract from Loïc Hamelin’s talk at the …","ref":"/en/blog/2023/04/12/dgex-solutions-forum/","tags":"","title":"DGEX Solutions Forum"},{"body":"Forum DGEX Solutions Voici un extrait de la conférence de Loïc Hamelin au forum DGEX Solutions , au sujet du calcul automatique de sillon de dernière minute.\nMais tout d’abord qu’est ce qu’un sillon ? Il s’agit de la réservation d’espace/temps sur le réseau, par les entreprises ferroviaires (EF), comme SNCF Voyageurs. Ces réservations se font généralement des années en amont (A-3). Les EF peuvent également faire des demandes de sillons en urgence (appelés sillons de dernière minute), de A-1 jusqu’au jour J. Ces demandes sont actuellement gérées par des guichets, et les sillons sont tracés à la main. Il y a donc un risque d’erreur humaine, et les demandes sont parfois traitées en plusieurs jours.\nQu’est ce que nous proposons ? Le logiciel OSRD, en plus de disposer d’un simulateur ferroviaire pour la planification des horaires, va également permettre de traiter les demandes de sillon de dernière minute de façon automatisée ! Il sera possible en seulement quelques clics d’exprimer une demande de sillon de dernière minute et obtenir une réponse en quelques secondes (tout au plus 3min) !\nSi le projet #osrd vous intéresse, n’hésitez pas à consulter le site web osrd et le repo GitHub, et le projet est #opensource.\nPost LinkedIn de Morgane Senejko\n","categories":"","description":"","excerpt":"Forum DGEX Solutions Voici un extrait de la conférence de Loïc Hamelin …","ref":"/fr/blog/2023/04/12/forum-dgex-solutions/","tags":"","title":"Forum DGEX Solutions"},{"body":"Forum DGEX Solutions Voici un extrait de la conférence de Loïc Hamelin au forum DGEX Solutions , au sujet du calcul automatique de sillon de dernière minute.\nMais tout d’abord qu’est ce qu’un sillon ? Il s’agit de la réservation d’espace/temps sur le réseau, par les entreprises ferroviaires (EF), comme SNCF Voyageurs. Ces réservations se font généralement des années en amont (A-3). Les EF peuvent également faire des demandes de sillons en urgence (appelés sillons de dernière minute), de A-1 jusqu’au jour J. Ces demandes sont actuellement gérées par des guichets, et les sillons sont tracés à la main. Il y a donc un risque d’erreur humaine, et les demandes sont parfois traitées en plusieurs jours.\nQu’est ce que nous proposons ? Le logiciel OSRD, en plus de disposer d’un simulateur ferroviaire pour la planification des horaires, va également permettre de traiter les demandes de sillon de dernière minute de façon automatisée ! Il sera possible en seulement quelques clics d’exprimer une demande de sillon de dernière minute et obtenir une réponse en quelques secondes (tout au plus 3min) !\nSi le projet #osrd vous intéresse, n’hésitez pas à consulter le site web osrd et le repo GitHub, et le projet est #opensource.\nPost LinkedIn de Morgane Senejko\n","categories":"","description":"","excerpt":"Forum DGEX Solutions Voici un extrait de la conférence de Loïc Hamelin …","ref":"/fr/blog/2023/04/12/forum-dgex-solutions/","tags":"","title":"Forum DGEX Solutions"},{"body":"I\u0026A février 2023 : ce qu’on retiendra ! L‘Inspect \u0026 Adapt est une cérémonie issue du framework d’agilité à l’échelle SAFe (Scaled Agile Framework), au cours de laquelle nous inspectons notre travail réalisé sur les 11 dernières semaines pour nous adapter en conséquence. Nous nous sommes donc réunis ce lundi 13 février pour clore le 4ème Increment de notre programme (PI 4).\nAprès avoir assisté à la demo de toutes les fonctionnalités développées par nos 3 équipes (PI system demo), nos parties prenantes ont pu évaluer l’atteinte de nos objectifs. Résultat : environ 80% de réussite.\nLancement de notre 5ème PIP ! Le Product Increment Planning (PIP) est une cérémonie au cours de laquelle les équipes se répartissent le backlog des nouvelles fonctionnalités et planifient leur travail sur les 11 prochaines semaines. Avant d’entamer le travail de planification en sous-groupe, Loïc Hamelin nous a présenté les évolutions du contexte business d’OSRD, retraçant les attentes de nos clients.\nDans la matinée du 15 février, Caroline Johnson, Directrice Solutions Numériques Exploitation chez SNCF Réseau, nous a présenté l’offre de service sur la DG-Num et a répondu à nos questions sur l’intégration prochaine de notre application dans le SI interne.\nA l’issue du PIP, nos business owners ont attribué une valeur, entre 1 et 10, à nos nouveaux objectifs de PI et les risques de programme ont été évalués.\n","categories":"","description":"","excerpt":"I\u0026A février 2023 : ce qu’on retiendra ! L‘Inspect \u0026 Adapt est une …","ref":"/fr/blog/2023/02/13/ia-et-pip-4-f%C3%A9vrier-2023/","tags":"","title":"I\u0026A et PIP 4 - février 2023"},{"body":"\nUne Devroom pour l’association Openrail Les 4 et 5 février se tenait le FOSDEM, l’évènement européen annuel incontournable pour la communauté open source. Tout au long de ces 2 jours à Bruxelles, les participants ont pu assister à une variété de conférences et ateliers portant sur les dernières tendances du logiciel libre et de l’open source. L’un des moments forts de l’événement était le lancement de la Devroom « Opening railways and open transport », portée par la toute nouvelle OpenRail association. Le programme OSRD a eu la chance d’ouvrir cette nouvelle room avec ST DCM.\n« Short-term digital capacity management » ou le challenge des sillons de dernière minute La conférence d’Eloi Charpentier, intitulée « automated short-term train planning in OSRD » présentait les réflexions issues de nos travaux sur la simulation de sillons de dernière minute. Ou comment permettre aux entreprises de fret ferroviaire d’obtenir des autorisations de circulation de dernière minute évitant les embouteillages sur le réseau, et d’avoir ainsi l’agilité indispensable pour concurrencer le transport routier ?\nSlides Vidéo Opendata et cartographie du réseau ferroviaire La présentation de Céline Durupt, “OpenStreetMap, one geographic database to rule them all?” abordait le sujet de l’opendata en matière de réseau ferroviaire. Sur la base d’une analyse européenne, Céline a présenté un plan d’actions pour partager la donnée ferroviaire via OSM et la rendre utilisable par OSRD.\nSlides Vidéo Rendez-vous l’année prochaine au FOSDEM 2024 avec des exemples concrets de collaboration et de nouveaux développements d’open source ferroviaire.\n","categories":"","description":"","excerpt":"\nUne Devroom pour l’association Openrail Les 4 et 5 février se tenait …","ref":"/fr/blog/2023/02/06/fosdem-2023-osrd-%C3%A9tait-pr%C3%A9sent/","tags":"","title":"Fosdem 2023 : OSRD était présent !"},{"body":"Hi ! My name is Céline, and I am on a mission to bring more open data into OSRD. To do so, I searched open data that can fit OSRD’s needs in every country of the European Union (+ Norway, United Kingdom and Switzerland).\nI have presented the main results of this study during a talk at the FOSDEM 2023 meeting, and you can see the replay on their website.\nIn this post I will go into details of the methodology I followed, feel free to contact me if you have any remarks or question :-)\nData download You can download the detailed data I created here. Update 11/03/23 : get the updated file here.\nAdded open data sources links for : Estonia, Czechia, Poland, Slovakia Added license detail pour : Sweden Added information on real-time position of trains for : Finland Special thanks to Christoph Breit \u0026 everyone that contributed by sending me links \u0026 info The file is composed of three tabs:\nEU-sources: links to download each country’s open data \u0026 info on license compatibility EU-data: data used to compare total track length between countries and source and to compute the “usability indicator” EU-epsg: EPSG code used for reprojecting geographical data for each country Compare total track length Calculate track length from open data Look for open data sources\nIf a source is found, look for data license\nCheck license compatibility with OpenStreetMap using OSM wiki and this blog post\nDownload open data\nLoad data into QGIS and reproject it based on the EU-epsg tab\nCalculate a new field using the following formula to get the length of each track in kilometers:\n\"length\" = $length / 1000 Report total length using the “Basic Statistics for Fields” tool\nLearn more about Inspire data model\nCalculate track length for OpenStreetMap data Download last OSM export from https://download.geofabrik.de/europe.html\nLoad lines data into QGIS\nSelect data using the “other_tags” field to select railway network:\n\"other_tags\" like '%\"railway\"=\u003e\"rail\"%' or \"other_tags\" like '%\"railway\"=\u003e\"narrow_gauge\"%' or \"other_tags\" like '%\"railway\"=\u003e\"light_rail\"%' Export selected objects and reproject the layer based on the EU-epsg tab\nCalculate a new field using the following formula to get the length of each track in kilometers:\n\"length\" = $length / 1000 Select electrified parts of the network using the “other_tages” field:\n\"other_tags\" like '%\"electrified\"=\u003e\"yes\"%' or \"other_tags\" like '%\"electrified\"=\u003e\"contact_line\"%' or \"other_tags\" like '%\"electrified\"=\u003e\"rail\"%' Report total length using the Basic Statistics for Fields tool\nLearn more about OpenStreetMap data model\nCalculate usability indicator List required and optional data For each data, indicate its availability using QGIS (Overpass Turbo can also be helpful to check OSM data) and the following scale : “Yes”: fully available “Partial”: not available everywhere on the country, or missing parts of the data “No”: not available Sum total required and optional data with Yes = 1; Partial = 0.5; No = 0 Generate indicator: “Good” if required=2 and optional\u003e2 “Okay” if required \u003e1 and optional \u003e=0 “Poor” if required=1 and optional \u003e2 “Not usable” else Map the result To show the indicator and license compatibility on a map, use the Eurostat borders datasets (for my presentation, I have used the 1:20 million scale and EPSG:3035) and join the table using countries names.\n","categories":"","description":"","excerpt":"Hi ! My name is Céline, and I am on a mission to bring more open data …","ref":"/en/blog/2023/02/03/openstreetmap-and-open-data-talk-at-fosdem-2023/","tags":"","title":"OpenStreetMap and open data talk at Fosdem 2023"},{"body":"Review cycle A code review is an iterative process. For a smooth review, it is imperative to correctly configure your github notifications.\nIt is advisable to configure OSRD repositories as “Participating and @mentions”. This allows you to be notified of activities only on issues and PRs in which you participate.\nMaintainers are automatically notified by the CODEOWNERS system. The author of a PR is responsible for advancing their PR through the review process and manually requesting maintainer feedback if necessary.\nsequenceDiagram actor A as PR author actor R as Reviewer/Maintainer A-\u003e\u003eR: Asks for a review, notifying some people R-\u003e\u003eA: Answers yes or no loop Loop between author and reviewer R--\u003e\u003eA: Comments, asks for changes A--\u003e\u003eR: Answers to comments or requested changes A--\u003e\u003eR: Makes necessary changes in dedicated \"fixups\" R--\u003e\u003eA: Reviews, tests changes, and comments again R--\u003e\u003eA: Resolves requested changes/conversations if ok end A-\u003e\u003eR: Rebase and apply fixups R-\u003e\u003eA: Checks commits history R-\u003e\u003eA: Approves or closes the PR Note left of R: \u0026 Merges if maintainer ","categories":"","description":"","excerpt":"Review cycle A code review is an iterative process. For a smooth …","ref":"/en/docs/guides/contribute/review-process/","tags":"","title":""},{"body":"Cycle de review Une revue de code est un processus itératif. Pour la fluidité d’une review, il est impératif de configurer correctement ses notifications github.\nIl est conseillé de configurer les dépôts OSRD en “Participating and @mentions”. Cela permet d’être notifié d’activités uniquement sur les issues et PR auxquelles vous participez.\nsequenceDiagram actor A as Auteur PR actor R as Reviewer/mainteneur A-\u003e\u003eR: Demande une review en notifiant spéciquement quelques personnes R-\u003e\u003eA: Répond à la demande par oui ou non loop Boucle entre auteur et reviewer R--\u003e\u003eA: Commente, demande des changements A--\u003e\u003eR: Répond à chaque commentaire/demande de changement A--\u003e\u003eR: Corrige le code si nécessaire dans des « fixups » dédiés R--\u003e\u003eA: Vérifie, teste, et commente à nouveau le code R--\u003e\u003eA: Résout les conversations/demandes de changement le cas échéant end A-\u003e\u003eR: Rebase si nécessaire R-\u003e\u003eA: Vérifie l'historique des commits R-\u003e\u003eA: Approuve ou ferme la PR Note left of R: Et fusionne si mainteneur Les mainteneurs sont automatiquement notifiés par le système de CODEOWNERS. L’auteur d’une PR est responsable de faire avancer sa PR dans le processus de review (quitte à notifier manuellement un mainteneur).\n","categories":"","description":"","excerpt":"Cycle de review Une revue de code est un processus itératif. Pour la …","ref":"/fr/docs/guides/contribute/review-process/","tags":"","title":""},{"body":"OSRD est une suite d’outils ferroviaires pour différents cas d’utilisation. Ces outils sont basés sur la simulation de l’infrastructure ferroviaire ainsi que son analyse.\n","categories":"","description":"","excerpt":"OSRD est une suite d’outils ferroviaires pour différents cas …","ref":"/fr/about/","tags":"","title":"À propos"},{"body":"OSRD is a railway toolbox designed for multiple use cases. These tools have in common a reliance on railway infrastructure simulation and results analysis.\n","categories":"","description":"","excerpt":"OSRD is a railway toolbox designed for multiple use cases. These tools …","ref":"/en/about/","tags":"","title":"About"},{"body":"Principe Le block automatique se caractérise en block automatique lumineux (BAL) et en block automatique à permissivité restreinte (BAPR) par :\nle fonctionnement entièrement automatique des signaux de cantonnement dont le changement d’état (fermeture ou ouverture) est provoqué par le passage des circulations sans aucune intervention humaine ; l’état d’occupation de chaque canton, agissant directement sur le signal d’entrée correspondant est obtenu par le circuit de voie en BAL, généralement par un comptage d’essieu en BAPR. Le BAL permet un débit élevé des circulations sur la ligne. Fonctionnement d’un circuit de voie Un circuit de voie est principalement constitué de trois éléments :\nun émetteur, branché à l’une des extrémités de la zone. Il délivre un courant qui peut être de différente nature selon les types de circuit de voie (continu, impulsionnel, alternatif, etc.) ; une ligne de transmission, constituée par les deux files de rails ; un récepteur, branché à l’autre extrémité de la zone. Il assure le filtrage, l’amplification et la transformation du signal reçu via les rails, ce qui agit sur un relais appelé relais de voie. Les contacts de ce relais sont utilisés pour établir ou couper le circuit électrique du signal d’entrée du canton. Lorsqu’aucun véhicule n’est présent sur la zone délimitant le circuit de voie (voie libre), le signal délivré par l’émetteur parvient au récepteur à travers la ligne de transmission, et le relais de voie est excité. Le feu d’entrée du canton est à voie libre (cas 1 ci-dessous).\nLorsqu’un véhicule est présent, son premier essieu agit comme une faible résistance, appelée shunt, qui court-circuite la transmission. Dans ce cas, le niveau du signal parvenant au récepteur n’est plus suffisant et le relais de voie se désexcite, ce qui entraine la fermeture du signal d’entrée du canton (cas 2 ci-dessous).\nFonctionnement des compteurs d’essieux Un compteur d’essieux est un dispositif technique servant à détecter la présence d’une circulation sur une section, par comptage des essieux qui franchissent les détecteurs encadrant cette section.\nUn point de détection est installé à chaque extrémité de la section, et chaque fois qu’un essieu passe sur ce point au début de la section, un compteur s’incrémente. Quand le train passe sur le point de détection en fin de la section, le compteur décrémente. Si le nombre final est zéro, la section est présumée libre pour un deuxième train et le signal d’entrée du canton présentera l’indication « voie libre ».\n","categories":"","description":"Block Automatique","excerpt":"Block Automatique","ref":"/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/","tags":"","title":"BA"},{"body":"Le signal d’entrée du canton présente une indication liée à l’état d’occupation du ou des cantons suivants, selon les règles suivantes :\nindication d’arrêt lorsque le canton est occupé par au moins une portion du train annonce lorsque le canton suivant est occupé voie libre par défaut (sauf signaux Nf) La longueur maximale d’un canton est en principe de 2800 m. Elle est généralement de 1500 m sur les lignes parcourues à la vitesse maximale de 160 km/h.\nAvantages du BAL Le BAL offre un niveau élevé de sécurité et permet un débit important.\nLimites L’installation du BAL est très coûteuse, et son fonctionnement nécessite une garantie de contact électrique entre la roue et le rail.\nImplémentation Simuler correctement le système BAL nécessite de respecter les critères suivants :\nlorsque la tête du train pénètre dans un canton, le signal d’entrée de celui-ci passe en indication d’arrêt lorsque la queue du train libère un canton, son signal d’entrée passe en annonce lorsque la queue du train libère un canton, le signal d’entrée du canton précédent passe en voie libre les signaux présentent une voie libre par défaut, sauf les signaux Nf qui sont par défaut en indication d’arrêt ","categories":"","description":"Block Automatique Lumineux","excerpt":"Block Automatique Lumineux","ref":"/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bal/","tags":"","title":"BAL"},{"body":"Le signal d’entrée du canton est un signal qui présente une indication liée à l’état d’occupation du canton suivant (indication d’arrêt ou de voie libre). Sur certaines lignes l’occupation du canton n’est pas obtenue par le circuit de voie mais par un système de comptage d’essieux entrants et sortants.\nLes cantons sont beaucoup plus longs que le BAL (jusqu’à 15 km et plus) et par conséquent le débit est moins important.\nAvantages du BAPR Le BAPR offre un bon niveau de sécurité et il est moins coûteux que le BAL.\nLimites Ce type de block n’est adapté qu’aux lignes conventionnelles à trafic moyen compte tenu de l’espacement imposé entre 2 trains successifs.\n","categories":"","description":"Block Automatique à Permitivité Restreinte","excerpt":"Block Automatique à Permitivité Restreinte","ref":"/fr/docs/railway-wiki/signalling/spacing/automatic_block_systems/bapr/","tags":"","title":"BAPR"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/categories/","tags":"","title":"Categories"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/categories/","tags":"","title":"Categories"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/docs/reference/apis/editoast/","tags":"","title":"Editoast"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/docs/reference/apis/editoast/","tags":"","title":"Editoast"},{"body":"Introduction L’ERTMS, pour European Rail Traffic Management System, est un système qui vise à harmoniser la signalisation ferroviaire en Europe.\nIl est composé de trois sous-systèmes :\nun système de signalisation : l’ETCS un système de communication : GSM-R / GPRS / FRMCS un système de gestion du traffic : l’ETML ","categories":"","description":"European Rail Traffic Management System","excerpt":"European Rail Traffic Management System","ref":"/fr/docs/railway-wiki/signalling/spacing/ertms/","tags":"","title":"ERTMS"},{"body":"","categories":"","description":"The European Train Control System, part of ERTMS","excerpt":"The European Train Control System, part of ERTMS","ref":"/en/docs/railway-wiki/signalling/spacing/ertms/","tags":"","title":"ETCS (ERTMS)"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/docs/reference/apis/gateway/","tags":"","title":"Gateway"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/docs/reference/apis/gateway/","tags":"","title":"Gateway"},{"body":"The team dedicated to OSRD within SNCF Réseau is always keen to hear from new profiles: if working on the project motivates you, send us a message on contact@osrd.fr!\n","categories":"","description":"","excerpt":"The team dedicated to OSRD within SNCF Réseau is always keen to hear …","ref":"/en/join-us/","tags":"","title":"Join us"},{"body":"L’équipe dédiée à OSRD au sein de SNCF Réseau est toujours intéressée par de nouveaux profils : si travailler sur le projet vous motive, envoyez-nous un message sur contact@osrd.fr !\n","categories":"","description":"","excerpt":"L’équipe dédiée à OSRD au sein de SNCF Réseau est toujours intéressée …","ref":"/fr/join-us/","tags":"","title":"Rejoignez-nous"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/search/","tags":"","title":"Search Results"},{"body":"","categories":"","description":"","excerpt":"","ref":"/en/tags/","tags":"","title":"Tags"},{"body":"","categories":"","description":"","excerpt":"","ref":"/fr/tags/","tags":"","title":"Tags"}] \ No newline at end of file