Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

Method for definition of functions

Content

1.1. 2.1. Basic principles

A general definition for a function was previously described in Technical note on definition of functions. Taking the previous definition into account, this section will further detail how a function can be defined for a railway system of interest.

1.1.1. 2.1.1. Railway system of interest is a control system

Hypothesis 1: Railway system of interest is a time-varying, physically distributed, large-scale interconnected multi-input multi-output control system. That is, its overall function can be described as controlling the positions of trains and people on the network in accordance with multiple types of constraint and a complex reference signal (the timetable), using a huge number of diverse sensors and actuators, some of which are inside and some are outside the system border. 

Definition: The "plant" is the system being controlled - in the case of railway system of interest, this is the collection of infrastructure moveable assets, trains, people, and everything else that is controlled by railway system of interest. 

Note: the hypothesis is not that the whole railway system can be reduced to one item of "plant" - the overall system contains a large number of control loops interacting with each other, where each loop controls an associated (internal) plant. Meaning that there is no single plant, but the entire system consists of multiple (literally a large number of) plants.

Hypothesis 2: Most core railway system of interest functions can be assigned to one of the four categories "control", "actuate", "sense" or "observe". 

Exception 1: Functions associated with non-operational states of railway system of interest, such as data updates or switching between operating and maintenance states, might not fit these categories because they are not part of the chain of functions directly controlling the railway state.

Exception 2: Where a human actor is in a control loop, an additional category of function "indicate" is allowed so that information from observed or other controlled states can be used by the human actor to make their control decisions. This is an addition to the original pattern; originally, the "actuate" archetype was used for displaying things, but since observed states cannot be actuated, this caused a problem where we want to display an observed state to a human actor; it seemed simpler to allow a new type of function. It is not shown in the sketch below but it is shown in the class diagram for the actual pattern further down this page.

Hypothesis 3: The core functions of the railway system of interest can be modelled as a combination of many of these control loops, which are interconnected and nested inside each other. A railway system contains a collection of several "plant behaviours" that are to be controlled with

several control loops. Actor functions belonging to the "Plant behaviour" category represent the physical behaviour of the entity they belong to.

The main functions of a control system are illustrated in colour below.

Function categories in railway system of interest

1.2. 2.2. Controllable and observable

Theorem: We can only control what we can observe (this is not up for debate, see any good control systems textbook e.g. "Control Systems Engineering" by Norman S. Nise)

Corollary: This is not the same as saying we can only control what we can sense. We can use sensed data to observe a state that we want to control, but cannot directly sense.

We can sense only the outputs of the plant, but we want to control the internal states of the plant.

Example: the speed of a train is an internal state; we can infer it by sensing certain specific quantities like the Doppler shift of passing objects (Doppler speed sensors), the rotational speed of individual axles on the train (pulse tachometers or tachogenerators), or the change in relative position to a constellation of satellites (GNSS speed sensor); from one or more of these sensed quantities we can infer the internal state that is the speed of the train (observation).

1.2.1. 2.2.1. The control system needs configuration data

Hypothesis 1: In railway-related control loops, most of the Control, Observe and Indicate functions include information about the system configuration into their consideration. The system configuration is another control loop on its own and it is mostly out of sync with the loops of the system itself as the system operations need to be (at least partially) halted in order to apply changes to the configuration.

Definition: Configuration data describe the basic layout of the system and / or its environment. They can be consumed by control, observe and indicate functions and are also supplied by the configuration data supply process.

Hypothesis 2: The creation of the configuration data and their activation as the valid configuration of the system are not synchronised. The planned future configuration is already validated to planning processes of a railway system, while other use cases require data about the valid (i.e. actual) system configuration.

1.2.2. 2.2.2. The control system needs calibration data

Hypothesis 1: In railway-related control loops many Actuate and Sense functions work according to a certain calibration. This calibration might not be static. E.g. for a wheel speed sensor, the diameter of the wheel decreases over time due to wear of the metal surface. Thus, the wheelspeed sensor calibration needs to be changed periodically.

Definition: Calibration data describe the benchmark values for actuators and sensors. They are supplied by the calibration data supply process.

1.3. 2.3. Pattern for railway operation control loop functions

Control: The purpose of a control function is to transform information about a needed change of the plant's state into instructions or commands for the state of the actuators. Control functions are where all the decisions are made.

Actuate: The purpose of an actuate function is to transform instructions or commands into a physical state that has some effect on the plant's internal state.

Sense: The purpose of a sense function is to transform a physical external state of the plant into information about the plant's external state.

Observe: The purpose of an observe function is to transform information about the plant's external state into an observation about the plant's internal state. Observe functions are where inferences and/or estimations are made about the state of the plant given incoming data. 

Indicate: Converts information from an estimated state or a required state into a human-perceptible form (audible, visual or haptic). At system level, each information type may only be indicated by one function. At physical level, this will be decomposed if necessary (for example, because two users need the information presented in two different locations or in two different formats).

Plant: See above

1.3.1. 2.3.1. Taxonomy

We will define rules that allow only a limited number of possible verbs for each category of function, in order to improve consistency.

Plant placeholders do not need to be forced to be consistent.

Taxonomy for control system principle

Each core function should be named and described in such a way that it conforms to one of the categories of control function. A "core" function is a function that is active when the system is in the OPERATIONAL state (or equivalent).

All functions are members of one of the following categories:

  • Control
  • Actuate
  • Indicate
  • Sense
  • Observe



The main five ontology elements (control, actuate, indicate, sense and observe), or their specialisations are to be used for naming functions.
If neither the main functions nor their specialisations fit the function being created, it is possible to use verbs not defined in the above-depicted ontology.
In such a case, the usage of a previously undefined verb must be justified and coordinated with the parties responsible for the modelling rules.

1.3.2. 2.3.2. Ontology

Note:

  • This ontology allows estimated states to be exchanged between observation functions so that observations can be made at different levels of abstraction; in other words, an observer does not always have to transform a sensed external state directly into a fully abstract estimated state;
  • Similarly, this ontology allows control functions to produce a required state that is not the required state of an actuator, but rather the required state of some other abstract concept, that feeds to a further control function; in other words, a control function does not always have to transform a required plant internal state directly into a required actuator state, but it might generate a command reference signal for a neighbouring control loop.

1.4. 2.4. Pattern for configuration and calibration functions

Original configuration data are provided by an external actor (the owner of the data). The provision of data occurs discontinuously, whenever a required state of the system configuration is defined. The activation of the data (the transition from a planned state to the valid actual state) is controlled by an external actor who got the necessary confirmation that the real configuration of the system fits the to-be-activated data in the "Maintain configuration data" function.

1.4.1. 2.4.1. Taxonomy

Not yet defined

1.4.2. 2.4.2. Ontology

Configuration data


Relation to control loop functions

(0..*) configuration data can be used by (1..*) control, observe or indicate functions. Configuration data are continuously delivered by the function "Maintain configuration data", one for each item of configuration data.


Calibration Data

Calibration data are provided directly to the actuation and sensing functions.