ClassType vs FunctionBlock
The ClassType is supported since UP Version 3.14.0 and is the logical continuation of the object-oriented approach in the domain model. Due to its many advantages, the ClassType will replace the FunctionBlock in the application model in the future.
| ClassType | FunctionBlock | Description | |
| Combining data and function | x | x | Both the FunctionBlock and the ClassType offer the possibility to combine function and data. |
| Encapsulation of the data | x | o | FunctionBlock All data (except the local non-persistent data) are accessible from outside. ClassType All data (Member) are basically private. I.e. they are not accessible from the outside. The model offers the possibility to make a member readable or writable via the configuration of a getter or setter. |
| Inheritance | x | o | FunctionBlock Not available. ClassType Probably the biggest advantage of the Class type is the possibility of inheritance. Thus, for example, a class can be created with a basic functionality and, depending on the purpose, data can be added and methods can be added or overwritten. Thus it is no longer necessary, as with the FunctionBlock, to develop option monsters. Also the need to make copies just because a functionality is slightly different in one use case is eliminated. |
| Instantiation in the controller interface (Method call Parent-Child) |
x | o | FunctionBlock Not possible. ClassType ClassType objects can be instantiated in the controller interface. This means that methods can be called by the parent in the child controller interface (for example, calculations). This call takes place in the task context of the parent controller (immediate return value) and does not have to be executed inconveniently using handshakes. Furthermore, calculation results no longer need to be copied to Interface. As soon as a ClassType is instantiated in an interface, you can access results using methods. |
| Method call from the ServiceUi | Future (is currently being implemented) |
o | In future it will be possible to execute method calls via the ServiceUi/HMI. Therefore it is no longer necessary to execute certain calculations via auxiliary state change/commands but can be executed directly from the ServiceUi/HMI (via MQTT). |
| Generic Classes | Future (hopefully available soon) |
o | Base classes/interfaces with additional generic behavior: Event/Button Class: Representation as button at service Ui → Button click is calling abstract execute() method which must be implemented by user (for asynchron behaviour like reset a drive, ...) Item / Property Class: equivalent to normal Cur, Par Structure property, but native support for subscription / unsubscription over MQTT / Service ui, for refreshing values without polling. This gives us the key to connect a PLC Application easily without custom implementation to a WebService, Cloud, IoT, Industrie 4.0, ... * Promise, Observable, BehaviorSubject |
| IoT ready | Future (is currently being implemented) |
o | Class methods communication channel is MQTT instead of OPC-UA. Today as direct channel between ServiceUi backend and PLC. Without a lot of additional implementation, this architecture is ready to connect the PLC over a MQTT Broker to ServiceUi, HMI, remote Ui, mobile device. This means, the PLC can stay save between Network infrastructure with firewall. Remote connection is available over a running broker, security is implemented while connecting to Broker. |