Hallo zusammen,
ich lerne gerade für die Schule das Thema Feldbussysteme. Dabei kommt im
Script immer wieder das ISO-OSI Referenzmodell vor. Da wir aufgrund von
Corona nur 3 Schulstunden hatten und bereits 5 Tage später (schon am
Montag) die Abschlussklausur schreiben, kann ich meinem Lehrer keine
Fragen stellen. Leider eine sehr unglückliche Situation.
Im Script geht er immer wieder auf das ISO-OSI Referenzmodell ein. Er
sagt, ALLE Protokolle halten sich an den Standard und lassen sich
darin einordnen, zumindest Layer 7, 2 und 1 während ausnahmslos
ausgeprägt. Auch bei I2C oder SPI.
Da im Script keinerlei Erklärung zu den Schichten gemacht wird (nur
deren Namen), lese ich dazu viel im Internet. Irgendwie habe ich aber
das Gefühl, dass dieses Modell sich nur auf Netzwerke (Internet)
bezieht. Jede Schicht fügt wohl irgendwelche Informationen hinzu.
Letztendlich wird immer wieder erwähnt, dass sich alle daran halten und
so eine Kommunikation über alle Hersteller und Protokolle hinweg
ermöglicht wird. Alle Schichten seien zueinander kompatibel.
Mir ist einfach nicht ganz klar, WAS dieses Modell eigentlich
beschreibt. Alle Erklärungen sind einfach so allgemein gehalten, ich
finde keine Informationen was in den Schichten physikalisch geschieht.
Kurzum: Ist das eine Norm, die sagt das Byte muss so und so aufgebaut
sein? Oder nur ein theoretisches Modell das sagt: Wir brauchen XYZ, ohne
jede Spezifikation? Ich habe keine Ahnung welchen Vorteil mir das Modell
bringen soll und wie es die Kommunikation zwischen verschieden
Protokollen ermöglichen kann?
Habt ihr ein paar Sätze dazu, die mich weiterbringen? Ich will keine
vorgekaute Erklärung, nur eine kurze Info um meinen Knoten im Gehirn
aufzulösen.
Danke!
Fabian schrieb:> Kurzum: Ist das eine Norm, die sagt das Byte muss so und so aufgebaut> sein? Oder nur ein theoretisches Modell das sagt: Wir brauchen XYZ, ohne> jede Spezifikation? Ich habe keine Ahnung welchen Vorteil mir das Modell> bringen soll und wie es die Kommunikation zwischen verschieden> Protokollen ermöglichen kann?
Es ist ein theoretisches Modell. Vergleichbar mit einem Schichtenmodell
(Achtung: wie immer unpassender Autovergleich) für Fortbewegungsmittel.
Da brauche ich auch ein Medium, einen Antrieb, Routenführung usw.
Im Idealfall kann ich die einzelnen Teile unabhängig voneinander
austauschen: Auto kann auf Feldweg oder Autobahn fahren; Ethernet geht
über Kupfer, Glasfaser, Funk... Aber das Modell ist nur eine Möglichkeit
das abzubilden, nicht die einzig echte Wahrheit. Und wie auch beim Auto
das Medium "Luft" nicht wirklich funktioniert wie beim Flugzeug, ist
auch die einzelne Austauschbarkeit der Schichten (deren Trennung
manchmal auch nicht ganz scharf ist) in der Realität nur eingeschränkt
möglich.
Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet"
bzw. die damit verbundenen Protokolle folgen strikt dem
OSI-Schichtenmodell. Es gab vor ewiger Zeit mal den Versuch, das
OSI-Protokoll auf Basis des OSI-Schichtenmodells zu implementieren, aber
das ging kräftig in die Hose. Einzelne Fragmente daraus haben aber bis
heute überlebt und wurden an andere Protokollfamilien adaptiert, z.B.
X.500 als LDAP und X.509 für die Verwaltung kryptografischer Schlüssel.
X.400 für E-Mail existiert noch, hat aber seinen Zenith auch schon seit
über zwanzig Jahren überschritten.
Leider wird immer wieder auf Krampf versucht, jegliche geschichteten
Protokolle in das OSI-Modell zu pressen, aber wie heißt es doch so
schön: "Nicht alles, was hinkt, ist ein Vergleich."
Fabian schrieb:> ich> finde keine Informationen was in den Schichten physikalisch geschieht.
Nur in Schicht 1 passiert etwas physikalisches. Deshalb heißt sie auch
so.
Jan H. schrieb:> Es ist ein theoretisches Modell.
OK, der Vergleich passt aber für mich. Es wird darin also nur
festgelegt, das man etwas benötigt um XYZ zu machen. Ala: Wenn du
sprechen willst, mach zuerst den Mund auf usw.
Das mag ja als Entwickler bei Neuentwicklungen hilfreich sein, aber ich
verstehe einfach nicht warum es scheinbar so immens wichtig ist,
Profibus oder andere Busse in diese Schichten zu zerlegen. Laut unserem
Lehrer würde dadurch die Fehlersuche vereinfacht. Bleibt nur die Frage
wie und warum? Die Doku des Busses hilft mir dabei sicher weiter, das
reine Modell doch eher nicht. Ich sehe einfach keinen Sinn in diesem
Modell.
Andreas S. schrieb:> Die Aussage des Lehrers ist großer Unsinn.
Danke ;)
> Leider wird immer wieder auf Krampf versucht, jegliche geschichteten> Protokolle in das OSI-Modell zu pressen, aber wie heißt es doch so> schön: "Nicht alles, was hinkt, ist ein Vergleich."
Und damit habe ich ein Problem :) Denn was hilft es, wenn ich I2C in
diese Schichten zerlege?
Andreas S. schrieb:> Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet"> bzw. die damit verbundenen Protokolle folgen strikt dem> OSI-Schichtenmodell.
Das kann man so nicht stehen lassen. Richtig ist, dass IP und darauf
aufbauende Protokolle nicht entsprechend des OSI-Modells designed
wurden.
Aber: man kann sie rückwärts durchaus weitgehend in die OSI-Schichten
einordnen. Nur einige wenige Protokolle sind auf zwei benachbarten
Schichten des OSI-Modells beheimatet und widersetzen sich dadurch einer
eindeutigen Zuordnung.
Es ist allerdings ziemlich bezeichnend, dass gerade diese Protokolle
wiederum nur Hilfsprotokolle der IP-Protokollfamilie darstellen. Man
könnte die Sache also auch so formulieren: IP und friends ist "quick and
dirty" spezifiziert. Ohne saubere Schichten. Einfach nur so, dass es auf
Basis der damaligen Verhältnisse einfach erstmal nur funktioniert...
> Leider wird immer wieder auf Krampf versucht, jegliche geschichteten> Protokolle in das OSI-Modell zu pressen
Weil es immer sinnvoll ist, sauber getrennte Protokollschichten zu
haben.
Fabian schrieb:> aber ich> verstehe einfach nicht warum es scheinbar so immens wichtig ist,> Profibus oder andere Busse in diese Schichten zu zerlegen.
Profibus ist auch ein eher schlechtes Beispiel, weil es die meisten
Schichten in PB nicht gibt, wie du ja bereits erkannt hast.
> Laut unserem> Lehrer würde dadurch die Fehlersuche vereinfacht.
Naja.
Es geht bei PB ja nur darum zu unterscheiden, was auf dem physischen
Kabel passiert (Schicht 1), was auf der untersten MAC-Schicht passiert
(Schicht 2) und welche Anwendungsdaten über dieses System übertragen
werde (Schicht 7).
Diese Schichten sind im theoretischen Modell vollständig unabhängig und
können beliebig ausgetauscht werden, ohne das Gesamtsystem zu
beeinflussen.
In der Praxis funktioniert das auch an einigen Stellen, aber nicht immer
und überall.
Bei PB sind die Schichten tatsächlich weitgehend unabhängig.
Es kann schon bei der Fehlersuche helfen, wenn man weiß, wie z.B. auf
dem Bus addressiert und arbitriert wird und dass auf der Schicht 2 und 1
passiert. Denn wenn man ein Problem nur auf der Anwendungsebene (7) mit
den Nutzdaten hat, dann hat das wahrscheinlich nichts mit Ebene 1 und 2
zu tun. Das meint dein Lehrer wahrscheinlich damit.
Unterm Strich ist das Modell aber überbewertet, weil die praktischen
Umsetzungen alle mehr oder weniger davon abweichen.
Andreas S. schrieb:> Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet"> bzw. die damit verbundenen Protokolle folgen strikt dem> OSI-Schichtenmodell.
Das wollte ich auch gerade schreiben.
Die Aussage des Lehreres ist definitiv falsch.
@TS
TCP/IP ist nie auf Basis des OSI Schichtenmodells enstanden, sondern
entstand direkt aus der Praxis weil sich einer hingesetzt hat und
einfach gemacht hat.
Später hat man dann versucht TCP/IP irgendwie rückwirkend ins OSI
Schichtenmodell einzupassen, so richtig passt es aber nicht.
Ein Blick in die beiden Wikipediaartikel zeigt auch warum.
> Es gab vor ewiger Zeit mal den Versuch, das> OSI-Protokoll auf Basis des OSI-Schichtenmodells zu implementieren, aber> das ging kräftig in die Hose.> ...> Leider wird immer wieder auf Krampf versucht, jegliche geschichteten> Protokolle in das OSI-Modell zu pressen, aber wie heißt es doch so> schön: "Nicht alles, was hinkt, ist ein Vergleich."
Genau so ist es.
Nano schrieb:> Später hat man dann versucht TCP/IP irgendwie rückwirkend ins OSI> Schichtenmodell einzupassen, so richtig passt es aber nicht.
TCP/IP sind aber nur ein Teil des Modells. Auch wenn sie sich eine
Adressierung teilen und deshalb nicht unabhängig sind, kann man die
restlichen Schichten (1, 2, 5, 6, 7) beliebig austauschen.
Ob du über Ethernet (1+2), WLAN (1+2) oder Buschfunk (1+2) ins Internet
gehst, spielt keine Rolle. Genau so kann man die oberen Schichten
austauschen. Auch einzeln.
Nano schrieb:> Andreas S. schrieb:>> Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet">> bzw. die damit verbundenen Protokolle folgen strikt dem>> OSI-Schichtenmodell.>> Das wollte ich auch gerade schreiben.> Die Aussage des Lehreres ist definitiv falsch.>> @TS
Blödsinn hoch 10!
Ich finde es äußerst beschämend so über eine Person zu urteilen die sich
hier nicht geäußert hat!
Wenn hier dumme Personen im Forum nachfragt dann hat er selber Probleme
um Verstaendnis. Das hat nichts mit dem Lehrpersonal zu tun.
Fabian schrieb:> Das mag ja als Entwickler bei Neuentwicklungen hilfreich sein, aber ich> verstehe einfach nicht warum es scheinbar so immens wichtig ist,> Profibus oder andere Busse in diese Schichten zu zerlegen.> ...> Laut unserem> Lehrer würde dadurch die Fehlersuche vereinfacht. Bleibt nur die Frage> wie und warum?
Wenn du eine ein neues Protokoll bspw. in der Bitübertragunsgschith
(Schicht 1) oder Sicherungsschicht (Schicht 2) oder bzw.
Netzzugangsschicht einführst und dieses zum Schichtenmodell kompatibel
machst, dann kannst du alle darüber liegenden Protokolle in den höheren
Schichten darüber laufen lassen ohne groß diese selbst schreiben zu
müssen oder Änderungen vornehmen zu müssen.
Wenn du also mal angenommen eine Leitung zu deinem Gartenhäuschen im
Garten baust und dir dafür ein neues Protokoll für einen unüblichen
Übertragungsweg ausdenkst. Z.b. Blitzlicht vom Wohnzimmerfenster ins
Gartenhäuschen und zurück und du dieses Protokoll dann Kompatibel zum
OSI Modell machst.
Dann kannst du darüber die Protokolle in den höheren Schichten
transportieren und somit alle Netzwerksoftware und Protokolle nutzen
ohne groß an diesen Änderungen vornehmen zu müssen.
Du könntest also bspw. Webseiten an dein Notebook im Gartenhäusschen
über dein Blitzlich übertragen ohne einen Browser selber schreiben zu
müssen, da HTTP in der Anwendungsschicht liegt und auf Schicht 6
aufbaut, welche wiederum auf Schicht 5 aufbaut und die Software aus
dieser Kategorie verwendet. Das geht so weit runter bis zu der Schicht
in dem dein Protokoll gültig ist und nur für dieses müsstest du dann
Treiber schreiben.
Alles andere kannst du somit wiederverwenden und das senkt dann auch die
Fehlersuche im Protokoll. Denn wenn bspw. eine ssh Verbindung über dein
Protokoll gut funktioniert, dann kannst du davon ausgehen, dass es kaum
noch Fehler enthält.
Versteher schrieb:> Ich finde es äußerst beschämend so über eine Person zu urteilen die sich> hier nicht geäußert hat!
Es wurde nicht über eine Person geurteilt, sondern es wurde eine Aussage
dieser Person bewertet. Das ist ein Unterschied.
Dass sich die allgemein "im Internet" verwendeten Protokolle strikt an
das Modell halten, ist eben sachlich falsch. Das hat mit der Person gar
nichts zu tun.
Versteher schrieb:> Nano schrieb:>> Andreas S. schrieb:>>> Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet">>> bzw. die damit verbundenen Protokolle folgen strikt dem>>> OSI-Schichtenmodell.>>>> Das wollte ich auch gerade schreiben.>> Die Aussage des Lehreres ist definitiv falsch.>>>> @TS>>> Blödsinn hoch 10!
Der TS hat gesagt: "Er sagt, ALLE Protokolle halten sich "
und das ist eben falsch, da TCP/IP nie auf Basis des OSI
Schichtenmodells entwickelt wurde.
Man hat nur im Nachgang versucht es irgendwie passend zu machen.
> Ich finde es äußerst beschämend so über eine Person zu urteilen die sich> hier nicht geäußert hat!
Wir können natürlich jetzt nur davon ausgehen, dass der TS
wahrheitsgemäß erzählt, was sein Lehrer zu ihm gesagt hat.
Alles andere bringt nichts und da der Lehrer hier ein absolute
Unbekannte für uns alle ist, sehe ich darin auch kein Problem.
> Wenn hier dumme Personen im Forum nachfragt dann hat er selber Probleme> um Verstaendnis. Das hat nichts mit dem Lehrpersonal zu tun.
Lehrer wissen auch nicht alles.
In den MINT-Fächern auf Lehramtbasis lernen die angehenden
Lehramtsstudenten nur einen Bruchteil von dem, was echte MINT-ler in
ihrem Studium gelernt haben.
Die Lehrer finden somit ihre Meister, sobald sie auf echte MINT-ler
stoßen.
Glück haben die Schüler, die echte Mint-ler als Lehrer bekommen, die den
Stoff ihres unterrichtees Schulfach nicht auf Lehramtbasis gelernt
haben.
So etwas kann bspw. in den Berufsschulen vorkommen. An den allgemeinen
Schulen ist es eher die Ausnahme.
Fabian schrieb:> Das mag ja als Entwickler bei Neuentwicklungen hilfreich sein, aber ich> verstehe einfach nicht warum es scheinbar so immens wichtig ist,
Es gibt im Ingenieurbereich einige wenige Grundprinzipien um Probleme zu
lösen. Ein Prinzip ist "Teile und herrsche." Um ein komplexes Problem
handhabbar und lösbar zu machen zerlegt man es in kleine Teilprobleme.
Das OSI-Referenzmodell beschreibt eine solche Zerlegung.
Dann macht man im Ingenieurbereich immer gerne etwas nach einem
vorgegebenen Schema. Wenn etwas funktioniert, dann zieht man das immer
wieder so durch. Darin unterscheidet man sich übrigens gewaltig von der
Informatik. Die Informatiker wollen immer alles neu machen, reißen mit
dem Arsch ab was sie mit den Händen aufgebaut haben und erkennen dabei
nicht einmal wenn sie einen Gewinner haben.
Gleichzeitig, dass ist das "Referenz" im Namen, bekommst du mit dem
OSI-Referenzmodell einen Vergleichsmaßstab. Genau wie ein Meter zum
Vergleich von Längen dient, oder ein Liter zum Vergleich von Volumen,
dient das OSI-Referenzmodell zum Vergleich von Netzwerktechniken.
Das läuft dann beispielsweise so ab: Du musst ein neues Protokoll
lernen. Du lernst nicht alles von Anfang an, sondern ziehst Vergleiche
zum Referenzmodell. Alle Konzepte die mit dem Referenzmodell halbwegs
übereinstimmen musst du nicht neu lernen wenn du das Referenzmodell
gelernt hast. Nur das wo das Protokoll nicht auf die Referenz passt
musst du Grundsätzliches neu lernen.
> Profibus oder andere Busse in diese Schichten zu zerlegen. Laut unserem> Lehrer würde dadurch die Fehlersuche vereinfacht.
Wie sage ich das jetzt? Dein Lehrer ist ein bisschen merkwürdig drauf.
Ja, in komplizierten Netzwerkprotokollen helfen die Schichten bei der
Fehlersuche. So wichtig ist das Modell da aber nicht, weil man auf die
Idee schichtweise vorzugehen auch selber kommt. Schön nacheinander
systematisch prüfen. Das ist wieder das "Teile und herrsche". Ist das
Kabel drin und sind Signale drauf? Gratulation, du hast soeben die
physikalische Schicht geprüft.
> wie und warum? Die Doku des Busses hilft mir dabei sicher weiter, das> reine Modell doch eher nicht.
Unterschätze nicht die Komplexität einiger Protokolle und Schichten.
Ethernet Schicht 1 und Schicht 2 sind auf tausenden von Seiten
dokumentiert. Mobilfunk dürfte in die Millionen Seiten gehen.
Das ließt du nicht von Anfang bis Ende. Da bist du froh, dass du alle
Schichten über und unter der Stelle an der du werkeln musst erst einmal
als Black-Box betrachten kannst.
> Ich sehe einfach keinen Sinn in diesem> Modell.
Ehrlich, dann lass es. Es ist ein Werkzeug. Ich wundere mich immer wenn
Handwerker sich selber einschränken und sich selber um Werkzeuge
berauben, aber das ist deine Entscheidung. Nicht jedes Werkzeug aus der
Werkzeugkiste braucht man jeden Tag. Aber wenn es ernst wird ist man
ganz froh, dass man unten in der Kiste noch was liegen hat und man weiß
wie man damit umgeht.
Zuerst ein "Danke" an alle Schreiber, fast alles hat mir bis hierhin
schon mal geholfen!
OSI schrieb:> Es kann schon bei der Fehlersuche helfen, wenn man weiß, wie z.B. auf> dem Bus addressiert und arbitriert wird und dass auf der Schicht 2 und 1> passiert. Denn wenn man ein Problem nur auf der Anwendungsebene (7) mit> den Nutzdaten hat, dann hat das wahrscheinlich nichts mit Ebene 1 und 2> zu tun. Das meint dein Lehrer wahrscheinlich damit.
OK, das leuchtet ein.
Nano schrieb:> Alles andere kannst du somit wiederverwenden und das senkt dann auch die> Fehlersuche im Protokoll.
Auch das leuchtet ein. Klar, die Schichten sind im optimalsten Fall
getrennt und ich kann diese austauschen. Alles super. Aber gerade an
diesem Punkt kommt mein Verständnisproblem: Wenn ja nur beschrieben
wird, dass es sowas geben muss, dann bringt mir das OSI-Modell ohne
Kenntnisse der verwendeten "Normen" in der Form nichts, da die
Schnitstellen unbekannt sind. AH OK! Jetzt fiel der Groschen hoffentlich
;D
Das eine geht ohne das andere nicht. Wie sollte man auch eine Norm
schreiben, wenn nirgendwo festgelegt wurde, wie weit diese Norm geht.
Das OSI-Modell legt also einen Grundrahmen fest, der dann von anderen
Protokollen/Normen ausgestaltet wird. Diese wiederum halten sich an die
vom Modell gesteckten Grenzen.
Ich hoffe das stimmt so und macht Sinn? ;)
Dazu passt ja:
Hannes J. schrieb:> Es gibt im Ingenieurbereich einige wenige Grundprinzipien um Probleme zu> lösen. Ein Prinzip ist "Teile und herrsche." Um ein komplexes Problem> handhabbar und lösbar zu machen zerlegt man es in kleine Teilprobleme.> Das OSI-Referenzmodell beschreibt eine solche Zerlegung.
Also abstrakt gesagt:
Man kann die Schichten quasi als Black-Box ansehen. Das OSI-Modell sagt
nur, das ich eine Black-Box für z.B. Schicht 3 nehmen kann. Das
Protokoll der Box sagt mir dann, wie ich sie anspreche und was sie
ausgibt. Diese beiden Dinge sind also völlig unabhängig.
Am Anfang der Fragestellung war ich noch der Meinung, das OSI-Modell
kümmert sich um alles und definiert auch das allgemeine Aussehen der
Schnittstellen.
OSI schrieb:> Dass sich die allgemein "im Internet" verwendeten Protokolle strikt an> das Modell halten, ist eben sachlich falsch. Das hat mit der Person gar> nichts zu tun.Nano schrieb:> Wir können natürlich jetzt nur davon ausgehen, dass der TS> wahrheitsgemäß erzählt, was sein Lehrer zu ihm gesagt hat.
Ja, so war sinngemäß die Aussage unseres Lehrers. Er sagte, das sich
ALLE Protokolle die es gab und derzeit gibt, ohne Einschränkungen in das
Modell überführen lassen. Egal ob mündliche Sprache, Rauchzeichen oder
sonst was, da es immer die Schichten 1, 2 und 7 geben müsse.
Auch hat er vor kurzem Informatik studiert. Soviel zu seiner Bildung.
Wie gesagt, wir hatten nur 3 Schulstunden mit ihm, sonst hätte ich
nochmal nachfragen können. Vielleicht kann ich das nach der Klausur
machen, jetzt habe ich ja Verständnis für das Thema.
Versteher schrieb:> Wenn hier dumme Personen im Forum nachfragt dann hat er selber Probleme> um Verstaendnis. Das hat nichts mit dem Lehrpersonal zu tun.
Meinst du mich mit der dummen Person?
Fabian schrieb:> Am Anfang der Fragestellung war ich noch der Meinung, das OSI-Modell> kümmert sich um alles und definiert auch das allgemeine Aussehen der> Schnittstellen.
Ja, das ist eine Fehlannahme.
Das OSI-Modell definiert eben keine Schnittstellen zwischen den
Schichten. Ganz im Gegenteil. Jede Schicht packt ihre Daten in ein Paket
und gibt das ganze Paket an die Nachbarschicht weiter. Die Schicht
darunter Packt dieses Paket unverändert und uninterpretiert in ihr
eigenes Paket. Je weiter nach unten, desto mehr Kartons werden in
(leicht größere) Kartons verpackt. Das Postgeheimnis wird gewahrt.
Ein text wird oft in Einleitung, Hauptteil und Schluss unterteilt. Dann
kannst Du jeden Text nehmen, und den danach unterteilen. Irgendwie
stimmt das immer. Manchmal fällt ein Teil weg oder geht in den anderen
über oder die Einleitung kommt erst am Schluss.... Aber alle halten sich
dran und es erleichtert die Analyse des Textes ...
Oder alle Wohnungen haben Flur, Schlafzimmer, Küche, Bad, Wohnzimmer,
Arbeitsraum und Abstellkammer. Passt immer, selbst wenn es ein
einzimmerarpartment ist.
Das OSI-Modell ist für die Fehlersuche nur ein Hilfsmittel um
strukturiert die Ursache einzugrenzen. Für den ersten Einstieg reicht es
völlig aus wenn man folgendes verinnerlicht: Die Schritte die auf der
Senderseite gemacht werden, müssen in umgekehrter Reihenfolge auf der
Empfängerseite durchgeführt werden.
Das Bild vom 7-Schichten-Modell unter nachfolgendem Link geht mit den
senkrechten Pfeilen deutlicher darauf ein:
https://www.elektronik-kompendium.de/sites/kom/0301201.htm
Wie bereits von pnuebergang geschrieben ist der Zweck von solchen
Modellen eine herstellerunabhängige Beschreibung. Dadurch ist es erst
möglich das z.B. eine Baugruppe von Alcatel über ein gemeinsam
unterstütztes Protokoll auch mit einer Baugruppe von Beckhoff,
Honneywell, Siemens, usw. kommunizieren kann. Egal ob die anderen
Hersteller zufälligerweise die gleichen Schaltungskomponenten verwenden,
die Firmware mit der gleichen Programmiersprache erstellt haben, usw..
In der Praxis kann man natürlich nicht mehr an allen Stellen nachprüfen
und man muß hier dem Hersteller vertrauen das er seine Hausaufgaben bei
der Entwicklung gemacht hat. Trotzdem gibt es noch genug Punkte die man
auf Sender- und Empfängerseite prüfen kann.
In einem kleinen Testaufbau führt das aufgrund der Überschaubarkeit
schnell zur Annahme das man diesen ganzen Aufwand mit dem Referenzmodell
nicht braucht. In einer großen Fabrikhalle wo die Schaltschränke in 20m
Entfernung auf einer Schaltschrankbühne stehen ist das eine völlig
andere Situation.
Beispiel strukturierte Fehlersuche nach OSI Modell : Ich komme mit
meinem PC nicht mehr ins Internet
1
1) Browser öffnen und Internetseite aufrufen (Aus den Favoriten auswählen damit sich kein Tippfehler einschleicht) -> Fehlermeldung: Seite kann nicht aufgerufen werden
2
2) Kommandozeile öffnen und Router anpingen -> Fehlermeldung: Keine Antwort
3
3) Auf der Kommandozeile mit ipconfig prüfen ob die Netzwerkkarte eine IP-Adresse hat (sofern DHCP verwendet wird) und wie der Medienstatus lautet -> Meldung: Medium getrennt
4
4) Am PC kontrollieren ob die Link-LED der Netzwerkkarte leuchtet -> Ergebnis: LED ist aus
5
5) Netzwerkkabel am PC aus- und korrekt wieder einstecken -> Ergebnis: LED bleibt aus
6
6) Netzwerkkabel vom PC zum Router verfolgen -> Ergebnis: Kabel ist unterbrochen (Bissspuren einer Katze ;-))
7
7) Netzwerkkabel austauschen (Ab jetzt in umgekehrter Reihenfolge zurück)
8
8) Am PC kontrollieren ob die Link-LED der Netzwerkkarte leuchtet -> Ergebnis: LED leuchtet
9
9) Auf der Kommandozeile mit ipconfig prüfen ob die Netzwerkkarte eine IP-Adresse hat und wie der Medienstatus lautet -> Meldung: IP-Adresse wird angezeigt
10
10) Seite im Browser aktualisieren -> Seite wird aufgebaut
Beispiel unstrukturierte Fehlersuche (nicht ganz ernstzunehmen)
1
1) Browser öffnen und Internetseite aufrufen (Per Hand eingeben und Tippfehler nicht bemerkt) -> Fehlermeldung: Seite kann nicht aufgerufen werden
2
2) Tippfehler bemerkt und korrigiert -> Fehlermeldung: Seite kann nicht aufgerufen werden
3
3) Alle Programme schließen und PC neustarten
4
4) Browser öffnen und Internetseite aufrufen (Aus den Favoriten auswählen damit sich kein Tippfehler einschleicht) -> Fehlermeldung: Seite kann nicht aufgerufen werden
5
5) Router neustarten (Netzteil aus- und wiedereinstecken)
6
6) Seite im Browser aktualisieren -> Fehlermeldung: Seite kann nicht aufgerufen werden
7
7) Treiber für Netzwerkkarte deinstallieren, Rechner neustarten und Treiber wieder installieren
8
8) Browser öffnen und Internetseite aufrufen (Wieder aus den Favoriten auswählen) -> Fehlermeldung: Seite kann nicht aufgerufen werden
9
9) Netzwerkkabel am PC aus- und korrekt wieder einstecken
10
10) Seite im Browser aktualisieren -> Fehlermeldung: Seite kann nicht aufgerufen werden
11
11) Netzwerkkabel am Router aus- und korrekt wieder einstecken
12
12) Seite im Browser aktualisieren -> Fehlermeldung: Seite kann nicht aufgerufen werden
13
13) Router nochmal neustarten (Netzteil aus- und wiedereinstecken)
14
14) Seite im Browser aktualisieren -> Fehlermeldung: Seite kann nicht aufgerufen werden
Timo R. schrieb:> Das OSI-Modell ist für die Fehlersuche nur ein Hilfsmittel um> strukturiert die Ursache einzugrenzen.
Wenn den Jugendlichen von veralteten Lehrern (Produktion vor 1995) nur
das OSI-Modell (mit 7 Schichten) und nicht das TCP/IP-Modell (4
Schichten) beigebracht wird, dann sind die Folgen aus
>The OSI protocol suite that was specified as part of the OSI project was
considered by many as too complicated and inefficient, and to a large extent
unimplementable
https://en.wikipedia.org/wiki/OSI_model#Comparison_with_TCP/IP_model
in sogenannten 'strukturierten' Fehlersuchen, die unstrukturiert 10
Punkte raten müssen, nachlesbar.
Sinnvoll wäre es die Jugendlichen darüber aufzuklären, dass selbst
Deutschland Mitte der 1990er die Hoffnung auf ein ITU-Netz nach
OSI-Modell als Alternative zum Internet aufgegeben hat und üblicherweise
Technik nach dem TCP-IP-Modell verwendet.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten