ALPHA-VISION® Basis: VISUalisation SIC

VISUalisation SIC

SUMMARY

‘Station in Control’ is a subsystem of the ALPHA-VISION^® VISU Software; it offers the opportunity to control the permissions among the stations of a multi-user-system and is intended as an enhancement to the standard access protection system.

CONTENTS

1. Definition of Terms
2. Basics
3. Runtime Structure
4. Parameterisation
5. Online User Administration
6. Considerations when Configuring
7. Actions and Functions for SIC
8. Data Object Events
9. Loss of a SIC
10. Scenarios

Definition of Terms

The term ‘Station in Control’ stands, on one hand, as a name for the overall concept and on the other, for an individual area of activities resp. for a collection of function numbers.
Where reference is made to SIC as a concept, the word ‘SIC’ appears without an article. Where a special SIC reference is intended, it is referred to ‘one SIC’ or ‘several SICs’.

Function numbers range between 1 and 99. A function number, independent whether assigned by an entry in the user profile or obtained by requesting an SIC, authorizes the user to initiate protected functions.

Basics

In the current version of ALPHA-VISION^® VISU a simple access control concept is used.

• Users log into the system by entering a user name and a password.
• A user profile is assigned to each user.
• A user profile consists of a collection of function numbers.
• If a functionality in a project has to be protected, a function number is assigned to it. At runtime, the system checks whether the function number is included in the user profile of the logged in user.

The SIC is designed as an extension to the normal access protection system.

• A SIC contains a collection of function numbers. A user who acquires a SIC gets these function numbers in addition to those contained in the user profile.
  (The amount of function numbers acquired with an SIC is referred to as the SIC profile later on.)
  For acknowledge, reconfiguration, control, etc., the function number configured therefore must be contained in the SIC profile.
• A SIC is protected against unauthorized access by a function number.
  - A user must own the function number to gain the SIC.
  - This function number is referred to as the ‘SIC protection number’.
• To a SIC it is assigned whether it is a single or a multiple one.
• A SIC-Assignment-Table allows several real SICs to be assigned to one SIC as requested by the application.
  This table allows to allocat the appropriate SIC to a user with the according rights.
  Wherever in the following text it is necessary to distinguish we will refer to requested SICs as ‘logical SICs’ and already received ones as ‘real SICs’.

Runtime Structure

At runtime, SIC is realised by the following structure:

• A matrix with as many rows as stations and as many columns as SICs. That matrix allows at runtime to determine which SIC is available on which station.
• An array over all stations indicates which user, resp. which user profile is currently active on any station.

Parameterisation

Till VISU2000 is completed, configuration is performed by using the resources provided for user management and by making entries in an INI file.

The SIC profiles are entered using the VISU-browser. There is no difference between user profiles and SIC profiles, i.e. a profile with a specified number can be addressed either as a user profile or a SIC profile.
If it is necessary to distinguish between the two, the numbers must not overlap.
The authorization to acquire an SIC is stored as a normal function number in the user profile.

Settings which cannot be defined by using the browser are entered in the INI file.

[SIC]
SIC.Entry01=1,1,99
SIC.Entry02=1,11,90
SIC.Entry03=1,12,95
SIC.Entry04=2,2,99
SIC.Entry05=2,21,95
SIC.Entry06=2,22,90

The individual entries SIC.Entry01, SIC.Entry02,...to SIC.EntryXX contain the most important information about the SICs.
The first number in the entry specifies the logical SIC, the second one specifies an assigned real SIC, and the third one specifies the SIC protection number the user profile must contain in order to acquire the SIC.

2 SICs are defined in the example above. Numbers 1 and 2 as they e.g. may requested via button A and B.
SIC #1 is replaced by SIC profile 1, 11 or 12, depending on which access level the SIC profile matches with the access rights stored in the user profile requesting the SIC.
SIC #2 is replaced by one of the real SIC profiles 2, 21 or 22.
A user with access level 90 will receive profile 11 when requesting profile 1.
If the user has access level 95, (s)he receives real SIC profile 12.

The shareability of a SIC is also controlled by means of entries in the INI file. The entries are stored in the same section [SIC] and appear as follows:

SIC.Limit01=1,1
SIC.Limit02=2,5

The entries in this example stand for 2 sharable SICs.
Logical SIC 1 can only be used on one station at a time;
logical SIC 2 can be used on up to 5 stations at a time.

Entries (see below) can be made to define objects which are set to value 1 if the assigned SIC is withdrawn from the current station due to an emergency takeover. These variables must be available separately for any individual stations.

EmergMsg.1=SICMSG1
EmergMsg.2=SICMSG2

The entries in the above example assign the variable SICMSG1 to SIC 1 and the variable SICMSG2 to SIC 2.

Further entries assign a variable to any combination of SIC and station. These variables can be used by the SIC subsystem to check which SICs are available on which stations. The variables can also be used, for example, in order to visualize the distribution of SICs among individual stations in an overview display. These variables must be synchronized between the stations.

HasSic.101.3=STN101SIC3
HasSic.102.3=STN102SIC3
HasSic.103.3=STN103SIC3
HasSic.104.3=STN104SIC3
HasSic.105.3=STN105SIC3

In the above example, variable STN101SIC3 indicates whether or not station 101 got SIC 3.

The next category of variables indicates which user is logged in at a particular station. The user number is stored in the relevant object. Data synchronization for these variables is again required between the stations.

UserVar.101=STN101USR
UserVar.102=STN102USR
UserVar.103=STN103USR
UserVar.104=STN104USR
UserVar.105=STN105USR

Online User Administration

Users may make limited modifications to the configuration at runtime.

• Each user may change the own password. A user with superuser privileges may change the password of any user. (Usr_ChngUsrPwd())
• A user with superuser privileges may change the profile of any user. (Usr_ChngUsrPrfl())
• The Usr_PrfAddFct() function may be used to add a function number to a user profile.
• The Usr_PrfRmvFct() function may be used to remove a function number from a user profile.

Considerations when Configuring

Great care must be taken when allocating function numbers and user groups.
In particular, you need to ensure that:

• The function numbers used to protect the SICs against unauthorized access, the SIC protection numbers, are used exclusively in the user profiles and not in the SIC profiles.
  ANNOTATION:
  It is normally not intended that a user, by acquiring a SIC, gains access to a further SIC to which (s)he wasn’t entitled before.
  Only in case of interrelated SICs, such as SBetr / SSich and SIC-Throttle it makes sense; however in such a case the release of one SIC should trigger the release of the others.
• A user profile should contain the authorization for only one of the real SICs assigned to a logical SIC. If that user has access rights for several matching real SICs, (s)he will always receive an accurately specified real SIC. However, in order to prevent ambiguity with reference to which SIC is really active at a given time, only one real SIC belonging to a logical SIC should be enabled.

Actions and Functions for SIC

A release or takeover request of a remote station is accepted.
Used as an action on buttons.
Sets variable $SICREPLY to 1.
(Is executed only if $SICACTIVE is equal to $OSNO.) Can be linked to a special variable by using the enable function: Obj_CmpValues($SICSIC, <const>) on a button.

Returns a ‘1’ if the currently active SIC transaction is to handover the specified SIC to the current station.
It is used as an enable function on buttons for accepting or denying the transaction currently running.

Returns a ‘1’ if the user specified by the user-ID (UserID = Value " PointID ") is authorized to acquire the SIC specified in ‘SICNumber’.
Used as an enable function for buttons to release a SIC to an authorized station.

Returns a ‘1’ if the user who is currently logged in is authorized to have the SIC specified in the first parameter. The name of the user variable must be specified in the second parameter, i.e. “$USR”.
Used as an enable function for buttons to initiate an emergency takeover of a SIC.

In case the variable $SICREPLY gets value 2 (transaction denied), the Sic_Clear() function is called on all stations.
(It must be configured via a Dataobject-event.)
If the condition $SICACTIVE = $OSNO is true, the function clears all variables, i.e. only the station that originally initiated the transaction is able to perform the clear operation.

If this function is called, the desired SIC is added immediately to the requesting station. If another station owns this SIC and the SIC is not enabled for sharing, the SIC is removed from the other station by means of dataobject synchronization. If an SIC transaction is currently in progress elsewhere, the value of the variable designated by the second parameter is set to 2. You can configure an appropriate data object event in order to display a dialog box as a notice.

The function returns the number of the User Profile owned by the user specified in the UserNumber.

The function returns a ‘1’ if the “SIC number” is owned by the currently logged in user.
Used as an enable function on the button for releasing the SIC.

The function returns a ‘1’ if the station, defined in parameter 1, owns the SIC defined in parameter 2.
Used as an enable function on a button that request a SIC from a station.

A release or takeover request from a remote station is denied.
Used as an action on buttons.

Attempts to release the SIC <SIC-Nummer>.
If this is not possible (e.g. a sharable SIC does not exist on at least one other station), the object specified by <Objektname> is set to value 1.
The name may be chosen freely but must refer to a local data object. It is also necessary to configure a dataobject-event that opens a dialog and in reaction to the event also resets the dataobject to zero.

Attempts to acquire the SIC <SIC-Nummer>.
If this cannot be performed immediately by filling in the SIC -(e.g. the SIC is not yet available on any station or the SIC is shared and the number of potential simultaneous stations has not yet been exhausted), the object specified by <Objektname> is set to value 1.
The name may be chosen freely but must refer to a local data object. It is also necessary to configure a dataobject-event that opens a dialog and in reaction to the event also resets the dataobject to zero.

This function executes the changes required on the SIC.
The function must be configured as a response to a dataobject-event, if the value of variable $SICREPLY becomes 1. The transaction affects 2 stations only. The values of the global PVs determine the action to be taken.
The addressed station sets the data-object $SICREPLY. The partner station, it is defined in the data-object $SICACTIVE, resets $SICREPLY to zero to signify the end of the transaction.
In the case that variable $SICREPLY gets value 2, the Sic_Clear() function is called on all stations. If the condition $SICACTIVE = $OSNO is true, the function clears all variables, i.e. only the station that originally initiated the transaction is able to perform the clear operation.

Data Object Events

Dataobject-events are configured in order to respond to specific conditions in the SIC system by displaying a dialog window.

Data object;
Function: Obj_CmpValues($OSNO,$SICPASSIVE)
Action: Wnd_Dialog(SICCHG,0)

If the value of variable $OSNO is equal to the value of $SICPASSIVE the dialog SICCHG is called.
(The name for the “SICCHG” dialog is arbitrary.)
The display of this dialog is the response to releasing or accepting a SIC from another station.
In order to distinguish between a release= or accept request, the dialog must be based on a figure shift by the dynamic function “Obj_ValueInt($SICACTION)”.

Data object;
Function: Obj_ValCmp($SICREPLY,1)
Action: Sic_Transaction()

The function ‘Sic_Transaction’ performs the transaction of the SIC and clears all variables concerning the transaction on the station that initiated the transaction.
No other station is affected by that function call.

Data object;
Function: Obj_ValCmp($SICREPLY,2)
Action: Sic_Clear()

The function ‘Sic_Clear’ clears all variables concerning the transaction on the station that initiated the transaction.
No other station is affected by that function call.

Data object;
Function: Obj_ValCmp(<EmergMsgVar>,1)
Action: Wnd_Dialog(<DialogName>,);Obj_SetVal(<EmergMsgVar>,0)

The variable assigned to the SIC via the INI-File has been set to 1.
This indicates that the relevant SIC on the local station has been withdrawn by another station. On the local station a dialog window should indicate the incident. As a further reaction the variable is reset.
(Individual variables are configured for any SIC, consequently an individual dialog can be configured and assigned to each SIC.)

Data object;
Function: Obj_ValCmp(<Variablenname>,2)
Action: Wnd_Dialog(<DialogName>,);Obj_SetVal(<Variablenname>,0)

To the functions Sic_EmergRequest(), Sic_Release() and Sic_Request() a parameter containing the name of a variable is handed over. Its value is set to 2, in case the according function cannot be executed due to the variables are currently in use. That allows to create individual variables for all 3 cases. Via dataobject-event the appropriate dialogs can be opened.

Loss of a SIC

Data object;
Function: Obj_ValCmp(<Variablenname>,-1)
Action: Wnd_Dialog(<DialogName>,)

If a station obtains a non-shareable SIC and is subsequently disconnected from the bus, the SIC is withdrawn.
Variables for all combinations of station and SIC are specified in the INI file. The value of the corresponding variable is set to –1. A Dataobject-event can then be used to notify the other stations about the loss of the specific SIC.

Scenarios

• A button for the release request of a SIC is pressed.
  
  
• • If the SIC is a SBetr / Ssich or a shareable one and another station owns this SIC too, no further action is needed.
    The SIC is released.
  • A list of stations with users having access rights for this SIC appears.
    
    
• The user pushes one of the buttons to inform the remote user of the handover request.
  The remote user can accept or deny.

• If the user got the required access rights, (s)he can request the SIC.
• If the SIC is sharable and still available, the user receives the SIC.
• If the SIC is non-sharable and already active on another workstation, the other workstation is requested to release the SIC.

• If the station got no SIC, log out is successful immediately.
• If the SIC on this station is shareable and active on at least one other station, log out is successfully.
• If the SIC is owned by this station only, it must be handed over before the user can log out.

• If the station owns a SIC which the new user is not authorization for, the log out of the old user and log in of the new user is denied.
• If the new user is already logged in at another station and in possession of an SIC there, (s)he is automatically logged out at the other station and receives the SIC from there.