Skip to content

UP

UP is a metamodel and a set of rules for machine control applications. The model describes what a machine consists of and how it behaves — and it is the source from which PLC code, documentation and tests are generated.

UP vs. UPstudio

UP is the system of models, rules and generators. UPstudio is the development environment in which these models are edited.

flowchart LR
    T["ControllerTree\nonce per project"]
    C["Controller\nthe reusable type"]
    I["ControllerInterface\ncommands · I/O · public data"]
    S["Statemachine\nstates · transitions · functions"]
    T -- "instantiates" --> C
    C --> I
    C --> S

Three elements, and everything else follows from them: the ControllerTree divides the machine, a Controller is one functional unit, its Statemachine is its behaviour.

ControllerTree

Functional units in a hierarchy of levels. A parent commands its children through their interfaces; the children report their state back. Commands never run upwards — that is what keeps a unit reusable, because it does not know who is using it.

flowchart TD
    subgraph L1["Level 1"]
        H["Handling"]
    end
    subgraph L0["Level 0"]
        C1["Cyl1"]
        C2["Cyl2"]
        C3["Cyl3"]
    end
    H --> C1
    H --> C2
    H --> C3
Level Role
4 · Top MAIN and general services such as HMI or file handling
3 · Group head of a complete function group, strongly machine-related
2 · Module a function within a group, often instantiated several times
1 · Element group smallest group of similar elements
0 · Element one task, reusable, the interface to the hardware
Driver hardware-specific, between element controller and hardware

This is the usual division, not a fixed scheme. The number of levels is not limited, and a real project deviates where it helps: skipping a level it does not need, and adding levels of its own — dedicated levels for interlocks or for communication, or one for a machine-specific group of elements.

Each occurrence in a level is a ControllerInstance of a controller type.

Controller

The smallest self-contained unit, modelled once and instantiated as often as the machine needs it. Public through its interface, private in its InterfaceLocal.

flowchart LR
    C(["Controller"]) --> IF["ControllerInterface · public"]
    C --> SM["Statemachine"]
    C --> LOC["InterfaceLocal · private"]
    IF --> CMD["Commands"]
    IF --> IO["Inputs · Outputs"]
    IF --> DAT["Public data\nConfig · Parameter\nRecipe · Current"]
    SM --> STS["states · transitions"]
    SM --> FNS["entry · state · exit"]
    LOC --> LV["Local variables"]
    LOC --> MSG["Messages"]
    LOC --> MTH["Methods"]
    LOC --> ILK["Interlocks"]

Commands are defined globally; a controller knows only the ones it reacts to, and the parent-child relation establishes the command channel automatically. The four data groups differ in who may write them and when: Config comes from the plant configuration, Parameter is set in manual or setup mode, Recipe may change during production, Current is written by the controller itself.

Statemachine

One per controller, following the UML state machine specification, drawn as a diagram. State, SuperState for hierarchies, and SuperState_WithBusyFinal which brings its start, transition and target state with it.

stateDiagram-v2
    [*] --> INIT
    INIT --> OFF : Cmd OFF
    OFF --> ON_Group : Cmd ON
    state ON_Group {
        [*] --> ON_busy
        ON_busy --> ON : position reached
    }
    ON_Group --> OFF : Cmd OFF

Each state can run entry on entering, state while active and exit before leaving. Around them the statemachine runs initFunction once at start and alwaysFunction_before / alwaysFunction_after every cycle.

The statemachine reference works the execution order through five situations and covers simulation and the constant values states get on the PLC.

Generation

One model, several outputs. Each output is a folder linked to the target project, declared an Actifsource target folder, with a BuildConfig added to it.

flowchart LR
    M["UP model"]
    M --> TB["target folder\n+ BuildConfig"]
    M --> TS["target folder\n+ BuildConfig"]
    M --> TC["target folder\n+ BuildConfig"]
    M --> TO["target folder\n+ your BuildConfig"]
    TB --> OB["B&R Automation Studio"]
    TS --> OS["Siemens TIA Portal"]
    TC --> OC["Beckhoff TwinCAT"]
    TO --> OO["HMI · report · test harness"]
Platform Configuration Setting up a project
B&R Automation Studio PlatformConfig_BR Setup BR project
Siemens TIA Portal PlatformConfig_S7Tia Setup TIA project
Beckhoff TwinCAT PlatformConfig_Beckhoff Setup Beckhoff project

The mechanism is not specific to PLC code, so a project can add a generator of its own — for an HMI, a report, an interface list. UP itself works that way beyond the PLC: the help system generates this documentation through a HelpBuildConfig, and the TextManager generates text lists.

Where the detail is