Harmonised and non-harmonised applications

Shared communication access, different application scopes

Alongside operational voice, Talbahn wants its own diagnostic application, transferring vehicle conditions to maintenance staff. Both need communication, but this does not mean that their application behaviour is standardised to the same extent.

Harmonisation here means the common definition of a function or application by the responsible stakeholders. The FRS explains harmonised applications and their relationship to functions made mandatory. Non-Harmonized Applications refers, in the particular document context, to applications outside that harmonised scope. This does not establish criticality or technical usability. FRS 2.1.0 also distinguishes its own functional scope from external applications. Determine these boundaries from the actual source passage, not by guessing from an application's name. [S05, definitions and clause 5.2]

Answer four questions separately

First: is the application function harmonised under the rules being considered? Second: which communication interface and service does it use? Third: what operational significance and protection needs apply? Fourth: which transition and usage rules apply in another domain? None of these answers substitutes for the others.

For our fictional diagnostic application, we assume an operator-specific application scope. Talbahn defines its data format and maintenance analysis. Its communication integration still uses a named, tested interface. “Operator-specific” does not mean “unrestricted access to every resource”.

Do not mix classifications

For domain transitions, the SRS also classifies applications by infrastructure manager versus railway undertaking and by interoperability. This is not automatically identical to “harmonised/non-harmonised”. Infrastructure managers provide railway infrastructure; railway undertakings operate trains. A service-domain transition must be assessed against the actual application and transition rules. [S06, clause 10.1.3.3]

The diagnostic application therefore receives an integration profile: partners, data purpose, coupling type, identity, permitted networks, load behaviour and response to interruption. It also records who approves changes to data formats and communication. The application remains manageable even when its application scope is not described by the same requirements as operational voice.

Check your understanding

Someone says: “Non-harmonised means non-critical, so the application may automatically use any public access after crossing a border.” Which conclusions are unsupported?

Model answer

Harmonisation status determines neither protection needs nor access permission. Public-network use, service access and domain behaviour need their own rules. Establish application scope, communication profile and transition behaviour separately.

What to remember

Harmonisation status, interoperability category, coupling and criticality are distinct properties. Careful classification prevents incorrect architectural assumptions.

Your Talbahn case file

Create the diagnostic application's integration profile. Label its operator-specific classification as a teaching-case assumption and record the relevant source terminology alongside it.