DIPLOMARBEIT - sobierajski.de fileDIPLOMARBEIT Aufzeichnungs- und Auswertesystem für ein...

DIPLOMARBEIT

Aufzeichnungs- und Auswertesystem für ein Feldbussystem

vorgelegt von Sebastian Sobierajski Iserlohn geboren am: 20.02.1980 Matr.-Nr.: 10002853

Fachhochschule Südwestfalen Hochschule für Technik und Wirtschaft Fachbereich Informatik und Naturwissenschaften

Sommersemester 2004/2005 1. Prüfer: Prof. Dr.-Ing. Fritz Mehner 2. Prüfer: Prof. Dr.-Ing. Walter Roth

Inhaltsverzeichnis

1

Inhaltsverzeichnis

Danksagung ..........................................................................................4

1 Einleitung und Zielsetzung..............................................................5

2 Anforderung an das System..............................................................8 2.1 Grundanforderung ....................................................................................8 2.2 Musskriterien..............................................................................................8 2.3 Wunschkriterien.........................................................................................9

3 Verwendete Entwicklungsumgebungen........................................ 10 3.1 Metrowerks CodeWarrior ......................................................................10 3.2 Borland C++ Builder 6 ..........................................................................10 3.3 Zusätzliche Werkzeuge...........................................................................11

4 Technische Grundlagen ................................................................. 12 4.1 Das Demonstrations Board DEMO9S12NE64.................................12

4.1.1 Beschreibung der DEMO9S12NE64 Hauptplatine................13 4.1.2 Kurze Einführung in den MC 9S12NE64................................14 4.1.3 Das Ethernet Physical Transceiver (EPHY) – Modul ...........15 4.1.4 Das Medium Independent Interface (MII) .............................15 4.1.5 Das Ethernet Media Access Controller (EMAC) - Modul....15 4.1.6 Konfiguration des EPHY- und EMAC-Moduls......................16 4.1.7 Das Serial-Communications-Interface(SCI)-Modul ................17

4.1.7.1 Erweiterungen an der Hardware des DEMO9S12NE64 Boards.....................................................18

4.1.7.2 SCI 1 Register-Konfiguration................................................20 4.2 Relevante Aspekte des ISO/OSI-Referenzmodells

zum TCP/IP-Schichtmodell..................................................................24 4.3 Das serielle VC3-Netzwerk....................................................................27 4.4 Das LON-Netzwerk / DPnet-Netzwerk ............................................27

4.4.1 Der Schicht-2-Header ..................................................................28 4.4.2 Aufbau der NPDU.......................................................................29 4.4.3 Der Adressaufbau.........................................................................30 4.4.4 Das PDU-Format .........................................................................31 4.4.5 Aufbau der Transport Protocol Data Unit (TPDU) ...............31 4.4.6 Aufbau der Session Protocol Data Unit (SPDU) ....................33 4.4.7 Aufbau der Application Protocol Data Unit (APDU)............34 4.4.8 Die Authentication Protocol Data Unit (AuthPDU)..............35

Inhaltsverzeichnis

2

4.5 Spezielle Software-Konzepte.................................................................36 4.5.1 Die VCL-Bibliothek .....................................................................36 4.5.2 Viola Systems OpenTCP TCP/IP Stack...................................36 4.5.3 Software-Paradigmen ...................................................................37 4.5.4 Das Lognachrichten-Speicherkonzept ......................................40 4.5.5 Das Konzept der Zeitschleifenkalibrierung..............................42

5 System-Architektur und Software-Architektur...............................44 5.1 Aufgabenverteilung im Aufzeichnungs- und Auswertesystem.........44 5.2 Der Entwicklungsaufbau........................................................................46 5.3 Die Client-Anwendung...........................................................................47

5.3.1 Die Client-Anwendung im Zustand Startup.............................49 5.3.2 Die Client-Anwendung im Zustand NWL Verbunden ..........52 5.3.3 Die Client-Anwendung im Zustand Aufzeichnung.................52

5.4 Das Kommunikationsprinzip zwischen Client und Mikrocontroller (NWL)..........................................................................53

5.5 Der Nachrichtenaufbau..........................................................................54 5.5.1 Aufbau von Kommandonachrichten.........................................55 5.5.2 Aufbau von Kommandobestätigungsnachrichten...................58 5.5.3 Aufbau von VC3-Lognachrichten..............................................59 5.5.4 Aufbau von DPnet-Lognachrichten..........................................60 5.5.5 Aufbau von Heartbeat-Nachrichten..........................................60

5.6 Der Kommando/Bestätigung-Mechanismus......................................61 5.7 Der Verbindungsaufbau zwischen Client-Programm und

Mikrocontroller (NWL)..........................................................................63 5.7.1 Neustart der NWL-Ethernet-Schnittstelle................................65

5.8 Übermittlung der Aufzeichnungsparameter an den NWL................67 5.9 Die Nachrichtenaufzeichnung...............................................................69

5.9.1 Nachrichtenaufzeichnung auf dem NWL.................................69 5.9.2 Nachrichtenaufzeichnung auf dem Client-Programm ............72

5.10 Die Nachrichtenanalyse.........................................................................72 5.10.1 Analyse von VC3-Lognachrichten.............................................73 5.10.2 Analyse von DPnet-Lognachrichten .........................................74

5.11 Fehlerbehandlung...................................................................................76 5.11.1 Fehlerbehandlung auf dem Client-Programm..........................76 5.11.2 Fehlerbehandlung auf dem NWL ..............................................77

6 Schlussbetrachtung ........................................................................78 6.1 Bekannte Fehler und Mängel, zu lösende Probleme..........................78

Inhaltsverzeichnis

3

Abbildungsverzeichnis........................................................................80

Anhang ................................................................................................82

Literaturverzeichnis ............................................................................85

4

Danksagung

Herrn Prof. Dr.-Ing. Fritz Mehner danke ich sehr herzlich für die

Überlassung des Themas, sein stetes Interesse am Fortgang der Arbeit und

die kritische Durchsicht bei der Abfassung der vorliegenden Schrift.

Herrn Dr. Peter Kaever danke ich für die Bereitstellung der

Entwicklungsumgebung, die Diskussionsbereitschaft, die zahlreichen

technischen Ratschläge, die Mitwirkung an der Arbeit, die Korrektur der

vorliegenden Schrift und die damit einhergehende unermüdliche

Hilfsbereitschaft.

Herrn Prof. Dr.-Ing. Walter Roth für die Übernahme des Koreferates.

Allen Mitgliedern des Studiengangs Angewandte Informatik für ihre

Hilfsbereitschaft.

Meiner Lebensgefährtin Joanna Onyskow danke ich ganz besonders für ihr

Verständnis und ihre Geduld.

Zu guter Letzt möchte ich meinen Eltern und meiner Familie danken, die

mir das Studium der Angewandten Informatik und damit auch diese

Diplomarbeit erst ermöglicht haben.

Iserlohn, im Februar 2008 Sebastian Sobierajski

Einleitung und Zielsetzung

5

1 Einleitung und Zielsetzung

Die Firma WestfaliaSurge gehört zum Unternehmensverbund der GEA

AG. Die GEA ist im Maschinen- und Anlagenbau tätig und insbesondere

auf Prozesstechnik sowie Komponenten spezialisiert, die in der

Nahrungsmittel-, Getränke-, Pharma-, Kosmetik- und Chemie-Industrie

eingesetzt werden. Dabei bietet die Firma WestfaliaSurge führende

Kompetenz bei der Entwicklung moderner Systeme zur Milchproduktion

sowie deren Service.

Diese Systeme zur Milchgewinnung nutzen Feldbussysteme zur Steuerung

und Überwachung der dort ablaufenden technischen Prozesse.

Unterschiedliche Konstellationen der Anlagen bilden sich über die

Feldbussysteme auf komplexe Netzwerktopologien ab, in denen mehrere

Prozesse Daten austauschen. Bei der Entwicklung bzw. Wartung solcher

Netzwerktopologien gestaltet sich eine Fehlersuche sehr schwierig. Die

Schwierigkeit ergibt sich durch die große Anzahl der Nachrichten, die über

das Netzwerk ausgetauscht werden, und den komplexen Aufbau jeder

Nachricht. Sporadisch auftretende Fehler sind somit sehr schwer

auffindbar.

Diese Arbeit beschäftigt sich mit der Entwicklung eines Werkzeuges für die

Aufzeichnung und Analyse von Netzwerknachrichten.

Mit Hilfe dieses Werkzeuges wird den Mitarbeitern der Firma

WestfaliaSurge ein Hilfsmittel in die Hand gegeben, das es ermöglicht, die

firmeninternen Netzwerke DPnet und VC3 aufzuzeichnen und in weiteren

Schritten zu analysieren. Das Produkt findet in der Entwicklungsphase

sowie bei der Fehlersuche in Netzwerken seinen Haupteinsatz, wo eine

Aufzeichnung der gesamten Datenübertragung zwischen den vernetzten

Geräten wichtig ist.

Das angestrebte Endprodukt dieser Arbeit besteht aus einem

Mikrocontroller für das Empfangen und Auslesen der Netzwerknachrichten

(den NWL = Networklistener) und einem PC mit zugehöriger Software

(den Client) für die Aufzeichnung und Auswertung der durch den NWL


6

eingelesenen Nachrichten. Die Kommunikation zwischen Client und NWL

erfolgt über Ethernet (s. Abb. 1).

Abbildung 1 Komponenten des Aufzeichnungs- und Auswertesystems

Networklistener

Mikrocontroller

PC

Ethernet

DPnet Netzwerk

VC3 Netzwerk

Um die Kommunikation über Ethernet zwischen NWL und Client-

Anwendung zu ermöglichen, wird auf dem NWL ein TCP/IP-Protokoll-

Stack implementiert. Für das Empfangen der beiden Netzwerknachrichten

DPnet und VC3 müssen an der Mikrocontroller-Hardware mechanische

Erweiterungen erfolgen. Dabei erfolgt das Einlesen der

Netzwerknachrichten parallel über entsprechende Routinen der NWL-

Anwendung.

Für die Client-Anwendung ist eine Benutzeroberfläche gedacht, in der die

aufgezeichneten Netzwerknachrichten tabellarisch dargestellt werden.

Zusätzlich soll über die Benutzeroberfläche eine Parametrierung des

Aufzeichnungs- und Auswertesystems möglich sein. Die Aufzeichnung

muss unterbrechungsfrei ablaufen. Des Weiteren soll jede aufgezeichnete


7

Nachricht einen Zeitstempel bekommen. Für weitere Details siehe

nachfolgenden Abschnitt.

Anforderung an das System

8

2 Anforderung an das System

2.1 Grundanforderung

Die Grundanforderungen an das Aufzeichnungs- und Auswertesystem sind

die Aufzeichnung und Auswertung von Nachrichten aus den beiden

firmeninternen Netzwerken DPnet und VC3. Beide Kanäle müssen

gleichzeitig gelesen werden können, und es dürfen keine Nachrichten

verloren gehen. Die Aufzeichnungsparameter müssen einstellbar sein und

die Aufzeichnungszeit darf nicht eingeschränkt werden.

2.2 Musskriterien

Die aus den Grundanforderungen resultierenden Musskriterien sind in

Tabelle 1 aufgeführt.

Tabelle 1 Die Musskriterien, die das Endprodukt leistet.

Grundanforderung Paralleles Einlesen der Netzwerknachrichten, das notwendig ist, da ein paralleler Betrieb der beiden Netzwerke VC3 und DPnet möglich ist. Kommunikation mit dem PC-Aufzeichnungsprogramm erfolgt über die Ethernet-Schnittstelle. Dieses Kommunikationsmedium bietet im Falle der Reichweite erhebliche Vorteile (bei 10Mbit/s über UTP-Kabel bis zu 100 Meter). Des Weiteren ist Ethernet sehr stark verbreitet und auch auf Laptops vorhanden. Keine Begrenzung der Aufzeichnungszeit. Die Aufzeichnung ist nur abhängig von der Größe des benutzten Datenträgers. Es darf keine Nachricht verloren gehen, und es muss eine kontinuierliche Aufzeichnung der Nachrichten möglich sein, die nicht von Speichervorgängen auf dem PC unterbrochen werden darf. Interfunktion mit anderen Programmen und Werkzeugen ist möglich. Unterschiedlich konfigurierbare Aufzeichnungseinstellungen. Die Formate der Aufzeichnung müssen kompatibel zu bestehenden Werkzeugen sein. Aktivieren von digitalen Ausgängen bei unvollständigen Nachrichten zur erweiterten Analyse durch weitere Messhilfsmittel. Quelle: Pflichtenheft Aufzeichnungs- und Auswertesystem für ein Feldbussystems

Anforderung an das System

9

2.3 Wunschkriterien

Als langfristiger optionaler Ausbau ist die Entwicklung der Hardware-

Komponenten (Mikrocontroller mit Netzwerkadaptern für das DPnet- und

VC3 Netzwerk) auf einer speziell dafür entwickelten Leiterkarte vorgesehen.

Bei der Entwicklung der Leiterkarte sollten Möglichkeiten der

Fernsteuerung der Aufzeichnung über digitale Kanäle ermöglicht sowie eine

Erweiterung für die Messung digitaler Pegel eingebaut werden. Eine weitere

Funktion stellt das Versehen der empfangenen Nachrichten mit einem

Zeitstempel durch den Mikrocontroller und den PC dar.

Verwendete Entwicklungsumgebungen

10

3 Verwendete Entwicklungsumgebungen

3.1 Metrowerks CodeWarrior

Dem Mikrocontroller MC 9S12NE64 ist eine RAD(Rapid Application

Development = schnelle Anwendungsentwicklung)-

Entwicklungsumgebung, der CodeWarrior, der Firma Metrowerks beigelegt.

Diese Entwicklungsumgebung bietet eine komfortable Möglichkeit, die

zugehörige Embedded-Komponente (die HCS12 MCU) in Assembler,

ANSI - C bzw. -C++ zu programmieren. Eine Debug-Funktionalität wird

ebenfalls bereitgestellt. Das Debugging kann in einer simulierten Umgebung

oder direkt auf der Embedded-Komponente ablaufen, dabei entspricht der

kleinste Debug-Schritt einem Assembler-Befehl. Die Hardware-Umgebung

umfasst unter anderem die Hauptplatine, den Prozessor und die Ein- /

Ausgabeeinheiten. Die RAD-Funktionalität wird mit dem Plugin Processor Expert geboten. Dieses Plugin ermöglicht mit speziell für den

Zielprozessor entwickelten Komponenten, genannt Embedded Beans,

eine Softwareentwicklung, wie sie aus der OOP (Objektorientierte

Programmierung) bekannt ist. Eine Komponente kapselt Grundelemente

der Hardware wie z. B. den MCU-Kern oder die auf der MCU befindliche

Peripherie. Diese kann dann über den Bean Inspector; eine

Benutzeroberfläche für die einfache Parametrierung und Programmierung

der Komponente, eingestellt werden.

3.2 Borland C++ Builder 6

Für die Entwicklung der Client Software in C++ wurde die

Entwicklungsumgebung Borland C++ Builder 6 verwendet.

Die Firma Borland Software Corporation bietet mit ihrer RAD-

Entwicklungsumgebung, dem C++ Builder 6, ein Werkzeug für die

Anwendungsentwicklung in C++. Der C++ Builder 6 unterstützt den

Anwendungsentwickler vom Anwendungsentwurf bis zur Fehlerbeseitigung

(Debugging).

Bei der Anwendungserstellung kommen fertige Komponenten zum Einsatz,

wobei zwischen visuellen und nicht visuellen Komponenten unterschieden

Verwendete Entwicklungsumgebungen

11

wird. Mit visuellen Komponenten wie z. B. Schaltflächen,

Eingabeelementen oder Listen werden Benutzeroberflächen erstellt. Die

nicht visuellen Komponenten kapseln Funktionalitäten wie z. B. eine

Datenbankverbindung oder ein Druckerdialog. Die Einstellung der

Komponenten erfolgt über den Objektinspektor. Der Objektinspektor

stellt die Eigenschaften und die möglichen Ereignisse jeder einzelnen

Komponente grafisch dar und ermöglicht somit einen komfortablen Zugriff

auf diese.

3.3 Zusätzliche Werkzeuge

In der Entwicklungsphase wurden für Analyse- und Simulationszwecke

folgende Hilfswerkzeuge verwendet.

Für die Überwachung der Ethernet-Datenübertragung zwischen

Mikrocontroller und Client wurde das frei erhältliche Programm Etherreal – Network Protocol Analyzer 0.10.9 verwendet.

Um Mikrocontroller-Diagnosenachrichten via RS232-Schnittstelle

empfangen und darstellen zu können, wurde die Demoversion des

Docklight V1.6-Programms eingesetzt. Zusätzlich wurden mit diesem

Programm die seriellen VC3-Nachrichten an den Mikrocontroller

übermittelt.

Technische Grundlagen

12

4 Technische Grundlagen

4.1 Das Demonstrations Board DEMO9S12NE64

Das von Freescale Semiconductor vertriebene Demonstrations Board

DEMO9S12NE64 befindet sich in einem Kunststoffgehäuse mit RJ45

Anschluss für das Ethernet, RS232-Schnittstelle, zwei Taster (SW1 und

SW2), Schalter für „RUN/LOAD“-Modus (SW3), Reset-Taster,

Potenziometer, LEDs, einem I/O-Port für MCU-Anschlüsse und einem

Anschluss für die Spannungsversorgung (s. Abb. 2). Zusätzlich ist für die

Ethernet-Kommunikation dem Demonstrations Board ein kostenloser

TCP/IP-Stack der Firma Viola-Systems beigelegt, der einen komfortablen

Datenaustausch über das Ethernet ermöglicht.

Abbildung 2 DEMO9S12NE64 im Kunststoffgehäuse

Draufsicht auf das DEMO9S12NE64 Gehäuse.


13

4.1.1 Beschreibung der DEMO9S12NE64 Hauptplatine

In Abbildung 3 ist der Schaltplan der Hauptplatine dargestellt (eine größere

Darstellung ist im Anhang zu finden). Dieser Schaltplan gibt einen

Gesamtüberblick über die Hardware-Implementierung des

DEMO9S12NE64.

Abbildung 3 Schaltplan des DEMO9S12NE64 Boards

SPANNUNGSVERSORGUNGSPANNUNGSVERSORGUNGSPANNUNGSVERSORGUNGSPANNUNGSVERSORGUNG

RESETRESETRESETRESETTASTERTASTERTASTERTASTER

BDMBDMBDMBDM

I/O – Port

RJRJRJRJ45454545ANSCHLUSSANSCHLUSSANSCHLUSSANSCHLUSS

RS RS RSRS 232232232232

TASTER TASTER TASTER TASTER SW SW SWSW 1 111SW SW SWSW 2222

RUN RUN RUN RUN / ///LOAD LOAD LOAD LOAD

SCHALTERSCHALTERSCHALTERSCHALTER

LED LED LED LED 1 111LED LED LED LED 2222

CPUCPUCPUCPU

CPUCPUCPUCPU

CPUCPUCPUCPU

ANALOG ANALOG ANALOG ANALOG IMPUTIMPUTIMPUTIMPUT

Quelle: Freescale Semiconductor - DEMO9S12NE64_SCH_A.pdf mit eigenen grafischen

Ergänzungen

Die schwarzen Rechtecke markieren die Position der einzelnen

Komponenten mit Beschaltung im Schaltplan.


14

4.1.2 Kurze Einführung in den MC 9S12NE64

Der MC9S12NE64 stellt eine Single-Chip-Lösung (Integrierung aller

Komponenten auf einen einzigen Chip) für eine Vielzahl von

Anwendungen dar, bei der das Ethernet als Übertragungsmedium eingesetzt

werden kann. Dieser Chip integriert einen 16-Bit-HCS12-Flash-

Mikrocontroller mit 8 KByte RAM, einem 64 KByte Flash-Speicher, einen

Ethernet Physical Transceiver (EPHY), einen Ethernet Media Access

Controller (EMAC), einen Inter-IC Bus (IIC), zwei asynchrone SCI’s (Serial

Communications Interface), eine serielle SPI-Schnittstelle (Serial Peripheral

Interfaces), einen 16-Bit-Timer mit vier Kanälen, einen 10-Bit-A/D-

Wandler mit acht Kanälen und KWU-Eingänge (Keypad Wake-UP).

Zusätzlich wird von der Hardware die Debug-Funktionalität über das

Background Debug Module (BDM) und Debug Module (DBG) unterstützt.

Beim Debugging über das BDM wird ein spezielles BDM-Kabel benötigt,

das an den BDM-Anschluss des Demonstration-Boards (s. Abb. 2) und

einen Entwicklungsrechner angeschlossen wird. Das Debugging mittels

DBG erfolgt über die RS232-Schnittstelle. [1]

Auf die Module (EMAC, EPHY, SCI), die bei der Realisierung des

Produkts zum Einsatz gekommen sind, wird in den nachfolgenden

Abschnitten näher eingegangen.


15

4.1.3 Das Ethernet Physical Transceiver (EPHY) – Modul

Das EPHY-Modul entspricht dem Standard IEEE 802.3 (Ethernet Physical

Transceiver) und ist somit im ISO/OSI-Referenzmodel der Schicht 1

(Bitübertragungsschicht) zugeordnet (s. u. Abb. 10). In dieser Schicht

übernimmt es die gesamte Digital /Analog-Verschlüsselung bzw.

Entschlüsselung, die der MC9S12NE64 für die Kommunikation über das

UTP-Kabel (Unshielded Twisted Pair) benötigt. Das EPHY-Modul

unterstützt eine Übertragungsgeschwindigkeit von 10BASE-T (10Mbit/s)

und 100BASE-TX (100Mbit/s) über die UTP-Verbindung. Bei beiden

Übertragungsgeschwindigkeiten ist entweder ein Full-Duplex oder Half-

Duplex Betrieb möglich. Ist der Auto-Negotiation-Modus aktiviert, werden

die Verbindungsparameter (Full- vor Half-Duplex und größte

Übertragungsgeschwindigkeit) zwischen beiden Schnittstellen ausgehandelt.

Bei fehlender Auto-Negotiation auf Seiten der Gegenstelle erfolgt die

Ermittlung der Geschwindigkeit über Parallel Detection. Die Ermittlung

des Duplex-Modus ist mittels Parallel Detection nicht möglich, weshalb

die Duplex-Starteinstellung auf Half-Duplex eingestellt werden sollte. Die

Kommunikation zwischen EPHY und EMAC wird über das dem EMAC

zugeordnete MII (Medium Independent Interface) bewerkstelligt [1].

4.1.4 Das Medium Independent Interface (MII)

Der bidirektionale Datenaustausch zwischen EPHY und EMAC wird über

das dem EMAC zugeordnete MII bewerkstelligt, weshalb das MII mit

dem internen EPHY verbunden ist. Zusätzlich bietet das MII Zugriff auf

interne EPHY-Register. Der interessierte Leser findet weitere Details

zum MII in [1].

4.1.5 Das Ethernet Media Access Controller (EMAC) - Modul

Analog zu dem EPHY-Modul ist das EMAC-Modul eine Implementierung

des Media Access Controllers nach IEEE 802.3 und somit der Schicht 2

(Sicherungsschicht) des ISO/OSI – Referenzmodel (s. u. Abb. 10)

anzuordnen, in der es die Steuerung des Datentransfers zwischen ethernet-

fähigen Geräten auf Netzwerk-Layer-Ebene übernimmt. Darüber hinaus

leistet es MAC-Adressen-Handling (Adresserkennung und Ethertyp Filter),


16

die Aufteilung der Daten in einzelne Pakete, Datenfluss-Kontrolle und eine

Fehlererkennung. Für eingehende Daten und zu sendende Daten stehen

drei Puffer bereit. Dabei sind zwei für eingehende Daten vorgesehen. Die

Kommunikation zum EPHY-Modul erfolgt wie bereits erwähnt über das

MII. [1]

4.1.6 Konfiguration des EPHY- und EMAC-Moduls

Die Konfiguration des EPHY- und EMAC-Moduls erfolgt mittels einer von

Freescale zur Verfügung gestellten API und einer zentralen

Konfigurationsdatei, in der über Makro-Direktiven (#define) Einstellungen

getroffen werden können.

Für die Kommunikation zwischen NWL (MC9S12NE64) und Client wird

das EPHY-Modul auf 10BASE-T (10Mbit/s) Übertragungsgeschwindigkeit

im Half-Duplex-Betrieb mit deaktivierten Auto-Negotiation eingestellt.

Diese Einstellung wurde gewählt, da sie weniger Hardware-Ressourcen

beansprucht und völlig ausreichend für das Datenaufkommen zwischen

NWL und Client ist. Der Ethertyp-Filter des EMAC-Moduls wird so

konfiguriert, dass er die beiden Ethernet-Protokolltypen ARP (Address

Resolution Protocol) und IPV4 (Internet IP Version 4) akzeptiert. Diese

Filtereinstellung wurde gewählt, damit der NWL IP-Pakete und sporadische

Anfragen des Client bezüglich der MAC-Adressauflösung (ARP)

verarbeiten kann.

Bei der Adresserkennung des EMAC-Moduls wird beim Systemstart des

NWL der Promiscuous Modus aktiviert (dies geschieht außerhalb der

Konfigurationsdatei im Programm), in dem alle Hardware-Adressen vom

EMAC-Modul akzeptiert werden. Nach dem Verbindungsaufbau, der über

Broadcast abläuft, wird dieser deaktiviert und nur Ethernet Frames mit der

Hardware-Adresse (MAC-Adresse) des NWL akzeptiert (Weitere Details

zum Verbindungsaufbau in Abschnitt: 5.6 Der Verbindungsaufbau zwischen Client-Programm und Mikrocontroller (NWL)).


17

4.1.7 Das Serial-Communications-Interface(SCI)-Modul

Mit dem SCI-Modul verfügt der MC9S12NE64 über zwei asynchrone

serielle Schnittstellen. Dabei wird eine Schnittstelle, die SCI 0, beim

Demonstrations Board für die Programmierung sowie das Debugging

verwendet und steht dem Anwendungsentwickler nicht zur Verfügung.

Durch ein Zusatzmodul des SCI wird die Signalmodulation für

Infrarotverbindungen unterstützt, das aber in der Aufgabenstellung keine

Anwendung findet und somit nicht weiter erörtert wird.

Die Empfangs- und Sendeeinheiten können separat voneinander betrieben

werden. Die Kommunikation erfolgt dabei im Full-Duplex durch Interrupts

gesteuert oder durch Polling. Die freie serielle Schnittstelle SCI 1 kommt

beim Einlesen der VC3-Nachrichten und beim Senden von

Diagnosenachrichten zum Einsatz.

Um diese zu verwenden, sind eine Konfiguration (Baudrate, Wortbreite …)

der SCI 1 und einige Erweiterungen an der Hardware des

DEMO9S12NE64 Boards nötig, die im folgenden Abschnitt erläutert

werden.


18

4.1.7.1 Erweiterungen an der Hardware des DEMO9S12NE64 Boards

Wie bereits erwähnt, sind für die Verwendung der SCI 1 einige

Erweiterungen an der Hardware des Demoboards nötig. Die Erweiterung

umfasst die Verbindung der TX (PS3/TXD1) und RX (PS2/RXD1)

Anschlüsse der SCI 1-Schnittstelle mit einem externen RS 232-Stecker über

den Treiberbaustein (MAX3243). In Abbildung 4 ist eine schematische

Darstellung der durchgeführten Erweiterung dargestellt.

Abbildung 4 Schematische Darstellung der durchgeführten Erweiterung

I/O Port

CPU

MAX3243

GND

2 3

RX TX

5

5

11

Kabelverbindung

Buchse

12

18

38

40

3

Lötstellen

33

32TX

RX

Board Punktrasterkarte

RS 232 Stecker

Vom RS 232-Stecker gehen 3 Leitungen, TX, RX und GND zur

Punktrasterkarte, auf der die GND-Verbindung direkt über den I/O-Port

an den GND-Anschluss des Boards geht. Die beiden Leitungen TX und

RX gehen für eine Signalaufbereitung über die Steckbuchse an die

Anschlüsse des Treiberbausteins MAX 3243, aus dem wiederum Leitungen

zurück an die Steckbuchse gehen, von wo sie über den I/O-Port an die

zugehörigen TX- und RX-Anschlüsse des SCI 1 verbunden werden.


19

In Abbildung 5 ist das DEMO9S12NE64 Board mit erweiterter

Beschaltung für die Nutzung der SCI 1-Schnittstelle dargestellt.

Abbildung 5 DEMO9S12NE64 Board mit erweiterter Beschaltung

Nach der mechanischen Erweiterung des Demoboards ist eine

Konfiguration der SCI-Modul Register im Controller erforderlich. Dabei

wird zwischen zwei Konfigurationen der SCI 1-Schnittstelle unterschieden.

Eine kommt in der Entwicklungsphase für das Senden von

Diagnosenachrichten an den PC zum Einsatz, und die andere konfiguriert

die SCI 1-Schnittstelle für den Empfang von VC3-Nachrichten. Auf die

Konfiguration der SCI 1-Schnittstelle und die Unterschiede der einzelnen

Konfigurationen wird im nachfolgenden Abschnitt eingegangen.


20

4.1.7.2 SCI 1 Register-Konfiguration

Um die SCI 1-Schnittstelle betreiben zu können, müssen bestimmte

Einstellungen über die SCI 1-Register getroffen werden. Diese

Parametrierung betreffen u. a. die Baudrate, Parity – Einstellungen,

Wortlänge und die Aktivierung der Sende- bzw. Empfangseinheit der SCI 1.

Dazu werden folgende Register aufgeführt und im Folgenden beschrieben:

• SCI 1 Baud Rate Registers (SCI1BD) für das Setzen der Baudrate

• SCI 1 Control Register 1 (SCI1CR1) für das Setzen der Wortlänge und der Parität-Einstellungen.

• SCI 1 Control Register 2 (SCI1CR2) für das Maskieren der erforderlichen Interrupts und Aktivierung der Sende- und Empfangseinheit

• SCI 1 Status Register 1 (SCI1SR1) für das Löschen der Interrupt Flags

Das SCI1BD-Register besteht, wie in Abbildung 6 zu sehen ist, aus zwei

Registern, dem höherwertigen SCI1BDH und niederwertigen SCI1BDL-

Register. Die ersten 3 höherwertigen Bits des SCIBDH-Registers betreffen

die Parametrierung des Infrarot-Moduls, das in der Aufgabenstellung nicht

benutzt wird. Diese 3 Bits können somit auf ihren Standardwerten belassen

werden (diese Einstellung deaktiviert das Infrarot-Modul des SCI). Die

restlichen Bits (Bit 4 – Bit 0) sind zusammen mit dem gesamten SCI1BDL-

Register für die Baudrateneinstellung bestimmt.

Abbildung 6 Bit-Aufteilung des SCI Baud Rate Registers

Quelle: MC9S12NE64 Data Sheet, Rev 1.0 - Chapter 8 Serial Communications Interface (SCI)

Block Description


21

Beim Setzen der Baudrate im SCI1BD-Register (SCI1BDH + SCI1BDL)

muss der Bustakt der CPU berücksichtigt werden. Diese Abhängigkeit wird

mit der folgenden Formel beschrieben:

BaudrateBustaktSCIBD×

=16

]0:12[

Bei der Konfiguration für das Senden von Diagnosenachrichten an den PC

beträgt die Baudrate 115200 Baud, für das Empfangen von VC3-

Nachrichten hingegen 4800 Baud.

Über das SCI1CR1-Register werden, wie bereits erwähnt, die Wortlänge

und die Paritätseinstellungen vorgenommen. In Abbildung 7 sind die

einzelnen Bits des SCI1CR1 dargestellt.

Abbildung 7 Bit-Aufteilung des SCI Control Register 1


Block Description

Die erforderlichen Einstellungen betreffen das M-Bit (Data Format Mode

Bit) und das PT-Bit (Parity Type Bit). Ist das M-Bit auf 1 gesetzt, wird mit

einer Wortlänge von 9 Bit gearbeitet, was jedoch nicht wünschenswert ist,

weshalb sichergestellt werden muss, dass das M-Bit auf 0 gesetzt ist, damit

mit einer Wortlänge von 8 Bit gearbeitet wird. Beim PT-Bit muss ebenfalls

sichergestellt werden, dass dieses auf 0 gesetzt ist, was die SCI 1–

Schnittstelle mit grader Parität (Even Parity) arbeiten lässt.


22

Mit dem SCI1CR2 werden die Sende- und Empfangseinheiten sowie die

zugehörigen Interrupts maskiert. Abbildung 8 zeigt das SCI1CR2 mit den

zugehörigen Bits.

Abbildung 8 Bit-Aufteilung des SCI Control Register 2


Block Description

Für die gewünschten Konfigurationen sind das RIE-Bit (Receiver Full

Interrupt Enable Bit), TE-Bit (Transmitter Enable Bit), RE-Bit (Receiver

Enable Bit) und das RWU-Bit (Receiver Wakeup Bit) von Interesse. Auf

den restlichen Teil der SCI1CR2 Bits wird nicht weiter eingegangen, da

diese für die Funktionalität nicht verändert werden müssen und somit auf

den Standardwerten belassen werden.

Für das Senden der Diagnosenachrichten wird das TE Bit mit dem RE und

RWU Bit auf 1 gesetzt. Das Setzen des TE Bits auf 1 aktiviert die

Sendeeinheit. Mit dem zusätzlichen Setzen des RE und RWU Bits auf 1

wird die Empfangseinheit in einen Wartezustand versetzt.


23

Bei der Konfiguration des SCI 1 für den Empfang der VC3-Nachrichten

werden nur die Bits RIE und RE mit 1 maskiert. Dies aktiviert den Receiver

Full Interrupt und die Empfangseinheit für den Interrupt-gesteuerten

Empfang. Anschließend muss sichergestellt werden, dass alle Interrupt-

Flags gelöscht sind. Dazu wird das SCI1SR1 (SCI 1 Status Register 1, siehe

Abbildung 9) ausgelesen, was dazu führt, dass alle SCI Interrupt Flags

gelöscht werden.

Abbildung 9 Bit - Aufteilung des SCI Status Register 1


Block Description

Für weitere Informationen zur Parametrierung der SCI wird auf

weiterführende Literatur verwiesen [1].


24

4.2 Relevante Aspekte des ISO/OSI-Referenzmodells zum TCP/IP-Schichtmodell

Der Datentransfer zwischen NWL und Client lässt sich anhand des

hierarchisch aufgebauten ISO/OSI-Referenzmodells in einzelne

Funktionsschichten aufteilen. Dabei werden die Daten horizontal beim

Sendevorgang aus Schicht 7 bis zur Schicht 1 durchgereicht und beim

Empfangsvorgang aus Schicht 1 bis zur Schicht 7 hochgereicht (s. Abb. 10),

wobei jede Schicht bestimmte Aufgaben erfüllt (z. B. in Schicht 2 die

Fehlererkennung).

Um auf den funktionellen Ablauf des Datentransfers ausführlicher eingehen

zu können, wird ein Bezug auf das TCP/IP-Schichtenmodell genommen,

da dieses auf die verwendeten Internet-Protokolle eingeht.

Der Datentransfer erfolgt analog zum ISO/OSI-Referenzmodell, bei dem

die Daten bei Sendevorgang von der obersten Schicht 4

(Anwendungsschicht ) bis zur Schicht 1 (Netzwerkschicht) durchgereicht

werden. Beim Empfangsvorgang entsprechend umgekehrt, von Schicht 1

hoch zur Schicht 4.

Die NWL-Applikation befindet sich in der Anwendungsschicht, in der die

Netzwerkinfrastruktur für den Austausch der anwendungsspezifischen

Daten (Kommandos, Parameter …) genutzt wird. Die

anwendungsspezifischen Daten werden der darunterliegenden Schicht 3

(Transportschicht) übergeben, in der wiederum das UDP (User Datagram

Protocol) zum Einsatz kommt. In dieser Schicht werden den Nutzdaten

u. a. Informationen über den Sender und Empfänger-Port angefügt und an

die Internetschicht übergeben. Das IP (Internet-Protocol) der

Internetschicht ergänzt das UDP-Datenpaket u. a. mit den logischen

Adressen (den IP-Adressen) des Senders und Empfängers sowie

Informationen über das mitgeführte Protokoll, in diesem Fall UDP. Das

ARP (Address Resolution Protocol) das ebenfalls der Internetschicht

zugeordnet wird, dient der Adressumsetzung zwischen IP- und

Geräteadressen (MAC-Adresse) und kommt bei sporadischen ARP-

Anfragen seitens des Clients auf dem NWL zum Einsatz.


25

Das fertige IP-Paket wird aus der Internetschicht der Netzwerkschicht

übergeben. Der Aufgabenbereich des Ethernet-Controllers ist im ISO/OSI-

Referenzmodell in die beiden Schichten Sicherungsschicht und

Bitübertragungsschicht aufgeteilt und erlaubt eine detailliertere

Aufgabenzuteilung als beim TCP/IP-Schichtenmodell.

Das EMAC-Modul stellt die Hardware-Implementierung der

Sicherungsschicht dar . Hier wird das IP-Paket in einen Ethernet Frame mit

u. a. Hardware-Adresse (MAC-Adresse) des Senders und Empfängers

verpackt, wobei der CSMA/CD(Carrier Sense Multiple Access with

Collision Detection)-Algorithmus den Netzwerkzugang für die

Übermittlung der Daten steuert. Dieser Frame wird mit berechneter CRC-

Prüfsumme über das MII an die EPHY-Modul der Hardware-

Implementierung der Bitübertragungsschicht übergeben. Dieses überträgt

die Daten, indem es diese in ein analoges Signal umwandelt und auf das

Übertragungsmedium legt.

Die obige Beschreibung soll keine ausführliche Darstellung der

Kommunikation zwischen NWL und Client sein, es soll eher der

prinzipielle Kommunikationsvorgang beschrieben werden. Eine

detailliertere Beschreibung der einzelnen Schichten und Protokolle kann der

Literatur [2] entnommen werden.


26

Abbildung 10 ISO/OSI-Referenzmodell in Bezug auf das TCP/IP-Schichtmodell

EMAC

EPHY

MII

NWL - Applikation


27

4.3 Das serielle VC3-Netzwerk

Im VC3-Netzwerk werden die einzelnen Bits seriell mit einem TTL-Signal

im Full Duplex Mode übermittelt. Eine Nachricht besteht aus maximal 254

Zeichen, die mit 8 Bit kodiert sind. Der Anfang und das Ende einer

Nachricht wird mit einem Delimiter-Zeichen markiert (s. Abb. 11).

Abbildung 11 VC3 Nachricht

Die Fehlererkennung erfolgt, indem ein Echo jedes empfangenen Zeichens

vom Empfänger zurück an den Sender geschickt wird. Ist das Echo

fehlerhaft, so wird das Zeichen vom Sender wiederholt verschickt.

4.4 Das LON-Netzwerk / DPnet-Netzwerk

Das LON-Netzwerk entspricht dem DPnet-Netzwerk der Firma

WestfaliaSurge und basiert auf dem LonTalk-Protokoll der Firma Echelon.

Um eine LON-Nachricht interpretieren zu können, ist die Kenntnis über

die Bedeutung der einzelnen Bits unerlässlich. Dieser Abschnitt beschäftigt

sich mit dem Aufbau und der Klassifizierung der einzelnen LON-

Nachrichten.

Bei der Übermittlung werden die Daten an den LonTalk-Protokollstapel

übergeben, wobei der dabei erstellte LonTalk-Paketrahmen mit der

Differenzial-Manchester-Codierung kodiert wird und folgenden Aufbau hat

(s. Abb. 12).

Abbildung 12 LonTalk-Paketrahmen

Bus - Idle Bus - Arbitration Präambel111111111111

Startbit0

Format + Adresse Daten CRC CVSchicht 2

Header

NPDU

Quelle: Dietmar Dietrich, Dietmar Loy, Hans-Jörg Schweinzer (Hrsg) (1999): LON-

Technologie „Verteilte Systeme in der Anwendung“ 2. Auflage. Verlagsname: Hüthig


28

Nach erfolgreicher Busarbitrierung wird eine Präambel, bestehend aus

mehrmaligen logischen 1, gefolgt von einem Startbit logisch 0, ausgesendet,

um die Bitsychronisierung herzustellen. Nach dem Startbit folgen

Informationen zum Schicht-2-Header, der NPDU (Network Protocol Data

Unit) mit Informationen zum Rahmeninhalt, Adressinformationen sowie

den Nutzdaten selbst. Die NDPU wird von einem 16-bit-CRC, der über

den Schicht-2-Header und die NPDU gebildet wird, gefolgt. Eine

abschließende Code Violation (CV), die die Differenzial-Manchester-Regel

verletzt, zeigt das Rahmenende an.

4.4.1 Der Schicht-2-Header

Der Schicht-2-Header besteht aus insgesamt 8 Bit und beinhaltet das

Priority-Bit, das Alternate Path Bit und das Delta Backlog (6 Bit)

(s. Abb. 13).

Abbildung 13 Aufbau des Schicht-2-Header

P rio rity – B it A lte rna te P a th B it D e lta – B ack log

1 1 6

Quelle: Dietmar Dietrich, Dietmar Loy, Hans – Jörg Schweinzer (Hrsg) (1999): LON –


Das Priority-Bit gibt die Priorität des Paketrahmens an. Mit dem Alternate Path Bit kann bei erfolgloser Kommunikation auf einen alternativen Kanal

ausgewichen werden. Das Delta Backlog gibt an, mit welchem

Netzwerkverkehr zu rechnen ist.


29

4.4.2 Aufbau der NPDU

Die NPDU enthält unter anderem die Nutzdaten sowie Informationen über

deren Format und Adresse. Wie in Abb. 14 zu sehen ist, wird mit den ersten

8 Bit der NPDU das Format der nachfolgenden Daten beschrieben.

Abbildung 14 Aufbau der NPDU

Protokoll Version

Format PDU

Format Adresse

Länge Domain - ID Adresse Domain - ID PDU

2 2 2 2

0/8/24/4800



Die Version des LonTalk wird in den ersten zwei Bit kodiert und ist derzeit

0. Mit zwei weiteren Bit wird einer der vier möglichen PDU (Protocol Data

Unit) - Typen kodiert (weitere Informationen ab Abschnitt 4.4.4 Das PDU-Format). Diese zwei Bit legen fest, wie der PDU-Teil der NPDU

interpretiert werden muss. Nach dem PDU-Format kommt das zwei Bit

breite Adressformat. Hier werden 4 unterschiedliche Adresstypen kodiert,

wobei insgesamt 5 Adressformate möglich sind (weitere Informationen ab

Abschnitt 4.4.3 Der Adressaufbau). Die Länge der Domain-ID ist

ebenfalls mit zwei Bit kodiert, wobei 4 Längen möglich sind, 0 Bit breit -

keine Domain – ID, 8 Bit breite Domain-ID, 24 Bit breite Domain-ID und

48 Bit breite Domain- ID (Für die Kodierung der Domain-ID-Länge siehe

Abb. 15).


30

4.4.3 Der Adressaufbau

Der genaue Adressaufbau ist in der NPDU über zwei Bit kodiert (s. Tab. 2.)

Tabelle 2 Mögliche NPDU-Adresstypen

Typ Kodierung Adressformat Logische Adresskomponenten #0 00 Broadcast Domain, SourceSub-Node,

destSubnet = 0 #0 00 Broadcast Domain, SourceSub-Node, destSubnet #1 01 Multicast Domain, SourceSub-Node, destGroup #2a 10 Unicast Domain, SourceSub-Node, destSub - Node #2b 10 Mulicast Domain, SourceSub-Node, destSub – Node, Group,

Group Member #3 11 Unicast Domain, SourceSub-Node, destSub, Neuron - ID



Für die Beschreibung der logischen Adresskomponenten siehe Literatur [3].Das Adressformat ergibt sich aus der Kodierung des Adresstyps und dem

neunten Bit des Adressfeldes der NPDU, Abbildung 15 illustriert den

Adressaufbau.

Abbildung 15 Aufbau der Adresstypen

Quelle: Dietmar Dietrich, Dietmar Loy, Hans – Jörg Schweinzer (Hrsg) (1999): LON-



31

4.4.4 Das PDU-Format

In der NPDU werden 4 mögliche PDU-Formate im Feld Format PDU

über Bit 5 und Bit 4 (s. o. Abb. 14) kodiert. In Tabelle 3 sind zu den PDU-

Formaten die zugehörigen Kodierungen aufgeführt.

Tabelle 3 Kodierung der PDU-Formate im NPDU-Header

Bit 5 Bit 4 PDU-Format 0 0 TPDU 0 1 SPDU 1 0 AuthPDU 1 1 APDU



Da die Aufgabenstellung sich auf die Interpretierung der einzelnen Bits

beschränkt, wird auf den Aufbau und die Bedeutung der einzelnen PDU-

Formate in den folgenden Abschnitten kurz eingegangen. Für detailliertere

Informationen zu den einzelnen Bits siehe Literatur [3].

4.4.5 Aufbau der Transport Protocol Data Unit (TPDU)

Bei der TPDU wird zwischen 5 verschiedenen Typen unterschieden, die

über das Feld Typ TPDU mit 3 Bit kodiert werden (s. Abb. 16)

Abbildung 16 Aufbau der TPDU

Authentication Bit Typ TPDU Transaktions-

nummer MitgliederlisteLängeReminder/Message (5)

Reminder (4)

1 3 4

APDU

MitgliederlisteLänge

-

APDU

APDU

ACK (2)

UnACKD_RPT (1)

ACKD (0)

24/32/40/48/56/648

0/8/168

0



Mit dem Authentication Bit wird bei TPDUs sowie SPDUs das

Datenpaket für eine Authentisierung gekennzeichnet. Dabei kann der


32

Empfänger den Sender auffordern, das zuvor gesendete Datenpaket zu

bestätigen. Da dieser Mechanismus im DPnet-Netzwerk nicht zum Einsatz

kommt, wird er im Abschnitt Die Authentication Protocol Data Unit (AuthPDU) nur kurz erörtert.

Jede TPDU wird mit einer Transaktionsnummer im Feld

Transaktionsnummer versehen. Diese wird nach jeder Übertragung

inkrementiert, außer das Datenpaket muss erneut übertragen werden.

Die folgende Aufzählung führt die einzelnen TPDU-Typen auf:

• ACKD: Die Acknowledged Message TPDU findet bei der verbindungslosen, zuverlässigen Übertragung eines Datagramms seinen Einsatz. Der Sender wartet dabei auf eine Empfangsbestätigung seitens des Empfängers. Bei Nicht- Bestätigung wird der Sendevorgang wiederholt.

• UnACKD_RPT: Die Unacknowledged-repeated Message TPDU ist mit der Acknowledged Message TPDU so weit identisch, außer dass vom Empfänger keine Bestätigung erwartet wird.

• ACK: Die Bestätigung-TPDU stellt die Empfangsbestätigung dar. Sie trägt die Transaktionsnummer des zu bestätigenden Datagramms im TPDU Header.

• Reminder: Die Erinnerung-TPDU wird bei Multicast-Transaktionen mit mindestens 16 Gruppenmitgliedern verwendet, um ausstehende Bestätigungen nachzufordern. Die Mitgliederliste enthält alle Mitglieder, die bestätigt oder noch nicht bestätigt haben. Mit einer 0 an der Stelle X wird angezeigt, dass Mitglied X noch nicht bestätigt hat. Eine 1 an der Stelle X zeigt an, dass von Mitglied X bereits eine Bestätigung eingegangen ist.

• Reminder/Message: Die Erinnerung-Message-TPDU ähnelt der Erinnerung-TPDU in der Funktionsweise. Die Unterschiede bestehen in der kleineren Anzahl von maximal 15 möglichen Mitgliedern in der Liste und der zusätzlichen APDU in einer einzigen Nachricht.


33

4.4.6 Aufbau der Session Protocol Data Unit (SPDU)

Im SPDU Header kommen wie bei der TPDU ein Authentication Bit und

eine Transaktionsnummer zum Einsatz (Beschreibung in Abschnitt 4.4.5

Aufbau der Transport Protocol Data Unit (TPDU)). Im Feld Typ SPDU werden über 3 Bit 4 mögliche SPDU-Typen kodiert (s. Abb. 17).

Dabei entsprechen die beiden Typen Reminder und Reminder/Message

dem TPDU-Algorithmus (s. o. Abschnitt 4.4.5 Aufbau der Transport Protocol Data Unit (TPDU)) und werden an dieser Stelle nicht

wiederholt aufgeführt.

Abbildung 17 Aufbau der SPDU

Authentication Bit Typ SPDU Transaktions-

nummer MitgliederlisteLängeReminder/Message (5)

Reminder (4)

1 3 4

APDU

MitgliederlisteLänge

APDU

APDU

Response (2)

Request (0)

24/32/40/48/56/648

0/8/168



Mit den SPDU-Typen Request und Response werden

anwendungsspezifische Daten über die APDU transportiert (für den

Aufbau der APDU siehe nachfolgenden Abschnitt 4.4.7 Aufbau der Application Protocol Data Unit (APDU) ).


34

4.4.7 Aufbau der Application Protocol Data Unit (APDU)

Die APDU besteht aus den Feldern Destination & Type und Data, wobei

der Inhalt von Data über Destination & Type klassifiziert wird

(s. Abbildung 18).

Abbildung 18 Aufbau der APDU

Destination & Type

8/16

1Netzwerkvariable

Daten

0...n �Die maximale APDU - Länge ist nicht definiert

d Selector1 1 14

0Application 0 Code

1 1 6

0Network Management 1 Code1 1 5

11

0Network Diagnostic 1 Code1 1 4

11

01

0Foreign Frame 1 Code1 1 4

01

01

1 = hinausgehend0 = hereinkommend



Wie in Abbildung 18 zu erkennen ist, kann die Breite des Destination & Type Feldes über das höchstwertige Bit der APDU bestimmt werden ( 1 =

16 Bit breit, 0 = 6 Bit breit).

Die nachfolgende Aufzählung führt die einzelnen APDU-Klassifizierungen

auf:

• Netzwerkvariable: Ist das höchstwertigste Bit der APDU. Auf 1 gesetzt handelt es sich um eine Netzwerkvariable, bei der das Feld Destination & Type 16 Bit umfasst. Das nachfolgende Bit kennzeichnet die Richtung der APDU (1 = hinausgehend 0 = hereinkommend) und der Selector stellt den Bezeichner der Netzwerkvariablen dar. Die Daten der Netzwerkvariablen sind im Feld Data enthalten und besitzen keine feste Länge, wobei allerdings das Datenende über das CV der NPDU gegeben ist.


35

• Application: Fängt die APDU mit der Bitkombination 0 0 an, dann handelt es sich um eine Application Message. Dem Feld Code ist der Code-Bereich von 00h–3Eh zugeteilt. Das Feld Data enthält die Daten, die zwischen Sender und Empfänger ausgetauscht werden.

• Network Management: Fängt die APDU mit der Bitkombination 0 1 1 an, dann handelt es sich um eine Network Management Message. Dem Feld Code ist der Code-Bereich von 60h–73h zugeteilt, und das Feld Data enthält die Daten.

• Network Diagnostic: Fängt die APDU mit der Bitkombination 0 1 0 1 an, dann handelt es sich um eine Network Diagnostic Message. Dem Feld Code ist der Code-Bereich von 50h–5Fh zugeteilt und das Feld Data enthält die Daten.

• Foreign Frame: Fängt die APDU mit der Bitkombination 0 1 0 0 an, dann handelt es sich um eine Foreign Message. Dem Feld Code ist der Code-Bereich von 40h–4Fh zugeteilt und das Feld Data enthält die Daten.

4.4.8 Die Authentication Protocol Data Unit (AuthPDU)

Da die AuthPDU im DPnet-Netzwerk nicht zum Einsatz kommt, wird an

dieser Stelle nur kurz auf den Mechanismus der AuthPDU eingegangen und

auf weitere Details verzichtet.

Mit der AuthPDU wird eine Möglichkeit gegeben, die Echtheit des

Netzwerkpartners durch Verwendung eines kryptografischen Schlüssels zu

bestimmen. Dazu kommen bestimmte CHALLENGE- und REPLY-Mechanismen zum Einsatz.


36

4.5 Spezielle Software-Konzepte

Dieser Abschnitt beschäftigt sich mit den Software-Konzepten, die bei der

Realisierung des Produkts zum Einsatz gekommen sind.

4.5.1 Die VCL-Bibliothek

Für die Entwicklung des Client-Programms wurde die Klassenbibliothek

VCL (Visual Component Library), die ein Bestandteil der

Entwicklungsumgebung Borland C++ Builder 6 ist, verwendet.

Die VCL besteht aus einer Menge von Objekten für die

Anwendungsentwicklung. Für die Verkürzung der Entwicklungszeit

beinhaltet die VCL zusätzlich eine Teilmenge von Komponenten.

Komponenten können zur Entwurfszeit in ein Formular (das Hauptfenster

der Anwendung ) platziert und bearbeitet werden, wobei zwischen visuellen

und nicht visuellen Komponenten unterschieden wird. Visuelle

Komponenten sind zur Laufzeit sichtbar, wie z. B. unter anderem

Eingabefelder oder Schaltflächen. Die nicht visuellen Komponenten stellen

unter anderem fertige Dialoge dar oder bieten eine komplette

Protokollfunktionalität wie z. B. die eines UDP-Clients. Diese

Implementierung von fertigen Funktionsgruppen in visuellen bzw. nicht

visuellen Komponenten begünstigt eine kürzere Entwicklungszeit.

4.5.2 Viola Systems OpenTCP TCP/IP Stack

Die Firma Viola Systems stellt mit der portablen OpenTCP TCP/IP Stack

Bibliothek Funktionen für die Implementierung eines TCP/IP Stack auf

8/16 Bit Mikrocontrollern, wie dem MC 9S12NE64, zur Verfügung. Die

Bibliothek deckt die Protokollfunktionalität der Anwendungsschicht, der

Transportschicht und der Internetschicht ab.

Aus dieser Protokollpalette wurden für die NWL-Anwendung nur die

Protokollfunktionalität des UDP, IP und ARP genutzt. Dabei beschränkt

sie die ARP-Implementierung aus Ressourcengründen nur auf den ARP-

Response. Diese wird benötigt, um auf sporadische ARP-Anfragen des


37

Client-Rechners bezüglich der Hardware-Adressauflösung antworten zu

können.

UDP wurde ausgewählt, da diese Netzwerkprotokoll-Implementierung für

die Aufgabenstellung genügt und zudem weniger Hardware-Ressourcen des

Mikrocontrollers als eine volle Implementierung des TCP beansprucht.

4.5.3 Software-Paradigmen

Um die Komplexität der Client-Software zu verringern, wurde ein Konzept

benötigt, das das Programmverhalten, bei der Interaktion mit dem NWL,

vom internen Zustand des Client-Programms abhängig macht.

Das objektorientierte Verhaltensmuster State (Zustand) ermöglicht es

einem Objekt, sein Verhalten zu ändern, wenn sich sein interner Zustand

ändert, und erfüllt somit die benötigte Anforderung.

Das Konzept des State Musters besteht aus einer abstrakten Klasse

Zustand, von der mehrere Klassen abgeleitet sind. Die abstrakte Klasse

Zustand definiert lediglich die gemeinsame Schnittstelle für alle

Unterklassen, wobei die Unterklassen das zustandsspezifische Verhalten der

Schnittstelle implementieren. Eine weitere Klasse verwaltet ein

Zustandsobjekt (ein Exemplar der Unterklasse), das die zustandsspezifische

Implementierung der Schnittstelle kapselt. Das Verwaltungsobjekt delegiert

alle zustandsspezifischen Anfragen an dieses Zustandsobjekt. Immer wenn

sich der Zustand ändert, ändert das Verwaltungsobjekt das verwendete

Zustandsobjekt.

Anhand eines Beispiels aus der Literatur soll das Konzept des State Musters

etwas konkreter veranschaulicht werden. [4]


38

Das Beispiel beschreibt die Verwendung des State Musters für die

Realisierung einer zustandsabhängigen TCP-Verbindung (s. Abbildung 19).

Abbildung 19 Beispiel zum Verhaltensmuster State

Quelle: Erich Gamma, Richerd Helm, Ralpf Johnson, John Vlissides (1996): Entwurfsmuster.

Elemente wiederverwendbarer objektorientierter Software 1. Auflage. Verlagsname: Addison Wesley

Die Klasse TCP-Verbindung, die eine Netzwerkverbindung repräsentiert,

verwaltet einen Zeiger auf die abstrakte Klasse TCPZustand. Dieser Zeiger

dient als gemeinsame Schnittstelle für die zustandsspezifischen Unterklassen

TCPEtabliert, TCPLauschend und TCPGeschlossen. Dabei werden alle

Anfragen des TCPVerbindungs-Objekts über den TCPZustand-Zeiger an

das entsprechende Zustandsobjekt delegiert.

Wenn ein TCPVerbindungs-Objekt z. B. eine Öffnen-Anfrage erhält, dann

hängt seine Antwort davon ab, ob sich die TCP-Verbindung im Etabliert-

oder Geschlossen-Zustand befindet.

Wie bereits erwähnt, wurde anhand dieses Musters das die Kommunikation

betreffende Zustandsverhalten der Client-Software implementiert. In

Abbildung 20 ist eine vereinfachte Darstellung des entstandenen

Klassendiagramms dargestellt.


39

Abbildung 20 Vereinfachtes Zustandsmuster der Client-Software

Für die Client-Software wurden, wie in Abbildung 20 zu sehen, drei

Zustände (Startup, NWL Verbunden und Aufzeichnung) implementiert.

Beim Programmstart befindet sich die Anwendung im Startup-Zustand. In

diesem wird unter anderem die Netzwerkverbindung aufgebaut und auf

Netzwerknachrichten vom NWL reagiert. Der Programmzustand wechselt

in den Zustand – NWL Verbunden, wenn eine Verbindung zum NWL

aufgebaut wird, wobei hier dem NWL die nötigen Parameter für die

Aufzeichnung übermittelt werden. In den Zustand – Aufzeichnung gelangt

das Programm, wenn die Parametrierung des NWLs abgeschlossen ist. Alle

drei Zustandklassen implementieren weitere zustandsspezifische

Funktionen, die aus Gründen des Umfangs nicht weiter beschrieben

werden.


40

4.5.4 Das Lognachrichten-Speicherkonzept

Für die Speicherung von Lognachrichten wurde auf dem Client ein

Speicherkonzept angewendet, das aus einer Ringpuffer-FIFO-Kombination

und einer dynamischen Liste für eingehende Daten besteht.

Beim Empfang einer Nachricht gelangt diese zuerst in einen Ringpuffer-

Eintrag, wobei eine dynamische FIFO eine Referenz auf diesen Eintrag hält.

Wenn kein Speichervorgang aktiv ist, wird über die FIFO-Referenz dieser

wieder aus dem Ringpuffer für eine weitere Verarbeitung geholt. Wenn es

sich bei dieser Nachricht um eine Lognachricht handelt, dann wird diese in

die Liste eingetragen und dem Benutzer angezeigt.

Bei einer bestimmten Anzahl von Lognachrichten in der Liste oder nach

Ablauf einer festgelegten Zeit werden die Nachrichten aus der Liste in eine

Datei gespeichert und die Liste geleert. Um eine Kollision der oben

erwähnten Auslösungskriterien zu vermeiden, wird über ein threadsicheres

Flag der Speicherungsvorgang abgesichert.

Bei einem laufenden Speichervorgang auf der Festplatte des PC werden neu

empfangene Nachrichten nur im Ringpuffer abgelegt, der ausreichend

dimensioniert ist, um empfangene Nachrichten für mehrere Sekunden

zwischenzuspeichern. Bei Abschluss des Speichervorgangs werden alle

zuvor empfangenen Lognachrichten aus dem Ringpuffer in die Liste

übertragen.

Dieses Konzept ermöglicht eine unterbrechungsfreie Lognachrichten-

Aufzeichnung, die nur durch den verfügbaren Speicherplatz des

verwendeten Datenträgers begrenzt wird. In Abbildung 21 ist ein

vereinfachtes Aktivitätsdiagramm dargestellt, das das Lognachrichten-

Speicherkonzept veranschaulicht.


41

Abbildung 21 Aktivitätsdiagramm zum Lognachrichten-Speicherkonzept


42

4.5.5 Das Konzept der Zeitschleifenkalibrierung

Bei der Nachrichten-Aufzeichnung werden in einer Millisekunde mehrere

Nachrichten aufgezeichnet, die mit einem Zeitstempel versehen werden.

Dabei stellte sich das Problem, dass die zur Verfügung stehende PC-

Systemzeit nur eine Zeitauflösung bis in den Millisekundenbereich bietet

und somit diese Zeitauflösung nicht ausreichend für einen Zeitstempel war.

Für dieses Problem wurde ein Konzept, die Zeitschleifenkalibrierung,

erarbeitet, das eine Zeitauflösung bis in den Mikrosekundenbereich

ermöglicht. Dabei wird die hohe Auflösung eines auf dem Mikrocontroller

befindlichen Quarz-Timers zusammen mit der Systemzeit des PC’s

kombiniert.

Bei der Zeitschleifenkalibrierung wird auf dem NWL ein aktueller Timer-

Wert, der Zeitstempel, jeder zu verschickenden Nachricht beigelegt. Das

Client-Programm speichert beim Empfang dieser Nachricht die aktuelle

Systemzeit und den Zeitstempel der Nachricht. Bei einer Wiederholung

dieses Vorgangs verfügt das Client-Programm über jeweils zwei Zeitstempel

und Systemzeiten. Aus diesen beiden Wertepaaren wird eine

Umrechnungskonstante für die Berechnung der Mikrosekunden pro

Zeitstempeleinheit errechnet. Die Güte der Umrechnungskonstante ist

dabei proportional der Differenzzeit zwischen dem ersten und zweiten

Zeitstempel. Die Konstante wird anhand der folgenden Formeln berechnet.

ldifferenzZeitstempedifferenzSystemzeitskonstanteUmrechnung

stempelErsterZeittstempelZweiterZeimzeitErsteSysteemzeitZweiteSystskonstanteUmrechnung

=

−−=

Der endgültige Zeitstempel einer Nachricht setzt sich grundsätzlich

zusammen aus der zuvor aufgezeichneten Systemzeit und einer berechneten

Zeitkomponente, die bis in den Mikrosekundenbereich reicht.


43

Die Berechnung der Zeitkomponente erfolgt aus der Zeitstempeldifferenz

und der zuvor berechneten Umrechnungskonstante. Hierfür wird die oben

erwähnte Gleichung für die Berechnung der Systemzeitdifferenz umgestellt.

ldifferenzZeitstempeskonstanteUmrechnungdifferenzSystemzeit ×=

Die Berechnung des endgültigen Zeitstempels kann somit mit der folgenden

Rechnung beschrieben werden:

erechnetdifferenzBSystemzeitSystemzeitlZeitstempeEngültiger

ldifferenzZeitstempeskonstanteUmrechnungerechnetdifferenzBSystemzeit

lZeitstempelZeitstempeldifferenzZeitstempe

lZeitstempeSystemzeit

ldifferenzZeitstempedifferenzSystemzeitskonstanteUmrechnung

lZeitstempelZeitstempeSystemzeitSystemzeitskonstanteUmrechnung

lZeitstempeSystemzeitlZeitstempeSystemzeit

+=

×=

−=

⇔=

=

−−=

⇔=⇔=

2_

2_3_

3_3_

1_2_1_2_

2_2_1_1_

Nachricht Dritte

Nachricht ZweiteNachricht Erste

Da der verwendete Timer-Quarz keine Langzeit- und Temperaturstabilität

aufweist, muss die Umrechnungskonstante in festen Intervallen neu

berechnet werden. Dazu werden dem Client in festen Intervallen so

genannte Heartbeat-Nachrichten (Heartbeat-Nachrichten werden im

späteren Verlauf näher betrachtet) mit Zeitstempel geschickt, um die

Umrechnungskonstante zu aktualisieren. Dieses Intervall ist so gewählt,

dass die Umrechnungskonstante eine ausreichende Güte für die

Zeitschleifenkalibrierung aufweist.

System-Architektur und Software-Architektur

44

5 System-Architektur und Software-Architektur

5.1 Aufgabenverteilung im Aufzeichnungs- und Auswertesystem

Dieser Abschnitt beschäftigt sich mit der geplanten und schließlich

realisierten Aufgabenverteilung von Client und Mikrocontroller (NWL).

Der NWL zeichnet Netzwerknachrichten aus den beiden Netzwerken

DPnet und VC3 auf und verschickt diese mit einem Zeitstempel an den

Client. Es ist zu erwähnen, dass die Implementierung der DPnet-

Aufzeichnung sowie das Erfassen der Zeitstempel von meinem Betreuer,

Herrn Dr. Peter Kaever, bewerkstelligt wurde.

Der Client empfängt die Nachrichten, stellt diese in einer Liste dar und

speichert diese anschließend in einer Datei ab. Des Weiteren bietet der

Client Oberflächenelemente für die Parametrierung der Ethernet-

Verbindung sowie der Aufzeichnungseinstellung.

Beim Entwurf des Aufzeichnungs- und Auswertesystems wurden folgende

Kriterien für die Aufzeichnungssteuerung aufgestellt, die das System leisten

sollte.

Eine Aufzählung der zu leistenden Kriterien für die

Aufzeichnungssteuerung:

1. Zeitgesteuerte Aufzeichnung. Hierbei wird der Start - und Stoppzeitpunkt der Aufzeichnung eingestellt.

2. Auswahl der Aufzeichnungskanäle. Es kann eingestellt werden, dass die Aufzeichnung sich auf einen Lognachrichtentyp (DPnet oder VC3) beschränkt oder dass beide Lognachrichtentypen gleichzeitig aufgezeichnet werden.

3. Aufzeichnung beim Auftreten eines externen Triggersignals am NWL.

4. Aufzeichnung beim Empfang einer unvollständigen Nachricht.

5. Untersuchung der empfangenen Netzwerknachrichten anhand bestimmter Eigenschaften, wobei diese für Netzwerknachrichten festgelegt werden können, bei der die Aufzeichnung startet und wieder beendet wird.


45

Die zeitgesteuerte Aufzeichnung sowie die Auswahl der

Aufzeichnungskanäle wurde dabei in der Client-Software implementiert.

Die letzten drei Punkte hatte die NWL-Software zu leisten. Dabei hat sich

aber während der Entwicklungsphase herausgestellt, dass Punkt 4, die

Untersuchung der empfangenen Nachrichten, zu umfassend für die NWL-

Hardware ist. Dieser Teil wurde somit der Client-Software überlassen. Dazu

werden alle aufgezeichneten Nachrichten dem Client über das Ethernet

übermittelt, der diese Auswertung durchführt, um zu entscheiden, ob es

sich um eine Startnachricht bzw. Stoppnachricht handelt.


46

5.2 Der Entwicklungsaufbau

Der Entwicklungsaufbau bestand, wie in Abbildung 22 zu sehen ist, aus

dem Entwicklungsrechner mit den beiden Entwicklungsumgebungen

Borland C++ Builder und Metrowerks CodeWarrior und dem

Demonstrations Board DEMO9S12NE64.

Für die Programmierung des Mikrocontrollers ist der Entwicklungsrechner

über ein RS 232-Kabel mit dem Mikrocontroller verbunden. Die zweite RS

232-Verbindung wurde, wie bereits erwähnt, über die Hardware-

Erweiterung am Demonstrations Board DEMO09S12NE64 realisiert.

Diese wurde während der Entwicklungsphase für die Übermittlung von

NWL-Diagnosenachrichten an den Entwicklungsrechner und zum Senden

von VC3-Nachrichten an den NWL verwendet.

Abbildung 22 Der Entwicklungsaufbau

Auf der Ethernet-Verbindung erfolgte die Kommunikation zwischen

Entwicklungsrechner mit dem Client-Programm und NWL.

Als die zweite RS 232-Schnittstelle auf dem NWL für den Empfang von

VC3-Nachrichten genutzt wurde, wurden die Diagnosenachrichten des

NWLs über das Ethernet an das Client-Programm übermittelt.


47

5.3 Die Client-Anwendung

Die Client-Anwendung besteht, wie bereits in früheren Abschnitten

erwähnt, aus einer Benutzeroberfläche für die Darstellung der

aufgezeichneten Lognachrichten sowie aus zusätzlichen

Oberflächenelementen für die Aufzeichnungsparametrierung und

-Steuerung (siehe Abb. 23)

Abbildung 23 Benutzeroberfläche der Client-Anwendung

.


48

Die Konfiguration des Aufzeichnungs- und Auswertesystems erfolgt über

ein Dialogfenster der Client-Anwendung. Dabei wird zwischen

Aufzeichnungs- und Verbindungseinstellungen unterschieden, auf die im

Nachfolgenden detaillierter eingegangen wird.

Für die Aufzeichnung können folgende Einstellungen getroffen werden:

• Zeitgesteuerte Aufzeichnung. Hierbei werden der Start- und der Stoppzeitpunkt der Aufzeichnung eingestellt.

• Aufzeichnung beim Auftreten eines externen Triggersignals am NWL.

• Aufzeichnung beim Empfang einer unvollständigen Lognachricht.

• Untersuchung der empfangenen Lognachrichten anhand bestimmter Eigenschaften, wobei diese für Lognachrichten festgelegt werden können, bei der die Aufzeichnung startet und wieder beendet wird.

• Auswahl der Aufzeichnungskanäle. Es kann eingestellt werden, dass die Aufzeichnung sich auf einen Lognachrichtentyp (DPnet oder VC3) beschränkt oder dass beide Lognachrichtentypen gleichzeitig aufgezeichnet werden.

Optional besteht die Möglichkeit die zuvor erwähnten Punkte miteinander

zu kombinieren.

Die Verbindungseinstellungen umfassen die NWL IP-Adresse, den UDP-

Port sowie die NWL-Hardware-Adresse, die beim Verbindungsaufbau dem

NWL übermittelt werden (weitere Details zum Verbindungsaufbau siehe

Abschnitt 5.7 Der Verbindungsaufbau zwischen Client-Programm und Mikrocontroller (NWL)).

Zusätzlich besteht die Möglichkeit, die zuvor getroffene

Systemkonfiguration in eine Einstellungsdatei zu sichern, um diese später

nochmals laden zu können.


49

Das Programmverhalten bei der Interaktion mit dem NWL ist, wie bereits

erwähnt, vom internen Zustand der Client-Anwendung abhängig. Dabei

wird zwischen den Programmzuständen Startup, NWL Verbunden und

Aufzeichnung unterschieden, die die Anwendung vom Programmstart bis

zur Lognachrichtenaufzeichnung durchläuft. In Abbildung 24 ist ein

vereinfachtes Zustandsdiagramm dargestellt, das die Zusammenhänge der

Programmzustände veranschaulicht.

Abbildung 24 Programmzustände der Client-Anwendung

Auf die einzelnen Programmzustände wird in den nachfolgenden

Abschnitten näher eingegangen.

5.3.1 Die Client-Anwendung im Zustand Startup

Beim Programmstart befindet sich die Anwendung im Zustand Startup, in

diesem wird davon ausgegangen, dass keine Verbindung zum NWL

aufgebaut ist und somit der NWL auf das Verbindungsaufbaukommando

der Client-Anwendung wartet. Dieser Programmzustand ist für die

Überprüfung der Netzwerkanbindung des Client-Rechners sowie der


50

Benutzereingaben erforderlich. Zusätzlich wird auf einen Sonderfall

reagiert, bei dem der NWL zuvor parametriert wurde und Nachrichten an

das Client-Programm übermittelt. Dieser Sonderfall ergibt sich, wenn das

Client-Programm nach erfolgreichem Verbindungsaufbau unsachgemäß (z.

B. Programmabsturz) beendet wurde. Wenn dieser Sonderfall eintritt, wird

vom Client-Programm ein Kommando an den NWL verschickt, das diesen

anweist, seine aktuelle Parametrierung dem Client-Programm zu

übermitteln. Beim Empfang dieser NWL-Parametrierung werden diese dem

Benutzer angezeigt. Der Benutzer kann diese Parameter für die

nachfolgende Aufzeichnung übernehmen und somit direkt in den Zustand

Aufzeichnung gelangen oder sie verwerfen. Beim Verwerfen der NWL-

Parametrierung wird dem NWL ein Reset-Kommando geschickt, das diesen

zurücksetzt und für einen erneuten Verbindungsaufbau vorbereitet. In

Abbildung 24 ist ein Zustandsdiagramm dargestellt, das den

Programmzustand Startup veranschaulicht.


51

Abbildung 25 Zustandsdiagramm zum Startup

Die Client-Anwendung gelangt in den Zustand NWL Verbunden, wenn

eine Verbindung zum NWL aufgebaut wird. Im nachfolgenden Abschnitt

wird auf den Zustand NWL Verbunden näher eingegangen.


52

5.3.2 Die Client-Anwendung im Zustand NWL Verbunden

Die Client-Anwendung gelangt in den Zustand NWL Verbunden, wenn

der Verbindungsaufbau mit dem NWL erfolgreich verläuft. Dieser

Programmzustand ist allein für die Übermittlung der NWL-

Aufzeichnungsparameter gedacht. Des Weiteren werden in diesem Zustand

mögliche Fehler behandelt.

Sobald die Client-Anwendung in diesen Zustand gelangt, werden

Aufzeichnungsparameter an den NWL geschickt. Nach erfolgreicher

Parametrierung wird in den Zustand Aufzeichnung gewechselt, ohne dass

der Benutzer etwas registriert.

Bei einem Fehlerfall während der Parametrierung verbleibt die Client -

Anwendung im Zustand NWL Verbunden. Dieser Zustand bleibet solange

erhalten, bis durch wiederholte Parametrierungsversuche durch den

Benutzer, die Parametrierung erfolgreich verläuft.

5.3.3 Die Client-Anwendung im Zustand Aufzeichnung

Wie bereits erwähnt, gelangt die Client-Anwendung direkt nach

erfolgreicher NWL-Parametrierung in den Zustand Aufzeichnung.

Dieser Programmzustand ist erforderlich, um Lognachrichten empfangen

und analysieren zu können. Dabei erfolgt die Lognachrichtenaufzeichnung

anhand der zuvor eingestellten Parameter.

Um die Aufzeichnung auszulösen, werden für den Benutzer Schaltflächen

aktiviert, mit denen die Aufzeichnung gestartet bzw. wieder gestoppt wird.

Des Weiteren wird eine weitere Schaltfläche aktiviert, mit der der NWL und

die Client-Anwendung in den Ursprungszustand versetzen werden können.

Dabei gelangt die Client-Anwendung wieder in den Zustand Startup.


53

5.4 Das Kommunikationsprinzip zwischen Client und Mikrocontroller (NWL)

Der Datenaustausch zwischen Client-Programm und NWL erfolgt über

eine Ethernet-Verbindung mit dem Netzwerkprotokoll UDP. Das dabei

verwendete Kommunikationsprinzip erfolgt über Nachrichten, die mit

einer Nachrichtenkennung versehen sind. Dabei wird zwischen fünf

Nachricht-Typen unterschieden, auf die im Folgenden eingegangen wird:

• Kommandonachrichten für die Anweisungsausführung.

• Die zu den Kommandonachrichten zugehörigen Kommandobestätigungsnachrichten

• VC3-Lognachrichten für die Übertragung der empfangenen VC3 - Nachrichten an das Client-Programm

• DPnet-Lognachrichten für die Übertragung der empfangenen DPnet-Nachrichten an das Client-Programm

• Heartbeat-Nachrichten für die Überprüfung des Verbindungsstatus zum NWL und der Zeitschleifenkalibrierung.

Die Anweisungsausführung basiert auf einem Kommando/Bestätigung-

Mechanismus. Dabei werden Kommandonachrichten mit einer bestimmten

Kennung und einer zugehörigen Kommandobestätigungsnachricht

verwendet. Die Kennung einer Kommandonachricht entspricht einem

Großbuchstaben aus dem Alphabet, z. B. A, und die der zugehörigen

Kommandobestätigungsnachricht entspricht dem Kleinbuchstaben, auf das

Beispiel bezogen a. (Für weitere Details zum Nachrichtenaufbau siehe

nachfolgenden Abschnitt: 4.4 Der Nachrichtenaufbau)

Mit den beiden Nachrichtentypen VC3-Lognachricht und DPnet-

Lognachricht werden die entsprechenden auf dem NWL empfangenen und

aufgezeichneten Netzwerknachrichten an das Client-Programm gesendet..

Heartbeat-Nachrichten werden für die Verbindungsüberprüfung periodisch

nach dem Verbindungsaufbau vom NWL an das Client-Programm

gesendet. Der Heartbeat-Nachricht wird zusätzlich ein Zeitstempel für die

Zeitschleifenkalibrierung beigefügt.

Aus Vollständigkeitsgründen muss an dieser Stelle der Nachrichtentyp

Diagnosenachricht erwähnt werden, der für die Auswertung des NWL-


54

Programmablaufs verwendet wird. Dieser wird in der Entwicklungsphase in

die Kommunikation zwischen NWL und Client-Programm eingeflochten

und bietet Möglichkeiten zur Übertragung von Debug-Informationen des

NWL.

Auf weitere Details zu den Nachrichtentypen wird im nachfolgenden

Abschnitt eingegangen.

5.5 Der Nachrichtenaufbau

Dieser Abschnitt beschäftigt sich näher mit dem Aufbau der zuvor

erwähnten Nachrichtentypen.

Alle erwähnten Nachrichtentypen bestehen aus mehreren Zeichen, die mit

8 Bit kodiert werden. Jede Nachricht fängt grundsätzlich mit einem Zeichen

für die Nachrichtenkennung an, über die der Empfänger (NWL oder Client-

Programm) die Nachricht zuordnen kann. Die Nachrichtenkennung wird

von einem Rautezeichen # oder direkt vom Datenteil der Nachricht gefolgt.

Das Nachrichtenende wird von keinen, einem oder zwei aufeinander

folgenden Rautezeichen markiert.

Der große Unterschied im Aufbau der im Folgenden beschriebenen

Nachrichtentypen ist durch die Art der Einbettung von Daten in eine

Nachricht begründet, die am Anfang der Entwicklungszeit verwendet

wurde.


55

5.5.1 Aufbau von Kommandonachrichten

Kommandonachrichten werden vom Client-Programm für die

Übermittlung von Anweisungen an den NWL eingesetzt. Dabei wird

zwischen Kommandonachrichten mit Datenteil und

Kommandonachrichten ohne Datenteil unterschieden.

Kommandonachrichten mit Datenteil enthalten Daten, die der NWL für die

Ausführung der Anweisung benötigt. Kommandonachrichten ohne

Datenteil werden wiederum bei Anweisungen verwendet, bei denen keine

zusätzlichen Daten benötigt werden.

Dem NWL werden vom Client-Programm folgende Anweisungen in Form

einer Kommandonachricht gesendet.

• Verbindungsaufbau

• Aufzeichnungsparametrierung

• Aufzeichnungsstart

• Aufzeichnungsstopp

• NWL-Reset

• NWL-Parameteranforderung

In Abbildung 26 ist der Aufbau der Kommandonachricht für den

Verbindungsaufbau dargestellt.

Abbildung 26 Kommandonachricht für den Verbindungsaufbau

Diese Kommandonachricht besitzt als Nachrichtenkennung ein A und

kapselt für die Ausführung des Verbindungsaufbaus die Angaben zum

UDP-Port, die neue NWL IP-Adresse, die neue NWL MAC-Adresse sowie

Informationen über die verwendete Systemversion des Client-Programms.

Diese Daten werden durch Rautezeichen getrennt, damit der NWL beim

Auslesen der Daten diese zuordnen kann. Das Nachrichtenende wird durch

zwei aufeinander folgende Rautezeichen markiert. Zu erwähnen ist, dass die


56

IP- und MAC-Daten für den Versand in ein 8-Bit-konformes Format

umgewandelt werden.

Für die Übermittlung der Aufzeichnungsparameter wird eine

Kommandonachricht mit der Nachrichtenkennung B verwendet, deren

Aufbau in Abbildung 27 dargestellt ist.

Abbildung 27 Kommandonachricht für Aufzeichnungsparametrierung

Die Kommandonachricht kapselt die folgenden Aufzeichnungsparameter:

die VC3-Netzwerkbaudrate, das Triggerflag für die Aufzeichnungsauslösung

beim Auftreten eines externen Triggersignals und das VC3-Nachrichten-

Trennzeichen. Dabei werden die Datenfelder mit einem Rautezeichen

voneinander getrennt. Das Nachrichtenende wird ebenfalls mit zwei

aufeinander folgenden Rautezeichen markiert.


57

Die Kommandonachrichten für die Anweisungen Aufzeichnungsstart,

Aufzeichnungsstopp, NWL-Reset und NWL-Parameteranforderung

besitzen kein Datenteil. Durch diese Eigenschaft haben diese vier

Kommandonachrichten einen gleichen Aufbau, der sich nur im Inhalt der

verwendeten Kommandokennung unterscheidet. In Abbildung 28 sind die

vier Kommandonachrichten dargestellt.

Abbildung 28 Kommandonachrichten ohne Datenteil

Wie in Abbildung 28 zu sehen, bestehen diese Kommandonachrichten aus

der Kommandokennung, zwei aufeinander folgenden Rautezeichen und

einer Zeichenkette, die eine Bezeichnung der Kommandonachricht

darstellt. Dieser Nachrichtenaufbau stellt einen Sonderfall dar, da für die

Auswertung der Kommandonachricht der NWL nur die

Nachrichtenkennung benötigt und der restliche Nachrichtenteil verworfen

wird. Dieser zusätzliche Teil stammt aus der Entwicklungsphase, in der es

wichtig war, die einzelnen UDP-Nachrichten im Etherreal Protokoll besser

lesbar zu machen.


58

5.5.2 Aufbau von Kommandobestätigungsnachrichten

Wie bereits kurz erwähnt, wird der Empfang von Kommandonachrichten

vom NWL mittels der zugehörigen Kommandobestätigungsnachricht

bestätigt. Diese besitzt als Nachrichtenkennung den Kleinbuchstaben der

Kommandonachrichtenkennung. Der Datenteil der

Kommandobestätigungsnachricht enthält einen Zeitstempel für die

Zeitschleifenkalibrierung.

In Abbildung 29 sind die Kommandobestätigungsnachrichten mit

Zeitstempel dargestellt.

Abbildung 29 Kommandobestätigungsnachrichten mit Zeitstempel


59

Ein Sonderfall stellt die Kommandobestätigungsnachricht dar, die

verwendet wird, wenn eine Kommandonachricht für die NWL-

Parameteranforderung empfangen wird. Sie enthält im Datenteil zusätzlich

die Aufzeichnungsparameter des NWLs. Diese sind das Triggerflag für die

externe Aufzeichnungsauslösung, das VC3-Nachrichtentrennzeichen

(Delimiter), die NWL-IP-Adresse, der UDP-Port, die NWL-MAC-Adresse,

die VC3-Baudrate und der Zeitstempel für die Zeitschleifenkalibrierung. In

Abbildung 30 ist der Aufbau der Kommandobestätigungsnachricht

dargestellt.

Abbildung 30 Kommandobestätigungsnachricht für die NWL-Parameteranforderung

5.5.3 Aufbau von VC3-Lognachrichten

VC3-Lognachrichten werden vom NWL für die Übermittlung von zuvor

aufgezeichneten VC3-Nachrichten an das Client-Programm verwendet.

Eine VC3-Lognachricht besitzt als Nachrichtenkennung ein V. Der

Datenteil enthält die Anzahl der aufgezeichneten VC3-Bytes, die

aufgezeichneten VC3–Bytes, den Zeitstempel, Informationen zur

Vollständigkeit der VC3-Nachricht und ein Rautezeichen, das das

Nachrichtenende markiert. In Abbildung 31 ist der Aufbau der VC3-

Lognachricht dargestellt.

Abbildung 31 Aufbau der VC3-Lognachricht


60

5.5.4 Aufbau von DPnet-Lognachrichten

Der NWL verwendet DPnet-Lognachrichten, um zuvor aufgezeichnete

DPnet-Nachrichten an das Client-Programm zu übermitteln, wobei der

Aufbau der DPnet-Lognachricht ähnelt.

Eine DPnet-Lognachricht besitzt als Nachrichtenkennung ein L. Der

Datenteil enthält die Anzahl der aufgezeichneten Bytes, die aufgezeichneten

DPnet-Bytes, den Zeitstempel, Informationen zur Vollständigkeit der

DPnet-Nachricht und ein Rautezeichen, das das Nachrichtenende markiert.

In Abbildung 32 ist der Aufbau der DPnet-Lognachricht dargestellt.

Abbildung 32 Aufbau der DPnet-Lognachricht

5.5.5 Aufbau von Heartbeat-Nachrichten

Heartbeat-Nachrichten werden vom NWL nach erfolgreichem

Verbindungsaufbau zur periodischen Verbindungsüberprüfung und

Zeitschleifenkalibrierung verschickt. Dabei besitzt eine Heartbeat-Nachricht

als Nachrichtenkennung ein h. Die Nachrichtenkennung wird durch ein

Rautezeichen vom Datenteil getrennt, wobei der Datenteil einen

Zeitstempel für die Zeitschleifenkalibrierung enthält. Gefolgt wird der

Zeitstempel durch ein Rautezeichen sowie eine Zeichenkette, die eine

Bezeichnung der Nachricht darstellt.


61

Der Grund für die zusätzliche Zeichenkette ist wie bei den

Kommandobestätigungsnachrichten darin begründet, dass es zur

Entwicklungszeit wichtig war, die einzelnen UDP-Nachrichten im Etherreal

Protokoll besser lesbar zu machen. Der Aufbau der Heartbeat-Nachricht ist

in Abbildung 33 dargestellt.

Abbildung 33 Aufbau der Heartbeat-Nachricht

5.6 Der Kommando/Bestätigung-Mechanismus

Bei der Anweisungsausführung werden, wie zuvor erwähnt,

Kommandonachrichten und die zugehörigen

Kommandobestätigungsnachrichten eingesetzt. Dabei gestaltet sich die

Anweisungsausführung folgendermaßen: Das Client-Programm verschickt

eine Kommandonachricht (mit oder ohne Nutzdaten) für die Ausführung

einer bestimmten Aktion (z. B. Aufzeichnungsstart) an den NWL. Dabei

wird ein Timer aktiviert, über den periodisch der Eingang der zugehörigen

Kommandobestätigungsnachricht überprüft wird.

Beim Empfang der Kommandonachricht startet der NWL die gewünschte

Aktion und sendet an das Client-Programm eine

Kommandobestätigungsnachricht zurück.

Wenn das Client-Programm nach Ablauf einer bestimmten Zeit keine

Bestätigung über die erfolgreiche Ausführung in Form der zugehörigen

Kommandobestätigungsnachricht erhält, dann kann davon ausgegangen

werden, dass eine Störung aufgetreten ist.

Zur Illustration wird ein vereinfachtes Sequenzdiagramm genommen, das

den Ablauf des Aufzeichnungsstarts veranschaulicht (siehe Abbildung 34).


62

Abbildung 34 Vereinfachtes Sequenzdiagramm zum Aufzeichnungsstart


63

5.7 Der Verbindungsaufbau zwischen Client-Programm und Mikrocontroller (NWL)

Beim Systemstart von Client-Programm und NWL besitzt das Client-

Programm keine Angaben zur IP- und MAC-Adresse des NWLs. Die

Ethernet-Anbindung des NWL befindet sich in dieser Phase im

Promiscuous-Modus. Dieser Modus bewirkt, dass der NWL jeglichen

ankommenden Netzwerkverkehr empfängt, wozu auch Broadcast-

Nachrichten zählen.

Dieser Modus der NWL-Ethernet-Anbindung wird für den

Verbindungsaufbau genutzt. Dabei wird dem NWL an einen bekannten

UDP-Port des NWLs über Broadcast eine Kommandonachricht mit neuen

Netzwerkparametern geschickt. Zu den Netzwerkparametern gehört die

neue NWL-IP- und MAC-Adresse sowie der neue UDP-Port. Dabei wird

die neue NWL-IP-Adresse anhand des Netzwerkteils des Client-Rechners

berechnet. Dies ist erforderlich damit der NWL eine IP-Adresse aus der

gleichen Netzwerk-Domain wie der Client-Rechner besitzen. Zusätzlich

wird dem Datenteil der Kommandonachricht die Version des Client-

Programms für die Vermeidung von zukünftigen Kompatibilitätsproblemen

beigefügt.

Beim Empfang verifiziert der NWL diese Broadcast-Nachricht anhand

eines speziellen Schemas. Bei erfolgreicher Verifizierung wird die IP- und

MAC-Adresse des Client-Rechners aus der Broadcast-Nachricht ausgelesen

und die NWL-Ethernet-Schnittstelle (EMAC und EPHY) mit den neuen

Netzwerkparametern neu gestartet. Anschließend wird eine

Kommandobestätigungsnachricht an das Client-Programm über P2P (Peer

– to – Peer) verschickt. Dabei enthält die Kommandobestätigungsnachricht

den ersten für die Zeitschleifenkalibrierung benötigten Zeitstempel.


64

In Abbildung 35 ist ein Sequenzdiagramm dargestellt, das den

Verbindungsaufbau zwischen Client-Programm und NWL veranschaulicht.

Im Anhang ist eine größere Darstellung des Sequenzdiagramms zu finden.

Abbildung 35 Sequenzdiagramm zum Verbindungsaufbau


65

5.7.1 Neustart der NWL-Ethernet-Schnittstelle

Wie bereits im oberen Abschnitt erwähnt, wird für den Verbindungsaufbau

die NWL-Ethernet-Schnittstelle ( EMAC- und EPHY-Modul ) neu

gestartet. Dieser Vorgang ist nötig, um die neue Hardware-Adresse des

NWLs sowie die Adresserkennung im EMAC-Moduls neu zu setzen.

Für den Neustart der NWL-Ethernet-Schnittstelle müssen EMAC- und

EPHY-Modul zuerst in einen Reset-Zustand versetzt werden, um beide

wieder aus diesem mit der neuen Konfiguration zu starten.

Hierfür wird über das MII das interne EPHY Control Register 0

angesprochen und das EPHY Reset Bit auf 1 gesetzt. Für diesen Reset-

Vorgang darf für eine Zeitdauer von 1.3 ms über das MII kein

Datentransfer zwischen EMAC und EPHY stattfinden. Um dies zu

gewährleisten, wird das EMAC-Modul über das EMACE (EMAC Enable)-

Bit deaktiviert. Danach kann der Reset-Vorgang des EMAC-Moduls, durch

das Setzen des MACRST (MAC Software Reset)-Bits auf 1, durchgeführt

werden. Zusätzlich werden alle Interrupts gesperrt, um jegliche

Unterbrechungen beim Neustart vom EHPY- und EMAC-Modul zu

unterbinden. Durch eine anschließende Zeitschleife von 1.3 ms wird

sichergestellt, dass der Reset-Vorgang des EPHY-Moduls abgeschlossen ist.

In Abbildung 36 ist der Ablauf des Reset-Vorgangs dargestellt.


66

Abbildung 36 Reset - Vorgang der NWL-Ethernet-Schnittstelle

Der Neustart erfolgt mit der neuen Konfiguration mittels der von Freescale

zu Verfügung gestellten API.


67

5.8 Übermittlung der Aufzeichnungsparameter an den NWL

Dem NWL werden nach erfolgreichem Verbindungsaufbau vom Client-

Programm Aufzeichnungsparameter in Form einer Kommandonachricht

übermittelt. Diese Aufzeichnungsparameter beinhalten die VC3-Netzwerk

Baudrate, das VC3-Nachrichtentrennzeichen und Einstellungen für die

Aufzeichnungsauslösung beim Auftreten eines externen Triggersignals am

NWL.

Die Aufzeichnungsparametrierung des NWL läuft wie folgt ab:

Das Client-Programm sendet die Kommandonachricht mit zugehörigen

Aufzeichnungsparametern an den NWL. Dabei wird ein Timer aktiviert,

über den periodisch der Eingang der zugehörigen

Kommandobestätigungsnachricht überprüft wird.

Beim Empfang liest der NWL die Aufzeichnungsparameter aus dem

Datenteil der Kommandonachricht. Mit den VC3-Parametern wird die SCI

1-Schnittstelle für den Empfang von VC3-Nachrichten konfiguriert und die

Einstellungen für das externe Triggersignal werden übernommen. Nach

dem Setzen der neuen Konfiguration sendet der NWL eine

Kommandobestätigungsnachricht an das Client-Programm. Diese

Kommandobestätigungsnachricht trägt im Datenteil einen Zeitstempel, der

aber für die Zeitschleifenkalibrierung nicht benutzt wird, da diese eine zu

geringe Zeitstempeldifferenz zum Zeitstempel der Verbindungsaufbau-

Bestätigung aufweist.

Wenn das Client-Programm nach Ablauf einer bestimmten Zeitspanne

keine Kommandobestätigung empfängt, dann kann davon ausgegangen

werden, dass eine Störung aufgetreten ist.

In Abbildung 37 ist das zugehörige Sequenzdiagramm abgebildet, das die

Aufzeichnungsparametrierung des NWL veranschaulicht. Eine größere

Darstellung ist im Anhang zu finden.


68

Abbildung 37 Sequenzdiagramm zur NWL Aufzeichnungsparametrierung

Zu erwähnen ist, dass dem NWL vor der eigentlichen Kommunikation eine

ARP-Anfrage bezüglich der NWL-Adressauflösung vom Client-Rechner

geschickt wird, die in das Sequenzdiagramm aus Gründen des Umfangs

nicht aufgenommen wurde.


69

5.9 Die Nachrichtenaufzeichnung

Bei der Nachrichtenaufzeichnung wird zwischen der internen Aufzeichnung

des NWLs und der Aufzeichnung des Client-Programms unterschieden. Die

interne Nachrichtenaufzeichnung des NWLs umfasst den Empfang der

VC3- bzw. DPnet-Netzwerknachrichten und eine Zwischenpufferung

dieser für den Versand an das Client-Programm. Die eigentliche

Nachrichtenaufzeichnung erfolgt dabei beim Client-Programm.

Auf die Nachrichtenaufzeichnung von NWL und Client-Programm wird in

den nachfolgenden Abschnitten detaillierter eingegangen.

5.9.1 Nachrichtenaufzeichnung auf dem NWL

Die Nachrichtenaufzeichnung wird beim NWL direkt durch den Empfang

eines Startkommandos oder indirekt durch Auftreten eines externen

Triggersignals ausgelöst.

Die Nachrichtenaufzeichnung umfasst dabei wie bereits erwähnt den

Empfang der VC3- und DPnet-Nachrichten und die Zwischenpufferung

dieser.

Für die Zwischenpufferung werden Strukturenpuffer für VC3- und DPnet-

Nachrichten verwendet (siehe Abbildung 38). Diese Strukturpuffer können

jeweils zwei Nachrichten mit einer Größe von insgesamt 254 Byte sowie

zusätzliche Informationen aufnehmen.

Abbildung 38 VC3- und DPnet-Strukturpuffer


70

Diese Information umfassen für jede Nachricht die Anzahl der

aufgezeichneten Bytes, deren Vollständigkeit und eine Freigabe für die

Übermittlung an das Client-Programm.

Der Empfang von VC3-Nachrichten erfolgt über die im Abschnitt: 4.1.7

Das Serial Communications Interface (SCI)-Modul erwähnte SCI 1-

Schnittstelle. Dabei wird beim Empfang eines Zeichens eine Interrupt-

Routine der SCI 1-Schnittstelle aufgerufen. In dieser Interrupt-Routine wird

das neue Zeichen in den entsprechenden VC3-Strukturenpuffer abgelegt.

Zusätzlich wird die Anzahl der empfangenen Zeichen in diesem

inkrementiert.

Eine VC3-Nachricht ist vollständig aufgezeichnet, wenn zuvor ein

Delimiter-Zeichen (VC3-Trennzeichen) gefolgt von weiteren Zeichen und

ein abschließendes Delimiter-Zeichen empfangen wurde. Wenn die

Nachricht komplett aufgezeichnet ist, wird ein Flag in dem betreffenden

VC3-Strukturenpuffer gesetzt. Diese Flag gibt den betreffenden VC3-

Strukturenpuffer für die Übermittlung an das Client-Programm in Form

einer VC3-Lognachricht frei. Der gefüllte Strukturpuffer wird für weitere

VC3-Nachrichten nicht mehr verwendet, bis sein Inhalt an das Client-

Programm übermittelt wurde. In dieser Zeit wird der zweite Strukturpuffer

für die Aufzeichnung verwendet.

Des Weiteren kann eine VC3-Nachricht unvollständig aufgezeichnet

werden. Dieser Sonderfall ergibt sich, wenn kein anführendes bzw.

abschließendes Delimiter-Zeichen für eine VC3-Nachricht empfangen

werden konnte. In diesem Fall wird zusätzlich in dem VC3-Strukturpuffer

ein Flag gesetzt, das angibt, dass diese Nachricht unvollständig

aufgezeichnet wurde. In Abbildung 39 wird anhand eines

Aktivitätsdiagramms die VC3-Nachrichtenaufzeichnung veranschaulicht.


71

Abbildung 39 Aktivitätsdiagramm zur VC3-Nachrichtenaufzeichnung

Da die Aufzeichnung der DPnet-Nachrichten von Herrn Dr. Peter Kaever

bewerkstelligt wurde, kann an dieser Stelle nur der grundlegende Ablauf

erläutert werden.

Für die Aufzeichnung einer DPnet-Nachricht wird das Bitmuster der

NPDU abgetastet, wobei die Abtastung durch Erfassung der

Flankenwechsel und Ermittlung der Zeiten zwischen den Flanken erfolgt.

Die somit erfassten Bits werden zu Bytes verdichtet und in den DPnet-

Strukturpuffer abgelegt. Zusätzlich werden wie bei der VC3-Aufzeichnung

weitere Informationen in diesen Strukturpuffer geschrieben.


72

Bei Abschluss der Aufzeichnung wird der DPnet-Strukturpuffer für die

Übermittlung an das Client-Programm in Form einer DPnet-Lognachricht

freigegeben.

5.9.2 Nachrichtenaufzeichnung auf dem Client-Programm

Wie bereits erwähnt, wird für die Nachrichtenaufzeichnung des Client-

Programms dem NWL ein Aufzeichnungsstartkommando geschickt.

Dadurch wird die interne Aufzeichnung des NWL gestartet und der NWL

übermittelt aufgezeichnete Lognachrichten an das Client-Programm.

Das Client-Programm puffert alle empfangenen Lognachrichten in einen

Ringpuffer, aus dem diese beim inaktiven Speichervorgang wieder für eine

weitere Bearbeitung ausgelesen werden. Bei der Bearbeitung wird anhand

der Nachrichtendaten ein entsprechendes VC3- bzw. DPnet-Objekt mit den

neuen Nachrichtendaten auf dem Programm-Stack erstellt. Bei der

Erstellung wird der Nachrichten-Zeitstempel errechnet und die

Nachrichtendaten werden in ein geeignetes Datenformat gebracht, das für

die weitere Verarbeitung wichtig ist. Nach der Erstellung des Nachricht-

Objektes werden aus diesem die Nachrichtendaten in eine Liste

geschrieben.

Aus dieser Liste werden, bei Erreichen einer bestimmten Anzahl von

Listeneinträgen oder nach Ablauf einer bestimmten Zeit, alle Listeneinträge

in eine Datei geschrieben. In dieser Zeit werden alle empfangenen

Nachrichten im Ringpuffer zwischengespeichert.

5.10 Die Nachrichtenanalyse

Die Nachrichtenanalyse ist Bestandteil des Client-Programms. Dabei

werden Kriterien für Start und Stopp der internen

Lognachrichtenaufzeichnung des Client-Programms definiert, die den

Nachrichtenaufbau sowie die Nachrichtendaten umfassen.

Die Nachrichtenanalyse gestaltet sich wie folgt. Das Client-Programm

verwirft alle empfangenen Lognachrichten, bis eine Lognachricht

empfangen wird, die einem Startkriterium entspricht. Wenn dies der Fall


73

ist, werden alle nachfolgenden Lognachrichten aufgezeichnet. Diese

Aufzeichnung erfolgt so lange, bis eine Lognachricht empfangen wird, die

dem Stoppkriterium entspricht. Diese Arbeitsweise ermöglicht, aus einer

Menge von Lognachrichten lediglich eine bestimmte Teilmenge

aufzuzeichnen.

Die Nachrichtenanalyse umfasst zusätzlich die Auswertung der zusätzlichen

Nachrichteninformation, die mit jeder Lognachricht vom NWL übermittelt

werden. Diese gibt Auskunft über die Vollständigkeit der aufgezeichneten

Lognachricht. Bei dieser Option startet die interne

Lognachrichtenaufzeichnung erst beim Empfang einer unvollständigen

bzw. defekten Lognachricht.

Im den folgenden Abschnitten wird auf die Analysekriterien von VC3- und

DPnet-Lognachrichten eingegangen.

5.10.1 Analyse von VC3-Lognachrichten

Für die VC3-Lognachrichtenanalyse können VC3-Lognachrichten für Start

und Stopp der internen Lognachrichtenaufzeichnung definiert werden.

Hierfür wird für die Startnachricht und Stoppnachricht jeweils ein

Datenteilmuster definiert, das mit jeder empfangenen VC3-Lognachricht

verglichen wird, um dann die entsprechende Aktion (Aufzeichnungsstart

oder Aufzeichnungstopp) auszulösen.

Optional kann bei der VC3-Lognachrichtenanalyse nur ein

Auslösekriterium (Startnachricht bzw. Stoppnachricht) verwendet werden.

In Abbildung 40 ist der zugehörige Dialog für die VC3-

Analyseeinstellungen dargestellt.


74

Abbildung 40 Dialogfeld für VC3-Analyse

5.10.2 Analyse von DPnet-Lognachrichten

Zu erwähnen ist, dass die DPnet-Lognachrichtenanalyse noch nicht

komplett implementiert werden konnte, da sich unerwartete Probleme bei

der NPDU-Prüfsummenberechnung ergaben. Somit kann an dieser Stelle

nur die geplante DPnet-Lognachrichtenanalyse behandelt werden.

Bei der DPnet-Lognachrichtenanalyse werden ebenfalls Muster für DPnet-

Lognachrichten definiert, bei denen die interne Aufzeichnung gestartet

bzw. gestoppt wird. Dabei setzt sich ein Muster zusammen aus einer PDU-

Angabe (APDU, TDPU…), einem Adressteil und dem PDU-Datenteil. Der

Adressteil umfasst dabei Sender-/Empfänger-Node und Sender-


75

/Empfänger - Sub Node. Optional kann auch wie bei der VC3-

Lognachrichtenanalyse mit nur einem Auslösekriterium gearbeitet werden.

In Abbildung 41 ist der zugehörige Dialog für die DPnet-

Analyseeinstellungen dargestellt.

Abbildung 41 Dialogfeld für DPnet-Analyse


76

5.11 Fehlerbehandlung

Die Fehlerbehandlung umfasst folgende gelistete Punkte, wovon ein

Großteil auf dem Client-Programm erfolgt:

• Netzwerkausfall

• Fehlerhafte Parametereingabe

• Fehlerbehandlung bei der Anweisungsausführung

• Fehlerbehandlung beim Sendevorgang

• Kommunikationsausfall zwischen Client-Programm und NWL

• Kompatibilitätsprüfung von NWL- und Client-Version

Die ersten fünf Punkte werden vom Client-Programm und die

Kompatibilitätsprüfung vom NWL bewerkstelligt. Auf die einzelnen

Fehlerbehandlungsmechanismen wird in den nachfolgenden Abschnitten

detaillierter eingegangen.

5.11.1 Fehlerbehandlung auf dem Client-Programm

Auf die bereits erwähnten Fehlerbehandlungsmechanismen des Client-

Programms wird im Folgenden detaillierter eingegangen.

Bei einem Netzwerkausfall wird der Benutzer auf diesen Fehler aufmerksam

gemacht und alle netzwerkspezifischen Kommunikationswege deaktiviert,

so dass keine Befehle an den NWL übermittelt werden können. Dieser

Zustand bleibt so lange erhalten, bis das Client-Programm eine aktive

Netzwerkverbindung registriert.

Alle getroffenen Parametereinstellungen werden vom Client-Programm vor

der Übernahme auf ihre Konsistenz überprüft, und bei einer Fehleingabe

wird der Benutzer auf diese aufmerksam gemacht.

Die Fehlerbehandlung der Anweisungsausführung basiert auf dem bereits

erwähnten Kommando / Bestätigung-Mechanismus. Dabei wird nach

Kommandoversand ein Timer aktiviert, der mehrmals periodisch den

Eingang der zugehörigen Kommandobestätigungsnachricht überprüft. Bei

fehlender Kommandobestätigung wird der Benutzer auf diesen Fehler

aufmerksam gemacht, um weitere Aktionen durchzuführen.


77

Sendefehler stellen einen schweren Fehlerfall dar. Ein Sendefehler entsteht,

wenn z. B. nach erfolgreichem Verbindungsaufbau nachträglich der IP-

Netzwerkteil vom Client-Rechner geändert wird. Dies führt dazu, dass

NWL und Client-Programm unterschiedlichen Netzwerk-Domänen

zugehören und somit nicht mehr miteinander kommunizieren können.

Beim Eintreten eines Sendefehlers wird eine zugehörige Fehlermeldung

ausgegeben und das Client-Programm in den Ausgangszustand versetzt.

Die Verbindungsprüfung zwischen Client-Programm und NWL erfolgt

über die bereits erwähnten Heartbeat-Nachrichten des NWLs. Werden nach

einem erfolgreichen Verbindungsaufbau zum NWL keine Heartbeat-

Nachrichten mehr empfangen, kann davon ausgegangen werden, dass die

Kommunikation zwischen Client-Programm und NWL ausgefallen ist.

5.11.2 Fehlerbehandlung auf dem NWL

Die Fehlerbehandlung auf dem NWL beschränkt sich nur auf die

Kompatibilitätsprüfung der NWL- und Client-Version, die beim

Verbindungsaufbau auf dem NWL erfolgt. Dazu wird die NWL-Version

mit der angegebenen Client-Version aus der empfangenen

Kommandonachricht für den Verbindungsaufbau verglichen. Bei

ungleichen Versionen, d. h. Inkompatibilität, wird die

Kommandonachricht verworfen und keine

Kommandobestätigungsnachricht an das Client-Programm übermittelt.

Dies wiederum löst beim Client-Programm eine Fehlermeldung aus.

Schlussbetrachtung

78

6 Schlussbetrachtung

6.1 Bekannte Fehler und Mängel, zu lösende Probleme

Das Aufzeichnungs- und Auswertesystem befindet sich noch in der

Entwicklungsphase und wurde für eine simulierte Umgebung ausgelegt. In

dieser konnte die Kommunikation zwischen NWL und Client über das

Netzwerkprotokoll UDP bewerkstelligt werden. Dabei konnte auf der Seite

des NWL die Viola Systems OpenTCP-Bibliothek für die Implementierung

des TCP/IP-Protokollstapels eingesetzt werden. Bei der Client-Anwendung

wurden fertige Komponenten verwendet, um eine UDP-

Netzwerkschnittstelle zu realisieren.

Um das System in einer realen Umgebung zu testen, müssten zunächst die

Hardware-Schnittstellen am Mikrocontroller für das DPnet- und VC3-

Netzwerk erstellt werden.

Beim Client-Programm, das eine zentrale Rolle im Aufzeichnungs- und

Auswertesystem besitzt, konnten die Grundanforderung für die

Lognachrichtenaufzeichnung sowie Aufzeichnungsparametrierung realisiert

werden. Dabei wurde die unterbrechungsfreie Lognachrichtenaufzeichnung

in Form des bereits erwähnten Speicherkonzepts realisiert. Die

Konfiguration sowie Verwaltung der Aufzeichnungsparametrierung ist

dabei im Funktionsumfang der Client-Anwendung wieder zu finden.

Mit dem Zeitschleifenkalibrierungskonzept konnte, wie bereits in zuvor

gegangenen Abschnitten beschrieben, die Zeitauflösung des Systems

ausreichend, für die Zeitstempelvergabe, vergrößert werden.

Die Auswertungsfunktionalität, die Bestandteil der Client-Anwendung ist,

konnte nur teilweise realisiert werden. Der operative Teil beschränkt sich

nur auf die VC3-Lognachrichten.

Das Problem bei der DPnet-Lognachrichtenauswertung stellt sich bei der

Prüfsummenberechnung der aufgezeichneten NDPU. Für diese

Berechnung ist ein LON-Talk-spezifischer CRC-CCITT 16 Algorithmus

erforderlich, der noch nicht implementiert werden konnte.

Schlussbetrachtung

79

Eine Möglichkeit besteht darin, die NPDU ungeachtet der Prüfsumme auf

Plausibilität zu prüfen. Dabei würde die NDPU anhand der in früheren

Abschnitten beschriebenen Klassifizierung interpretiert. Wenn bei dieser

Interpretation keine eindeutige PDU entsteht, kann davon ausgegangen

werden, dass die NDPU fehlerhaft ist.

Die Entwicklungsumgebung Borland C++ Builder 6 zeigte in ihrer

derzeitigen Implementierung noch einige Schwächen bezüglich der

Stabilität. Selbst nach Installation der zur Verfügung gestellten Updates

konnte keine Verbesserung der Stabilität beobachtet werden.

Abbildungsverzeichnis

80

Abbildungsverzeichnis Abbildung 1 Komponenten des Aufzeichnungs- und Auswertesystems...6 Abbildung 2 DEMO9S12NE64 im Kunststoffgehäuse.............................12 Abbildung 3 Schaltplan des DEMO9S12NE64 Boards.............................13 Abbildung 4 Schematische Darstellung der durchgeführten

Erweiterung ................................................................................18 Abbildung 5 DEMO9S12NE64 Board mit erweiterter Beschaltung .......19 Abbildung 6 Bit-Aufteilung des SCI Baud Rate Registers .........................20 Abbildung 7 Bit-Aufteilung des SCI Control Register 1 ............................21 Abbildung 8 Bit-Aufteilung des SCI Control Register 2 ............................22 Abbildung 9 Bit - Aufteilung des SCI Status Register 1 .............................23 Abbildung 10 ISO/OSI-Referenzmodell in Bezug auf ................................... das TCP/IP-Schichtmodell......................................................26 Abbildung 11 VC3 Nachricht...........................................................................27 Abbildung 12 LonTalk-Paketrahmen ..............................................................27 Abbildung 13 Aufbau des Schicht-2-Header..................................................28 Abbildung 14 Aufbau der NPDU....................................................................29 Abbildung 15 Aufbau der Adresstypen...........................................................30 Abbildung 16 Aufbau der TPDU.....................................................................31 Abbildung 17 Aufbau der SPDU .....................................................................33 Abbildung 18 Aufbau der APDU ....................................................................34 Abbildung 19 Beispiel zum Verhaltensmuster State .....................................38 Abbildung 20 Vereinfachtes Zustandsmuster der Client-Software.............39 Abbildung 21 Aktivitätsdiagramm zum Lognachrichten-Speicherkonzept ...........................................41 Abbildung 22 Der Entwicklungsaufbau..........................................................46 Abbildung 23 Benutzeroberfläche der Client-Anwendung..........................47 Abbildung 24 Programmzustände der Client-Anwendung ..........................49 Abbildung 25 Zustandsdiagramm zum Startup .............................................51 Abbildung 26 Kommandonachricht für den Verbindungsaufbau ..............55 Abbildung 27 Kommandonachricht für Aufzeichnungsparametrierung ...56 Abbildung 28 Kommandonachrichten ohne Datenteil ................................57 Abbildung 29 Kommandobestätigungsnachrichten mit Zeitstempel .........58 Abbildung 30 Kommandobestätigungsnachricht für

die NWL-Parameteranforderung.............................................59 Abbildung 31 Aufbau der VC3-Lognachricht................................................59 Abbildung 32 Aufbau der DPnet-Lognachricht ............................................60 Abbildung 33 Aufbau der Heartbeat-Nachricht ............................................61 Abbildung 34 Vereinfachtes Sequenzdiagramm

zum Aufzeichnungsstart ...........................................................62 Abbildung 35 Sequenzdiagramm zum Verbindungsaufbau.........................64 Abbildung 36 Reset - Vorgang der NWL-Ethernet-Schnittstelle................66 Abbildung 37 Sequenzdiagramm zur NWL

Aufzeichnungsparametrierung.................................................68 Abbildung 38 VC3- und DPnet-Strukturpuffer.............................................69 Abbildung 39 Aktivitätsdiagramm zur VC3-Nachrichtenaufzeichnung ....71 Abbildung 40 Dialogfeld für VC3-Analyse.....................................................74 Abbildung 41 Dialogfeld für DPnet-Analyse .................................................75 Abbildung 42 Schaltplan des DEMO9S12NE Bords - groß - ...................82 Abbildung 43 Sequenzdiagramm zum Verbindungsaufbau – groß -..........83

Abbildungsverzeichnis

81

Abbildung 44 Sequenzdiagramm zur NWL Aufzeichnungsparametrierung - groß - .................................84

Anhang

82

Anhang

Abbildung 42 Schaltplan des DEMO9S12NE Bords - groß -

Quelle: Freescale Semiconductor - DEMO9S12NE64_SCH_A.pdf

Anhang

83

Abbildung 43 Sequenzdiagramm zum Verbindungsaufbau – groß -

Anhang

84

Abbildung 44 Sequenzdiagramm zur NWL Aufzeichnungsparametrierung - groß -

Literaturverzeichnis

85

Literaturverzeichnis [1] Freescale Semiconductor (2004): MC9S12NE64 Data Sheet http://www.freescale.com/files/microcontrollers/doc/data_sheet/ MC9S12NE64V1.pdf [2] Kevin Washburn, Jim Evans (1996): TCP/IP Aufbau und Betrieb eines TCP/IP – Netzes 2. Auflage Verlagsname: Addison Wesley

[3] Dietmar Dietrich, Dietmar Loy, Hans – Jörg Schweinzer (Hrsg) (1999): LON – Technologie „Verteilte Systeme in der Anwendung“ 2. Auflage

Verlagsname: Hüthig

[4]Erich Gamma, Richard Helm, Ralpf Johnson, John Vlissides (1996): Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software 1.

Auflage. Verlagsname: Addison Wesley

86

Erklärung

Ich erkläre hiermit an Eides Statt,

• dass ich die vorliegende Diplomarbeit selbstständig angefertigt,

• keine anderen als die angegebenen Quellen benutzt,

• die wörtlich oder dem Inhalt nach aus fremden Arbeiten entnommenen Stellen, bildlichen Darstellungen und dergleichen als solche genau kenntlich gemacht und

• keine unerlaubte fremde Hilfe in Anspruch genommen habe.

Ort, 14. Februar 2008

_____________________________ Sebastian Sobierajski

DIPLOMARBEIT - sobierajski.de fileDIPLOMARBEIT Aufzeichnungs- und Auswertesystem für ein...

Documents

Transcript of DIPLOMARBEIT - sobierajski.de fileDIPLOMARBEIT Aufzeichnungs- und Auswertesystem für ein...