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 page was cached on 2023-02-09 - 11:16.

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 | Legal notice | Privacy Policy (german)