ControllerBase Class

This class is intended for application layer objects. Within a control system, each sub-system is supposed to have one object of this class. This class incorporates a state machine and allows to group (sub)systems hierarchically. State transitions are triggered and depend on events sent by users, the status of devices and the states of other controller objects of (sub(sub))systems.

The main advantage is an easier startup of systems and detection of errors and problems within a distributed control system. Moreover, nominal values of a whole system are assigned a configuration ID that can be used to store and re-load different sets of nominal values of a control system.

Principle

Controller objects and their sub-controller objects form a hierarchical tree. Commands are always propagated down to the next lower level of sub-controllers by sending events. State (changes) are propagated up to the next upper level of (top-)controllers as DIM services.

Configuration

Each object of this class may have zero, one or more sub-controller objects. Sub-controller objects are defined via the database (Interface0, ...). The configuration of device classes is taken care by child classes. As an important feature, a state change request may be triggered by a state change of sub-controllers or a change of a device status. For avoiding overloading the system in busy situations, it was decided to check for a required state change only periodically within the periodic action loop. By default, the PeriodicInterval is set to 50 ms. Please note, that this concerns only states changes of the controller object itself, but not receiving state updates by sub-controllers and devices which is done asynchronously via trend message events.

Operation

If required, states of sub-controller objects or devices can be ignored during run-time. This feature is useful, when a sub-system is not used, not operational, its state or configuration needs to be conserved or if the sub-system should be ignored as an example for special intervention. Typically, users will interact with the conroller objects by sending state change requests("Configure", "PrepareForOperation") as well as additional commands ("SaveConfiguration", "IgnoreDevice", "IgnoreSubController",...). Of course, users will interact with device like modifying nominal values.

Child Class GOGController

This GOGController class adds the functionality of managing devices to the ControllerBase class. For doing this, it uses the functionality of the GeneralObjectGUI (GOG) class. Each object of the GOGController class creates an object of the GOG class. That GOG object does not need to be configured via the database. The frontpanel of the GOG object is not shown. However, system administrators will open the front panel to add and configure devices.

Naming Conventions

1. The GOGController object has the name SYSTEMNAME, which is the name of the (sub)system.
2. The GOG object of the GOGController has the name SYSTEMNAMEGOG.
3. The setting file of a GOG has the name SYSTEMNAME_configID.gog, where configID is the configuration ID that is sent to a ControllerBase object when a state change is requested by sending a "Configure" event.
4. The temporary setting file (see below) for each GOG object has the name SYSTEMNAME_tmp.gog.
5. The backup of the temporary setting file fear each GOG object has the name SYSTEMNAME_tmpBackup.gog

Temporary Setting Files

When entering the CONFIGURED state, the original setting file is copied to a temporary file. The GOG object then just loads the temporary file. When a configuration is saved, the GOG object save it to the temporary file and then copies the temporary file to the official setting file. This has the following reasons.

1. The "original" setting file is protected and remains unchanged, unless a user request to save the actual configuration. All changes done by administrators (or users) in a GOG won't effect the original setting file. Thus, it is easier to go back to the original settings in case a mistake has been done.
2. Using a temporary file allows for automated saving of backup-settings to the temporary file without affecting the original setting file. This can be complemented by automated submission of the temporary file to a subVersion repository.
3. If users missed to save their most recent settings (or after a system crash), they can easily recover their settings by copying or loading their temporary files. Of course, this must be done prior to the next "Configure" command.
   Note: There might be a good chance that there is even a backup of the temporary file. The backup of the temporary file is written as soon when the system is properly shut down (the GOGController objects are destroyed).

Usage

(Sub)systems are configured via it's GOG. An administrator connects to the machine where the GOGController and its GOG are running, opens the front panel of the GOG, adds devices and configures the methods, and finally saves the settings to the appropriate file name (see "Naming Conventions" above). This configuration is rather crucial and should not be done by operators.

GUI Class GOGControllerGUI

This is a base class for GUIs of the GOGController class. (Note: A GUI for the ControllerBase class does not exist, since this class does not handle the use of devices.) Its main intention is to provides methods that can be used by derived classes via direct method calls. Those methods should make the implementation of GUIs much simpler. This is best demonstrated by the GOGCtrlDemoGUI class.

Class Documentation

Instead of writing many details, it is probably easier for the reader (and less work for me) to have a look at the class documentation. Please check the following classes.

• ControllerBase (including its state machine)
• GOGController
• GOGControllerGUI

Example GOGCtrlDemoGUI

For an example, please have a look at the GOGCtrlDemoGUI class. The sources contain a folder DemoSystemSettings. Import all required objects into the configuration database by using the SimDevices4Demo_db.ini file. Eventually you need to change the database entries for objects of the classes GOGCtrlDemoGUI as well as GOGController so that complete path to the folder DemoSystemSettings is correct. Then it should be sufficient to load the settings file STARTME_DemoSystem.gog ino the UserGOG.

-- DietrichBeck - 02 Feb 2010