Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
Set of examples for definition and decomposition of functions
Content
Warning
In the following page, a few examples are described. Please note that these are only examples and do not claim completeness and correctness of the defined contents.
1.1. 5.1. Example 1 - Set the point position
1.1.1. 5.1.1. Define system functions for "Set the point position"
If we take a simple turn out like the one in the picture below and draw out the mechanical parts, we can immediately draw a couple of very important conclusions:
- we do not directly control the position of the switch rails; more precisely, the control system is of the form of a cascaded control system, where there is an inner loop for controlling the state of the actuator (usually, this means voltages on the terminals of a motor);
- we assume, based on a model of the mechanics of the switch, that the state of the actuator has an effect on the position of the switch rails;
- we do not directly observe the position of the switch rails;
- we infer the position of the switch rails from the state of proximity switches in the locking mechanism of the point.
Even if we stand at the point and watch the switch rails move from left to right and vice versa, we can only infer from what we can see that the point is in the internal state "LOCKED RIGHT" that we might need in order to pass a train safely.
Conclusion: all four of the basic control system functions are present: control, actuate, sense, observe.
It is important for us to be precise about what we control, actuate, sense and observe.
Our model of the position state of the point defines states like LOCKED_LEFT, LOCKED_RIGHT and UNDEFINED. These are internal states - because we cannot know directly which of these states the point is in. We can only infer it from what we sense. Yet it is this internal state that is meaningful and useful to us because we need to have the point in a LOCKED_LEFT or LOCKED_RIGHT state before we can safely run trains over the point, in a facing direction.
The hand sketch below neglects the following (but the Capella output that follows does not):
- Occupancy of the point by a train unit
- Reservation of the point by an existing movement permission
- Usage restrictions affecting the point
- The availability state of the point
Initial sketch
Example in capella AMOD-056 System functions and exchanges (single system capability)
1.1.2. 5.1.2. Split the system functions for "Set the point position"
The starting point was the system definitions of functional flow and functional chain as described before.
Automated transition in Capella is needed ARCH.M.060 Method for the execution of automatic transition in capella.
Example in capella AMOD-081 Logical functional flow definition
The functional flow at logical level has been laid out in a similar way to that at system level, but note elements have been laid over the diagram to indicate the splitting principles that were used.
This example is particularly simple because only one of the splitting principles is really used - the abstraction layers.
Open point DPS group availability - there was some doubt over whether there should be both an observer and a controller of DPS group state - it was decided that it is something that is controlled by the system based on other observations rather than directly being observed, so a control function was considered sufficient, but this might need to be discussed.
Splitting results - "control the position state of one point"
The function "control the position state of one point" is split along the abstraction layers only. Note that the object abstraction layer doesn't make any transformation of the required state of the DPS, so there is no function needed at this level. This will cause debate in RCA - open point - should placeholder or postbox functions be included every time, so that the chain is always complete? See the next function - this would become ridiculous when three or more layers of the abstraction layering do nothing on the information.
It is already only one function type ("control"), so no further split is needed.
Similarly, it already operates on only one multiplicity level (one point) so doesn't need to be split along the lines of many points/one point (note here though that there are implicit differences in multiplicity between functions in this chain - "control the state of one point actuator" could be instantiated many times for one point - so the multiplicity factor may need to be removed as a splitting principle, and replaced with a rule that says functions must always operate on one individual thing; this is an open point.).
It operates only on one object type (point) so there is no further split for object type.
It is purely safety-critical so there is no further split for safety criticality.
Splitting results - "observe the position state of one point"
Similarly to the control of the point's position, no split was necessary along the lines of function type (all observe), object type (already only for a point), multiplicity (all one) or safety-criticality (already all safety-critical).
Here, the split along the lines of the abstraction layers is different because the final output is obtained from the device abstraction layer, and layers above that layer do not add or transform the information.
Note that the estimated position state of the point is fed back to the control of the position state directly at the device control layer - reflecting what an object controller really does.
1.2. 5.2. Example 2 - joining 2 trains
This is a much more complex example than example 1 and required considerably more time to model.
Train unit A is stationary; train unit B is approaching and will couple up to A. Train Unit A simply prepares itself for coupling and waits; Train Unit B prepares itself for coupling, enters on-sight manual driving mode and moves up to Train Unit A, engaging the couplings and then carrying out the checks and reconfigurations required for onward operation.
Example in Capella AMOD-056 System functions and exchanges with color code to match ontology