CS Access System

Introduction

The CS Access System (CAS) provides the possibility to lock (and unlock) objects or sub-systems for exclusive use. As an example, if an object or a sub-system is locked via a GUI, the object or sub-system will only accept events from that GUI but will no longer accept events from other GUIs.

CAS based on a very simple mechanism and not intended to prevent malicious attacks. CAS is meant to prevent simultaneous and accidential access of shared resources from different parts of a distributed control system. A typical use-case are two operators (A, B) sitting at different consoles trying to change the setting of the same power supply without knowing about each other. In such a case, operator A can lock the power supply. The object representing the power supply will only except events from the GUI of operator A, but operator B can not operate the power supply from his GUI.

CAS has been written in LabVIEW and licensed under the GNU Public License (GPL).

Principle

CAS is based on a publisher-subscriber mechanism. This mechanism is implemented via a dedicated thread for each object and a CSAccessServer.

• For locking and unlocking, objects form a hierarchical tree. Each hierarchical tree can be called a sub-system. A sub-system must consist of at least one object.
• Each object has a so-called AccessID.
• When sending an event, each object sends its AccessID together with the event data.
• When receiving an event, an object only accepts the event data, if its own AccessID matches the AccessID coming with the event data.
• For each object, the CSAccessServer publishes the name of the parent object of that object.
• Each object subscribes to the CSAccessServer to obtain the name of its parent object.
• Each object publishes its own AccessID.
• Each object subscribes to the AccessID of its parent object.
• The CSAccessServer is the generic top object for all objects.
• If an object is not locked, any other object can become the parent object of that object via the CSAccessServer.

The result is the following:

• All object within a sub-system inherit the AccessID of the top object of that sub-system.
• Every object in a sub-system can send an event to all objects within the same sub-system.
• If a sub-system is not locked,
  • the top object of that sub-system is the CSAccessServer.
  • all objects on the network can send events to every object of that sub-system.
• If a sub-system is locked,
  • the top object of that sub-system is an object, that is its own parent object.
  • only objects within the sub-system can send events to other objects of that sub-system
• Locking a sub-system only requires to lock the (previous) parent object of a sub-system.
• Locking and unlocking of sub-system can be done on-the-fly.
• Partitioning and re-partitioning can be done on-the-fly.
• The configuration of the default parents of all object within the CSAccessServer
  • is important,
  • should be static and can be saved/reloaded to/from files,
  • should not be accessible to normal users.

Example

The figure above shows a control system with three sub-systems, "A", "B" and "C". For each object, the CSAccessServer publishes the name of the tree parent. This is shown for the objects "A1", "A2", "A4", "B1" and "C1". Here, the two sub-system "A" and "B" are locked. Sub-System "C" is not really a sub-system, since its tree parent is the CSAccessServer. Therefore, sub-system "C" is not locked. Any object in sub-system "A" can send an event to any other object in sub-system "A". As an example, object "A1" may send an event to object "A6" and object "A6" may send an event to object "A1". Same for sub-system "B", where all objects of "B" can communicate with each other. However, sub-system "C" is not locked. So any object of sub-systems "A" and "B" may send events to any object of sub-system "C".

Locking of a Sub-System

In the above figure, the CSAccessServer has changed the parent name of object "C1" from "CSAccessServer" to "C1". Now, sub-system "C" is locked. Any object in sub-system "C" will only accept events from objects within the sub-system "C". Objects from sub-systems "A" and "B" can no longer send events to objects of sub-system "C".

Partitioning

In the second figure, the CSAccessServer has changed the tree parent of object "A2" from "A1" to "A2". The effect in the tree structure is dramatic: The objects "A2", "A4" and "A5" now form an own sub-system "A magenta" which is locked. "A2", "A4" and "A5" can communicate with each other. The remaining objects of the previous sub-system "A" ("A1", "A3" and "A6") can still communicate with each other. The sub-systems "A magenta" and "A" are completely independent like the sub-systems "B" and "C" (In fact, it would be better to draw the sub-system "A magenta" on the same level as the sub-system "A", "B" and "C".) No object of sub-system "A magenta" can communicate with any object of sub-system "A" and vice versa.

Download

CAS is already included in the core system of CS, see here.

-- DietrichBeck - 18 Jul 2006