ControllerTree Application Method

Basic Idea

The ControllerTree concept is an approach to abstract complex machine or plant functionality into manageable functional units. By using this concept, the development and maintenance of machine software is simplified.

UP is a tool that embodies the ControllerTree concept. Not only does the tool support the use of the ControllerTree concept, it also provides countless additional functionality and libraries to support the entire life-cycle of the machine software

ControllerTree

The ControllerTree is the central element of a UP application. It is used to divide a machine process into functional units, so-called Controller. The tree defines a hierarchy in which the higher-level controllers communicate with the lower-level controllers. Communication takes place via the controller interface. The subordinate controllers (child) are commanded by the higher-level controllers (parent).
The ControllerTree exists in a project only once.

class ControllerTree extends BaseControllerTree, ACallingBaseElement

Communication from bottom to top is not allowed.

Level

The hierarchy of the ControllerTree is defined by levels. The number of levels used is not limited. Within the levels the controller is instantiated.

The usual levels are defined as follows:

Level 4, Top Level:
MAIN controllers and "general services" like HMI, Filehandler, ... which have nothing to do with the control function.

Level 3, Group:
Group controller, strongly machine-related, head of an entire function group.

Level 2, module:
Modules which perform a corresponding function in a group can also be instantiated several times within group or within a whole machine.

Level 1, Element group:
Smallest group of similarities, summary of simple element controllers, which do not necessarily have to be addressed separately.

Level 0, Element:
Lowest level of the controller, fulfills exactly one task, reusable, interface to the hardware.

Driver, Driver:
Hardware-specific configuration, interface between element controller and hardware (typical application for controllers with motion tasks -> controller is identical, drivers differ depending on the drive used).

class Level extends NamedResource

ControllerInstance

The ControllerInstance is an instance of a controller. A controller is instantiated in the ControllerTree.

The controller instance is the application-specific version of the corresponding controller. In the context of the ControllerTree, various elements are defined which define the uniqueness.

class ControllerInstance extends AnnotableComment, RangeChildFieldRef, BaseTreeElementInstance

Controller

The controller is the central element of a UP application. A controller defines the smallest, intrinsically functional unit.

A controller essentially consists of two main elements:

• Interface and data
• Statemachine

In addition, the controller has the definition of relations to Child controllers.

A controller can also be described as an instantiable type that is instantiated in the UP - ControllerTree.

Controller extends NamedResource, AControllerDescription, AnnotableComment, DatatypeLibraryOwner, RootVariableLibrary, RootVariableName, AOoDomainRoot, ACallingBaseElement, AResourceWithType

ControllerInterface

Definition of public informations of a Controller.
A Controller interface can implement other interfaces and inherits all its elements.

class ControllerInterface extends NamedResource, AnnotableComment, DatatypeLibraryOwner

Command

Commands are typically used to trigger transitions between states. Each controller has a command interface through which actions can be triggered on the controller.
Commands are defined globally. However, a controller only knows the commands to which it should respond.
The parent-child relationship in the controller tree automatically establishes a command channel for top-down commands.

class Command extends NamedResource, AnnotableComment, ATextSourceProperty, AResourceWithType

Mode

ToDo

Data

All public data of a controller is defined in the interface data.

class InterfaceData extends AInterfaceData, FieldUnit, AOoExtendable

Config

The configuration parameters form the machine. They define the layout, the size, the existence of modules and machine parts. There is exactly one configuration file, which is valid for the corresponding plant / machine.

class Config extends InterfaceData_deprecated

Current

The current structure contains the actual values of the respective controller. Basically, this structure is in the writing authority of the own Controller.

class Current (deprecated) extends InterfaceData_deprecated

Parameter

The machine parameters contain all the setting values of the individual modules. The machine parameters can only be edited in manual or setup mode. During production, the machine parameters are fixed.

class Parameter extends InterfaceData_deprecated

Recipe

The recipe parameters contain all product-specific parameters. The recipe parameters form a subset of the machine parameters and can be edited during the production mode.

class Recipe (deprecated) extends InterfaceData_deprecated

Statemachine

Each controller has a state machine. It is generated automatically when the controller is created. The state machine describes the sequence or logic of a controller. The state machine is based on the specification of a UML state machine.

The statemachine has a graphical representation (diagram). This supports the developer when creating states and transitions.

The UML state diagram shows the different states a controller can be in and the transitions between these states. A state represents a stage in the behavior pattern of a controller. It is possible to have start and end states. An initial state, also called creation state, is the state in which a controller is at startup, while an end state is a state from which no transitions lead out.
A transition is a transition from one state to another and is triggered by an event that is either internal or external to the controller.

class Statemachine extends AStatemachine, AStatemachineStart, RootVariableName, ASmDecorator, AJunctionProperty

Functions

initFunction

The init function is called at the start of a controller and before the cyclic processing of the state machine.

notExistBehaviour

This class defines the behaviour of statemachine if controller exist flag is false. Without any definitions, native single answer implementation is active.

Use singleAnswerOverwrite definition to change single answer behaviour dependent of requested command.

Define a function to implemement another specific behaviour during single answer mode.

class NotExistBehaviour extends Resource

alwaysFunction_before

This function is called cyclically before the states of the state machine are executed.

alwaysFunction_after

This function is called cyclically, after processing of the states of the state machine.

State types

State

A state can describe a static situation in which the controller waits for an event, or it describes a dynamic situation (such as the execution of a task).

SuperState

The SuperState (or Composite State) allows the modeling of hierarchies of states. In a hierarchical state diagram, as it results from compound states, several states that are in a hierarchical relationship to each other can be active simultaneously. If a state that is part of a hierarchical state is active, all states in the same hierarchy are active.

In the following figure, StateA is in a hierarchical relationship to SState2 and SState1. Since StateA is active, SState2 and SState1 are also active.

SuperState_WithBusyFinal

This state extends the SuperState with an initialization function. When this state is created, a start state, a transition state and a target state are created.

class SuperState_WithBusyFinal extends SuperState

State functions

Each state has the possibility to call functions at different times. Any number of functions can be defined.

entry

This function is executed and completed on entering the state before any further actions are called.

state

This function starts after entering the state (and after a possible entry function) and is executed until it ends or the state is exited again.

exit

When leaving a state, but after the entry or state function, the exit function is called and completely processed. The state can only be left after this.

---

Best practice

State representation on PLC

Like commands, states are represented by constant values on the PLC. In principle, states always receive automatically the next free constant value during generation. With the following exceptions, the assignment of constant values to the states can be influenced:

1. If a state is named the same way as a command (caution: case sensitive), the state gets the same constant value.
2. If a superstate with busy and final state has the following structure, the superstate receives the value of the corresponding command -2 and the busy state receives the value of corresponding command -1.

---

History State

State machine sequence

Simulation

Simulation is a central element of modeling the state machine. A realistic simulation allows testing the software without or only with parts of the hardware. Basically every state that is in exchange with hardware should have a behavior in case of a simulation.

There are two different types of simulation:

1. Single- Answer simulation
2. state simulation

Single Answer Simulation

The Single-Answer Simulation is the simplest form of simulation. It is activated as soon as a controller is available but switched to not-exist. Essentially, the command sent is confirmed directly with the corresponding status.

Example:

Parent > Child, Command = START

Child > Parent, State = START

This type of simulation expects a state with the same name as the command and that this state is the objective of the command.

State Simulation

In the state simulation, a behavior for the simulation case is modeled for each state. When a controller is put into simulation, the hardware is separated on the software side. This allows hardware signals to be set in the simulation function.

Common Controller Functions

The controller has a set of functions at its disposal to command itself and the direct child controllers and to query statuses:

_Common Model Functions

Interlock

Message handling

UP has a configurable message system. Messages are mainly used to report errors, warnings or other information.

However, it is also possible to send messages to a controller or a controller group without this being visible on the HMI.

Logger

UP has a configurable logging system. The underlying idea is that values are logged into a log cloud from different locations. This cloud can then be used by different clients. For example, a client can create a log file or persist values in a database.