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 system interfaces
- 1. Definition of system interface with non-human actor
- 1.1. Context
- 1.2. Pattern for non-externally constrained system interfaces
- 1.3. Pattern for externally constrained system interfaces
- 2. Definition of system interface with human actor
1.1. Context
System interfaces are the interfaces between the system and external actors/systems in its environment. It describes how the systems communicate by allowing mass, energy, and information to flow between them. It is a high level of design that will provide the foundation for the requirements which will be needed at the lower, more detailed levels (e.g. subsystem interfaces).
At the system level, an external interface may impose constraints on how the system should be designed. Each external interface with constraints should be defined as far as possible. Nevertheless, only those layers that are externally constrained and/or relevant to the interface should be modelled. The concept of a layer comes from an approach called Open Systems Interconnect (OSI), which identifies the interface layers involved in different tasks. The reference model for OSI is available here. For the purpose of ARCH, the following interpretations of OSI are made:
- application layer - information content that needs to be transferred in order to achieve the system capabilities
- presentation layer - data formatting and type conversion, packet structuring, bit field formats
- session layer - message sequencing & handshaking
- transport layer - connection setup, monitoring and shutdown
- network layer - addressing and routing
- data link layer - formats for physical transmission, byte/bit order, parities, checksums...
- physical layer - 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 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 to prevent incorrect data being used in safety-critical applications.
In some cases a system interface is defined without considered or available external constraints. The following picture describes this basic representation, focussing on architectural aspects.
The system and the actor exchange data through a physical link between them. But, in order to have details of the interfaces, symbolic exchanges are represented (those in dotted lines).
warning
The component exchange can be associated to an "application layer" of the OSI approach (see above), but an allocation of functional exchanges between core functions to a component exchange is only allowed for non-externally constrained system interface.
System and actors have interfacing functions complementing the system functions. The following picture describes the basic concept of system interfaces, focussing on architectural aspects.
The system and the actor exchange data through a physical link between them. But, in order to detail the interfaces, interfacing functions and symbolic exchanges are represented (those in dotted lines). These exchanges are present in the model but do not represent the real path of the information. These are more "direct" plots that simplify the understanding of exchanges in certain situations that do not require a high level of detail. All these concepts will be refined at the physical level.
Each external interface might have a variable number of layers defined at system level, depending on how heavily it is constrained from external needs/requirements/constraints. The intention here is to ensure external constraints are captured so as to steer design decisions appropriately, but to leave open for the designers all possible aspects where they still have freedom to make architectural decisions. Only at physical layer must all these factors be completely resolved.
1.3.1. Interfacing functions
1.3.1.1. Tasks of interfacing function
It is an active function when the system and an actor need to communicate with each other through a specific constrained interface. They are organised in pairs (one allocated to the system and one allocated to the actor) and have the same tasks. The following table provides a description of the tasks.
Task | Meaning |
---|---|
Producing information | The interface function provides data to another interfacing function or to system functions. |
Receiving information | The interface function receives data from another interfacing function or from system functions. |
When interfacing functions exchange between each other, the functional exchange and the component exchange are modelled depending of the externally constrained interface layers.
1.3.2. Exchanges between interfacing functions
1.3.2.1. Constrained layers
As explained above, only externally constrained layers (referencing to the OSI layers) are supposed to be represented. Where an external standard/specification dictates the nature of the interface, the interface to the system of interest shall exactly reflect the implementation of that standard. A symbolic exchange of the data should already be represented by the system functions and functional exchanges that interact across the system boundary in the existing scenarios used as input to this activity. Then, depending on the constrained layers, there may be at least one functional exchanges between the interfacing functions. Same work for the component exchanges: each functional exchange linked to a specific interface layer need to have a dedicated component exchange (see example below).
Where it is not yet known how an interface layer will be realised, the component exchange or physical link should still be created. This indicates that a gap is known and can be managed.
1.3.2.2. Symbolic and real data exchange
The exchanges of information between concepts are distinguished between the symbolic and real data exchanges. The following table provides a description of these concepts.
Symbolic | Conceptual exchange between elements of the same interface layer (function, component, etc.). This is needed to define and understand which data is exchanged on this layer without considering other adjacent layers. For example:
|
Real | Actual exchange between the system and the actors thanks to different interface layers (application, presentation, physical, etc.) This is how the data is exchanged with using the adjacent layers. |
Info
Symbolic and real exchanges have to be modelled.
1.3.2.3. Oriented-flow exchanges
Note that these exchanges may be bidirectional depending on the representation of the interface (see example below). And as functional exchanges are oriented flows, both directions the exchanges between interfacing functions have to be modelled. It is not necessary for component exchanges because they can be non-oriented flow.
1.3.2.4. Multiplicity of interfacing functions
Be careful, the system may have multiple interfaces with the same actor and in consequence multiple pair of interfacing functions with the same actor (depending on the existing constraints imposed by the actor or by interoperability requirements).
1.3.3. Support of the pattern
- Create interfacing functions within the system and the actor;
- Create functional exchanges between the interfacing function and the system functions;
- Create functional exchanges between the interfacing functions, one (or two if the functional exchanges are bilateral) per constrained interface;
- Create one component exchange between the system and the actor per constrained interface and link it to the corresponding functional exchange(s) between interfacing functions;
- Create a physical link to represent the physical layer of the interface (as a placeholder for any physical constraints).
1.3.4. Logical components of the system for externally constrained interfaces
RCAMT-678 - Getting issue details... STATUS
1.3.4.1. General information
The following picture describes the basic concept for logical components for interfaces of the system, focusing on architectural aspects. For each system interface the system has a dedicated logical component (called interface endpoint). Those ones encapsulate the interfacing functions for the considered interface. See Method for definition of logical components for the allocation of the interfacing functions to specific logical components grouping the functionality of a specific externally constrained system interface. For subsystems, the logical components representing the interface endpoints are then later refined to individual interface layer components (see also Method for definition of subsystem interfaces).
1.3.4.2. Multiplicity of interfacing functions at logical layer
As for the system level, it is possible to have several interfaces with the same actor. In this situation, interfacing functions of a same entity are allocated to different logical components. This choice multiplies the number of logical components, but will facilitate the traceability of the elements of a same interface (components and/or functions) between the logical layer and the methodology put in place at the subsystem layer (see Method for definition of subsystem interfaces for more information).
Info
This section just describes the current knowledge about how to model HMI interfaces (e.g. in Capella). Applicable standards or other information available to validate these documentation and ideas are not considered or analysed yet. This will be done in future versions of this page if necessary. Also the HMI will be part of a wider topic Human System Integration" in the future.
2.2. Model the HMI functionality
Based what is defined in ARCH.M.010 Method for definition of functionality the following functional pattern should be used for a HMI system interface:
Explanation for "Display / Indicate / Illuminate / Generate the xyz" function:
To show the human actor the human-perceptable state, a function from the indicate category needs to be selected. This function converts information from an estimated state or a required state into a human-perceptible form (audible, visual or haptic).
Explanation for "Register the abc input event" function:
If the human actor takes a control decision and provides a required state into the system a function shall register this event on the HMI. The register function registers the HMI input event for abc from the human actor and transforms it into a continuous input state requirement for the abc state inside the system. The assumption at the moment is that the function that is called register belongs to the control category, this may be changed in the future.
Indicate same information to more then one actor:
In a situation were a single function's output crosses the system boundary and reaches two or more human actors. That is, both/all actors use the same information, but because they are separate actors, their interfaces and presentation may be different. But until there is a consideration of where the actors are in relation to each other, and whether separate displays/connections are needed, the function stays as one single item feeding the output to both actors;
So at system system analysis level and logical architecture level each information type should only be indicated by one function. At subsystem level, this will be further decomposed if necessary (for example, because two users need the information presented in two different locations or in two different formats). The rational way to do not split this on logical architecture level already is, that there would be logical components like "indicators". At logical level there is then only one of these per information item defined. At subsystem architecture level they could then realised in different physical places.