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 operational activities
Content
1.1. 3.1. Observations on the pattern for functions
The pattern originally developed for functions (Method for definition of functions) may be used to define operational activities, but after trying it out with a couple of operational processes we made the following observations:
- It is not always clear to the modellers what object or concept is having its state controlled, and this can still result in inconsistency;
- It is not intuitive, especially not to a non-engineer such as an operational stakeholder, to have only one operational activity that enacts all state changes belonging to one object or concept; this is not how operating procedures read.
From these observations, the following conclusions are reached:
- We must always try to establish what thing (data object or abstract concept) is having its state controlled, even if the current model is not very clear on it;
- this can be illustrated by a state machine for states that can be modelled as a small set of discrete states;
- for more continuous states, this might need to be illustrated by a mathematical definition e.g. a range/domain of values over which a state is defined;
- sometimes it can be useful to have both a continuous definition and a discrete-state definition (i.e. hybrid system), for example speed could be defined as a continuous range from 0 to 400 km/h, and as a set of discrete states "stationary", "up to 40 km/h", "41 - 160 km/h", "161-400 km/h" if it were useful to do so.
- Some of the more intuitive existing operational activities only operate on part of the state model of the object or concept being controlled; that is, an activity is permitted to make only a subset of the total number of state changes possible for any given state; for example, "accelerate the train" could change the state from "stationary" to any of the other speed ranges; "brake the train to a stand at service braking rate" could change the state from any speed range state to the "stationary" state; this is crucial because activities expressed in this way are prime candidates to be turned into system capabilities, and the starting and ending states then become prime candidates for start and end conditions of the system capability.
1.1.1. 3.1.1. Impact on definition of operational activites
Preferred way where appropriate:
We can define a pattern for operational activities that allows them to be defined at two abstraction levels:
- The original control system level, where all the possible states of an object are controlled/observed etc. with one activity,
OR
- two or more activities that each only enact a subset of the possible state transitions for that object.
There is a relationship between these two levels - they are not completely independent of one another. This is useful because if we always define the top level, but leave it out of operational processes, it can be used as a prompt for us to check that we have sufficiently decomposed the top level activity - that is, that there exist sufficient activities enacting partial transitions to cover all the possible state transitions for the object.
If we follow the second option, which can result in clearer/more intuitive operational activities, then we must also model the state space to define the transitions that these activities achieve.
It is not mandatory to begin with one abstraction or the other, but after completing the model, it should be possible to identify what the higher-level activities are, even if they don't exist in the model. That is, if we model the activities "open the train doors" and "close the train doors" we should be able to infer that there exists a higher-level activity "Control the open/closed state of train doors".
It is not mandatory to use the word "state" inside the name of an operational activity, but it can sometimes help to do so.
Because the operational level works with abstract things without concrete physical implementations, there should be no need to separate actuate, plant and sense activities; these can be rolled together in one activity. It is not forbidden to separate them, but they should only be modelled at that level of detail if it is strictly necessary.
In the first instance, this pattern should be used to form most operational activities that have something to do with core real-time operation of the railway:
So if some kind like control and observe activities also exist as types of operational activities on operational level, the pattern for configuration can also be used. As there is no system, the question when and how the data cross its border is obsolete. Thus, the data supply process is not relevant and the function ontology is simplified compared to the System level.
1.1.2. 3.1.2. Fallback
where the pattern is not appropriate, it needs to be selected an appropriate English verb for the name of an operational activity.
Where an operational activity resembles the name of a system function, this is not necessarily repetition in the model. This tells us that there is a business need for something to be done, and that it will be done wholly by the system.
Indicators of an operational activity are:
- You can imagine this being a line in someone's job description
- It's a step in a ruleset or procedure that happens regardless of whether or not it is done by an automatic system or humans or a combination of both
- Its scope is part of, but not the whole of, a customer/actor journey from an initial condition to an ending condition
Operational activities can be pushed down to system level with automatic transitions and turned into any one of:
- system mission
- system capability
- system function
The scope of an operational activity, coupled with our decision on how much to automate, determines which of these options we use.
See capability method definition for further guidance on how to deal with operational activities.