How do we classify the safety requirements in a rail system?


When we specify the safety requirements of a railway system, component or procedure, we can always classify it as belonging to one of the following groups:

In this article we are going to explore each one of these 3 types of security requirements, understanding their differences and RAMS Engineering strategies associated with each of them. In all cases, it is important to understand that these security requirements are the output ( product output) or result of a risk assessment process and that we will typically find them in a particular specification of security requirements or, labeled as "security requirement" in the specification of general system requirements, where in a consolidated way, ALL the requirements of a system are integrated (forgive the redundancy).

It is also important to classify them by type (not just identify them as security requirements), since it will allow us to take a step forward in diligence and criteria in the management and treatment of security requirements, without a doubt, the sub-group of most important requirements that our system will have.

In a non-exhaustive way, but very often, we will find that the functional security requirements come from the effects of random and systematic failures. On the other hand, both technical security and contextual security requirements, in most cases, tend to come from systematic failures.

Primary influencers of a security requirement
Primary influencers of a security requirement

One of the points that we want to reinforce more in this article from Leedeo Engineering is that, regardless of their type (functional, technical security or contextual security), it is key within a project that the security requirements are agreed upon and approved by all project stakeholders. This point will make it possible to ensure a correct foundation of the bases for a good resolution of the security functions by all the stakeholders of a project.

Functional Safety Requirements

The primary and secondary requirements for fulfilling the functions that are fundamental to the system and the main reason for its creation are the functional requirements. That is, the functional requirements express the behavior of the system. Let's take an example: the train doors can only be opened if the train is completely stopped.

On the other hand, we can define functional safety, in a very simplified way, as a portion of the total safety of a system that depends on the functional and physical units correctly performing the functions for which it has been designed and manufactured, in response to system excitation inputs.

The functional security requirements are directly related to the fulfillment of a function for which the system is used and this must cover security needs.

The functional safety requirements must always be accompanied by two important characteristics: their expected functional behavior in ordinary or habitual mode and the expected functional behavior against the appearance of failures. Regarding the latter, the concepts of:

  • Security integrity, defined as the level of capability of a system to perform the required security functions under all declared conditions, within an operating environment and for a given duration. Higher security integrity implies a lower probability of NOT performing the required security functions. Safety Integrity has its highest representation and recognition in the railway sector as the SIL-X level (SIL-3 for example).
  • Possible alternative behaviors to the ordinary or usual functions but that maintain the security of the system (for example: a degraded mode) in case of failures that do not lead to a risk situation.

Technical Security Requirements

The technical requirements are associated with the technical implementation of the system which, for said implementation, are required at the level of necessary additional requirements. The technical requirements, therefore, do not characterize the functionality of the system but they do have an impact on its structure.

Let's take an example: the system must not have sharp or sharp edges. Obviously, a given railway system is not created to puncture or cut through its edges, but its mechanical system that works as an envelope or main body designed and manufactured, may contain sharp or cutting edges if the correct finish is not applied in its welders, its cuts or demolding of mechanical parts. Therefore, the technique used to implement the equipment forces us to consider security requirements that ensure a product or system "free of security problems". Let's take a few more examples:

  • A high-power electrical equipment, the use of a correct electrical grounding architecture, to ensure that there is no possibility of electric shock when handling the equipment.
  • A safety relay cannot be energized for more than 10,000 hours since its contacts can remain stuck (better said, welded) permanently.
  • Presence of flammable combustible material in a locomotive.
  • An electromagnetic interference causes to turn on a permissive aspect of a railway signal.

The technical requirements of each product are primarily derived from the potential threats created by the technology and regardless of its intended function. It is a good "trick" to use international regulations and standards to ensure that the technical solution adopted does not generate failures against security. In most cases, we will see that we correctly define a requirement of this type if it represents a limitation or obligation for the design, installation or use.

Contextual Security Requirements

The contextual requirements can be considered as a further classification of requirements of the relationship between the system and its environment (beyond the system itself) through contextual requirements. The contextual requirements would therefore address issues such as modes of operation and maintenance; operational restrictions related to safety, the training received by the personnel responsible for the operation and maintenance of the system, the profile of the specific mission, the particular logistics of the project, the particular characteristics, for example, of a given railway line, etc. Let's take some example:

  • In a certain line the maximum speed of the train must be limited due to the physical characteristics of the railway section.
  • The training of the personnel that operates with the system must be of certain characteristics to ensure the correct use of the system.

In Leedeo Engineering , we are specialists in the development of RAMS projects, providing support at any level required for RAM and Safety tasks, and both at the level of infrastructure, signaling, electrification or on-board equipment.

Are you interested in our articles about RAMS engineering and Technology?

Sign up for our newsletter and we will keep you informed of the publication of new articles.