Home

Dokument 1 - Dokumentenserverhosting der SUB

1. 52 4 3 5 Auto In Out Modus 2 22 2 20a m nn nn 52 4 4 Einlesesoftware 53 5 Realisierung des Einlesemoduls 55 5 1 WHDL Schaltwerk 55 5 1 1 MIILCOUNT_GEN Einheit 2 24 224 acd ae Aon a nal 56 5 1 2 SWAP_NIBBLES_TOPLEVEL Einheit 57 5 1 3 IIMESTAMP Einheit 2 2 2 4 222 eae era Ge e 60 5 1 4 FIFO_INTERN Einheit 2 oA are serien 62 5 1 5 FX2_STATEMACHINE Einhett 3324 3 2 442 de 24h 2 deed 63 5 1 6 ETH_USB_CONTROLPATH Einheit 66 5 2 Cypress FX2 Firmware 504255 See oe Sew Ok Oe Oe Sane Ss 68 5 3 EINIESeSOMWares sr veined ee he De De Ae 69 5 3 1 Definition einer Klasse zum Einlesen e 69 5 3 2 Realisierung der Einlesemethode 70 5 4 Verifikation mit CRC32 Prifsumme 71 6 Design des Interpretationsmoduls 72 Inhaltsverzeichnis 7 Be Ee ee a 4 5 2 ae rare 72 6 2 Design eines Konvertierungsprogramm aoaaa 73 6 2 1 Die Rohdaten e 73 6 2 2 Konvertierung der Daten mit der HybridToPcapParser Klasse 73 6 2 3 Parsen der Daten 74 6 2 4 Definition der Frameliste 75 6 2 5 Speichern der Daten mit der PcapFile Klasse 77 6 3 Design der Wireshark Dissector Plugins 78 7 Realisierung der Interpretationssoftware 79 7 1 Realisierung des Zustandsautomaten f r den HybridToPcapParser 79 7 2 Realisierung eines Wireshark Dissectors e 82 7 2 1 Auswahl des Datenbusses ooo 83 7
2. PcapHeader protolndicator int frameList PcapFrameList laeufer PcapFrameNode getG_header unsigned char pcapHeader PcapHeader last PcapFrameNode en PcapFile frameList PcapFrame neu PcapFrameNode 1 List PcapFrameList setLinkType void 1 1 PcapFrameList setFrameList frameList PcapFra getHead PcapFrameNode meList void count unsigned int setPcapHeader protolndicator void print int void void clear saveToDisk filename char void Abbildung 6 4 Klassendiagramm der Klasse PcapFile 6 Design des Interpretationsmoduls 78 6 3 Design der Wireshark Dissector Plugins F r das Design der Dissectors musste zun chst analysiert werden wie viele Protokolltypen es im hybriden Bussystem gibt Eine bersicht ber die verschiedenen Protokolltypen l sst sich bersichtlich mit Hilfe einer Baumstruktur darstellen In Abbildung 6 5 ist sie zu sehen Von dem Wurzelelement CIDS Protokolltypen schwarz gehen zwei Zweige aus die mit Top und Middle Line braun und gr n bezeichnet werden Dies sind die zwei verschiedenen Datenbusse des CIDS cIDS Protokolitypen Top Line Downstream Echtzeit Daten Nicht Echtzeit Upstream Nicht Echtzeit Daten Nicht Echtzeit Abbildung 6 5 Baumstruktur zur bersicht ber die verschiedenen Protokolltypen Von dem Top Line Knoten gehen zwei Zweige aus die zu den Knoten Upstream hellblau und Downstream dunkelblau f h
3. 3 8 Blockschaltbild zur Busankopplung mir zwei Transceivern und Verarbeitungs Block 2a ar EE 32 3 9 Prinzip eines Ethernet TAP s 43 3 2 348 23 646224444 el bed 33 3 10 Aufbau des Ethernet Controllers Yukon FE 88E8040 der Firma Marvell vgl Mae St ve sate Set ak te Ee lh a ne a emer oie ne are eo 34 4 1 Systembl cke des Einlesemoduls 204 45 4 2 Vertauschen der Nibbles durch Verarbeitsungsblock 47 4 3 Signale zur Ansteuerung des Slave FIFO vgl Cypress TRM S 172 50 4 4 ZeitverhaltendersynchronenAPI 53 4 5 Zeitverhalten der asynchronen API 54 5 1 Blockschaltbild des VHDL Schaltwerkes ETH USB 55 5 2 Zeitverhalten des MW 2 4 2 0 e ege 3 Er Se PS Oe BE 56 5 3 Simulation der MIL COUNT_GEN Einheit 56 5 4 Impulsdiagramm zur Verdeutlichung des Vertauschen der 4 bit Nibbles 57 5 5 Verworfenes Design der SWAP_NIBBLES Einheit 58 5 6 System mit Kontrollblad 2 222 See AER ee oes 59 5 7 Zustandsdiagramm der Steuerpfad Komponente der SWAP_NIBBLES Einheit 59 5 8 Aufbau der TIMESTAMP Einheit 2 2 2 0 004 60 Abbildungsverzeichnis 10 5 9 Zustandsdiagramm des Kontroll Pfads der TIME_STAMP Einheit 61 5 10 Simulationsergebnis der TIMESTAMP Einheit 62 5 11 Zustandsdiagramm der FX2_STATEMACHINE Einheit 63 5 12 Reaktion auf das Setzen des EMPTY Signals 64 5 13 Reaktion auf das FULL S
4. Die Abbildung 1 1 zeigt einige der zum CIDS geh renden Kompo nenten Director DEU Decoder Encoder Unit FAP Flight Attendant Panel Abbildung 1 1 Die Komponenten des CIDS Boarding Music engl Musik welche abgespielt wird w hrend die Passagiere einsteigen oder das Flugzeug verlassen 1 Einleitung 13 1 2 2 Die Datenbusse Middle und Top Line Der Director kommuniziert ber zwei Typen von Datenbussen mit der Elektronik Peripherie die Middle und Top Line genannt werden siehe Abbildung 1 2 Im Middle Line Datenbus werden Informationen bertragen die die Funktionen des Kabinenpersonals betreffen Eine DEU die an die Middle Line angeschlossen ist wird auch DEU B genannt Im Top Line Datenbus werden Informationen bertragen die die passagierbezogenen Funktionen be treffen Eine DEU die an die Top Line angeschlossen ist wird auch DEU A genannt Top Line Endger t Jj Endger t lj Middle Line Abbildung 1 2 Aufbau des CIDS 1 3 CIDS Protokoll Das Kommunikationsprotokoll mit dem in der Middle und Top Line Informationen ausge tauscht werden ist ein propriet res Echtzeit Protokoll Auf der physikalischen Schicht wird eine Ethernet Variante mit einer Geschwindigkeit von 10 Mbit s benutzt Das Zeitverhalten dieses Protokolls orientiert sich an der Samplingrate der Audio Daten die ber den Daten bus geschickt werden Die Samplingrate betr gt 32 kS
5. Die Schnittstelle zu diesem Slave FIFO ist vergleichbar mit der Schnittstelle eines normalen FIFOs Es gibt ein FULL und EMPTY Signal sowie das Signal SLWR mit dem dem gesteuert wird ob die Daten die am Datenbuseingang FD lt 15 0 gt anliegen in das FIFO geschrieben werden sollen Die Abbildung 4 3 zeigt die Signale CLK EE FIFOADR 1 0 FULL gt SLWR EXT FD 15 0 Master PKTEND Abbildung 4 3 Signale zur Ansteuerung des Slave FIFO vgl Cypress TRM S 172 4 Design des Einlesemoduls 51 4 3 3 Festlegen des Transfertyps Anforderungen an die bertragung Zum Festlegen des Transfertyps sind zwingende Anforderungen an die bertragung der Daten zu beachten Zusammengefasst lauten die Anforderungen e Die Daten bertragung muss fehlerfrei sein e Es muss eine garantierte Daten bertragungsrate geben e Die Datenrate muss mindestens 100 MBit s betragen Die Eigenschaften der verschiedenen Transferarten die bei USB verwendet werden k nnen wurden bereits in Kapitel 4 3 1 genannt Stellt man die Transfertypen gegen ber erh lt man folgende bersicht Control Isochron Interrupt Bulk Fehlerkorrektur Ja Ja Ja Garantierte Bandbreite max 10 max 90 max 90 Datenrate von 100MBit s BRIBE 192 MBit s 192MBit s 384MBit s Tabelle 4 1 bersicht ber die Transferarten vgl Udo Erhardt 2001 S 63 Wahl des Transferty
6. Im Fall von 100BASE TX werden geschirmte oder ungeschirmte Twisted Pair Kabel STP oder UTP der Kategorie 5 verwendet Falls das gesamte Kabel noch einmal geschirmt ist lautet die Bezeichnung S STP und S UTP Kabel Das S steht f r screened und beudeutet dass das gesamte Kabel zus tzlich von einem Drahtgeflecht umh llt ist Die Grenzfrequenz dieser Leitungen betr gt 100 MHz Der Wellenwiderstand dieser Leitungen betr gt 100 2 Die Leitungen m ssen also sender und empf ngerseitig mit 100 Q abgeschlossen werden um Reflexionen auf der Leitung zu vermeiden und Leistungsanpassung zu erreichen Die Kabel enthalten 4 Adernpaare von denen bei 100BASE TX je ein P rchen f r das Emp fangen und ein P rchen f r das Versenden verwendet wird Die weiteren Adernpaare werden bei 100BASE TX nicht genutzt ber ein Adernpaar werden die Signale differentiell bertra gen Diese Art der bertragung macht die bertragung des Signals st rungstolerant gegen ber Einwirkungen von elektromagnetischen Feldern vgl Erich Stein 2008 1 6 2 Physikalische Schicht In den drei Schichten Physical Coding Sublayer PCS Physical Medium Attachement PMA und Physical Medium Dependent PMD die in der Abbildung des OSI Schichtenmodells siehe Abbildung 1 4 zu dem Begriff PHY zusammengefasst wurden wird die bertragung des Digitalsignals im Basisband definiert Unter anderem werden die verwendeten Leitungs codierungen definiert die nun bes
7. bis das FX2_FULL Signal wieder auf 0 gesetzt wird 5 Realisierung des Einlesemoduls 66 5 1 6 ETH_USB_CONTROLPATH Einheit Dieser Systemblock dient als Kontroll Einheit f r das gesamte Schaltwerk Er verarbeitet die Statussignale FIFO_INTERN_EMPTY und FIFO_INTERN_FULL des internen FIFOs und generiert daraus das Steuersignal RESET_OUT mit dem s mtliche Systemkomponenten au er der Test Einheit MIILCOUNT_GEN bzw der wirklichen MII verbunden sind Das Ver halten des Blocks wurde mit einem Zustandsautomaten realsiert Das Zustandsdiagramm ist in Abbildung 5 14 zu sehen FIFO_INTERN_EMPTY 0 amp FIFO_INTERN_FULL 1 INIT QINT lt x 7735940 FIFO_INTERN_EMPTY 0 amp FIFO_INTERN_FULL 1 RESET_COUNTER 0 LED_RECEIVING 1 RESET_OUT 0 LED_FULL 0 RESET_COUNTER 1 LED_RECEIVING 0 RESET_OUT 0 LED_FULL 0 RESET_COUNTER 0 LED_RECEIVING 0 RESET_OUT 0 LED_FULL 1 QINT gt x 7735940 FIFO_INTERN_FULL 0 RESET_COUNTER 0 LED_RECEIVING 0 RESET_OUT 1 LED_FULL 0 RESET_COUNTER 0 LED_RECEIVING 0 RESET_OUT 0 LED_FULL 0 FIFO_INTERN_FULL 1 Abbildung 5 14 Zustandsdiagramm der ETH_USB_CONTROLPATH Einheit Um die Funktion des Automaten anschaulich zu beschreiben wird angenommen dass der Automat den Zustand RECEIVING angenommen hat In diesem Zustand ist das Signal LED RECEIVING gesetzt das bewirkt dass eine entsprechende Status LED auf dem Xilinx Board leuchtet De
8. nge 1982 Bytes e PAD Dieses Feld dient zum Auff llen eines Ethernet Frame auf eine minimale Fra mel nge Die minimale Framel nge definiert sich durch den im Standard definierten Parameter minFrameSize 512 Bits Dies ist f r die korrekte Funktion der Buszu griffssteuerung CSMA CD n tig e FCS Dieses Feld enth lt eine 4 Byte lange CRC32 Pr fsumme die von der Sendesta tion des Frame berechnet wurde Diese Pr fsumme wird ber den gesamten Framen abz glich Preambel und SFD Feld berechnet Eine exakte Berechnungsvorschrift zur Berechnung dieser CRC32 Pr fsumme ist in der Quelle IEEE 802 3 auf Seite 125 zu finden e EXTENSION Dieses Feld dient ebenfalls zum Auff llen des Frame Anders als beim PAD Feld wird das Paket hier bis zu dem Parameter slotTime aufgef llt Bei Ethernet Technologien spielt dieses Feld aber keine Rolle da die Parameter slotTime und minFrameSize hier gleich sind Bei 1 Gb Ethernet betr gt der Parameter minFrame Size 512 Bits und der Parameter slotTime 4096 Bits Hier w rde das Paket entspre chend aufgef llt werden 2 Anforderungen Der Inhalt dieses Kapitels stellt die Anforderungen an den Protokollanalysator dar Das Ka pitel ist in zwei Teile aufgeteilt Im ersten Teil werden die Anforderungen an die Hardware behandelt Im zweiten Kapitel werden die Anforderungen an die Analyse Software darge stellt 2 1 Anforderungen an die Hardware Um den Datenstro
9. Beispiel Ethernet oder WLAN gibt es eine bestimmte Zahlenkonstante Die anderen Parameter die ses Feldes k nnen in der Quelle Wireshark nachgeschlagen werden Packet Header Im Packet Header stehen Informationen zu den folgenden Daten Diese Informationen lauten e ts_sec Zeitstempel in Sekunden e ts_usec Zeitstempel in Mikrosekunden e orig_len und incl_len Anzahl der Bytes im Packet Data Feld Packet Data In diesem Feld befinden sich die Nutz Daten mit der im Packet Header an gegebenen L nge Dies sind die zu analysierenden Inhalte 6 Design des Interpretationsmoduls 73 6 2 Design eines Konvertierungsprogramm Um die Dokumentation des Konvertierungsprogramms zu strukturieren orientiert sich dieses Kapitel an dem Weg den die Daten von ihrem Zustand in Roh Form bis hin zum Speichern im pcap Format auf die Festplatte nehmen Die Quelltexte der Software sind im elektroni schen Anhang A zu finden 6 2 1 Die Rohdaten Um eine Programmierschnittstelle f r den Datenstrom mit den Rohdaten zu schaffen wurde die Klasse RawData erstellt deren Konstruktor zun chst die Roh Daten von der Festplatte einliest Als Schnittstelle zu den eingelesenen Daten gibt es die Methode unsigned char nextByte mit der ein Byte aus den Roh Daten zur ckgegeben wird w hrend der Index Z hler automatisch bei jedem Aufruf der Methode inkrementiert wird Mit der Methode unsigned char getPayload erh lt man einen Zeiger auf ein zusammenh ng
10. Die Reali sierung der Zustandsautomaten im Schaltwerk wurde nach dem Muster aus dem Lehrbuch J rgen Reichard 2009 S 235ff durchgef hrt E_RX_CLK E_RXD_OUT E_RXD_IN WR_EN_OUT E_RX_DV_IN E_RXD_OUT E RESET E_RX_DV_OUT SWAP_NIBBLES_TOPLEVEL TIME_STAMP CLK RESET_OUT F FIFO_INTERN_FULL LED_RESETING 2 FX2_IFCLK FIFO_INTERN_EMPTY LED_FULL d F FX2_SLWR RESET 2 ell FX2_DATA_OUT ETH_USB_CONTROLPATH FX2_STATEMACHINE CLK E_NRST RESET LED_RUNNING ETH_INIT Abbildung 5 1 Blockschaltbild des VHDL Schaltwerkes ETH_USB 5 Realisierung des Einlesemoduls 56 5 1 1 Mil COUNT_GEN Einheit Die Quelle des Ethernet Datenstroms ist das MII des Ethernet Transceivers Das Zeitverhal ten der f r den Empfang von Daten wichtigen Signale ist in dem Impulsdiagramm in Abbil dung 5 2 zu sehen Das Taktsignal E_RX_CLK betr gt 25 MHz Das Signal E_RXD lt 0 3 gt ist der Datenausgang des MII Das Signal E_RX_DV wird gesetzt wenn g ltige Daten an dem Datenausgang anliegen Die Signale werden bei der fallenden Flanke von E_RX_CLK generiert ERCK L NT E_RXD lt 0 3 gt ERX DV Sees Abbildung 5 2 Zeitverhalten des MII Die Einheit MIL COUNT_GEN dient dazu das Verhalten der MII des Transceivers zu simu lieren Das Simulationsergebnis der reinen Test Einheit MIILCOUNT_GEN ist in Abbildung 5 3 zu sehen Die Ausgangsdaten werden dabei durch einen Z hler generiert Es ist zu erkennen dass die 4 bit Nibbles in der Reihenfolge vertausch
11. Eier Logical Link Control MAC Media Access Control OSI gege Open Systems Interconnection PAD Padding Bits PCS siisi ips reh Physical Coding Sublayer PMA EE Physical Medium Attachement PMD mee ge Physical Medium Dependent SED AN tact Start Frame Delimiter STE Bienes Standard Template Library SIP Ian Shielded Twisted Pair TDMA Time Division Multiple Access USB evens Universal Serial Bus NR Unshielded Twisted Pair A Inhalt der CD thesis3 pdf Dieses Dokument in PDF Format HybridLogger Quelltext des erstellten Programms Einlese und Konvertiertungs Software FX2Firmware Firmware f r den Cypress FX2 Mikrocontroller JETH_USB Quelltext und kompletter synthesis report f r das VHDL Schaltwerk des Ein lesemoduls WSDissectors Quelltexte der Wireshark Dissectors D JO Om P GO MM 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 B Auszug aus synthesis report Design Summary Number of errors 0 Number of warnings 2 Logic Utilization Number of Slice Flip Flops Number of 4 input LUTs Logic Distribution Number of occupied Slices Number of Slices containing only related Number of Slices containing unrelated See NOTES below for an explanation of the effects of unrelated 367 out of 11 776 217 out of 11 776 257 out of 5 888 logic 25 logic 3 1 4 7 out of 0 out of 257 100 257 0 logic
12. GUI zu verwenden ist es n tzlich wenn es eine Methode gibt die einen Einlesevorgang durchf hrt Durch Klicken auf eine Schaltfl che wird diese Methode dann aufgerufen Durch ein Auswahlmen wird die Daten menge definiert die eingelesen werden soll Deshalb enth lt die Parameterliste der Funktion read den Parameter rxMByte ber den die Datenmenge mitgeteilt wird Mit der Funktion usp_release_interface muss die Kontrolle des Ger tes wieder an das Betriebssystem abgegeben werden Au erdem ist es vorgeschrieben die Funkti on usb_close auszuf hren um die Kommunikation mit dem USB Ger t zu schlie en Dies bernimmt der Destruktor der Klasse der automatisch aufgerufen wird wenn das Ob jekt zerst rt wird Ein Klassendiagramm der Klasse ist in Abbildung 5 15 zu sehen USBHandler rxData unsigned char instances static unsigned int rxDataSize unsigned int USBHandler USBHandler saveRxData close read in rxMByte findDevice init Abbildung 5 15 Klassendiagramm der Klasse USBHandler 5 Realisierung des Einlesemoduls 70 5 3 2 Realisierung der Einlesemethode Nun wird beschrieben wie die Einlesemethode read der Klasse USBHandler rea lisiert wurde Diese Methode liest den Datenstrom aus dem FX2 ein Die Abbildung 5 16 zeigt das Flussdiagramm f r den Einlesevorgang Wie in Kapitel 4 4 ausgearbeitet wird eine Anforderungsschlange f r den Transfer verwendet Es
13. Gesamtpuffer geschrieben werden bleibt ungenutzt usb_bulk_read Daten sind angekommen und werden abgespeichert Abbildung 4 4 Zeitverhalten der synchronen API 4 Design des Einlesemoduls 54 Asynchrone API Im Gegensatz dazu verh lt sich die asynchrone API flexibler Hier wird zun chst mit Hilfe der Funktion usb_submit_async eine Sendeaufforderung an den Treiber libusb0 sys losgeschickt 3 Danach tritt die Funktion aber nicht in den blocked Zustand ein bis die Daten eingegangen sind Es lassen sich deshalb danach noch andere Aufgaben erledigen Mit der Funktion usb_reap_async l sst sich die Sendeaufforderung abbauen und die Daten werden in den Gesamtpuffer geschrieben sobald sie angekommen sind Sendeaufforderungsschlange Um den Datenstrom kontinuierlich zu machen wurde ein Verfahren erarbeitet das mit der asynchronen API arbeitet Zu Beginn eines Einlesevorgangs werden drei Sendeaufforderun gen 3 an den Treiber geschickt Anschlie end fragt man die Sendeaufforderungen 1 ab ob sie fertig ist Dies geschieht mit Hilfe der Funktion usb_reap_async 4 Wenn der Transfer abgeschlossen ist werden die Daten gespeichert 5 Da zu Beginn der bertragung gleich drei Sendeaufforderungen losgeschickt wurden be ginnt nach dem ersten Transfer sofort der n chste Transfer 5 Der exakte Zeitpunkt zu dem der zweite Transfer beginnt konnte nicht ermittelt werden Mit Hilfe dieses Verfahrens ber l sst man d
14. Listing 7 1 Auszug aus der Definition der Klasse Stateltem Das Listing 7 2 zeigt den Automaten in der Anwendung Die Stateltem Objekte werden von einer Klasse mit dem Namen StateMachine verwaltet int StateMachine run unsigned char input help2 entspricht dem bergangszustand und help dem aktuellen Zustand help2 help gt getNextState input Ermitteln des n chsten Zustands aus dem Eingangssignal newFrame help2 gt isNewFrame Liegt ein neuer Frame vor help help2 Der aktuelle Zustand wird der n chste Zustand return newFrame Ergebnis ob ein neuer Frame vorliegt zur ckgeben Listing 7 2 Auszug aus der Definition der Klasse StateMachine 7 Realisierung der Interpretationssoftware 81 Ein Zustand wird durch die Klasse State beschrieben Die Klassenhierarchie ist in Ab bildung 7 1 zu erkennen Der Aufbau dieser Klasse ist auf das in diesem Kontext zu reali sierende Problem zugeschnitten Der Zustandsautomat ist ein reiner Moore Automat Dazu besitzt die Klasse State das Attribut newF rame das als Ausgangssignal des jeweiligen Zustands fungiert Es besitzt den Wert 1 bei der Erkennung eines neuen Frames und den Wert 0 in allen anderen Zust nden Die Klasse StateItem ist eine Vererbung der Klasse State und ihre Aufgabe wurde bereits geschildert Um eine Vielzahl von diesen Objekten zu verwalten wurde eine Ableitung der Klasse Stateltenm definiert Dies ist die Klasse StateItemNode un
15. OCTETS FRAME CHECK SEQUENCE EXTENSION LSB MSB b DM BITS TRANSMITTED gt LEFT TO RIGHT Abbildung 1 5 Aufbau eines Ethernet konformen Packets vgl IEEE 802 3 S 123 e PREAMBLE Die Pr ambel dient der Taktr ckgewinnung in der Empf ngerschaltung Die Sequenz hat die Form 101010 101010 Diese Sequenz wird sieben Mal hin tereinander zu Beginn jedes Frames gesendet e SFD Nach der Preambel wird die Sequenz 101010 101011 geschickt Nach die sem Feld beginnt definitionsm ig der Frame e DESTINATION ADDRESS SOURCE ADDRESS Dieses Feld gibt an an welchen Teil nehmer der Frame adressiert ist und von wem der Frame kommt Diese Adresse die verwendet wird wird als MAC Adresse bezeichnet Dies ist eine Hardware Adresse die jeder Ethernet Controller besitzt Einleitung 19 e LENGTH TYPE Dieses Feld kann zwei Bedeutungen haben Sie sind abh ngig von dem Wert der in dem Feld steht 1 Wenn der Wert gleich oder gr er ist als 1536 beziehungsweise hexadezimal x0600 wird dieses Feld als Typen Feld behandelt 2 Ist der Wert kleiner als 1536 wird das Feld als L ngen Feld interpretiert Es gibt an wie viele Byte das folgende Datenfeld enth lt e MAC CLIENT DATA Dieses Feld enth lt das Datenfeld Es gibt drei verschiedene Da tenfeldtypen 1 Einfache Frames maximale L nge 1500 Bytes 2 Q tagged frames maximale L nge 1504 Bytes 3 Envelope Frame maximale L
16. Programm das die Daten anschlie end visualisiert und Filter und Sortierfunktionen bereitstellt Ein weiterer Nachteil ist dass bei gro en Datenmengen die XML Datei sehr gro wird da neben den Nutzdaten viele andere Informationen zur Be schreibung der XML Datei gespeichert werden m ssen 3 Konzept 43 3 3 2 Erweiterung f r Wireshark Eine weitere Option ist die Verwendung eines existierenden Programms welches alle oder Teile der Anforderungen bereits erf llt Hier bietet es sich an das Programm Wireshark mit Plugins zu erweitern Diese Plugins werden Dissector Plugins genannt Im Folgenden wird auf die in Kapitel 3 3 genannten Bewertungskriterien eingegangen 1 Bei Wireshark k nnte man zur Visualisierung die bew hrte Anzeige der Daten verwen den Das Fenster wird dabei in drei Teile aufgeteilt Im oberen Teil werden die Frames aufgelistet Hier k nnte man die Echtzeit Frames und die Nichtechtzeit Frames diffe renziert anzeigen lassen Im mittleren Teil werden die Details eines Frames angezeigt Im unteren Teil wird der Frame in Roh Form wahlweise in Hex oder Bin r Format angezeigt 2 Zur Analyse der Daten gibt es in Wireshark Werkzeuge wie zum Beispiel Sortier und Filterfunktionen Au erdem lassen sich mit IO Graphs Statistiken ber die Daten erstellen 3 Mit Hilfe von Dissector Plugins lassen sich neue Protokolle in Wireshark integrieren Diese Plugins werden nach einem Konzept entwickelt das in der Dokume
17. Wireshark in Kenntnis zu setzten dass es diesen Dissector gibt Der Parameter dissect_hybrid_rt_top_down in der Parameterliste der Funktion create_dissector_handle ist ein Zeiger auf die Funktion die einen Frame in seine Bestandteile aufteilt Zeile 4 Die Funktion dissector_add definiert bei welcher Zahlenkonstante also bei welchem Verbindungstyp der Dissector verwendet werden soll Der Dissector f r das Protokoll der Top Line Downstream Verbindung verwendet die Zahlenkonstante WTAP_ENCAP_USER3 wie im Listing zu erkennen ist Zeile 5 void proto_reg_handoff_hybrid_nonrt void static dissector_handle_t hybrid_rt_top_down hybrid_rt_top_down create_dissector_handle dissect_hybrid_rt_top_down proto_hybrid_rt_top_down dissector_add wtap_encap WTAP_ENCAP_USER3 hybrid_rt_top_down WTAP_ENCAP USER3 Konstante siehe Datei wiretap pcap common c Listing 7 4 Ausschnitt aus der Datei packet hybrid_topline_downstream c Die Datei wiretap pcap common c beinhaltet die Auflistung aller in Wireshark verf gbaren Verbindungstypen In dieser Datei sind die Zahlenkonstanten f r die verschiedenen Daten busse des hybriden Bussystems eingetragen damit Wireshark ihnen einen bestimmen Diss ector zuordnen kann Das Listing 7 5 zeigt die Zahlenkonstanten f r die Verbindungs Typen des hybriden Bussystems 148 WTAP_ENCAP_USER1 REALTIME PROTOCOL MIDDLELINE UP AND DOWNSTREAM 149 WTAP_ENCAP_USER
18. e_rxd_out o feth_usb_test dut fifo_intern_c din 0 feth_usb_test dut fifo_intern_c wr_en 0 feth_usb_test dut fifo_intern_c rd_en o feth_usb_test dut fifo_intern_c dout P feth_usb_test dut fifo_intern_c full D feth_usb_test dut fifo_intern_c empty 1 feth_usb_test dut fx2_statemachine_c clk 0 feth_usb_test dut Fx2_statemachine_c fx2_data_in Fi feth_usb_test dut Fx2_statemachine_c fx2_full_in fi feth_usb_test dut fx2_statemachine_c empty_in 1 feth_usb_test dut fx2_statemachine_c rd_en 0 feth_usb_test dut Fx2_statemachine_c state decision_state jeth_usb_test dut fx2_statemachine_c next_state decision_state feth_usb_test dut fx2_statemachine_c fx2_Full_temp1 feth_usb_test dut Fx2_statemachine_c empty feth_usb_test dut fx2_statemachine_c fx2_slwr_temp feth_usb_test dut fx2_statemachine_c fx2_data_out CH Fong feth_usb_test dut fx2_statemachine_c Fx2_slwr feth_usb_test dut fx2_statemachine_c fx2_Full feth_usb_test dut Fx2_statemachine_c fx2_ifclk Fooo F000 Cursor 1 2775 5 ns Abbildung 5 13 Reaktion auf das FULL Signal 1 SLWR wird auf 0 gesetzt und bei der n chsten steigenden Flanke von FX2_IFCLK werden die Werte des Signals FX2_DATA_OUT in das FIFO geschrieben Nach einer Verz gerungszeit von txe g 9 5ns wird das FULL Signal des FX2 gesetzt Der Wert der Verz gerunggszeit ist im Datenblatt zu finden vgl Cypress Datasheet 2 Wenn sich der Automat im DECICION_STATE Zustand befindet bleibt er so lange in diesem Zustand
19. ein Teilnehmer zur Zeit senden kann Sende und Empfangsstation m ssen beim Halb Dublex die Erlaubnis auf der Leitung zu senden deshalb untereinander aushandeln Dies wird durch den CSMA CD Algorithmus realisiert Von einer n heren Betrachtung dieses Algorithmus wird abgesehen da er f r Ethernet 100BASE TX nicht mehr von wesentlicher Bedeutung ist Im Voll Duplex Modus k nnen die Sende und Empfangsstation gleichzeitig Senden und Emfangen Laut IEEE 802 3 m ssen drei Vorraussetzungen erf llt sein damit die Sende und Empfangsstation in diesem Modus arbeiten darf 1 Einleitung 18 1 Auf dem physikalischen Medium ist es m glich gleichzeitig senden und empfangen zu k nnen 2 Es gibt maximal zwei Stationen im Netzwerk So wird eine Punkt zu Punkt Verbindung zwischen den Stationen erreicht Ein Algorithmus wie CSMA CD ist hier deshalb un n tig 3 Beide Stationen sind f hig im Voll Duplex Modus zu arbeiten Daten Kapselung Eine weitere Aufgabe der Sicherungs Schicht ist die Daten Kapselung Der Standard defi niert ein MAC Paket das in Abbildung 1 5 zu erkennen ist Die Felder dieses Pakets werden im Folgenden erkl rt 7 OCTETS PREAMBLE 1 OCTET SFD 6 OCTETS DESTINATION ADDRESS 6 OCTETS SOURCE ADDRESS m OCTETS 2 OCTETS LENGTHITYPE bQ TRANSMITTED gt q TOP TO BOTTOM 46 TO 1500 OR 1504 MAC CLIENT DATA f iL ORASSZOCTETS 4 peer semema een seed SEE 3 2 7 PAD 4
20. mit dem die Daten per USB ber die Transferart Interrupt Transfer von dem Computer einge lesen werden Es wurden verschiedene Realisierungsm glichkeiten f r die Analyse Software diskutiert und bewertet Als optimale L sung hat sich herausgestellt das Analyseprogramm Wireshark mit geeigneten Plugins zu erweitern Die Plugins bernehmen abh ngig von dem Datenstrom die individuelle Analyse Um die Daten mit Wireshark untersuchen zu k nnen m ssen die Rohdaten in das pcap Format konvertiert werden Hierf r wurde eine Konvertierungssoftwa re entwickelt die diesen Vorgang durchf hrt Eine Erweiterungsm glichkeit f r dieses Analyse System ist das Setzen von Trigger Bedingungen Durch einen Mechanismus der bei einer erf llten Bedingung automatisch einen Einlesevorgang startet k nnte dies realisiert werden Die gleichzeitige Analyse des Upstream und Downstream Datenstromes w re eine weitere Erweiterungsm glichkeit Auf diese Weise k nnte analysiert werden wie Netzwerk Knoten auf bestimmte Anfragen reagieren Eine M glichkeit dies zu realisieren ist ein Analyse System an den Sende Pfad und ein Analyse System an den Empfangs Pfad an zu koppeln und beide zeitlich miteinander zu synchronisieren Nach dem Empfang der Daten beider Da tenstr me k nnen durch die Zeitinformationen die beiden Datenstr me zu einem Datenstrom geschachtelt werden der anschlie end analysiert werden kann Literaturverzeichnis Bernhard Lahres Grego
21. nschten Verhalten dass der Z hlerstand an das Ende eines jeden Frame angeh ngt werden soll Die Werte der letz ten beiden Nibbles des Eingangsdatenstromes E_RXD_IN betragen ONE und 0x0 An das Ende des Signals E_RXD_IN wird der aktuelle Z hlerstand mit dem Wert von 0x123456 an geh ngt Das resultierende Signal ist das Signal E_RXD_OUT Das Signal E_RX_DV_OUT wird w hrend der Ausgabe des Z hlerstandes auch gesetzt sodass diese Daten f r das interne FIFO in dem n chsten Systemblock als g ltig gelten eth_usb_test dut time_stamp_c reset eth_usb_test dut time_stamp_c e_rx_dk Jeth_usb_test dut time_stamp_c e_rx_dv_in Jeth_usb_test dut time_stamp_c e_rxd_in Jeth_usb_test dut time_stamp_c e_rx_dv_out Jeth_usb_test dut time_stamp_c e_rxd_out Jeth_usb_test dut time_stamp_c datastream_mux_c sel Jeth_usb_test dut time_stamp_c datastream_mux_c e_rxd_temp Jeth_usb_test dut time_stamp_c datastream_mux_c usec_count4bit Jeth_usb_test dut time_stamp_c datastream_mux_c datastream_temp Jeth_usb_test dut time_stamp_c datastream_mux_c datastream Jeth_usb_test dut time_stamp_c control_path_c state Jeth_usb_test dut time_stamp_c control_path_c next_state Jeth_usb_test dut time_stamp_c control_path_c e_rx_dv_out Jeth_usb_test dut time_stamp_c control_path_c e_rx_dv Jeth_usb_test dut time_stamp_c usec_counter_c sample_usec Jeth_usb_test dut time_stamp_c control_path_c count_sel Jeth_usb_test dut time_stamp_c usec_count Jeth_usb_test dut time_stamp_c usec_cou
22. 1 Klassenhierarchie der Klasse Stateltem On ONO P 10 11 12 13 14 7 Realisierung der Interpretationssoftware 82 Das Listing 7 3 zeigt die Definition von drei Zust nden und ihren Folgezust nden Der Zu standsautomat aus Kapitel 6 2 3 in Abbildung 6 2 dient dabei als Grundlage Zuerst werden die Zust nde definiert und anschlie end ihre Folge Zust nde festgelegt Zust nde aus StateltemNode Klasse erzeugen StateltemNode xpreamble7 new StateltemNode charx PREAMBLE7 StateltemNode xframestart new StateltemNode charx FRAMESTART 1 Eine neuer Frame beginnt StateltemNode frame new StateltemNode charx FRAME DATA Folgezust nde definieren for int i 0 i lt OxFF i preamble7 gt setNextState i frame framestart gt setNextState i frame frame gt setNextState i frame preamble7 gt setNextState 0x55 preamble7 preamble7 gt setNextState OxD5 framestart Es wurde eine Preambel gefunden frame gt setNextState 0x55 preamble1 Ist es eine neue Preambel Listing 7 3 Definition der Folgezustande Ein Nachteil von diesem Konzept ist dass es eine L sung auf dieses konkrete Problem darstellt und aufwendig erweitert werden muss um es auf andere Probleml sungen anzu wenden Das erste Konzept ist in der Hinsicht flexibler da ein neuer Zustand mit anderem Verhalten in die bestehende Klassen Konstellation hinzugef gt werden kann Ein w
23. 2 REALTIME PROTOCOL TOPLINE UPSTREAM 150 WTAP_ENCAP_USER3 REALTIME PROTOCOL TOPLINE DOWNSTREAM Listing 7 5 Anpassung der Datei wiretap pcap common c _ NO OO POD 7 Realisierung der Interpretationssoftware 84 7 2 2 Automatische Frametyp Detektion Um innerhalb eines Datentromes erkennen zu k nnen ob es sich um einen Echtzeit oder Nicht Echtzeit Frame handelt wird eine automatische Frametyp Detektion ben tigt F r eine automatische Detektion muss es einen Mechanismus geben bei dem zun chst der Inhalt jedes Frames gepr ft wird Nur dadurch ist es m glich feststellen zu k nnen ob es sich um Echtzeit oder Nicht Echtzeit Daten handelt Um dies im hybriden Protokoll festzustellen gibt es ein Flag das festlegt ob die folgenden Daten Echtzeit oder Nicht Echtzeit Informationen sind Um die automatische Detektion zu realisieren eignet sich das Prinzip der heuristi schen Dissectoren welches durch das Listing 7 6 verdeutlicht wird Zu Beginn der Funktion die das Zerlegen des Frames durchf hrt wird der heuristische Diss ector mit der Funktion dissector_try_heuristic aufgerufen Zeile 6 Der heu ristische Dissector ist im Fall des hybriden Bussystem der Dissector f r die Nicht Echtzeit Frames Falls der Frame von dem heuristischen Dissector zerst ckelt wurde bricht die Funk tion durch den Ausdruck return die weitere Verarbeitung ab Zeile 6 Falls der Frame nicht von dem heuristischen
24. 2 the design is Is 10 8 80 Total Number of 4 input LUTs 309 out of 11 776 Number used as logic 217 Number used as a route thru 92 The Slice Logic Distribution report is not meaningful if over mapped for a non slice resource or if Placement fai Number of bonded IOBs 38 out of 372 IOB Flip Flops 18 Number of BUFGMUXs 2 out of 24 Number of RAMB16BWES 16 out of 20 Average Fanout of Non Clock Nets 3 65 Peak Memory Usage 227 MB Total REAL time to MAP completion 5 secs Total CPU time to MAP completion 5 secs Timing Summary Speed Grade 4 Minimum period 5 480ns Maximum Frequency 182 482MHz Minimum input arrival time before clock 2 561ns Maximum output required time after clock 6 991ns Maximum combinational path delay 6 884ns Listing B 1 Auszug aus dem synthesis report von Xilinx ISE Versicherung ber die Selbstst ndigkeit Hiermit versichere ich dass ich die vorliegende Arbeit im Sinne der Pr fungsordnung nach 16 5 APSO TI BM ohne fremde Hilfe selbstst ndig verfasst und nur die angegebenen Hilfs mittel benutzt habe W rtlich oder dem Sinn nach aus anderen Werken entnommene Stellen habe ich unter Angabe der Quellen kenntlich gemacht Hamburg 28 Februar 2011 Ort Datum Unterschrift
25. 2 2 Automatische Frametyp Detektion 84 8 Systemintegration und Verifikation 87 8 1 Integration der Hardwarekomponenten 87 8 2 Integration der Softwarekomponenten 88 8 2 1 Integration der Konvertierungssoftware 88 8 2 2 Analyse der Daten mit Wirehark 90 8 3 Verifikation cco ace eae Sects a ae Shee ea ae ae et ex Syke E 91 9 Zusammenfassung und Ausblick 92 Literaturverzeichnis 93 Abkurzungsverzeichnis 95 A Inhalt der CD 96 B Auszug aus synthesis report 97 Tabellenverzeichnis 4 1 bersicht ber die Transferarten vgl Udo Erhardt 2001 S 63 5 1 Fehlerhafter Datenstrom aufgrund versetzter Nibbles Abbildungsverzeichnis 1 1 Die Komponenten des CIDS 12 1 2 AufbaudssE DS 2 2 25 27 BERLE ee EHE 13 1 3 Aufbau des hybriden Datenbus 2 2 2 nn nn nn 14 1 4 OSI Schichtenmodell vgl IEEE 802 3 S 77 8 ea es 15 1 5 Aufbau eines Ethernet konformen Packets vgl IEEE 802 3 S 123 18 3 1 Aufbau des Gesamtsystems 0000052 eae 25 3 2 Parallelschaltung von zwei Leitungen 26 3 3 Augendiagramm ohne Abschlusswiderstand an der Abzweigeleitung 27 3 4 Augendiagramm mit Abschlusswiderstand an der Abzweigeleitung 27 3 5 Anpassung des Wellenwiderstandes mit Hilfe eines Ubertragers 29 3 6 Busankopplung mit der Daisy Chain Methode 30 3 7 Situation f r eine Kollision im Hub aaau 31
26. 32_documentation J rgen Reichard 2009 J RGEN REICHARD Lehrbuch Digitaltechnik Oldenbourg 2009 ISBN 978 3 486 58908 5 Literaturverzeichnis 94 Jungo JunGo JUNGO WinDriver URL http www jungo com st windriver_usb_pci_driver_development_software html Klaus Dembowski 2007 KLAUS DEMBOWSKI Lokale Netze Addision Wesley 2007 ISBN 978 3 8273 2573 0 Marvel MARVEL Yukon FE 88E8040 Product Brief URLhttp www marvell com products pc_connectivity yukon Yukon_FE_88E8040 pdf synapse SYNAPSE Online Lexikon zu LAN WAN Analyse URL http www syn wiki de LAN WAN Analysis htm ger _0O LAN Analyse htm Udo Erhardt 2001 UDO ERHARDT Hrsg USB 2 0 Professional Series 2001 ISBN 3 7723 7965 6 Wikipedia WIKIPEDIA Zyklische Redundanzpr fung URL http de wikipedia org wiki Zyklische_Redundanzpr C3 BCfung Wireshark WIRESHARK HOWTO for Wireshark developers URL http anonsvn wireshark org wireshark trunk doc README developer Abk rzungsverzeichnis jd EPR eee ey ry es Application Interface CDS ineen Cabin Intercommunication Data System CRO 2 422 Cyclic Redundancy Check DEU seien ene Decoder Encoder Units DUR ug geg Cedies Director PAP een rl Flight Attendant Panel FCS 222222 Frame Check Sequence FPGA Field Programmable Gate Array Resear ae Graphical User Interface lEEE 4 4 4 Institute of Electrical and Electronics Engineers
27. 802 3 IEEE 802 3 definiert Die f r das Verst ndnis dieser Arbeit wichtigen Sachverhalte begrenzen sich auf die ersten beiden Schichten dieses Modells Sie lauten PHYSICAL Layer physikalische Schicht und DATA LINK Layer Sicherungsschicht und werden im Folgenden beschrieben osi LAN REFERENCE CSMA CD MODEL LAYERS LAYERS HIGHER LAYERS j APPLICATION LLC LOGICAL LINK CONTROL OR OTHER MAC CLIENT PRESENTATION MAC CONTROL OPTIONAL SESSION MAC MEDIA ACCESS CONTROL TRANSPORT A DS RECONCILIATION RECONCILIATION j l T Ga FA Mil gt J aM gt NETWORK ES PLS PCS Geer PHY DATALINK AU gt aui gt LL PMA mau PMA PMA PMD PHYSICAL ww Moi gt MDI gt 7 MEDIUM z g MEDIUM lt gt MEDIUM 1 Mb s 10 Mb s 10 Mb s 2 100 Mb s AUI ATTACHMENT UNIT INTERFACE PCS PHYSICAL CODING SUBLAYER MAU MEDIUM ATTACHMENT UNIT PHY PHYSICAL LAYER DEVICE MDI MEDIUM DEPENDENT INTERFACE PLS PHYSICAL LAYER SIGNALING MII MEDIA INDEPENDENT INTERFACE PMA PHYSICAL MEDIUM ATTACHMENT PMD PHYSICAL MEDIUM DEPENDENT Abbildung 1 4 OSI Schichtenmodell vgl IEEE 802 3 S 77 1 Einleitung 16 1 6 1 bertragungsmedium Noch unter der physikalischen Schicht wird das Medium definiert auf dem die bertragung stattfindet
28. CalcCRCPcap crcpoly unsigned int frameList PcapFrameList initxor unsigned int errors int crc32_rev unsigned int validateCRC unsigned int crc32_end crcreg unsigned int Li PcapFrameNode laeufer_p int finalxor unsigned int CalcCRCPcap PcapFrameList frame crc32_reg unsigned int List init void calcEthernetCRC int calc unsigned char datastream2 void CalcCRC Abbildung 5 17 Klassendiagramm der Klassenhierarchie CalcCRCPcap 6 Design des Interpretationsmoduls Das Interpretationsmodul verarbeitet die empfangenen Rohdaten und stellt sie dem Benut zer in Wireshark dar Es besteht aus zwei Komponenten Eine Komponente ist ein Kon vertierungsprogramm das die empfangenen Rohdaten in ein Format umschreibt mit dem Wireshark arbeiten kann Dieses Format tr gt die Bezeichnung pcap und wird im Folgenden erl utert Die andere Komponente ist der Wireshark Dissector f r das jeweilige Protokoll 6 1 Das pcap Format Eine pcap Datei besteht aus einem Global Header Feld dem die Kombination aus den Fel dern Packet Header und Packet Data folgt Diese Kombination beschreibt einen einzelnen Frame in einer pcap Datei Global Header Packet Header Packet Data Packet Header Packet Data Global Header Im Global Header Feld wird der Verbindungstyp network spezifiziert dem die folgenden Nutz Daten angeh ren F r jeden Verbindungstyp wie zum
29. Dissector verarbeitet wurde f hrt der Dissector f r die Echtzeit Frames mit der Verarbeitung fort static void dissect_hybrid_rt_top_down tvbuff_t xtvb packet_info xpinfo proto_tree xtree gint offset 0 guint8 length 0 if dissector_try_heuristic heur_subdissector_list tvb pinfo tree return Listing 7 6 Ausschnitt aus der Datei packet hybrid_topline_downstream c ook W PD N 7 Realisierung der Interpretationssoftware 85 Der heuristische Dissector berpr ft einen Frame ob er ihn zerteilen soll Dies erfolgt durch die if Abfrage in Zeile 7 des Listing 7 7 Die Variable bit enth lt den Wert des Flag das an zeigt ob ein Frame ein Echtzeit oder Nicht Echtzeit Frame ist Die Ermittlung dieses Wertes erfolgt in der Zeile 6 durch die Funktion tvb_get_bits8 Diese Funktion extrahiert ein Bit aus den Daten wobei der Offset im Frame 71 betr gt Dies ist das 7 Bit im 8 Byte jedes Frame Besitzt dieses Bit den Wert 1 bricht der heuristische Dissector die Verarbeitung ab und gibt dem Standard Dissector den Wert FALSE zur ck Wenn dieses Bit den Wert 0 be sitzt ist dieser Frame ein Nicht Echtzeit Frame und der heuristische Dissector f hrt mit der Verarbeitung fort indem er den Frame zerteilt Am Ende der Funktion gibt der Dissector den Wert TRUE zur ck wodurch dem Standard Dissector mitgeteilt wird dass der Frame bereits zerteilt wurde static gboolean dissect_hybrid_nonrt tv
30. Head PcapFrameNode Klak i void setNextNode nextP PcapF SE setTs_sec ts_sec unsigned int rameNode Sa S p a g void prin getTs_sec PcapFrameNode get_next a r Karl setincl_len incl_len unsigned int getIncl_len setOrig_len orig_len unsigned int getOrig_len setPayload incl_len unsigned char getPayload Abbildung 6 3 Klassenhierarchie der Klasse PcapFrameList 6 Design des Interpretationsmoduls 77 6 2 5 Speichern der Daten mit der PcapFile Klasse F r die Beschreibung der zu erstellenden pcap Datei wurde die Klasse PcapFile entwor fen Dem Konstruktor der Klasse PcapFile wird ein Zeiger auf die Frameliste bergeben Es wird nur ein Zeiger bergeben da die Frameliste den gesamten Datenstrom enth lt und bei einer Einlesemenge von 300 MByte das Objekt viel Speicherplatz einnimmt Um das Kopieren der Daten zu vermeiden wird ein Zeiger des Objektes bergeben Die PcapFile Klasse beherbergt neben dem Zeiger auf die Frameliste auch einen Zeiger auf ein PcapHeader Objekt welches den Global Header einer pcap Datei repr sentiert Die PcapFile Klasse speichert den Global Header und die Frames mit Hilfe der Methode saveToDisk char filename ab Das Klassendiagramm der Klasse ist in der Ab bildung 6 4 zu sehen PcapHeader PcapFile PcapFrameList g_header unsigned char outputFile FILE head PcapFrameNode
31. Hochschule f r Angewandte Wissenschaften Hamburg Hamburg University of Applied Sciences Bachelorthesis Jan Erik Lange Entwicklung eines modularen Analysators f r propriet re Ethernet basierte Kommunikationsprotokolle Fakult t Technik und Informatik Faculty of Engineering and Computer Science Department Informations und Department of Information and Elektrotechnik Electrical Engineering Jan Erik Lange Entwicklung eines modularen Analysators f r propriet re Ethernet basierte Kommunikationsprotokolle Bachelorthesis eingereicht im Rahmen der Bachelorpr fung im Studiengang Informations und Elektrotechnik am Department Informations und Elektrotechnik der Fakult t Technik und Informatik der Hochschule f r Angewandte Wissenschaften Hamburg Betreuender Pr fer Prof Dr rer nat Thomas Lehmann Zweitgutachter Prof Dr rer nat Jochen Schneider Abgegeben am 28 Februar 2011 Jan Erik Lange Thema der Bachelorthesis Entwicklung eines modularen Analysators f r propriet re Ethernet basierte Kommu nikationsprotokolle Stichworte Ethernet Xilinx Cypress Wireshark Protokoll Analyse Kurzzusammenfassung Bei der Firma Airbus Operations wurde ein propriet res Kommunikationsprotokoll f r ein Kabinenmanagement System entwickelt F r die Entwicklung von Ger ten die mit diesem Protokoll arbeiten ist es n tig eine M glichkeit zu schaffen den Datenverkehr mitzulesen und zu analysieren Es wurde ein Konz
32. Im Folgenden werden die Simulationsergebnisse des Zustandsautomaten ge zeigt Zunachst wird gezeigt wie der Automat reagiert wenn das interne FIFO leer ist An schlieBend wird die Reaktion des Automaten gezeigt wenn durch den FX2 das FX2_FULL Signal gesetzt wird 5 Realisierung des Einlesemoduls 64 Reaktion auf das Setzen des EMPTY Signals Die Abbildung 5 12 dient der Veranschau lichung der Reaktion auf das Setzen des EMPTY Signals feth_usb_test dut swap_nibbles_toplevel_cfe_rx_dv feth_usb_test dut swap_nibbles_toplevel_cfe_rxd feth_usb_test dut swap_nibbles_toplevel_cfe_rxd_out feth_usb_test dut swap_nibbles_toplevel_c wr_en_out feth_usb_test dut time_stamp_cfe_rx_dy_out feth_usb_test dut time_stamp_c e_rxd_out feth_usb_test dut fifo_intern_c din feth_usb_test dut Fifo_intern_c wr_en feth_usb_test dut Fifo_intern_c rd_en Jeth_usb_test dut fifo_intern_c dout Jeth_usb_test dut fifo_intern_c Full Jeth_usb_test dut fifo_intern_c empty jeth_usb_test dut fx2_statemachine_c cik jeth_usb_test dut fx2_statemachine_c fx2_data_in jeth_usb_test dut fx2_statemachine_c fx2_Full_in jeth_usb_test dut fx2_statemachine_c empty_in jeth_usb_test dut fx2_statemachine_c rd_en feth_usb_test dut Fx2_statemachine_c state e i jeth_usb_test dut fx2_statemachine_c next_state E de i W den st feth_usb_test dut Fx2_statemachine_c Fx2_full_temp1 feth_usb_test dut Fx2_statemachine_c empty feth_usb_test dut Fx2_statemachine_c Fx2_slwr_temp feth_usb_test
33. alse Protocols in frame hybrid_topline_rt_upstream Hybrid Protocol Topline RT UPSTREAM Preamble 55555555555555d5 Type 0x83 1000 Type RFU 0x08 m 0 Type H_Type_extension 0x00 H 0 Type Non Realtime Content 0x00 1 Type Realtime Content 0x01 eee Type Realtime Frame 0x01 1110 1000 1100 0000 00 DEU Address 0x03a300 10 1000 DEU A Port 0x000028 DEU A stuff 2 0x000001 DEU A Number 0x000000 eose sese cane sreo van eave DEU A Stuff 1 Ox000000 00 0001 0000 0100 0000 Discrete Data 1 0x001040 1000 0001 0000 0010 00 Highspeed Channel 1 0x020408 sees ae 00 0100 0000 1000 0000 Highspeed Channel 2 0x004080 0000 0000 0000 0001 00 Highspeed Channel 3 0x000004 00 0010 0000 0100 0000 Highspeed Channel 4 0x002040 1000 0001 0000 0010 00 Highspeed Channel 5 0x020408 sees oe 00 0100 0000 1000 0000 Highspeed Channel 6 0x004080 0000 0000 0000 0001 00 Highspeed Channel 7 0x000004 00 0010 0000 0100 0000 Highspeed Channel 8 0x002040 1000 0001 0000 0010 00 CRC 0x020408 PETE 00 EOF 0x00 0000 55 55 55 55 55 55 55 d5 83 e8 cO 01 04 08 10 20 UUUUUUU u 0010 40 80 00 01 02 04 08 10 20 40 80 00 01 02 04 08 0020 10 20 40 80 00 01 02 04 08 10 20 40 80 00 01 02 0030 40 00 08 00 01 20 00 04 80 00 10 00 02 4000 08 0040 00 01 20 00 04 80 0010 00 72 22 Ob ks assas Time delta fr
34. are system consists of the Xilinx Spartan 3A starter kit and the Cypress FX2 microcontroller The analysis of the data has been realized by using the program Wireshark The individual protocol analysis has been realized by the devel opment of Wireshark dissectors To analyse the proprietary communication protocols with Wireshark a conversion program is neccessary which also has been developed in this thesis Inhaltsverzeichnis Tabellenverzeichnis Abbildungsverzeichnis 1 2 Einleitung 1 1 Vorstellung des Unternehmens 1 2 Cabin Intercommunication DataSystem 1 2 1 Komponenten des Cabin Intercommunication Data System 1 2 2 Die Datenbusse Middle und Top Line 1 3 CIDS Protokoll 2 4 244 244 44 2449 sad aaa 1 4 Hybrides Protokoll TTT 1 5 Darstellung des Themas 1 6 Grundlagen zu Ethernet 1OOBASE TX 1 6 1 bertragungsmedium dere ee 1 6 2 Physikalische Schicht aoao a 1 6 3 Sicherungsschicht Anforderungen 2 1 Anforderungen an die Hardware 2 1 1 Anforderungen an die Busankopplung 2 1 2 Anforderungen an das Einlesemodul 2 2 Anforderungen an die Analyse Software 2 3 Recherche zu bestehenden Analyse Systemen 2 3 1 Analyse eines Netzwerks auf der physikalischen Schicht 2 3 2 Analyse eines Netzwerks ab der Vermittlungsschicht Konzept 3 1 Busankopplung arte ag
35. buff_t tvb packet_info xpinfo proto_tree xtree gint offset 0 guint8 length 0 guint8 bit tvb_get_bits8 tvb 71 1 Dieses Bit ist das RT_Frame Bit 7 Bit im 8 Byte des Frames if bit 1 return FALSE Listing 7 7 Ausschnitt aus der Datei packet hybrid_nonrt c 7 Realisierung der Interpretationssoftware 86 Das Zerteilen eines Frame wird im Listing 7 8 gezeigt In diesem Beispiel zerst ckelt das Plugin einen Teil des IP Fragment des Nicht Echtzeit Protokolls Die Funktion proto_tree_add_item erzeugt in Zeile 2 des Listing 7 8 den Eintrag f r das Timestamp Feld in Wireshark Der Parameter hf_hybrid_timestamp definiert die Eigenschaften des Feldes Mit dem Parameter of fset wandert der Dissector Byte weise durch den Frame 1 kkkkkkkkkkk IP Fragment 2 proto_tree_add_item hybrid_tree hf_hybrid_timestamp tvb offset 4 FALSE offset 4 3 proto_tree_add_item hybrid_tree hf_hybrid_src tvb offset 1 FALSE 4 proto_tree_add_item hybrid_tree hf_hybrid_seqnr tvb offset 2 FALSE offset 2 Listing 7 8 Ausschnitt aus der Datei packet hybrid_nonrt c Die Definition des Parameters hf_hybrid_timestamp wird in Listing 7 9 dargestellt Die Zeichenkonstante TP Timestamp gibt die Bezeichnung des Feldes an Zeile 3 Unter dieser Bezeichnung wird das Feld in Wireshark angezeigt Der Parameter BASE_HEX gibt an dass das Feld im hexadezimalen Format angezeigt wi
36. chrieben werden Um bei der Taktregeneration im Empf nger lange Eins und Null Folgen zu vermeiden wird die 4B 5B Codierung verwendet Bei dem Codiervorgang werden vier Nutzdatenbits auf f nf Codebits abgebildet Durch das Einf gen eines weiteren Bit erh ht sich die Datenrate um den Faktor 5 4 gegen ber dem uncodierten Signal Dies bedeutet auch dass sich das Si gnalspektrum zu hohen Frequenzen verschiebt Die Taktrate betr gt auf der Leitung durch die Erh hung der Datenrate um den Faktor 5 4 daher 125 MHz Eine Analyse des Spektrums des Signals ergibt bei 125 MHz die gr ten Spektralanteile des Signals Wie bereits erw hnt hat das bertragungsmedium aber eine Grenzfrequenz von 100 MHz Das Signal w rde deshalb ohne weitere Ma nahmen verzerrt werden Um dem entgegenzuwirken wird zus tzlich die MLT 3 Leitungscodierung verwendet Dies ist ein dreistufiger Code mit den Pegeln 1 V 0 V und 1 V twisted pairs engl verdrillte Paare 3screened engl abgeschirmt 1 Einleitung 17 Beim Codiervorgang entspricht eine logische Eins einem Pegelwechsel Bei der bertragung einer Null wird kein Pegelwechsel durchgef hrt Ein direkter bergang zwischen 1 V und 1 V und umgekehrt ist nicht erlaubt Wenn zum Beispiel vier Einsen hintereinander gesendet werden ndert sich der Spannungspegel auf der Leitung nach dem Schema 1 V 0 V 1 V O V Dies ist der Extremfall in dem sich das Signal am schnellsten ndert Dieser Zyklu
37. d erg nzt ihre Basisklas se um einen Zeiger nextState Durch diesen Zeiger und weiteren Methoden der Klasse ist es m glich diese Objekte in einer Liste zu verwalten Diese Liste wird durch die Klasse StateMachine verwaltet Der Konstruktor der Klasse bernimmt ein StateItemNode Objekt dass der Initialzustand ist Um weitere Zust nde in den Automaten einzuf gen wur de die Methode insert definiert Die Klasse StateMachine besitzt wie bereits in Listing 7 2 beschrieben die Methode run um den Automaten in der Anwendung zu ver wenden Mit der Methode clear werden s mtliche Zust nde gel scht State Stateltem name char nextState Stateltem 256 newFrame int Stateltem name char newFrame int State name char newFrame int setNextState input unsigned char nextState Statel getName char 20 tem void isNewFrame int getNextState input unsigned char Stateltem StateMachine StateltemNode head laeufer last neu StateltemNode nextState StateltemNode newFrame int x tStateltemNode name chat newFrame int help help2 Stateltem 1 0 isLast int StateMachine node StateltemNode setNextNode next StateltemNode void StateMachine getNode StateltemNode insert node StateltemNode StateltemNode getNext StateltemNode run input unsigned char int clear void Abbildung 7
38. d nicht Ethernet konforme Frames verwirft 3 Konzept 32 3 1 4 T St ck mit Ethernet Transceivern Eine M glichkeit sich in das Netzwerk an zu koppeln ist zwei Ethernet Transceiver zu be nutzen um die Daten mit dem einen Transceiver zun chst zu empfangen und anschlie end mit dem anderen Transceiver weiter zu verschicken Zus tzlich ist eine Verarbeitungseinheit n tig die die Daten von Transceiver zu Transceiver bertr gt und intern zwei Ankopplungs zweige besitzt um die Daten mitzulesen Die Abbildung 3 8 zeigt dieses Prinzip als Blockschaltbild Dieses Element entspricht einem Kettenglied im Daisy Chain Netzwerk Es entsteht eine Zeitverz gerung die identisch mit der eines Daisy Chain Elements ist wenn diese Verarbeitungseinheit genauso funktioniert wie die einer DEU Die Anzahl der maximal m glichen DEUs in einer Kette ist auch abh ngig von ihrer internen Verz gerung daher verringert sich diese Zahl um 1 bei dieser Art der Ankoppplung Die maximale Anzahl an DEUs im hybriden Bussytem betr gt 16 was bedeutet dass maximal 15 DEUs in das Bussystem angeschlossen sein d rfen Downstream Downstream Upstream Upstream Abbildung 3 8 Blockschaltbild zur Busankopplung mir zwei Transceivern und Verarbeitungsblock 3 Konzept 33 3 1 5 Verwendung eines Ethernet Tap Ein Ethernet Tap erm glicht die berwachung eines Datenstroms in einem Netzwerk Er eig net sich f r das Mitlesen des Daten
39. das Ergebnis einer Kollision auf dem Bus ist und wird verwor fen Diskrepanz zu Frames des hybriden Protokoll Mit Bezug auf die genannten Punkte stehen die Frames des hybriden Protokolls zu den Ethernet konformen Frames in den folgenden Punkten in Diskrepanz e Die Frames des Protokolls des Upstream Pfads der Topline haben eine Lange von 25 Bytes Die Frames sind also k rzer als die Mindestl nge von Ethernet Frames und werden deshalb verworfen e Die Frames gelten als ung ltig da das L ngenfeld nicht mit der wirklichen Framel nge bereinstimmt e Au erdem wird die berechnete CRC Pr fsumme immer falsch sein egal wie lang der Frame ist 3 Konzept 36 Behandlung ung ltiger Frames Zur Behandlung dieser ung ltigen Frames sagt der Standard aus ein ung ltiger MAC Frame sollte nicht an die LLC oder MAC Unterschichten weitergegeben werden Er kann ignoriert oder verworfen werden Die Nutzung solcher Frames entzieht sich dem Geltungs bereich dieses Standards IEEE 802 3 Das bedeutet dass Ethernet Controller die strikt dem Standard folgen die Frames des hybriden Protokolls nicht weiterleiten Zusammenfassung Der erarbeitete Analyse ergab dass Ethernet Controller welche dem Standard folgen hy bride Datenframes nicht weiterleiten Einige Hersteller die die MAC und PHY Komponenten entwickeln weichen eventuell von dem Standard ab Dies ist f r die weitere Planung des Einlesemoduls aber eine zu riskan
40. datenrate e Wie kontinuierlich ist der Daten Transfer e Wie gro ist der Aufwand f r die Realisierung e Wie hoch sind die Kosten f r die Realisierung Ethernet 100BASE TX Wenn man Ethernet 100BASE TX f r das Senden des Daten stroms vom FPGA zum PC in Betracht zieht muss man sich im Klaren dar ber sein dass die beim hybriden Datenbus eingesetzte bertragungstechnik ebenfalls 100BASE TX lautet W hrend bei den Ethernet konformen Frames zus tzliche Informationen zu den Nutzdaten versendet werden vgl Kapitel 1 6 m ssen mit dem Protokollanalysator s mtliche Informa tionen des hybriden Protokolls bertragbar sein Aus diesem Grund ist diese bertragungs technik zu langsam f r die Daten bertragung zum PC Gigabit Ethernet Die bertragungstechnik Gigabit Ethernet w re aus dem Gesichts punkt der bertragungsgeschwindigkeit geeignet als bertragungtechnik da die Datenra te 1 Gbit s betr gt Die Frames des hybriden Protokolls k nnte man im Nutzdatenfeld des Ethernet Frame bertragen Ein Vorteil der Verwendung von Gigabit Ethernet ist die Tatsa che dass man computerseitig keine Treiber programmieren muss um die Daten zu empfan gen Es gen gt ein 1 Gbit f higer Ethernet Controller Ein Nachteil ist dass man den MAC Layer zur Kommunikation mit dem Computer im FPGA implementieren m sste Die IP Cores von Xilinx die man hierf r benutzen k nnte w ren durch ihre Lizenz nur zeitlich begrenzt benutzbar Die Lizenz m
41. dem Empfang dieses Datenstroms wird anschlie end die CRC Pr fsumme jedes Ethernet Frame berpr ft um beurteilen zu k nnen ob das System die Daten korrekt bertr gt Es wurde eine Klasse entwickelt mit deren Methoden die CRC32 Pr fsumme eines Ethernet Frames berechnet wird Das Klassendiagramm ist in Abbildung 5 17 zu sehen Der verwendete Algorithmus zur Berechnung der Pr fsumme wurde der Quelle Wikipedia ent nommen Es wurde eine Klassenhierarchie entworfen in der die Basisklasse CalcCRC den bernommenen Algorithmus beinhaltet Durch diesen hierarchischen Aufbau wird eine Tren nung der selbst entwickelten Elemente und dem bernommenem Algorithmus erreicht Basierend auf der Klasse CalcCRC wurde eine Klasse mit dem Namen CalcCRCPcap ab geleitet Dem Kontruktor der Klasse wird eine Liste von Frames bergeben in der Ethernet Frames in Rohform abgelegt sind Einzelheiten zu dieser Liste werden im Kapitel 6 2 4 n her erl utert In der Methode calcEthernetCRC wird zu jedem Frame in der Liste die Pr fsumme berechnet und mit der sich im FCS Feld befindenden Pr fsumme verglichen Der Vergleich wird in der Methode validateCRC durchgef hrt Sind die Pr fsummen identisch trat kein Fehler bei der bertragung auf Falls sie nicht identisch sind liegt ein Fehler im Frame vor und das Attribut errors wird inkrementiert Der komplette Quellcode dieser Klasse ist im elektronischen Anhang A zu finden CalcCRC
42. dut Fx2_statemachine_c fx2_data_out feth_usb_test dut fx2_statemachine_c fx2_slwr feth_usb_test dut fx2_statemachine_c fx2_Full feth_usb_test dut fx2_statemachine_c Fx2_ifclk 10000 ns Cursor 1 2142 052 ns Abbildung 5 12 Reaktion auf das Setzen des EMPTY Signals 1 Der Automat ist im DECISION STATE Zustand 2 Der Wert des EMPTY Signals des internen FIFOs wird 0 Durch die kombinatorische Logik im Ubergangsschaltnetz des Automaten erfolgt nach einer symbolischen Verz6 gerungszeit eine Anderung des Signals NEXT_STATE in den symbolischen Zustand styp RD_EN_STATE 3 Bei der n chsten steigenden Flanke nimmt der Automat den Zustand aus dem Uber gangschaltnetz ein und das Signal RD_EN wird auf 1 gesetzt Dadurch wird ein Da tensatz aus dem FIFO gelesen 4 Es erfolgt ein Zustands bergang in den FX2_SLWR Zustand und das Signal wird ge setzt Dieses Signal ist low aktiv Wenn dieses Signal auf 0 gesetzt ist schreibt der FX2 den Wert am Datenbuseingang in das Slave FIFO 5 Realisierung des Einlesemoduls 65 Reaktion auf das Setzen des FULL Signals Die Abbildung 5 13 dient der Veranschauli chung der Reaktion auf das Setzen des FULL Signals leth_usb_test dut swap_nibbles_toplevel_c e_rx_dv o feth_usb_test dut swap_nibbles_toplevel_cfe_rxd o Jeth_usb_test dut swap_nibbles_toplevel_c e_rxd_out o feth_usb_test dut swap_nibbles_toplevel_c wr_en_out Io feth_usb_test dut time_stamp_c e_rx_dv_out 0 feth_usb_test dut time_stamp_c
43. e Fehlerquelle die ohne weitere Ma nahmen unentdeckt bleiben w rde Diese Fehlerquelle ist das interne FIFO das berl uft wenn der USB Transfer von FX2 zum Computer langsa mer ist als der Eingangsdatenstrom des Ethernet Transceivers Indem VHDL Schaltwerk ist in der ETH_USB_ Komponente ein Mechanismus implementiert mit dem diese Fehlerquelle in Form einer leuchtetenden LED bei berlauf detektierbar ist W hrend der 10 Einlesevor g nge die als Tests durchgef hrt wurden ist dieser Fehlerfall aber nicht aufgetreten 9 Zusammenfassung und Ausblick Diese Arbeit beschreibt die Entwicklung eines Analyse Systems mit dem die Untersu chung von propriet ren Ethernet basierten Kommunikationsprotokollen m glich ist Es wer den M glichkeiten aufgezeigt wie die Ankopplung an ein zu analysierendes Netzwerk reali siert werden kann Aus diesen M glichkeiten hat sich der Ethernet Tap als optimale L sung herausgestellt Um die Daten in den Computer einzulesen wurde eine Analyse durchgef hrt in der gepr ft wurde ob man einen Standard Ethernet Controller f r den Einlesevorgang verwenden kann Das Ergebnis dieser Analyse ist dass ein alternatives System n tig ist um die Daten ein zulesen Dies hat den Grund dass Ethernet Frames die nicht dem IEEE 802 3 Standard entsprechen von einem Ethernet Controller verworfen werden Mit dem Xilinx Spartan 3A Entwicklungsboard und dem Cypress FX2 Mikrocontroller wurde ein Einlesemodul realsiert
44. e Kosten gering zu halten 2 1 2 Anforderungen an das Einlesemodul Das Einlesemodul muss so beschaffen sein dass es den Datenstrom aus dem Ankopp lungszweig empf ngt und zum Computer bertr gt Es muss auf der physikalischen Schicht von Ethernet 100BASE TX arbeiten Der gesamte Datenstrom muss ohne Einschr nkungen analysierbar sein Deshalb darf die Einlese Hardware oder das Betriebssystem im Computer keine Teile des Datenstroms heraus filtern 2 Anforderungen 22 2 2 Anforderungen an die Analyse Software Modularit t Das Analyse System muss modular aufgebaut sein um es leicht an unter schiedliche Protokolle anpassen zu k nnen Echtzeitanforderungen Es ist nicht vorgesehen dass die Analyse in Echtzeit durchf hr bar ist weil auf dem Datenbus ein st ndiger Informationsaustausch zwischen den DEUs und dem Director herrscht Die Analyse dieser Datenmenge w re in Echtzeit nicht durchf hrbar Stattdessen sollen die empfangenen Daten zun chst in einer Datei zwischengespeichert werden Visualisierung der Daten Durch eine grafische Benutzeroberfl che soll der Datenstrom im Detail analysierbar sein Eine zus tzliche Darstellung in bin r Format ist erw nscht da mit der Benutzer einzelne Flags des Protokolls untersuchen kann ohne zwischen Hex und Bin rformat umrechnen zu m ssen Analysewerkzeuge zur Untersuchung des Datenstroms Um einen bestimmten Vor gang bei einer bertragung zu untersuchen sind nur bestimmte In
45. e ei nes Frame kenntlich macht Die Preambel des hybriden Protokolls ist hierzu geeignet Die Abbildung 6 2 zeigt das Zustandsdiagramm zur Detektion eines neuen Frame Das Eingangssignal des Automaten ist der Datenstrom des hybriden Protokolls Die Analy se des Datenstroms erfolgt Byte weise Der Initialisierungszustand ist der IDLE Zustand In diesem Zustand verharrt der Automat so lange bis ein Byte mit dem hexadezimalen Wert 0x55 als Eingangssignal vorkommt Dann erfolgt ein bergang in den Zustand PREABM BLE1 Wenn das folgende Byte ebenfalls den Wert 0x55 besitzt erfolgt ein bergang in den PREAMBLE2 Zustand Wenn nicht dann erfolgt ein bergang in den FRAME Zustand Mit diesem Verhalten soll erreicht werden dass der Automat bei der Erkennung von 7 Bytes mit dem Wert 0x55 hintereinander und einem folgenden Byte mit dem Wert OxD5 signalisiert dass eine Preambel also ein neuer Frame erkannt wurde Bei der Erkennung eines neuen Frame betr gt der Wert des Signals newF rame 1 sonst 0 EREAMBLET PREAMBLE2 0x55 PREAMBLE3 PREAMBLE4 PREAMBLES newFrame 0 PREAMBLE6 PREAMBLE7 newFrame 0 Abbildung 6 2 Zustandsdiagramm des Datenstrom Parser 6 Design des Interpretationsmoduls 75 6 2 4 Definition der Frameliste Wie bereits im Kapitel 6 2 2 beschrieben erzeugt der Parser eine verkettete Liste von pcap konformen Frames Der Vorteil einer verketteten Liste von Frames liegt darin dass man auf
46. e entwickelt durch die sich ein Einlesevorgang durchf hren l sst Die Benutzeroberfl che ist in Abbildung 8 2 zu sehen Die Benutzeroberfl che wurde mit der C Klassenbibliothek Qt entwickelt Die Schaltfl chen und Auswahlmen s wurden mit Elementen dieser Bibliothek realisiert H Datenlogger WEG FS u Funktionstest Benutzeraktionen Fortschritt m 1 Funktionstest Ethernetdatenstrom auf Fehler pr fen Starten eines a eink Einlesevorgangs i n SR gt Menge der Middle Line Upstream amp Downstream z einzulesenden Daten Jg Auswahl des Datenbusses Zeigt dem Benutzer den Fortschritt eines Einlesevorgangs an Abbildung 8 2 Screenshot der grafischen Benutzeroberfl che Um einen Einlesevorgang zu starten gibt es die Schaltfl che Bus Daten einlesen Durch einen Klick auf diese Schaltfl che wird die Methode readUSBDataSlot der Klasse HybridLoggerGUI aufgerufen Ein Auszug aus der Methode ist in Listing 8 1 zu sehen In dieser Methode werden wie in Kapitel 5 3 2 ausgearbeitet mit der Methode read die Daten Uber USB eingelesen Zeile 6 und mit saveRxData abgespeichert Zeile 7 Hier endet der Aufgabenbereich des Einlesemoduls Ab diesem Punkt beginnt der Parse Vorgang der Rohdaten In Zeile 9 wird ein Objekt der Klasse RawData erzeugt w hrend dem Konstruktor der bereits allokierte Speicherplatz als Zeiger bergeben wird Au erdem wird dem Konstrukto
47. e werden durch die Einheit CONTROL_PATH gesteuert E_RXD_IN E_RXD DATASTREAM I gt yY m gt USEC_COUNT_4BIT SEL E_RX_DV_IN ELRX_DV COUNT SEL gt set DATASTREAM_MUX SAMPLE_USEC USEC_COUNT_4BIT KK E END OUT I I sAMPLE_USEC USEC_COUNT k n USEC_COUNT CONTROL_PATH USEC_MUX USEC_COUNTER LU A gt E_RX_CLK RESET Abbildung 5 8 Aufoau der TIMESTAMP Einheit 5 Realisierung des Einlesemoduls 61 Die Komponente CONTROL_PATH wurde durch einen Zustandsautomaten realisiert dessen Zustandsdiagramm in Abbildung 5 9 zu sehen ist TIMESTAMP1 E_RX_DV 0 COUNT_SEL 0 SAMPLE_USEC 1 E_RX_DV_T1 1 SEL 1 COUNT_SEL 0 SAMPLE_USEC 1 E ER DN Ti COUNT_SEL 0 SAMPLE_USEC 0 E_RX_DV_T1 0 COUNT_SEL 3 SAMPLE_USEC 1 E_RX_DV_T1 1 COUNT_SEL 1 SAMPLE_USEC 1 E_RX_DV_T1 1 COUNT_SEL 5 SAMPLE_USEC 1 E_RX_DV_T1 1 SEL 1 COUNT_SEL 4 SAMPLE_USEC 1 E_RX_DV_T1 1 SEL 1 COUNT_SEL 2 SAMPLE_USEC 1 E_RX_DV_T1 1 SEL 1 Abbildung 5 9 Zustandsdiagramm des Kontroll Pfads der TIME_STAMP Einheit Solange das Signal E_RX_DV nicht gesetzt ist verharrt der Automat im IDLE Zustand Wenn Daten empfangen werden wird das Signal durch den Transceiver gesetzt und es erfolgt ein Zustandswechsel in den Zustand FRAME Solange E_RX_DV geseizt ist bleibt der Aut
48. eichnet Sol len Daten innerhalb des Bussystems bertragen werden kann nur der Host die Transfers initiieren Dies geschieht mit Hilfe von Sendeaufforderungen USB Deskriptoren sind Datenstrukturen die Informationen ber angeschlossene Endger te enthalten Uber den device Deskriptor kann zum Beispiel ein Ger t durch seine Vendor und Product ID identifiziert werden Endpunkte sind Puffer in die ein USB Controller Daten hineinschreiben kann oder heraus lesen kann Endpunkte in die der Controller Daten hineinschreibt werden OUT Endpunkte genannt und Endpunkte aus denen Daten herausgelesen werden werden IN Endpunkte genannt Die verf gbare Datenmenge die die Endpunkte fassen k nnen l sst sich durch die USB Deskriptoren ermitteln Transferarten Es gibt 4 Transferarten mit denen der Datenfluss im USB realisiert werden kann Bulk Transfers finden nur statt wenn auf dem Bus Zeit zum bertragen verf gbar ist Sie werden deshalb in der Regel f r zeitunkritische Datenaufkommen verwendet Wenn aber nur ein Endger t an den Bus angeschlossen ist kann mit diesem Transfertyp die h chste Datenrate aller Transfertypen erreicht werden Die theoretisch maximal erreichbare Datenrate betr gt 384 MBit s 4 Design des Einlesemoduls 49 Interrupt Transfers besitzen Interrupt Endpunkte ein Abfrage Intervall das sicherstellt das sie vom Host regelm ig abgefragt werden Sie werden daher verwendet wenn Daten in nerhalb eines bestim
49. eiterer Nachteil bei dem 2 Konzept ist dass zu jedem Zustand immer 256 Zeiger geh ren was Speicherplatz kostet Ein Vorteil von dem 2 Konzept ist dass die Zustands berg nge in der Anwendung schnell von statten gehen da eine Lookup Tabelle im Gegensatz zu Abfragen von Bedingungsausdr cken schneller ist Um die genannten Vor und Nachteile erarbeiten zu k nnen wurde 2 Konzept f r die Realisierung der Konvertierungssoftware umgesetzt 7 2 Realisierung eines Wireshark Dissectors F r die Realisierung der Wireshark Dissectors wurde der Skeleton Code aus der Quel le Wireshark erweitert Die Entwickler Gemeinde von Wireshark stellt diesen Quelltext f r die Entwicklung von Dissectors zu Verf gung Es wurden drei Dissectors f r das Top Line Upstream Top Line Downstream und Middle Line Protokoll erstellt skeleton engl Ger st WON N 7 Realisierung der Interpretationssoftware 83 7 2 1 Auswahl des Datenbusses Die Auswahl mit welchem Protokoll die Daten interpretiert werden sollen wird vom Benut zer eingestellt Die Auswahl wird durch den Parameter network des Global Header vgl Kapitel 6 1 realisiert Dieser Parameter stellt eine Zahlenkonstante dar die den Protokoll Typ identifiziert Das Konvertierungsprogramm ber cksichtig diesen Parameter in der Klasse PcapHeader Im Listing 7 4 ist die Funktion proto_reg_handoff_hybrid_nonrt zu sehen Zeile 1 Diese Funktion hat den Zweck
50. en Netzwerk Datenverkehr Die bei den Bibliotheken erhalten die Ethernet Frames von dem jeweiligen Betriebssystem Das Be triebssystem kommuniziert ber einen Treiber mit der Netzwerkkarte Das bedeutet dass es von dieser Komponenten Zusammensetzung abh ngt welche Daten sich mit dem Analyse Programm anzeigen lassen Zusammenfassung Die zu entwickelnde Analyse Software ist vergleichbar mit einem Sniffer Programm mit dem die Analyse des Datenstroms m glich ist Das zu entwickeln de Analyse System soll Daten auf der physikalischen Schicht von Ethernet 100BASE TX analysieren Es ist zu pr fen welche Komponenten Zusammensetzung n tig ist um den Datenstrom einzulesen sniffer engl Schn ffler 2to capture engl empfangen 3 Konzept Der Systemaufbau f r den Protokollanalysator ist in Abbildung 3 1 zu sehen In diesem Ka pitel wird gepr ft welche Technologien und Bauteile f r die jeweiligen Systemkomponenten in Frage kommen Es werden Alternativen vorgestellt die bewertet werden Downstream Pfad Hybrider Datenbus Top oder Middle Line Uptream Pfad Ankopplungszweig Downstream Pfad Ankoppiungszweig Upstream Pfad Rohdaten Abbildung 3 1 Aufbau des Gesamtsystems 3 Konzept 26 3 1 Busankopplung 3 1 1 Passive Ankopplung Um die Busankopplung an das Bussystem zu realisieren gibt es verschiedene M glich keiten Die ideale Ankopplungsart ist eine rein passive Ankopplung da dadurch ke
51. endes char Feld aus den Rohdaten Die Abbildung 6 1 zeigt das Klas sendiagramm RawData datastream unsigned char index static unsigned int count unsigned int RawData char filename unsigned char rxDataBuffer RawData getPayload atEnd unsigned int getIndex unsigned int getLength unsigned int getCharacter int i unsigned char nextByte unsigned char indexToBegin void Abbildung 6 1 Klassendiagramm der Klasse RawData 6 2 2 Konvertierung der Daten mit der HybridToPcapParser Klasse Eine Instanz der Klasse RawData benutzt ein Parser um die Rohdaten in das pcap Format zu konvertieren Dieser Parser ist eine Instanz der Klasse HybridToPcapParser Die ses Objekt erzeugt als Ergebnis des Parse Vorgangs ein PcapFrameList Objekt das die pcap konformen Frames in Form einer einfach verketteten Liste von PcapFrame Objekten beherbergt Jedes PcapFrame Objekt enth lt die Informationen die von dem Pcap Dateiformat f r die Speicherung der Daten vorgesehen sind vgl Kapitel 6 1 6 Design des Interpretationsmoduls 74 6 2 3 Parsen der Daten Der Parser soll aus dem Datenstrom einzelne Frames extrahieren um sie in einer pcap Datei abspeichern zu k nnen Die Klasse HybridToPcapParser verwendet einen Zustands automaten f r den Parse Vorgang Um die Frame Abgrenzungen in den Rohdaten erkennen k nnen ben tigt der Parser eine definierte Zeichenfolge die den Start oder das End
52. ept erarbeitet in dem dargestellt wird welche Hardware und Software Komponenten f r die Entwicklung des Analyse Systems zum Einsatz kom men k nnen Infolge dessen wurde mit Hilfe des Xilinx Spartan 3A Starterkit und des Cypress FX2 Mikrocontroller ein Hardwaresystem f r das Einlesen eines Da tenstroms aus dem propriet ren Kommunikationssystem entwickelt Die Analyse der Daten erfolgt mit Hilfe des Programms Wireshark Die individuelle Protokoll Analyse wurde durch die Entwicklung von Wireshark Dissectors realisiert Um die propriet ren Kommunikationsprotokolle mit Wireshark analysieren zu k nnen wurde ein Konver tierungsprogramm entwickelt das die Roh Daten in das Wireshark konforme pcap Dateiformat konvertiert Jan Erik Lange Title of the paper Development of a modular analyzer for proprietary Ethernet based communication protocols Keywords Ethernet Xilinx Cypress Wireshark protocol analysis Abstract A proprietary communication protocol of a cabin management has been developed at the company Airbus Operations For the development of devices using this pro tocol a way needs to be created to read and to analyse the data traffic in the cabin management system A concept has been worked out which hardware and software components can be used for the development of the data analysis system As a result a hardware system for reading the datastream from the proprietary communication system has been de veloped This hardw
53. er ty eel Seige EE 3 1 1 Passive Ankopplung 3 1 2 Daisy Chain Ankopplung aoa a 3 1 3 Verwendung eines Ethernet 100BASE TXHub 3 1 4 T St ck mit Ethernet Transceiven 3 1 5 Verwendung eines Ethernet Tap 11 11 11 12 13 13 13 14 15 16 16 17 20 20 20 21 22 23 23 24 Inhaltsverzeichnis 6 3 22 Einlesemodul amp 2 a Ya ea Ze dE ie re 34 3 2 1 Einsatz eines Ethernet Controllers als Einlesemodul 34 3 2 2 Alternative zum Ethernet Controller e 36 3 2 3 bertragung zum Computer 37 3 2 4 Einlesesoftware 39 3 3 Analysesoftware 41 3 3 1 Entwicklung eigener Software a 2 2 nme 41 3 3 2 Erweiterung f r Wireshark 2 2 2202 2 200 2 a0 2 nn ne aa 43 3 3 3 Fazit f r die Analysesoftware 43 3 4 Zisammenlassung see ee ea ce a ee den 44 4 Design des Einlesemoduls 45 4 1 Erstellung eines Blockdiagramm 45 4 2 Entwurf des VHDL Schaltwerks 45 4 2 1 Das interne FIFO 2 000000 22 eee 46 4 2 2 Anh ngen der Zeitstempel oaoa a a 46 4 2 3 Tauschen der 4 Bit Nibbles 47 4 2 4 Ansteuerung des Slave FIFO Interface des FX2 47 4 3 Cypress FX2 Firmware gt 4 2 ne ca ig nr 48 4 3 1 Einf hrung zum Universal Serial Bus 48 4 3 2 Verst ndnis zum Cypress FX2 Mikrocontroller 2 222 50 4 3 3 Festlegen des Transfertyps 51 4 3 4 Synchroner oder asynchroner Betrieb
54. et F ngt diese LED w hrend eines Einlesevorgangs an zu leuchten ist dies ein Indikator f r den Benutzer dass das interne FIFO voll ist und die Daten fehlerhaft sein werden Nachdem der Z hler den Wert 125000000 berstiegen hat erfolgt ein Zustands bergang in den Zustand AWAIT_FULL In diesem Zustand wartet der Automat solange bis das FULL Signal des internen FIFOs zur ckgesetzt ist Sobald ein neuer Einlese Vorgang begonnen hat und deshalb das FULL Signal zur ckgesetzt wird erfolgt ein bergang in den Zustand RESETTING In diesem Zustand wird das Signal RESET_OUT gesetzt was bewirkt dass s mtliche Schaltwerk Einheiten au er der MIILCOUNT_GEN Einheit zur ckgesetzt wer den Danach erfolgt der Zustands bergang in den Zustand RECEIVING in dem der Automat wieder solange verharrt bis das FIFO voll wird 5 Realisierung des Einlesemoduls 68 5 2 Cypress FX2 Firmware In diesem Kapitel wird die Realisierung der Firmware f r den Cypress FX2 Mikrocontroller dokumentiert Wie im Kapitel 4 3 beschrieben muss der FX2 im Slave FIFO Modus arbeitet Au erdem sind eine Reihe weiterer Ma nahmen erforderlich damit der Mikrocontroller wie gew nscht den Datenstrom zum Computer bertr gt Als Grundlage f r die Firmware wurde eine Firmware angepasst die im Benutzerhandbuch des FX2 zu finden ist vgl Cypress TRM S 188 Die komplette Firmware ist im elektronischen Anhang A zu finden Die Werte f r die elementaren Register werde
55. formationen von Inter esse Dazu wird eine Filterfunktion ben tigt mit der man sich durch Benutzervorgaben nur bestimmte Frames anzeigen lassen kann Eine Sortierfunktion ist auch hilfreich Zeitinformationen zu den Frames Eine Anforderung f r die Analyse der Daten ist dass Zeitinformationen zu den Frames zur Verf gung stehen um das Zeitverhalten untersuchen zu k nnen Die Genauigkeit sollte mindestens 1 us betragen Protokollerkennung Die Auswahl ob es sich bei den Rohdaten um einen Datenstrom handelt der aus der Top Line oder Middle Line kommt und ob er auf dem Downstream oder Upstream Pfad mitgelesen wurde soll durch den Benutzer konfigurierbar sein Die Software dient der Analyse und der Fehlersuche Daher ist eine Automatik bei eventuell fehlerhaften Frames nicht sinnvoll Im Datenbus des CIDS herrscht ein Broadcast von dem Director zu den DEUs Alle 31 25 us wird ein Echtzeit Frame vom Direktor verschickt Innerhalb von 1 s werden daher 32000 Echtzeit Frames verschickt Zwischen den Echtzeit Frames werden im hybriden Datenbus zus tzlich Nicht Echzeit Frames verschickt Bei der Analyse der Daten w re es f r den Be nutzer des Analysesystems zu viel Aufwand manuell f r jeden Frame festzulegen ob er als Echtzeit oder Nicht Echtzeit Frame interpretiert werden soll 2 Anforderungen 23 Innerhalb des empfangenen Datenstroms muss das Analysewerkzeug deshalb selbst ndig erkennen k nnen ob es sich um einen Nicht Echtzeit Fra
56. ger te die eine Bitfehler ratenmessung am bertragungskanal durchf hren k nnen Mit dem AXS 200 850 der Firma EXFO lassen sich zum Beispiel Bitfehlerraten und Jittermessungen des Digitalsignals durch f hren vgl EXFO Mit dem gleichen Ger t lassen sich auch Messungen durchf hren ob die Sendestationen die Frame Check Sequence FCS korrekt berechnen Diese Messungen entsprechen Analysen eines Netzwerks auf der Sicherungsschicht und der physikalischen Schicht 2 Anforderungen 24 2 3 2 Analyse eines Netzwerks ab der Vermittlungsschicht Es gibt verschiedene Anwendungsf lle f r die Analyse von Netzwerken ab der Vermittlungs schicht Mit Hilfe von Last Profilen l sst sich zum Beispiel anzeigen welche Datenmenge je Zeiteinheit ber die Datenleitung bertragen wird Diese Analysem glichkeit wird zum Bei spiel zur Planung von Firmennetzwerken angewendet Zur Analyse von Sicherheitsl cken in einem Computernetzwerk werden LAN Analysen durchgef hrt vgl synapse Bei LAN Analysen werden Sniffer Programme verwendet um den Datenstrom grafisch darzustellen Ein Beispiel f r ein Sniffer Programm ist Wireshark Wireshark stellt den Datenverkehr den das Betriebssystem zur Verf gung stellt grafisch dar Den Datenverkehr erh lt Wireshark dabei ber Programmbibliotheken Unter Windows lautet diese Bibliothek winpcap und unter Linux libpcap Diese Bibliotheken werden auch capture engines genannt und erm glichen Zugriff auf d
57. i jedem vierten Frame die Differenz 32 us betr gt weil die exakte Differenz 31 25 us lautet Au erdem wird die Frame L nge angezeigt Unter diesen Informationen wird der Inhalt des Frame angezeigt Dabei wird der Frame in die Felder des jeweiligen Protokolls wie das Type oder das DEU Address Feld aufgesplittet Im unteren Fensterteil wird der Frame in Roh Form wahlweise in Hex oder Bin r Format angezeigt EIER File Edit View Go Capture Analyze Statistics Telephony Tools WSinternal Help TAAA SaAxesS Qe OFS F8 aaa ZZ BURKE Fiter Y Expression No Time Source Destination Protocol Info E 22800 0 692817 HYBRID_TOPLINE_RT_UPSTREAM 22801 0 692825 HYBRID_NONRT 22802 0 692849 HYBRID_TOPLINE_RT_UPSTREAM 22803 0 692856 HYBRID_NONRT 22804 0 692880 HYBRID_TOPLINE_RT_UPSTREAM 22805 0 692887 HYBRID_NONRT 22806 0 692911 HYBRID_TOPLINE_RT_UPSTREAM 22807 0 692943 HYBRID_TOPLINE_RT_UPSTREAM 22808 0 692974 HYBRID_TOPLINE_RT_UPSTREAM ze gt Frame 22808 76 bytes on wire 608 bits 76 bytes captured 608 bits arrival Time Jan 5 2011 14 09 04 693042000 Westeuropb sche Normalzeit Epoch Time 1294232944 693042000 seconds Time delta from previous captured Frame Time delta from previous displayed fra co Time since reference or first frame 0 692974000 seconds Frame Number 22808 Frame Length 76 bytes 608 bits Capture Length 76 bytes 608 bits Frame is marked False Frame is ignored F
58. iderstandes mit Hilfe eines bertragers Um eine Widerstandsanpassung zu erreichen m sste man ein Windungsverh ltnis von e49 1 1 4181 3 1 verwenden Dann sieht man am Abzweigepunkt eine Impedanz von R N N 1 415 R R Ein Nachteil ist dass durch diese Anpassung die Spannung auf der Sekund rseite wiederum heruntertransformiert wird Ny U N2 1 gt U U U 0 709 DU 3 3 Ny Up NM 1a l ES Dieses Verhalten birgt wiederum de Gefahr dass die Empf nger das Signal nicht korrekt detektieren k nnen Die weitere Verfolgung dieses Ansatzes der Busankopplung wird nicht weiter verfolgt da dies nicht den Schwerpunkt dieser Arbeit darstellt Diese Ankopplungsart ist aufgrund der Verschlechterung der Signalqualit t des Ethernet Signals nicht geeignet 3 Konzept 30 3 1 2 Daisy Chain Ankopplung Eine M glichkeit zur Ankopplung an den CIDS Bus ist die Eigenschaft der Netzwerkar chitektur auszunutzen Jedes Kettenglied reicht alle ankommenden Daten an das n chste Kettenglied weiter Abbildung 3 6 Nicht Echtzeit Daten Downstream Upstream Echtzeit Daten Abbildung 3 6 Busankopplung mit der Daisy Chain Methode Die Ankopplung an den Downstream Pfad ist ber die letzte DEU in der Kette m glich in dem man den Ankopplungszweig an ihren Downstream Tx Port anschlie t M chte man sich an den Upstream Pfad ankoppeln m sste der Datenstrom Multiplexe
59. ie zeitliche Verwaltung der Transfers der Funktionsbibliothek sodass die Pause zwischen den Transfers minimal klein wird Die blau hinterlegte Fl che in der Abbildung 4 5 verdeutlicht dass bei der Annahme dass der Treiber libusbO sys keine Pausen zwischen Transfers macht ein st ndiger Datentransfer besteht Sendeaufforderung 2 Sendeaufforderung 3 Sendeaufforderung 1 usb_submit_async f r Sendeaufforderung 1 3 usb_reap_async f r Sendeaufforderung 1 Daten der Sendeaufforderung 1 sind angekommen usb_submit_async f r Sendeaufforderung 1 usb_reap_async f r Sendeaufforderung 2 Abbildung 4 5 Zeitverhalten der asynchronen API 5 Realisierung des Einlesemoduls 5 1 VHDL Schaltwerk Im Folgenden wird die Realisierung des VHDL Schaltwerkes dokumentiert In den Unter kapiteln werden die Teilbl cke des in der Abbildung 5 1 abgebildeten Systems beschrieben S mtliche Systembl cke au er dem MII_COUNT_GEN Block werden mit der ansteigenden Takt Flanke abgefragt Zu s mtlichen Systembl cken wurden VHDL Testbenches erstellt um die korrekte Funktion zu berpr fen Der MI COUNT GEN Block wurde f r Testzwecke er stellt Wenn das Analyse System Ethernet Daten empfangen soll nimmt das wirkliche MII des Transceivers den Platz dieser Komponente ein Die VHDL Quelltexte und die Testbenches sind im elektronischen Anhang zu finden Im An hang A ist der Pfad zu den Dateien des elektronischen Anhangs beschrieben
60. iesem Problem muss man sich im Klaren dar ber sein dass in der Datenver arbeitung die kleinste ansprechbare Dateneinheit ein Byte ist Die Uber USB empfangenen Bits werden deshalb spatestens im Computer in Bytes eingeteilt Sind die Nibbles um eine Position versetzt werden die Daten folgenderma en vom Computer eingelesen F 0 ungew nschtes Verhalten 0 1 gew nschtes Verhalten Wale CID E A B C D E F Tabelle 5 1 Fehlerhafter Datenstrom aufgrund versetzter Nibbles 5 Realisierung des Einlesemoduls 58 Analyse des Fehlers In der Abbildung 5 5 ist der Ursprung dieses Fehlers zu erkennen Bei der Markierung 1 wird das globale System Reset Signal auf 0 gesetzt Zu diesem Zeit punkt empf ngt der Transceiver aber schon Daten Da das E_RX_DV Signal gesetzt ist be ginnt die Einheit damit die Nibbles zu tauschen Sie beginnt damit aber bei einer ungeraden Position der Nibbles siehe Markierung 2 Dadurch wird die Reihenfolge der Nibbles nicht korrigiert sondern weiter verf lscht Markierungen mit wei em Pfeil feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rx_clk feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c reset feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rx_dv feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxd feth_usb_test dut swap_nibbles_toplevel_cjswap_nibbles_c qint feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c en_rxd1 feth_usb_test dut swap_nibbles_toplevel_c
61. ignal 2 2 2 mann une 65 5 14 Zustandsdiagramm der ETH_USB_CONTROLPATH Einheit 66 5 15 Klassendiagramm der Klasse USBHandler 69 5 16 Flussdiagramm f r die Einlesefunktion 00 70 5 17 Klassendiagramm der Klassenhierarchie CalcCRCPcap 71 6 1 Klassendiagramm der Klasse RawData 20 73 6 2 Zustandsdiagramm des Datenstrom Parser 74 6 3 Klassenhierarchie der Klasse PcapFrameList 76 6 4 Klassendiagramm der Klasse PceapFile 77 6 5 Baumstruktur zur bersicht ber die verschiedenen Protokolltypen 78 7 1 Klassenhierarchie der Klasse Stateltem 81 8 1 Verbindung der Hardwarekomponenten 87 8 2 Screenshot der grafischen Benutzeroberflache 88 8 3 Screenshot von Wireshark 90 1 Einleitung 1 1 Vorstellung des Unternehmens Airbus begann 1985 mit der Entwicklung eines integrierten Kabinenmanagement Systems dem Cabin Intercommunication Data System CIDS Dieser Bereich wuchs sehr schnell sodass im Jahre 1991 daraus der Standort in Buxtehude entstand 1995 wurde KID Systeme als ein Profitcenter mit Sitz im Standort Buxtehude gegr ndet Am Standort entwickelte Produkte die an andere Flugzeughersteller wie z B Boeing verkauft werden tragen die Marke KID Systeme 1999 wurde KID Systeme als 100 ige Tochter von Airbus eine eigene Firma mit Sitz im Standort Buxtehude In 2005 wurde das Werk in B
62. inerlei Zeitverz gerung entsteht Bei der passiven Ankopplung wird f r die Busankopplung ein Y Kabel verwendet Dabei wird ein weiteres Leitungsst ck an die Leitung gel tet und an das Analyse System angeschlossen Auswirkungen der Ankopplung mit einem Y Kabel Der Wellenwiderstand einer Cats UTP oder STP Leitung betr gt 100 2 Durch das Paral lelschalten der Leitungen sieht die Leitung mit der Signalquelle am Ankopplungspunkt den halben Wellenwiderstand mit einem Wert von 50 Q Abbildung 3 2 Dadurch ist zu erwarten dass Reflexionen auf der Leitung entstehen Durch Reflexionen entsteht eine schlechte Si gnalqualit t was eventuell zur Folge hat dass die Empfangsschaltung die Signale nicht mehr korrekt detektieren kann In einer Messung muss die Signalqualit t berpr ft werden 100 Ohm 100 Ohm JI 100 Ohm Abbildung 3 2 Parallelschaltung von zwei Leitungen Abzweigung zum Analysator Leitung zwischen zwei DEUs 3 Konzept 27 Messungen am Y Kabel Um bei digitalen Signalen die Signalqualit t messtechnisch erfassen zu k nnen verwendet man das Augendiagramm Das Augendiagramm ist die Summe aller bereinander gezeich neten Ausschnitte eines Digitalsignals deren Dauer jeweils gleich der Taktperiode ist Um alle m glichen berg nge zu erfassen muss das Digitalsignal n herungsweise ein Zufalls signal sein Es wurde ein Augendiagramm f r den Fall mit Abschlusswiderstand an der Abzweigelei
63. jeden Frame der Rohdaten einzeln zugreifen kann Durch wenige nderungen in der Softwa re k nnen so zus tzliche Programm Funktionen eingef gt werden k nnen Die Realisierung der CRC Prusummenberechnung von IEEE 802 3 konformen Frames f r die Verifikation des Einlesemoduls ist ein Beispiel in dem man von der Listenstruktur profitiert Um eine verkettete Liste zu realisieren bietet es sich an den Container list der Standard Template Library STL von C zu verwenden Mit diesem Template kann eine Liste von Objekten eines bestimmten Typs erstellt werden Der Vorteil von dieser L sung ist dass viele Funktionen f r die Verarbeitung einer Liste bereits implementiert sind Im Laufe der Realisie rung der Software kam es zu Abst rzen des Programms Die Fehlerquelle hierf r lag beim L schen der Frame Liste die mit dem Template der STL realisiert wurde Da diese Frame Liste nicht den Schwerpunkt des Analyse Systems darstellt wurde die exakte Lokalisierung des Fehlers wegen Mangel an Zeit nicht ausf hrlicher behandelt Stattdessen wurde eine eigene verkettete Liste definiert Template engl Schablone 6 Design des Interpretationsmoduls 76 Das Klassendiagramm der einfach verketteten Liste ist in Abbildung 6 3 zu sehen Die Klasse PcapFrame beschreibt einen einzelnen Frame mit seinen Informationen Die At tribute ts_sec und ts_usec beschreiben zum Beispiel den Zeitstempel eines Frame PcapFrameNode ist eine abgeleitete Kla
64. kennen ist be finden sich in diesem Controller die Komponenten PHY und MAC Dies bedeutet dass in diesem Controller die Schichten 1 und 2 des OSI Schichtenmodells fest eingebaut sind SSV NM Async Transmit Queue Magnetics RJ45 Abbildung 3 10 Aufbau des Ethernet Controllers Yukon FE 88E8040 der Firma Marvell vgl Marvel Um zu pr fen ob unter diesen Voraussetzungen die Frames des hybriden Protokolls emp fangen werden k nnen wird Bezug auf die Arbeitsgruppe IEEE 802 3 genommen vgl IEEE 802 3 Die Arbeitsgruppe hat das Aussehen eines Ethernet konformen Frames definiert 3 Konzept 35 Definition ung ltiger Frames Der Abschnitt 3 4 Invalid MAC frame sagt aus dass ein Frame ung ltig ist wenn e die auf dem empfangenen Frame berechnete Pr fsumme nicht mit der sich im FCS Feld befindenden Pr fsumme bereinstimmt vgl 4 2 4 1 2 Frame check sqeuence validation e die Framel nge nicht mit dem Wert bereinstimmt der im L ngen Typ Feld des Frame steht Es kann auch sein dass in diesem Feld ein Typ Wert steht Wenn dieser Wert ein g ltiger Typ Wert ist gilt der Frame als g ltig e wenn die Anzahl der Bits im Frame kein Vielfaches von 8 ist Minimale Framel nge Der Abschnitt 4 2 4 2 2 Collision filtering sagt aus dass Ethernet 100BASE TX konforme Frames eine minimale L nge von 512 Bits haben m ssen Wenn ein Frame k rzer ist wird davon ausgegangen dass er
65. l m gliche Datenrate des hybriden Bussystems Es gibt vier verschiedene Transferarten die f r bestimmte Applikationen ausgelegt sind Mit Interrupt Transfers lassen sich kontinuierliche Datenraten erzielen Dieser Transfertyp f hrt au erdem eine Fehlerkor rektur durch sodass man die Gewissheit hat dass die bertragenen Daten korrekt sind Bei Recherchen f r m gliche Hardware wurde der Cypress FX2 Mikrocontroller gefunden Dieser Controller l sst sich als Slave FIFO konfigurieren und kann auf diese Weise von einem externen Ger t gesteuert werden und Daten zum Host PC senden Laut Cypress ist die volle Datenrate die mit USB 2 0 m glich ist mit dem FX2 realisierbar Hier kommt es darauf an wie leistungsf hig die Software ist die mit dem FX2 kommuniziert F r die Kommunikation mit dem FX2 gibt es zwei Alternativen Es gibt die Funktionsbibliothek libusb f r Linux beziehungsweise libusb win32 f r Windows durch die man mit USB Ger ten kommunizerien kann Au erdem gibt es das WinDriver driver development kit von der Firma Jungo Diese beiden Alternativen werden in Kapitel 3 2 4 n her vorgestellt Mit 66 Euro pro St ck ist der Preis f r ein Erweiterungsboard auf dem dieser Controller integriert ist g nstig genug Diese Argumente machen USB 2 0 zu der optimalen bertra gungstechnik f r diese Anwendung 3 Konzept 39 3 2 4 Einlesesoftware F r die Kommunikation zwischen dem Schaltwerk im FPGA und dem Computer
66. m mit einem Computer analysieren zu k nnen muss zun chst eine Bu sankopplung an den Datenbus geschaffen werden Im Folgenden werden die Anforderungen diese Ankopplung dargestellt 2 1 1 Anforderungen an die Busankopplung Vermeidung zeitlicher Belastung Der hybride Datenbus darf maximal einer zeitlichen Verz gerung von t lt lus pro DEU ausgesetzt sein W re die Verz gerung l nger dann k me es zu Fehlfunktionen im Bussystem Mathematisch l sst sich das Verhalten des An kopplungssystems mit der Gleichung g t s t t 2 1 ausdr cken Dabei ist s t das Eingangssignal und g t das Ausgangssignal Vermeidung von Reflektionen Durch das Einf gen des Ankopplungsglieds in die Leitung darf der Wellenwiderstand der Leitung nicht verandert werden Die Abschlusswiderstande an den Leitungsenden sind dann nicht gleich dem Wellenwiderstand was dazu f hrt dass es zu Reflexionen an den Leitungsenden kommt AuBerdem besteht dann keine Leistungs anpassung mehr was sich beim Empfanger ebenfalls durch eine schlechte Signalqualitat bemerkbar macht 2 Anforderungen 21 Ankopplung beider bertragungsrichtungen Die Ankopplung muss so realisiert wer den dass sich das bertragungsmedium beider bertragungsrichtungen ankoppeln l sst Es ist aber nicht zwingend notwendig dass beide Richtungen gleichzeitig ankoppelbar sind Off the shelf Komponenten Es sollten wenn m glich nur Off the shelf Komponenten verwendet werden um di
67. me oder einen Echtzeit Frame han delt Eine Automatik ist in diesem Fall nicht zu vermeiden Eine automatische Erkennung der Frame Typen setzt voraus dass im Frame ein Indikator vorhanden ist durch den die Auto matik die Erkennung durchf hrt Wenn der Indikator fehlerhaft ist wird die Automatik nicht korrekt funktionieren Wie bereits erw hnt dient die Software der Analyse und Fehlersuche eines Protokolls Ei ne automatische Fehler Detektion der empfangenen Frames des hybriden Protokoll ist da her nicht vorgesehen Durch geeignete Tests muss deshalb sichergestellt werden dass das Analyse System den Datenstrom m glichst fehlerfrei einliest Durch den modularen Aufbau des Systems soll es aber m glich sein bei Bedarf die Software in der Art zu erweitern dass eine Fehlererkennung durchf hrbar ist 2 3 Recherche zu bestehenden Analyse Systemen Es gibt verschiedene M glichkeiten zur Analyse von Kommunikationsnetzen F r die Ent wicklung dieses Analyse Systems wurde deshalb eine Recherche zu bestehenden Analyse Systemen durchgef hrt um feststellen zu k nnen welche Art von Analyse System die ge nannten Anforderungen erf llt Um einen berblick ber die Analyse Arten zu erhalten l sst sich das OSI Schichtenmodell benutzen mit dem die verschiedenen Arten logisch vonein ander getrennt werden k nnen 2 3 1 Analyse eines Netzwerks auf der physikalischen Schicht Zur Analyse eines Netzwerks auf physikalicher Schicht gibt es Test
68. mit Hilfe eines XML Baumes erfolgen in den die Informationen aus den Frames des hybriden Protokolls eingef gt werden 1 Zur Verwaltung eines XML Baumes gibt es spezielle Funktionsbibliotheken F r C gibt es zum Beispiel die Qt Klasse QDomDocument um einen solchen Baum zu er stellen und ihn zu verwalten Zur Visualisierung k nnten die Frames als Baumstruktur in einem Browser oder in einer selbstgeschriebenen ausf hrbaren Anwendung ange zeigt werden 2 Mit der selben Klasse k nnte der XML Baum geparst werden Beim Parsen k nnten mit Hilfe von Bedingungen nur bestimme Knoten anzeigt werden und so zum Beispiel Filter realisiert werden Im Gegensatz zu einem Datenbanksystem stehen aber keine optimierten Algorithmen zur Verf gung 3 Zum Erzeugen der XML Datei ist ein zu entwickelndes Programm n tig das den ge speicherten Datenstrom analysiert und in einen XML Baum einf gt Dieses Programm muss wie in der Datenbank Alternative leicht anpassbar sein um nderungen an der Protokoll Definition vornehmen zu k nnen Bewertung Ein Vorteil dieser L sung ist dass man nicht zwingend ein Programm schreiben muss um die Daten zu visualisieren Jeder Browser kann wohlgeformte XML Dokumente als Baumstruktur anzeigen lassen Wenn man aber Filter und Sortierfunktionen hinzuf gen m chte muss man zus tzliche Software entwickeln Ein Nachteil ist dass man ein Programm entwickeln muss das die Daten parst und in den XML Baum einf gt und ein
69. mten Zeitraums bertragen werden m ssen Die theoretisch maximal erreichbare Datenrate betr gt 192 MBit s Wenn man Daten mit einer konstanten Datenrate bertragen m chte sind Isochrone Trans fers n tzlich Isochone Transfers werden zum Beispiel bei der Echtzeit bertragung von Spra che und Musik verwendet Zum Austausch von Daten ist dieser Transfertyp nicht geeignet da es hier keine Fehlerkorrektur gibt Sie eignen sich also nur f r Transfers bei denen gele gentlich Fehler akzeptabel sind Die theoretisch maximal erreichbare Datenrate betr gt 192 MBit s Control Transfers dienen dazu kurze Datenpakete sicher zu transferieren Mit Control Trans fers werden die USB Endger te vom Host Controller konfiguriert Die theoretisch maximal erreichbare Datenrate betr gt 4 MBit s 4 Design des Einlesemoduls 50 4 3 2 Verst ndnis zum Cypress FX2 Mikrocontroller Im Slave FIFO Modus erlaubt der FX2 einer externen Schaltung ber Steuer Status und Datensignale Daten ber USB zum Host Computer zu bertragen Der Unterschied zu ei nem normalen FIFO ist dass die Daten die in das Slave FIFO hineingeschrieben werden ber eine integrierte Schaltung im FX2 in die USB IN Endpunkte eingegeben werden Von dort aus werden sie automatisch zum Computer bertragen Dieser Vorgang passiert ohne Einwirkung der CPU des FX2 Das hat den Grund dass bei einer hohen Belastung der CPU die Datenrate nicht einbricht vgl Cypress TRM S 163ff
70. n im Folgenden beschrieben Interface Configuration IFCONFIG 0x03 In diesem Register wird festgelegt dass der FX2 e als Slave Fifo arbeitet e eine externe Taktquelle verwendet e und im synchronen Modus arbeitet Endpoint 6 Slave FIFO Configuration EP6FIFOCFG 0x0D In diesem Register wird festgelegt dass e der AUTOIN Modus verwendet wird e und der Eingangsdatenbus des Slave FIFO 16 bit breit ist Endpoint 6 Configuration EP6CFG 0xF0 In diesem Register wird festgelegt dass e die Ubertragungsrichtung IN lautet e der Endpunkt 6 aktiv ist Interrupt Transfer zur Ubertragung verwendet wird der Endpunkt Buffer 512 Byte gro ist und quad buffering angewendet wird 5 Realisierung des Einlesemoduls 69 5 3 Einlesesoftware 5 3 1 Definition einer Klasse zum Einlesen Zur Kommunikation mit dem FX2 wurde eine Klasse definiert die alle F higkeiten enth lt die man f r die Initialisierung der Funktionsbibliothek libusb win32 und zur Kommunikation mit dem FX2 ben tigt Diese Klasse tr gt den Namen USBHandler Um mit dem FX2 zu kom munizieren wird eine Methode ben tigt die das Ger t identifiziert Diese Methode wurde findDevice benannt Eine weitere Methode ist n tig die libusb initialisiert Sie wurde init benannt Es bietet sich an dass diese Methoden durch den Konstruktor der Klasse USBHandler ausgef hrt werden Um die Klasse in einer grafischen Benutzeroberflache
71. ndung mit einem FPGA verwendet Es wird das Xilinx Spartan 3A Starter Kit benutzt Um die Daten zum Computer zu bertragen wird der Cypress FX2 Mikrocontrol ler in der Art vom FPGA gesteuert dass dieser den Datenstrom ber USB zum Computer bertr gt Computerseitig werden die Daten ber die Funktionsbibliothek libusb win32 eingelesen da f r die Nutzung dieser Bibliothek keine Kosten anfallen Zur Analyse der Daten wird Wires hark verwendet da die Vorteile die dieses Programm bietet in einer selbst geschriebenen Anwendung nur mit viel Aufwand verwirklicht werden k nnen 4 Design des Einlesemoduls Die Aufgabe des Einlesemoduls ist den Datenstrom aus dem Ankopplungszweig zu emp fangen und zum Computer zu senden In diesem Kapitel wird das Design des Einlesemoduls dokumentiert 4 1 Erstellung eines Blockdiagramm In Abbildung 4 1 ist ein Blockschaltbild zu sehen das die Dokumentation des Entwurfs des Einlesemoduls unterst tzt S mtliche Komponenten die in diesem Kapitel erkl rt werden finden sich in diesem Blockschaltbild wieder Abbildung 4 1 Systembl cke des Einlesemoduls 4 2 Entwurf des VHDL Schaltwerks Da kein Ethernet Controller sondern ein Ethernet Transceiver in Verbindung mit einem FPGA und dem FX2 Mikrocontroller verwendet wird musste ein Schaltwerk entworfen werden das den Datenstrom in geeigneter Art dem FX2 Mikrocontroller zur Verf gung stellt der diesen ber USB zum Computer bertr gt Das De
72. ne Steuerpfad Komponente erstellt die die SWAP_NIBBLES Einheit kontrolliert Das Verhalten der Steuerpfad Einheit wurde mit einem Zustandsautomaten modelliert dessen Zustands diagramm in Abbildung 5 7 zu sehen ist Der Zustandsautomat bleibt wenn nach einem System Reset gerade ein Frame empfangen wird zun chst im IDLE Zustand siehe mar kiertes Signal Wenn der laufende Frame zu Ende ist und deshalb das Signal E_RX_DV auf 0 gesetzt wird geht der Automat in den Zustand SWAPPING ber Nun ist sichergestellt dass die Nibbles wie gew nscht getauscht werden Au erdem ist gew hrleistet dass zu Beginn jedes Frames die Anzahl der Nibbles im FIFO einen geraden Wert hat In Abbildung 5 6 ist das Simulationsergebnis zu sehen Jeth_usb_test dut swap_nibbles_toplevel_c reset_swap_nibbles feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rx_clk Jeth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c reset _usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rx_dv leth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxd feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxd_out eth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c qint leth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxdi feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxd2 Jeth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxd3 La La La La La La La Jeth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_r
73. nt4bit i Er Er La La Er Cursor 1 459764 ps Abbildung 5 10 Simulationsergebnis der TIMESTAMP Einheit 5 1 4 FIFO_INTERN Einheit Das interne FIFO wurde mit dem LogicCORE IP FIFO Generator v6 2 generiert Das FIFO besitzt eine Eingangsdatenbusbreite von 4 bit entsprechend des Datensignals E_RXD lt 3 0 gt des MII des Ethernet Transceivers Die Ausgangsdatenbusbreite betr gt 16 bit entsprechend des FD lt 15 0 gt Signals des Slave FIFO Interface 5 Realisierung des Einlesemoduls 63 5 1 5 FX2_STATEMACHINE Einheit Implementierung In Abbildung 5 11 ist das Zustandsdiagramm des Zustandsautomaten abgebildet Im DECISION_STATE Zustand wird gepr ft ob das FX2 Slave FIFO nicht voll ist FX2_FULL 0 und das interne FIFO nicht leer ist EMPTY 0 Wenn beide Bedingungen wahr sind erfolgt ein Zustands bergang in den RD_EN_ STATE in dem das Signal RD_EN gesetzt wird und darauf ein bergang in den SLIWR_ON_STATE Zustand in dem das Signal FX2_SLWR gesetzt wird Durch das Setzen des RD_EN Signals wird ein Datensatz aus dem internen FIFO gelesen und durch das Setzen des Signals FX2_SLWR wird dieser Wert in das FX2 Slave FIFO geschrieben FX2_FULL 1 oder EMPTY 1 one RD_EN 0 RD_EN 1 FX2_SLWR 0 FX2_SLWR 0 FX2_FULL X FX2_FULL X EMPTY X EMPTY X FX2_FULL 0 und EMPTY 0 INIT SLWR_ON_STATE RD_EN 0 FX2_SLWR 1 Abbildung 5 11 Zustandsdiagramm der FX2_STATEMACHINE Einheit Simulation
74. ntation von Wireshark beschrieben ist Die Modularit t w re also gegeben Bewertung Der Vorteil den man durch die Verwendung von Wireshark hat ist dass man auf jahrelange Entwicklungsarbeit zur ckgreift Als Opensource Programm wird es durch viele Entwickler betreut und weiterentwickelt Durch Plugins kann man Protokoll Module in Wires hark integrieren und von diesen Vorteilen profitieren Zudem werden Benutzer die schon einmal mit Wireshark gearbeitet haben wenig Zeit brauchen sich in die Analyse Software einzuarbeiten Der Nachteil ist dass man eine Entwicklungsumgebung einrichten muss In dieser Software muss der gesamte Quellcode von Wireshark kompilierbar sein Au erdem muss man sich in die Entwicklung der Dissector Plugins einarbeiten 3 3 3 Fazit f r die Analysesoftware F r die Analyse der Daten wurde Wireshark verwendet Die verschiedenen Protokoll Definitionen werden mit Hilfe von Dissector Plugins realisiert Der Ausschlag f r die Wahl f r die Verwendung von Wireshark ist sich dessen Vorteile als langj hrig betreutes Opensource Programm zu Nutze zu machen 5to dissect engl zerteilen 3 Konzept 44 3 4 Zusammenfassung Zusammenfassend werden nun die Komponenten genannt die f r den Protokollanalysator zum Einsatz kommen F r die Busankopplung wird ein Ethernet Tap verwendet da dieses Ger t die genannten Anforderungen erf llt F r das Einlesen der Busdaten wird ein Ethernet Transceiver in Verbi
75. om previous captured frame frame Packets 36831 Displayed 36831 Marked 0 Load time 0 00 609 Profile Default Abbildung 8 3 Screenshot von Wireshark screenshot engl Bildschirmausdruck 8 Systemintegration und Verifikation 91 8 3 Verifikation Verifikation mit CRC32 Pr fsumme In der Verifikation wird die Funktionalit t des Analy sators mit der in Kapitel 5 4 ausgearbeiteten Pr fsummenberechnung nachgewiesen Wenn die bertragung von Ethernet Daten funktioniert funktioniert auch die bertragung der Da ten des hybriden Bussystems Zum Starten eines Funktionstests gibt es in der Oberfl che der Software die Schaltfl che Funktionstest Klickt man die Schaltfl che an ffnet sich eine Maske in der man festlegen kann unter welcher Datei die Rohdaten abgespeichert werden sollen Der folgende Ablauf ist identisch mit dem Ablauf in der Methode readUSBDataSlot die in Kapitel 8 2 1 erl utert wur de Zus tzlich wird hier eine Pr fsummenberechnung mit den Frames durchgef hrt Bei 10 Einlesevorg ngen mit je 300 MBytes eingelesenen Daten wurden keine Fehler im empfan genen Datenstrom entdeckt Damit ist kein 100 iger Nachweis aber ein hinreichend gutes Indiz erbracht dass der Datenstrom korrekt bertragen wird Detektion von silent errors Silent errors sind Fehler die w hrend der Daten bertra gung passieren und unentdeckt bleiben In dem vorliegenden bertragungssystem gibt es ei n
76. omat in diesem Zustand In diesem Zustand wird das Signal SAMPLE_USEC geseizt Es bewirkt dass der aktuelle Zahlerstand des Mikro Sekunden Zahlers USEC_COUNT festgehalten wird damit der Wert des Zahlerstandes an den Frame angeh ngt wird der zu Beginn des Frames existierte Au erdem wird das Signal E_RX_DV_T1 Signal gesetzt Es bewirkt dass alle folgenden Signale als g ltig interpretiert werden Wenn das Signal E_RX_DV wieder zur ckgesetzt wird also keine Daten mehr empfangen werden soll der Zeitstempel an den Frame geh ngt werden Deshalb erfolgt ein bergang in den Zustand TIMESTAMP1 Von diesem Zustand aus geht der Automat schrittweise in den Zustand TIMESTAMP6 ber W hrend dieser Zust nde wird das Signal SEL auf 1 gesetzt was bewirkt das das Datensignal mit dem Z hlerstand auf den Datenausgang geschaltet wird Der Multiplexer hierf r ist in dem Block DATASTREAM_MUX enthalten siehe Abbildung 5 8 W hrend der berg nge der Zust nde TIMESTAMP1 bis TIMESTAMP6 wird au erdem das Steuersignal COUNT_SEL f r den Multiplexer generiert der den Datenausgang des 24 bit Z hlers in sechs 4 bit Kan le unterteilt Das Signal COUNT_SEL wird beginnend mit dem Wert 0 in jedem der sechs Zust nde bis zum Wert 5 inkrementiert Das bewirkt dass zum Ende eines Zyklus der komplette Z hlerstand in den Datenausgang geschrieben wurde 5 Realisierung des Einlesemoduls 62 Das Simulationsergbnis aus Abbildung 5 10 entspricht dem gew
77. on einem Bussystem gesprochen Der Aufbau des Netz werks ist in Abbildung 1 3 zu erkennen Nicht Echtzeit Daten Downstream Downstream Upstream Upstream Echtzeit Daten Abbildung 1 3 Aufbau des hybriden Datenbus 1 5 Darstellung des Themas F r die Fehlersuche bei der Entwicklung von Ger ten die das hybride Protokoll verwenden ist es hilfreich die auf dem Netzwerk gesendeten Daten mitlesen und analysieren zu k nnen Ein Analyse System soll f r einen bestimmten Zeitraum Daten auf der physikalischen Schicht von Ethernet 100BASE TX mitlesen und diese auf einem PC System zur weiteren Analyse bereitstellen Auf dem PC System sollen die Daten interpretiert und bersichtlich dargestellt werden k nnen Das Analyse System soll modular aufgebaut werden um es leicht an unter schiedliche Protokolle anpassen zu k nnen 1 Einleitung 15 1 6 Grundlagen zu Ethernet 100BASE TX Im Folgenden wird ber die Grundlagen von Ethernet 100BASE TX berichtet da das hybride Protokoll diese bertragungstechnik auf der physikalischen Ebene verwendet Die Sachverhalte lassen sich anschaulich mit Hilfe des Open Systems Interconnection Schichtenmodells OSI Schichtenmodell erkl ren Das OSI Schichtenmodell beschreibt die verschiedenen Abstraktionsebenen der Kommunikation zwischen Netzwerkteilnehmern F r Ethernet 100BASE TX werden die Schichten von einer Projektarbeitsgruppe mit dem Namen Institute of Electrical and Electronics Engineers
78. ps Das Ergebnis ist dass der Interrupt Transfer f r den Transfer der Daten geeignet ist Au erdem ist der Bulk Transfer geeignet wenn das Analyseger t das einzige am Bus angeschlossene Ger t ist Der Interrupt Transfer wird f r diese bertragung der Bus Daten verwendet da die genannten Anforderungen bei diesem Transfer Typ ohne Einschr nkungen erf llt werden 1 Auf einem ansonsten freien Bus stellen Bulk Transfers den schnellsten Transfer Typ dar Jan Axelon 2007 S 84 4 Design des Einlesemoduls 52 4 3 4 Synchroner oder asynchroner Betrieb Das Slave FIFO l sst sich im synchronen oder asynchronen Modus betreiben Bei asyn chroner Ansteuerung werden die Daten die am Daten Bus FD lt 15 0 gt anliegen bei jedem bergang von High nach Low des Signals SLWR in das FIFO geschrieben Um die korrekte Funktion des FX2 bei diesem Modus zu gew hrleisten m ssen bestimmte Zeitparameter eingehalten werden die im Datenblatt des FX2 zu finden sind vgl Cypress Datasheet S 43 Im synchronen Modus werden die Daten die am FD lt 15 0 gt Datenbus anliegen bei jeder steigenden Flanke des Taktsignals IFCLK in das FIFO hineingeschrieben wenn SLWR ge setzt ist Der Takt kann zwischen 5 MHz und 48 MHz liegen Auch hier sind Zeitparameter einzuhalten die im Datenblatt zu finden sind Cypress Datasheet S 42 F r diese Applikati on wird der synchrone Modus verwendet weil in diesem Modus die Werte f r Zeitparameter leichte
79. r Automat verharrt solange in dem Zustand bis das FIFO voll ist Das Status Signal FULL besitzt dann den Wert 1 und das Signal EMPTY den Wert 0 Es kann zwei Gr nde geben warum das FIFO voll wird Ein Grund ist dass ein Einlesevor gang beendet ist was bedeutet dass keine Daten mehr zum Computer Ubertragen werden Der andere Grund ist dass das interne FIFO aufgrund einer zu langsamen Ubertragungsrate vom FX2 zum Computer Ubergelaufen ist Fur die eingelesenen Daten bedeutet das zwangs laufig dass sie fehlerhaft sind da die Daten die nicht in das interne FIFO geschrieben wer 5 Realisierung des Einlesemoduls 67 den konnten verloren gehen Diese Fehlfunktion muss dem Benutzer des Analyse Systems gemeldet werden Dieser Meldevorgang wird folgenderma en realisiert Ist das FIFO voll erfolgt ein Zustands bergang in den Zustand RES_CNT_S in dem der Z hler der das Signal QINT generiert zur ckgesetzt wird Das R cksetzen geschieht durch das Setzen des Signals RESET_COUNTER auf den Wert 1 in dem Zustand RES_CNT_S F r einen Taktzyklus bleibt der Automat in diesem Zustand und geht dann in den FULL Zustand ber In diesem Zustand bleibt der Automat solange das Signal QINT kleiner oder gleich als der Wert 125000000 bzw hexadezimal 0x7735940 ist Bei einer Taktfrequenz von 25 MHz bleibt der Automat deshalb 5 Sekunden in diesem Zustand W hrend dieses Zustandes ist das Signal LED_FULL gesetzt das bewirkt dass eine Status LED leucht
80. r Bibliothek Die Funktionsbibliothek kommuniziert ihrerseits ber den Treiber libusbO sys mit den USB Treibern der niederen Systemebene vgl Johan nes Erdfelt opensource engl quelloffen 3 Konzept 40 Es wird eine synchrone und ein asynchrone Application Interface API zur Verf gung ge stellt Die synchrone API bietet die M glichkeit auf einfache Art und Weise eine Kommuni kation mit einem USB Ger t zu realisieren Die asynchrone API bietet laut der Entwicklungs gemeinde die fortgeschritteneren Techniken zur Kommunikation mit USB Ger ten Zusammenfassung F r die Kommunikation zwischen dem Cypress FX2 und dem Computer wird die libusb win32 Funktionsbibliothek eingesetzt da die Nutzung von WinDriver kostenpflichtig ist 3 Application Interface engl Anwendungs Schnittstelle 3 Konzept 41 3 3 Analysesoftware Nun werden Optionen vorgestellt die die Aufgabe der Visualisierung der Daten berneh men k nnen Die Bewertungskriterien f r die verschiedenen Alternativen werden aus den Anforderungen entnommen Zusammenfassend werden sie noch einmal genannt 1 K nnen die Daten visualisiert werden 2 Sind Analysewerkzeuge zur Untersuchung der Daten realisierbar 3 Ist es m glich die Definition der Protokolle modular zu gestalten 3 3 1 Entwicklung eigener Software Eine Option ist die Entwicklung eigener Software F r diese Software gibt es verschiedene Alternativen die jetzt kurz vo
81. r Rayman 2009 BERNHARD LAHRES GREGOR RAYMAN Objek torientierte Programmierung Galileo Computing 2009 ISBN 978 3 8362 1401 8 Cypress Datasheet CYPRESS DATASHEET EZ USB FX2 Datenblatt URL www keil com dd docs datashts cypress cy7c68xxx_ds pdf Cypress TRM CYPRESS TRM EZ USB FX2 Technical Reference Manual URL www keil com dd docs datashts cypress fx2_trm pdf Erich Gamma Richard Helm Ralph Johnson John Vlissides 2004 ERICH GAMMA RI CHARD HELM RALPH JOHNSON JOHN VLISSIDES Entwurfsmuster Addision Wesley 2004 ISBN 978 3 8273 2199 2 Erich Stein 2008 ERICH STEIN Taschenbuch Rechnernetze und Internet Hanser 2008 ISBN 978 3 446 40976 7 EXFO EXFO Produktbrosch re des Ethernet Testers AXS 200 850 URL http www opternus de uploads media AXS850_db11010d pdf HORUS NET HORUS NET Beschreibung von Ethernet Taps URL http www horus net de de products taps index html IEEE 802 3 IEEE 802 3 Carrier sense multiple access with Collision De tection CSMA CD Access Method and Physical Layer Specifications SECTION ONE URL http standards ieee org getieee802 download 802 3 2008_sectionl pdf Jan Axelon 2007 JAN AXELON USB 2 0 Handbuch f r Entwickler Axelon 2007 ISBN 3 936427 45 3 Johannes Erdfelt JOHANNES ERDFELT libusb win32 documentation http www sourceforge nel URL http sourceforge net apps trac libusb win32 wiki libusbwin
82. r das gleiche Verhalten aufweisen wie eine DEU Er m sste sich also wie ein Kettenglied im Daisy Chain Netz werk verhalten und die ankommenden Informationen an ein weiteres Kettenglied weiterlei ten Dieses Verhalten ist bis zum jetzigen Zeitpunkt jedoch nicht implementiert sodass eine Ankopplung an den Upstream Pfad auf diese Weise nicht m glich ist 3 Konzept 31 3 1 3 Verwendung eines Ethernet 100BASE TX Hub Ein Ethernet Hub arbeitet auf der physikalischen Schicht Er ist jedoch nicht Voll Duplex f hig W rde man ihn in das Netzwerk hineinschalten w rden Kollisionen entstehen Die Abbildung 3 7 beschreibt die Situation in der eine Kollision entsteht Situation 1 Situation 2 Upstream Port Upstream Port Ankopplung Ankopplung Downstream Port Downstream Port Abbildung 3 7 Situation f r eine Kollision im Hub In Situation 1 werden an dem Port Daten empfangen der an den Upstream Pfad ange schlossen ist Die Signale die an dem Rx Port anliegen werden an alle weiteren Tx Ports weitergeleitet In Situation 2 werden an dem Downstream Port ebenfalls Daten empfangen Auch in diesem Fall werden die Signale an alle Tx Ports weitergeleitet Nun entsteht an dem Tx Port des Abzweig Ports eine Kollision der beiden Datenstr me Dieses Verhalten macht einen Hub f r die Busankopplung unbrauchbar Anmerkung Die Verwendung eines Ethernet Switch schlie t sich aus dem Grund aus als er auf OSI 2 arbeitet un
83. r der Dateiname der Rohdaten bergeben Im Konstruktor wird die Datei eingelesen und im bergebenen Speicherplatz abgelegt oO NO 01 gt Po Re 11 12 13 14 15 16 17 18 19 20 21 8 Systemintegration und Verifikation 89 In Zeile 10 wird ein Objekt der Klasse HybridToPcapParser erzeugt und dem Kon struktor die Rohdaten bergeben die er mit der Methode parse in eine Liste von pcap Frames konvertiert Zeile 11 Mit der pcap Frame Liste wird ein Objekt der Klasse PcapFile erzeugt Zeile 13 In der Methode setLinkType wird das zu verwendete Protokoll festgelegt das Wireshark f r den Dissect Vorgang verwenden soll Dies wird mit einer Zahlenkonstante realisiert wie in Kapitel 7 2 1 beschrieben Intern erzeugt die Klas se daraus ein PcapHeader Objekt Das PcapFile Objekt speichert seinen Inhalt mit der Methode saveToDisk auf der Festplatte ab Anschlie end werden die Objekte zerst rt QString qFilename QFileDialog getSaveFileName this tr Save File 0 Wireshark Pcap Files pcap if qFilename isEmpty cutFilename qFilename Dateiendung anpassen Rohdaten werden mit der Endung bin gespeichert unsigned int dataSize 3 30 300 fx2 gt read dataSize dataSizeComboBox gt currentIndex USB Daten einlesen fx2 gt saveRxData filename USB Daten abspeichern unsigned char rxDataBuffer fx2 gt getRxDataBuffer Pointer auf den reservierten Speicherpla
84. r einzuhalten sind 4 3 5 Auto In Out Modus Der Auto In Out Modus erlaubt einer externen Schaltung ohne Einwirkung der Firmware per USB Daten zum Host zu bertragen Im Auto Modus muss die Firmware weder Daten verpacken noch eine Flusskontrolle mit dem Host bewerkstelligen In dieser Applikation wird der Auto In Moduls verwendet 4 Design des Einlesemoduls 53 4 4 Einlesesoftware Mit der Einlesesoftware wird der Datenstrom ber USB in den Computer eingelesen Um das Design der Software zu beschreiben wird in diesem Kapitel die synchrone und asynchrone API von libusb win32 vorgestellt um erkl ren zu k nnen wie die Einlesesoftware realisiert wurde Um vergleichen zu k nnen ob die asynchrone oder synchrone API zum Einlesen der Daten verwendet werden sollte wird mit einem Zeitstrahl das zeitliche Verhalten der APIs beschrieben Synchrone API Wenn die Funktion usb_bulk_read die zur synchronen API geh rt aufgerufen wird 1 tritt die Funktion solange in den blocked Zustand ein bis Daten eingegangen sind Die Zeit in der das Programm im blocked Zustand verharrt bleibt dabei ungenutzt Wenn Daten eingegangen sind 2 wird der Inhalt des Empfangspuffers der Parameter bytes in der Pa rameterliste der Funktion usb_bulk_read von der Einlesesoftware in einer Schleife in den Gesamtpuffer geschrieben der der Puffer des gesamten Datenstromes ist In dem Zeit raum in dem die Daten durch die Einlesesoftware in den
85. rd Zeile 4 Der Parameter FT_UINT32 gibt Wert Typ f r das Feld an In diesem Fall lautet der Typ 32 bit unsigned integer Zeile 4 Die anderen Parameter k nnen in der Quelle Wireshark nachgeschlagen werden amp hf_hybrid_timestamp IP Timestamp hybrid _non_rt timestamp FT_UINT32 BASE_HEX NULL O NULL HFILL D JO Om P WD Listing 7 9 Ausschnitt aus der Datei packet hybrid_nonrt c 8 Systemintegration und Verifikation 8 1 Integration der Hardwarekomponenten In diesem Kapitel wird gezeigt wie in dem Prototyp Aufbau des Analyse Systems die Hard warekomponenten miteinander verbunden wurden In der Abbildung 8 1 ist dazu ein Block schaltbild zu sehen Im Prototypen des hybriden Bussystems werden D Sub Steckverbinder zum Verbinden der Komponenten verwendet Dazu mussten Kabel angefertigt werden die auf der einen Seite einen D Sub Stecker und auf der anderen Seite einen RJ 45 Stecker besitzen siehe Markierungen 1 und 2 Es wurden Cat5 STP Kabel als bertragungsme dium verwendet Im Laufe der Entwicklung wurden als Adapter Markierung 3 Einzeladern verwendet Hybrider ame Downstream Analyse System Abbildung 8 1 Verbindung der Hardwarekomponenten 8 Systemintegration und Verifikation 88 8 2 Integration der Softwarekomponenten 8 2 1 Integration der Konvertierungssoftware Es wurde eine Software mit einer graphischen Benutzeroberfl ch
86. ren da diese sich unterscheiden Bei der Middle Line wird diese Unterscheidung nicht gemacht da die Protokolle f r Up und Downstream identisch sind Die Endknoten mit der Aufschrift Up und Downstream zweigen jeweils zwei Knoten ab die die Echtzeit Daten Frames und die Nicht Echtzeit Daten Frames repr sentieren Die Nicht Echtzeit Frames besitzen bei s mtlichen Verbindungstypen das gleiche Protokoll F r Wireshark m ssen deshalb 4 Protokoll Dissectors f r die verschiedenen Protokolle entwi ckelt werden Zwischen den drei Protokolltypen Middle Line Top Line Uptream und Top Line Down stream soll der Benutzer manuell entscheiden k nnen welches Protokoll f r die Verarbei tung der Rohdaten verwendet werden soll Die Realisierung hierf r wird im Kapitel 7 2 1 Auswahl der Leitungsverbindung behandelt Innerhalb dieser drei Protokolle k nnen Echtzeit Frames und Nichtechtzeit Frames auftreten Hier muss das Analyseprogramm selbstst ndig unterscheiden k nnen um welchen Frame Typ es sich handelt Die Realisierung hierf r wird im Kapitel 7 2 2 Automatische Protokoll detektion behandelt 7 Realisierung der Interpretationssoftware 7 1 Realisierung des Zustandsautomaten f r den HybridToPcapParser In diesem Kapitel wird die Realierung des Zustandsautomaten beschrieben mit dem die Pr ambel in dem Datenstrom des hybriden Bussystem detektiert wird Der Zustandsautomat ist in Kapitel 6 2 3 zu sehen Eine M glichkeit einen Zus
87. rgestellt werden Die Alternativen werden nach dem Muster aus Kapitel 3 3 bewertet Datenbank als Speicherort Die Realisierung k nnte durch ein Programm erfolgen das die Daten parst und die Infor mationen anschlie end in einer Datenbank speichert 1 F r die Realisierung der Software kann jede Programmiersprache verwendet werden die eine Schnittstelle zu einem Datenbanksystem wie mySQL bereitstellt Zur Visuali sierung muss eine neue Software erstellt werden 2 Sortier und Filterfunktionen sind in jedem Datenbanksystem realisierbar Sie k nnen mit Hilfe von Datenbankabfragen realisiert werden 3 F r das Einf gen der Daten in die Datenbank muss ein Programm entwickelt werden Dieses Programm parst den gespeicherten Datenstrom und f gt die Informationen in die Datenbank ein Dieses Programm muss so konzipiert sein dass sich die Protokoll Definition leicht ver ndern lasst Bewertung Der Vorteil dieser L sung ist dass s mtliche Verwaltungsfunktionen verf gbar sind die es f r gro e Datenmengen in Datenbank Verwaltungsystemen gibt Ein weiterer Vorteil ist dass die Daten nur einmal geparst werden m ssen Anschlie end stehen sie in einer Datenbank zur Verf gung Der Nachteil ist dass ein Programm entwickelt werden 4to parse engl aufgliedern 3 Konzept 42 muss das die Daten in die Datenbank einf gt und ein Programm das sie anschlie end visualisiert Baumstruktur mit XML Die Realisierung k nnte
88. s 1 4 Hybrides Protokoll Um den Datenbus des CIDS leistungsf higer zu machen wird als physikalische Schicht nun Ethernet 100BASE TX verwendet das eine Datenrate von 100 Mbit s besitzt Das Kommuni kationsprotokoll wird um einen Nicht Echtzeit Teil erweitert da in der selben Zeit mehr Daten bertragen werden k nnen Das hybride Protokoll orientiert sich nach wie vor an der Sampling Rate der Audio Daten und bertragt die Frames des alten Protokolls mit derselben Frequenz von 32 kHz Diese Frames werden in diesem Zusammenhang als Echtzeit Frames bezeichnet Neben den Echtzeit Frames werden Daten getunnelt die nicht die Anforderungen haben in Echtzeit bertragen zu werden 1 Einleitung 14 Das Tunneln der Frames wird mit einem Multiplexer realisiert der abwechselnd die Echtzeit Frames und die Nicht Echtzeit Frames auf den Datenbus schaltet Das Verfahren mit dem der Multiplexer arbeitet ist das synchrone Zeitmultiplexverfahren Time Division Multiple Ac cess TDMA Beim synchronen TDMA wird dem Sender der Echtzeit Frames und dem Sen der der Nicht Echtzeit Frames ein jeweils fester Zeitabschnitt zur bertragung zur Verf gung gestellt Mit der nderung des physikalischen bertragungsmediums hat sich auch die Bus Topolo gie des CIDS ver ndert Die DEUs sind nun ber ein Daisy Chain Netzwerk verbunden da Ethernet 100BASE TX eine Punkt zu Punkt Verbindung vorsieht Aus historischen Gr nden wird im Folgenden aber weiter v
89. s dauert vier Bit L ngen Aufgrund dieser Tatsache reduziert sich das Signalspektrum auf der Frequenzachse auf 25 des 4B 5B Signalspektrums Nun befinden sich die gr ten Spektralanteile bei 31 25 MHz und das Signal wird durch das bertragungsmedium nicht mehr verzerrt vgl Klaus Dembowski 2007 S 137 An der xMII Schnittstelle werden der n chstgelegenen Sicherungsschicht die bertragenen Nutz Daten und Steuersignale bereitgestellt Im Fall 100BASE TX gibt es das MII und RMII Beim MII wird ein 4 Bit breiter Datenstrom bei einer Taktfrequenz von 25 MHz zur Verf gung gestellt Beim RMII betr gt die Breite des Datenstromes 2 Bit und die Taktfrequenz 50 Mhz 1 6 3 Sicherungsschicht Die Sicherungsschicht ist in zwei Unterschichten aufgeteilt Diese lauten Media Access Con troll MAC und Logical Link Control LLC In diesen beiden Schichten wird im Wesentli chen der Zugriff auf das bertragungsmedium geregelt und eine Daten Kapselung durchge f hrt Zugriffssteuerung auf das bertragungsmedium Laut IEEE 802 3 werden bei Ethernet 100BASE TX zwei Betriebsmodi zur Verf gung ge stellt Halb Duplex und Voll Duplex Im Halb Duplex Modus sendet nur ein Teilnehmer zur Zeit Dieser Modus wird bei Ethernet 100BASE TX nicht mehr h ufig verwendet da es ge trennte Sende und Empfangsleitungen gibt sodass zwei Teilnehmer gleichzeitig senden k nnen Hingegen wird bei 10BASE2 zur bertragung nur ein Koaxialkabel verwendet auf dem nur
90. sign dieses Schaltwerks wird im Folgenden be schrieben 4 Design des Einlesemoduls 46 4 2 1 Das interne FIFO Aufgabe der Systemfunktion Das interne FIFO hat die Aufgabe die Frames des hy briden Protokolls zu puffern falls sie nicht gleich zum Computer geschickt werden k nnen Au erdem lassen sich mit einem FIFO zwei Taktdom nen koppeln sodass man es mit einem schnelleren Takt auslesen kann als mit dem 25 MHz schnellen Takt des MIl Anordnung der Funktion in dem System Das interne FIFO ist der zentrale System block des Einlesemoduls Die Anordnung der folgenden Funktionen orientiert sich an diesem Block 4 2 2 Anh ngen der Zeitstempel Aufgabe der Systemfunktion Jeder Frame des hybriden Protokolls soll mit einem Zeit stempel versehen werden der anzeigt zu welchem Zeitpunkt er empfangen wurde Die zeitli che Aufl sung der Zeitstempel ist durch Wireshark auf 1 us begrenzt Der Stempel setzt sich aus einem Sekunden und einem Mikrosekundenteil zusammen Wenn der Mikrokunden Teil den Wert 999999 us erreicht muss der Wert des Sekunden Teils um 1 inkrementiert werden Umgerechnet in das Hex Zahlenformat betr gt der maximale Wert f r den Mikrosekunden Teil OxOF423F us Die L nge des Zeitstempels wurde deshalb auf 3 Bytes spezifiziert Anordnung der Funktion in dem System Bevor ein Frame in den Datenpuffer geschrie ben wird muss er mit dem Zeitstempel versehen werden Der Grund daf r ist dass sich die Daten im Datenp
91. sse von PcapFrame Sie erweitert die Klasse um einen Zeiger auf sich selbst wodurch die Realisierung einer verketteten Liste m glich wird Au erdem enth lt die Klasse die Methode set Next Node die einen neuen Kno ten an die Liste anh ngt Um eine Klasse zu realisieren die die Liste verwaltet wurde die Klasse PcapFrameList erstellt Die Verwaltungsoptionen begrenzen sind auf das Einf gen eines Elementes in die Liste und das L schen und die Anzeige aller Elemente Diese Klasse PcapFrameList besitzt vier Zeiger die auf Objekte der Klasse PcapFrameNode zeigen k nnen Die Beziehung zwischen den beiden Klassen ist eine Komposition da die Lebensdauer der PcapNode Objekte auf die die vier Zeiger zeigen von der Lebensdauer der Klasse PcapFrameList abh ngt vgl Bernhard Lahres Gregor Rayman 2009 PcapFrame ts_sec unsigned int ts_usec unsigned char 4 incl_len unsigned int orig_len unsigned int payload unsigned char PETERS PcapFrame ts_usec unsigned PcapFrameNode Heads Peap rime ade char ts_sec unsigned int in next PcapFrameNode Leese PcapFrameNode eB len unsigned int orig_len unsi PcapFrameNode ts_usec unsi last PcapFrameNode us ee gned char ts_sec unsigned int neu PcapFrameNode ME incl_len unsigned int orig_len un o i a K u nun PcapFrameList setTs_usec ts_usec unsigned qj signed int 0 1 R N char es En etTs_usec gint ec get
92. sste also zus tzlich ge kauft werden Ein weiterer Grund f r Entscheidung gegen Gigabit Ethernet ist der Preis der bei der Recherche gefundenen Boards Ein f r diese Applikation ideales Board w re das XUPV2P Virtex II Pro gewesen Es hat einen Gigabit Ethernet Transceiver sowie einen Ethernet 100 BASE TX Transceiver integriert Mit 1217 79 Euro ist der Preis f r dieses Board aber zu hoch 3 Konzept 38 Firewire IEEE 1394a b Die bertragungsgeschwindigkeit mit der bei Firewire gesendet werden kann betr gt laut der Arbeitsgruppe IEEE 1394a 100 200 oder 400 Mbit s und nach Standard IEEE 1394b 800Mbit s Um die Daten auf den Computer zu bertragen w rde die bertragungsrate also ausreichen Bei Recherchen zu verwendbarer Hardware wurde das Entwicklungsmodul UC1394A 1 der Firma Orsys gefunden Die folgenden Punkte sprechen aber gegen den Einsatz dieses Mo duls e Es gibt kein Entwicklungsboard und durch die kleine Gr e ist das Modul schlecht l tbar e Die Qualit t der Treiber und des Supports sind nicht bekannt e Der Preis ist mit 3500 bis 3900 Euro hoch Ein anderes Entwicklungsboard wurde nicht gefunden Diese Punkte sprechen gegen eine Verwendung f r Firewire als bertragungstechnik Universal Serial Bus 2 0 Der Universal Serial Bus besitzt in seiner High Speed Variante eine theoretische Daten ber tragungrate von 480 Mbit s Die Nutzdatenrate betr gt 30 bis 35 MByte s und ist somit h her als die maxima
93. stroms weil er auf OSI Schicht 1 arbeitet Im Gegensatz zu der L sung unter 3 1 4 erzeugt ein Ethernet Tap keinerlei zus tzliche zeitliche Belastung f r das Netzwerk in das er geschaltet wird sodass w hrend der Analyse die maximal m g liche Anzahl an DEUs an den Bus angeschlossen sein kann Zudem ist er im Gegensatz zu einem Ethernet Hub Voll Duplex f hig vgl HORUS NET Die Abbildung 3 9 zeigt die Wirkungsweise eines Taps Es gibt zwei Ports die dazu dienen sich zwischen die Ethernet Leitung zu schalten Nebenan gibt es zwei weitere Ports die das Auskoppeln des Rx oder Tx Datenstroms erm glichen Diese Eigenschaften machen einen Ethernet Tap zu der optimalen L sung f r die Busankopplung Upstream Port Ankopplung des Downstream Port Ankopplung des Downstream Port Upstream Port Abbildung 3 9 Prinzip eines Ethernet TAP 3 Konzept 34 3 2 Einlesemodul Das Einlesemodul hat die Aufgabe den Datenstrom aus dem Ankopplungszweig zu emp fangen vorzuverarbeiten und zum Computer zu bertragen siehe Abbildung 3 1 3 2 1 Einsatz eines Ethernet Controllers als Einlesemodul Um beurteilen zu k nnen ob man als Einlese Modul einen Ethernet Controller f r den Emp fang des Datenstroms aus dem hybriden Bussystem verwenden kann muss man sich ber den Aufbau von Ethernet Controllern im Klaren sein In Abbildung 1 6 ist der Aufbau des Ethernet Controller Yukon FE 88E8040 der Firma Marvel gezeigt Wie zu er
94. swap_nibbles_c e_rxd1 feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxd3 feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxd_out_temp feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c wr_en_out_temp feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c e_rxd_out feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c wr_en_out feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c reset_switch_counter feth_usb_test dut time_stamp_c e_rx_dy_in La La Lia Ly Ly Lia feth_usb_test dut time_stamp_cfe_rxd_in 0 ic oF IB Jo feth_usb_test dut time_stamp_c e_rx_dy_out feth_usb_test dut time_stamp_c e_rxd_out feth_usb_test dut Fifo_intern_cjdin feth_usb_test dut fifo_intern_c wr_en jeth_usb_test dut fifo_intern_c rd_en feth_usb_test dut fifo_intern_c dout Cursor 1 1420 ps Abbildung 5 5 Verworfenes Design der SWAP_NIBBLES Einheit Fur die Analyse der Daten ist allein dieser Fehler aber nicht kritisch da diese Daten verwor fen werden k nnen Das sich ergebende Problem ist dass wie im im obigen Fall gezeigt eine ungerade Anzahl an Nibbles in das FIFO geschrieben wird S mtliche folgenden Da ten werden auch in das FIFO geschrieben Sp testens im Computer werden dann s mtliche Daten zu Bytes zusammengefasst und es ergibt sich das unerw nschte Verhalten wie in Tabelle 5 1 gezeigt 5 Realisierung des Einlesemoduls 59 Korrektur des Fehlers Um das erw hnte Problem zu l sen wurde ei
95. t ande rem Verhalten hinzugef gt werden Der Grund hierf r wird gekl rt indem das Konzept nun erl utert wird D JO Om AON 11 12 13 14 On NOOO Ff 7 Realisierung der Interpretationssoftware 80 Aquivalent zu den 256 m glichen Werten des Eingangssignals besitzt ein Stateltem Objekt 256 Zeiger die auf ein nachstes Stateltem Objekt zeigen Zeile 4 des Listing 7 1 Ein Zeiger auf das nachste Stateltem Objekt reprasentiert den Pfeil auf den nachsten Zustand in einem Zustandssymbol eines Zustandsdiagramms Beim Erzeugen des Automaten werden die Zustandstbergange mit der Methode setNextState Methode definiert Zeile 6 Abh ngig von dem Parameter input wird ein Zustand mit einem anderen Zustand nextState ber einen Zeiger verbunden Zeile 8 Beim Durchlaufen des Zustandsautomaten in der Anwendung wird mit der Methode getNextState Zeile 10 der Ubergangsszustand eines Zustands mit Hilfe des Ein gangssignals input ermittelt Zeile 12 Die Ermittlung des n chsten Zustands erfolgt ohne Schachtelung von Abfragen sondern durch diese Lookup Tabelle class Stateltem public State private Stateltem nextState 256 public void setNextState unsigned char input Stateltem nextState Festlegen des n chsten Zustands x this gt nextState input nextState Stateltem getNextState unsigned char input Ermitteln des n chsten Zustands return this gt nextState input
96. t diese berpr fung nicht gemacht werden muss wird die Vertauschung vor dem Anh ngen der Zeitstempel vollzo gen 4 2 4 Ansteuerung des Slave FIFO Interface des FX2 Aufgabe der Systemfunktionen Aus dem internen FIFO muss der Datenstrom zum Slave FIFO des FX2 bertragen werden damit er von dort aus ber USB zum Computer geschickt wird Die Aufgabe dieses Blocks ist die Datenflusskontrolle zwischen dem inter nen FIFO und dem FX2 Slave FIFO zu bernehmen Der Datenfluss ist unidirektional Anordnung der Funktion in dem System Diese Funktion wird im Systemmodell zwi schen das interne FIFO und das FX2 Slave FIFO geschaltet 4 Design des Einlesemoduls 48 4 3 Cypress FX2 Firmware Um den FX2 im Slave FIFO Modus zu betreiben ist eine Firmware erforderlich die den FX2 in diesem Modus arbeiten l sst In diesem Kapitel werden die dazu n tigen Einstellungen und Eigenschaften genannt Aufgrund der Tatsache dass der FX2 die bertragungstechnik USB zur Kommunikation mit dem Computer verwendet werden die n tigen Begriffe und Sachverhalte im Folgenden erkl rt Die Folgenden Informationen stammen aus der Quelle Jan Axelon 2007 4 3 1 Einf hrung zum Universal Serial Bus Begriffe Der Universal Serial Bus ist ein durch einen Host gesteuertes Bussystem Auch die ber tragungsrichtungen werden aus Sicht des Hosts definiert Transfers zum Host werden als IN Transfers und Transfers zu den Endger ten werden als OUT Transfers bez
97. t sind Dies entspricht dem wirklichen Verhalten des Transceivers feth_usb_test dut mii_count_gen_c reset Jeth_usb_test dut mii_count_gen_c e_rx_dk Jo feth_usb_test dut mii_count_gen_c e_rxd_out 2 feth_usb_test dut mii_count_gen_c e_rx_dv 1 Abbildung 5 3 Simulation der MIILCOUNT_GEN Einheit 5 Realisierung des Einlesemoduls 57 5 1 2 SWAP_NIBBLES_TOPLEVEL Einheit In dieser Einheit werden die 4 bit Nibbles umgetauscht Dazu wurde das Modell einer Einheit entwickelt dessen Zeitverhalten in der Abbildung 5 4 zu sehen ist Um den Tauschvorgang zu realisieren wird ein Schieberegister verwendet durch das das Datensignal E_RXD gef hrt wird Mit Hilfe eines Multiplexers wird abwechselnd das Signal E_RXD1 und E_RXD3 auf den Ausgangsdatenbus E_RXD_OUT geschaltet Als Steuersignal f r den Multiplexer wird das Signal E_RXD_EN verwendet das durch einen Z hler generiert wird E_RX_CLK E_RXD lt 0 3 gt E_RXD1 lt 0 3 gt E_RXD2 lt 0 3 gt E_RXD3 lt 0 3 gt E_RXD_EN E_RXD_OUT lt 0 3 gt af 8 Yo jo Y YF WR_EN_OUT Abbildung 5 4 Impulsdiagramm zur Verdeutlichung des Vertauschen der 4 bit Nibbles Fehlerhaftes Verhalten Auf Grundlage dieses Modells wurde die VHDL Einheit SWAP_NIBBLES erstellt in der dieses Verhalten realisiert ist Mit diesem Schaltwerk kam es beim Empfangen von Daten zu Fehlern Die Fehler machten sich darin bemerkbar dass die Nibbles um eine Position versetzt vom Computer empfangen wurden Fur die L sung zu d
98. tandsautomaten zu realisieren ist die Verwendung einer switch case Anweisung Um den objektorientierten Programmieransatz zu verfolgen werden zwei alternative Konzepte vorgestellt 1 Konzept State Design Pattern Dies ist ein gebr uchliches Konzept f r der Realisie rung von Zustandsautomaten in Software mit Hilfe objektorientierter Programmierung Das Konzept sieht vor dass das Verhalten eines Objekts abh ngig von seinem Zustand ist F r jeden Zustand Objekt wird dabei eine eigene Klasse eingef hrt die das Verhalten des Ob jekts in diesem Zustand definiert Jeder dieser Zust nde ist f r gew hnlich eine Ableitung einer abstrakten Klasse State vgl Erich Gamma Richard Helm Ralph Johnson John Vlissides 2004 Ein Vorteil bei der Verwendung von State Design Pattern ist dass kom plexe Bedingungsausdr cke vermieden werden k nnen Die Wartbarkeit wird erh ht indem der Quellcode leichter lesbar ist und leichter erweitert werden kann Der Nachteil ist dass der Implementierungs Aufwand f r einen Automaten mit einer simplen Struktur wie sie der hier zu realisierende Automat besitzt hoch ist 2 Konzept Verkettete Objekte vom Typ Stateltem Dieses Konzept ist ein propriet res Konzept in der die einzelnen Zust nde ebenfalls durch eine Klasse beschrieben werden Diese Klasse beschreibt einen Zustand durch seine Bezeichnung und sein Ausgangssignal In die Automatenstruktur k nnen im Gegensatz zum 1 Konzept keine Zust nde mi
99. te Voraussetzung da der gesamte Datenstrom ohne Ein schr nkungen zur Verf gung stehen muss Im Folgenden wird deshalb ein alternatives Ge samtsystem erstellt 3 2 2 Alternative zum Ethernet Controller Eine Hardware die die Aufgaben der physikalischen Schicht von Ethernet bernimmt nennt sich Ethernet PHY oder Transceiver In diesem Punkt gibt es keine Alternativen Bei Recher chen nach geeigneter Hardware wurde kein Microcontroller Board gefunden das einen Mi krocontroller zusammen mit einem Ethernet Transceiver auf einem Entwicklungsboard ver eint Es wurden nur Ethernet Controller gefunden die die ersten beiden OSI Schichten im plementiert haben Aus den bereits genannten Gr nden ist die Verwendung dieser Ethernet Controller aber nicht m glich Bei FPGA Boards gibt es Boards die Ethernet Transceiver statt Ethernet Controller enthal ten Eine M glichkeit ist das Spartan 3A Starter Kit von Xilinx Auf diesem Board ist ein Spartan 3A FPGA vom Typ XC3S700A integriert Die Bezeichnung des auf dem Board integrierten Ethernet Transceiver lautet Standard Microsystems LAN8700 10 100 Ethernet physical layer PHY interface Das Board hat einen Preis 146 Euro und ist damit nicht zu teuer 3 Konzept 37 3 2 3 bertragung zum Computer Es muss eine bertragungstechnik gefunden werden die die Daten aus dem FPGA zuver l ssig zum Computer schickt Die Bewertungskriterien lauten e Wie hoch ist die erreichbare Nutz
100. tung Abbildung 3 4 und f r den Fall ohne Abschlusswiderstand Abbildung 3 3 an der Abzwei gung aufgenommen Da kein differentieller Tastkopf zur Verf gung stand wurde nur an einer der zwei Leitungen eines Adernpaares gemessen Der Masse Anschluss des Tastkopfes wurde mit der Masse der DEU verbunden Getriggert Tek Run Ey H A Trigger quelle chi ch4 weiter 1von3 ivy 47 6000ns Typ SC Kopplung Flanke Pegel Modus Flanke amp Holdoff Abbildung 3 3 Augendiagramm ohne Abschlusswiderstand an der Abzweigeleitung SIE 200mv Setriggert Tek Run ch4 1 Wweiter 1von3 gt Ar 382 040ns Typ SC Kopp lung Flanke eet Modus Flanke amp Holdoff Abbildung 3 4 Augendiagramm mit Abschlusswiderstand an der Abzweigeleitung 3 Konzept 28 Messergebnis In Abbildung 3 4 ist zu erkennen dass das Auge aufgrund der schlechten Signalqualit t wei ter geschlossen ist als in Abbildung 3 3 Au erdem ist der Signalpegel mit dem Abschlusswi derstand kleiner Das Hinzuschalten des Abschlusswiderstandes wirkt sich also negativ auf das zu analysierende Signal aus bertr gt man mittels der Personal Announcement Funktion des CIDS Audio Daten w h rend die Ankopplungsleitung mit dem Abschlusswiderstand abgeschlossen ist macht sich die schlechte Signalqualit t insofern bei der bertragung von Sprache bemerkbar als st n dig ein Knacken und Knistern z
101. tz f r die Rohdaten erhalten RawData rawData new RawData filename rxDataBuffer Einlesen der Rohdaten HybridToPcapParser parser new HybridToPcapParser rawData Dem Konverter die Rohdaten bergeben PcapFrameList frameList parser gt parse Die Rohdaten parsen delete parser PcapFile pcapFile new PcapFile frameList PcapFile Objekt mit der erstellten Frame Liste erzeugen pcapFile gt setLinkType linkTypeComboBox gt currentiIndex Datenbus festlegen pcapFile gt saveToDisk qFilename toAscii data pcapFile Objekt abspeichern printf abgeschlossen n delete rawData delete frameList delete pcapFile Listing 8 1 Ausschnitt des Quelltextes der Methode readUSBDataSlot 8 Systemintegration und Verifikation 90 8 2 2 Analyse der Daten mit Wirehark Die mit der Konvertierungssoftware erstellte pcap Datei l sst sich mit Wireshark ffnen Die Abbildung 8 3 zeigt einen Screenshot in dem die Frames des hybriden Protokolls dargstellt werden Im oberen Fensterteil wird die Frame Liste angezeigt Hier kann man erkennen ob es sich um einen Echtzeit Frame HYBRID_TOPLINE_RT_UPTREAM oder um einen Nicht Echtzeit Frame HYBRID_NONRT handelt Im mittleren Fensterteil werden Informationen ber die Ankunftszeit des Frame angezeigt Automatisch berechnet Wireshark die zeitliche Differenz zu dem vorigen Frame Wie er wartet betr gt die zeitliche Differenz der Frames 31 us w hrend be
102. u h ren ist Diese Ankopplung verf lscht das zu analysierende Signal also so stark dass es von Empf nger nicht mehr korrekt detektiert werden kann Kompensierung der Auswirkungen Verhinderung des Pegeleinbruchs Ein Grund f r den Einbruch des Signalpegels k nnte sein dass der Innenwiderstand der Spannungsquelle nun nicht mehr mit dem Gesamtwider stand der parallel geschalteten Abschlusswiderst nde bereinstimmt Das Parallelschalten bewirkt dass der Gesamtwiderstand sinkt die Spannungsquelle zu stark belastet ist und der Signalpegel deshalb einbricht Der Abschlusswiderstand der Abzweigeleitung m sste also um mindestens den Faktor 10 hochohmiger als die brigen Abschlusswiderst nde sein um die Signalquelle nicht so stark zu belasten Dies w re mit einem Impedanzwandler realisierbar der im Frequenzbereich bis ungef hr 100 MHz ein nahezu lineares Verhalten aufweist Personal Announcement engl Flugbegleiter Durchsage 3 Konzept 29 Vermindern der Reflexionen Um die Reflexionen zu vermindern muss eine Anpassung des Wellenwiderstandes durchgef hrt werden Da das Spektrum des Signals sehr breitban dig ist l sst sich keine Stichleitung und kein einfacher A 4 Transformator verwenden Eine M glichkeit w re einen bertragerbaustein mit einem bestimmten Wicklungsverh ltnis zu verwenden um eine Impedanzanpassung zu erreichen siehe Abbildung 3 5 100 Ohm N1 N2 50 Ohm Abbildung 3 5 Anpassung des Wellenw
103. uffer sammeln wenn sie nicht sofort zum Computer verschickt werden k n nen Nachdem sie dann aus dem FIFO gelesen werden l sst sich nicht mehr individuell zu jedem Frame die Empfangszeit bestimmen Das ist der Grund daf r dass der Systemblock vor den Datenpuffer geschaltet ist 4 Design des Einlesemoduls 47 4 2 3 Tauschen der 4 Bit Nibbles Aufgabe der Systemfunktion Durch den 4B 5B Codierungsvorgang werden die 4 Bit Nibbles im empfangenen Datenstrom vertauscht Das Umtauschen in die korrekte Reihen folge wird nicht von dem Transceiver erledigt Nachdem diese 4 Bit Gruppen empfangen wurden m ssen sie deshalb wieder umgetauscht werden Dieser Block hat die Aufgabe diesen Tausch durchzuf hren Die Abbildung 4 2 zeigt auf welche Weise der Datenstrom verarbeitet werden muss ua _ a4 Abbildung 4 2 Vertauschen der Nibbles durch Verarbeitsungsblock Anordnung der Funktion in dem System Das Tauschen der 4 Bit Nibbles kann tech nisch gesehen sowohl innerhalb des FPGA als auch durch die Analysesoftware erfolgen Es ist sinnvoller den Tauschvorgang im FPGA durchzuf hren Die Begr ndung hierf r liegt dar in dass im Systemmodell nach dem Transceiver der Systemblock folgt der die Zeitstempel an die Frames anh ngt Wenn man die Nibbles durch die Analysesoftware tauschen w rde m sste die Software bei jedem Byte des Frame pr fen ob es sich gerade um den Zeitstem pel handelt weil der Zeitstempel nicht gedreht werden darf Dami
104. uxte hude reintegriert Die KID Systeme GmbH blieb in verkleinerter Gr e parallel am Standort bestehen 1 2 Cabin Intercommunication Data System Das CIDS ist der Kern der Kabinenelektronik aller Airbus Flugzeuge Es betreibt und Uber wacht die verschiedenen Passagier und Crew Funktionen Zu diesen Funktionen geh ren z B ein Kommunikationssystem f r das Kabinenpersonal die Kabinenbeleuchtung F ll standsanzeige der Wasser Abwassertanks die Regulierung der Kabinentemperatur und weitere berwachungsfunktionen 1 Einleitung 12 1 2 1 Komponenten des Cabin Intercommunication Data System Das CIDS ist ein zentral gesteuertes System mit mehreren redundanten Servern Director Das CIDS besteht je nach Gr e des Flugzeugs aus einer bestimmten Anzahl von Directors die das Herzst ck des Systems sind Sie verarbeiten die Signale der gesamten Peripherie Zu der Peripherie z hlen die verschiedenen Sensoren und Komponenten die durch das CIDS gesteuert werden Zwischen der Peripherie und des Directors gibt es Netzknoten die Decoder Encoder Units DEU die die Signale die zum Director f hren oder vom Director ausgehen umsetzen Als einfachstes Beispiel wird in den DEUs eine A D beziehungsweise D A Umsetzung der Signale durchgef hrt Ein Flight Attendant Panel FAP dient dabei der Statusanzeige diverser Funktionen des CIDS Au erdem lassen sich dort Einstellungen wie Boarding Music und Beleuchtungsein stellungen vornehmen
105. werden zun chst drei Sendeanforderungen verschickt submit request 1 3 in denen je weils 65536 Byte eingelesen werden sollen In einer while Schleife wird jede Anforderung abgebaut reap und in den buffer geschrieben buffer Anschlie end wird sie wieder zum FX2 geschickt submit Die while Schleife pr ft nach jedem Durchlauf ob noch mehr Daten eingelesen werden m ssen Dies geschieht durch eine Z hlvariable die die Schleifendurch l ufe z hlt Wenn keine Daten mehr eingelesen werden m ssen steigt das Programm aus der Schleife aus und die drei Anforderungen werden abgebaut reap request 1 3 Der kom plette Quellcode zu dieser Methode ist im elektronischen Anhang A zu finden submit request1 submit submit request2 request3 no reap and reap buffer requesti request1 reap submit request2 request1 reap and rea buffer Submit request3 request3 f request3 a write da tastream buffer to disk Abbildung 5 16 Flussdiagramm f r die Einlesefunktion 5 Realisierung des Einlesemoduls 71 5 4 Verifikation mit CRC32 Pr fsumme VHDL Simulationen haben bereits ergeben dass das Schaltwerk sicher funktioniert Es musste aber zus tzlich gepr ft werden ob die Ansteuerung des FX2 auch auf der Hardware Ebene funktioniert Um die Funktionalit t zu berpr fen ist die bertragung eines IEEE 802 3 konformen Ethernet Datenstroms geeignet Nach
106. wird der Cypress FX2 verwendet der mit der bertragungstechnik USB 2 0 arbeitet Die Einlese software welche auf dem PC l uft ist die Software die die Kommunikation zwischen dem FX2 und dem Computer realisiert Zur USB Kommunikation werden nun zwei Alternativen vorgestellt WinDriver NM WinDriver ist ein Entwicklungswerkzeug der Firma Jungo zur Erstellung von Ger tetrei bern f r zum Beispiel USB PCI und PCMCIA Die Treiberentwicklung erfolgt dabei ber eine grafische Benutzeroberfl che In dieser Benutzeroberfl che kann der Benutzer Treiber an die eigenen Bed rfnisse anpassen Durch eine automatische Code Generierung wird als Resul tat der komplette Quelltext des Treibers erzeugt Allerdings ist die Nutzung von WinDriver kostenpflichtig WinDriver bietet folgende Vorteile vgl Jungo e Die Entwicklungszeit reduziert sich nach Einarbeitung erheblich e Die Treiber laufen mit individueller Kompilierung auf allen unterst tzten Betriebssyste men wie Windows und Linux e F r Cypress gibt es unter anderem eine erweiterte Unterst tzung f r die Entwicklung von Treibern speziell f r den FX2 libusb win32 libusb win32 ist eine Funktionsbibliothek f r Windows Betriebssysteme die eine Kommuni kation mit USB Endger ten erlaubt Libusb win32 ist ein Opensource Projekt Zur Realisie rung der Kommunikation muss keinerlei Treiberentwicklung betrieben werden Die Kommuni kation erfolgt ber Funktionen de
107. x_dv1 Jeth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c wr_en_out_temp leth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_c reset_switch_counter Jeth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_controlpath_c clk feth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_controlpath_c reset leth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_controlpath_c e_rx_dv Jeth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_controlpath_c reset_swap_nib Jeth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_controlpath_c state Jeth_usb_test dut swap_nibbles_toplevel_c swap_nibbles_controlpath_c next_state Cursor 1 Abbildung 5 6 System mit Kontrollpfad E_RX_DV 1 RESET_SWAP_NIBBLES 1 RESET_SWAP_NIBBLES 0 Abbildung 5 7 Zustandsdiagramm der Steuerpfad Komponente der SWAP_NIBBLES Einheit 5 Realisierung des Einlesemoduls 60 5 1 3 TIMESTAMP Einheit Die TIMESTAMP Einheit h ngt die Zeitstempel an die Frames Der Aufbau der Einheit ist in Abbildung 5 8 zu sehen Die Einheit USEC_COUNTER beinhaltet den 24 bit Z hler der die Mikrosekunden Werte die an die Frames angeh ngt werden generiert Die Einheit USEC_MUX beinhaltet den Multiplexer der den 24 bit Z hlerstand auf sechs 4 bit Grup pen aufteilt da der FIFO Eingangsdatenbus 4 bit breit ist Die Einheit DATASTREAM_MUX beinhaltet den Multiplexer der entweder den Datenstrom E_RXD oder den Z hlerstand USEC_COUNT_4BIT auf den Ausgang schaltet Diese Bl ck

Dokument 1 - Dokumentenserverhosting der SUB

Contents

Download Pdf Manuals

Related Search

Related Contents