Challenges in Digitizing Specific Application Configurations

To enjoy the full benefits of Signaling Design Automation, particular care needs to be taken regarding the Specific Application Configuration.

Characteristics of Specific Application Configuration

Specific Application Configuration (SAC) often involves large amounts of safety critical data organized in an inhomogeneous fashion. Data might be given as scheme plans, control tables, and/or in written documents, notes, etc. In some cases, the data is only communicated verbally or is even implicit as a common understanding among involved engineers.

The typical configuration process therefore tends to be error prone and time consuming. This also applies to any independent checking and verification of the final configuration. Over time, maintenance also becomes even more difficult.

Weakly and partially specified configuration data distributed over many types of sources is not an ideal way for an efficient and reliable process.

A Way Forward?

A way forward is to have a well specified set of SAC data organized in a uniform way in a “human friendly” open format. Such a format would also make it possible to use tool support for performing trusted computations on the SAC data for checking static requirements and for producing derived data.

In a generic approach this requires a Generic Application Configuration (GAC) containing the specification of the SAC data. The GAC is a natural place for specifying static checks and derived data.

Geographical data would preferably be represented in some compact easily reviewable format, and there should be support for tabular data.

The Layout Configuration Format – A Uniform Approach

The Layout Configuration Format (LCF) and its supporting tools released by Prover address these problems. It realizes a CENELEC SIL-4 compliant process that gives:

• a general and consistent way to represent all required SAC data for any given interlocking in a compact and review friendly file format
• a generic way to specify which SAC data is required and how it should be used for any given interlocking type
• an interface that is used to document how to collect and interpret the various pieces of data that make up the configuration of the specific application, in order to map it to LCF
• a method to configure algorithms to compute derived SAC data from given SAC data in a trusted way, in order to minimize the amount of data to create and review
• a highly configurable method for transforming SAC data to standardized tables and variable mappings for code generation and sign-off verification
• a format with accompanying tools that are independent of signaling principles, design tools, and interlocking platform.

Find out more about LCF here.