Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
Technical note on definition of functions
Content
2.1. 1.1. Introduction
2.1.1. 1.1.1. Purpose of this note
The architecture development process (ARCH) used for a railway reference architecture is heavily focused on defining a set of functions that describe the required behaviour (i.e. functional requirements) of the system of interest.
Since the terms “function” and “functional requirement” can be interpreted in many different ways, it is important that a single definition is adopted, to ensure all participants have a common understanding of what is being developed, and thereby to avoid inconsistencies in the description of the system of interest.
This technical note gives the definition of “function” as used for the reference architecture, and explains the rationale behind this interpretation.
2.1.2. 1.1.2. Starting point
The ARCH process is a detailed implementation of the ARCADIA methodology. A key feature of ARCADIA is the separation of concerns and engineering tasks into multiple levels of a model, with traceability between these levels. The ARCADIA method covers all of the structuring activities of engineering in five levels. In the four top levels of ARCADIA, functions are defined (although they are called "operational activities" at the top level).
The elements of ARCADIA's "modelling language" (known as ArcML, but actually not a modelling language, rather an ontology) are defined in an experimental French standard XP Z 67-140. This standard gives the following definition of "function" (translated from the French):
This function definition, when modelled in ontological terms, results in the following visualisation, immediately highlighting the broad nature of the definition.
2.1.3. 1.1.3. Why we need a more specific interpretation
The definition from ARCADIA allows for multiple interpretations of functions. This is reasonable, since the ARCADIA framework is intended to support many types of projects. However, when developing a precise model, it is not sufficient because it can result in a mixture of functions that are more like actions and operations, and functions that are more like services.
This is a problem because it mixes two incompatible paradigms, function decomposition (where the functions are seen more like services) and object decomposition (where the functions are seen more like operations belonging to objects).
The key difference between actions/operations and services (in common interpretation) is that operations have a finite execution cycle (they are called, executed, and return a value) whereas services are persistent (they are available over a longer-term timescale and can be seen as being continuously available). In some programming languages, a "function" is the same thing as an operation.
For a consistent model for the reference architecture, we need to select which of these two options is more appropriate for representing our needs, and set out precise modelling rules to govern the definition of functions.
2.2. 1.2. Definition of a function for the reference architecture
2.2.1. 1.2.1. Limitations
The definitions given here are intended as a general guideline for achieving a consistent model. We might need to make exceptions to how we apply the definition if we encounter a specific case that does not seem to fit the patterns. The architecture cluster should decide if and when to make exceptions to this interpretation.
2.2.2. 1.2.2. Reasoning
2.2.2.1. 1.2.2.1. Viewing a railway system of interest as a control system
The reference architecture for a railway system of interest is a large-scale multi-input multi-output interconnected dynamical control system - that is, its entire purpose is to keep the position of all the trains on the network within safe and optimal parameters and as closely as possible to a defined plan.
There already exist notations and conventions for modelling control systems. These invariably treat functionality as being persistent, like an electrical circuit that transforms its inputs into outputs in a certain fixed (or at least fixed within one system state) way. These functions can be represented in block diagram form and in mathematical form as transfer function and state-space expressions. This leads us towards an interpretation of a function as a persistent service.
2.2.2.2. 1.2.2.2. Description of need vs description of solution
The reference architecture model is intended to describe the required behaviour and constraints of the system of interest and of its subsystems, not to describe the internal structure of possible solutions for subsystems. In other words, the structure of functions in the reference architecture model does not have to reflect any possible implementation and does not have to follow an object decomposition paradigm, as would be followed normally by software engineers implementing one or more system of interest subsystems.
Instead, reference architecture model functions describe the need on the system/subsystem as can be observed from outside. In general, the functionality of the system appears to those observing from the outside as a collection of services that are always available. Consequently, when the inputs to the system change, the services within the system modify the outputs accordingly.
Note: The logical architecture and the subsystem architecture describes functions as needs from the point of view of a subsystem supplier, but an outline of the solution from the point of view of a system integrator.
From our point of view as system integrators, the logical and subsystem functions are our solution to the system-level needs. From the point of view of a supplier, the subsystem functions are a statement of the needs on the particular subsystem they are supplying, but not of the solution they should implement in order to meet those needs.
This leads us towards an interpretation of an reference architecture function as a persistent service.
2.2.2.3. 1.2.2.3. Abstraction by parameterisation
When functions are modelled in a more operation-based style, a result is frequently that several different functions are defined that all operate on the same input and produce the same output, but each function describes a different combination of input and output values.
This can result in inconsistency and a higher-than-necessary function count.
A persistent function can describe how a particular type of output is generated from a particular type of input for all possible input and output ranges (including absent or invalid inputs) - that is, treating the inputs and outputs as parameters rather than triggers. This results in fewer and more general functions, where the behavioural description of the function is a transformation of all possible input values into all possible output values.
2.2.2.4. 1.2.2.4. Event-based vs continuous analysis
It is known, because of external constraints, that several external and internal interfaces within the reference architecture need to be operate in an event-based fashion. This would lead us towards a more discrete-time, operation-based interpretation of functions. However, the underlying need on the system's behaviour is independent of the constraint. If the functions are modelled as continous-time, always-on transformations, this does not obstruct us from using events as parameters, and specifying the functions in terms of the transformation they perform on incoming events. The conversion from event-based or regular sample-based to continous-time flows is itself a mathematical transformation that can be considered to be an always-on function (for example, a zero- or first-order hold applied to an input that consists of regularly-spaced samples, can be called "D/A convertor").
This means that event-based inputs and outputs can still be serviced with continous functions - but the opposite is not true.
2.3. 1.3. Conclusion
To reduce the overall number of functions, improve consistency, and increase the abstraction/solution-independency of the reference architecture model, it was decided to interpret functions in a persistent sense for the reference architecture. The panel below gives the definition of this interpreted function.
A function for the reference architecture is available in a range of system states and is a container for a mathematical behavioural specification.
The behavioural specification describes a mathematical transformation of inputs into outputs and holds for all possible values of input and output parameters defined in the exchange item elements.
A function's involvement in a system capability can be inferred from its inclusion at a particular point in a functional chain or exchange scenario, which tells the reader that the function's outputs change at this point because of a change in its inputs.