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 functional chains
Table of content
Info
Capella talks only about a functional chain from system level onwards, in operational analysis, it is still called operational process, the methodology is the same for both, therefore no further distinction is made.
Open points:
- Is it needed to have more then one functional chain per capability?
1. Overview
The system is designed to carry out missions that require a set of capabilities in order to be accomplished. Each of these capabilities is described by a sequence of functions that use dependencies between them in a given context. Depending on the pre- and postconditions, these can be formalised in different ways, in particular via functional chains (or scenarios described in Method for definition of scenarios).
As a starting point we have the functional chain concept of Arcadia that is defined by Jean-Luc Voirin in "Model-based System and Architecture Engineering with the Arcadia Method" as follows:
"A functional chain is an ordered set of references to functions and the functional exchanges that link them, describing one possible path among all the paths forming the data-flow. Functional chains are used to describe the system behaviour in a particular usage context, to contribute to one or more system capabilities. Each reference to a function or exchange inside the chain can be qualified by an expectation in the context of the chain (the value that an exchange item or a function attribute should take, for example)."
Furthermore:
"A functional chain also specifies constraints or expectations of precedence or anteriority via oriented sequence links. A set of functions and sequence links is a sequence. Control nodes can be defined between the sequence links, to express the parallelism or alternative between several sequences of functions, or, also the iteration or condition of a sequence to be realised."
Based on the definition, a few refinements are described in the following sections, so that in the overall context the functional chain is compatible with the other defined methods. e.g. ARCH.M.010 Method for definition of functionality.
2. Pre- and postconditions
As mentioned before a functional chain has a pre-and post-condition as well, this should be the same conditions of the capability. The functional chain may be used to refine its owning capability by limiting the features applied to it. As a result, the pre and post-conditions of the owning capability may apply only partially to the functional chain. In such cases, the preconditions and postconditions of the functional chain may be refined from those of the owning capability. So the related functional chains can have different end conditions. A capability should contain all relevant conditions for all of the functional chains it contains. They can be differentiated in the description using OR relationships.
3. General guidance for a functional chain
The interpretation of the functional chain for ARCH is that with the help of oriented sequence links it is possible to describe in which sequence the functions are expected to change or modify their output value over time. A function involvement means that when the chain of sequence links reaches this particular function involvement, the output value of this function has changed. More precisely, the target function cannot produce its expected outputs before receiving the inputs produced by the source function. The references to functions are called in Capella "functional chain diagrams function involvements". They are not functions themselves but can only be created to represent functions that already exist. The functional chain viewpoint exists to show sequential order of functions without considering allocation of the functions. For the functional chain diagram is makes sense to allow plenty of space so that it is possible to set the diagram out in a neat and orderly way; these diagrams quickly become unreadable if the left-to-right or top-to-bottom convention is not followed.
4. Sequencing and control flow concepts
Three types of control nodes are possible: parallelism (AND), optional branches (OR), iterations/loop (IT). The control nodes and sequence links can be compared a bit with a functional flow block diagram or SysML v1 activity diagram.
OR:
- Where a decision is made between two or more possible, mutually exclusive paths in the process the OR node is used to split one incoming sequence link into two or more outgoing sequence links.
- Where two or more alternative paths come back together to a common path the OR node is used to merge two or more incoming sequence links to one outgoing sequence link.
AND:
Where two or more branches of the process run in parallel/concurrently the AND node is used to split one incoming sequence link into two or more outgoing sequence links.
Where two or more branches of the process run in parallel/concurrently the AND node is used to merge two or more incoming sequence links into one outgoing sequence link.
This does not mean that AND nodes must be always used as matching pairs where the number of outgoing links from the first AND equals the number of incoming links to the second AND, as long as all parallel branches are eventually terminated by an AND.
IT:
- Where the same function or sequence of functions occurs more than once within a functional chain.
- Where the execution logic of the functional chain requires a return loop from a later function to an earlier function.
Sequence links does not have the semantics of triggering in Arcadia. Since we have defined functions in ARCH.M.010 Method for definition of functionality: Technical note on definition of functions as persistent our interpretation of the sequence link is as follows: A sequence link between two functions (between function references, in fact) shows that the output value of the source function has changed before the destination function can change its output value.
The following examples explain the concepts more in detail:
- The output value of F1 changes before F2 does change the output value.
- F1 and F2 are not necessarily connected by a functional exchange.
- F2 requires a change of the output value of FE12 from F1.
- F2 and F3 change their output values after F1 changed it.
- F4 can start after F2 and F3 changed their output values.
- Before starting, F2 needs FE12 from F1.
- Either F2 or F3 changes their output value, according to the condition attached to their respective sequence link.
- F4 can start after F2 or F3.
- Before starting, F2 needs FE12 from F1.
- F2 requires for returning to a previous part of the functional chain.
- F3 requires to repeat a part of the chain multiple times.
5. Assembling functional chains
Functional chains can be assembled and reused in order to express more complex scenarios. The definition for the ARCH methods is that a functional chain is assembled in another one in case of that the that there is an include/extent relationship between the respective owning capabilities In that case the included or extended functional chain should be connected to the functional chain of interest using sequence links. The included/extended functional chain will be displayed minimised.
6. Create functional chains
When creating functional chains enough information about how the system works with the actors for this capability shall be available. Functional chain description diagrams are directly derived from knowledge and must only be developed by a view that complies with all the modelling rules. If, on the other hand, it is necessary to gather information, a brainstorming workshop should be held. There should be sufficienet number of participants represent knowledge/concerns of all the involved actors and functional areas of the system.
A brainstorming session should identify sufficient functions and functional exchanges to get from the starting conditions to the ending conditions, and identify the decision and sequence logic that is needed (parallelism, optional branches, iterations). The number of internal exchanges (that is, functional exchanges between pairs of functions that are both allocated to the same component) should be kept to a minimum. Where new functions or functional exchanges are identified, these should be first created.
7. Update functional chains
If the functions are further decomposed so the initially functional chains needs to be updated, so that the newly created functions are now represented in the updated functional chain description diagram.
Do the following modifications for the functional chain:
- If involved functions were decomposed during functional decomposition replace the function involvements on the functional chain such that only leaf-level functions are involved.
- If the logic of the functional chain has changed because of alterations to arising from decomposition update the logic of the functional chain so that it is consistent with the rest of the model.