I will try to explain by examples what I want to see on FncBlocks diagram
Let look at some functional block that should calculate output based on input
output = FncBlock2 (input)
a = f1 (input)
b = 5
c = f2(a, b)
output = (c, b)
using only ports (no variables)
using “variables” (or data objects betwee functions)
using variables and variable references
Data ports and variables can be typed by Capella classes.
This diagrams shows only data flows. There is no control flows here.
For contorl flow definition Behaviour Trees or Decision trees could be used.
In case of Behaviour Tree B, F1, F2, F3 will be referenced from leaf actions.
Why use different meta-model for modeling behaviour of atomic functions?
In this way Capella “atomic” function remains atomic and does not decomposed into functional blocks
In this way Statecharts and Behaviour Trees defined for components can used atomic function but not functional blocks.
In other words using different meta model makes main model compatible with Arcadia\Capella.
Atomic functions specify signature but does not specify how output is “calculated” from innputs
More over functional exchanges with Operation exchange type have control flow semantics but not only data flow.
Functional blocks specify how outputs are calculated and does not contains any control flow semantics.
We don’t want decompose atomic function 2 to F1, F2, F3. We want to allocate to components atomic functions but not functional blocks.
Data flows and data ports can be allocated to functional exchanges and functional ports. The same way as functional exchanges are allocated to component exchanges.
Not sure I understand well. But what is for sure is that functional exchanges in Arcadia represent dependencies between functions in terms of what is exchanged (data, mass, energy) and not control flows.
Your FcnBlocks remind me the Function Blocks defined by IEC 61499 standard:
This is clearly out of the scope of Arcadia, which doesn’t address the detailed definition of leaf functions behaviour.
I would suggest to create a new forum thread on this topic, and to differentiate the BTree (which can be useful without introducing this level of detail) and these FcBlcks (which could be useful indepenently of the BTrees).
I understand that defining behaviour of atomic functions is out of scope for Arcadia.
In IT projects where I mainly used Capella I needed to specify behaviour of atomic functions.
I think Functional blocks are similar to blocks from IEC 61499.
FunctionalBlocks can be used without BTree. I even created another viewpoint for their definition. I will create another topic on modeling atomic functions using functional blocks.
But BTree can be used to modeling control flow of functional blocks inside atomic functions. From this point of view they are connected.
There are 4 main use cases for BTree usage
Functional blocks can also also connected with ComplexValues in some way and my ComplexValue viewpoint I’ve created to define mappings between ComplexValues.
ComplexValue viewpoint helps to define mapping between intput and output parametes of functional blocks.
There is another notation where Functional Blocks is used. See xod.io
It’ a visual tool used to create programs for Arduino, ESP8266, ESP32.
In this tool data flows and control flows are modeled on the same diagram.
To model control flows (ticks) diferent type of exchanges are used. (in parallel with data flows)
Done and UPD ports can be connected. Some tick (from clock) can be connected to UPD port. Or some modificator (for example Loop) is applied to UPD port.
In more detail execution model of XOD is described here
Leaf actions\conditions in Behaviour Tree notation communicate over the Blackboard.
It’s a key\value storage global to Behaviour Tree that can be used by any leaf actions\condition.
Each Behaviour Tree has each own Blackboard.
Input\output pins are implemented over Blackboard by using the same name for ports.
Also Blackboard value can be set or read by any leaf function.
Behaviour Tree notation does not define visual notation for data flows diagrams.
Visual notation I’ve published before for data flows between Functional Blocks can be easily mapped to Blackboard objects
When Behaviour Tree is used with atomic functions data flows between functions are modeled by functional exchanges. Input\output pins send\receive not individual data but ExchangeItems that contains individial data that is called ExchangeItem Element.
In other words in case of atomic functions data pins are modeled implicitly by functional exchange pins and their ExchangeItem Elements. It can be interpeted as composite functional pins (typed by ExchangeItem) that contain data pins (ExchangeItem Elements typed by data types).
On the diagram below functional blocks are shown inside it’s parent atomic function.
In this diagram internal parts of the input port for atomic function is shown as 3 level port.
FunctionInputPort -> ExchangeItem -> ExchangeItemElement
Ports on the third level is typed by Classes and have directions (red - input, gree - output)
ExcgangeItemElements of atomic Function is mapped (delegated) to DataPorts of FncBlock.
Below is the demonstration of detailed behaviour specification for atomic functions.
Functional Blocks and Behaviour Tree are used for this specification.
Root FunctionalBlock is created inside the atomic function.
Behaviour Tree is created Inside the root functions block.
Control flow for atomic function is defined using Behaviour Tree
While BTree is created sub FunclBlocks are added to the root Functional Block.
FncBlocks can be grouped into any hierarchy and don’t depends on structure of BTree nodes.
Data ports and DataFlows between sub FuncBlocks are defined using new data flow diagram.
When diagram is created root FncBlock is shown automatically. On the border of the root functional block input and output ports of parent atomic function are shownn. For functional ports detailed structure is shown based on exchangeItems and exchangeItemElements specified for ports.
This ports are used for mapping (via delegate) between elements of functional ports data ports of sub FuncBlocks.
As mentioned, functional blocks as presented are part of design/implementation, not architecture anymore. Did you generate some code out of this or just defined internal structure of an atomic functions and later coded it by hand? If I had to define internal structure, I’d prefer to generate the code instead of redoing textual implementation, which means we’re close to implement some open source Simulink equivalent 
The notation of functional blocks is also a little bit troubling to me as both FncBlocks, F1 and F2 are just normal functions, so they shall exist somewhere in a functional decomposition. Just F3 is some abstract code element, also ‘b’ constant can’t be modelled as it’s not a function:
And some details of allocated exchange items/elements can be specified on interface level.
Nevertheless, your last video is very interesting, just a use case is not so clear yet, e.g. what should be the relation between actions and functions?
Yes. it’s design
This FuncBlock notation is 2 days old. So not yet )
Let’s look at an example from software engineering.
Take class A and define several functions inside this class. And define main function that implements control flow (business logic of this class) and execute other class’ functions in some sequences.
All of this function when executed also implements some control flow (but more technical one) : analyze input parametes, prepare parameters for external functions, calls external function, analyze results, create objects based on results and so on. I named this actions as functional blocks.
We don’t want to know about them in the main control flow (busines logic). We don’t want to subdivide functions defined in class.
In case of Capella modeling we want to have class functions to be atomic functions in functional decomposition. And used them in statechart\behaviour tree defined for component.
In othere words we don’t mix busines logic with technical logic.
In IT projects there are a lot of “technical” work and logic inside atomic functions. Data are prepared, services are called, mapping between different strutures are made. In our case software implementation was done by several subcontractors. They had not very good understanding of data architecture in our system. We needed to define a lot of mappings for atomic functions:
between input data and called services, services results and atomic function resul and so on.
I’ve created special viewpoint to define these mappings (ComplexValue Viewpoint). Aftre mappings are defined we needed some way to define control\data flow inside atomic functions and “attach” these mappings to blocks of this flow. We did decomposed atomic functions into functional blocks as part of functional decomposition and attached mapping to leaf small functions. I don’t think this is a good aproach as “business logic” mix with “technical logic”.
I think this question can arise.
In Capella there a logical architecture and physical architecture. And someone can advise to
use physical architecture to add “tecnical logic”. And keep logical architecture clean from them.
I should say that FunctionalBlocks are not from physical architecture. We wanted to stay on logical architecture and specify behaviour of atomic functions in more detail.
In physical architecture FunctionalBlocks will not become physical functions.
Functional Blocks can be used on all level of architecture to specify atomic functions in more details but preserving level of abstraction for atomic functions.
Meta model used for functional decomposition is not good for defining internal behaviour of atomic functions. This meta model was not designed for FunctionalBlock level.
On this level one block calculates some variable and some other block use it. We don’t want to define ExhangeItems and pack data into it to “transfer” data to the other block. We want to define simple data exchange typed by data type we are transfering.
It’s normal to pack data into “signatures” and interfaces on the atomic function level. But it’s not good to model data transfer between two blocks of code inside one atomic function.
Term “actions” I use from Behaviour Tree notation. It’s a leaf node of Behaviour Tree. “actions” is a means to call “atomic functions” or “FncBlocks” from BehaviourTree.
If Behaviour Tree is defined for a component then actions reference atomic functions from hierarchical decomposition. If BTree is defined for atomic functions then “actions” reference to FncBlocks.
I’m coming from embedded world, so thinking rather in software components and their interfaces than classes and methods, therefore for me having function as a smallest element of architecture w/o depicting its internal behaviour is perfectly OK. But I understand, that in your case it might be not enough.
Leaf functions on higher architecture layers not necessarily have to be atomic - e.g. you can realize system function by one or more logical functions, which can be realized by one or more physical functions. So if you’re designing your system architecture on all layers it’d make sense to define functional blocks on a lowest layer.
Wondering if activity diagram from SysML wouldn’t be better here were you can have as many levels as you need and also design data flows and control flows simultaneously.
I think that FunctionalBlocks can be used on all levels. I will try to describe my understanding later.
Have spend more than 7 years with Rational Rhapsody (SysML and UML) at the same time with Thales. Was very glad to be able to swithch to Capella. Don’t want to switch back )
Don’t think it’s a good idea to have control flows and data flows on the same diagram.
Diagram becomes overloaded with information of different types.
On the next step I plan to prototype flowchart notation to specify simple control flows inside atomic functions.
They will use functions\FuncBlocks in the same manner as BTrees…
Data flow diagrams for Functional Blocks will be used in conjunctions with flowchart.
I think I will implement data flow on flowchart also but don’t plan to use it. May be in very simple cases.
Let’s look at Capella leaf functions from “call stack” view.
And let’s define 3 levels of functions of different levels. Functions of high level call middle level functions. Functions of middle level call low level functions.
In data flow digram we can show this like this
In functional decomposition functions of all levels will be “atomic” functions
This is the correct way of using functional decomposition in Capella.
We can clearly see that Capella helps to define functional interactions but does not define behaviour of functions.
There is the only way to define behaviour of HighLevelFunction is to allocate functions to components and define behaviour using statectart
Let’s allocate HighLevelFunction and MiddleLevelFunctions to HighLevelComponent
And define behaviour of this component on the statechart
In high level state it executes HighLevelFunctions1. In “middle level” states it executes MiddleLevelFunctions
We see from the statechart that MiddleFunction2 and MiddleFunction3 are called only in some condition.
Another way to specify the behaviour of HighLevelFunction is to use Functional scenarios
Will continue in next post how to define the same behabiour using FunctionalBlocks and BTree notation.
FncBlocks and BTree helps us to define behaviour of any atomic functions. In the same manner we can define behaviour of high lelevl, middle level, low level atomic functions (see example from previous post). We don’t need to create components to define behaviour of higl level functions and can define behaviour of any atomic fucntions.
If want to specify bahaviour for HighLevelFunction we can add FncBlock behaviour specification that contains
Behaviour Tree that define control flow for FncBlocks
data flow diagram that defines detailed data flow betwee FncBlocks
BTree definition diagram is used to specify control flow and helps to define FncBlocks (leaf actions)
FncBlock data flow diagram helps to define in details data flows betwee FncBlocks. It also delegates dataflows to input\output ports of parent function (HighLevelFunction).
I plan to change visual notation for delegate ports.
Dataflow diagram does not show “call results” (return). Every FncBlock can return: SUCCESS, FAILURE or RUNNING. The same result type for all FuncBlocks. Based on this result BTree make decision about next node execution.
The result model created for specifying detailed behaviour of function HighLevelFunction wiil look like this
Leaf actions in BTree are involvements of FncBlocks.
When detailed data flows between FunctionBlocks are defined it’s possible to add addition information about behaviour of separate functionBlocks. In many cases behaviour of FncBlocks that call some other function is simple. It takes own input parameter, prepare input parameter for function call. Receive output parameter from called function. And prepare it’s own output parameter.
For such simple FncBlocks it’s possible to use ComplexValues to define data mapping between different parameters
For example in CallMiddleLevelFunction1
For this puprpose we use ComplexValue Viewpoint to define mappings between different parameters.
I wiil add example of using ComplexValues with FncBlocks in next posts.
Using FncBlocks we was able to specify behaviour of atomic function in detail without decomposing atomic function to small functions like “Call MediumLevelFunction”. It would be incorrect usage of functional decomposition in Capella.
