Dokument: Analyse und Design
Datum: 19 Sep. 97
Autor(en): Leonhard Pang & Beat Schär
Betreuer: Dr. F. Meyer
1 Einleitung
2 Anforderungen
3 Hardware
Die Zyklopen sind Gestalten des griechischen Mythos und waren gigantische einäugige Monster. Sie waren Söhne des Himmels und der Erde. Es gab deren drei: Brontes, Steropes und Arges. Sie repräsentierten Donner, Blitz und Blitzkeil. Sie waren die ersten Schmiede. Als Cronus an die Macht kam, wurden sie auf Tartarus gefangen gehalten.
Zeus befreite sie. Sie kämpften mit ihm gegen die Titanen. Als Belohnung für ihre Befreiung schmiedeten sie für Zeus Donnerkeile.
Die Diplomarbeit Cyclop ist ein intelligentes Tür-Überwachungssystem. Die runde einlinsige Überwachungskamera gleicht dem Auge des Zyklopen.
Die Idee von Cyclop ist eine Tür-Überwachung über ein Netzwerk zu bewerkstelligen. Dazu wird die Überwachungskamera, die Türsteuerung, die Gegensprechanlage und das Licht über einen PC gesteuert und verwaltet. Ein Benutzer soll von irgendeiner Workstation auf die Bilddaten zugreifen können und entscheiden, ob der Person Einlass gewährt werden soll oder nicht.
Die Steuerung der Kamera, der Türe, des Lichtes und der Gegensprechanlage, wird durch den Agent übernommen. Er wartet auf die Befehle eines Managers und führt dann diese aus. Er unterrichtet auch alle angeschlossene Manager über eventuelle Ereignisse.
Der Manager ermöglicht dem User die Bilder von der Überwachungskamera auf seiner Workstation zu holen und anzuzeigen. Auch kann er dann die Steuerung der Kamera, der Türe und des Lichtes übernehmen.
Abbildung 1: Manager und Agent im Intranet
Für die Diplomarbeit Cyclop sind folgende Anforderungen gestellt:
Cyclop ist ein computerunterstütztes System für die Kontrolle einer Tür. Dieses System ist nach dem Manager/Agent Prinzip aufgebaut: Ein Manager und ein Agent sind an ein lokales Netzwerk /Ethernet) angeschlossene Computer.
Der Manager läuft auf einem PC unter Windows NT und stellt das Benutzer-Interface zur Verfügung. Der Agent läuft auf einem Industrie PC unter dem im Systemsoftwarekurs entwickelten Betriebssystem Xinu. Er unterstützt die folgenden peripheren Geräte:
Dem Bericht soll eine Zusammenfassung mit den wichtigsten Resultaten der Arbeit vorangestellt werden.
Die Arbeit soll mit einer einfachen Web Seite auf dem Internet präsentiert
werden.
Die Hardware besteht aus dem Einplatinen-Computer "Microspace PCC P5 V2.x" der Firma Digital-Logic AG. An der seriellen Schnittstelle wird ein Microcontroller-Board angehängt, welche die Steuerung der Kamera übernimmt. Über dieses Board wird auch das Licht und die Tür kontrolliert.
Abbildung 2: Hardware
Abbildung 3: PCC P5 166Mhz
Der Einplatinen-Computer PCC5 vereint alle zum Betrieb notwendigen Komponenten auf einer Platine. Er verfügt über folgende Features:
Abbildung 5: Grabber-Chip auf dem Einplatinen Computer
Der Chip C&T 65554 ist ein high Performance Multimedia-Graphikchip mit eingebautem Blitter und Grabberfunktion. Mit Hilfe dieses Chips werden die Bilddaten abgespeichert und dann übers Netzwerk an den Manager geschickt. Der Manager zeigt dann das Bild auf dem Bildschirm des Users an. Der Chip unterstützt die Bildformate YUV 4:2:2, RGB15 und RGB16.
Der Video Pixel Decoder VPX3220A von ITT decodiert das von der Kamera empfangene PAL-Signal und stellt es digitalisiert dem Graphikchip zur Verfügung. Er beherrscht noch mehr Bildformate als der Graphikchip, nämlich YUV 4:2:2, YUV 4:4:4, YUV 4:1:1, RGB24, RGB16 und RGB15.
Da der Chip aus der Consumer-Electronic Branche stammt, kann er nur über eine I2C-Schnittstelle programmiert werden. Dies ist auch der Grund, dass wir ein solches Device noch zusätzlich schreiben mussten.
Der Soundchip AD1816 von Analog Devices befindet sich auf der Unterseite des Einplatinen-Computers. Er unterstützt die gleichzeitige Ein- und Ausgabe von 8bit- 16bit-Sounddaten, mit Sample-Rates zwischen 4 kHz und 55.2 kHz.
Ausserdem hat er einen eingebauten Yamaha OPL3 Synthesizer-Chip, einen MPU401 kompatiblen MIDI-Port, einen MPC Level-3 Mixer mit Stereo Phase Expander und einen integrierten Game-Port. Ausserdem ist der Chip kompatibel mit dem Soundblaster-Pro Standard.
Abbildung 6: Schaltbild Microcontroller Board
Das Microcontroller-Board übernimmt die Steuerung der ganzen Peripherie. Das Board wird über die serielle Schnittstelle an den Agent angeschlossen. So lassen sich mit diesem Board die Türe, die Kamera und das Licht ansteuern. Die Klingel und das Bewegungsmeldermodul melden ihre Veränderungen ebenfalls dem Microcontroller-Board. Über die serielle Schnittstelle werden diese Ereignisse weitergeleitet. Es besteht grundsätzlich die Möglichkeit, den Status der einzelnen Ports abzufragen.
Abbildung 7: Überwachungskamera
Es ist eine Farb-CCD-Kamera mit integrierter Beleuchtung und Beheizung. Die Kamera ist schwenkbar. Mit Hilfe von Stellmotoren lässt sich die Kamera um ± 20° schwenken. Die Bildübertragung geschieht im PAL-Format. Das Objektiv hat eine Brennweite von 4mm und eine Blende von 1:2. Die Verschlusszeit liegt zwischen 1/50 und 1/30000 Sekunden. Die Steuerung der Brennweite, der Blende und des Verschlusses erfolgt automatisch durch die Kamera.
Der Manager kann die Kamera wie folgt steuern:
Abbildung 8: Bewegungsmelder
Das Bewegungsmeldermodul erfasst in einem begrenzten Bereich Infrarotstrahlung. Am Modul befindet sich ein Bewegungsschalter und ein Dämmerungsschalter. Über diese Schalter lässt sich der Zustand des Bewegungsmoduls erfahren. Mit Hilfe des Microcontroller-Boards können dann diese Ereignisse dem Agent mitgeteilt werden.
Die Reichweite der Bewegungsdetektion, sowie die Dämmerungsschwelle lassen sich am Modul einstellen.
Bei einer allfälligen Bewegungsdetektion sollen alle registrierten Manager benachrichtigt werden.
Abbildung 9: Gegensprechanlage
Die Gegensprechanlage besteht aus einem Lautsprecher und einem Mikrofon. Der Lautsprecher und das Mikrofon werden an die Aus/Eingänge des Soundchips angehängt.
Abbildung 10: Klingel
Die Klingel löst ein Ereignis im Agent aus. Dieser sendet an alle
registrierten Manager eine Message, dass jemand geklingelt hat.
Das verwendete Protokoll baut auf die Vorlage der letztjährigen
Diplomarbeit. Das Protokoll beschreibt die Messages, die zwischen dem Manager
und dem Agent ausgetauscht werden.
Hier legten wir fest, was der Agent auf eine Anfrage des Managers antworten
kann, und wie er reagieren soll.
Das Protokoll ist die wichtigste Schnittstelle zwischen dem Manager
und dem Agent. Ohne das Protokoll würde nichts funktionieren.
Das Protokoll wird mit Hilfe von UDP/IP übers Netz geschickt.
Dabei ist zu bemerken, dass UDP nicht zuverlässig ist, d.h. dass Pakete
verloren gehen können.
Der Protokollheader steht am Anfang einer Message. Eine Ausnahme bilden Video und Audio Datenpakete. Die Struktur des Headers finden wir in "DcpMsg.h”. Mit uMsgNo wird angegeben, welcher Service vom Agent gefragt ist. Folgende Werte sind im Moment zulässig:
MA: Manager Agent
AM: Agent Manager
Ein Manager muss sich zuerst beim Agent registrieren. Dazu sendet er eine DCP_MA_REGISTER_REQ-Message. Bei der Registrierung werden auch die Audio- und Video-Fähigkeiten vom Manager und vom Agent ausgetauscht. Der Manager schickt seine erwünschten Formate mit. Der Agent sucht in dieser Sequenz nach dem ersten passenden Format für Audio und Video. Falls er erfolgreich war, antwortet er dem Manager mit DCP_OK. Sonst wird die Registrierung verweigert mit der Angabe, dass der Agent kein passendes Audioformat und/oder Videoformat gefunden hat.
Das Array der Fähigkeiten besteht aus einer Sequenz von U32-Werten. Das Highword gibt an, um welche Art von Fähigkeit es sich handelt, das Lowword definiert die möglichen Multimedia Extensions.
Z.B.:
| Highword | Lowword |
| DCP_ACAP_AUDIO | WAVE_FORMAT_PCM |
| DCP_ACAP_STILL_IMAGES | RGB16 |
| 0 | 0 |
Da der Agent proprietäre Formate unterstützt, wurden diese in "mmagent.h” aufgelistet.
Damit sich ein Manager vom Agent abmelden kann, schickt er ihm ein DCP_MA_UNREGISTER_REQ Message. Der Agent schickt darauf ein DCP_OK zurück.
Die Alive Message wird benötigt um dem Agent mitzuteilen, dass ein Manager noch anwesend ist. Dies ist vorallem dann wichtig, wenn ein Manager die Kontrolle über den Agent genommen hat. Im Falle eines Absturzes des Managers wäre der Agent sonst blockiert und würde jegliche weitere Befehle anderer Manager verweigern.
Aus diesem Grunde muss der aktive Manager sich innerhalb von 90 Sekunden auf irgendeine Weise bemerkbar machen, sei es durch einen Befehl oder eine Alive-Message. Ansonsten wird dieser Manager deaktiviert und ein anderer Manager kann die Kontrolle übernehmen.
Der Manager schickt im Protokollheader die Message DCP_MA_ALIVE_REQ.
Der Agent antwortet bei Erfolg mit DCP_OK. Wenn der Manager aber aus der Registrierung entfernt wurde, erhält er als Antwort DCP_REJECT. Er muss sich dann beim Agent neu registrieren.
Die Message DCP_MA_LIGHT_REQ lässt das Licht ein- und ausschalten. Dazu werden in der "DcpMaLightReq”-Struktur die Kommandos DCP_DOOR_LIGHT_ON oder DCP_DOOR_LIGHT_OFF geschickt.
Der Agent führt das Kommando aus. Falls es keine Komplikationen gibt, steht in der Antwort "DcpAmLightReply” ein DCP_OK. Falls ein aktiver Manager vorhanden ist und der anfragende Manager nicht der aktive Manager ist, erhält er den Bescheid DCP_REFUSE_MAIN_CTRL. Ist der Manager nicht registriert meldet der Agent DCP_REJECT.
Mit DCP_MA_DOOR_REQ wird die Kontrolle über die Tür aufgenommen. Folgende Parameter können mit der Struktur "DcpMaDoorReq” mitgegeben werden: DCP_OPEN_DOOR, DCP_CLOSE_DOOR, DCP_SEND_DOOR_STATE.
Die Antwort des Agenten ist wie bei Light (Kapitel 4.1.2.5).
Mit der Message DCP_AM_AGENT_IND wird der Manager über ein allfälliges Ereignis benachrichtigt. Folgende Ereignisse können eine solche Meldung auslösen:
Die Message DCP_MA_CAMERA_REQ ermöglicht die Steuerung der Kamera. Im Lowbyte steht das Kommando (z.B. MOVE_CAMERA). Im Highbyte steht ein allfälliger Parameter oder ein Argument (z.B. START_PANNING_RIGHT, STOP_PAN_AND_TILT).
Die Kamerabefehle sind von der Fähigkeit der Kamera abhängig. So lässt sich bei einigen Kameras zoomen, bei anderen nicht.
Zusätzlich zu den Antworten von Light (Kapitel 4.1.2.5) kann der Status noch den Wert DCP_CAMERA_CMD_ERR annehmen. Diese Antwort erfolgt, wenn die Kamera den gesendeten Befehl nicht verstanden hat.
Hier kann ein Manager die Kontrolle des Agents übernehmen. Er wird zum aktiven Manager, wenn kein anderer Manager ihm zuvorgekommen ist.
Mit der Message DCP_MA_MAIN_CTRL_REQ und dem Kommando DCP_GET_MAIN_CTRL kann er aktiver Manager werden. Zusätzlich schickt er den UDP-Port, wohin später die Audio/Video Daten gesendet werden sollen. Auch die maximale Datengrammgrösse wird noch angegeben.
Auch hier gleichen die möglichen Antworten denen von Light (Kapitel 4.1.2.5).
Sobald der Manager die Kontrolle übernommen hat, kann er auch Video und Audiodaten anfordern. Dazu sendet er Kommandos wie DCP_SEND_VIDEO_STILL, DCP_SEND_AUDIO, DCP_RECV_AUDIO, DCP_STOP_AUDIO...
Zu beachten ist, dass die Logik immer vom Agent ausgeht. So bedeutet DCP_SEND_VIDEO_STILL, dass der Agent dem Manager ein Still-Image schickt. Dagegen bedeutet DCP_RECV_AUDIO, dass der Agent vom Manager Audio-Daten erhält.
In diesen Paketen werden Audio- oder Video-Daten gesendet. Entweder sind Audiodaten im Paket, dann ist die Videosize gleich 0, oder es sind Videodaten, dann ist die Audiosize gleich 0. Beide Datentypen können nicht vermischt werden.
Die Pakete werden mit einer aufsteigenden Sequenznummer versehen. In der 0-ten Sequenznummer befindet sich immer nur der Header (z.B. BITMAPHEADER, WAVEFORMATEX).
Bei der Video-Übertragung befindet sich im Highword die Nummer
des Images und im Lowword die laufende Nummer des Teilbildes.
Die zu schreibende Software besteht aus Xinu-Devices und -Processes.
Abbildung 11: Legende Flussdiagramm
Abbildung 12: Datenflussdiagramm des Dooragents
Das Serial Device stellt eine Schnittstelle zwischen Xinu und der Hardware der seriellen Schnittstelle bereit. Im Door-Agent wird die serielle Schnittstelle zur Ansteuerung der Peripherie verwendet. Folgende Methoden sollen definiert werden:
DevOpen, DevClose: Öffnet bzw. schliesst die serielle Schnittstelle
DevWrite, DevPutc: Schreibt Daten über die serielle Schnittstelle hinaus
DevRead, DevGetc: Liest Daten von der seriellen Schnittstelle ein
DevCntl: Stellt verschiedene Optionen ein (Geschwindigkeit, Blocking-Mode, etc…)
ISR: Interrupt Service Routine. Schreibt die auszugebenden Daten in die Register, bzw. liest von dort die Daten ein.
Das I2C Device dient zur Programmierung des Video Pixel Decoders VPS3220A. Es bedient sich 2 General-Purpose Anschlüssen am Graphikchip. Folgende Methoden sollen definiert werden:
DevOpen, DevClose: Öffnet bzw. schliesst das I2C Device
DevWrite, DevPutc: Führt eine Schreib-Transaktion auf dem I2C-Bus durch
DevRead, DevGetc: Führt eine Lese-Transaktion auf dem I2C-Bus durch.
DevCntl: Stellt verschiedene Optionen ein (Slave address, Sub address)
Das Grabber Device stellt eine Schnittstelle zwischen Xinu und dem Graphikchip C&T 65554 bereit. Der Grabber wird verwendet, um die Bilder der Videokamera zu digitalisieren und an den entsprechenden Xinu-Prozess weiterzuleiten. Folgende Methoden sollen definiert werden:
DevOpen, DevClose: Öffnet bzw. schliesst das Grabber Device
DevRead: Liest ein Bild von der Framegrabber-Karte ein
DevCntl: Stellt verschiedene Optionen ein (Auflösung, Start grabbing, etc…)
Das Sound-Device wird dann verwendet, wenn die Phase 4 realisiert wird (siehe Kapitel 7.5). Es stellt eine Schnittstelle zwischen Xinu und der Hardware des Soundchips (AD1816) bereit. Der Soundchip wird dazu verwendet, Sound auf einen Lautsprecher auszugeben. Es soll aber auch über ein Mikrofon Sound aufgenommen und digitalisiert werden können. Das Sound-Device soll folgende Methoden aufweisen:
DevOpen, DevClose: Öffnet bzw. schliesst das Sound Device
DevWrite: Gibt Sounddaten auf den Lautsprecher aus
DevRead: Liest Sounddaten vom Mikrophon ein
DevCntl: Stellt verschiedene Optionen ein (Sampling Rate, Starten/Stoppen, etc…)
Abbildung 13: Video Prozess Datenflussdiagramm
Der Video-Prozess hat die Aufgabe, bei Bedarf vom Framegrabber-Device ein Bild anzufordern und dieses als Bitmap via UDP-Device an den Manager zu schicken. Bei Videosequenzen wird nach jedem vollen Bild auf dem Xinu-Port geschaut, ob sich eine Message dort befindet. Dadurch ist es gewährleistet, dass der Videoprozess nicht blockiert wird.
Abbildung 14: AudioOut Prozess Datenflussdiagramm
Der AudioOut-Prozess schickt die digitalisierten Audiodaten dem Manager. Eine Besonderheit bildet der Halfduplex Modus. Der Agent wäre für den Vollduplex Modus bereit. Wenn der Manager diese Fähigkeit nicht besitzt, stoppt der AudioOut-Prozess den AudioIn-Prozess, sobald er Daten senden soll.
Abbildung 15: AudioIn Prozess Datenflussdiagramm
Der AudioIn-Prozess empfängt Audiodaten vom Manager. Im Halfduplex Modus schaltet der AudioIn-Prozess den AudioOut-Prozess ab, sobald er Daten empfangen soll.
Das Manager-Objekt verwaltet alle registrierten Manager und deren Fähigkeiten. Die einzelnen Prozesse können auf diese Daten zurückgreifen und richtig reagieren.
Durch das Manager-Objekt können die anderen Prozesse herausfinden, ob ein aktiver Manager sich im System befindet oder nicht.
Der Control-Prozess ist der Kommando-Dispatcher. Er blockiert auf dem UDP-Port bis dort eine Message eintrifft. Anhand der Message-Nummer werden die Anforderungen identifiziert und nach Möglichkeit ausgeführt. Er verteilt die Messages weiter an die entsprechenden Prozesse und steht dann für weitere Befehle zur Verfügung.
Wenn ein aktiver Manager vorhanden ist, kann ein anderer Manager weder die Peripherie steuern, noch Audio und Video Daten senden lassen. Der Control-Prozess lässt nur noch Alive-, Register- und Unregister-Messages zu. Nur der aktive Manager hat die volle Aufmerksamkeit des Agent.
Abbildung 16: Periphery-Prozess Datenflussdiagramm
Der Periphery-Prozess steuert die ganze Peripherie an der seriellen Schnittstelle. Hier befindet sich auch die ganze Logik der Steuerung. Deshalb sind in diesem Prozess gleich fünf State-Event Machines implementiert.
Abbildung 17: State-Event Legende
Abbildung 18: State-Event für (oben nach unten) Dämmerung,
Licht, Kameralicht, Tür
Abbildung 19: State-Event Kamerabewegung
Abbildung 20: Event-Prozess Datenflussdiagramm
Der Event-Prozess reagiert auf Inputs vom Com Device. Wenn der Bewegungsmelder,
Klingel 1 oder Klingel 2 ausgelöst wird, verschickt der Event-Prozess
den Managern eine Mitteilung.
Das Com-Device wird mit einem Echo-Programm getestet. Es verfügt über 2 Fenster: Im ersten Fenster werden alle eingetippten Zeichen auf die Schnittstelle ausgegeben. Im zweiten werden von der seriellen Schnittstelle eingelesene Zeichen ausgegeben.
Das I2C Device wird mit einem kleinen Tool getestet, welches das beliebige Lesen und Schreiben von Register auf dem Chip VPX3220A ermöglicht.
Das Grabber-Device wird getestet, indem vom Grabber Bilder eingelesen und auf dem Monitor als Hex-Dump angezeigt werden.
Der Video-Prozess wird getestet, indem Bilder vom Grabber-Chip eingelesen werden. Danach werden die Bilder per UDP-Device an den Manager gesendet. Mit einem Network-Sniffer-Programm kann kontrolliert werden, was effektiv über die Leitung geht.
Der AudioOut-Prozess wird getestet, indem Wavedaten vom Sound-Chip eingelesen werden. Danach werden die Sounddaten per UDP-Device an den Manager gesendet. Der Sound wird auf dem Manager ausgegeben. Falls der Sound Device nicht fertig wird kann nur beschränkt getestet werden. Es kann eine kleine Sequenz einer Sounddatei übers Netz geschickt werden.
Der AudioIn-Prozess wird getestet, indem Wavedaten vom Manager empfangen werden. Danach werden die Sounddaten über den Sound-Chip ausgegeben.
Mit simulierten Einträgen und Zugriffe kann das Manager-Objekt getestet werden. Die Rückgabewerte sind auszugeben, um festzustellen, ob sich das Manager-Objekt korrekt verhält.
Da mit dem Control-Prozess bereits das ganze System lauffähig ist, kann der Control-Prozess mit dem Manager getestet werden. Dabei muss darauf geachtet werden, dass sämtliche im Control-Prozess implementierte Kommandi vom Manager auch tatsächlich verwendet werden. Um den korrekten Ablauf übers Netzwerk zu gewährleisten, kann ein Network-Sniffer installiert werden, der den Kommunikationsablauf verfolgt
Der Periphery-Prozess kann mit dem Control-Prozess getestet werden. Sobald eine Message vom Control-Prozess angekommen ist, soll eine Reaktion an der angeschlossenen Peripherie ersichtlich sein.
Der Event-Prozess kann ähnlich wie der Control-Prozess getestet werden. Sobald jemand auf die Klingel drückt oder der Sensor eine Bewegung wahrnimmt, muss der Event-Prozess eine entsprechende Notification an den Manager verschicken. Dieser Vorgang kann mit einem Network-Sniffer überprüft werden.
Table 1: Zeitplan
Beat Schär:
Implementierung und Testen des Com-Devices.
Implementierung des Event-Prozesses.
Implementierung des Periphery-Prozesses.
Implementierung und Testen des Manager-Objekts.
Implementierung des Control-Prozesses.
Integration und Testen des Com-Devices, Event-Prozesses, Periphery-Prozesses, Manager-Objekts und Control-Prozesses.
Implementierung und Testen des Video-Prozesses.
Implementierung und Testen des I2C-Devices
Implementierung und Testen des Grabber-Devices.
Integration des Grabber-Devices und des Video-Prozesses in die Control-Testumgebung.
Implementierung und Testen des AudioIn- und des AudioOut-Prozesses.
Implementierung und Testen des Sound-Devices.
Integration des Sound-Devices und des AudioIn- und des AudioOut-Prozesses in die Control-Testumgebung.
Erstellen der Diplomarbeitsdokumentation und zeitliche Reserve.
Die Audio-Übertragung wird nur in Angriff genommen, wenn die Phasen 1 und 2 termingerecht abgeschlossen werden konnten. Sie besteht aus folgenden Tätigkeiten:
Das Komprimieren des Videostromes wird nur dann realisiert, wenn alle anderen Phasen vor dem vorgesehenen Termin abgeschlossen werden können.