_auth (Berechtigung)
Die Berechtigungen für Änderungen an Datenpunktattributen werden über die Konfig "_auth" verwaltet. Die Berechtigungen können jeweils für jede Konfig eines Datenpunktelementes vergeben werden, also z.B. für die Datenpunktfunktionen eines Knotens etc.- siehe die Abbildung unterhab.
Ein Manager läuft unter einem Benutzer. Ein Benutzer hat allgemeine Berechtigungen (siehe Berechtigungsstufen und Gruppen). Die Benutzerberechtigungen definieren die erforderliche allegemeine Berechtigungsstufe wie Lese- und Schreibrechte oder die Quittierberechtigung für eine bestimmte Benutzergruppe und für die Benutzer dieser Gruppe. Siehe auch das Kapitel Berechtigungskonzept für eine Übersicht der unterschiedlichen Berechtigungstypen in WinCC_OA .
Lese - und Schreibrechte für eine spezifische Datenpunktkonfig können jedoch über die _auth-Konfig definiert werden. Das bedeutet, dass wenn der Benutzer keine Berechtigung hat, um Datenpunktwerte in einem WinCC OA-System zu schreiben, könnte der Benutzer jedoch den Wert eines spezifischen Datenpunktes über die _auth-Konfig und das Setzen der Berechtigung für die _original-Konfig (siehe Abbildung unterhalb), schreiben. Damit definiert die _auth-Konfig eine zusätzliche Berechtigungsstufe für die Datenpunktkonfigs.
_auth-Konfig - zwei Berechtigungstypen: Benutzer- und Managerberechtigung
Die _auth-Konfig enthält zwei Berechtigungstypen: Benutzer- und Managerberechtigung. Die Berechtigungstypen sind "ODER"-Verknüpft. D.h., dass wenn z.B. ein Benutzer weder Schreib- noch Leserechte hat aber ein Manager z.B. Schreibrechte besitzt, besitzt ein Benutzer trotzdem Schreibrechte. Das gleiche gilt selbstverständlich für Leserechte. Eine Liste der WinCC OA -Manager, für die eine _auth-Konfig definiert werden kann, finden Sie weiter unten.
Durch die Definition einer _auth-Konfig und Setzen der "Eigentümer Schreiben"-Berechtigung, kann z.B. definiert werden, dass ein Manager, der unter einem bestimmten Benutzer läuft, den Wert eines Datenpunkts schreiben oder ändern darf. Durch Setzen der "Eigentümer Lesen"-Berechtigung kann definiert werden, dass ein Manager, der unter einem bestimmten Benutzer läuft, den Wert eines Datenpunkts nur lesen darf. Die Berechtigungstabelle, welche die Benutzer- und Managerberechtigung beschreibt, finden Sie weiter unten.
Beispiele für wie die _auth-Konfig für Manager verwendet werden könnte, wären z.B. ein UI-Manager, der einen Wert über ein Skript setzt oder ein Treiber, der einen Wert setzt oder abfragt. Für ein Beispiel einer _auth-Konfig, siehe weiter unten.
![](auth_config.png)
DPE
Das Datenpunktelement oder Alias für das die Berechtigung vergeben wird.
Owner
Der Manageridentifikator im oberen Bereich des Panels besteht aus "Eigentümer" (Systemnummer), Managertyp und Managernummer. Der Eigentümer 0 ist das lokale System.
Der Managertyp enthält alle Managertypen, die im System vorhanden sind.
Abbildung: Manageridentifikator
Konfig-Name
Die Spalte Config Name enthält die Datenpunktkonfigs. Konfigs fassen Eigenschaften zusammen, die Datenpunktelemente in WinCC OA aufweisen können. Für mehr Information - siehe Kapitel Grundlagen Datenpunktkonfigs.
Read, Write, Owner Read, Owner Write
In einer Tabelle werden die Konfigs und die dazugehörigen Berechtigungsstufen angezeigt. Durch Anklicken einer Zeile der Tabelle erscheint neben der ausgewählten Zeile eine Auswahlmöglichkeit, um die Berechtigungsstufe zu vergeben.
![](auth_config_authLevel.png)
Die _auth-Konfig enthält zwei Berechtigungstypen: Benutzer und Manager und vier Berechtigungsarten: Lesen, Schreiben, Eigentümer Lesen und Eigentümer Schreiben. Die Berechtigungen sind "ODER"-Verknüpft. D.h., dass wenn z.B. ein Benutzer weder Schreib- noch Leserechte hat aber ein Manager z.B. Schreibrechte besitzt, besitzt ein Benutzer trotzdem Schreibrechte. Das gleiche gilt selbstverständlich für Leserechte.
Berechtigung | Beschreibung |
---|---|
Lesen | Leseberechtigung für einen Benutzer. |
Schreiben | Schreibberechtigung für einen Benutzer. |
Eigentümer Lesen | Leseberechtigung für einen Manager. |
Eigentümer Schreiben | Schreibberechtigung für einen Manager. |
Wenn ein Benutzer keine Schreibrechte hat, kann der Wert eines Datenpunktes nicht über die dpSet*-Funktionen oder über die Funktion alertSet gesetzt werden. Eine Fehlermeldung wird im Log Viewer ausgegeben. Um einen Alarm zu quittieren, wird die Quittierberechtigung der Meldeklasse (nicht die _auth-Konfig) geprüft - siehe Beschreibung weiter unten.
Die _auth-Konfig wird nicht für historische Abfragen ausgewertet.
Wenn Berechtigungen zu Managern oder Benutzern hinzugefügt werden, achten Sie auf folgendes:
Wenn ein Manager oder Benutzer keine Leserechte hat, kann ein Manager nicht gestartet werden und Werte von Datenpunkten lesen. Genauso kann ein Benutzer keine Werte eines Datenpunktes lesen.
Die folgenden Bits können für die unterschiedlichen Konfigs gesetzt werden:
Bit | Beschreibung |
---|---|
Bits 1-32 | Der Benutzer benötigt dieses Bit, um eine Konfig zu editieren oder zu lesen. Es kann eines der Bits von 1-32 gesetzt werden. |
0 | Keine Einschränkung. Die Konfig kann editiert oder gelesen werden unabhängig von Berechtigungsbits. |
- | Kein Benutzer darf die Konfig bearbeiten oder lesen. |
x |
Die Berechtigung wird vom übergeordneten Knoten geerbt oder wenn im übergeordneten Knoten keine Berechtigung definiert wurde, vom _System-Datenpunkt geerbt. x (Vererbung) ist die Default-Einstellung. |
Die _auth-Konfig definiert Lese-und Schreibrechte für eine Datenpunktkonfig. Die Benutzerberechtigung (siehe Berechtigungsstufen und Gruppen) wiederum "allgemeine" Lese- und Schreibrechte sowie die Quittierberechtigung.
Die Attribute der Konfig entnehmen Sie bitte dem Anhang.
_auth-Konfig-Beispiel: UI-Benutzerberechtigung
In diesem Beispiel wurde das Bit 6 für "Schreiben" (Write) für den UI-Manager mit der Nummer 1 gesetzt. D.h. dass ein UI-Manager mit der Nummer 2, der unter einem Benutzer, der das Bit 6 besitzt, läuft, den Originalwert des Datenpunktes ExampleDP_Arg1. ändern darf.
- Der Benutzer JohnPublic besitzt das Bit 6, das für die _auth-Konfig gesetzt wurde. Das Bit 6 wird benötigt, um den Originalwert des Datenpunktes ExampleDP_Arg1. zu setzen.
- Ein UI mit der Nummer 1, die in der _auth-Konfig des Datenpunktes ExampleDP_Arg1. angegeben wurde, wird mit dem Benutzer JohnPublic geöffnet.
- JohnPublic kann den Originalwert des Datenpunktes ExampleDP_Arg1.setzen.
![](auth_userAuth.png)
_auth-Konfig-Beispiel: Managerberechtigung
In diesem Beispiel kann nur der Treibermanager den Wert eines Datenpunktes setzen. Mit anderen Worten, es werden nur die Werte von der SPS akzeptiert da der Typ Treibermanager ("DRIVER_MAN") ist.
-
Die _auth-Konfig für den Datenpunkt ExampleDP_Arg1. wird für den Managertyp "DRIVER_MAN" mit der Nummer 1 gesetzt. Es werden die Schreib-und Leseberechtigung für den Manager auf 0 (Keine Einschränkungen) und die Schreibberechtigung für UI-Benutzer auf "Niemand" (-) gesetzt. Durch die Einstellungen der _auth-Konfig werden nur Werte von der SPS akzeptiert.
![](auth_config_driverPLC.png)
_alert
_alert bildet eine Ausnahme und ist nicht ein reales Config. _alert enthält die alert_hdl-Attribute einer Alarm-Instanz, die zur Laufzeit über die Funktionen alertSet/alertGet gesetzt oder abgefragt werden können, wie z.B. _add_values
Für alle alert_hdl-Attribute, siehe Kapitel alert_hdl-Attribute.
CTRL-Script Beispiele
Dieser Abschnitt enthält Beispiele für wie eine _auth-Konfig über die CTRL-Sprache zu einem Datenpunkt hinzugefügt werden kann.
Beispiele
Nur Benutzer mit der Berechtigungsstufe 3 dürfen ein Attribut der Konfig "Ersatzwert" (_default) verändern:
main(mapping event) { dpSet("System1:ExampleDP_Result.:_auth._default._write", 3); }
Alle Benutzer dürfen Peripherieadressen parametrieren.
main(mapping event) { dpSet("System1:ExampleDP_Result.:_auth._address._write", 0); }
Die Berechtigungen zum Verändern der Attribute der Konfig "Ersatzwert" (_default) des Elements "dp.el1.el2" werden vom Elternknoten "dp.el1" übernommen.
main(mapping event) { dpSet("dp.el1.el2:_auth._default._write", 255); }
![](auth_DP_with_elements.png)
![](defaultConfig_auth_inherit.png)
Berechtigungen für Alarme
Schreibrechte (editieren):
Um ein Alarm-Attribut zu schreiben, z.B. zur Laufzeit über alertSet()-Funktion mit_add_values, um einen Begleitwert zu setzen oder den Alarm durch setzen vom alert_hdl-Attribut _event ( ":_alert_hdl.2._event", DPATTR_ALERTEVENT_CAME) kommen und gehen zu lassen, wird die Berechtigung des _alert-Attributs vom _auth-Konfig überprüft. Damit die Berechtigung überprüft wird, setzen Sie für einen Datenpunkt die _auth-Konfig (die Rechte "Lesen" und "Schreiben") sowie eine Berechtigungsstufe für die Konfig "_alert_hdl" der_auth-Konfig (siehe Abbildung unterhalb):
![](authconfig_dp.png)
Beachten Sie zudem, dass die gesetzte _auth-Berechtigung für alle alert_hdl-Attribute, die über die Funktion alertSet() gesetzt werden können, überprüft wird. D.h. die _auth-Konfig wird nicht nur für die oberhalb erwähnten Attribute "_add_values" und "_event" überprüft, sondern für alle alertSet()-Attribute sofern die _auth-Konfig für einen Datenpunkt gesetzt wurde.
Quittierrechte:
Um einen Alarm zu quittieren, wird die Quittierberechtigung der Meldeklasse geprüft. Die Berechtigung wird gesetzt:
- in der Meldebehandlungskonfiguration (_alert_hdl-Konfig) des Datenpunktes. Für die gesetzte Meldeklasse in der Meldebehandlung könnte eine bestimmte Berechtigungsstufe erforderlich sein, um Alarme zu quittieren, siehe die Meldeklasse "040_warning" unterhalb sowie die zweite Abbildung "Quittierberechtigung in der internen Meldeklasse "warning" (Meldepriorität 40)" unterhalb:
![](alerthdl_dp.png)
sowie
- in der internen Meldeklasse _AlertClass in der die Quittierberechtigungen für die Meldeklassen selektiert werden.
![](alertclass_auth.png)
Die Meldeklasse "warning" mit Meldepriorität 40 wurde für die Meldebehandlung vom Datenpunkt "ExampleDP_arg2" selektiert indem die Meldeklasse 040_warning. selektiert wurde. Damit gilt die Quittierberechtigung der internen Meldeklasse für den Datenpunkt "ExampleDP_arg2".
3 unterschiedliche Berechtigungsszenarien stehen Ihnen zur Verfügung:
1. Es kann die _auth-Konfig gesetzt werden. Damit wird die Berechtigung überprüft, wenn Alarm-Attribute geschrieben werden.
2. Es kann die Quittierberechtigung für eine Alarmklasse gesetzt werden und dadurch für die Meldebehandlung, wenn dieselbe Alarmklasse für eine Meldebehandlung eines Datenpunktes verwendet wird.
3. Es können beide die _auth-Konfig sowie die Quittierberechtigung gesetzt werden.