Quelltext der Seite Diskussion:Access Control (RSbySCHAEFER-2009)

Bitte keine PDF-Dateien als vollständige Artikel hochladen. Der Inhalt der pdf-Dateien kann von anderen Usern nicht bearbeitet werden. Wenn man nicht so fit ist in der MediaWiki-Syntax, dann stellen Sie bitte den Text unformatiert in das Wiki, damit es von anderen formatiert werden kann, oder benutzen Sie die Exportfunktion von [http://de.openoffice.org/downloads/oooportable.html OpenOffice], um Ihre Dokumente direkt in der [[Hilfe:Tutorial MediaWiki-Text exportieren|MediaWiki-Syntax]] zu exportieren. 
--[[Benutzer:JHell|JHell]] 14:36, 14. Jan. 2008 (CET)

== Vorschlag vom 21.10.2008 ==

'''Zu Punkt 1:''' In der Subfunction sollte nur der Kartentyp stehen (0 , 1..32). Eine Aufteilung in Basic- und Subtyp halte ich für überflüssig (kein Mehrwert).

Byte 3 sollte wie bei den virtuellen Eingängen die Bezeichnung Floor haben.

'''Zu Punkt 2:''' Nur Vorschlag 2 macht Sinn. Für jeden Kartentyp wird ein eigenes Objekt definiert. Die Auswerteeinheit kann so zum Zeitpunkt der Erstellung den Speicher definieren und kennt zu jedem unterstützten Kartentyp die Bedeutung der vom Lesegerät gelieferten Daten. Man kann so später problemlos jederzeit neue Kartentypen definieren. Für jeden Kartentyp werden die gelieferten Daten genau festgelegt.

Der Objekttyp ist dabei von der Art der gelieferten Daten abhängig, z. B.:

{|border="1" cellspacing="" cellpadding="3"
|-
| Index       || xx01h           
|-
| Name        || Tag-ID EM4001 & EM4002
|-
| Object Code || Var
|-
| Data Type   || 5 Bytes octed string
|-
|}


{|border="1" cellspacing="" cellpadding="3"
|-
| Index       || xx02h           
|-
| Name        || Card data EM V4050 
|-
| Object Code || Array
|-
| Data Type   || 4 Bytes octed string (32 blocks a 4 bytes = 128 bytes)
|-
|}


Die Parametrierung des Lesegerätes erfolgt über ein Objekt:

{|border="1" cellspacing="" cellpadding="3"
|-
| Index       || xx00h           
|-
| Name        || Reader configuration
|-
| Object Code || Record
|-
|}


{|border="1" cellspacing="" cellpadding="3"
|-
| Sub-Index   || 1h
|-
| Name        || Current detected card type
|-
| Data Type   || Byte
|-
|}


{|border="1" cellspacing="" cellpadding="3"
|-
| Sub-Index   || 2h
|-
| Name        || Bit-Mask of supported card types
|-
| Data Type   || DWORD
|-
|}


{|border="1" cellspacing="" cellpadding="3"
|-
| Sub-Index   || 3h
|-
| Name        || Bit-Mask of current scanning card types
|-
| Data Type   || DWORD
|-
|}

 
{|border="1" cellspacing="" cellpadding="3"
|-
| Sub-Index   || 4h
|-
| Name        || Upload timeout in ms (Default 3 s)
|-
| Data Type   || WORD
|-
|}


'''Zu Punkt 3:''' Viel zu kompliziert und nicht notwendig. Um in einem beliebigen Knoten virt. Eingänge freizuschalten, schlage ich eine neue virtuelle Ausgangsfunktion mit dem Namen Freigabe 1 .. 255 vor.

Die Auswerteeinheit muß dann nur wissen, bei welcher Karte sie welche Freigaben zu senden hat. Z. B.

 Karte 1: Freigabe Etage 1 und 2 -> Virt. Ausgang 'Freigabe 1'
 Karte 2: Freigabe Etage 3 und 4 -> Virt. Ausgang 'Freigabe 2'

Sollte es dabei zu Überschneidungen kommen, könnte man immer noch mehrere physik. Ausgänge parallel schalten. 

Dieses Verfahren ist sehr einfach und auch für einen Techniker vor Ort leicht nachzuvollziehen und zu überprüfen.


'''Zu Punkt 4:''' Byte 3 sollte die Bezeichnung Floor haben.


-- [[Benutzer:Hba|HBa]] 22.10.2008 09:42