Using behaviour three notation for behaviour description in Capella in comparison with statechart notation

Will try to add more user need’s oriented answers.

Arcadia and Capella features

  • strict sequence in the process: at first atomic functions should be defined and after that behaviour should be defined using state machines
  • does not help in specifying behaviour of “atomics” functions

There is a need for the following approach:

  • “atomic functions” need to be defined during behaviour specification (the same way as interactions are defined during scenarios creations)
  • there should be an opportunity to specify behaviour of atomic function in detail

BTrees can help with theses needs:

  • BTree supports an approach when atomic functions are defined during behaviour modeling
  • BTree can be used on different levels : from high level to the low level behaviours (atomic functions behaviours)
  • BTree can be easily introduced in Capella due to using semantic information for composite functions to specify control flows (no need to model control flows explicitly)

Capella introduced a very simple tool for functional analysis. BTree adds an option to specify behaviour in the same simple manner, without using additional modeling constructs.

Have created the first prototype of the Behaviour Tree Viewpoint for Capella.

This viewpoint adds new diagram types:

  • Behaviour Tree Definition Diagram helps in creating Behaviour Tree nodes of different types

  • Behaviour Tree Sequence Diagram helps in defining tick scenarios between parent->child nodes

You can see the demonstration on youtube

In my opinion it would be better to implement BTree notation as part of Capability Realisation mechanism. It would be more consistent than mixing BTree control flow with data flow on functional decomposition level (conditions, decorators, sequences and selectors are not functions (actions)).


1 Like

I agree that it is a possible approach. And it should be also implemented in BTree viewpoint.

I used to name it “in a Capella way.” In this way composite functions in hierarchical decomposition do not have execution semantics. In this way leaf-functions are atomic.

There are several elements where BTree could be used in this way

  • in capabilities
  • in functions (in the same way as functional chains)
  • in components (in addition to statecharts)

In this way a new separate meta-model for BTree needs to be defined.
It’s more convenient than “stereotype” elements using property values.
It gives possibility to show BTree node types in model browser (using icons)
New BTree element type can be added to existing elements (using Capella element’s extension mechanism)

I will add support of this approach to the viewpoint also.

Have create separate meta-model for BehaviourTree in Capella

Now it’s possible to add BehaviourTrees in function, capability and component elements for all Capella model levels (OA, SA, LA, PA)


Elements can be created via model browser using standard Add Capella Element menu

I need to make a decision now about linking leaf-nodes to functions.
There is an architecture trade betwee

  1. 1 to 1 mapping (one leaf node of BTree is linked to one atomic function)
  2. 1 to N mapping (one leaf node of BTree is linked to several atomic functions)

Currently I’ve selected 1 to 1 mapping.
1 to N mapping can be compared to statechart possibility to add several functions for entry\do\exit actions
May be In BTree this approach should be also used.

Abother decision about link implementation

  1. using an attribute in leaf-function
  2. using separate link elements that cab be added to leaf-functions

In the second case it will be possible to show linked functions in Model Browser.

The way is done for Functional Chains is IMHO quite consistent: a Function is involved in a Functional Chain. The involvement is an element of the model, and the relation is 1 to 1. This is because if a Function is involved in a FC more than once, each of these involvements say something about the expected behaviour of the function in this particular context. If leaf nodes are actions, I think it could be done in a similar way.

Thanks for your comment. Currently I’ve selected this way (1 to 1 mapping)

In this video I show how functions are used (involved) in Behaviour Tree by reference

It is possible

  • to create new functions from BTree diagram
  • to rename functions from BTree diagram
  • to add existing function involvement to BTree diagram via drag and drop from browser
  • to change function involvement (action) via function drag and drop from browser

In this video I show how Behaviour Trees can be included in each other

It’s possible

  • to include existing behaviour trees via drag and dtop from browse to diagram
  • to create new behaviour trees from diagram
  • to change BTree inclusion via drag and drop from broswer to existing reference on diagram
  • to create new diagrams for included behaviour trees
  • to navigate to diagrams of included behaviour trees

There is some thoughts aboout condition node enhancements.
Currently condition node can be defined by any text in BTree model.

It will be good to be able to reference other model elements from a condition node
in the same manner as guards and triggers are defined in statecharts

  • condition node can reference any constraint from model
  • condition node can define triggers by referencing exchange items of different types
  • condition node can references function from functional decomposition (to check function results)

some more type of references ?

Have added a possibility to move sub trees on diagram

  • double click on some element (all subtree element’s will be selected)
  • move this elemen (all subtree will be moved) on diagram

Some thoughts about using BTrees in components

If BTree is contained in a component
It will be good to automatically allocate to this component functions that are not allocated yet

  • created via Behaviour tree definition diagram
  • referenced in Behaviour tree by drag and drop from browser

It will be good to prevent referencing functions in BTree
that are allocated to another component.

In this case Behaviour Tree will clearly define behaviour of a component based on functions allocated to this component.

Some thoughts about using BTree in capabilies

if BTree is defined in a capability all functions referenced by BTree should be added to the Cappability as involved functions. It should be the same result as for data flow diagrams in capabilities and scenarios.

Check out for instance the Sequence Links in Functional Chains. They have a Condition field, which can be completed by the user referencing any element in the model, including constraints, exchange items, …

It’s the most flexible solution, but not necessairly the one the guides the engineer in the best way. I’m not a BTree expert, but there may be attributes that you shall fill regarding a condition. As an example, in Sequence Links you shall define the “Links” attribute, and the options are restrained to the involvements of functional exchanges between the functions.

It’d be better to apply execution order numbering to transition arrows instead of names of elements:


BTW, is the numbering necessary at all if it’s known that BTree execution goes always from left to right (or top to bottom)?

1 Like

Thanks! I like your proposal. Will change to this way.

At this point numbering is neccessary to sync diagram with model browser.
Numbering helps to understand that nodes order in model and diagram are different.
On diagram you can easily change order of nodes.
After that you also need to change order of nodes in model browser.

Uploaded BTree prototype code to github

Link to BTree update site (for Capella 1.4.2)

After installing you need to activate viewpoint for aird file (aird > context menu > Viewpoint Selection > Behavior Tree Viewpoint)

this release contains both approaches

  • BTree as part of functional decomposition
  • BTree as an external model to functional decomposition

You may consider adding this project to the Labs 4 Capella:
It makes it more visible for Capella users :+1:

I will be ready in a week or two.
Need I write to ?

I also like an approach with typed attributes. I will add some in the next version.

Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.