Access Control (RSbySCHAEFER-2009)
Integration der Zutrittskontrolle in die CiA-417
Auch als PDF: Access Control
Ein Vorgang der Zutrittskontrolle besteht aus 3 bzw. 4 Schritten:
- Lesegerät sendet Upload Request (PDO)
- Auswerteeinheit liest eigentliche Zugangsdaten vom Lesegerät aus (SDO)
- Optional: Auswerteeinheit schaltet im Lesegerät entsprechende Inputs frei (SDO)
- Auswerteeinheit sendet Upload Acknowledgement (PDO)
1. Upload Request Telegramm
Lesegerät erkennt Karte und sendet:
Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 |
Basic function | Sub function | Lift | Panel | Door | Data |
0x0F | Type of Reader | Value of Lift | Value of Panel | Value of Door | Value of Data |
In der Subfunktion steht entweder der Wert des Lesertyps oder der entsprechenden Wert des niederwertigerem Byte des Objektes „Card Tag ID“ aus dem die Auswerteeinheit die Zugangsdaten auslesen kann.
Wertedefinition von Data (Byte 5)
Value (Bit 0) of Data | Description |
0 | Karte nicht mehr im Lesebereich oder Upload Timeout |
1 | Lesegerät hat gültige Daten von der Karte gelesen |
Zu diesem Zeitpunkt liegen im Objekt "Card Tag ID" die Daten in vordefinierbaren Kodierungen bereit.
Type: | |
Bit7 Bit5
|
Bit4 Bit0
|
Definition des Basic Type:
Value | Description |
000b | reserved |
001b | RFID |
010b | Tastatur |
011b | Fingerabdruck |
100b | Stimmerkennung |
101b | Magnet-Karte |
... | reserved |
Wenn Basic Type = 001b (RFID)
Sub Type:
Value | Description |
0x00 | Keine/ unbekannte Karte |
0x01 | EM4001/4002/4101 |
0x02 | EM V4050 |
... | Fingerabdruck |
2. Objekte für die Zugangsdaten
Vorschlag 1 Ein Objekt "Card Tag ID" für alle Lesertypen
Für die Daten (Zugangscode) wird für alle Lesertypen nur ein Objekt bereitgestellt.
D.h. Die aktuell gültigen Zugangsdaten können immer aus dem gleichen Objekt ausgelesen werden,
unabhängig vom Lesertyp. Die Objekteinträge sind babei mit variabler Größe definiert.
Zusätzlich kann den Daten noch ein weiterer Parameter vorangestellt werden, der z.Bsp. den
Lestertyp identifiziert.
Eine Verifizierung aus dem "Access Control Upload Request" und dem Objekt "Card Tag ID" Daten (Zugangscode) kann hierbei noch vorgenommen werden.
Wenn die Daten (Zugangscode) im Subindes 01h hinterlegt werden, ist es möglich in den weiteren
Subindizes noch weitere Information zu hinterlegen.
Index | 3000h |
Name | Objekt Card Tag ID |
Objekt Code | Array |
Data Type of entry | Domain |
Category | Optional |
Wenn Type = 0x21 (Basic: 001 + Sub: 00001 = 00100001b = 0x21)
Die Länge der Daten wird beim Dowload Request vom Server festgelegt. Beim Leser Type 21h sind dies bei einer Kodierung in Hexdump eine Objektlänge von 6 Byte (1 Byte Leser Typ und 5 Byte Nutzdatenlänge).
Vorschlag 2 Ein Objekt für jeden Lesertyp
Für die Daten (Zugangscode) wird für jeden Lesertyp ein Objekt bereitgestellt.
D.h. Es ist erforderlich, bei 255 definierbaren Lesertypen auch 255 Objekte für
Daten (Zugangscode) zu definieren. Die Objekte enthalten dann im niederwertigen Bytes
des Index die Nummer des Lesertyps.
Hierbei wären die Objekte z.Bsp.
Index | 3000h |
Name | Objekt reserviert |
Objekt Code | Array |
Data Type of entry | Domain |
Category | Optional |
Index | 3021h |
Name | Objekt Card Tag RFID |
Objekt Code | Array |
Data Type | Undsigned 40 |
Category | Optional |
Index | 3041h |
Name | Objekt Card Tag Tastatur |
Objekt Code | Array |
Data Type of entry | n.d. |
Category | Optional |
Index | 30FFh |
Name | Objekt reserviert |
Objekt Code | Array |
Data Type of entry | n.d. |
Category | Optional |
erforderlich.
Die Auswerteeinheit kann mit dem Wert aus dem Subfunction des "Access Control Upload Request" das betreffende Objekt ermitteln und die Daten (Zugangscode) per SDO Zugriff auslesen.
2.1 Weitere Objekte
Der Lesezugriff ist der Auswerteeinheit nur während eines parametrierbaren Zeitfensters gewährt und beginnt bei Eintreffen des Telegramms (PDO) Upload Request mit Data 0.
Erfolgt das Telegramm Upload Acknowledge, so wird die Zugriffszeit auf das Objekt beendet.
2.1.1 (ACC Protocol Control) Dieses Objekt steuert die Protokolllaufzeiten.
1. Eintrag für Request Timeout
- Dieser Eintrag definiert die Zeit zwischen den PDOs Upload Request mit Data 1 und Upload Request mit Data 0. Die Werte sind in ms Schritten festgelegt. Definition in ms.
2. Eintrag für Confirm Timeout
- Dieser Eintrag definiert die maximale Wartezeit auf ein Upload Acnowledge PDO. Trifft dieses während dieser Zeit nicht ein, so wird der Lesezugriff auf die Daten (Zugangscode) und der Schreibzugriff auf das Freigabe Objekt gesperrt. Alle vorhanden Daten der Leseeinheit werden gelöscht. Definition in ms.
3. Eintrag für Protocol Cycle Timeout
- Dieser Eintrag definiert die maximale Zeit für den Einlesevorgang einer Leseeinheit. Ist der Einlesevorgang nach dieser Zeit nicht fertiggestellt, so wird der Einlesevorgang unterbrochen und die vorhandenen Daten der Leseeinheit gelöscht. Definition in ms.
4. Eintrag für Data Send Max Time
- Dieser Eintrag definiert intern die maximale Zeit für die Übertragung des Upload Requests. Diese verhindert die Freischaltung der Zugangsdaten beim Auftreten eines internen Fehlers. Definition in ms.
2.1.2 (ACC Function Control) Dieses Objekt steuert die Zeitfenster der Ein-/Ausgänge
1. Eintrag für Release IN Time
- Dieser Eintrag definiert die maximale Dauer der Freischaltung virtueller Eingänge. Dieses Zeitfenster startet unmittelbar nach eintreffen eines Upload Acknowledge mit Data 80h und endet nach der parametrierten Zeit. Definition in ms.
2. Eintrag für Release OUT Time
- Ortogonal zu Release IN Time ist ein Objekt erforderlich in dem vereinbart wir, wie sich die Quittierung des freigeschalteten Inputs verhalten soll.
- Dauer der Quittierung
- Verhalten der Quittierung
- Dauer der Quittierung
3. Inputs frei schalten
Es sollte eine differenzierte Zugangskontrolle möglich sein. Nicht alle User dürfen, z.B. in der Kabine, in alle Etagen fahren. Hierzu zwei Möglichkeiten:
3.1 Freischaltung der Virtuellen Eingänge:
Im Objekt Input Parameter 1 (6120h – 613F) ist bereits ein Bit (Enable) definiert. Hier kann die Auswerteeinheit eintragen, ob der virtuelle Input freigeschaltet wird oder nicht.
Nachteil: Die Auswerteeinheit muss alle enable Bits einzeln setzen bzw. löschen.
Byte 3 | Byte 2 | Byte 1 | Byte 0 |
reserved(FFFFh) | Error code | Enable |
Wertebedefinition
Bit7 Bit1
|
Bit0 |
reserved | enable |
3.2 Neues Objekt: Input release
Ein Subindex (32 Bit) beschreibt die release Bits von 32 virtuellen Inputs. Vorteil: 32 Inputs können mit einem SDO freigeschaltet werden.
Objekt Beschreibung
Index | xxxx |
Name | Input release |
Object Code | Array |
Data Type | Unsigned 32 |
Category | Optional |
Eintrag Beschreibung
Sub-Index | 00 |
Beschreibung | Anzahl der Sub indezes |
Wertebereich | 1 - 8 |
Voreinstellwert | Nein |
Sub-Index | 1 |
Beschreibung | Release Bits der virtuellen Inputs 1 - 32 |
bis
Sub-Index | 8 |
Beschreibung | Release Bits der virtuellen Inputs 225 - 256 |
4. Upload Acknowledgement
4.1 Auswerteeinheit sendet positive Bestätigung
Hiermit werden die enable Bits freigegeben und damit die entsprechenden Inputs freigeschaltet. Nach Ablauf einer definierten Zeit (s. Objekt: ReleaseTime) werden die enable Bits wieder gesperrt.
4.2 Auswerteeinheit sendet negative Bestätigung
Mit dem Data Byte hat die Auswerteeinheit zusätzlich die Möglichkeit die Lesgeräte ein- oder auszuschalten.
4.3 Weitere benötigte Objekte
Index | xxxx |
Name | Release Time |
Object Code | Var |
Data Type | Unsigned 8 |
Category | Optional |