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

CAS1

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

CAS2 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
Topic revision: r3 - 2009-08-25, DietrichBeck
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding GSI Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)