SCADA - EASy (Teil 2) -...

37
FB 2 – ET / IT http://automatisierung.fh-pforzheim.de Seite 1 von 37 Fachhochschule Pforzheim Studiengang Elektrotechnik / Informationstechnik Interdisziplinäre Projektarbeit SCADA - EASy (Teil 2) von Mathias Bischoff Mat. – Nr.: 280372 August 2002

Transcript of SCADA - EASy (Teil 2) -...

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 1 von 37

Fachhochschule PforzheimStudiengang

Elektrotechnik / Informationstechnik

Interdisziplinäre Projektarbeit

SCADA - EASy (Teil 2)

von

Mathias BischoffMat. – Nr.: 280372

August 2002

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 2 von 37

Inhalt

1 Einleitung......................................................................................................................... 42 Die Prozessstation............................................................................................................ 6

2.1 Der Mikrocontroller als Prozessstation..................................................................... 72.1.1 Allgemeines zum Mikrocontroller Board .......................................................... 82.1.2 Die Softwarestruktur des Mikrocontrollers ....................................................... 92.1.3 Das Kommunikationsprotokoll ........................................................................ 112.1.4 Die realisierten C-Funktionen des PIC’s ......................................................... 13

2.2 Das Blackboxnet Programm ................................................................................... 163 Die Prozessvisualisierung .............................................................................................. 17

3.1 Was ist ein Java Applet?......................................................................................... 173.2 Realisierung der Prozessvisualisierung................................................................... 19

3.2.1 Der zeitliche Ablauf während der Prozessvisualisierung ................................ 203.2.2 Das UML Gerüst der Prozessvisualisierung .................................................... 213.2.3 Das Simpleview Paket ..................................................................................... 213.2.3 Das Lightview Paket ........................................................................................ 24

3.3 Gründe für die Entscheidung zu dieser Struktur..................................................... 254 Epilog............................................................................................................................. 25

4.1 Zusammenfassung................................................................................................... 254.2 Zukünftige Ansatzpunkte........................................................................................ 25

5 Anhang Applet Klassendiagramme OOD...................................................................... 276 Anhang Mikrocontroller als Prozessstation (Schaltpläne)............................................. 327 Abbildungen...................................................................................................................368 Literatur.......................................................................................................................... 37

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 3 von 37

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte sind dem Autorvorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohneschriftliche Zustimmung des Autors urheberrechtswidrig und daher strafbar. Dies giltinsbesondere für die Vervielfältigung, Übersetzung oder Verwendung in elektronischenSystemen. Alle Angaben und Programme in dieser Publikation wurden mit größterSorgfalt kontrolliert. Der Autor kann nicht für Schäden haftbar gemacht werden, die inZusammenhang mit der Verwendung dieser Information entstehen.

Die Projektarbeit wurde betreut von:Prof. Dr. Frank ThuseltProf. Dr. Alfred SchätterDipl. phys. Michael Bauer

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 4 von 37

1 Einleitung

In vielen Unternehmen gibt es eine inhomogene Systemlandschaft mit mehr oder wenigerautarken Automationszellen. In diesen fallen eine Menge von Daten und Informationenan, welche, an zentraler Stelle erfasst, zur Optimierung der einzelnen Prozessabläufebeitragen können. Die Erfassung und Visualisierung ist Aufgabe des hier beschriebenenEthernetbasierten Automatisierungssystems.

Im Rahmen der Projektarbeit wurde ein Linux - Webserver bzw. Portalserver als zentraleDatensammelstelle mit Betriebssystem und Datenbanksoftware eingerichtet bzw.konfiguriert. Dieser Computer wird über das Ethernet1 angesprochen. Dabei werden dieDaten über ein CGI – Script auf dem Portalserver manipuliert und abgespeichert. CGI istdie Abkürzung fürCommon Gateway Interface. Hierbei handelt es sich um eineSpezifikation, welche definiert wie Daten von Clients auf dem Server verarbeitet werden.

Außerdem wurde ein PIC (Programmable Integrated Circuit) mit RS 232 Schnittstelle alsProzessstation in das Kommunikationssystem (Bild 1) integriert.Diese Prozessstation kommuniziert über die serielle Schnittstelle mit einem Client PC(hier Client 2, siehe Bild 1). Damit diese Kommunikation ausgeführt werden kann, wurdeeine Software auf dem PIC implementiert. Dabei läuft gleichzeitig auf dem PC (Client 1)das RS232 zu TCP/IP Konverter Programm BlackboxNET.Um eine Verbindung zwischen dem Server und dem PIC aufzubauen, ist eineKonvertierung der Daten des PIC's in Daten, die das CGI Script versteht, durch dasProgramm BlackboxNET nötig.

Das Ziel dieser Projektarbeit bestand darin, dass eine Messdatenerfassung undVisualisierung eines Embedded Systems durchgeführt wird. Zusätzlich kann diesesSystem über das Internet gesteuert und abgerufen werden.

Zur Wartung und Visualisierung der Daten wurde zusätzlich eine Internetanwendungprogrammiert. Der Zustand jeder Prozessdateneinheit lässt sich über ein Browserfenstervon jedem Punkt der Welt abrufen.Jede Prozessstation kann aus einer oder mehren Prozessdateneinheiten bestehen.Bei einer Prozessdateneinheit handelt es sich um einen Ein- oder Ausgang einerProzessstation. Bei jeder Prozessdateneinheit liegen bestimmte Zustände bzw. Werte vor,welche sich im Laufe der Zeit ändern können. Der Server verarbeitet und speichert jedeÄnderung.

1) EthernetZur Vernetzung z.B. zweier Computer wird eine elektrische Verbindung zwischen ihnen benötigt. Ganz schlicht gesprochen muss einKabel verlegt werden, und dieses muss an den Computern irgendwo angeschlossen werden können, die Computer müssen also übereine bestimmte Hardware verfügen. Im einfachsten Fall und heute im LAN sehr gebrächlich sind Ethernet-Steckkarten alsNetzwerkkarten. Die billigste Kabelverbindung dazwischen ist ein Stück Koaxialkabel, an beiden Enden muss noch einAbschlusswiderstand aufgesteckt werden.Die Ethernethardware ist in der Lage, in einem Standard festgelegte elektrische Signale zwischen diesen beiden Ethernetkartenauszutauschen, die zugehörige Treibersoftware sorgt für korrekten Betrieb. Mehr als einzelne Bits ohne tiefere Bedeutung können dieComputer jetzt aber noch nicht austauschen.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 5 von 37

Das folgende Beispiel soll das verdeutlichen.In unserem Fall besitzt eine Prozessstation (hier der PIC) einen analogenTemperatursensor und zwei digitale Prozessdateneinheiten. Der Wert der Temperaturverändert sich von 23 Grad auf 24 Grad. Die Prozessstation sendet dem BlackboxNETProgramm über ein definiertes Protokoll diesen Wert der Prozessdateneinheit A00 undden dazugehörigen Header (Source IP – Adresse, etc.). Das Programm reicht diese vonder seriellen Schnittstelle empfangenen Werte weiter an den Server. Auf dem Server wirdein CGI Script ausgeführt, welches den veränderten Messwert der Prozessstationabspeichert.

Client 1 ist neugierig und möchte unbedingt wissen, welche Temperatur in derUmgebung der PIC’s herrscht. Diesen Wert kann er über den Browser und diedazugehörige URL abfragen.

Bild 1 Das Kommunikationssystem

Das System wird aus diesem Grund in die Bestandteile Prozessvisualisierung,Prozessstation und Portalserver untergliedert. Die nachfolgenden Kapitel beschreiben unddokumentieren die Entwicklung der Prozessvisualisierung (Java Applet) und derProzessstation.

Hinweis:Die Konfiguration und der Aufbau des Servers werden im Dokumentationsteilvon Alexander Thiel (SCADA - EASy Teil 1) detaillierter beschrieben.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 6 von 37

2 Die Prozessstation

Eine Prozessstation ist eine Systemkomponente unseres Gesamtsystems.Jede Prozessstation besitzt mindestens eine oder mehrere Prozessdateneinheiten.Eine Prozessdateneinheit kann z.B. eine analoger oder digitaler Ein- bzw. Ausgang sein.Bei jeder Prozessdateneinheit liegen bestimmte Zustände bzw. Werte vor, welche sich imLaufe der Zeit verändern können.

Jedes Gerät mit Ethernetschnittstelle kann eine Prozessstation unseres Systems sein.Das bedeutet, dass ein PC sowie ein Mikrocontroller oder andere elektronische Geräteeine Systemkomponente sein kann.Jedoch müssen folgende Vorrausetzungen erfüllt werden, damit ein Gerät denSpezifikationen einer Prozessstation unseres Systems entspricht:

1. Die Prozessstation muss eine eigene IP – Adresse besitzen.2. Die Prozessstation muss über Ein- und Ausgabeports bzw. Prozessdateneinheiten

verfügen.

Insgesamt sind 0..99 analoge und 0..99 digitale Prozessdateneinheiten pro Prozessstationin Verknüpfung mit der Datenhaltung unsers Servers realisierbar. Das bedeutet, dass die101. Prozessdateneinheit nicht mehr unter der Prozessstation auf dem Serverabgespeichert werden kann.Die Zahl der Prozessdateneinheiten pro Prozessstation kann jedoch in Abhängigkeit vonder Hardwarerealisierung im Rahmen dieser Beschränkung variieren.

Jede Prozessstation kennt zwei Befehle:

1) Den Befehl cmd (für command) = read, welcher die gesamte Konfiguration vomServer einliest.2) Den Befehl cmd = write, welcher die gesamte Konfiguration der Prozessstation aufden Server schreibt. Bsp.: cmd=write&D01=128&D02=33

Die Bedeutung der Befehle wird in den folgenden Abschnitten genauer erläutert.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 7 von 37

2.1 Der Mikrocontroller als Prozessstation

Um unser Portal testen zu können, haben wir ein Evaluationsboard mit PIC Controller alsProzessstation bestehend aus 2 digitalen Ports (siehe Bild 2 LED Kette) und einemanalogen Port mit Temperatursensor aufgebaut (Schaltpläne dazu im Anhang).

Bild 2 Das Mikrocontroller Board

Dabei sind das Board und der damit seriell verknüpfte PC inklusive BlackboxNETProgramm zusammen als Prozessstation zu betrachten (Bild 1).Beide Geräte kombiniert entsprechen zusammen den in Kapitel 2 definierten Standardeiner Prozessstation.Das Board (Bild 2) inklusive PIC besitzt in dieser Form eine digitaleAusgabeprozessdateneinheit (8 Bit LED Kette) und eine digitaleEingabeprozessdateneinheit (8 Bit Dippschalter + LED Kette) und einenTemperatursensor (analoge Prozessdateneinheit).Die komplette PIC Software wurde in C realisiert. Dazu wurde der C-Compiler derFirmaCCSwurde verwendet. Das Handbuch des C - Compiler kann von der Laborseite desFachbereiches 2 herunter geladen werden.(http://www.fh-pforzheim.de/fb2/eit/labore/automatisierungstechnik)

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 8 von 37

2.1.1 Allgemeines zum Mikrocontroller Board

Um eine Kommunikation der Prozessstation mit dem Server herzustellen musste zuersteine neue Software für den PIC entwickelt werden. Diese Software spricht die einzelnenProzessdateneinheiten (Peripherien) des Mikrocontroller – Boards an.

Das Programm besteht im Wesentlichen aus zwei Funktionen, welche weitereUnterfunktionen aufrufen und damit den Code übersichtlich halten (Bild 3).

Der Entschluss für diese Struktur wurde durch folgende Faktoren beeinflusst:

Die Übersichtlichkeit der Softwarestruktur sollte für spätere Weiterentwicklungen andiesem Projekt im Vordergrund stehen. Andere Personen sollen zügig den Sinn derbereits implementierten Software verstehen, damit auf diesem Know – How schnelleraufgebaut werden kann.

Die meisten TCP/IP2 Implementierungen sind für Desktop PCs entwickelt und erforderneinen hohen Programmier- und Speicherplatzbedarf. Der verfügbare Speicher aufEmbedded Systemen wie unserem Mikrocontroller Board ist viel kleiner im Vergleichzum Hauptspeicher bzw. zur Festplatte eines PCs.Der gewünschte TCP3/IP Stack wurde zwar in der momentanen Version nichtimplementiert, jedoch haben wir uns schon Gedanken darüber gemacht wie dieSpeicherressourcen des PIC’s durch geeignete Codekonstrukte entlastet werden.Deshalb liegt eine zusätzliche Intension darin, dass genug Speicherplatz für zukünftigeFunktionen wie z.B. dem TCP/IP Stack übrig bleibt. Dies wird in den weiterenAbschnitten genauer erläutert.

2) IPÜber den Ethernet-Hardwaretreibern wird nun das Internet Protocol IP angeordnet. Es bündelt die zu übertragenden Daten in Paketemit Absender- und Empfängeradresse und gibt diese Pakete zur Übertragung nach unten an die Ethernet-Schicht weiter. Auf deranderen Seite nimmt IP die Pakete von der Ethernet-Schicht in Empfang und packt sie aus.Die Datenübertragung ist nun schon etwas komfortabler, da jetzt ganze Pakete ausgetauscht werden. Allerdings fehlt noch jeglicherMechanismus um feststellen zu können, ob alle Pakete angekommen sind und welche Reihenfolge diese haben müssen.

3) TCPÜber die IP - Schicht wird nun die Transmission Control Protocol - Schicht TCP gelegt. Diese überwacht die Übertragung, fordertfehlende Pakete erneut an, bringt sie in die korrekte Reihenfolge, usw..Die beiden Protokoll-Schichten TCP und IP werden in der Regel zusammengefasst zu TCP/IP, und da diese übereinander liegen,spricht man auch oft von einem TCP/IP – Protokoll - Stapel oder TCP/IP - Stack.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 9 von 37

2.1.2 Die Softwarestruktur des Mikrocontrollers

Das Hauptprogramm (Bild 3) besteht aus der Initialisierung der IO - Ports und zweiFunktionen in einer Endlosschleife. Die Funktionen werden später genauer erläutert.Jeder einzelne Schleifendurchlauf der Hauptroutine arbeitet nur einen einzigen Befehl auseinem Befehlsatz des Servers ab. Der PIC bekommt jedoch mehrere Befehle d. h. einenBefehlssatz auf einen Schlag gesendet. Der Empfangspuffer des PICs hat nur eine Breitevon 3 Zeichen. Aus diesem Grund werden die Befehle direkt zur Empfangszeit auf demPIC verarbeitet oder bestimmte Merker werden gesetzt.Dies bedeutet, dass der PIC nur bestimmte Funktionsaufrufe schnell genug ausführt. Beigewissen Code Anweisungen kann es zu Problemen kommen. Deshalb werden in diesemFall die Werte bzw. Parameter der Befehle abgespeichert und zu einem späterenZeitpunkt verarbeitet.

Bild 3 Das Nassi - Shneiderman Diagramm der PIC Software

Diese Verarbeitung der zeitaufwendigeren Operationen wird erst nach dem letzten Befehl(EOT = End Of Transmission) ausgeführt (Erläuterungen dazu imKommunikationsprotokoll).Der Grund für diese Maßnahme besteht darin, dass nach dem EOT Befehl der PIC genugZeit hat die restlichen vorgemerkten Operationen auszuführen.

Die Absicht hinter diesem Konzept besteht darin, dass für spätere Implementierungenneuer Prozessdateneinheiten die Zahl der Befehle eines Befehlsatzes beliebig groß seinkann (in Abhängigkeit von der Anzahl der Ports).

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 10 von 37

Wie gesagt wird pro Schleifendurchlauf nur ein Befehl verarbeitet.

Die Routine• void getCommandAndValueString (char * command, char * value)

liest die gesendeten Zeichen einer einzigen Anweisung von der seriellen Schnittstelle(RS232) ein und spaltet diese Zeichenkette in Befehlskürzel (Command) und Wert(Value) auf. In der Funktionsbeschreibung wird das genauer erläutert. Ein '&' Zeichensignalisiert das Ende des kompletten Befehls.

Die Funktion• void SetPort (char port[], char StrValue[])

wird im Anschluss daran aufgerufen. Sie verarbeitet den zuvor empfangenen Befehl.Dieses Spiel wiederholt sich beim Empfang aller Befehle über die serielle Schnittstelle.

Eine komplette Verarbeitung aller Befehle des Servers zur Laufzeit ist nicht möglich, dabestimmte Funktionen zu viel Zeit benötigen. Gleichzeitig müssen vom PIC Befehleeingelesen werden.Diese Wartezeit wird beispielsweise benötigt um den Temperaturwert des Sensors oderdie Dip - Schalterleiste einzulesen. Zusätzlich benötigt der PIC zu viele Taktzyklen fürdas Zurücksenden einer Statusmeldung zum BlackboxNET Programm (CCS – Funktionputs ()).Deshalb werden diese restlichen Operationen erst nach dem Ende aller empfangenenBefehle ausgeführt. Die Intension dieses Ansatzes liegt darin, dass nicht erst alle Befehlein einen Puffer auf dem PIC geschrieben werden müssen. Dies erspart den dafürzusätzlichen erforderlichen Speicherplatz auf dem PIC. Das Programm würde bei einemSpeicherüberlauf bzw. Speichermangel abstürzen oder andere Teile des bereits belegtenPuffers überschreiben.

Des Weiteren sei zu erwähnen, dass durch diese fast gleichzeitige Verarbeitung eingültiger Befehlsatz erkannt bzw. überprüft wird. Somit ist eine fehlerhafteKommunikation auszuschließen.

Das bedeutet, dass am Anfang jedes Befehlssatzes einBOTBefehl =BeginOfTransmission (siehe Kommunikationsprotokoll) empfangen werden muss, um einerfalschen Übertragung vorzubeugen. Ein Befehlssatz besteht aus mehreren Befehlen.Zusätzlich muss jeder Befehlssatz mit einemEOT= EndOf Transmission beendetwerden.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 11 von 37

2.1.3 Das Kommunikationsprotokoll

Die Kommunikation des Servers mit dem PIC findet über ein einfaches selbst definiertesProtokoll statt. Für die Verbindung zwischen Server und PIC sorgt das Visual C++Programm auf dem PC. Es hat die Aufgabe die Strings (Zeichenketten) des Servers anden PIC (siehe Bild 1) weiterzuleiten und umgekehrt.

Die Zeichen die der PIC dann empfängt haben folgendes Format und werden in 2 Typenunterschieden:

Bild 4 Die Unterscheidung zwischen Steuerbefehl und Aktionsbefehl, der Befehlssatz

Die Grafik (Bild 4) soll verdeutlichen, dass es zwei verschiedenen Befehlstypen imKommunikationsprotokoll gibt.Der Grund für die Unterscheidung zwischen Aktions- und Steuerbefehl ist, dass bei denSteuerbefehlen keine zusätzlichen Parameter angehängt werden müssen. Die bis jetztbestehenden Steuerbefehle Typ 1 BOT (Begin of Transmission) und EOT (End ofTransmission) haben nur die Aufgabe eine anfangende bzw. eine endendeBefehlsübertragung zu signalisieren.Die Aktionsbefehle bewirken eine Veränderung bzw. lesen den Zustand derProzessdateneinheit.Es werden aus diesem Grund Parameter übergeben die nach einem '=' Zeichen folgen.In Bild 4 stellen alle 5 Befehle einen kompletten Befehlssatz dar, der zwei Arten vonBefehlstypen beinhaltet.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 12 von 37

Bild 5 Der allgemeine Befehlsaufbau

Die Grafik (Bild 5) erläutert den syntaktischen Unterschied eines Befehls.Bei den Steuerbefehlen entfallen die Punkte 2 und 3. Aktionsbefehle Typ 2 bewirken eineVeränderung des Zustandes auf dem Server bzw. Board, sofern der vorherige Befehlnicht der gleiche war.

Bestehender Befehlssatz:

• BOT(Begin of Transmission): Befehlsübermittlung beginnt• EOT(End of Transmission): Befehlsübermittlung endet• TIM (Timer): Zeitintervall des Timers setzen (Zeit bis Board Status

zurückgesendet wird) Die Mindestwartezeit von einer Sekunde kann nichtunterschritten werden.

• D00 (Digitaler Port 00): Ausgabe am Digitalen Port 00 (00 bis 99 wären optionalmöglich)

• D01 (Digitaler Port 01): Einlesen des definierten Eingangsports 01(Prozessdateneinheiten werden je nach Initialisierung beschrieben odereingelesen)

• A00(Analoger Port 00): Einlesen der aktuellen Temperatur auf dem Board

Hinweis: Das Programm Blackbox hängt an den EOT Befehl ein '&' Zeichen an, damitder PIC erkennt dass der Befehl beendet ist.

Typ 1 Steuerbefehl Typ 2 Aktionsbefehl1. Befehlskürzel (immer 3 Zeichen lang) Befehlskürzel (immer 3 Zeichen lang)2. (entfällt) '=' Startzeichen für den folgenden

Parameter3. (entfällt) Wert (Parameter)4. '&' als Befehlende '&' als Befehlende

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 13 von 37

2.1.4 Die realisierten C-Funktionen des PIC’s

Dieser Abschnitt beinhaltet eine Erläuterung zu den C - Funktionen die auf dem PICimplementiert sind.

Hinweis: Genauere Erläuterungen sind auch direkt im Source Code zu finden!

Die Funktionen:

• void getCommandAndValueString (char * command, char * value)

Aufgabe:Einlesen der seriellen Schnittstelle des PIC’s mit den Zeichen aus dem Puffer.Weiterverarbeitung der Zeichen zu einer Zeichenkette (String). ZusätzlicheAuftrennung eines Befehles in Befehlskürzel (Command) und Wert (Value).

Rückgabewerte bzw. Zeiger:Command Zeiger auf den Befehlskürzelstring NULL terminiert (=Rückgabe)Value Zeiger auf den Wertestring NULL terminiert (=Rückgabe)

Bemerkung:Die empfangenen Befehlskürzel haben ein vereinbartes Protokollformat von 3Zeichen. Darauf folgt ein '=' das ein Ende des Befehlskürzel anzeigt oder ein '&' dasein Ende des kompletten Befehls anzeigt. Durch das '=' Zeichen wird dann erkanntdas ein Wert folgt. Also sobald ein '&' empfangen wird endet die Ausführung dieserFunktion, da es bedeutet dass der empfangene Befehl zu Ende ist und ein weitererfolgen kann.

Benötigte Header Datei:#include "picdefinition.h"#include "stdlib.h"#include "string.h"

• void init_digiport ()

Aufgabe:Die Funktion initialisiert die I/O-Ports.

Benötigte Header Datei:#include "picdefinition.h"

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 14 von 37

• void delay_seconds (int n)

Aufgabe:Sekunden Warteroutine

Parameter:n Integer (Zeit in Sekunden)

Bemerkung:PIC wartet für die Zeit n in Sekunden in dieser Routine.Werte kleiner 1 werden wieder auf 1 gesetzt.

Benötigte Header Datei:#include "picdefinition.h"

• int getInPutValues ()

Aufgabe:Einlesen der Eingangsbits bzw. Ports und Konvertierung dieser Bits zu einem Integer.

Rückgabewert:integer Rückgabe der 8 Eingangs Bit als Integer

Bemerkung:Einlesen der Define Ports in0, in1, in2, in3, in4, in5, in6 und in7.

Benötigte Header Datei:#include "picdefinition.h"

• int WhichPorttoSet (char myport[])

Aufgabe:Stringvergleichsfunktion welche die Befehlskürzel erkennt und ihrer Aufgabezuordnet.

Rückgabewert:integer als Option

Bemerkung:Prioritätsencoder (if Bedingungen) da die switch case Bedingungen keineZeichenketten (Strings) zulassen.

Benötigte Header Datei:#include "string.h"

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 15 von 37

• void SetPort (char port[], char StrValue[])

Aufgabe & Bemerkung:HauptabarbeitungsfunktionGenauere Erläuterungen dazu findet man im PIC Source Code. DieBefehlsabarbeitung findet nur statt wenn ein gültiges 'BOT' empfangen wurde. Allearbeitsaufwendigen Operationen des PICs finden erst nach dem gesendeten 'EOT'statt. Was bedeutet, dass der Temperaturwert des Temperatursensors erst danngelesen wird. Danach werden die Input Bits eingelesen. Daraus und aus den vorhergesetzten Globalen Variablen wird der Rücksendestring an den Server generiert undgesendet. Es folgt das ausführen der Warteschleife bis der PIC wieder den neuenBefehlsatz vom Server anfordert d.h. dass das Hauptprogramm des PIC's wieder indie Einlesefunktion springt.

Parameter:char port[] aus globaler Variable strMyKey (String = Array aus chars = Zeichen)char StrValue[] aus globaler Variable strMyValue, falls nicht leer

Benötigte Header Datei:#include "string.h"#include "picdefinition.h"#include "stdlib.h"#include "1_wire.h"

Hinweis: Die in den jeweiligen Header Dateien deklarierten Header Dateien solltensich natürlich im Projektverzeichnis befinden und sind bei denbenötigten HeaderDateiennicht berücksichtigt.

Bsp.: Sendestring des PICs an den PC via serielle Schnittstelle

http://141.47.75.234/cgi-bin/aportal/modules.cgi?CMD=read §http://141.47.75.234/cgi-bin/aportal/modules.cgi?CMD=write&TIM=5&A00=23.5&D00=111&D01=222 #

Das Zeichen ’§’ signalisiert das Ende des Lesebefehls. Das Zeichen ’#’ signalisiert dasEnde des Schreibbefehls. Deshalb werden die Zeichen im BlackboxNET Programmentfernt.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 16 von 37

2.2 Das Blackboxnet Programm

Die Aufgabe des Programms BlackboxNET besteht darin unseren PIC Controller,welcher noch nicht über eine Ethernetverbindung verfügt, mit dem Netzwerk zuverbinden. Die Software setzt empfangene Daten von der RS232 Schnittstelle auf dasEthernet um und umgekehrt. Somit wird eine Kommunikation zwischen PIC und Serveraufgebaut.

Die Realisierung des Programms wurde mit der Programmiersprache Visual C++durchgeführt.Der Code darf vom CVS Repository herunter geladen werden.Genauere Informationen sind auf derhttp://automatisierung.fh-pforzheim.deSeite zufinden.

Zusätzlich zum Programm wurde ein Installationspaket der Software erstellt. Somit kanndie Anwendung auf jedem beliebigen Windowsrechner installiert werden.

Erläuterungen zur Verwendung des Programms:Der ButtonGet Server Statusholt den gewünschten letzten Datensatz einerProzessdateneinheit vom Server. Sobald das EditfensterRS 232 Sendestringmit denZeichen des Befehlsprotokolls gefüllt ist kann eine ständige Abfrage und Lieferung derDaten durch einen klick auf den ButtonSendengestartet werden. Die Interaktion ist nunan den Änderungen der StatusfensterNetzstatusundRS232 Eventzu erkennen. Durch dasFeldCom Portkann der RS232 Port zum PIC je nach Belegung der Ports am PCzwischen 1 und 4 verändert werden.Eine Initialisierungsdatei ist nicht vorhanden. In diesem Fall muss jedes Mal beim startendes BlackboxNet Programms der COM Port wieder verändert werden, sofern dieser nichtder Standardeinstellung Port 2 entspricht.

Mit dem Button Netzverbindung beenden wird die ganze automatische Prozedur.Sie kann aber wieder wie gewohnt gestartet werden. Auf die Dokumentation des SourceCodes wird verzichtet, da es zum jetzigen Zeitpunkt nur ein Hilfsmittel ist.

Probleme:Das Blackbox Programm verwendet 2 ActiveX4 Steuerelemente, eines für die TCP/IPVerbindung und das zweite für das Programmieren der seriellen Schnittstelle. Aufgrundbestimmter Netzwerkprobleme kann es vereinzelt zu einem Abbruch der Kommunikationzwischen PIC und Server kommen. DiesesFeaturehängt von der Netzkonstellation abund kann nur durch erneutes manuelles Starten behoben werden.

4) ActiveX SteuerelementEin ActiveX Steuerelemente ist eine Softwarekomponente, die sich in die verschiedensten unter Microsoft Produkten erstelltenProgrammen einbauen lässt und die man wie einen ursprünglichen Teil des Programms verwenden kann. Das Konzept dahinter ist mitdem Baukastensystem einer Stereoanlage vergleichbar. Wenn man z.B. einen Schallplattenspieler kauft, kann man den einfach mit derbereits vorhandenen Anlage verbinden und deren Funktionalität erweitern. ActiveX Steuerelemente bringen die gleichenMöglichkeiten der Zusammenarbeit von Komponenten in Softwareanwendungen.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 17 von 37

3 Die Prozessvisualisierung

Die Prozessvisualisierung wird mittels verschiedener Java Applets realisiert, das inunsere Webseite integriert ist. Sie dienen der Kommunikation zwischen Client undServer.

3.1 Was ist ein Java Applet?

Ein Applet ist ein kleines übersetztes Java Programm, das man mit einem Web-Browserim Internet aufrufen kann (über die HTML – Datei). Der Browser z.B. Microsoft InternetExplorer 6.0 muss die Programmiersprache Java interpretieren, damit die Anwendungausgeführt wird.

Das Applet besitzt meistens eine grafische Benutzeroberfläche und liefert fast dengesamten Leistungsumfang von Java für Multimediaanwendungen (Animationen,Ausgabe von Bildern und Sound siehe nachfolgende Tabelle).Die Vorteile von Applets liegen in der Plattformunabhängigkeit (läuft unterverschiedenen Browsern), und dass das Programm direkt aus dem Netz herunterladen undauf dem Clientbrowser ausgeführt werden kann.Die Nachteile der Java Applets liegen vor allem in der geringen Geschwindigkeit unddem etwas höherer Erstellungsaufwand in Gegensatz zu Java Script5 oder Flash6.

Für die Visualisierung komplexer Vorgänge im Internet sind Applets besonders gutgeeignet und werden deshalb meist im Bereich Online – Banking verwendet.

Sicherheit ist wichtig, weil Applets dazu gedacht sind, von einem entfernten Rechnergeladen und auf einem lokalen Rechner ausgeführt zu werden. Deshalb ist man imGegensatz zu richtigen Java Anwendungen in den Möglichkeiten eingeschränkt.

1. Applets können niemals lokale Programme ausführen2. Applets können nur mit dem Server kommunizieren, von dem sie geladen

wurden.3. Applets können das Dateisystem des lokalen Rechners weder lesen noch

schreiben (hängt natürlich vom entsprechenden ausführenden Browser ab).4. Applets können keinerlei Informationen über den lokalen Rechner ausfindig

machen, außer der benutzten Java – Version, dem Namen und der Version desBetriebssystems und dem Zeichen, das zum Trennen von Dateien (z.B. / oder\),Pfadnamen und Zeilen verwendet wird. Insbesondere können Applets nicht denNamen des Anwenders, seine E-mail- Adresse usw. herausfinden.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 18 von 37

Die folgende Tabelle zeigt was Java – Programme unter den folgenden Umständen tundürfen.

Operation NL NF AV JAlokale Datei lesen Nein Nein Ja Jalokale Datei schreiben Nein Nein Ja JaDateiinformationen erhalten Nein Nein Ja JaDatei löschen Nein Nein Nein Jaein anderes Programm ausführen Nein Nein Ja Jaden Benutzernamen lesen Nein Ja Ja Ja

Verbindung zum Netzwerk des Servers Ja Ja Ja Ja

Verbindung zum Netzwerk einesanderen Systems

Nein Ja Ja Ja

Java-Bibliothek laden Nein Ja Ja Jaexit aufrufen Nein Nein Ja Jaein Pop - Up - Fenster erzeugen mit Warnung Ja Ja Ja

NL = ein URL geladen durch NetscapeNF = eine lokal geladene Datei durch NetscapeAV = Applet BetrachterJA = als Java-Anwendung (nicht als Applet)

Tabelle und Sicherheitsgrundlagentext aus [1] (siehe Literaturhinweise)

5) Java ScriptJava Script ist eine Internet – Programmiersprache, die Java sehr ähnelt, aber viel einfacher zu erlernen ist.Java Script wird anders als Java direkt in den HTML – Code geschrieben. Für Java ist es notwendig, mit dem JDK(Java DevelopmentKit) oder einem grafischen Tool zu programmieren. Dann wird der Code kompiliert und das Applet und das Applet liegt als Bytecodein einem Appletclass– File vor. Für Java Script ist es nicht notwendig, den Code zu kompilieren. Es werden keine separaten Dateienwie bei Java (*.java und *.class) benötigt.

6) FlashVor Flash bewegte sich wenig im Internet. Meist kamen animierte Gif - Grafiken zum Einsatz, die durch eine Abfolge vonEinzelbildern einen Daumenkino-Effekt erzeugten. Flash hingegen setzt auf Filme. In diesen Movies folgen Grafiken, Texte, Fotosund Sounds einer eigenen Choreografie. Während der Produktion wird das Verhalten aller beteiligten Filmelemente mit Hilfe einerZeitleiste festgelegt. Überblendungen zwischen Bildern, Farbwechsel und bewegliche Schriftzüge gehören zum Standardrepertoire derFlash - Movies.Seit seiner Einführung 1993, damals kam das Programm unter dem Namen Canvas auf den Markt, entwickelte sich Flash vom bloßenAnimationstool zur multimedialen Komplettlösung, die seit der Version 3 auch Interaktivitäten ermöglicht.Zum Abspielen der Flash-Movies benötigt der Browser zwingend den Flash-Player. Der massive Einsatz von Flash löst häufigSpekulationen darüber aus, ob Flash eines Tages den HTML-Standard verdrängen wird. Andererseits werden ausufernde Flash-Introsvon vielen Usern als lästig empfunden. Fakt ist aber, dass Flash inzwischen aus Web-Präsentationen und e-Learning-Lösungen nichtmehr wegzudenken ist.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 19 von 37

3.2 Realisierung der Prozessvisualisierung

Da jede Prozessstation eine Zahl an digitalen und analogen Ports bzw.Prozessdateneinheiten besitzen kann, muss dafür auch eine Visualisierung auf derClientseite stattfinden. Dies bedeutet, dass zumindest zwei verschieden Applets proProzessstation nötig sind, d.h. unterschiedliche Applets für analoge oder digitaleProzessdateneinheiten.Hinzu kommt dass für jede Prozessdateneinheiten durch ein XML7 – File auf dem Serverzusätzlich konfiguriert werden kann, ob die jeweilige Prozessdateneinheit beschreibbaroder nur lesbar sein soll (genaueres dazu in der Dokumentation von Alexander Thiel).Damit verdoppelt sich die Zahl der denkbaren Prozessvisualisierungs- Applets proProzessstation auf 4 unterschiedliche Möglichkeiten.Je nach XML - Konfiguration bekommt jede Prozessdateneinheiten einen der vier Fällezugeordnet.Die 4 Viewer – bzw. Prozessvisualisierungs- Applets werden zusammen in einem Paketverpackt und komprimiert. Dieses Paket ist nun ein JAR – File.Alle Informationen für den Client Browser stecken in einem JAVA JAR – Archivfile,welches 4 verschiedene Layouts enthält:

• read_digital• read_analog• write_digital• write_analog

Diese Layouts werden in Abhängigkeit der Parameter in der XML – Config für dieentsprechende Prozessvisualisierung geladen.

Zusätzlich haben wir uns aber die Möglichkeit offen gelassen verschiedene JAR ViewerPakete für jede einzelne Prozessstation zu schreiben, welche natürlich auch dann in demXML – File konfiguriert werden können.Jedes Paket muss die vier oben genanten Applets enthalten, damit es mit unserem Systemfunktioniert.Die Intension welche hinter dieser Idee steckt ist, dass jeder User seine eigenen Viewer-bzw. Prozessvisualisierungs- Applets für die jeweilige Prozessstation schreiben kann.

Das Simpleview JAR Paket ist das einfachste Standard Paket für eineProzessvisualisierungsstation (es gibt keine zusätzliche graphische Darstellung derProzessdateneinheit).

Es verändern sich bei einem neuen Viewerpaket nicht alle Java Dateien (in diesem Fallnicht das gesamte Simpleview JAR Paket), sondern nur gewisse JAVAVisualisierungspanels (Java Dateien) bzw. es kommen neue dazu.

7) XMLXML ist die Abkürzung für Extensible Markup Language; eine 1998 vom World-Wide-Web-Consortium standardisierte Sprache aufder Basis von SGML, mit der sich Auszeichnungssprachen definieren lassen. Im Unterschied zu SGML oder HTML könnenbestimmte Teile von XML selbst definiert und im gleichen Dokument auch genutzt werden. Damit wird der Seitenaufbau und dieBehandlung von Daten mit XML erheblich flexibler.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 20 von 37

3.2.1 Der zeitliche Ablauf während der Prozessvisualisierung

Was passiert eigentlich wenn ein User auf der HTML – Seite einer Prozessstation landet?

Bild 6 Der zeitliche Ablauf während der Prozessvisualisierung

Phase 1 Initialisierung:Der Client startet durch den Mausklick eine HTML – Anfrage an den Portalserver.Dieser sendet ihm dann die HTML – Datei inklusive dem in dem XML – Filekonfigurierten Prozessvisualisierungsviewer.Die Viewer bzw. das JAR File und die HTML-Datei werden in dem Ordner TemporaryInternet Files (Clientrechner) herunter geladen und gespeichert.Nun befindet sich der Java Bytecode auf der Clientseite.Der Browser startet nun die Applet Anwendung aus dem JAR - Paket.

Phase 2 Datenabgleich:In der Initialisierungsroutine des Applets wird ein Timer mit einem konstantenTaktzyklus gestartet.Dieser Timer baut pro Taktzyklus einmal eine Verbindung zum Portalserver auf und holtsich durch den Aufruf des serverseitigen CGI Skriptes die aktuellen Daten der jeweiligenProzessstation.Diese Daten werden dann in der Appletansicht nach jedem Takt aktualisiert.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 21 von 37

3.2.2 Das UML Gerüst der Prozessvisualisierung

Im Kapitel 5 sind die Klassendiagramme der Prozessvisualisierungspakete Simpleviewund Lightview zu finden. Die Diagramme sollen Aufschluss über den Aufbau einesProzessvisualisierungspaketes geben.

Wie bereits erwähnt besteht jedes JAR Paket aus den vier Prozessvisualisierungsappletsread_digital, read_analog, write_digital und write_analog. Diese Klassen sind immer vonder Java Klasse Applet abgeleitet. Auf jedem einzelnen Applet ist die grafischeBenuteroberfläche in bestimmte Panels unterteilt.Panels sind Behälter für Komponenten, die ihrerseits im Fenster angeordnet werden. Sobenutzt man z.B. ein Panel für die Schaltflächen und ein anderes Panel für dieEingabefelder.

Die Benutzeroberfläche wird aus unterschiedlichen Panels zusammengesetzt (eine ArtBaukastenkomponente).Ein zweites Klassendiagramm über das Lightview Paket verdeutlicht einmal genauer denAufbau und die Struktur der einzelnen Panels.

3.2.3 Das Simpleview Paket

Das Simpleview Paket enthält insgesamt fünf Derivate von der Klasse Panel (siehe Bild11). Jedes dieser Panels hat eine bestimmte Aufgabe die nun beschrieben wird:

1. Die KlasseKeyValuePanelist ein Panel, welches nicht direkt als Komponenteder Appletklasse verwendet wird. Hierbei handelt es sich um eine Panelklasse dienormalerweisenur in jeweilige andere Panels eingebunden wird. Dieses Panelenthält ein Textfeld und ein entsprechendes Label dafür.ÿ Kombination aus Bezeichnung bzw. Labelfeld (Key) und Wert bzw. Textfeld(Value)

2. DieBasicInfoPanelKlasse enthält das KeyValuePanel in diesem Fall dreimal.Bei der Erzeugung dieses Panels wird die Modul IP, Portnummer und dieBezeichnung übergeben. Die Werte dieses Panels verändern sich nur bei einerneuen Konfiguration im XML – File. Der User kann diese Konfiguration nichtverändern.

3. Über dieNetConnectionKlasse kann nur gesagt werden, dass diese Klassebestimmte Funktionen ausführt, welche den Serverstatus der jeweiligenProzessstation abfragen. (Man hätte z.B. die Funktionen auch als statischeFunktionen deklarieren können.). Diese Funktionen rufen das CGI Skript desServers auf und bekommen das Ergebnis der Abfrage als String zurück. Daraufhinfolgt eine Stringmanipulation und Aufbereitung.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 22 von 37

Diese Funktionen sollen dem eigentlich verwendeten PanelderivatValueInfoPanelzusätzlich zur Verfügung stehen. Dieses ValueInfoPanel wirdvon allen Prozessvisualisierungsapplets verwendet und ist von der KlasseNetConnection abgeleitet. Es enthält zwei KeyValuePanels für die Visualisierungder dynamischen Werte.Zusätzlich wird in diesem Panel ein Timer eingebunden, welcher die für diezyklische Abfrage (Kapitel 3.2.1 Datenabgleich) verantwortlich ist. Dieser Timerkann über das Interface TimerHandler ebenfalls auch für andere Programmeverwendet werden.

4. Das WriteDigitalValuePanel öffnet unabhängig zum InfoValuePanel einen Kanalzum Server. Es besteht mit diesem Panel die Möglichkeit neue Datensätze für diejeweilige Prozessvisualisierungsstation anzulegen. Dieses Panel wird für diedigitalen Ports verwendet.

5. Das WriteAnalogValuePanel erfüllt den gleichen Zweck wie dasWriteDigitalValuePanel, jedoch für die analogen Ports.

In Bild 7 und 8 sind die Panels des Simpleview Pakets grafisch mit Farbe markiert, damitdas Konzept des Baukastensystems verdeutlicht wird.

Bild 7 Das Simpleview Paket read_digital Applet

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 23 von 37

Bild 8 Das Simpleview Paket write_analog Applet

Hinweis:Die restlichen fünf KeyValuePanels sind in dieser Abbildung nicht mehrmarkiert (vergl. Bild 7).

Die Applets write_digital und read_analog sind hier nicht aufgeführt, da sie sich visuellnicht von den beiden Beispielen unterscheiden.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 24 von 37

3.2.3 Das Lightview Paket

Der Unterschied zwischen dem Simpelview Paket und dem Lightview Paket ist dass dasLightview Paket drei zusätzliche Klassen enthält.Diese Klassen werden nun beschrieben und sind zusätzlich grafisch in Kapitel 5 Bild 14und 15 beschrieben.

Die KlasseLightPanel ist für die visualisierten *.JPG bzw. *.GIF Bilder verantwortlichwelche in Bild verwendet werden. Das Panel zeigt die Zahl 70 binär als Bilderkette an.Damit die Bilder (hier Lampen) sich auch an die Größe des Panels anpassen wird dieKlasseBildCanvasbenötigt.

Die ValueLightInfoPanel Klasse ersetzt die Funktion der SimpleviewklasseValueInfoPanel. Sie wurde ebenfalls von NetConnection abgeleitet und implementiertdas Interface TimerHandler. Jedoch enthält eine Instanz der Klasse LightPanel zurbinären Visualisierung.

Bild 9 Das Lightview Paket write_digital Applet

Die Applets write_analog und read_analog sind hier nicht aufgeführt, da sie sich visuellund inhaltlich nicht von dem Simpleview Paketapplets unterscheiden.Bei der read_digital Klasse würde nur das WriteDigitalValuePanel wegfallen.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 25 von 37

3.3 Gründe für die Entscheidung zu dieser Struktur

Durch objektorientierte Programmierung verringern sich die Zeilen an Source Code fürneue Entwicklungsprojekte. Die Gründe für die Abnahme sind die Vererbungshierarchienund bereits bestehenden Softwarebibliotheken. Aus diesem Anlass und wegen derPlattformunabhängigkeit wurde Java wurde als Programmiersprache für dieVisualisierung einer Prozessstation innerhalb eines Browsers verwendet.Die in diesem Projekt erstellten Klassen sollen ein Ansatzpunkt für zukünftigeProzessvisualisierungen unseres Systems sein. Die bisher erstellten Applets dienen alsBaukastengruppe für neue Prozessvisualisierungprojekte. Damit verringert sich derEntwicklungsaufwand für neue Viewer erheblich, da ein bestehendes Modul kein zweitesMal erstellt werden muss.

4 Epilog

4.1 Zusammenfassung

In diesem zweiten Teil der Dokumentation wurde die Realisierung einer Software füreinen PIC (Programable Integrated Circuit) als Prozessstation innerhalb unseresGesamtsystems (Bild 1) besprochen.Außerdem haben wir die Verwirklichung eines Applets als Prozessvisualisierungbeschrieben.Dabei sind die Prozessvisualisierung und die Prozessstation Komponenten einesGesamtsystems, welches eine Messdatenerfassung an einer Prozessstation (PIC – Board)durchführt, die über das Internet gepflegt und abgerufen werden kann.

4.2 Zukünftige Ansatzpunkte

Es gibt Verbesserungsmöglichkeiten bei der Verbindung der Applets zum Server. Hiersollte mit mehren Threads gearbeitet werden, da dies bei einer schlechtenNetzwerkverbindung zu Problemen führen kann, d.h. dass das Applet lange auf eineAntwort vom Server wartet, diese jedoch nicht ankommt (das Applet bleibt in einerRoutine hängen). In diesem Fall jetzt muss manuell im Browser der Refresh Buttongedrückt werden.

Als weiterer Ansatzpunkt wäre ein webfähiges PIC Board bzw. Prozessstation mitintegriertem TCP/IP Stack. Dieser wurde nicht implementiert, da die dafür notwendigeHardware noch nicht vorhanden ist.

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 26 von 37

Bei dieser Implementierung (Bild 10) würde der BlackboxNET Client aus Bild 1wegfallen. Das Board soll in der Zukunft voll webfähig werden und die Funktionen desBlackboxNET Programms mit auf dem PIC integrieren, d.h. dass das Board direkt an dasEthernet angeschlossen werden kann.

Bild 10 Das zukünftige Kommunikationsmodel

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 27 von 37

5 Anhang Applet Klassendiagramme OOD

Bild 11 Das Klassendiagramm für das Paket Simpleview

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 28 von 37

Bild 12 Zusätzliche Detailklassen des Pakets Simpleview

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 29 von 37

Bild 13 Die Legende der Klassendiagramme

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 30 von 37

Bild 14 Das Klassendiagramm für das Paket Lightview

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 31 von 37

Bild 15 Zusätzliche Detailklassen des Pakets Lightview

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 32 von 37

6 Anhang Mikrocontroller als Prozessstation(Schaltpläne)

Bild 16 Der PIC Polsockel

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 33 von 37

Bild 17 Die serielle Schnittstelle (RS232)

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 34 von 37

Bild 18 Die LED Kette inklusive Dip - Schalter

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 35 von 37

Bild 19 Der Prozessor

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 36 von 37

7 Abbildungen

Bild 1 Das Kommunikationssystem.................................................................................... 5Bild 2 Das Mikrocontroller Board ...................................................................................... 7Bild 3 Das Nassi - Shneiderman Diagramm der PIC Software .......................................... 9Bild 4 Die Unterscheidung zwischen Steuerbefehl und Aktionsbefehl, der Befehlssatz . 11Bild 5 Der allgemeine Befehlsaufbau ............................................................................... 12Bild 6 Der zeitliche Ablauf während der Prozessvisualisierung ..................................... 20Bild 7 Das Simpleview Paket read_digital Applet ........................................................... 22Bild 8 Das Simpleview Paket write_analog Applet.......................................................... 23Bild 9 Das Lightview Paket write_digital Applet............................................................. 24Bild 10 Das zukünftige Kommunikationsmodel............................................................... 26Bild 11 Das Klassendiagramm für das Paket Simpleview ............................................... 27Bild 12 Zusätzliche Detailklassen des Pakets Simpleview............................................... 28Bild 13 Die Legende der Klassendiagramme ................................................................... 29Bild 14 Das Klassendiagramm für das Paket Lightview .................................................. 30Bild 15 Zusätzliche Detailklassen des Pakets Lightview ................................................. 31Bild 16 Der PIC Polsockel................................................................................................ 32Bild 17 Die serielle Schnittstelle (RS232) ........................................................................ 33Bild 18 Die LED Kette inklusive Dip - Schalter .............................................................. 34Bild 19 Der Prozessor ....................................................................................................... 35

FB 2 – ET / IT

http://automatisierung.fh-pforzheim.de Seite 37 von 37

8 Literatur

[1] Cornell, Gary:Java bis ins Detail: das Buch für Experten / Gary Cornell/Cay S. Horstmann[Dt. von: G&U Flensburg].- Hannover: Heise, 1996Einheitssacht.: Core Java <dt.>NE: Horstmann, Cay S.:ISBN 3-88229-087-0

[2] Walter Doberenz:Programmierung interaktiver WWW-Seiten/ Walter Doberenz / Uwe Druckenmüller. –München ; Wien: Hanser (Hanser Programmier Praxis)Teilw. nur verf. Von Walter DoberenzISBN 3-446-19047-3ISBN 3-446-18854-1 (1. Aufl.)Buch. – 2., aktualisierte Auflage – 1998

[3] Dan Gookin:Computerlexikon für Dummies / Dan Gookin, Sandra Hardin Gookien.Übersetzung aus dem Amerikanischen von Martina Hesse-Hujber und Sabine Lambrich.Bonn: MITP-Verlag , 1998Einheitssacht.: Illustrated Computer Dictionary for Dummies <dt.>NE: Sandra Hardin GookinISBN: 3-8266-2771-7

[4] Heide Balzert:Lehrbuch der Objektmodellierung: Analyse und Entwurf / Heide Balzert. – Heidelberg,Berlin: Spektrum, Akad. Verl., 1999 (Lehrbücher der Informatik)ISBN: 3-8274-0285-9

[5] RRZN: Regionales Rechenzentrum für Niedersachsen / Universität HannoverJava 2 Grundlagen und Einführung 1. Auflage April 2001RRZN - Klassifikationsschlüssel: SPR.JAV 1

[6] RRZN: Regionales Rechenzentrum für Niedersachsen / Universität HannoverC Die Programmiersprache C. Ein Nachschlagewerk 9. (fast) unveränderte AuflageRRZN - Klassifikationsschlüssel: SPR.C 1

[7] MSDN – Library: July 2000 DVD von Microsoft

[8] JavaTM 2 SDK: Standard Edition Documentation Version 1.4.0 Sun Microsystems,Inc.

[9] Prof. Dr. K. – H. Rau Skriptum Systementwicklung FH – Pforzheim