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 subsystem interfaces
1. Overview
The subsystem interfaces are the actual interfaces which define how two subsystems (or a subsystem and external system / actor) are talking to each other. Depending on the chosen technology to achieve this, the definition includes exchanged data, the exchange medium as well as the internal structuring, functions and behaviour inside each interfacing partner related to the interface. The following picture shows four possible architectural options for subsystem interfaces with a simple graphical visualisation.
In general, a subsystem interface is determined by content provided of the logical components (i.e. business logic, e.g. railway-domain) and constraints imposed on the physical architecture (i.e. technological choices and constraints, e.g. existing specifications or standards). A subsystem interface sometimes refers to one side of an exchange, but more generally refers to both sides of the exchange and the exchange medium.
2. Pattern for inter-subsystem interfaces
Two interfacing subsystems are internally structured with interface layer components complementing the logical components. The following picture describes the basic concept of an inter-subsystem interfaces focussing on the architectural aspects.
The structuring is a design in the sense of the need (not the solution design of supplier) to enable communication and synchronisation of information between them. This comprises the interface itself as the exchange medium which enables the real exchange of data as well as the internal need design of each subsystem with interface layers.
3. Pattern for subsystem interfaces to external system or actor
A subsystem interface to an external system or actor is very similar to the inter-subsystem interface. The following picture visualises the basic concept similar as for the inter-subsystem interface above.
One difference is that these interfaces are derived from system interfaces of higher abstraction levels (i.e. logical architecture). Also the internal structure of the actor / external system is only considered as far as required for that interface.
4. Pattern for interface layers
Interface layers are used to structure and modularise subsystem interfaces. They are bound to a specific technology for data exchange regarding the considered subsystem interface. The following picture describes the basic concept for interface layers considering an inter-subsystem interface.
Each interface layer consists of at least two interface layer components complementing the logical components for each interfacing subsystem.
4.1. Interface layer components
The interface layer components represent the internal structuring and internal behaviour of the subsystems for the considered subsystem interface. In general, they are responsible for the transformation between the pseudo-continuous world of the logical components to the analogue/sampled/event-based world and vice versa, plus the reactive behaviour on the state of interfaces. This means basically this pattern separates the core control/observe functionality from the functionality to distribute information across subsystem boundaries as separation between transformation and synchronisation.
The following three concepts characterise interface layers. These are independent from each other but blend together when applying them in a concrete context.
4.1.1. Master and mimic role
Two interface layer components of the same interface layer are organised as a pair in where each interface layer componenent has a different role. These are defined as "master" and "mimic". The following table provides a description of these roles.
role | task | meaning |
---|---|---|
master | producer | Source or master of the information. Only the master is allowed to decide what the current state of the information is. It is not meant like a master in terms of a communication protocol. |
mimic | consumer | Sink or mimic which just repeats what it is told by the master. In other words, each type of information only has one master but may have more than one mimic. It is not meant like a slave in terms of a communication protocol. |
Like the exchange direction of information between logical components following the control loop pattern (e.g. between two controllers or two observers) these roles define a clear one-way direction of information exchange always from the master to the mimic. This is very much like a synchronisation relationship. This allows that the behaviour of a single interface layer can be isolated and modelled, and consist of information exchanges representing the master state and confirmation that the mimic has followed the master state accurately.
4.1.2. Symbolic and real data exchange
The exchanges of information between interface layers are distinguished between the symbolic and real data exchanges. The following table provides a description of this concepts.
kind | visualisation | meaning |
---|---|---|
symbolic | horizonal | Conceptual exchange between interface layer components of the same interface layer. This is needed to define and understand which data is exchanged on this layer without considering other adjacent layers. |
real | vertical | Actual exchange betwwen interface layer components of two different interface layers. This is how the data is exchanged with using the adjacent layers. |
In a set of multiple interface layers, the real data between interface layer components of the same interface layer is not exchanged directly between them but only using services of the layer below. The data is exchanged symbolic way directly between them because each interface layer has to care about the data of is own layer which is provided or required from the adjacent layers.
Note: Depending on how the subsystem interface is modelled, the subsystem interface itself typically is a physical link (lowest layer) between two subsystem is a real exchange but can be visualised horizonally.
4.1.3. Resuable and one-off usage
Interface layers can be used differently in relation to concrete subsystem interfaces. The following table provides a description of the underlying concept.
kind | meaning |
---|---|
reusable | Reusable interface layers can be used in multiple subsystem interfaces. These reusable interface layers are probably imposed on the project and are complementing the one-off interface layers. The definitions of the reusable interface layers are in general done independent of their usage in a subsystem or actor/external system. |
one-off | One-off interface layers are only used in context of one specific subsystem interface. Those layers are typically the most upper layer with unique exchanges between a specific pair of two subsystems. |
In general, all interface layers and its components are considered reusable in a context of specifc subsystem interface, but practically there can be the need to define this difference.
Note: A whole subsystem interface is not reusable in that sense. If two subsystem interfaces have the exact same set of interface layers then these are still different interfaces because the subsystem pairs are different.
4.1.4. Ontology
The following diagram of the ontology provides a more formal definition of the pattern for the interface layer components.
4.2. Interface layer functions
The interface layer functions are the functions of the interface layer components. They are responsible for the transformation of the continuous information from the subsystem's logical functions to the analogue/sampled/event-based information and vice versa. This means basically this pattern separates the core control/observe functions from the functionality to distribute information across subsystem boundaries as separation between transformation and synchronisation.
4.2.1. Mimic and master role
The functions of interface layer components strictly follow the given master or master roles of its interface layer component.
role | task | meaning |
---|---|---|
master | producing information | A master function provides data to the mimic function. |
mimic | consuming information | A mimic function replicates the provided data of the master function. |
Similar to the exchange direction of information between logical functions following the control loop pattern (e.g. between two control functions or two observe functions) these roles define a clear one-way direction of information exchange always from the master to the mimic.
4.2.2. Ontology
The following diagram of the ontplogy provides a more formal definition of the pattern for the interface layer functions.
5. Applications
The patterns can be applied to different subsystem interfaces following commonly known layerling principles.
5.1. Protocol stacks
Protocol stacks for computer network communication considering the OSI/ISO reference model are a typical example of a layered subsystem interface. Real data between protocol entities of the same protocol layer (e.g. TCP client and server) is not exchanged directly between them but only using services of the layer below. The data is exchanged symbolic directly between them because each protocol layer has to care about the data of is own layer which is provided or required from the adjacent layers.
5.1.1. Mapping to pattern
The following table shows a mapping between the subsystem interfaces concepts to the concepts of protocol stacks. It is a non-exhaustive overview covering the most importent elements.
concept of pattern | concrete element |
---|---|
subsystem interface (real) | medium (e.g. ethernet cable) API (e.g. between RTE and subsystem) |
interface end (real) | physical port (e.g. ethernet RJ45 8P8C) |
interface layer | protocol layer |
interface layer component | protocol entity |
interface layer component exchange (symbolic) | peer protocol entity exchange (symbolic) |
interface layer component exchange (real) | protocol entity exchange (real) - i.e. exchange between adjacent layers |
interface layer exchange data (symbolic) | protocol data unit (PDU) |
interface layer exchange data (real) | service data unit (SDU) |
interface layer function | protocol entity function (e.g. service to adjacent layers or internal layer functions) |
5.1.2. Protocol layers
For the purpose of DBS/RCA, the following interpretations of OSI/ISO reference model for protocol layers are made as described in the following table.
layer | name | purpose |
---|---|---|
7 | application | information content that needs to be transferred in order to achieve the system capabilities |
6 | presentation | data formatting and type conversion, packet structuring, bit field formats |
5 | session | message sequencing and handshaking, session management |
4 | transport | connection setup, monitoring and shutdown |
3 | network | addressing and routing |
2 | data link | formats for physical transmission, like byte/bit order, parities and checksums |
1 | physical | physical configurations, voltages/energy levels, polarities, frequencies, pinouts etc. |
These layers are a guideline and can be adapted and tailored as necessary for a specific subsystem interface. Sometimes not all layers are needed (for example, a discrete digital relay interface could be adequately represented by application and physical layers only). Where other interfaces define extra layers not explicitly included in OSI, most commonly a "safety" layer for error-detection and correction is included to prevent incorrect data being used in safety critical applications. Where the communications platform is used for networked communications, the network, data link and physical layers should be specified on the interface from a primary subsystem to the communications platform, and not directly on the interface between two subsystems (since they are not actually physically connected to each other, rather they are connected through the communications network). Lower level protocol layers (i.e. from physical up to transport layer) are available as COTS equipment and therefore probably need not be specified as detailed as domain-specific upper interface layers.
Regarding the application layer a difference shall be betwwen the concepts of application vs. application layer: The application relates to the subsystem's interaction over the interface (e.g. sending a PDU) and uses then the application layer protocol as the highest protocol layer. An example would be a web browser as an application may use a number of different application layer protocols e.g. HTTP, DNS which are top-level interface layers in a layered interface.
6. Resources
The following papers and documents include a description of the approach based on examples that have influenced the contents of this page.