On-board FRMCS, TOBA and application integration

The same operational task has two ends

In the vehicle, Lea uses her voice application. In the control centre, Niko uses a workstation for operational conversations. Both applications need communication services; their user interfaces and operational responsibilities nevertheless remain different.

The Telecom On-Board Architecture (TOBA) describes the communication architecture on the vehicle. It organises components and connections so applications can use communication capabilities. TOBA means neither the complete control centre nor one particular box.

OBAPP is the interface between an on-board application and the On-Board FRMCS System. It connects the intended communication functions. TSAPP is the corresponding application interface on the trackside. For example, it concerns connecting a control-centre application to the Trackside FRMCS System; it is not a second on-board connection. [S10, S31]

UIC TOBA-7510, the TOBA FRS, describes on-board functional requirements. It specifies capabilities the On-Board FRMCS System is intended to provide. This course uses version 2.1.0 of 25 April 2025. The ERA list for FRMCS B0 instead references version 1.0.0 under index 099; teaching source and TSI reference baseline must be distinguished. The FFFIS additionally contains interface details for OBAPP and TSAPP. [S39, S16, S10]

Where is the MCX client?

From 2.4 you know the MCX client as the service participant on the user side. The Form Fit Functional Interface Specification (FFFIS) describes the intended application interfaces. Among other things, it specifies how applications connect and use communication functions. This includes different ways of integrating the MCX client.

With Tight Coupling, the MCX client is integrated into the application. Following local binding, it uses the intended communication facilities through OBAPP or TSAPP. The application thus takes on more service-related tasks.

With Loose Coupling, the application uses an offered programming interface while the FRMCS system provides the associated MCX client functions. An API is a defined interface through which software invokes functions of other software. The application can, for example, request a communication session without implementing every MCX procedure itself. [S10, sections 5.6–5.7]

This distinction does not mean Tight is always faster or Loose always interchangeable. Interchangeability depends on the specific supported functions, versions, failure responses and security requirements.

Which connection applies to our voice example?

The Voice Application Subsystem (VAS) groups the functions of the operational voice application. It connects user operation with the required voice services. For the driver VAS, SRS 2.1.0 used here requires Tight Coupling over OBAPP. The generally explained Loose Coupling variant is therefore not a freely selectable alternative for this voice profile. [S06, section 24.2.3.3]

For the controller VAS, the path depends on TSAPP support: if it supports TSAPP, it uses TSAPP with Tight Coupling. Otherwise it connects through TSCTRL. This separate reference point connects the controller VAS to FRMCS communication services. A controller VAS does not use TSAPP and TSCTRL simultaneously. [S06, sections 6.4.1.3 and 24.3.3.2–24.3.3.4]

In the Talbahn example, we choose the TSAPP variant for Niko. Lea uses OBAPP and Niko TSAPP, both with Tight Coupling. The following diagram shows this selected voice variant and logical boundaries. A manufacturer may place several functions on shared hardware; interfaces and responsibilities must still be established.

Open diagram at full size (SVG, new tab) G06

An interface needs defined behaviour

Niko's application requests a connection to the role “Driver of train 1234”. In this test case, Lea holds that role. For the application's connection, Talbahn must at least know:

• which identity and permissions the application uses;
• how it recognises success, rejection and connection loss;
• which states are restored after restart or interruption;
• who owns interface changes and faults on each side.

A successfully submitted request does not mean Lea hears speech. The service and transport components from 2.8 lie between the request and the audible result.

The on-board specification is an appropriate source for vehicle architecture. It does not replace a general operational specification for the control centre. The case file therefore keeps interface description, operational control-centre requirement and evidence separate.

Check your understanding

An offer mentions “TOBA with OBAPP and TSAPP on the vehicle” and claims Loose Coupling guarantees replacement of the control-centre application without retesting. Correct both claims. Which connection does the driver VAS considered here use?

Model answer

OBAPP belongs to the on-board application connection and TSAPP to the trackside connection. They are not two connections in the same vehicle architecture. Loose Coupling describes connection through an API and the location of MCX client functions. Replacing an application still requires checking interface scope, versions, permissions and failure behaviour in the actual combination. Under the SRS 2.1.0 considered here, the driver VAS uses OBAPP with Tight Coupling.

What to remember

A clearly named interface separates responsibilities; it does not replace functional evidence.

Your Talbahn case file

Place OBAPP and TSAPP on the correct sides of your system map. For the vehicle application, record where the MCX client resides and who owns the interface. Mark the voice variant with Tight Coupling on both sides and the selection of TSAPP for Niko.