Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
Method for decomposition of functions
Content
1.1. 4.1. Split the system functions for the logical architecture
The logical level of the architecture is concerned with abstract partitioning of functionality. Therefore, when we split functions at logical level, we can only do this on the basis of some logical or abstract splitting principle.
1.1.1. 4.1.1. Define the relevant splitting principle
The subsections below define the splitting principles for a reference architecture functions.
It can also be that the following criteria overlap, not all criteria must always be taken into account to split a function of interest, use only those that are meaningful for a corresponding function.
1.1.1.1. 4.1.1.1. Function category
In theory, the function category should already have been set at system level. We allow for the possibility of a mistake at system level or a further refinement to be done for the logical architecture.
Task: Identify if system level functions are already categorised into specific function categories as defined in the relevant function pattern
- E.g. Railway operation functions (control, actuate, indicate, sense, observe or the placeholder for plant (actor) functions)
- E.g. Configuration data (provide, maintain)
- E.g. Data maintenance or software update functions (pattern yet to be defined)
After splitting along these lines, each function should fit individually into one of the categories.
1.1.1.2. 4.1.1.2. Operated object type
Operated object means one of two things:
- concrete railway assets
- abstract concepts
where the "thing" has some kind of state that can change over time, whether this is a discrete state (on-off) or a continuous state in the sense of state-space modelling (scalar or vector quantities such as position, speed, acceleration).
The "object" here is the object of the phrase that defines the function, for example "sense the rotational speed of one axle" has operated object "axle".
The number of possible values is equal to the number of items in the railway ontology plus the number of abstract concepts defined in the model, excluding any duplicates.
Task: Identify the operated object types
1.1.1.3. 4.1.1.3. State type
Each operated object may have multiple types of state that need to be controlled/observed/etc. separately.
For example, the operated object "train unit" has many different state types: motion state, headlight state, horn state, door locking state, door open/closed state, air tightness state.....
It is not always necessary to split functions to manage each possible state type separately, but where interface constraints indicate a grouping or split (e.g. where there are two separate interface specifications each governing a subset of the overall set of states controlled for one object) then it may be sensible to split functionality along that constraint line, thus separating concerns from each interface specification.
Task: Identify for each operated object the types of state that can change over time. This could be:
- Discrete state (e.g. state type "point position" has possible values "left", "moving/unlocked", "right")
- Continuous state in the sense of state-space modelling (scalar or vector quantities such as position, speed, acceleration)
Note: Theoretically there are three types of states: discrete, continuous, and "hybrid". The latter refers to a state variable whose value may suddenly (i.e. discontinuously) change.
1.1.2. 4.1.2. Preparation in capella
- As a starting point choose a realised capability and the defined functional chain for this capability.
- This is the functional chain of interest within this chain are the core functions of interest, those that are linked with sequence links. These functions should be now split, if needed.
- Functions which only provide information to a function of interest should be decomposed as part of other realised capabilities (if they are already decomposed, the LDFB needs to be updated/refreshed so that the last leaf level function is shown on the diagram).
- Open the LDFB diagram for the chosen capability. The diagram should show all the functions of interest for the functional chain which describes the capability.
- It can help to use text boxes on the LDFB diagram to show the relevant logical or abstract splitting principles behind the functions. (note: this is helpful to add later the mandatory splitting rationale against the function)
1.1.3. 4.1.3. Split one function of interest
Note: if there exist already logical functions in the model, this functions shall be reconciled with the transferred system functions or with the new leaf level logical functions as part of this process step. So that at the end only one set of consistent logical functions exists which are traced to system functions.
Decide now for each function of interest which splitting principles to apply. Perform the following steps:
- Check if there are any mistakes or misunderstandings regarding the pattern for function categories and check if a further split is needed based on the functional category. If not, decompose this logical function of interest, so that the function can fit into the defined functional categories.
- Check which individual operated object type should be handled by the function. Confirm that the function operates only one individual object into the logical level, taking into consideration that one function that controls one individual operated object type can be instantiated many times. If the splitting principle seems correctly applied, split this logical function of interest so that the function can operate the individual operated object type as required.
- Check if the function needs to be split according to state type . This will depend on how much detail it is considered useful to show. For example, when controlling the state of one point machine, it is only necessary to show that we are controlling the left/right drives, not that we are controlling the individual states of each wire on the interface; on the other hand, when controlling the state(s) of one train unit, we are interested separately in the state of the emergency brake, the state of the service braking and traction, the state of the air-tightness, the state of the brake types enabled... so it makes sense to split the functions down in this instance.
- Check if this function needs to be split along the defined abstraction layers.
- Split this logical function of interest so that the function can provide the required functionality on each abstraction layer.
- Split a function only for a specific layer when the input state and the output state of the function have been modified. Functions should only be created within a layer if an additional new functionality is really added or an operated state can assume a different state by the new function.
- Split/Create the functional exchanges between the split functions and connect the existing functional exchanges from the parent function to the new leaf function.
- Define a rationale to justify why the system function was split and the splitting principles which were taken as the basis for the split.
- Define a description for each newly created function.
- Finally, a realisation relationship to the original system function/function exchange should be established for all newly created logical functions/functional exchanges.
Note: during consolidation of the functions, the function that has been transferred to logical layer and split into logical functions will be deleted. - Start with the next function of interest or finish by cleaning up the diagrams/views.
1.2. 4.2. Instantiate or split the functions further for the subsystem architecture
This sections needs further updated in the future.
Reason to instantiate functions:
- The function of interest and the logical component were the function is allocated, should provide the functionality in more then one subsystem. If that is the case the logical component and the function needs to be instantiated within different subsystem boundaries.
Reason to split a function further:
- Due to subsystem specific properties it can be necessary that a function behaves differently in different subsystems. A logical function can then be split so that this individual behaviour is distributed to one function per subsystem.
Abstraction layers:
The abstraction layers are a core concept for a structured architecture for the subsystem architecture which can be used to decompose functions according to different levels of abstraction.
The abstraction layers are defined as following for the RCA / OCORA project:Abstraction layer name Description and examples All other generic function Functions which provide common capabilities needed for other functions in more than one of the other layers, including interaction with the human users and maintainers of the system, configuration and diagnostic data management, and access to single-source data.
Plan implementation Functions in the Plan Implementation Layer execute railway operation plans by generating discrete states for controlling operational movements, operational restrictions or operational warning measures.
- One abstract plan and one state of one abstract object (e.g. operational plan to required drive protection section position state or journey profile to required target speed profile)
- Two types of abstract plans (e.g. operational plan to journey profile)
Safety control Functions in the safety control layer ensure a safe future state of the railway by validating that required states lead to a safe state of the railway given the current state of the railway, providing authorised state, and reacting to unsafe states of the railway.
- One safe state of one abstract object (e.g. position state of one drive protection section or speed profile "state" of one movement permission or movement authority into safe braking curve)
Object aggregation/abstraction Functions in the object aggregation layer distribute and disaggregate abstract objects to abstract device objects, and aggregate current states from abstract devices into abstract objects. Functions observing one state between different abstract objects (e.g. TVPS state from/to moveable object state)
Device abstraction Functions in the device abstraction layer abstract between states of the abstract devices, and those of specific devices.
- One state between one abstract object and one concrete object (e.g. point state from/to drive protection section state or movement permission to movement authority)
- One state between one abstract object and another abstract object
Device control (Concrete) Functions in the device control layer control specific devices into physical output to the controlled device. They also sense or observe the physical state of the controlled device.
Functions controlling/observing/actuating/sensing one state of one concrete object (e.g. one point machine, TCMS actor)
Task: Identify if the function of interest needs to be split along the architecture layers